Terminology

[Alexei]

I'm looking for better terminology, something more self explanatory and user friendly. Terms like "Triggers", "Alarms", "Alerts", "Queue", "Screens" may be confusing and even incorrect.

So, here is full list of terms in question:

Latest values
Triggers
Queue
Alarms - "Events"
Alerts - "Notifications", but actually "Alerts" is list of actions performed. So, maybe "Action history" is better alternative?
Network maps - "Maps"
Graphs
Screens - "Vews"
Actions

Please, feel free to discuss it. I appreciate any suggestions.

[cooper]

Triggers
Alarms - "Events"
Alerts - "Notifications", but actually "Alerts" is list of actions performed. So, maybe "Action history" is better alternative?

Please, feel free to discuss it. I appreciate any suggestions.

For me having triggers appear twice, once as a config option and once as a status option, is slightly confusing. The way i see it, a trigger is configured to generate an alarm. So if an alarm occurs, it was generated by a trigger. I dont need to know the trigger is positive, the alarm tells me that.

I think that changing 'alarms' to 'events' would be good, because not every event needs to generate an alarm. If you had an event that happened several times or over a course of 10 mins. that may be an alarm. An alarm being something that needs to be responded to rather than an 'event' that just needs to be looked in to.

Alerts took me a little time to get used to. They seem to just be a record of the action that was taken to contact an admin. I would consider an alert more of a current "hey look at me i am having problems" indicator, or 'alarm, and 'action history' being more what the current 'alerts' is like.

just my $.02.

thanks

cooper

[riegersteve]

trigers should be called variables, and should not show up in the status page, only in the config section.

thats all

[LEM]

My 20 cents proposal:

• TRIGGERS: I propose PROBES. In fact, triggers are probes set on a monitoring target. Perhaps, PROBES should be used during configuration, and VALUES could be used during usage/views/consultation?
• QUEUE: unchanged
• ALARMS: I propose EVENTS
• ALERTS: I propose NOTIFICATIONS
• NETWORK MAPS: I propose MAPS, more generic as MAPS may be * based (network, functionnal, system...). An alternative should be "OPERATIONAL VIEWS".
• GRAPHS: unchanged
• SCREENS: I propose VIEWS. An alternative should be "TECHNICAL VIEWS"
• ACTIONS: unchanged

[Alexei]

Thanks for all replies!

So far:

Latest values - Unchanged.
Triggers - Probes? I don't know. Is "probe" kind of synonym to "agent"?
Alarms - Events.
Alerts - Notifications.
Network maps - Maps.
Graphs - Unchanged.
Screens - Views.
Actions - Unchanged.

[LEM]

Triggers - Probes? I don't know. Is "probe" kind of synonym to "agent"?

Well, a probe detect what she's programed to. Agents are "only" media to assume communications between monitoring targets (servers) and the monitoring core infrastructure (zabbix daemons).

Anyway, 'trigger' fits well to.

[LEM]

• NETWORK MAPS: I propose MAPS, more generic as MAPS may be * based (network, functionnal, system...). An alternative should be "OPERATIONAL VIEWS".
• SCREENS: I propose VIEWS. An alternative should be "TECHNICAL VIEWS"

I come back on the "views" ideas : "Business/Operational/Technical views". Some other proprietary monitoring software base some of their terminology (both technical and marketing) with the idea they provide views to different kinds of users:Business views for sales/customer-account-managers, Operational views for helpdesk/delivery-managers, and Technical views for... technical peoples.

Taking ZABBIX frontend, we've got :

• Actual "Screens": to show technical datas. Some kinds of Technical views, isn't it?
• Actual "MAPS": to show operationnal views, both technical and functionnals. So, Operational views is not a so bad terms, isn't?
• Actual "IT Services": to show business related views (SLAs).

We're not forced to use these terms ([business,operational,technical] views) instead of IT-Services/Maps/Screens, but we should keep them in mind for the marketing part of the ZABBIX docs.

[TheEdge]

I'm looking for better terminology, something more self explanatory and user friendly. Terms like "Triggers", "Alarms", "Alerts", "Queue", "Screens" may be confusing and even incorrect.

So, here is full list of terms in question:

Latest values
Triggers
Queue
Alarms - "Events"
Alerts - "Notifications", but actually "Alerts" is list of actions performed. So, maybe "Action history" is better alternative?
Network maps - "Maps"
Graphs
Screens - "Vews"
Actions

Please, feel free to discuss it. I appreciate any suggestions.

- For me the biggest confusing thing as a new user was the fact that the same term appears twice (top row, bottom row) and one was to "look at" something and one was to "configure" something. As part of the renaming I would suggest that the HTML be extended to provide an explanation of what the HREF is for. ie add some ALT tags. So for instance hovering over "Graphs" would say something like. "Select this option to configure your own custom graphs for use with user defined screens".
- I also agree with other posters that the interface needs to be seperated into "areas". That is I want to be able to do configuration or I want to be doing monitoring. Having them clearly seperated would make it easier to understand what is going on. It would also be great if say when you were "configuring" something that you saw a "preview" of what it would look like. That way you would not have to configure it and then go and monitor something you have just created to see if it does what you want it to.
- As I am using the 1.0 release I am not sure how much of this has been addressed with 1.1

Just my 2c worth.

[Wolfgang]

Here my 2 cent.


View Triggers - Trigger Status
View Queue - Queue Status
View Screens - Views

Configuration Items - Checks (an item can be anything. a host, a check, a trigger, etc.)
Configuration Screen - Views (graphs and histories are grouped in views)

Configuration General Mediatype - Actiontypes

As for Configuration/General/User and Configuration/General/Mediatype this is bit confusing for me.

For example, so far a "media type " can be a script, but is assigned to a user or group. Also a media type is assigned to a trigger. So i assign a trigger always to a user or group. But what if a script takes care? In that case i would define a dummy user account, only to get the script assigned.

A suggestion would be:
A "trigger" is assigned to an "actionset". An "actionset" uses a group of actions defined as actiontypes. An "actiontype" can be something like exec a script, send an email or perform any other predefined function that might not yet exist. But it should not depend on a user. Of cause, an "actionset" can use actions from any actiontype like "send email" or "send sms" to contact a particular user or user group. But an actiontype can also be a simple script that is not connected to an user.


So in short:
-checks query data
-data can be monitored by triggers
-triggers define the severity of the event.
-triggers start an actionset, which is a group of actions.
-actions are defined by actiontypes and do things like send an email, send a sms, run a script, restart a service etc.

and...
-the result of checks can be put into graphs or histories.
-graphs and histories can be grouped to views
-hosts can be placed on maps for visualisation

[Tractor]

Terms

Hi, there are lots of standard terms and some of those are really clear, if you simply describe what some term means. wolfgang had done most of this. More specifically, what means what:

Trigger - trigger or threshold which describes conditions in which service status gets changed, e.g. from UP to DOWN, etc.. Anyway, this is not Probe nor variable :-)
Probe - probe or Check module which generates some variable (QoS data) according to actual service status at the moment. Actually, it is some software module or plugin having some configuration set.
Variable - or QoS data - it is simply result returned by the Probe. Such result can be processed by some trigger resulting in actual service status, like "UP" or "DOWN".
Alarm or Event - it is not so clear term, but actually, we allways should have some object which should generate some actions in some conditions described in triggers. So, event when trigger changes its status is Event.
Alert, Action, Notification - it is simply Action, some thing which should be done when some Event occurs. Notification is simply kind of such Action.

there are several other terms, like:
QoS data - Quality of Service data - data describing actual running service parameters.
SLO - Service Level Objective - complex of triggers/tresholds which describe what means "running service" and what means "not running service".
SLA - Service Level Aggreement - Complex of SLOs with thresholds describing how long SLO can be violated before SLA will be broken.

Regards - Ricardas.

[Siegfried]

Personally, I would not change trigger for probe. If anything would be named probe, I'd go with Items, as they are the parts that gather the information, and not generate actions.

Trigger does sound ok, but the suggested Threshold could be very good too.

Audit could be changed to History

Also, I agree that triggers in monitoring should be changed to something else, at the very least Trigger Status (or whatever "trigger" is replaced with) if no better wording can be found.

0.02$

[TheLead]

- For me the biggest confusing thing as a new user was the fact that the same term appears twice (top row, bottom row) and one was to "look at" something and one was to "configure" something. As part of the renaming I would suggest that the HTML be extended to provide an explanation of what the HREF is for..........

I agree with TheEdge's comments - the "same term" repeated is very difficult to understand at first. Clearly showing the lower section for initial setups would make the interface more intuitive.

Also some graphs are buried deeply in the menus. A method to centralise these would also make Zabbix easier to use.

Its a great product, well done to the dev team, the hard work is worth it.

Thanks! TheLead

[KarmaPolice]

I'm looking for better terminology, something more self explanatory and user friendly. Terms like "Triggers", "Alarms", "Alerts", "Queue", "Screens" may be confusing and even incorrect.

So, here is full list of terms in question:

Latest values
Triggers
Queue
Alarms - "Events"
Alerts - "Notifications", but actually "Alerts" is list of actions performed. So, maybe "Action history" is better alternative?
Network maps - "Maps"
Graphs
Screens - "Vews"
Actions

Please, feel free to discuss it. I appreciate any suggestions.

I like where you're going with this idea, i'll throw my ideas in as i can see a lot of people are getting very technical...

Latest values = this is good
Triggers = good
Queue = good
Alarms - I actually like this as alarms it makes the most sense in my mind
Alerts - definitely needs changing, not sure to what though it's too close to "alarms", there is no way to distinguish between the two based on name
Network maps - Maps
Graphs
Screens - "Views" or perhaps "Panels"
Actions

[bdub]

Personally I wouldn't change either triggers or screens. They both seem reasonable and self explanatory to me. I wouldn't mind seeing alerts become Notifications however, and Audit could be History.

My .02.

[rhenson]

Triggers
Queue
Alarms - "Events"
Alerts - "Notifications", but actually "Alerts" is list of actions performed. So, maybe "Action history" is better alternative?
Network maps - "Maps"
Graphs
Screens - "Views"
Actions

Network Maps - "Topology". Topology makes me think of a network map, which is what you appear to be after.

Triggers - Looks like fired triggers, so Events would be a good name

Events - Looks like a configuration change log, so perhaps just "Change Log"

Screens - Seems like a way to customize a portal, so "Views" or "Portals" sounds good to me

Latest Data - This is like doing a tail on your raw data, which is useful perhaps for debugging purposes, but I would think it better to try and compile some type of view to make better sense of the data.

I am still new to your software, so perhaps I can provide the perspective of someone who is trying to figure this out intuitively as to what I think you intended to provide with the software. I would like to say how easy the program was to get setup and how much variety it appears to provide. I was interested in simply monitoring our service availability, but it seems this can do much more then that! Kudos to you!