| ZABBIX Manual v1.6 | Release 017 | |||
|---|---|---|---|---|
| Review and Approval | ||||
| Name | Signature | Date | ||
| For ZABBIX SIA: | ||||
No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of ZABBIX SIA
Copyright 2008 ZABBIX SIA, REGISTERED IN LATVIA NO: LV40003738045
1.ABOUT....................................................................................................................20
1.1.Revision History...........................................................................................................20 1.2.Conventions..................................................................................................................20 1.3.Distribution list.............................................................................................................21 1.4.Overview of ZABBIX.....................................................................................................22
1.4.1.What is ZABBIX? ............................................................................................22 1.4.2.What does ZABBIX offer? ..............................................................................22 1.4.3.Why use ZABBIX? ..........................................................................................23 1.4.4.Users of ZABBIX .............................................................................................23
1.5.Goals and Principles....................................................................................................23 1.5.1.Main Goals of ZABBIX Development ..............................................................23 1.5.2.Main principles of ZABBIX development..........................................................23
1.6.What’s new in ZABBIX 1.6...........................................................................................24 1.6.1.Escalations and Repeated notifications...........................................................24 1.6.2.Much Better Performance................................................................................24 1.6.3.Support of IPv6................................................................................................24 1.6.4.Support of IPMI................................................................................................24 1.6.5.Better Distributed Monitoring...........................................................................24 1.6.6.ZABBIX Proxy Process....................................................................................24 1.6.7.Dashboard.......................................................................................................24 1.6.8.Dynamic Screens.............................................................................................25 1.6.9.Nice Zoom for Graphs.....................................................................................25 1.6.10.Pie Charts......................................................................................................25 1.6.11.Basic Management Functions........................................................................25 1.6.12.More Efficient Communication with Agents....................................................25 1.6.13.More Efficient ZABBIX Sender.......................................................................25 1.6.14.Improved View of Trigger Statuses................................................................25 1.6.15.Support of SNMP Data with Dynamic Index...................................................25 1.6.16.Special Processing of Well-known SNMP OIDs.............................................25 1.6.17.Added Printable View for All Screens............................................................26
1.6.18.Disabling of Login Rights for a Group of Users..............................................26
1.6.19.Added Support of UTF-8................................................................................26
1.6.20.Added Screen for Better Management of Translations..................................26
1.6.21.Added Maintenance Mode.............................................................................26
1.6.22.Unlimited Number of Map Link Styles............................................................26
1.6.23.Improved User Permission Schema...............................................................26
1.6.24.Other Improvements......................................................................................26 1.6.24.1.Queue moved into Administration...............................................................26 1.6.24.2.Link to Maps, Screens and Graphs moved to the Dashboard.....................26 1.6.24.3.Auto-login option.........................................................................................27 1.6.24.4.New communication protocol......................................................................27 1.6.24.5.Support of themes for ZABBIX front-end....................................................27 1.6.24.6.User ‘guest’ can be disabled.......................................................................27 1.6.24.7.Disabling of a group of users......................................................................27 1.6.24.8.Database down screen...............................................................................27 1.6.24.9.Duplicated Login removed..........................................................................27 1.6.24.10.Added sorting for all screens....................................................................27 1.6.24.11.Better informative message......................................................................27 1.6.24.12.Support of import/export of the host template linkage information............27 1.6.24.13.Support of negative values in graphs........................................................28 1.6.24.14.Support of directories in the parameter Include........................................28 1.6.24.15.Support of new macros.............................................................................28 1.6.24.16.New after-login greeting message............................................................28 1.6.24.17.Auto-discovery by ICMP ping....................................................................28 1.6.24.18.Increased number of log entries sent per second.....................................28 1.6.24.19.Added mass-update functionality for hosts and triggers...........................28 1.6.24.20.Added full-screen icon..............................................................................28 1.6.24.21.Active only mode for ZABBIX agent..........................................................28 1.6.24.22.Added monitoring of Proxy availability......................................................28 1.6.24.23.Added protection against brute-force attacks............................................29 1.6.24.24.Improved event viewing............................................................................29 1.6.24.25.More accurate ICMP pings........................................................................29 1.6.24.26.Support of bulk acknowledgements..........................................................29 1.6.24.27.Added time filter to Availability Report.......................................................29 1.6.24.28.History of Actions moved under Administration.........................................29 1.6.24.29.Required server performance value is available.......................................29 1.6.24.30.Added support of auto-login......................................................................29 1.6.24.31.Automatic selection of the first element in drop-downs.............................29 1.6.24.32.Last access time is displayed for users.....................................................29 1.6.24.33.More flexible Status of Trigger screen......................................................29 1.6.24.34.Extended host profiles..............................................................................30
1.7.Installation and Upgrade Notes...................................................................................30
1.7.1.Installation........................................................................................................30
1.7.2.Version compatibility........................................................................................30
1.7.3.Important.........................................................................................................30
1.7.4.Upgrade procedure..........................................................................................30 1.7.4.1.Stop ZABBIX server......................................................................................30
1.7.4.2.Backup existing ZABBIX database...............................................................30 1.7.4.3.Backup configuration files, PHP files and ZABBIX binaries..........................30 1.7.4.4.Install new server binaries.............................................................................31 1.7.4.5.Review Server configuration parameters......................................................31 1.7.4.6.Upgrade database........................................................................................31 1.7.4.7.Install new ZABBIX GUI................................................................................31 1.7.4.8.Start new ZABBIX binaries...........................................................................31
1.8.Commercial support.....................................................................................................31
2.INSTALLATION.......................................................................................................33
2.1.How to Get ZABBIX......................................................................................................33 2.2.Requirements...............................................................................................................33
2.2.1.Hardware Requirements..................................................................................33 2.2.1.1.Memory Requirements..................................................................................33 2.2.1.2.CPU Requirements.......................................................................................33 2.2.1.3.Other hardware.............................................................................................33 2.2.1.4.Examples of hardware configuration.............................................................33 2.2.2.Supported Platforms........................................................................................34 2.2.3.Software Requirements...................................................................................35 2.2.4.Choice of database engine..............................................................................36 2.2.5.Database size..................................................................................................36 2.2.6.Time synchronization.......................................................................................38
2.3.Components.................................................................................................................39 2.3.1.ZABBIX Components.......................................................................................39 2.3.2.ZABBIX Server................................................................................................39 2.3.3.ZABBIX Proxy..................................................................................................39 2.3.4.ZABBIX Agent..................................................................................................39 2.3.5.The WEB Interface..........................................................................................40
2.4.Installation from Source..............................................................................................40 2.4.1.Software requirements.....................................................................................40 2.4.2.Structure of ZABBIX distribution......................................................................41 2.4.3.ZABBIX Server................................................................................................42 2.4.4.ZABBIX Proxy..................................................................................................47 2.4.5.ZABBIX Agent..................................................................................................51 2.4.6.ZABBIX WEB Interface....................................................................................54
2.5.Upgrading.....................................................................................................................64
2.5.1.Database upgrade...........................................................................................64
3.ZABBIX PROCESSES............................................................................................65
3.1.ZABBIX Server..............................................................................................................65 3.2.ZABBIX Proxy...............................................................................................................68 3.3.ZABBIX Agent (UNIX, standalone daemon)................................................................72 3.4.ZABBIX Agent (UNIX, Inetd version)...........................................................................75 3.5.ZABBIX Agent (Windows)............................................................................................76
3.5.1.Installation........................................................................................................76 3.5.2.Usage..............................................................................................................77
3.6.ZABBIX Sender (UNIX).................................................................................................80 3.7.ZABBIX Get (UNIX).......................................................................................................81
4.CONFIGURATION...................................................................................................82
4.1.Development Environment..........................................................................................82 4.2.Actions..........................................................................................................................82
4.2.1.Action conditions..............................................................................................83 4.2.2.Operations.......................................................................................................86 4.2.3.Macros for messages and remote commands.................................................87
4.3.Macros...........................................................................................................................88
4.3.1.List of supported macros ................................................................................88
4.4.Applications..................................................................................................................92 4.5.Graphs...........................................................................................................................92 4.6.Medias...........................................................................................................................92
4.6.1.EMAIL..............................................................................................................92 4.6.2.JABBER...........................................................................................................92 4.6.3.SCRIPT............................................................................................................93 4.6.4.GSM Modem....................................................................................................93
4.7.Host templates..............................................................................................................93 4.8.Host groups..................................................................................................................94 4.9.Host and trigger dependencies...................................................................................94 4.10.Items............................................................................................................................95
4.10.1.Item key.........................................................................................................95 4.10.2.Supported by Platform...................................................................................95 4.10.3.ZABBIX Agent..............................................................................................101 4.10.4.SNMP Agent................................................................................................111 4.10.5.Simple checks..............................................................................................113 4.10.5.1.Timeout processing...................................................................................115 4.10.5.2.ICMP pings...............................................................................................116
4.10.6.Internal Checks............................................................................................116 4.10.7.Aggregated checks......................................................................................117 4.10.8.External checks............................................................................................118
4.11.User Parameters.......................................................................................................119
4.11.1.Simple user parameters...............................................................................119 4.11.2.Flexible user parameters.............................................................................120
4.12.Windows performance counters.............................................................................121
4.12.1.Simple user parameters...............................................................................122
4.13.Triggers.....................................................................................................................122
4.13.1.Expression for triggers ................................................................................123 4.13.2.Trigger dependencies .................................................................................130 4.13.3.Trigger severity............................................................................................131 4.13.4.Hysteresis ...................................................................................................132
4.14.Screens and Slide Shows........................................................................................132 4.15.IT Services................................................................................................................133 4.16.User permissions.....................................................................................................135
4.16.1.Overview......................................................................................................135 4.16.2.User types....................................................................................................135
4.17.The Queue.................................................................................................................135
4.17.1.Overview......................................................................................................135 4.17.2.How to read.................................................................................................136
4.18.Utilities......................................................................................................................137
4.18.1.Start-up scripts ............................................................................................137 4.18.2.snmptrap.sh ................................................................................................137
7.QUICK START GUIDE..........................................................................................139
7.1.Login............................................................................................................................139
7.1.1.Protection against brute force attacks............................................................140
7.2.Add user......................................................................................................................140 7.3.Email settings.............................................................................................................144 7.4.Add agent-enabled host.............................................................................................146 7.5.Set-up notifications....................................................................................................151
8.XML IMPORT AND EXPORT...............................................................................154
8.1.Goals...........................................................................................................................154
8.2.Overview.....................................................................................................................154 8.3.Data export..................................................................................................................154 8.4.Data import.................................................................................................................156
9.TUTORIALS..........................................................................................................158
9.1.Extending ZABBIX Agent...........................................................................................158 9.2.Monitoring of log files................................................................................................159 9.3.Remote actions...........................................................................................................159 9.4.Monitoring of Windows services..............................................................................161
10.ESCALATIONS AND REPEATED NOTIFICATIONS.........................................163
10.1.Goals.........................................................................................................................163 10.2.Overview...................................................................................................................163
11.WEB MONITORING............................................................................................164
11.1.Goals.........................................................................................................................164 11.2.Overview...................................................................................................................164 11.3.WEB Scenario...........................................................................................................164 11.4.WEB Step..................................................................................................................166 11.5.Real life scenario .....................................................................................................168
12.LOG FILE MONITORING....................................................................................172
12.1.Overview...................................................................................................................172 12.2.How it works.............................................................................................................172
13.AUTO-DISCOVERY............................................................................................173
13.1.Goals.........................................................................................................................173 13.2.Overview...................................................................................................................173 13.3.How it works.............................................................................................................174
13.3.1.Discovery.....................................................................................................174 13.3.2.Actions.........................................................................................................174
13.4.Auto-discovery rule .................................................................................................175 13.5.Real life scenario .....................................................................................................175
14.ADVANCED SNMP MONITORING.....................................................................180
14.1.Special MIBs.............................................................................................................180 14.2.Use of dynamic indexes...........................................................................................182
15.MONITORING OF IPMI DEVICES......................................................................184
15.1.Goals.........................................................................................................................184 15.2.IMPI parameters........................................................................................................184 15.3.IPMI actions..............................................................................................................184
16.USE OF PROXIES..............................................................................................185
16.1.Why use Proxy..........................................................................................................185 16.2.Proxy v.s. Node.........................................................................................................185 16.3.Configuration............................................................................................................186
17.DISTRIBUTED MONITORING............................................................................187
17.1.Goals.........................................................................................................................187 17.2.Overview ..................................................................................................................187 17.3.Configuration............................................................................................................187
17.3.1.Configuration of Nodes................................................................................187 17.3.2.Simple configuration....................................................................................189 17.3.3.More complex setup.....................................................................................194
17.4.Platform independence............................................................................................195 17.5.Configuration of a single Node...............................................................................195 17.6.Switching between nodes........................................................................................196 17.7.Data flow...................................................................................................................196
17.7.1.Child to Master.............................................................................................196 17.7.2.Master to Child.............................................................................................196 17.7.3.Firewall settings...........................................................................................197
17.8.Performance considerations...................................................................................197
18.MAINTENANCE MODE FOR ZABBIX GUI........................................................198
18.1.Goals.........................................................................................................................198 18.2.Configuration............................................................................................................198 18.3.How it looks like.......................................................................................................199
19.WEB INTERFACE...............................................................................................200
19.1.Creating your own theme........................................................................................200
19.2.Configuration............................................................................................................201
19.2.1.General........................................................................................................201 19.2.1.1.Events.......................................................................................................201 19.2.1.2.Housekeeper............................................................................................203 19.2.1.3.Images......................................................................................................204 19.2.1.4.Themes.....................................................................................................207 19.2.1.5.Value mapping..........................................................................................208 19.2.1.6.Working time.............................................................................................210 19.2.1.7.Other.........................................................................................................212
19.2.2.WEB............................................................................................................213
19.2.3.Hosts............................................................................................................217 19.2.3.1.Hosts.........................................................................................................217 19.2.3.2.Templates.................................................................................................220 19.2.3.3.Proxies......................................................................................................222 19.2.3.4.Host groups..............................................................................................224 19.2.3.5.Template linkage......................................................................................226 19.2.3.6.Applications...............................................................................................228
19.2.4.Items............................................................................................................230 19.2.4.1.Items.........................................................................................................230
19.2.5.Triggers.......................................................................................................237 19.2.5.1.Triggers....................................................................................................237
19.2.6.Actions.........................................................................................................241 19.2.6.1.Actions......................................................................................................241
19.2.7.Graphs.........................................................................................................243 19.2.7.1.Graphs......................................................................................................243
19.2.8.Screens........................................................................................................247 19.2.8.1.Screens.....................................................................................................247
19.2.9.Maps............................................................................................................251 19.2.9.1.Maps.........................................................................................................252
19.2.10.IT Services.................................................................................................258 19.2.10.1.IT Services..............................................................................................258
19.2.11.Discovery...................................................................................................261 19.2.11.1.Discovery................................................................................................261
19.2.12.Export/Import.............................................................................................263 19.2.12.1.Export.....................................................................................................263 19.2.12.2.Import......................................................................................................265
19.3.Administration..........................................................................................................267
19.3.1.Authentication..............................................................................................267 19.3.1.1.HTTP........................................................................................................267 19.3.1.2.LDAP........................................................................................................269
19.3.2.Users...........................................................................................................270 19.3.2.1.Users........................................................................................................270 19.3.2.2.User Groups.............................................................................................275
19.3.3.Media types..................................................................................................278 19.3.3.1.Media types...............................................................................................278 19.3.4.Scripts..........................................................................................................280 19.3.5.Audit.............................................................................................................282 19.3.6.Queue..........................................................................................................285 19.3.7.Notifications.................................................................................................288 19.3.8.Locales........................................................................................................289 19.3.9.Installation....................................................................................................291
20.PERFORMANCE TUNING..................................................................................292
20.1.Real world configuration ........................................................................................292 20.2.Performance tuning .................................................................................................292
20.2.1.Hardware ....................................................................................................292 20.2.2.Operating System .......................................................................................292 20.2.3.Database Engine ........................................................................................293 20.2.4.General advices ..........................................................................................293
21.COOKBOOK.......................................................................................................295
21.1.GENERAL RECIPES.................................................................................................295 21.1.1.Monitoring of server's availability.................................................................295 21.1.2.Sending alerts via WinPopUps....................................................................295
21.2.MONITORING OF SPECIFIC APPLICATIONS..........................................................295 21.2.1.AS/400.........................................................................................................295 21.2.2.MySQL.........................................................................................................295 21.2.3.Mikrotik routers............................................................................................297 21.2.4.WIN32..........................................................................................................297 21.2.5.Novell...........................................................................................................297 21.2.6.Tuxedo.........................................................................................................298 21.2.7.Informix........................................................................................................298 21.2.8.JMX..............................................................................................................298
21.3.INTEGRATION...........................................................................................................301
21.3.1.HP OpenView..............................................................................................301
22.TROUBLESHOOTING........................................................................................303
22.1.Error and warning messages..................................................................................303
23.LICENCE.............................................................................................................305
24.CONTRIBUTE.....................................................................................................313
25.CREDITS.............................................................................................................315 25.1.Developers of ZABBIX..............................................................................................315 25.2.Contributors to ZABBIX...........................................................................................315
This manual is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This manual is part of ZABBIX software. The latest version of the manual is available at http://www.zabbix.com.
The ZABBIX Reference Manual IS NOT distributed under a GPL-style license.
Use of the manual is subject to the following terms:
Please send an e-mail to sales@zabbix.com for more information.
The purpose of this document is to provide a comprehensive introduction and overview of ZABBIX, its architecture, the features it offers and their functions. This document contains all information necessary for the successful administration of ZABBIX.
No deep technical knowledge is required, although an understanding of UNIX is essential.
Anyone involved in installation and administration of ZABBIX, and anyone else wishing to get an insight into how it works.
ZABBIX SIA
Location: Neretas 2/1-109, LV-1004, Riga, Latvia Tel: +371 7743943 Fax: +371 7743944 Email: sales@zabbix.com
ZABBIX SIA, Product Manager, Director Alexei Vladishev Email: alexei.vladishev@zabbix.com
ZABBIX SIA, Sales Email: sales@zabbix.com
ZABBIX SIA, Customer Support Email: support@zabbix.com
TERM Active
Active checker
Action
Agent
Alerter
Auto-registration
Auto-discovery
Event Graphs
Host Housekeeper
IPMI DESCRIPTION
Active refers to a mode that the ZABBIX Agent can run in. When running actively, the agent keeps track of what items to send to the server and at what intervals. The agent can poll the server at set intervals in order to keep track of what items it should be sending.
Active checker gather operational information from the system where ZABBIX Agent is running, and report this data to the ZABBIX for further processing.
An action is a response taken when a Trigger has been triggered. Actions can be configured to send messages to specific user groups as defined in ZABBIX, based on their Media Type settings, or execute remote commands.
Agent refers to the program that is run on hosts that want to be monitored. It is run as a service and can process both active and passive checks simultaneously.
Alerter is a server process which is responsible for execution of actions (emails, jabber, SMS, scripts).
Auto-registration refers to a feature of ZABBIX that allows Hosts to automatically register themselves with the ZABBIX server. This is configured via the web interface by an administrator that defines a particular Hostname patter such as ‘*-Linux’ and define Items for that host based on a Template of items.
ZABBIX auto-discovery module is a module which performs automated discovery of hosts and services and generating events for further processing.
An event is when a trigger is triggered.
Graphs can refer to the simple graphs that are available for each numerical Item that is monitored, or it can refer to custom graphs which can be used to show several numerical Items in one graph.
Host refers to the machine that is being monitored.
Housekeeper refers to the service within the ZABBIX server that cleans the ZABBIX database of old actions, events, history, and trend data as defined by the user. Housekeeping of Actions and Events is defined in General settings. History and trend data is defined per item.
Intelligent Platform Management Interface.
IT Services
Item
Location Map
Master or Master Node Media Type
Node Node ID Node Watcher Queue
Passive
Pinger Poller
Proxy
IT Services refers to a feature within ZABBIX that allows users to define an SLA and have ZABBIX keep track of the expected SLA and actual SLA. IT Services are defined as groups of triggers and can be configured to calculate the minimum of a group or maximum of a group.
Item refers to an individual item that is monitored on a host, such as load average or response time. Item can refer to an item obtained via the ZABBIX agent, SNMP, or other means. Items can be configured as float, 64-bit integers, character strings, text or log values.
Environment monitored by a single Node. Map refers to a feature of ZABBIX that allows users to create customized graphics via the web interface to create network maps and define links between Hosts on the map. Links can be configured to change color or style based on Triggers.
Master Node. Master Node may have one or several Childs.
Master Node can control configuration of the Childs. Media Types are used to notify ZABBIX users when an Action has occurred. Media types can be via email or custom scripts. Media Types are configured globally to be made available to all Users, and then specified per User to allow certain Users to be notified via one media type, and other users to be notified via another media type.
ZABBIX Server in distributed setup monitoring number of
hosts. Node ID is a unique number which identifies Node. Each Node must have its own unique Node ID.
ZABBIX Server process which takes care of inter-node
communications. Queue refers to the internal queue of items the ZABBIX server is monitoring. Based on the specified intervals of items the ZABBIX server maintains a queue to keep track of the items and when it should poll them.
Passive refers to a mode that the ZABBIX Agent can run in. When running passively, the agent waits for requests for items from the server and sends them back as requested. It should be noted that typically the agent runs in both modes, and the modes are defined by the Item when it is configured.
ZABBIX Server process which processes ICMP pings.
ZABBIX Server process which is responsible for retrieval of data from ZABBIX and SNMP agents and processing remote (simple) checks.
ZABBIX Proxy process which collects performance and availability data from servers and network devices and send it to a ZABBIX Server for further processing.
ROI Screen
Sender Server
SLA
Child or Child Node Template
Timer Trapper Trigger
User
Return on Investment.
Screen refers to another customizable feature of ZABBIX which allows users to create custom pages within ZABBIX for displaying information. A screen can consist of graphs (custom), simple graphs, maps, or plain text such as the last 5 values of a particular item.
ZABBIX utility which sends data to ZABBIX Server for further processing. It usually used in user scripts.
Server refers to the program that is run on a centralized machine that has been deemed the “monitoring station”. The server is run as a service and is in charge of keeping track of all the configured hosts, items, actions, alerts, etc.
SLA refers to Service Level Agreement. These are typically used in contracts between companies and clients in order to define a certain level of service such as 99.5% availability of a particular Host.
Child Node is linked to a Master Node. Child Nodes reports to Master Node.
A Template is a Host that has a defined set of Items, Triggers, etc. which Hosts can be linked to. This allows easier configuration of hosts and changes to hosts without having to change each individual host. Host Templates are no different from other hosts except that their status is set to ‘Template’ during configuration and as such no Host is actually monitored.
ZABBIX Server process responsible for processing of date and time related functions of trigger expressions.
ZABBIX Server process responsible for processing of ZABBIX Agent (active) checks, log files and data sent by sender.
A trigger is used to define constraints on items and provide notifications when these constraints are exceeded. For example, you could be monitoring load average on a specific host and want to know when load average exceeds 1.0. Triggers are very flexible and can allow for multiple constraints.
The ZABBIX web front-end can be configured to allow access to multiple users at varying levels of access. Users can be allowed anonymous access via the guest account and be allowed to view all available data but not modify any changes, or users can be given access to only view or modify specific sections of ZABBIX.
User parameter User Parameter, (UserParameter) refers to custom scripts defined in an agent’s configuration file. User parameters are defined by a key and command. The key refers to the item defined in the web interface and can be configured to accept arguments as sent by the server.
ZABBIX ZABBIX Software
ZABBIX SIA Latvian company that develops and provides support for ZABBIX.
The following publications provide further information on technical aspects of ZABBIX.
No internal documents at the moment.
| Release | Date | Reason | Who |
|---|---|---|---|
| 13 | 10/04/2008 | Updated Release Notes | Alexei Vladishev |
| 15 | 18/09/2008 | Pre-1.6 updates. | Alexei Vladishev |
| 16 | 04/11/08 | Added: • Maintenance mode • Configuration (Hosts, WEB, Triggers, Graphs, Maps, everything) • Paremeters StartDBSyncers, BufferSend, BufferSize • creation of new themes • Key zabbix[proxy,...] | Alexei Vladishev |
| 17 | 04/11/08 | Added: • info on permission check for notifications • description of {TRIGGER.NSEVERITY} • description of last(#num) • information on of secure LDAP connections • error codes (version 1.8) • macros for system maps (version 1.8) • item data type (version 1.8.) | Alexei Vladishev |
Document conventions
The ZABBIX Manual uses the typographical conventions shown in the following table.
Format Definition
file name Name of file or directory
| Important note Shell commands Constants Note: Note | Notes, important information, strong emphasis Shell commands, paths, configuration files Constants, configuration parameters Notes, comments, additional details. |
| 1.3.Distribution list |
| Author | Changes |
| Alexei Vladishev | Author and maintainer of the Manual. |
| Charlie Collins | Significant improvements of initial (LyX) versions of the document. |
| Shawn Marriott | Proofreading of the ZABBIX Manual v1.0. |
ZABBIX was created by Alexei Vladishev, and currently is actively developed and supported by ZABBIX SIA.
ZABBIX is an enterprise-class open source distributed monitoring solution.
ZABBIX is software that monitors numerous parameters of a network and the health and integrity of servers. ZABBIX uses a flexible notification mechanism that allows users to configure e-mail based alerts for virtually any event. This allows a fast reaction to server problems. ZABBIX offers excellent reporting and data visualisation features based on the stored data. This makes ZABBIX ideal for capacity planning.
ZABBIX supports both polling and trapping. All ZABBIX reports and statistics, as well as configuration parameters, are accessed through a web-based front end. A web-based front end ensures that the status of your network and the health of your servers can be assessed from any location. Properly configured, ZABBIX can play an important role in monitoring IT infrastructure. This is equally true for small organisations with a few servers and for large companies with a multitude of servers.
ZABBIX is free of cost. ZABBIX is written and distributed under the GPL General Public License version 2. It means that its source code is freely distributed and available for the general public. Both free and commercial support is available and provided by ZABBIX Company.
ZABBIX offers:
Many organisations of different size around the World rely on ZABBIX as a primary monitoring platform.
There are several goals ZABBIX is trying to achieve:
Support of escalations and repeated notifications has been implemented. Escalations can be configured in a very flexible way and may include not only notifications but also execution of remote and IPMI commands.
ZABBIX database cache module, when enabled by the parameter StartDBSyncers, increases speed of ZABBIX up-to 4-8x times depending on the configuration.
All ZABBIX modules support both IPv4 and IPv6. ZABBIX can be used in mixed or IPv6 only environments.
ZABBIX support monitoring of IPMI parameters and manual execution of IMPI commands from ZABBIX front-end as well as remote commands.
ZABBIX distributed monitoring has been improved for a more efficient Node synchronisation protocol.
See also details on ZABBIX Proxy.
ZABBIX Proxy is a lightweight process, which collects data collection on behalf of ZABBIX Server. The proxies can be used in order to centralise monitoring of remote locations by reporting to the central server or one of ZABBIX nodes in the distributed environment.
ZABBIX Proxy simplifies deployment and maintenances of the centralised distributed monitoring significantly.
ZABBIX Dashboard provides high level personalized details about the monitored environment. Now this is a central part of ZABBIX front-end.
A screen element can be made dynamic. In this case, the information displayed in the element will depend on the particular host selected by ZABBIX user.
The Zoom period can be selected by mouse for drill-down analysis.
Pie charts (both 2D and 3D) are supported.
Traceroute and Ping can be executed from a number of screens. More scripts can be added and configured.
The scripts are executed on the single ZABBIX server or any ZABBIX node in the distributed setup.
ZABBIX Agents support data buffering, which can be tuned by new configuration parameters, BufferSize and BufferSend.
The communication protocol has been improved to support sending of multiple values by one TCP connection.
ZABBIX Sender has been improved to support sending of multiple values by one network connection.
1.6.14.Improved View of Trigger Statuses
The screen will display information about triggers and associated events.
A new syntax can be used to monitor SNMP data with a dynamic index. See SNMP section for more details.
1.6.16.Special Processing of Well-known SNMP OIDs
Simple SNMP OIDs, like ifDescr, ifInOctets, ifInOctets, and other can be used in ZABBIX and will be translated automatically into correct numeric representation by ZABBIX itself.
Any screen can be printed in a nice way by pressing the “Print” link.
An entire user group can be configured not to have access to ZABBIX front-end.
ZABBIX front-end is UTF-8 ready. Note that ZABBIX database and ZABBIX server and agent processes still are not ready for correct processing of UTF-8 data.
The screen can be used to add new translations of ZABBIX front-end.
ZABBIX maintenance mode can be activated to disable ZABBIX front-end temporarily.
Any number of triggers can be linked to the map link. The style of the triggers will define how the link is displayed.
1.6.23.Improved User Permission Schema
In 1.6 user permissions slightly differ from the permissions in 1.4.
1.6.24.Other Improvements
1.6.24.1.Queue moved into Administration
Now the information is available to ZABBIX Super Administrators only.
1.6.24.2.Link to Maps, Screens and Graphs moved to the Dashboard
The main menu was simplified. Now Maps, Screens and Graphs can be accessed from the Dashboard.
The user profile option makes possible automatic login to ZABBIX front-end within one month.
New more efficient communication protocol makes possible sending of multiple values by one TCP connection.
New frond-end includes two themes by default. More themes can be added.
In this case, user authorization is required for access to the ZABBIX front-end.
A group of users can be disabled.
Nice screen will appear in case if ZABBIX front-end is unable to talk to the database.
1.6.24.9.Duplicated Login removed
The Login menu item has been removed to avoid confusion.
1.6.24.10.Added sorting for all screens
Most of tables in ZABBIX front-end can be sorted by selected column.
Information message has different colours depending on status. It may also contain more details, which are hidden by default.
1.6.24.12.Support of import/export of the host template linkage information
XML import/export respects host template linkage information.
Graphs support displaying of negative values.
Parameter Include can be used to include all files in a directory.
Add new macros, which can be useful for notifications: {EVENT.DATE}, {EVENT.TIME}, {EVENT.AGE}, {ESC.HISTORY}
Welcome message is not confusing any more.
Auto-discovery supports discovery by ICMP ping.
By default ZABBIX will send no more than 100 of lines per second per each log file.
Some of host and trigger attributes can be mass-updated.
Most of screens support full-screen mode, which is controlled by the full-screen icon.
Active-only mode can be enabled for agents. In this case, the agent will not listen for incoming connections, which may be important for security.
1.6.24.22.Added monitoring of Proxy availability
Availability of proxies can be monitored automatically using new internal checks.
ZABBIX front-end is protected from brute force attacks.
Every single event provides detailed information about executed commands and notifications.
Refresh rate for ICMP pings can be controlled individually for each item.
Multiple events can be acknowledged by a single click thanks to bulk-acknowledgement.
Availability report support selection of time period.
History of actions and remote command moved to Administration->Audit.
The value is a good indicator of performance of ZABBIX and can be used for hardware requirements.
Optional one month auto-login is supported on user level.
1.6.24.31.Automatic selection of the first element in drop-downs
The first element of all drop-down controls will be selected by default.
1.6.24.32.Last access time is displayed for users
Last access time is available for users.
Status of Triggers screen provide information about triggers and corresponding events.
Extended host profiles can be optionally used.
See the INSTALLATION section for full details.
Older agents from ZABBIX 1.0, ZABBIX 1.1.x and ZABBIX 1.4.x can be used with ZABBIX 1.6. It does not require any configuration changes on agent side.
User permission schema has been changed. Now ZABBIX Administrators do not have write access to all hosts by default.
ZABBIX 1.6 does not allow empty user passwords. All empty passwords are replaced by 'zabbix' after database upgrade! User 'guest' is the only exception.
The following steps have to be performed for successful upgrade from ZABBIX
1.4.x to 1.6.
The whole upgrade procedure may take several hours depending on size of ZABBIX database.
1.7.4.1.Stop ZABBIX server
Stop ZABBIX server to make sure that no new data are coming to database.
This is very important step. Make sure that you have backup of your database. It will help if upgrade procedure fails (lack of disk space, power off, any unexpected problem).
1.7.4.3.Backup configuration files, PHP files and ZABBIX binaries
Make a backup copy of ZABBIX binaries, configuration files and PHP files.
You may use pre-compiled binaries or compile your own.
Some parameters of zabbix_server.conf were changed in 1.6, new parameters added. You may want to review them.
Database upgrade scripts are located in directory upgrades/dbpatches/1.6/<db engine>:
MySQL: upgrades/dbpatches/1.6/mysql/patch.sql Oracle: upgrades/dbpatches/1.6/oracle/patch.sql PostgreSQL: upgrades/dbpatches/1.6/postgresql/patch.sql
Note: Database upgrade may take quite significant time, several hours or more. It is recommended to test the upgrade procedure in a non-production environment.
Make sure that you have enough permissions (create table, drop table, create index, drop index). Also make sure that you have enough free disk space.
Note: These scripts are for upgrade from ZABBIX 1.4.x to 1.6 only!
Follow Installation Instructions.
Start new binaries. Check log files to see if the binaries are started successfully.
ZABBIX SIA offers a full range of support options to meet your specific needs.
ZABBIX Support Services provide direct access to our expert Support Engineers who are ready to assist you in the development, deployment, and management of ZABBIX.
Visit http://www.zabbix.com/services.php or contact sales@zabbix.com for more details.
Check the ZABBIX Home Page at http://www.zabbix.com for information about the current version and for downloading instructions.
ZABBIX requires both physical and disk memory. 128 MB of physical memory and 256 MB of free disk space could be a good starting point. However, the amount of required disk memory obviously depends on the number of hosts and parameters that are being monitored. If you're planning to keep a long history of monitored parameters, you should be thinking of at least a couple of gigabytes to have enough space to store the history in the database.
Each ZABBIX daemon process requires several connections to a database server. Amount of memory allocated for the connection depends on configuration of the database engine.
Note: The more physical memory you have, the faster the database (and therefore ZABBIX) works!
ZABBIX and especially ZABBIX database may require significant CPU resources depending on number of monitored parameters and chosen database engine.
A serial communication port and a serial GSM Modem required for using SMS notifications built-in ZABBIX.
The table provides several hardware configurations:
hosts Small
Ubuntu
PII 350MHz
MySQL MyISAM 20
Linux 256MB
Ubuntu
AMD Athlon
MySQL InnoDB 500
Medium
Linux 64 bit 3200+ 2GB
Ubuntu
Intel Dual
MySQL InnoDB >1000
Large
Linux 64 bit
Core 6400
or
4GB PostgreSQL
RAID10
RedHat
Intel Xeon
MySQL InnoDB >10000
Very large
Enterprise 2xCPU
or 8GB
PostgreSQL Fast RAID10
Note: Actual configuration depends on number of active items and refresh rates very much. It is highly recommended to run the database on a separate box for large installations.
Due to security requirements and mission-critical nature of monitoring server, UNIX is the only operating system that can consistently deliver the necessary performance, fault tolerance and resilience. ZABBIX operates on market leading versions.
ZABBIX is tested on the following platforms:
Note: ZABBIX may work on other Unix-like operating systems as well.
ZABBIX is built around modern Apache WEB server, leading database engines, and the PHP scripting language.
The following software is required to run ZABBIX:
| Software | Version | Comments |
|---|---|---|
| Apache | 1.3.12 or later | |
| PHP | 4.3 or later | |
| PHP modules: php-gd php-bcmath | 4.3 or later | PHP GD module must support PNG images. |
| MySQL php-mysql | 3.22 or later | Required if MySQL is used as ZABBIX back end database. |
| Oracle php-sqlora8 | 9.2.0.4 or later | Required if Oracle is used as ZABBIX back-end database. |
| PostgreSQL php-pgsql | 7.0.2 or later | Required if PostgreSQL is used as ZABBIX back-end database. Consider using PostgreSQL 8.x or later for much better performance. |
| SQLite php-sqlite3 | 3.3.5 or later | Required if SQLite is used as ZABBIX back-end database. |
Note: ZABBIX may work on previous versions of Apache, MySQL, Oracle, and PostgreSQL as well.
WEB browser on client side
Support for HTML and PNG images required. MS Explorer (5.xx and 6.xx) and Mozilla 1.x work perfectly. Cookies and Java Script must be enabled. Other browsers may work with ZABBIX as well.
ZABBIX Server and Proxy support four database engines:
The table can be used as a general recommendation on choice of database engine.
| Database engine of choice | Usage |
| MySQL InnoDB | Heavy duty Node/Standalone Server Heavy duty Proxy |
| MySQL MyISAM | Light duty Node/Standalone Light duty Proxy |
| PostgreSQL | Heavy duty Node/Standalone Server Heavy duty Proxy |
| Oracle | Heavy duty Node/Standalone Server |
| SQLite | Light duty Proxy |
ZABBIX configuration data requires fixed amount of disk space and does not grow much.
ZABBIX database size mainly depends on these variables, which define amount of stored historical data:
• Number of processed values per second This is average number of new values ZABBIX server receives every second. For example, if we have 3000 items for monitoring with refresh rate of 60 seconds, number of values per seconds is calculated as 3000/60 = 50.
It means that 50 new values are added to ZABBIX database every second.
• Housekeeper settings for history
ZABBIX keeps values for a fixed period of time, normally several weeks or months. Each new value required certain amount of disk space for data and index.
So, if we would like to keep 30 days of history and we receive 50 values per second, total number of values will be around (30*24*3600)*50 = 129.600.000, or about 130M of values.
Depending on used database engine, type of received values (floats, integers, strings, log files, etc), disk space for keeping a single value may vary from 40 bytes to hundreds of bytes. Normally it is around 50 bytes per value.
In our case, it means that 130M of values will require 130M * 50 bytes = 6.5GB of disk space.
• Housekeeper setting for trends
ZABBIX keeps 1 hour max/min/avg/count statistics for each item in table trends. The data is used for trending and long period graphs.
ZABBIX database, depending on database type, requires about 128 bytes per each total.
Suppose we would like to keep trend data for 5 years. 3000 values will require (3000/1800)*(24*3600*365)*128 = 6.3GB per year, or 31.5GB for 5 years.
• Housekeeper settings for events
Each ZABBIX event requires approximately 130 bytes of disk space. It is hard number of events generated by ZABBIX daily. In worst case scenario, we may assume that ZABBIX generates one event per second.
It means that if we want to keep 3 years of events, this would require 3*365*24*3600*130 = 11GB
The table contains formulas that can be used to calculate disk space required for ZABBIX system:
| Parameter | Formula for required disk space (in bytes) |
| ZABBIX configuration | Fixed size. Normally 10MB or less. |
| History | days*(items/refresh rate)*24*3600*bytes items: number of items days: number of days to keep history refresh rate: average refresh rate of items |
bytes: number of bytes required to keep single value, depends on database engine, normally 50 bytes.
days*(items/1800)*24*3600*bytes items: number of items days: number of days to keep history bytes: number of bytes required to keep
single trend, depends on database engine, normally 128 bytes.
Trends
days*events*24*3600*bytes
events: number of event per second. One (1) event per second in worst case scenario.
days: number of days to keep history
bytes: number of bytes required to keep single trend, depends on database engine, normally 130 bytes.
Events
So, the total required disk space can be calculated as:
Configuration + History + Trends + Events
The disk space will NOT be used immediately after ZABBIX installation. Database size will grow then it will stop growing at some point, which depends on hosekeeper settings.
Note: Disk space requirements for nodes in distributed setup are calculated in a similar way, but this also depends on a total number of child nodes linked to a node.
It is very important to have precise system date on server with ZABBIX running. timed is one of most popular daemons that synchronizes the host’s time with the time of other machines.
ZABBIX consists of several major software components, the responsibilities of which are outlined below.
This is the centre of the ZABBIX software. The Server can remotely check networked services (such as web servers and mail servers) using simple service checks, but it is also the central component to which the Agents will report availability and integrity information and statistics. The Server is the central repository in which all configuration, statistical and operational data are stored, and it is the entity in the ZABBIX software that will actively alert administrators when problems arise in any of the monitored systems.
ZABBIX can also perform agent-less monitoring and also monitor network devices using SNMP agents.
The Proxy is an optional part of ZABBIX deployment. The Proxy collects performance and availability data on behalf of ZABBIX Server. All collected data is buffered locally and transferred to ZABBIX Server the Proxy belongs to.
ZABBIX Proxy is an ideal solution for a centralized monitoring of remote locations, branches, networks having no local administrators.
ZABBIX Proxies can also be used to distribute load of a single ZABBIX Server. In this case, only Proxies collect data thus making processing on the Server less CPU and disk I/O hungry.
In order to actively monitor local resources and applications (such as harddrives, memory, processor statistics etc.) on networked systems, those systems must run the ZABBIX Agent. The Agent will gather operational information from the system on which it is running, and report these data to the ZABBIX for further processing. In case of failures (such as a harddisk running full, or a crashed service process), the ZABBIX Server can actively alert the administrators of the particular machine that reported the failure.
The ZABBIX Agents are extremely efficient because of use of native system calls for gathering statistical information.
In order to allow easy access to the monitoring data and then configuration of ZABBIX from anywhere and from any platform, the Web-based Interface is provided. The Interface is a part of the ZABBIX Server, and is usually (but not necessarily) run on the same physical machine as the one running the ZABBIX Server.
Note: ZABBIX front-end must run on the same physical machine if SQLite is used.
Building of ZABBIX server or agents from sources requires additional software. The following software is required to compile ZABBIX:
One of the following database engines: MySQL Headers and Libraries
Version 3.22 or later required.
Oracle Headers and Libraries
Sqlora8 headers and libraries are required.
PostgreSQL Headers and Libraries
Version 7.0.2 or later required. Consider using PostgreSQL 8.x for much better performance.
SQLite Headers and Libraries
Version 3.3.5 or later required.
Note: Usually provided as part of mysql-dev, postgresql-dev, sqlite3-dev packages.
NET-SNMP (or UCD-SNMP) library and header files
Required for SNMP support. Optional.
Iksemel library and header files
Required to enable Jabber messaging. Optional.
Libcurl library and header files
Version 7.13.1 or higher required for WEB monitoring module. Optional.
C Compiler
C compiler is required. GNU C compiler is the best choice for open platforms. Other (HP, IBM) C compilers may be used as well.
GNU Make
GNU make is required to process ZABBIX Makefiles.
docs
The directory contains this Manual in PDF format
src The directory contains sources for all ZABBIX processes except frontends.
src/zabbix_server
The directory contains Makefile and sources for zabbix_server.
src/zabbix_agent
The directory contains Makefile and sources for zabbix_agent and zabbix_agentd.
src/zabbix_get
The directory contains Makefile and sources for zabbix_get.
src/zabbix_sender
The directory contains Makefile and sources for zabbix_sender.
include
The directory contains include ZABBIX files.
misc misc/init.d
The directory contains start-up scripts for different platforms.
frontends frontends/php
The directory contains files of PHP frontend.
create
The directory contains SQL script for initial database creation.
create/schema
Database creation schemas.
create/data
Data for initial database creation.
upgrades
The directory contains upgrade procedures for different versions of ZABBIX.
2.4.3.ZABBIX Server
Server side
Create the ZABBIX superuser account
This is the user the server will run as. For production use you should create a dedicated unprivileged account ('zabbix' is commonly used). Running ZABBIX as 'root','bin', or any other account with special rights is a security risk. Do not do it!
Note: ZABBIX server process (zabbix_server) is protected from being run under root account.
Untar ZABBIX sources
shell> gunzip zabbix-1.6.tar.gz && tar -xvf zabbix-1.6.tar
Create the ZABBIX database
ZABBIX comes with SQL scripts used to create the required database schema and also to insert a default configuration. There are separate scripts for MySQL, Oracle, PostgreSQL and SQLite.
For MySQL:
shell> mysql -u<username> -p<password>
mysql> create database zabbix;
mysql> quit;
shell> cd create/schema
shell> cat mysql.sql | mysql -u<username> -p<password> zabbix
shell> cd ../data
shell> cat data.sql | mysql -u<username> -p<password> zabbix
shell> cat images_mysql.sql | mysql -u<username> -p<password> zabbix
For Oracle (we assume that user ‘zabbix’ with password ‘password’ exists and has permissions to create database objects):
shell> cd create
shell> sqlplus zabbix/password
sqlplus> set def off
sqlplus> @schema/oracle.sql
sqlplus> @data/data.sql
sqlplus> @data/images_oracle.sql
sqlplus> exit
For PostgreSQL: shell> psql -U <username> psql> create database zabbix; psql> \q shell> cd create/schema shell> cat postgresql.sql | psql -U <username> zabbix shell> cd ../data shell> cat data.sql | psql -U <username> zabbix shell> cat images_pgsql.sql | psql -U <username> zabbix
For SQLite:
shell> cd create/schema shell> cat sqlite.sql | sqlite3 /var/lib/sqlite/zabbix.db shell> cd ../data shell> cat data.sql | sqlite3 /var/lib/sqlite/zabbix.db shell> cat images_sqlite3.sql | sqlite3 /var/lib/sqlite/zabbix.db
Note: The database will be automatically created if it does not exist.
Configure and compile the source code for your system
The sources must be compiled for both the server (monitoring machine) as well as the clients (monitored machines). To configure the source for the server, you must specify which database will be used.
shell> ./configure --enable-server --with-mysql --with-net-snmp –with-jabber – with-libcurl # for MySQL + Jabber + WEB monitoring
or
shell> ./configure --enable-server --with-pgsql --with-net-snmp –with-jabber – with-libcurl # for PostgreSQL + Jabber + WEB monitoring
or shell> ./configure --enable-server --with-oracle=/home/zabbix/sqlora8 --with-netsnmp –with-jabber –with-libcurl # for Oracle + Jabber + WEB monitoring
Note: Use flag --with-oracle to specify location of sqlora8 library. The libary is required for Oracle support. The library can be found at libsqlora8 homepage
Note: Use flag --enable-static to statically link libraries. If you plan to distribute compiled binaries among different servers, you must use this flag to make these binaries work without required libraries. --enable-static does not work under Solaris. Flag --with-ucd-snmp can be used instead of --with-net-snmp. If no SNMP support required, both --with-net-snmp and --with-ucd-snmp may be skipped.
However, if you want to compile client binaries along with server binaries, run:
shell> ./configure --enable-server --enable-agent --with-mysql --with-net-snmp – with-jabber –with-libcurl
Parameter —enable-static may be used to force static linkage.
Make and install everything
shell> make install
By default,
make install
will install all the files in /usr/local/bin, /usr/local/lib etc. You can specify an installation prefix other than /usr/local using --prefix
Configure /etc/services
The step is not real requirement. However, it is recommended. On the client (monitored) machines, add the following lines to /etc/services:
zabbix-agent 10050/tcp Zabbix Agent zabbix-agent 10050/udp Zabbix Agent zabbix-trapper 10051/tcp Zabbix Trapper zabbix-trapper 10051/udp Zabbix Trapper
Configure /etc/inetd.conf
If you plan to use zabbix_agent instead of the recommended zabbix_agentd, the following line must be added:
zabbix_agent stream tcp nowait.3600 zabbix /opt/zabbix/bin/zabbix_agent
Restart inetd
shell> killall -HUP inetd
Modify default settings in configuration files
Configure /etc/zabbix/zabbix_agent.conf
You need to configure this file for every host having zabbix_agent installed. The file should contain IP address of ZABBIX server. Connections from other hosts will be denied. You may take misc/conf/zabbix_agent.conf as example.
Configure /etc/zabbix/zabbix_agentd.conf
You need to configure this file for every host with zabbix_agentd installed. The file should contain the IP address of the ZABBIX server. Connections from other hosts will be denied. You may take misc/conf/zabbix_agentd.conf as example.
Step Configure /etc/zabbix/zabbix_server.conf 10
For small installations (up to ten monitored hosts), default parameters are sufficient. However, you should change default parameters to maximize performance of ZABBIX. See section [Performance tuning] for more details.
You may take misc/conf/zabbix_server.conf as example.
Step Run server processes 11
Run zabbix_server on server side.
shell> cd bin shell> ./zabbix_server
Step Run agents 12
Run zabbix_agentd where necessary.
shell> cd bin shell> ./zabbix_agentd
ZABBIX Proxy is a special process. It is not required to run the process.
Create the ZABBIX superuser account
This is the user the Proxy will run as. For production use you should create a dedicated unprivileged account ('zabbix' is commonly used). Running ZABBIX Proxy as 'root','bin', or any other account with special rights is a security risk. Do not do it!
Note: ZABBIX Proxy process (zabbix_proxy) is protected from being run under root account.
Untar ZABBIX sources
shell> gunzip zabbix-1.6.tar.gz && tar -xvf zabbix-1.6.tar
Create the ZABBIX database. Optional.
Note: ZABBIX Proxy process will create database automatically on the first run if it does not exist. It will use existing database otherwise. Database auto-creation is supported by SQLite only.
ZABBIX comes with SQL scripts used to create the required database schema. There are separate scripts for MySQL, Oracle, PostgreSQL and SQLite.
For MySQL:
shell> mysql -u<username> -p<password>
mysql> create database zabbix;
mysql> quit;
shell> cd create/schema
shell> cat mysql.sql | mysql -u<username> -p<password> zabbix
shell> cd ../data
shell> cat data.sql | mysql -u<username> -p<password> zabbix
shell> cat images_mysql.sql | mysql -u<username> -p<password> zabbix
For Oracle (we assume that user ‘zabbix’ with password ‘password’ exists and has permissions to create database objects):
shell> cd create/schema
shell> cat oracle.sql | sqlplus zabbix/password >out.log
Note: Check file out.log for any error messages.
shell> cd ../data shell> cat data.sql | sqlplus zabbix/password >out.log shell> cat images_oracle.sql | sqlplus zabbix/password >>out.log
For PostgreSQL:
shell> psql -U <username> psql> create database zabbix; psql> \q shell> cd create/schema shell> cat postgresql.sql | psql -U <username> zabbix shell> cd ../data
shell> cat data.sql | psql -U <username> zabbix shell> cat images_pgsql.sql | psql -U <username> zabbix
For SQLite:
shell> cd create/schema shell> cat sqlite.sql | sqlite3 /var/lib/sqlite/zabbix.db shell> cd ../data shell> cat data.sql | sqlite3 /var/lib/sqlite/zabbix.db shell> cat images_sqlite3.sql | sqlite3 /var/lib/sqlite/zabbix.db
Note: The database will be automatically created if it does not exist.
Configure and compile the source code for your system
The sources must be compiled to enable compilation of ZABBIX Proxy process. To configure the source for the Proxy, you must specify which database will be used.
shell> ./configure --enable-proxy --with-mysql --with-net-snmp –with-libcurl # for MySQL + WEB monitoring
or
shell> ./configure --enable-proxy --with-pgsql --with-net-snmp –with-libcurl # for PostgreSQL + WEB monitoring
or
shell> ./configure --enable-proxy --with-oracle=/home/zabbix/sqlora8 --with-netsnmp –with-libcurl # for Oracle + WEB monitoring
Note: Use flag --with-oracle to specify location of sqlora8 library. The libary is required for Oracle support. The library can be found at libsqlora8 homepage
Note: Use flag --enable-static to statically link libraries. If you plan to distribute compiled binaries among different hosts, you must use this flag to make these binaries work without required libraries. --enable-static does not work under Solaris. Flag --with-ucd-snmp can be used instead of --with-net-snmp. If no SNMP support required, both --with-net-snmp and --with-ucd-snmp may be skipped.
However, if you want to compile client binaries along with proxy binaries, run:
shell> ./configure --enable-proxy --enable-agent --with-mysql –with-net-snmp – with-libcurl
Parameter —enable-static may be used to force static linkage. Make and install everything shell> make install
By default,
make install
will install all the files in /usr/local/bin, /usr/local/lib etc. You can specify an installation prefix other than /usr/local using --prefix
Configure /etc/services The step is not real requirement. However, it is recommended. On the client (monitored) machines, add the following lines to /etc/services:
zabbix_agent 10050/tcp zabbix_trap 10051/tcp Configure /etc/inetd.conf If you plan to use zabbix_agent instead of the recommended zabbix_agentd, the following line must be added:
zabbix_agent stream tcp nowait.3600 zabbix /opt/zabbix/bin/zabbix_agent Restart inetd
shell> killall -HUP inetd
Modify default settings in configuration files
Configure /etc/zabbix/zabbix_proxy.conf
For small installations (up to ten monitored hosts), default parameters are sufficient. However, you should change default parameters to maximize performance of ZABBIX Proxy.
Make sure you have correct Hostname and Server parameters set. You may take misc/conf/zabbix_proxy.conf as example.
Run Proxy processes
Run zabbix_proxy:
shell> cd sbin shell> ./zabbix_proxy
Client side
Create the ZABBIX account
This is the user the agent will run as. For production use you should create a dedicated unprivileged account (“zabbix” is commonly used). ZABBIX agents have protection against running under root account.
Untar ZABBIX sources
shell> gunzip zabbix-1.6.tar.gz && tar xvf zabbix-1.6.tar
Configure and compile the source code for your system
The sources must be compiled for the client only.
To configure the source for the client:
shell> ./configure --enable-agent
Note: Use flag --enable-static to statically link libraries. If you plan to distribute compiled binaries among different hosts, you must use this flag to make these binaries work without required libraries.
Build agent
shell> make
Copy created binaries from bin/ to /opt/zabbix/bin or any other directory Other common directories are /usr/local/bin or /usr/local/zabbix/bin. Configure /etc/services The step is not real requirement. However, it is recommended. On the client (monitored) machines, add the following lines to /etc/services: zabbix_agent 10050/tcp zabbix_trap 10051/tcp
Configure /etc/inetd.conf If you plan to use zabbix_agent instead of the recommended zabbix_agentd, the following line must be added:
zabbix_agent stream tcp nowait.3600 zabbix /opt/zabbix/bin/zabbix_agent Restart inetd
shell> killall -HUP inetd
Configure /etc/zabbix/zabbix_agent.conf You need to configure this file for every host having zabbix_agent installed. The
file should contain IP address of ZABBIX server. Connections from other hosts will be denied. Note, that no end of line character should present in the file. You may take misc/conf/zabbix_agent.conf as example.
Configure /etc/zabbix/zabbix_agentd.conf You need to configure this file for every host with zabbix_agentd installed. The file should contain IP address of ZABBIX server. Connections from other hosts will be denied. You may take misc/conf/zabbix_agentd.conf as example. Run zabbix_agentd on all monitored machines
shell> /opt/zabbix/bin/zabbix_agentd
Note: You should not run zabbix_agentd if you have chosen to use zabbix_agent!
Note: Make sure that your system allows allocation of 2MB of shared memory, otherwise the agent may not start and you will see “Can't allocate shared memory for collector.” in agent’s log file. This may happen on Solaris 8.
Point your browser to ZABBIX URL.
Read and accept GPL v2.
Make sure that all software pre-requisites are met.
| Pre-requisite | Minimum value | Description |
|---|---|---|
| PHP version | 4.3.0 | |
| PHP Memory limit | 8MB | In php.ini: memory_limit = 128M |
| PHP post max size | 8MB | In php.ini: post_max_size = 8M |
| PHP max execution time | 300 seconds | In php.ini: max_execution_time = 300 |
| PHP database support | One of: MySQL, Oracle, PostgreSQL, SQLite | One of the following modules must be installed: php-mysql, php-sqlora8, phppgsql, php-sqlite3 |
| PHP BC math | Any | Compiled in PHP5. |
| GD Version | 2.0 or higher | Module php-gd. |
| Image formats | At least PNG | Module php-gd. |
Step 4 Configure database settings. ZABBIX database must already be created.
Enter ZABBIX Server details.
See summary of settings.
Download configuration file and place it under conf/.
Finishing installation.
For distributed monitoring only!
If used in a distributed environment you have to run:
shell> ./zabbix_server –n <nodeid>
where Node ID is an unique Node identificator. For example:
shell> ./zabbix_server –n 1
This will convert database data for use with Node ID ‘1’ and also adds a local node.
Step 10 ZABBIX frontend is ready! Default user name is ‘Admin’, password 'zabbix'.
The upgrade procedure is quite simple. New binaries and frontend should be installed according to latest installation instructions. In order to update database structure, the following steps should be performed.
The upgrade process can take from 0 seconds (if no patches required) to several hours. Note that before applying database patches, all ZABBIX processes must be stopped.
Database upgrade is usually required for upgrade from one major stable release to another. For example, from 1.4.x to 1.6.x.
For production installations a database backup is required!
Go to the upgrades/dbpatches directory. In this directory are subdirectories named according to a version upgrade (e.g. 1.0beta3_to_1.0beta4). Enter the directory corresponding to your upgrade (if you are upgrading through multiple versions, you will need to apply the upgrades one at a time). Depending on which database you use:
shell> cd mysql; cat patch.sql |mysql zabbix -u<username> -p<password>
or
shell> cd postgresql; cat patch.sql|psql -U <username> zabbix
Do not forget to upgrade PHP front-end files.
Finally, read version specific notes below for any extra procedures and useful information.
ZABBIX Server is a central process of ZABBIX software. ZABBIX Server can be started by executing:
shell> cd bin shell> ./zabbix_server
ZABBIX Server runs as a daemon process. ZABBIX Server accepts the following command line parameters:
-c --config <file> specify configuration file, default is
/etc/zabbix/zabbix_server.conf -h --help give this help -v --version display version number
In order to get this help run:
shell> zabbix_server -h
Example of command line parameters:
shell> zabbix_server –c /usr/local/etc/zabbix_server.conf shell> zabbix_server --help shell> zabbix_server -v
The configuration file contains parameters for zabbix_server. The file must exist and it should have read permissions for user ‘zabbix’. Supported parameters:
| Parameter | Mandatory | Default value | Description |
|---|---|---|---|
| AlertScriptsPath | No | /home/zabbix/bin | Location of scripts for user-defined media types. |
| DBHost | Yes | - | Database name. Usually ‘zabbix’. |
| Parameter | Mandatory | Default value | Description | |
|---|---|---|---|---|
| DBName | Yes | - | Database name. Usually ‘zabbix’. | |
| DBSocket | No | - | DB socket name. Used for non-TCP connection to MySQL database. Example: /tmp/mysql.sock | |
| DBPassword | No | NULL | Database password. If password is not used, then this parameter must be commented. | |
| DBUser | No | NULL | User name for connecting to the database. | |
| DebugLevel | No | 3 | Debug level, one of 0 – none 1 – critical 2 – errors 3 – warnings 4 – debug | |
| DisableHouseke eping | No | 0 | If set to 1, housekeeper will be disabled. | |
| ExternalScripts | No | / etc/zabbix/extern alscripts | Location of scripts for external checks. | |
| FpingLocation | No | /usr/sbin/fping | Location of ICMP pinger. It must have setuid flag set. | |
| HousekkepingFr equency | No | 1 | The parameter defines how often the daemon must perform housekeeping procedure (in hours). If PostgreSQL is used set the value to 24 as it will perform command VACUUM. | |
| Include | No | - | Use this parameter to include a file into the configuration file. Number of parameters Include is not limited. For example: Include=/etc/zabbix/db_conn. conf | |
| ListenIP | No | - | Interface to listen by trapper processes. Trapper will listen |
| Parameter | Mandatory | Default value | Description | |
|---|---|---|---|---|
| to all interfaces if this parameter is not set. | ||||
| ListenPort | No | 10051 | Port number to listen by trapper processes. | |
| LogFile | No | - | Name of log file. If not set, syslog is used. | |
| LogFileSize | No | 1 | This parameter controls log rotation setting for LogFile. By default, ZABBIX automatically roatates log file when it reaches 1MB. This parameter is in MB. If set to 0, no log rotation will be performed. | |
| NodeID | No | 0 | Unique NodeID (0-999). Must be ‘0’ or missing for standalone ZABBIX Server. | |
| NodeNoEvents | No | 0 | If set to ‘1’ local events won’t be sent to master node. | |
| NodeNoHistory | No | 0 | If set to ‘1’ local history won’t be sent to master node. | |
| PidFile | No | / tmp/zabbix_serv er.pid | Name of file to store PID | |
| PingerFrequenc y | No | 30 | ZABBIX server ping servers once per PingerFrequency seconds (1-3600). | |
| SenderFrequenc y | No | 30 | The parameter defines how often the daemon must try to send alerts (in seconds) | |
| SourceIP | No | - | Set source IP address for all connections established by the process. | |
| StartDBSyncers | No | 0 | Enable database cache: 0 – Disabled 1 – Enabled | |
| StartDiscoverers | No | 1 | Number of discoverers to start (0-255). | |
| StartHTTPPoller s | No | 5 | Number of HTTP pollers to start (0-255). | |
| StartPollers | No | 5 | Number of pollers to start (0 |
| Parameter | Mandatory | Default value | Description | |
|---|---|---|---|---|
| 255). | ||||
| StartPollersUnre achable | No | 1 | Number of pollers for unreachable hosts to start (0255). | |
| StartTrappers | No | 5 | Number of trappers to start (0-255) | |
| Timeout | No | 5 | Do not spend more than Timeout seconds on retrieving requested value (130) Note: Example of the configuration file can be found at misc/conf/zabbix_server.conf | |
| TrapperTimeout | No | 5 | Do not spend more than Timeout seconds on | |
| processing of traps (1-255) | ||||
| UnavailableDela y | No | 60 | How ofter try to connect to unavailable host | |
| UnreachableDel ay | No | 15 | How often try to connect to unreachable host | |
| UnreachablePeri od | No | 45 | If a host was unreachable for more than UnreachablePeriod seconds, change host status to Unavailable |
ZABBIX Proxy is a process which collects performance and availability data from one or more monitored devices and sends the information to a ZABBIX Server. ZABBIX Proxy can be started by:
shell> cd sbin shell> ./zabbix_proxy
ZABBIX Proxy runs as a daemon process. ZABBIX Proxy accepts the following command line parameters:
-c --config <file> specify configuration file, default is
/etc/zabbix/zabbix_proxy.conf -h –help give this help -v --version display version number
In order to get this help run:
shell> zabbix_proxy -h
Example of command line parameters:
shell> zabbix_proxy –c /usr/local/etc/zabbix_proxy.conf shell> zabbix_proxy --help shell> zabbix_proxy -v
The configuration file contains parameters for zabbix_proxy. The file must exist and it should have read permissions for user ‘zabbix’. Supported parameters:
| Parameter | Mandatory | Default value | Description |
|---|---|---|---|
| ConfigFrequenc y | No | 3600 (1 hour) | How often proxy refreshes configuration data in seconds. |
| DataSenderFreq uency | No | 10 | Proxy will send collected data every N seconds. Possible values 1-3600 seconds. |
| DBHost | Yes | - | Database name. Usually ‘zabbix’. |
| DBName | Yes | - | Database name. Usually ‘zabbix’. |
| DBSocket | No | - | DB socket name. Used for non-TCP connection to MySQL database. Example: /tmp/mysql.sock |
| DebugLevel | No | 3 | Debug level, one of 0 – none 1 – critical 2 – errors 3 – warnings 4 – debug |
| Parameter | Mandatory | Default value | Description | |
|---|---|---|---|---|
| FpingLocation | No | /usr/sbin/fping | Location of ICMP pinger. It must have setuid flag set. | |
| Fping6Location | No | /usr/sbin/fping6 | Location of ICMP pinger for TCP6. It must have setuid flag set. | |
| Hostname | Yes | - | Unique proxy name. The name is used to identify proxy on server side. | |
| HeartbeatFreque ncy | No | 60 | Frequency of heartbeat messages in seconds. If set to 0, heartbeat messages will be disabled. | |
| HousekeepingFr equency | No | 1 | The parameter defines how often the daemon must perform housekeeping procedure (in hours). If PostgreSQL is used set the value to 24 as it will perform command VACUUM. | |
| ListenIP | No | - | Interface to listen by trapper processes. Trapper will listen to all interfaces if this parameter is not set. | |
| ListenPort | No | 10051 | Port number to listen by trapper processes. | |
| LogFile | No | - | Name of log file. If not set, syslog is used. | |
| LogFileSize | No | 1 | This parameter controls log rotation setting for LogFile. By default, ZABBIX automatically roatates log file when it reaches 1MB. This parameter is in MB. If set to 0, no log rotation will be performed. | |
| PidFile | No | / tmp/zabbix_serv er.pid | Name of file to store PID | |
| ProxyLocalBuffe r | No | 0 | Proxy will keep data locally for N hours. This parameter may be used if local data is used by third party applications. | |
| ProxyOfflineBuff | No | 1 | Proxy will keep data N hours |
| Parameter | Mandatory | Default value | Description | |
|---|---|---|---|---|
| er | in case if no connectivity with ZABBIX Server. Older data will be lost. | |||
| Server | Yes | 30 | DNS name or IP address of ZABBIX server thr proxy will report to. | |
| ServerPort | No | 10051 | The Proxy will connect to this server port. | |
| SourceIP | No | - | Set source IP address for all connections established by the process. | |
| StartDBSyncers | No | 0 | Enable database cache: 0 – Disabled 1 – Enabled | |
| StartDiscoverers | No | 1 | Number of discoverers to start (0-255). | |
| StartHTTPPoller s | No | 5 | Number of HTTP pollers to start (0-255). | |
| StartPingers | No | 1 | Number of ICMP pingers to start (0-255). | |
| StartPollers | No | 5 | Number of pollers to start (0255). | |
| StartPollersUnre achable | No | 1 | Number of pollers for unreachable hosts to start (0255). | |
| StartTrappers | No | 5 | Number of trappers to start (0-255) | |
| PingerFrequenc y | No | 30 | ZABBIX server ping servers once per PingerFrequency seconds (1-3600). | |
| Timeout | No | 5 | Do not spend more than Timeout seconds on retrieving requested value (1255) | |
| TrapperTimeout | No | 5 | Do not spend more than Timeout seconds on processing of traps (1-255) | |
| UnavailableDela y | No | 60 | How ofter try to connect to unavailable host | |
| UnreachableDel ay | No | 15 | How often try to connect to unreachable host |
ZABBIX UNIX Agent runs on a host being monitored. The agent provides host's performance and availability information for ZABBIX Server.
ZABBIX Agent processes items of type ‘ZABBIX Agent’ or ‘ZABBIX Agent (active)’.
ZABBIX Agent can be started by executing:
shell> cd bin shell> ./zabbix_agentd
ZABBIX Agent runs as a daemon process. ZABBIX Agent accepts the following command line parameters:
-c --config <file> specify configuration file, default is
/etc/zabbix/zabbix_agentd.conf -h --help give this help -v --version display version number -p --print print supported metrics and exit -t --test <metric> test specified metric and exit
In order to get this help run:
shell> zabbix_agentd –h
Example of command line parameters:
shell> zabbix_agentd –c /usr/local/etc/zabbix_agentd.conf shell> zabbix_agentd --help
shell> zabbix_agentd --print shell> zabbix_agentd –t “system.cpu.load[all,avg1]”
The configuration file contains configuration parameters for zabbix_agentd. The file must exist and it should have read permissions for user ‘zabbix’. Supported parameters:
| Parameter | Mandatory | Default value | Description |
|---|---|---|---|
| BufferSend | No | 5 | Do not keep data longer than N seconds in buffer. Number of seconds, 1-3600. |
| BufferSize | No | 100 | Maximum number of values in a buffer. The agent will send all collected data to ZABBIX Server or Proxy if the buffer is full. |
| DebugLevel | No | 3 | Debug level: 0 – none 1 – critical 2 – errors 3 – warnings 4 – debug |
| DisableActive | No | 0 | Disable processing of active checks. The agent will not connect to ZABBIX server to get list of active items if set to '1'. |
| DisablePassive | No | 0 | Disable processing of passive checks. The agent will not listen TCP port. Set this parameter to '1' if you use active checks only. |
| EnableRemoteC ommands | No | 0 | Enable remote commands. ZABBIX server will be able to send commands for execution by the agent. |
| Hostname | No | System hostname. | Unique host name. The hostname is used for active checks only. If missing, system hostname (system.hostname) is used. |
| Include | No | - | Use this parameter to include |
| Parameter | Mandatory | Default value | Description | |
|---|---|---|---|---|
| a file into the configuration file. Number of parameters Include is not limited. For example: Include=/etc/zabbix/user_par ameters.conf | ||||
| ListenIP | No | - | IP address to bind agent to. Useful if the host has multiple interfaces. | |
| ListenPort | No | 10050 | Port number to listen. | |
| LogFile | No | - | Name of log file. If not set, syslog is used. | |
| LogFileSize | No | 1 | This parameter controls log rotation setting for LogFile. By default, ZABBIX automatically roatates log file when it reaches 1MB. This parameter is in MB. If set to 0, no log rotation will be performed. | |
| PidFile | No | / tmp/zabbix_age ntd.pid | Name of PID file. | |
| RefreshActiveCh ecks | No | 120 | The agent will refresh list of active checks once per 120 (default) seconds. | |
| Server | Yes | - | Comma-delimited list of IP addresses of ZABBIX servers or Proxies. Connections from other IP addresses will be rejected. | |
| ServerPort | No | 10051 | The agent will connect to this server port for processing active checks. This can be port of ZABBIX Server or a Proxy. | |
| SourceIP | No | - | Set source IP address all connections established by the process. | |
| StartAgents | No | 5 | Number of agents to start. | |
| Timeout | No | 3 | Do not spend more than Timeout seconds on getting requested value (1-255). The |
| Parameter | Mandatory | Default value | Description |
|---|---|---|---|
| agent does not kill timeouted User Parameters processes! | |||
| UserParameter | No | - | User-defined parameter to monitor. There can be several user-defined parameters. Value has form , Example:UserParameter=use rs,who|wc -l Note: Example of the configuration file can be found at misc/conf/zabbix_agentd.con f. |
The file contains configuration parameters for zabbix_agent. The file must exist and it should have read permissions for user ‘zabbix’. Supported parameters:
| Parameter | Mandatory | Default value | Description |
|---|---|---|---|
| Server | Yes | - | Comma-delimited list of IP addresses of ZABBIX Servers or Proxies. Connections from other IP addresses will be rejected. |
| Timeout | No | 3 | Do not spend more than Timeout seconds on getting requested value (1-255). The agent does not kill timeouted User Parameters processes! |
| UserParameter | No | - | User-defined parameter to monitor. There can be several user-defined parameters. Example:UserParameter=us ers,who|wc -l |
Note: Example of the configuration file can be found at misc/conf/zabbix_agent.conf
Zabbix_agentd is ZABBIX agent for Win32/64 systems. It will work on Windows NT 4.0, Windows 2000, Windows XP, and Windows Vista.
Installation is very simple and includes 3 steps: Create configuration file. Create configuration file c:/zabbix_agentd.conf (it has the same syntax as UNIX agent). Install agent as a Windows service.
zabbix_agentd.exe --install
If you wish to use configuration file other than c:\zabbix_agentd.conf, you should use the following command for service installation:
zabbix_agentd.exe --config <your_configuration_file> install
Full path to configuration file should be specified. Run agent. Now you can use Control Panel to start agent's service or run:
zabbix_agentd.exe --start
Note: Windows NT 4.0 note. Zabbix_agentd.exe uses PDH (Performance Data Helper) API to gather various system information, so PDH.DLL is needed. This DLL is not supplied with Windows NT 4.0, so you need to download and install it by yourself. Microsoft Knowledge Base article number 284996 describes this in detail and contains a download link. You can find this article at http://support.microsoft.com/default.aspx?scid=kb;en-us;284996
Command line syntax:
zabbix_agentd.exe [-Vhp] [-idsx] [-c <file>] [-t <metric>]
ZABBIX Windows Agent accepts the following command line parameters:
| Options: | |
|---|---|
| -c --config <file> | Specify alternate configuration file (default is |
| c:\zabbix_agentd.conf). | |
| -h --help | Display help information. |
| -V --version | Display version number. |
| -p --print | Print list of supported checks (metrics) and |
| exit. | |
| -t –test <metric> | Test single check (metric) and exit. |
Functions:
-i --install Install ZABBIX agent as a service. -d --uninstall Uninstall ZABBIX agent service. -s --start Start ZABBIX agent service. -x --stop Stop ZABBIX agent service.
The configuration file (c:/zabbix_agentd.conf) contains configuration parameters for Zabbix_agentd.exe. Supported parameters:
| Parameter | Mandatory | Default value | Description |
|---|---|---|---|
| Alias | No | - | Sets the alias for parameter. It can be useful to substitute long and complex parameter name with a smaller and simpler one. For example, if you wish to retrieve paging file usage in percents from the server, you may use |
| Parameter | Mandatory | Default value | Description | |
|---|---|---|---|---|
| parameter "perf_counter[\Paging File(_Total)\% Usage]", or you may define an alias by adding the following line to configuration file: Alias = pg_usage:perf_counter[\Pagi ng File(_Total)\% Usage] After that you can use parameter name "pg_usage" to retrieve the same information. You can specify as many "Alias" records as you wish. Please note that aliases cannot be used for parameters defined in "PerfCounter" configuration file records. | ||||
| DebugLevel | No | 3 | Debug level, one of 0 – none 1 – critical 2 – errors 3 – warnings 4 – debug | |
| Include | No | - | Use this parameter to include a file into the configuration file. Number of parameters Include is not limited. For example: Include=c:\user_parameters. conf | |
| ListenPort | No | 10050 | Port number to listen. | |
| LogFile | No | - | Name of log file. If not set, syslog is used. | |
| LogUnresolvedS ymbols | No | - | Controls logging of unresolved symbols during agent startup. Values can be strings ‘yes’ or ‘no’ (without quotes). | |
| MaxCollectorPro cessingTime | No | 100 | Sets maximum acceptable processing time of one data sample by collector thread (in milliseconds). If processing time will exceed specified |
| Parameter | Mandatory | Default value | Description | |
|---|---|---|---|---|
| value, warning message will be written to the log file. | ||||
| NoTimeWait | No | - | The parameter has no effect. | |
| PerfCounter | No | - | <parameter_name>,"<perf_c ounter_path>",<period> Defines new parameter <parameter_name> which is an average value for system performance counter <perf_counter_path> for the specified time period <period> (in seconds). | |
| For example, if you wish to receive average number of processor interrupts per second for last minute, you can define new parameter "interrupts" as following: | ||||
| PerfCounter = interrupts,"\Processor(0)\Inter rupts/sec",60 | ||||
| Please note double quotes around performance counter path. Samples for calculating average value will be taken every second. You may run typeperf –qx to get list of all performance counters available in Windows. | ||||
| PidFile | No | - | The parameter has no effect. | |
| Server | Yes | - | Comma-delimited list of IP addresses of ZABBIX servers. Connections from other IP addresses will be rejected. | |
| SourceIP | No | - | Set source IP address all connections established by the process. | |
| StartAgents | No | - | The parameter has no effect. |
ZABBIX UNIX Sender is a command line utility which may be used to send performance data to ZABBIX Server for processing.
The utility is usually used in long running user scripts for periodical sending of availability and performance data.
ZABBIX Sender can be started by executing:
shell> cd bin shell> ./zabbix_sender –z zabbix –p 10051 –s LinuxDB3 –k db.connections –o 43
ZABBIX Sender accepts the following command line parameters:
-z --zabbix-server Hostname or IP address of ZABBIX Server.
<zabbix server> -p --port <zabbix Specify port number of server trapper server port> running on the server. Default is 10051.
-s --host <host Specify host name. Host IP address and
name or IP> DNS name will not work. -I --source-Specify source IP address address <ip address>
-k --key <key of Specify metric name (key) we want to send. metric>
-o --value <value> Specify value of the key. -i --input-file Load values from input file. <input file>
-h --help Give this help. -v --version Display version number.
In order to get this help run:
shell> zabbix_sender -h
ZABBIX UNIX Get is a process which communicates with ZABBIX Agent and retrieves required information. The utility is usually used for troubleshooting of ZABBIX Agents. ZABBIX Get can be started by executing:
shell> cd bin shell> ./zabbix_get -s127.0.0.1 -p10050 -k"system.cpu.load[all,avg1]"
ZABBIX Get accepts the following command line parameters:
-p --port <port Specify port number of agent running on the
number> host. Default is 10050. -s –host <host Specify host name or IP address of a host. name or IP>
-I --source-Specify source IP address address <ip address>
-k –key <key of Specify metric name (key) we want to metric> retrieve. -h --help Give this help. -v --version Display version number.
In order to get this help run:
shell> zabbix_get -h
Ubuntu Linux is used as a primary development platform for ZABBIX.
Four servers are used for test purposes:
ZABBIX reacts to events by executing set of operations. An action can be defined for any event or set of events generated by ZABBIX.
Action attributes:
| Parameter | Description |
| Name | Unique action name. |
| Event Source | Source of event. Currently two sources are supported: Triggers – events generated by trigger status changes Discovery – events generated by auto-discovery module |
| Enable escalations | Enable escalations. If enable, the action will be escalated according to operation steps defined for |
| Parameter Description |
|---|
| operations. |
| Period (seconds) Time period for increase of escalation step. |
| Event Source Event source: |
| Triggers – action will be executed for events generated |
| by triggers |
| Discovery – action will be executed for discovery |
| events |
| Default subject Default notification subject. The subject may contain |
| macros. |
| Default message Default notification message. The message may |
| contain macros. |
| Recovery message If enabled, ZABBIX will send a recovery message after |
| an original problem is resolved. The messages will be |
| send to those who received any message for this |
| problem before. |
| Recovery subject Subject of the recovery message. It may contain |
| macros. |
| Recovery message Recovery message. It may contain macros. |
| Status Action status: |
| Enabled – action is active |
| Disabled – action is disabled |
An action is executed only in case if an event matches defined set of conditions. The following conditions can be defined for Trigger based events:
| Condition type | Supported operators | Description |
|---|---|---|
| Application | =, like, not like | = -event came from Trigger, which is part of the Application like -event came from Trigger, which is part of the Application containing the String not like -event came from Trigger, which is part of the Application not containing the String |
| Condition type | Supported operators | Description | ||||||
|---|---|---|---|---|---|---|---|---|
| Host group | =, <> | Compare against Host Group having a trigger which generated event. | ||||||
| = -event came from this Host Group | ||||||||
| <> -event did not come from this Host Group | ||||||||
| Host template | =, <> | Compare against Host Template the trigger belongs to. | ||||||
| = -event came from a trigger inherited from this Host Template | ||||||||
| <> -event did not come from a trigger inherited from this Host Template | ||||||||
| Host | =, <> | Compare against Host having a trigger which generated event. | ||||||
| = -event came from this Host | ||||||||
| <> -event did not come from this Host | ||||||||
| Trigger | =, <> | Compare against generated event. | Trigger | which | ||||
| = -event generated by this Trigger | ||||||||
| <> -event generated by other Trigger | ||||||||
| Trigger (name) | description | like, not like | Compare against Trigger Name which generated event. like – String can be found in Trigger Name. Case sensitive. | |||||
| not like – String cannot be found in Trigger Name. Case sensitive. | ||||||||
| Trigger severity | =, <>, >=, <= | Compare with Trigger Severity. | ||||||
| = -equal to trigger severity | ||||||||
| <> -not equal to trigger severity | ||||||||
| >= -more or equal to trigger severity | ||||||||
| <= -less or equal to trigger severity | ||||||||
| Trigger value | = | Compare with Trigger Value. = -equal to trigger value (OK PROBLEM) | or | |||||
| Time period in | in | Event is within time period. in – event time matches period | the | time | ||||
| Time period is given in format: | ||||||||
| Copyright 2008 ZABBIX SIA | Page 84 of 320 | |||||||
| Condition type | Supported operators | Description |
|---|---|---|
| dd-dd,hh:mm-hh:mm;dddd,hh:mm:hh:mm;… |
Trigger value:
Note: Status change FALSE->UNKNOWN->TRUE is treated as FALSE->TRUE, and TRUE->UNKNOWN->FALSE as TRUE->FALSE.
The following conditions can be defined for Discovery based events:
| Condition type | Supported operators | Description |
|---|---|---|
| Host IP | =, <> | Check if IP address of a discovered Host is or is not in the range of IP addresses. = -Host IP is in the range <> -Host IP is out of the range |
| Service type | =, <> | Check if a discovered service. = -matches discovered service <> -event came from a different service |
| Service port | =, <> | Check if TCP port number of a discovered service is or is not in the range of ports. = -service port is in the range <> -service port is out of the range |
| Discovery status | = | Up – matches Host Up and Service Up events Down – matches Host Down and Service Down events |
| Uptime/Downtime | >=, <= | Downtime for Host Down and Service Down events. Uptime for Host Up and Service Up events. |
| Condition type | Supported operators | Description |
|---|---|---|
| >= -uptime/downtime is more or equal | ||
| <= -uptime/downtime is less or equal Parameter is given in seconds. | ||
| Received value | = <> >= <= like not like | Compare with value received from an agent (ZABBIX, SNMP). String comparison. = -equal to the value <> -not equal to the value >= -more or equal to the value <= -less or equal to the value like – has a substring not like – does not have a substring Parameter is given as a string. |
For example this set of conditions (calculation type: AND/OR):
Host group = Oracle servers Host group = MySQL servers Trigger name like ‘Database is down’ Trigger name like ‘Database is unavailable’
is evaluated as
(Host group = Oracle servers or Host group = MySQL servers) and (Trigger name like ‘Database is down’ or Trigger name like ‘Database is unavailable’)
Operation or a set of operations is executed when event matches conditions.
ZABBIX supports the following operations:
| Parameter | Description |
| Step | If escalation is enabled for this action, escalation settings: From – execute for each step starting from this one To – till this (0, for all steps starting from From) Period – increase step number after this period, 0 – use default period. |
| Operation type | Type of action: Send message – send message to user Execute command – execute remote command |
| Event Source | |
| Send message to | Send message to: Single user – a single user User group – to all member of a group |
| Default message | If selected, default message will be used. |
| Subject | Subject of the message. The subject may contain macros. |
| Message | The message itself. The message may contain macros. |
| Remote command | List of remote commands. |
Note: Starting from 1.6.2, ZABBIX sends notifications only to those users, which have read permissions to a host (trigger), which generated the event. At least one host of a trigger expression must be accessible.
The macros can be used for more efficient reporting.
Subject: {TRIGGER.NAME}: {TRIGGER.STATUS}
Message subject will be replaced by something like:
‘Processor load is too high on server zabbix.zabbix.com: ON’
The message will be replaced by something like: ‘Processor load is: 1.45’
The message will be replaced by something like:
Latest value: 1.45 MAX for 15 minutes: 2.33 MIN for 15 minutes: 1.01
ZABBIX supports number of macros which may be used in various situations. Effective use of macros allows to save time and make ZABBIX configuration more transparent.
The table contains complete list of macros supported by ZABBIX.
| {DATE} | X | Current date in yyyy.mm.dd. format. | ||||
| {ESC.HISTORY} | X | Escalation history. Log of previously sent messages. | ||||
| {EVENT.AGE} | X | Age of the event. Useful in escalated messages. | ||||
| {EVENT.DATE} | X | Date of the event. | ||||
| {EVENT.ID} | X | Numeric event ID which triggered this action. | ||||
| {EVENT.TIME} | X | Time of the event. | ||||
| {HOSTNAME} | X | X | X | X | Host name of first item of the trigger which caused a notification. | |
| {HOST.CONN} | X | X | X | IP and host DNS name depending on host settings. | ||
| {HOST.DNS} | X | X | X | Host DNS name. | ||
| {IPADDRESS} | X | X | X | X | IP address of first item of the trigger which caused a notification. | |
| {ITEM.LASTVALUE} | X | X | The latest value of first item of the trigger expression which caused a notification. Supported from ZABBIX 1.4.3. | |||
| It is alias to {{HOSTNAME}: {TRIGGER.KEY}.last(0)} | ||||||
| {ITEM.NAME} | X | Name of first item of the trigger which caused a notification. | ||||
| {ITEM.VALUE} {ITEM.VALUE1} | X | The latest value of Nth item of the trigger expression if used for displaying triggers. | ||||
| … {ITEM.VALUE9} | Historical (when event happenned) value of Nth item of the trigger expression if used for displaying events. | |||||
| Supported from ZABBIX 1.4.3. | ||||||
| {PROFILE.CONTACT} | X | Contact from host profile. | ||||
| {PROFILE.DEVICETY PE} | X | Device type from of host profile. | ||||
| {PROFILE.HARDWAR E} | X | Hardware from host profile. | ||||
| {PROFILE.NAME} | X | Name from host profile. | ||||
| Copyright 2008 ZABBIX SIA | Page 90 of 320 |
| {PROFILE.LOCATION} {PROFILE.MACADDR ESS} {PROFILE.NOTES} {PROFILE.OS} {PROFILE.SERIALNO} {PROFILE.SOFTWAR E} {PROFILE.TAG} {STATUS} {TIME} {TRIGGER.COMMENT } {TRIGGER.ID} | X X X X X X X X X X X | Location from host profile. Mac Address from host profile. Notes from host profile. OS from host profile. Serial No from host profile. Software from host profile. Tag from host profile. Alias for {TRIGGER.STATUS}. Current time in hh:mm.ss. Trigger comment. Numeric trigger ID which triggered this action. |
| {TRIGGER.KEY} | X | Key of first item of the trigger which caused a notification. |
| {TRIGGER.NAME} | X | Name (description) of the trigger. |
| {TRIGGER.NSEVERIT Y} | X | Numerical trigger severity. Possible values: |
| 0 - Not classified | ||
| 1 - Information | ||
| 2 - Warning 3 - Average 4 - High 5 - Disaster | ||
| {TRIGGER.SEVERITY} | X | Supported starting from ZABBIX 1.6.2. Trigger severity. Possible values: Not classified |
| Information | ||
| Warning Average High Disaster | ||
| {TRIGGER.STATUS} | X | Unknown Trigger state. ON - if trigger is in TRUE state, OFF - if trigger is in FALSE state. |
| {TRIGGER.URL} | X | Trigger URL. |
{TRIGGER.VALUE} X X Current trigger value:
0 - trigger is in OFF state
1 – trigger is in ON state
2 – trigger UNKNOWN
This macro can also be used in
trigger expressions. {host:key.func(param) X X Simple macros as used in trigger } expressions.
Note: Macros for host labels are supported starting from 1.8.
Application is a set of host items. For example, application ‘MySQL Server’ may contain all items which are related to the MySQL server: availability of MySQL, disk space, processor load, transactions per second, number of slow queries, etc.
An item may be linked with one or more applications.
Applications are used in ZABBIX front-end to group items.
User-defined graphs allow the creation of complex graphs. These graphs can be easily accessed via the menu item “Graphs”.
Media is a delivery channel for ZABBIX alerts. None, one or more media types can be assigned to user.
Email notification
Notifications using Jabber messaging.
Custom script. ZABBIX passes three command line parameters to the script: Recipient, Subject and Message.
ZABBIX supports sending of SMS messages using Serial GSM Modem connected to ZABBIX Server’s serial port.
Make sure that:
PIN can be entered by issuing command AT+CPIN=”NNNN” (NNNN is your PIN number, the quotes must present) in a terminal software, such as Unix minicom or Windows HyperTerminal.
ZABBIX has been tested with the following GSM modems:
Use of templates is an excellent way of making maintenance of ZABBIX much easier.
A template can be linked to a number of hosts. Items, triggers and graphs of the template will be automatically added to the linked hosts. Change definition of a template item (trigger, graph) and the change will be automatically applied to the hosts.
Host template attributes:
| Parameter | Description | |
| Name | Unique template (host) name. unique within ZABBIX Node. | The name must be |
| Parameter | Description |
| Groups | List of host groups the template belongs to. |
| New group | Assign new host group to the template. |
| Link with template | Used to create hierarchical templates. |
Host group may have zero, one or more hosts. Host group attributes:
| Parameter | Description |
| Group name | Unique host group name. The name must be unique within ZABBIX Node. |
| Hosts | List of hosts of this group. |
ZABBIX does not support host dependencies. Host dependencies can be defined using more flexible option, i.e. trigger dependencies.
How it works?
A trigger may have list of one or more triggers it depends on. It means that the trigger will still change its status regardless of state of the triggers in the list, yet the trigger won’t generate notifications and actions in case if one of the trigger in the list has state TRUE.
Host dependency
Suppose you have two hosts: a router and a server. The server is behind the router. So, we want to receive only one notification if the route is down:
“The router is down”
instead of:
“The router is down” and “The host is down”
In order to achieve this, we create a trigger dependency: “The host is down” depends on “The router is down”
In case if both the server and the router is down, ZABBIX will not execute actions for trigger “The host is down”.
Item is a single performance or availability check.
Flexible and non-flexible parameters
Flexible parameter is parameter which accepts argument. For example, vfs.fs.free[*] is flexible parameter. * is any string that will be passed as argument of the parameter. vfs.fs.free[/], vfs.fs.free[/opt] -correct definitions.
Allowed characters
The following characters are allowed:
0-9a-zA-Z_.,:-$<space>
Note: Use of the ‘,’ and ‘:’ is not recommended and can be dropped in future releases. Support of Novell parameters will be maintained.
Please consult ZABBIX Manual for Windows parameters. The table is valid for ZABBIX 1.1beta3 and higher.
| Parameter system | Windows | Linux 2.4 | Linux 2.6 | FreeBSD | Solaris | HP-UX | AIX | Tru64 | Mac OS/X | |
|---|---|---|---|---|---|---|---|---|---|---|
| agent.ping | X | X | X | X | X | X | X | X | X | |
| agent.version | X | X | X | X | X | X | X | X | X | |
| kernel.maxfiles | - | X | X | X | - | - | - | - | - | |
| kernel.maxproc | - | - | - | X | X | - | - | - | - | |
| net.if.collisions[<if>] | - | X | X | X | X | - | - | - | - | |
| net.if.in[<if><,mode>] | - | X | X | X | X | - | - | - | - | |
| mode | bytes | - | X | X | X | X | - | - | - | - |
| packets | - | X | X | X | X | - | - | - | - | |
| errors | - | X | X | X | X | - | - | - | - | |
| dropped | - | X | X | X | - | - | - | - | - | |
| net.if.out[<if><,mode>] | - | X | X | X | X | - | - | - | - | |
| mode | bytes | - | X | X | X | X | - | - | - | - |
| packets | - | X | X | X | X | - | - | - | - | |
| errors | - | X | X | X | X | - | - | - | - | |
| dropped | - | X | X | - | - | - | - | - | - | |
| net.tcp.dns[<ip,>zone] | - | X | X | X | X | X | X | X | - | |
| net.tcp.listen[port] | - | - | - | X | X | - | - | - | - | |
| net.tcp.port[<ip,>port] | X | X | X | X | X | X | X | X | X | |
| net.tcp.service.perf[service<,ip> <,port>] | - | X | X | X | X | X | X | X | - | |
| net.tcp.service[service<,ip><,port >] | - | X | X | X | X | X | X | X | - | |
| proc.mem[<name><,user> <,mode><,cmdline>] | - | X | X | X | X | - | X | X | - | |
| Parameter system | Windows | Linux 2.4 | Linux 2.6 | FreeBSD | Solaris | HP-UX | AIX | Tru64 | Mac OS/X | |
|---|---|---|---|---|---|---|---|---|---|---|
| mode | sum | - | X | X | X | X | - | X | X | - |
| avg | - | X | X | X | X | - | X | X | - | |
| max | - | X | X | X | X | - | X | X | - | |
| min | - | X | X | X | X | - | X | X | - | |
| proc.num[<name><,user> <,state><,cmdline>] | - | X | X | X | X | - | X | X | - | |
| state | all | - | X | X | X | X | - | X | X | - |
| sleep | - | X | X | X | X | - | X | X | - | |
| zomb | - | X | X | X | X | - | X | X | - | |
| run | - | X | X | X | X | - | X | X | - | |
| system.boottime | - | X | X | X | - | - | - | - | - | |
| system.cpu.intr | - | X | X | X | X | - | - | - | - | |
| system.cpu.load[<cpu> <,mode>] | X | X | X | X | X | X | - | - | - | |
| mode | avg1 | - | X | X | X | X | X | - | - | - |
| avg5 | - | X | X | X | X | X | - | - | - | |
| avg15 | - | X | X | X | X | X | - | - | - | |
| system.cpu.num | X | X | X | X | X | X | - | - | - | |
| system.cpu.switches | - | - | - | X | X | - | - | - | - | |
| system.cpu.util[<cpu><,type> <,mode>] | X | - | X | X | X | - | - | - | - | |
| Parameter system | Windows | Linux 2.4 | Linux 2.6 | FreeBSD | Solaris | HP-UX | AIX | Tru64 | Mac OS/X | |
|---|---|---|---|---|---|---|---|---|---|---|
| type | user | - | - | X | X | X | X | - | - | - |
| nice | - | - | X | X | - | X | - | - | - | |
| idle | - | - | X | X | X | X | - | - | - | |
| system | - | - | X | X | - | X | - | - | - | |
| kernel | - | - | - | - | X | X | - | - | - | |
| wait | - | - | - | - | X | X | - | - | - | |
| interrupt | - | - | - | X | - | - | - | - | - | |
| mode | avg1 | - | X | X | X | - | X | - | - | - |
| avg5 | - | X | X | X | - | X | - | - | - | |
| avg15 | - | X | X | X | - | X | - | - | - | |
| system.run[command<,mode>] | X | X | X | X | X | X | X | X | X | |
| mode | wait | X | X | X | X | X | X | X | X | X |
| nowait | X | X | X | X | X | X | X | X | X | |
| system.hostname | X | X | X | X | X | X | X | X | X | |
| system.localtime | X | X | X | X | X | X | X | X | X | |
| system.swap.in[<swap><,type>] | - | - | X | - | X | - | - | - | - | |
| type | count | - | - | - | - | X | - | - | - | - |
| pages | - | - | - | - | X | - | - | - | - | |
| system.swap.out[<swap><,type>] | - | - | X | - | X | - | - | - | - | |
| type | count | - | - | - | - | X | - | - | - | - |
| pages | - | - | - | - | X | - | - | - | - | |
| system.swap.size[<swap><,type>] | X | X | X | X | X | - | - | X | - | |
| Parameter system | Windows | Linux 2.4 | Linux 2.6 | FreeBSD | Solaris | HP-UX | AIX | Tru64 | Mac OS/X | |
|---|---|---|---|---|---|---|---|---|---|---|
| mode | free | - | X | X | X | X | - | - | X | - |
| total | - | X | X | X | X | - | - | X | - | |
| system.uname | X | X | X | X | X | X | X | X | - | |
| system.uptime | X | X | X | X | X | - | - | - | - | |
| system.users.num | - | X | X | X | X | X | X | X | - | |
| vfs.dev.read[device<,type> <,mode>] | - | X | X | X | X | - | - | - | - | |
| type | sectors | - | X | X | - | - | - | - | - | - |
| operations | - | X | X | - | X | - | - | - | - | |
| bytes | - | - | - | - | X | - | - | - | - | |
| ops | - | - | - | X | - | - | - | - | - | |
| bps | - | - | - | X | - | - | - | - | - | |
| mode | avg1 | - | - | - | X | - | - | - | - | - |
| avg5 | - | - | - | X | - | - | - | - | - | |
| avg15 | - | - | - | X | - | - | - | - | - | |
| vfs.dev.write[device<,type> <,mode>] | - | X | X | X | X | - | - | - | - | |
| type | sectors | - | X | X | - | - | - | - | - | - |
| operations | - | X | X | - | X | - | - | - | - | |
| bytes | - | - | - | - | X | - | - | - | - | |
| ops | - | - | - | X | - | - | - | - | - | |
| bps | - | - | - | X | - | - | - | - | - | |
| Parameter system | Windows | Linux 2.4 | Linux 2.6 | FreeBSD | Solaris | HP-UX | AIX | Tru64 | Mac OS/X | |
|---|---|---|---|---|---|---|---|---|---|---|
| mode | avg1 | - | - | - | X | - | - | - | - | - |
| avg5 | - | - | - | X | - | - | - | - | - | |
| avg15 | - | - | - | X | - | - | - | - | - | |
| vfs.file.cksum[file] | X | X | X | X | X | X | X | X | - | |
| vfs.file.exists[file] | X | X | X | X | X | X | X | X | X | |
| vfs.file.md5sum[file] | X | X | X | X | X | X | X | X | - | |
| vfs.file.regexp[file, user] | - | X | X | X | X | X | X | X | - | |
| vfs.file.regmatch[file, user] | - | X | X | X | X | X | X | X | - | |
| vfs.file.size[file] | X | X | X | X | X | X | X | X | - | |
| vfs.file.time[file<,mode>] | - | X | X | X | X | X | X | X | - | |
| mode | modify | - | X | X | X | X | X | X | X | - |
| access | - | X | X | X | X | X | X | X | - | |
| change | - | X | X | X | X | X | X | X | - | |
| vfs.file.inode[fs<,mode>] | - | X | X | X | X | X | X | X | - | |
| mode | total | - | X | X | X | X | X | X | X | - |
| free | - | X | X | X | X | X | X | X | - | |
| used | - | X | X | X | X | X | X | X | - | |
| pfree | - | X | X | X | X | X | X | X | - | |
| pused | - | X | X | X | X | X | X | X | - | |
| vfs.file.size[fs<,mode>] | - | X | X | X | X | X | X | X | - | |
| Parameter system | Windows | Linux 2.4 | Linux 2.6 | FreeBSD | Solaris | HP-UX | AIX | Tru64 | Mac OS/X | |
|---|---|---|---|---|---|---|---|---|---|---|
| mode | total | - | X | X | X | X | X | X | X | - |
| free | - | X | X | X | X | X | X | X | - | |
| used | - | X | X | X | X | X | X | X | - | |
| pfree | - | X | X | X | X | X | X | X | - | |
| pused | - | X | X | X | X | X | X | X | - | |
| vm.memory.size[<mode>] | X | X | X | X | X | X | X | - | - | |
| mode | total | - | X | X | X | X | X | X | X | - |
| free | - | X | X | X | X | X | X | X | - | |
| shared | - | X | X | X | - | X | X | - | - | |
| buffers | - | X | X | X | - | X | X | - | - | |
| cached | - | X | X | X | - | X | X | - | - | |
Flexible and non-flexible parameters
Flexible parameter is parameter which accepts argument. For example, vfs.fs.free[*] is flexible parameter. * is any string that will be passed as argument of the parameter. vfs.fs.free[/], vfs.fs.free[/opt] -correct definitions.
String between [] may contain the following characters:
0-9a-zA-Z.:,()_/[space]
List of supported parameters ZABBIX AGENT
| Key | Description | Return value | Parameters | Comments |
|---|---|---|---|---|
| agent.ping | Check the agent availability. | Always return ‘1’. | - | Can be used as a TCP ping. |
| agent.version | Version of ZABBIX Agent. | String | - | Example of returned value: 1.3.2 |
| kernel.maxfiles | Maximum number of opened files supported by OS. | Number of files. Integer. | ||
| kernel.maxproc | Maximum number of processes supported by OS. | Number of processes. Integer. | ||
| log[file<,regexp >] | Monitoring of log file. | Log. | file – full file name regexp – regual expression | Must be Active Check. |
| net.if.collisions[ if] | Out-of-window collision. | Number of collisions. Integer. | if -interface | |
| net.if.in[if | Network | Integer. | if -interface | |
| <,mode>] | interface incoming statistic. | mode – bytes number of bytes (default) packets number of packets errors number of errors dropped number of dropped packets | ||
| net.if.out[if | Network | Integer. | if -interface | Examples: |
| <,mode>] | interface outgoing statistic. | mode – bytes number of bytes (default) packets number of packets errors number of errors | net.if.out[eth0,errors] net.if.out[eth0] You may use this key with Delta (speed per second) in order to get bytes per second statistics. |
| Key | Description | Return value | Parameters | Comments |
|---|---|---|---|---|
| dropped number of dropped packets | ||||
| net.tcp.dns[ip, | Checks if DNS | 0 -DNS is down | ip -IP address of | Example: |
| zone] | service is up. | 1 -DNS is up | DNS server (ignored) zone -zone to test the DNS | net.tcp.dns[127.0.0.1, zabbix.com] |
| net.tcp.listen[p ort] | Checks if this port is in LISTEN state. | 0 -it is not 1 -it is in LISTEN state | port -port number | Example: net.tcp.listen[80] |
| net.tcp.port[<ip | Check, if it is | 0 -cannot | ip -IP | Example: |
| >, port] | possible to make TCP connection to port number port. | connect 1 -can connect | address(default is 127.0.0.1) port -port number | net.tcp.port[,80] can be used to test availability of WEB server running on port 80. Old naming: check_port[*] |
| net.tcp.service[ | Check if | 0 -service is | service -one of ssh, | Example: |
| service <,ip> <,port>] | service is running and accepting TCP connections. | down 1 -service is running 2 -timeout connecting to the service | service.ntp, ldap, smtp, ftp, http, pop, nntp, imap, tcp ip -IP address (default is 127.0.0.1) port -port number (by default standard service port number is used) | net.tcp.service[ftp,,45 ] can be used to test availability of FTP server on TCP port 45. Old naming: check_service[*] |
| net.tcp.service. | Check | 0 -service is | service -one of ssh, | Example: |
| perf[service | performance | down | service.ntp, ldap, | net.tcp.service.p |
| <,ip> <,port>] | of service | sec -number of seconds spent | smtp, ftp, http, pop, nntp, imap, tcp | erf[ssh] can be used to test speed of initial |
| while | ip -IP address | response from SSH | ||
| connecting to | (default is 127.0.0.1) | server. | ||
| the service | port -port number (by default standard service port number | Old naming:check_service[*] | ||
| is used) | ||||
| proc.mem[<na me> <,user> <,mode><,cmdli ne>] | Memory used by process name running under user | Memory used by process. | name -process name user -user name (default is all users) | Example: proc.mem[,root] -memory used by all processes running |
| Key | Description | Return value | Parameters | Comments |
|---|---|---|---|---|
| user | mode -one of avg, | under user "root". | ||
| max, min, sum (default) | proc.mem[zabbix_ser ver,zabbix] -memory | |||
| cmdline -filter by command line | used by all processes zabbix_server running under user zabbix proc.mem[,oracle,ma x,oracleZABBIX] -memory used by most memory hungry process running under oracle having oracleZABBIX in its command line | |||
| proc.num[<nam | Number of | Number of | name -process | Example: |
| e> <,user> <,state><,cmdli ne>] | processes name having state running under user user | processes. | name user -user name (default is all users) state -one of all | proc.num[,mysql] -number of processes running under user mysql |
| (default), run, sleep, | proc.num[apache2,w | |||
| zomb | ww-data] -number of | |||
| cmdline -filter by command line | apache2 running under user www-data | |||
| proc.num[,oracle,slee | ||||
| p,oracleZABBIX] - | ||||
| number of processes | ||||
| in sleep state running | ||||
| under oracle having | ||||
| oracleZABBIX in its | ||||
| command line | ||||
| system.cpu.intr | Device interrupts. | Integer. | ||
| system.boottim e | Timestamp of system boot. | Integer. | Time is seconds. | |
| system.cpu.loa | CPU(s) load. | Processor load. | cpu -CPU number | Example: |
| d[<cpu> <,mode>] | Float. | (default is all CPUs) mode -one of avg1 | system.cpu.load[] | |
| (default),avg5 | ||||
| (average within 5 | ||||
| minutes), avg15 | Note that returned | |||
| value is not | ||||
| percentage. |
| Key | Description | Return value | Parameters | Comments |
|---|---|---|---|---|
| Old naming: system.cpu.loadX | ||||
| system.cpu.nu m | Number of CPUs. | Number of available proccessors. | Example: system.cpu.num | |
| system.cpu.swi tches | Context switches. | Switches count. | Old naming: system[switches] | |
| system.cpu.util[ | CPU(s) | Processor load | cpu -CPU number | Old naming: |
| <cpu> <,type> | utilisation. | in percents | (default is all CPUs) | system.cpu.idleX, |
| <,mode>] | type -one of idle, nice, user (default), system mode -one of avg1 (default),avg5 (average within 5 minutes), avg15 | system.cpu.niceX, system.cpu.systemX, system.cpu.userX Example: system.cpu.util[0,user ,avg5] | ||
| system.run[co | Run specified | Text result of | command - | Example: |
| mmand<,mode> ] | command on the host. | the command | command for execution | system.run[ls -l /] -detailed file list of root |
| mode -one of wait (default, wait end of execution), nowait (do no wait) | directory. Note: To enable this functionality, agent configuration file must have EnableRemoteComm ands=1 option. | |||
| system.hostna me | Return host name. | String value | Example of returned value www.zabbix.com | |
| system.localtim e | System local time. | Time in seconds. | ||
| system.swap.in | Swap in. | Swap statistics | device -swap device | Example: |
| [<device> <,type>] | (default is all), type -one of count (default, number of swapins), pages (pages swapped in) | system.swap.in[,byte s] Old naming: |
| Key | Description | Return value | Parameters | Comments |
|---|---|---|---|---|
| swap[in] | ||||
| system.swap.o ut[<device> <,type>] | Swap in. | Swap statistics | device -swap device (default is all), type -one of count (default, number of swapouts), pages (pages swapped out) | Example: system.swap.out[,pag es] Old naming: swap[out] |
| system.swap.si ze[<device> <,mode>] | Swap space. | Number of bytes or percentage | device -swap device (default is all), type one of free (default, free swap space), total (total swap space), pfree (free swap space, percentage), pused (used swap space, percentage) | Example: system.swap.size[,pfr ee] -percentage of free swap space Old naming: system.swap.free, system.swap.total |
| system.uname | Returns detailed host information. | String value | Example of returned value: FreeBSD localhost 4.4-RELEASE FreeBSD 4.4RELEASE #0: Tue Sep 18 11:57:08 PDT 2001 murray@builder.Free BSD.org: /usr/src/sys/compile/ GENERIC i386 | |
| system.uptime | System's uptime in seconds. | Number of seconds | Use Units s or uptime to get readable values. | |
| system.users.n um | Number of users connected. | Number of users | Command who is used on agent side. | |
| vfs.dev.read[de vice <,type>] | Disk read statistics. | Numeric value | device -disk device (default is all), type one of sectors (default), operations | Example: vfs.dev.read[,operatio ns] Old naming: io[*] |
| vfs.dev.write[de vice <,type>] | Disk write statistics. | Numeric value | device -disk device (default is all), type one of sectors (default), operations | Example: vfs.dev.write[,operatio ns] Old naming: io[*] |
| vfs.file.cksum[fi le] | Calculate file check sum | File check sum calculated by algorithm used | file -full path to file | Example of returned value: 1938292000 |
| Key | Description | Return value | Parameters | Comments |
|---|---|---|---|---|
| by UNIX cksum. | Example: vfs.file.cksum[/etc/pa sswd] | |||
| vfs.file.exists[fil e] | Check if file exists | 0 -file does not exist 1 -file exists | file -full path to file | Example: vfs.file.exists[/tmp/ap plication.pid] |
| vfs.file.md5sum [file] | File's MD5 check sum | MD5 hash of the file. Can be used only for files less than 64MB, unsupported otherwise. | Example of returned value: b5052decb577e0fffd 622d6ddc017e82 Example: vfs.file.md5sum[/etc/z abbix/zabbix_agentd. conf] | |
| vfs.file.regexp[fi le, regexp] | Find string in a file | Matched string | file -full path to file, regexp -GNU regular expression | Example: vfs.file.regexp[/etc/pa sswd,zabbix] |
| vfs.file.regmatc h[file, regexp] | Find string in a file | 0 -expression not found 1 -found | file -full path to file, regexp -GNU regular expression | Example: vfs.file.regexp[/var/lo g/app.log,error] |
| vfs.file.size[file] | File size | Size in bytes. | file -full path to file | File must have read permissions for user zabbix Example: vfs.file.size[/var/log/s yslog] |
| vfs.file.time[file <, mode>] | File time information. | Number of seconds. | file -full path to file mode -one of modify (default, modification time), access -last access time, change -last change time | Example: vfs.file.time[/etc/pass wd,modify] |
| vfs.fs.inode[fs <,mode>] | Number of inodes | Numeric value | fs -filesystem, mode -one of total (default), free, used, pfree (free, percentage), pused (used, percentage) | Example: vfs.fs.inode[/,pfree] Old naming: vfs.fs.inode.free[*], vfs.fs.inode.pfree[*], vfs.fs.inode.total[*] |
| vfs.fs.size[fs <,mode>] | Disk space | Disk space in KB | fs -filesystem, mode -one of total (default), free, used, pfree (free, percentage), pused (used, percentage) | In case of a mounted volume, disk space for local file system is returned. Example: vfs.fs.size[/tmp,free] |
| Key | Description | Return value | Parameters | Comments |
|---|---|---|---|---|
| Old naming: vfs.fs.free[*], vfs.fs.total[*], vfs.fs.used[*], vfs.fs.pfree[*], vfs.fs.pused[*] | ||||
| vm.memory.siz | Memory size | Memory size in | mode -one of total | Old naming: |
| e[<mode>] | bytes | (default), shared, free, buffers, cached | vm.memory.buffers, vm.memory.cached, vm.memory.free, vm.memory.shared, vm.memory.total | |
| web.page.get[h ost,<path>,<por t>] | Get content of WEB page | host hostname, path -path to HTML document (default is /), port -port number (default is 80) | WEB page source as text | Returns EOF on fail. Example: web.page.get[www.z abbix.com,index.php, 80] |
| web.page.perf[ host,<path>,<p ort>] | Get timing of loading full WEB page | Time in seconds | host -hostname, path -path to HTML document (default is /), port -port number (default is 80) | Example: web.page.perf[www.z abbix.com,index.php, 80] |
| web.page.regex p[host, <path>, <port>, <regexp>, <length>,] | Get first occurence of regexp in WEB page | Matched string | host -hostname, path -path to HTML document (default is /), port -port number (default is 80), regexp -GNU regular expression, length -number of characters to return | Returns EOF on fail. Example: web.page.get[www.z abbix.com, index.php, 80, OK, 2] |
Linux-specific note. ZABBIX agent must have read-only access to filesystem /proc. Kernel patches from www.grsecurity.org limit access rights of non-privileged users.
WIN32-SPECIFIC PARAMETERS
This section contains description of parameter supported by ZABBIX WIN32 agent only.
| Key | Description | Return value | Comments |
|---|---|---|---|
| agent[avg_coll ector_time] | Average time spent by collector | Time in milliseconds |
| Key | Description | Return value | Comments |
|---|---|---|---|
| thread on each sample processing for last minute. | |||
| agent[max_coll ector_time] | Maximum time spent by collector thread on each sample processing for last minute. | Time in milliseconds | |
| agent[accepted _requests] | Total number of requests accepted by agent for processing. | Number of requests | |
| agent[rejected_ requests] | Total number of requests rejected by agent for processing. | Number of requests | |
| agent[timed_ou t_requests] | Total number of requests timed out in processing. | Number of requests | |
| agent[accept_e rrors] | Total number of accept() system call errors. | Number of system calls | |
| agent[processe d_requests] | Total number of requests successfully processed by agent. | Number of requests | |
| agent[failed_re quests] | Total number of requests with errors in processing. | Number of requests | These requests generated ZBX_ERROR return code |
| agent[unsuppo rted_requests] | Total number of requests for unsupported parameters. | Number of requests | These requests generated ZBX_UNSUPPORTED return code |
| perf_counter[*] | Value of any performance counter, where | Value of the counter | Performance Monitor can be used to obtain list of available counters. Note that this parameter will return correct value only for counters that require just one sample (like |
| Key | Description | Return value | Comments |
|---|---|---|---|
| parameter is the counter path. | \System\Threads). It will not work as expected for counters that require more that one sample -like CPU utilisation. | ||
| service_state[*] | State of service. Parameter is service name. | 0 – running 1 – paused 2 -start pending 3 -pause pending 4 -continue pending 5 -stop | Parameter must be real service name as it seen in service properties under "Name:" or name of EXE file. |
| pending 6 – stopped 7 -unknown 255 – no such service | |||
| proc_info[<pro cess>,<attribut e>,<type>] | Different information about specific process(es). | <process> -process name (same as in proc_cnt[] parameter) <attribute> -requested | The following attributes are currenty supported: vmsize -Size of process virtual memory in Kbytes wkset -Size of process working set (amount of physical memory used by process) in Kbytes pf -Number of page faults ktime -Process kernel time in milliseconds utime -Process user time in milliseconds io_read_b -Number of bytes read by process during I/O operations io_read_op -Number of read operation performed by process io_write_b -Number of bytes written by process during I/O operations io_write_op -Number of write operation performed by process io_other_b Number of bytes transferred by process during operations other than read and write operations io_other_op -Number of I/O |
| process attribute. | operations performed by process, other than read and write operations gdiobj -Number of GDI objects used by process userobj -Number of USER objects used by process <type> -representation type (meaningful when more than one process with the same name exists). Valid values are: min -minimal value among all processes named <process> max -maximal value among all processes named <process> avg -average value for all processes named <process> sum -sum of values for all processes named |
| Key | Description | Return value | Comments |
|---|---|---|---|
| <process> Examples: 1. In order to get the amount of physical memory taken by all Internet Explorer processes, use the following parameter: proc_info[iexplore.exe,wkset,sum] 2. In order to get the average number of page faults for Internet Explorer processes, use the following parameter: proc_info[iexplore.exe,pf,avg] Note: All io_xxx,gdiobj and userobj attributes available only on Windows 2000 and later versions of Windows, not on Windows NT 4.0. |
ZABBIX must be configured with SNMP support in order to be able to retrieve data provided by SNMP agents.
The following steps have to be performed in order to add monitoring of SNMP parameters:
Step 1 Create a host for the SNMP device.
Enter an IP address and a port of 161. Set the host Status to NOT MONITORED. You can use the host.SNMP template which would automatically add set of items. However, the template may not be compatible with the host.
Step 2 Find out the SNMP string of the item you want to monitor.
After creating the host, use 'snmpwalk' (part of ucd-snmp/net-snmp software which you should have installed as part of the ZABBIX installation) or equivalent tool:
shell> snmpwalk <host or host IP> public
This will give you a list of SNMP strings and their last value. If it doesn't then it is possible that the SNMP 'community' is different to the standard public in which case you will need to find out what it is. You would then go through the list until you find the string you want to monitor, e.g. you wanted to monitor the bytes coming in to your switch on port 3 you would use:
interfaces.ifTable.ifEntry.ifOctetsIn.3 = Counter 32: 614794138 You should now use the snmpget command to find the OID for interfaces.ifTable.ifEntry.ifInOctets.3:
shell> snmpget -On 10.62.1.22 interfaces.ifTable.ifEntry.ifOctetsIn.3
where the last number in the string is the port number you are looking to monitor. This should give you something like the following:
.1.3.6.1.2.1.2.2.1.10.3 = Counter32: 614794138
again the last number in the OID is the port number.
3COM seem to use port numbers in the hundreds, e.g. port 1=port 101, port 3=port 103, but Cisco use regular numbers, e.g. port 3=3
Create an item for monitoring.
So, now go back to ZABBIX and click on Items, selecting the SNMP host you created earlier. Depending on whether you used a template or not when creating your host you will have either a list of SNMP items associated with your host or just a new item box. We will work on the assumption that you are going to create the item yourself using the information you have just gathered using snmpwalk and snmpget, so enter a plain English description in the 'Description' field of the new item box. Make sure the 'Host' field has your switch/router in it and change the 'Type' field to "SNMPv1 agent" (I had difficulty with SNMPv2 agent so I don't use it). Enter the community (usually public) and enter the numeric OID that you retrieved earlier in to the 'SNMP OID' field being sure to include the leading dot,
i.e. .1.3.6.1.2.1.2.2.1.10.3
Enter the 'SNMP port' as 161 and the 'Key' as something meaningful, e.g. SNMP-InOctets-Bps. Choose the Multiplier if you want one and enter an 'update interval' and 'keep history' if you want it to be different from the default. Set the 'Status' to MONITORED, the 'Type of information' to NUMERIC and the 'Store value' to DELTA (important otherwise you will get cumulative values from the SNMP device instead of the latest change).
Now ADD the item and go back to the hosts area of ZABBIX. From here set the SNMP device to be MONITORED and check in LATEST VALUES for your SNMP data!
General example Note that OID can be given in either numeric or string form. However, in some cases, string OID must be converted to numeric representation. Utility snmpget may be used for this purpose:
| Parameter | Description |
| Community | public |
| Oid | 1.2.3.45.6.7.8.0 (or .1.2.3.45.6.7.8.0) |
| Key | <Unique string to be used as reference to triggers> For example, ‘my_param’. |
shell> snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0
Monitoring of SNMP parameters is possible if either -with-net-snmp or -with-ucdsnmp flag was specified while configuring ZABBIX sources.
Monitoring of Uptime
| Parameter | Description |
| Community | public |
| Oid | MIB::sysUpTime.0 |
| Key | router.uptime |
| Value type | Float |
| Units | uptime |
| Multiplier | 0.01 |
Simple checks Simple checks are normally used for agent-less monitoring or for remote checks of services. Note that ZABBIX Agent is not needed for simple checks. ZABBIX
Server is responsible for processing of simple checks (making external connections, etc). All simple check accepts two optional parameters: ip -IP address. Dafult value is 127.0.0.1 port -Port number. If missing, standard default service port is used. Examples of using simple checks:
ZABBIX Manual v1.6 ftp,127.0.0.1,155http,11.22.33.44http_perf,11.22.33.44,8080
List of supported simple checks:
| Key | Description | Return value |
|---|---|---|
| icmpping | Checks if server is accessible by ICMP ping | 0 – ICMP ping fails 1 – ICMP ping successful |
| icmppingsec | Return ICMP ping response time | Number of seconds |
| ftp,<ip>,<port> | Checks if FTP | 0 – FTP server is down |
| server is running and | 1 – FTP server is running | |
| accepting connections | 2 – timeout | |
| http,<ip>,<port> | Checks if HTTP | 0 – HTTP server is down |
| server is running and | 1 – HTTP server is running | |
| accepting connections | 2 – timeout | |
| imap,<ip>,<port> | Checks if IMAP | 0 – IMAP server is down |
| server is running and | 1 – IMAP server is running | |
| accepting connections | 2 – timeout | |
| nntp,<ip>,<port> | Checks if NNTP | 0 – NNTP server is down |
| server is running and | 1 – NNTP server is running | |
| accepting connections | 2 – timeout | |
| pop,<ip>,<port> | Checks if POP | 0 – POP server is down |
| server is running and | 1 – POP server is running | |
| accepting connections | 2 – timeout | |
| smtp,<ip>,<port> | Checks if SMTP | 0 – SMTP server is down |
| server is running and | 1 – SMTP server is running | |
| accepting connections | 2 – timeout | |
| ssh,<ip>,<port> | Checks if SSH | 0 – SSH server is down |
| server is running and | 1 – SSH server is running | |
| accepting connections | 2 – timeout |
Return value
Checks if TCP
0 – TCP service is down service is
tcp,<ip>,<port>
1 – TCP service is running running and accepting
2 – timeout connections
Checks if FTP
0 – FTP server is down server is
ftp_perf,<ip>,<port>
Otherwise number of millisecond spent running and connecting to FTP server.
accepting connections
Checks if HTTP 0 – HTTP (WEB) server is down
http_perf,<ip>,<port
(WEB) server is
>
Otherwise number of millisecond spent running and connecting to HTTP server.
accepting connections
Checks if IMAP 0 – IMAP server is down
imap_perf,<ip>,<port
server is
>
Otherwise number of millisecond spent running and connecting to IMAP server.
accepting connections
Checks if NNTP 0 – NNTP server is down
nntp_perf,<ip>,<port
server is
>
Otherwise number of millisecond spent running and connecting to NNTP server.
accepting connections
Checks if POP
0 – POP server is down server is
pop_perf,<ip>,<port>
Otherwise number of millisecond spent running and connecting to POP server.
accepting connections
Checks if SMTP 0 – SMTP server is down
smtp_perf,<ip>,<port
server is
>
Otherwise number of millisecond spent running and connecting to SMTP server.
accepting connections
Checks if SSH
0 – SSH server is down server is
ssh_perf,<ip>,<port>
Otherwise number of millisecond spent running and connecting to SSH server.
accepting connections
ZABBIX will not process a simple check longer than Timeout seconds defined in ZABBIX Server configuration file.
In case if Timeout time succeeded, ‘2’ is returned.
ZABBIX uses external utility fping for processing of ICMP pings. The utility is not part of ZABBIX distribution and has to be additionally installed. If the utility is missing, has wrong permissions or its location does not match FpingLocation defined in configuration file, ICPM pings (icmpping and icmppingsec) will not be processed.
Run these commands as user ‘root’ in order to setup correct permissions:
shell> chown root:zabbix /usr/sbin/fping
shell> chmod 710 /usr/sbin/fping
shell> chmod ug+s /usr/sbin/fping
Internal checks allow monitoring of internals of ZABBIX. Internal checks are calculated by ZABBIX Server.
| Key | Description | Comments |
|---|---|---|
| zabbix[boottime] | Startup time of ZABBIX server process in seconds. | In seconds since the epoch. |
| zabbix[history] | Number of values stored in table HISTORY | Do not use if MySQL InnoDB, Oracle or PostgreSQL is used! |
| zabbix[history_str] | Number of values stored in table HISTORY_STR | Do not use if MySQL InnoDB, Oracle or PostgreSQL is used! |
| zabbix[items] | Number of items in ZABBIX database | |
| zabbix[items_unsup ported] | Number of unsupported items in ZABBIX database | |
| zabbix[log] | Stores warning and error messages generated by | Character. Add item with this key to have ZABBIX internal messages stored. |
| Key | Description | Comments | |||
|---|---|---|---|---|---|
| ZABBIX server. | |||||
| zabbix[proxy,<name >,<param>] | Access to Proxy related information. | <name> -Proxy name List of supported parameters (<param>): lastaccess – timestamp of last heart beat message received from Proxy For example, zabbix[proxy,”Germany”,lastaccess] | |||
| zabbix[queue] | Number items in Queue. | of the | |||
| zabbix[trends] | Number of values stored in table TRENDS | Do not use if MySQL InnoDB, Oracle PostgreSQL is used! | or | ||
| zabbix[triggers] | Number triggers ZABBIX database | of in | |||
| zabbix[uptime] | Uptime of ZABBIX server process in seconds. | ||||
Aggregate checks do not require any agent running on a host being monitored. ZABBIX server collects aggregate information by doing direct database queries.
Syntax of aggregate item's key
groupfunc[“Host group”,”Item key”,”item func”,”parameter”]
Supported group functions:
| GROUP FUNCTION | DESCRIPTION |
| grpavg | Average value |
| grpmax | Maximum value |
| grpmin | Minimum value |
| grpsum | Sum of values |
Supported item functions:
| ITEM FUNCTION | DESCRIPTION |
| avg | Average value |
| count | Number of values |
| last | Last value |
| max | Maximum value |
| min | Minimum value |
| sum | Sum of values |
Examples of keys for aggregate items: Example 1 Total disk space of host group 'MySQL Servers'.
grpsum[“MySQL Servers”,”vfs.fs.size[/,total]”,”last”,”0”]
Example 2 Average processor load of host group 'MySQL Servers'.
grpavg[“MySQL Servers”,”system.cpu.load[,avg1]”,”last”,”0”]
grpavg[“MySQL Servers”,”mysql.qps”,”avg”,”300”]
External check is a check executed by ZABBIX Server by running a shell script or a binary. External checks do not require any agent running on a host being monitored. Syntax of item’s key:
script[parameters]
script – name of the script.
parameters – list of command line parameters.
ZABBIX server will find and executed the script in directory defined in configuration parameter ExternalScripts. First command line parameter is host name, other parameters are substituted by parameters.
Note: Do not overuse external checks! It can decrease performance for ZABBIX system very much.
check_oracle.sh[-h 192.168.1.4]
ZABBIX will execute:
check_oracle.sh www1.company.com -h 192.168.1.4.
Functionality of ZABBIX agents can be enhanced by defining user parameters (UserParameter) in agent’s configuration file.
In order to define a new parameter for monitoring, one line has to be added to configuration file of ZABBIX agent and the agent must be restarted.
User parameter has the following syntax:
UserParameter=key,command
| Parameter | Description |
| Key | Unique item key. |
| Command | Command to be executed to evaluate value of the Key. |
Simple command
UserParameter=ping,echo 1
The agent will always return ‘1’ for item with key ‘ping’.
More complex example UserParameter=mysql.ping,mysqladmin -uroot ping|grep alive|wc –l
The agent will return ‘1’, if MySQL server is alive, ‘0’ – otherwise.
Flexible user parameters can be used for more control and flexibility. For flexible user parameters,
UserParameter=key[*],command
| Parameter | Description |
| Key | Unique item key. The [*] defines that this key accepts |
| parameters. | |
| Command | Command to be executed to evaluate value of the Key. ZABBIX parses content of [] and substitutes $1,…,$10 in the command. |
Something very simple
UserParameter=ping[*],echo $1
We may define unlimited number of items for monitoring all having format ping[something]. ping[0] – will always return ‘0’ ping[aaa] – will always return ‘aaa’
Let’s add more sense!
UserParameter=mysql.ping[*],mysqladmin –u$1 –p$2 ping|grep alive|wc –l
This parameter can be used for monitoring availability of MySQL database. We can pass user name and password:
mysql.ping[zabbix,our_password]
How many lines matching a regular expression in a file?
UserParameter=wc[*],grep “$2” $1|wc -l
This parameter can be used to calculate number of lines in a file.
wc[/etc/passwd,root] wc[/etc/services|zabbix]
Windows performance counter can be effectively monitored using perf_counter[]. For example:
perf_counter[“Processor(0)\Interrupts/sec”]
In order order to get full list of performance counter available for monitoring you may run:
typeperf -qx
Unfortunately, depending on local settings naming of the performance counters can be different on different Windows servers. This intoroduce certain problem when creating a template for monitoring number of Windows machines having different locales.
Every performance counter can be translated into numeric form, which is unique
and exactly the same regardless of language settings. Run regedit, the find HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009.
The registry entry contains information like: 1 1847 2 System 4 Memory 6 % Processor Time 10 File Read Operations/sec 12
File Write Operations/sec 14 File Control Operations/sec 16 File Read Bytes/sec 18 File Write Bytes/sec .... So, in order to translate string name of a performance counter into numeric form, find corresponding numbers for each part of the performance counter, like: System -> 2 % Processor Time -> 6 /System/% Processor Time Then use these numbers to create a numeric format: /2/6
In order to define a new parameter for monitoring, one line has to be added to configuration file of ZABBIX agent and the agent must be restarted.
Trigger is defined as a logical expression and represents system state.
Trigger status (expression) is recalculated every time ZABBIX server receives new value, if this value is part of this expression. The expression may have the following values:
VALUE DESCRIPTION
TRUE Normally means that something happened. For example, processor load is too high.
FALSE This is normal trigger state.
UNKNOWN In this case, ZABBIX cannot evaluate trigger expression. This may happen because of several reasons:
The expressions used in triggers are very flexible. You can use them to create complex logical tests regarding monitored statistics.
The following operators are supported for triggers (descending priority of execution):
PRIORITY OPERATOR DEFINITION
1/ Division 2* Multiplication 3-Arithmetical minus 4+ Arithmetical plus 5< Less than 6> More than 7# Not equal. The operator is defined as:
A=B • (A<B-0.000001) | (A>B+0.000001) 8= Is equal. The operator is defined as:
A=B • (A>B-0.000001) & (A<B+0.000001) 9& Logical AND 10 | Logical OR
The following functions are supported:
| FUNCTION | ARGUM | SUPPORTED | DEFINITION |
| ENT | VALUE | ||
| TYPES | |||
| abschang e | ignored | float, int, str, text | Returns absolute difference between last and previous values. |
| For strings: | |||
| 0 – values are equal | |||
| 1 – values differ | |||
| avg | sec or #num | float, int | Average value for period of time. Parameter defines length of the |
| period in seconds. | |||
| delta | sec or | float, int | Same as max()-min() |
| #num | |||
| change | ignored | float, int, str, text | Returns difference between last and previous values. |
| For strings: | |||
| 0 – values are equal | |||
| 1 – values differ |
| FUNCTION | ARGUM | SUPPORTED | DEFINITION |
| ENT | VALUE | ||
| TYPES | |||
| count | sec or #num | float, int, log, str | Number of historical values for period of time in seconds or number of last #num values matching condition. |
| The function accepts second optional parameter pattern and third parameter operation. | |||
| For example, | |||
| count(600,12) will return exact number of values equal to ‘12’ stored in the history. | |||
| Integer items: exact match | |||
| Float items: match within 0.00001 | |||
| String, text and log items: matches if contains pattern. | |||
| Third parameter works for integer and float values only. | |||
| Supported operators: | |||
| eq – equal | |||
| ne – not equal | |||
| gt – greater | |||
| ge – greater or equal | |||
| lt – less | |||
| le – less or equal | |||
| For example, | |||
| count(600,12,”gt”) will return exact number of values which are more | |||
| than ‘12’ stored in the history for the last 600 seconds. | |||
| Another example: | |||
| count(#10,12,”gt”) will return exact number of values which are more | |||
| than ‘12’ stored in the history among last 10 values. | |||
| Parameter #num is supported from ZABBIX 1.6.1. |
| FUNCTION | ARGUM ENT |
| date | ignored |
| dayofweek diff | ignored ignored |
| fuzzytime | sec |
| iregexp last | 1st – string 2nd – sec or #num sec #num |
| logseverit y | ignored |
| SUPPORTED | DEFINITION |
| VALUE | |
| TYPES | |
| any | Returns current date in YYYYMMDD format. |
| For example: 20031025 | |
| any | Returns day of week in range of 1 to 7. Mon – 1, Sun – 7. |
| float, int, str, | Returns: |
| text | • 1 – last and previous values differ |
| • 0 – otherwise | |
| float, int | Returns 1 if timestamp (item value) does not differ from ZABBIX server |
| time for more than N seconds, 0 – otherwise. | |
| Usually used with system.localtime to check that local time is in sync with local time of ZABBIX server. | |
| str, log, text | This function is non case-sensitive analogue of regexp. |
| float, int, str, text | Last (most recent) value. Parameter: sec – ignored |
| #num – Nth value | |
| For example, | |
| last(0) is always equal to last(#1) | |
| last(#3) – third most recent value | |
| ZABBIX does not guarantee exact order of values if more than two | |
| values exists within one second in | |
| history. | |
| Parameter #num is supported starting from ZABBIX 1.6.2. | |
| log | Returns log severity of the last log entry. Parameter is ignored. |
| • 0 – default severity | |
| • N – severity (integer, useful for Windows event logs). ZABBIX takes log severity from field Information of Windows event log. |
| FUNCTION | ARGUM | SUPPORTED |
| ENT | VALUE | |
| TYPES | ||
| logsource | string | log |
max
min
nodata
now
prev regexp
sec, #num
sec, #num
sec
ignored
ignored
1st – string 2nd – sec or #num float, int
float, int
any
any
float, int, str, text
str, log, text
DEFINITION
Check if log source of the last log entry matches parameter.
Normally used for Windows event logs. For example, logsource(“VMWare Server”)
Maximal value for period of time. Parameter defines length of the period in seconds.
Minimal value for period of time. Parameter defines length of the period in seconds.
Returns:
Returns number of seconds since the Epoch (00:00:00 UTC, January 1, 1970).
Returns previous value. Parameter is ignored.
Check if last value matches regular expression. Parameter defines regular expression, Posix style.
Second optional parameter is number of seconds or number of lines to analyse. In this case more than one value will be processed.
This function is case-sensitive.
Returns:
FUNCTION ARGUM SUPPORTED DEFINITION ENT VALUE TYPES
1st
str – str, log, text Find string in last (most recent) string value. Parameter defines string to find. Case sensitive!
2nd – sec
or #num Second optional parameter is number of seconds or number of lines to analyse. In this case more than one value will be processed.
Returns:
sum sec, float, int Sum of values for period of time. #num Parameter defines length of the period in seconds.
time ignored any Returns current time in HHMMSS format. Example: 123055
Note: Note that some of the functions cannot be used for non-numeric parameters!
Most of numeric functions accept number of seconds as an argument. You may also use prefix # to specify that argument has a different meaning:
| ARGUMENT | DEFINITION |
| sum(600) | Sum of all values within 600 seconds |
| sum(#600) | Sum of last 600 values |
The following constants are supported for triggers:
CONSTANT DEFINITION <number> Positive float number. Examples: 0, 1, 0.15, 123.55 <number><K|M|G> K – 1024*N M – 1024*1024*N G – 1024*1024*1024*N Examples: 2K, 4G, 0.5M
A simple useful expression might look like:
{<server>:<key>.<function>(<parameter>)}<operator><const>
Parameter must be given even for those functions, which ignore it. Example: last(0)
Processor load is too high on www.zabbix.com
{www.zabbix.com: system.cpu.load[all,avg1].last(0)}>5)
‘www.zabbix.com: system.cpu.load[all,avg1]’ gives a short name of the monitored parameter. It specifies that the server is ‘www.zabbix.com’ and the key being monitored is ‘system.cpu.load[all,avg1]’. By using the function ‘last()’, we are referring to the most recent value. Finally, ‘>5’ means that the trigger is true whenever the most recent processor load measurement from www.zabbix.com is greater than 5.
www.zabbix.com is overloaded
({www.zabbix.com: system.cpu.load[all,avg1].last(0)}>5)| ({www.zabbix.com: system.cpu.load[all,avg1].min(600)}>2)
The expression is true when either the current processor load is more than 5 or the processor load was more than 2 during last 10 minutes.
/etc/passwd has been changed
Use of function diff:
({www.zabbix.com: vfs.file.cksum[/etc/passwd].diff(0)})>0
The expression is true when the previous value of checksum of /etc/passwddiffers from the most recent one.
Similar expressions could be useful to monitor changes in important files, such as /etc/passwd, /etc/inetd.conf, /kernel, etc.
Someone downloads a big file from the Internet
Use of function min:
({www.zabbix.com: net.if.in[eth0,bytes].min(300)})>100K
The expression is true when number of received bytes on eth0 is more than 100 KB within last 5 minutes.
Both nodes of clustered SMTP server are down
Note use of two different hosts in one expression:
({smtp1.zabbix.com:net.tcp.service[smtp].last(0)}=0)&({smtp2.zabbi x.com:net.tcp.service[smtp].last(0)}=0)
The expression is true when both SMTP servers are down on both smtp1.zabbix.com and smtp2.zabbix.com.
ZABBIX agent needs to be upgraded
Use of function str(): {zabbix.zabbix.com:agent.version.str(beta8)}=1
The expression is true if ZABBIX agent has version beta8 (presumably 1.0beta8).
Server is unreachable
{zabbix.zabbix.com:status.last(0)}=2
Note: The ‘status’ is a special parameter which is calculated if and only if corresponding host has at least one parameter for monitoring. See description of ‘status’ for more details.
No heart beats within last 3 minutes
Use of function nodata():
{zabbix.zabbix.com:tick.nodata(180)}=1
‘tick’ must have type ‘ZABBIX trapper’’. In order to make this trigger work, item ‘tick’ must be defined. The host should periodically send data for this parameter using zabbix_sender. If no data is received within 180 seconds, the trigger value becomes TRUE.
CPU activity at night time
Use of function time():
({zabbix: system.cpu.load[all,avg1].min(300)}>2)&({zabbix: system.cpu.load[all,avg1].time(0)}>000000)& ({zabbix: system.cpu.load[all,avg1].time(0)}<060000)
The trigger may change its status to true, only at night (00:00-06:00) time.
Trigger dependencies can be used to define relationship between triggers.
Trigger dependencies is a very convenient way of limiting number of messages to be sent in case if an event belongs to several resources. For example, a host Host is behind router Router2 and the Router2 is behind
Router1. ZABBIX -Router1 – Router2 -Host If the Router1 is down, then obviously the Host and the Router2 are also
unreachable. One does not want to receive three notifications about the Host, the Router1 and the Router2. This is when Trigger dependencies may be handy. In this case, we define these dependencies:
Before changing status of trigger ‘Host is down’, ZABBIX will check if there are corresponding trigger dependencies defined. If so, and one of the triggers is in TRUE state, then trigger status will not be changed and thus actions will not be executed and notifications will not be sent.
ZABBIX perform this check recursively. If Router1 or Router2 is unreachable, the Host trigger won’t be updated.
Trigger severity defines how important is a trigger. ZABBIX supports following trigger severities:
| SEVERITY | DEFINITION | COLOR |
|---|---|---|
| Not | Unknown severity. | Gray. |
| classified | ||
| Information | For information purposes. | Light greed. |
| Warning | Be warned. | Light yellow. |
| Average | Average problem. | Dark red. |
| High | Something important has happened. | Red. |
| Disaster | Disaster. Financial losses, etc. | Bright red. |
The severities are used to:
Sometimes a trigger must have different conditions for different states. For example, we would like to define a trigger which would become TRUE when server room temperature is higher than 20C while it should stay in the state until temperature will not become lower than 15C.
In order to do this, we define the following trigger:
Temperature in server room is too high
({TRIGGER.VALUE}=0&{server:temp.last(0)}>20)| ({TRIGGER.VALUE}=1&{server:temp.last(0)}>15)
Note use of macro {TRIGGER.VALUE}. The macro returns current trigger value.
ZABBIX screens allow grouping of various information for quick access and display on one screen. Easy-to-use screen builder makes creation of the screens easy and intuitive.
Screen is a table which may contain the following elements in each cell:
Number of elements in each screen is unlimited.
Slide Show is a set of screens, which will be automatically rotated according to configured update intervals.
PARAMETER Description
Name Name of slide show. Update interval (in sec) This parameter defines default interval between
screen rotations in seconds. Slides List of individual slides (screens): Screen Screen name Delay How long the screen will be displayed, in
seconds. If set to 0, Update Interval of the slide show will be used.
Slide show “ZABBIX administrators”
The slide show consists of two screens which will be displayed in the follwing order: ZABBIX Server • Pause 60 seconds • ZABBIX Server2 • Pause 30 seconds
• ZABBIX Server • Pause 60 seconds • ZABBIX Server2 • ...
IT Services are intended for those who want to get a high-level (business) view of monitored infrastructure. In many cases, we are not interested in low-level details, like lack of disk space, high processor load, etc. What we are interested is availability of service provided by our IT department. We can also be interested in identifying weak places of IT infrastructure, SLA of various IT services, structure of existing IT infrastructure, and many other information of higher level.
ZABBIX IT Services provides answers to all mentioned questions.
IT Services is hierarchy representation of monitored data.
A very simple IT Service structure may look like:
IT Service
|
|-Workstations
||
| |-Workstation1
||
| |-Workstation2
|
|-Servers
Each node of the structure has attribute status. The status is calculated and propagated to upper levels according to selected algorithm. Triggers create lowest level of the IT Services. [To be finished...]
User permissions
All ZABBIX users access the ZABBIX application through the Web-based front end. Each ZABBIX user is assigned a unique login name and a password. All user passwords are encrypted and stored on the ZABBIX database. Users can not use their user id and password to log directly into the UNIX server unless they have also been set up accordingly to UNIX. Communication between the Web Server and the user’s browser can be protected using SSL.
Access permissions on screen within the menu may be set for each user. By default, no permissions are granted on a screen when user is registered to the ZABBIX.
Note that the user is automatically disconnected after 30 minutes of inactivity.
[To be finished...]
ZABBIX has a flexible user permission schema which can be efficiently used to manage user permission within one ZABBIX installation or in a distributed environment.
Permissions are granted to user groups on a host group level.
ZABBIX supports several types of users. The type controls what administrative functions a user has permission to.
User types are used to define access to administrative functions and to specify default permissions.
USER TYPE Description
ZABBIX User The user has access to Monitoring menu. The user has no access to any resources by default. Permissions to host groups must be explicitly given.
ZABBIX Admin The user has access to Monitoring and Configuration. The user has no access to any host groups by default. Permissions to host groups must be explicitly given.
ZABBIX Super Admin The user has access to everything: Monitoring, Configuration and Administration. The user has Read-Write access to all host groups. Permissions cannot be revoked by by denying access to specific host groups.
ZABBIX Queue displays items that are waiting for a refresh. The Queue is just a logical representation of data from the database. There is no IPC queue or any other queue mechanism in ZABBIX.
Statistics shown by the Queue is a good indicator of performance of ZABBIX server.
The Queue on a standalone application or when displayed for a master node shows items waiting for a refresh.
In this case, we see that we have three items of type ZABBIX agent waiting to be refreshed 0-5 seconds, and one item of type ZABBIX agent (active) waiting more than five minutes (perhaps the agent is down?).
Note that information displayed for a child node is not up-to-date. The master node receives historical data with a certain delay (normally, up-to 10 seconds for inter-node data transfer), so the information is delayed.
On the screenshot we see that there are 93 items waiting more than 5 minutes for refresh on node “Child”, however we should not trust the information as it depends on:
-performance of the Child node
-communications between Master and Child nodes
-possible local time difference between Master and Child nodes
Note: A special item key zabbix[queue] can be used to monitor health of the queue by ZABBIX.
The scripts are used to automatically start/stop ZABBIX processes during system’s start-up/shutdown.
The scripts are located under directory misc/init.d.
The script is used to receive SNMP traps. The script must be used in combination with snmptrapd, which is part of package net-snmp.
Configuration guide:
traphandle default /bin/bash /home/zabbix/bin/snmptrap.sh
• Copy misc/snmptrap/snmptrap.sh to ~zabbix/bin
• Run snmptrapd
This is Welcome ZABBIX screen. When installed use user name "Admin" with no password to connect as ZABBIX superuser.
When logged in, you will see "Connected as Admin" and access to "Configuration" area will be granted:
In case of five consecutive failed login attempts, ZABBIX interface will pause for 60 seconds within next 15 minutes in order to prevent brute force and dictionary attacks.
IP address of a failed login attempt will be displayed after successful login.
After initial installation, ZABBIX has only two users defined. User "Admin" is ZABBIX superuser. User "Admin" has all permissions. User "guest" is a special default user. If an user does not log in, the user will be granted with "guest" permissions. By default, "guest" has read-only permissions.
In order to add new user, press "Create user".
By default, new user has no permissions. Grant user rights.
The user is added.
Select "user groups" from drop-down to edit user group membership.
Click on a group to change membership of the group.
Assign notification methods (medias) to the user. No medias assigned yet.
Configure email address, list of severities for which the media will be active.
Done! You may try to log in.
Initially, ZABBIX has only one notification delivery method (media type) defined, Email. Email configuration can be found under Menu->Configuration->Media types.
Select "Email" from the list of all available media types.
Set correct SMTP server, SMTP helo and SMTP email values. Press "Save" when ready.
Now you have media type "Email" defined. A media type must be linked with users, otherwise it will not be used.
The section provides details about monitoring a host which has ZABBIX agent running. You must have the agent installed and configured properly.
No hosts defined yet.
We have ZABBIX agent running on our ZABBIX server and we want to monitor this server.
Click on "Create host". Enter all required details. We will use standard template Unix_t in order to simplify configuration.
If a template is not used, we should manually add Items and Triggers to the host afterwards.
The host is created and it has exactly the same items and triggers as Unix_t has.
Back to the list of hosts. We see our host in the list.
Let's check if this host has any items to monitor. Menu->Configuration->Items:
Yes! What about triggers? Menu->Configuration->Triggers:
Good. It is time to see what information is available. Go to Menu->Latest data:
It is time to see some graphs. Click on Graph.
.. and finally triggers. Menu->Status of triggers:
All right, the host is under ZABBIX control. After the host is added, we may be interested in:
We have a host or several hosts monitored. We see graphs and status of the hosts. Now it is time to configure basic email notification. Menu->Configuration>Actions
No actions defined yet. Press "Create Action":
If you do not specify any conditions the action will be triggerred if any trigger change its status.
Macro {TRIGGER.NAME} will be substituted by a trigger name. Macro {STATUS} is either ON or OFF depending on current status of the trigger.
The action will be applied to all medias linked to the selected user or user group.
This is very basic setup of notifications. We may be interested in:
ZABBIX Import/Export functionality is created to make possible effective exchange of templates, hosts, items, triggers and graphs configuration parameters.
Exported data has XML format which is easy to read and modify.
Universal XML format make possible integration and data import/export with third party tools and applications.
ZABBIX Import/Export processes the following data:
Menu->Configuration->Export/Import
Select elements for export
We selected host “Template_Linux” all its items and triggers. Press button “Preview” to see list of elements to be exported:
Export data
Press button “Export” to export selected elements to a local XML file with default name zabbix_export.xml. The file has the following format (one element of each type is shown):
<?xml version="1.0"?> <zabbix_export version="1.0" date="11.05.07" time="11.11"> <hosts>
<host name="ZABBIX Server"> <useip>1</useip> <ip>127.0.0.1</ip> <port>10050</port> <status>1</status> <groups> </groups> <items>
<item type="0" key="agent.ping" value_type="3"> <description>Ping to the server (TCP)</description> <delay>30</delay> <history>7</history> <trends>365</trends> <snmp_port>161</snmp_port> <valuemap>Service state</valuemap> <applications>
<application>General</application> </applications> </item>
.... </items> <triggers>
<trigger> <description>Version of zabbix_agent(d) was changed on
{HOSTNAME}</description> <expression>{{HOSTNAME}:agent.version.diff(0)}>0</expression> <priority>3</priority>
</trigger> .... <graphs>
<graph name="CPU Loads" width="900" height="200"> <show_work_period>1</show_work_period> <show_triggers>1</show_triggers> <yaxismin>0.0000</yaxismin> <yaxismax>100.0000</yaxismax> <graph_elements>
<graph_element item="{HOSTNAME}:system.cpu.load[,avg15]"> <color>990000</color> <yaxisside>1</yaxisside> <calc_fnc>2</calc_fnc> <periods_cnt>5</periods_cnt>
</graph_element>
<graph_element item="{HOSTNAME}:system.cpu.load[,avg1]"> <color>009900</color> <yaxisside>1</yaxisside> <calc_fnc>2</calc_fnc> <periods_cnt>5</periods_cnt>
</graph_element>
<graph_element item="{HOSTNAME}:system.cpu.load[,avg5]"> <color>999900</color> <yaxisside>1</yaxisside> <calc_fnc>2</calc_fnc> <periods_cnt>5</periods_cnt>
</graph_element> </graph_elements> </graph> .... </graphs> </host> ....
</hosts> </zabbix_export>
Menu->Configuration->Export/Import
Configure settings for data import and press “Import”.
Pay attention to the following parameters of the item:
PARAMETER Description
Import file File name of XML file.
Rules Element defines element of XML file.
If parameter Update is set for Existing element, then the import will update it with data taken from the file. Otherwise it will not update it.
If parameter Add is set for Missing element, then the import will add new element with data taken from the file. Otherwise it will not add it.
This section contains step-by-step instructions for most common tasks.
This tutorial provides step-by-step instructions how to extend functionality of ZABBIX agent.
Write a script or command line to retrieve required parameter.
For example, we may write the following command in order to get total number of queries executed by a MySQL server:
mysqladmin -uroot status|cut -f4 -d":"|cut -f1 -d"S"
When executed, the command returns total number of SQL queries. Add this command to agent's configuration file. Add the command to zabbix_agentd.conf:
UserParameter=mysql.questions,mysqladmin -uroot status|cut -f4 -d":"|cut -f1 -d"S"
mysql.questions is an unique identifier. It can be any string, for example, queries. Test this parameter by executing: zabbix_agentd -t mysql.questions
Restart ZABBIX agent.
Agent will reload configuration file.
Add new item for monitoring.
Add new item with Key=mysql.questions to the monitored host. Type of the item must be either ZABBIX Agent or ZABBIX Agent (active).
Be aware that type of returned values must be set correctly on ZABBIX server. Otherwise ZABBIX won't accept them.
This tutorial provides step-by-step instructions how to setup monitoring of log files. It is assumed that a host is configured already in ZABBIX frontend.
Configure ZABBIX agent.
Follow standard instructions in order to install and configure agent on monitored host. Make sure that parameter Hostname matches host name of the host configured in ZABBIX frontend.
Also make sure that parameter DisableActive is not set in zabbix_agentd.conf
Add a new item for monitoring of a log file.
Pay attention to the following parameters of the item:
PARAMETER Description
Type Must be set to ‘ZABBIX Agent (active)’.
Key Must be set to ‘log[file<,regexp>]’.
For example: log[/var/log/syslog], log[/var/log/syslog,error]
Make sure that the file has read permissions for user ‘zabbix’ otherwise the item status will be set to ‘unsupported’.
ZABBIX agent will filter entries of log file by the regexp if present.
Type of information Must be set to ‘log’.
Update interval (in sec) The parameter defines how often ZABBIX Agent will check for any changes in the log file. Normally must be set to 1 second in order to get new records as soon as possible.
9.3.Remote actions
This tutorial provides step-by-step instructions how to setup remote execution of pre-defined commands in case on an event. It is assumed that ZABBIX is configured and operational.
Configure new action.
Follow standard instructions in order to configure configure agent on monitored host.
Pay attention to the following parameters of the action:
PARAMETER Description
Action type Must be set to ‘Remote command’.
Remote command Each line must contain an command for remote execution.
For example: host:/etc/init.d/apache restart
Make sure that corresponding agent has EnableRemoteCommands set to 1 in zabbix_agentd.conf.
Remote command may contain macros!
Syntax of remote commands:
REMOTE COMMAND Description
<host>:<command> Command ‘command’ will be executed on host ‘host’.
<group>#<command> Command ‘command’ will be executed on all hosts of host group ‘group’.
Syntax of IMPI remote commands:
REMOTE COMMAND Description
<host>:IPMI <ipmi The syntax is for execution of IMPI command on
control> [value] a single host.
Supported ipmi controls: "reset", "power"
Supported values: "on", "off" or number (1, by default) Examples:
Server restart: host:IPMI reset on
Server reboot:
host:IPMI power off
<group>#IPMI <ipmi The syntax is for execution of IPMI command for
control> [value] all hosts of a host group.
Important notes
Make sure that user 'zabbix' has execute permissions for configured commands. One may be interested in using sudo to give access to priviledged commands. ZABBIX agent executes commands in background ZABBIX does not check if a command has been executed successfully
Restart of Windows on certain condition.
In order to automatically restart Windows in case of a problem detected by ZABBIX, define the following actions:
PARAMETER Description
Action type ‘Remote command’ Remote command host:c:\windows\system32\shutdown.exe –r –f Replace ‘host’ with ZABBIX hostname of Windows server.
9.4.Monitoring of Windows services
This tutorial provides step-by-step instructions how to setup monitoring of Windows services. It is assumed that ZABBIX server and ZABBIX agent are configured and operational.
Get service name
You can get that name by going to the services mmc and bring up the properties of the service you want to monitor it's up/down status. In the General tab you should see a field called Service name. The value that follows that you put in the brackets above. For example, if I wanted to monitor the "workstation" service then my service would be lanmanworkstation.
Add item for monitoring of the service
Add item with a key service_state[lanmanworkstation], value type Integer, value mapping Windows service state.
ZABBIX Escalations is aimed to the following goals:
ZABBIX provides effective and very flexible functionality for escalations and repeated notifications. Depending on configuration, ZABBIX will automatically escalate (increase escalation step) unresolved problems and executed actions assigned to each escalation step.
ZABBIX WEB Monitoring is aimed to the following goals:
ZABBIX provides effective and very flexible WEB monitoring functionality. The module periodically executes WEB scenarios and keeps collected data in the database. The data is automatically used for graphs, triggers and notifications.
The following information is collected per each step of WEB scenario:
ZABBIX also checks if a retrieved HTML page contains a pre-defined string.
ZABBIX WEB monitoring supports both HTTP and HTTPS.
Scenario is set of HTTP requests (steps), which will be periodically executed by ZABBIX server. Normally a scenario is defined for one particular part of functionality of a WEB application. Scenarios are very convenient way of monitoring user experience.
WEB Scenario is linked to a host application for grouping.
WEB Scenario is periodically executed and consists of one or more Steps.
All cookies are preserved during execution of a single scenario.
Monitoring of ZABBIX GUI If we want to monitor availability and performance of ZABBIX GUI, we have to login, check how quickly Overview and Status of Triggers screens work and then logout.
The scenario may have the following steps:
| Parameter | Description |
| Application | WEB scenario will be linked to this application. The application must exist. For example: ZABBIX Server |
| Name | Name of the WEB scenario. The name will appear in Monitoring -> Web For example: ZABBIX GUI |
| Update interval | How often this scenario will be executed, in seconds. For example: 60 |
| Agent | ZABBIX will pretend to be the selected browser. Useful for monitoring of WEB sites which generate different content for different WEB browsers. For example: Opera 9.02 on Linux |
| Status | Active: active scenario, it will be executed Disabled: disabled scenario, it will NOT be executed |
| Variables | List of macros to be used in configuration of the steps. Syntax: {macro}=value The macro {macro} will be replaced by “variable” in Step’s URL and Post variables. For example: {user}=guest {password}=guest |
| Steps | Steps of the scenario. |
As soon as a scenario is created, ZABBIX automatically adds the following items for monitoring and links them to the selected application. Actual scenario name will be used instead of “Scenario”.
| Item | Description |
| Download speed for scenario 'Scenario' | This item will collect information about download speed (bytes per second) of the whole scenario, i.e. average for all steps. Item key: web.test.in[Scenario,,bps] Type: float |
| Failed step of scenario 'Scenario' | This item keeps number of failed step of the scenario. If all steps are executed successfully, 0 is returned. |
| Item key: web.test.fail[Scenario] Type: integer |
These items can be used to create triggers and define notification conditions. Trigger “WEB scenario failed” The trigger expression can be defined as: {host: web.test.fail[Scenario]}.last(0)#0 Do not forget to replace the Scenario with real name of your scenario. Trigger “WEB application is slow” The trigger expression can be defined as: {host: web.test.in[Scenario,,bps]}.last(0)<10000 Do not forget to replace the Scenario with real name of your scenario.
Step is basically a HTTP request. Steps are executed in a pre-defined order.
| Parameter | Description |
| Name | Name of the step. |
| For example: Login | |
| URL | URL |
| For example: www.zabbix.com | |
| Post | HTTP POST variables, if any. |
| Parameter | Description |
| For example: id=2345&userid={user} If {user} is defined as a macro of the WEB scenario, it will be replaced by its value when the step is executed. The information will be sent as is. | |
| Timeout | Do not spend more than Timeout seconds for execution of the step. Actually this parameter defines maximum time for making connection to the URL and maximum time for performing an HTTP request. Therefore, ZABBIX will not spend more than 2xTimeout seconds on the step. For example: 15 |
| Required | The string (given as Posix regular expression) must exist in retrieved content. Otherwise this step fails. If empty, any content will be accepted. For example: Homepage of ZABBIX |
| Status codes | List of HTTP status codes to be considered as success. If retrieved status code is not in the list, this step fails. If empty, any status code is accepted. For example: 200,210 |
As soon as a step is created, ZABBIX automatically adds the following items for monitoring and links them to the selected application. Actual scenario and step names will be used instead of “Scenario” and “Step” respectively.
| Item | Description |
| Download speed for step 'Step' of scenario 'Scenario' | This item will collect information about download speed (bytes per second) of the step. Item key: web.test.in[Scenario,Step,bps] Type: float |
| Response time for step 'Step' of scenario 'Scenario’ | This item will collect information about response time of the step in seconds. Item key: web.test.time[Scenario,Step] Type: float |
| Response code for step 'Step' of scenario 'Scenario’ | This item will collect response codes of the step. Item key: web.test.rspcode[Scenario,Step] Type: integer |
These items can be used to create triggers and define notification conditions.
Trigger “ZABBIX GUI login is too slow”
The trigger expression can be defined as: {zabbix: web.test.time[ZABBIX GUI,Login]}.last(0)>3
Let’s use ZABBIX WEB Monitoring for monitoring of ZABBIX WEB interafce. We want to know if it is available, provides right content and how quickly it works.
So, first we make a login with our user name and password and then we will try to access Configuration->General page.
Add new host application.
This step is not required if you already have a suitable application. You may also want to create a host if one does not exist.
Add new WEB scenario.
We add a new scenario for monitoring of ZABBIX WEB inetrafce. The scenario will execute number of steps.
Note that we also created two macros, {user} and {password}.
Define steps for the scenario. Add steps for monitoring.
Scenario step 1. Note use of macros {user} and {password}.
Scenario step 2.
Save Scenario.
The list of applications and linked scenarios will appear in Monitoring->WEB:
Click on a scenario to see nice statistics:
ZABBIX can be used for cetralised monitoring and analysis of log files. Notifications can be used to warn users when a log file contains certain strings or string patterns.
Monitoring of log files requires ZABBIX Agent running on a host. An item used for monitoring of a log files must have type ZABBIX Agent (Active), its value type must be Log and key set to log[path to log file<,pattern>].
Important notes:
There are several goals of ZABBIX auto-discovery module:
Auto-discovery makes possible use of ZABBIX in rapidly changing environments with no excessive administration.
ZABBIX provides effective and very flexible auto-discovery functionality. ZABBIX auto-discovery is based on the following information:
The actions can be configured to respect host or service uptime and downtime.
Auto-discovery basically consists of two phases: Discovery and Actions.
First, we discover a host or a service, and generate discovery event or several events.
Then we process the events and apply certain actions depending of type of discovered device, IP, its status, up/down time, etc.
ZABBIX periodically scans IP ranges defined in auto-discovery rules. Frequency of the check is configurable for each rule individually. Each rule defines set of service checks to be performed for IP range. Events generated by auto-discovery module have Event Source “Discovery”.
ZABBIX generates the following events:
Event
Service Up Service Down Host Up
Host Down Service Discovered
Service Lost Host Discovered
Host Lost
When generated
Every time ZABBIX detects active service. Every time ZABBIX cannot detect service. If at least one of the services is UP for the
IP. If all services are not responding. If the service is back after downtime or
discovered for the first time. If the service is lost after being up. If host is back after downtime or discovered
for the first time. If host is lost after being up.
For a description of all conditions available for auto-discovery based events see Action conditions.
For a description of all operations available for auto-discovery based events see Operations.
Auto-discovery rule is a rule used by ZABBIX to discover hosts and services. Parameters of auto-discovery rule:
| Parameter | Description |
| Name | Name of the rule. For example, “Local network”. |
| IP range | Range of IP addresses for discovery. It may have the following formats: Single IP: 192.168.1.33 Range of IP addresses: 192.168.1.1-255 List: 192.168.1.1-255,192.168.2.1-100,192.168.2.200 |
| Delay (in sec) | This parameter defines how often ZABBIX should execute this rule. |
| Checks | ZABBIX will use this list of check for discovery of hosts and services. List of supported checks: SSH, LDAP, SMTP, FTP, HTTP, POP, NNTP, IMAP, TCP, ZABBIX Agent, SNMPv1 Agent, SNMPv2 Agent Parameter Ports may be one of following: Single port: 22 Range of ports: 22-45 List: 22-45,55,60-70 |
| Status | Active – the rule is active and will be execute by ZABBIX server Disable – the rule is not active. It won’t be executed. |
Suppose we would like to setup auto-discovery for local network having IP range of 192.168.1.1-192.168.1.255. In our scenario we want to:
Define auto-discovery rule for our IP range.
ZABBIX will try to discover hosts in IP range of 192.168.1.1-192.168.1.255 by connecting to ZABBIX Agents and getting system.uname. A value received from an agent can be used to apply different actions for different operating systems. For example, link Windows boxes to Windows_Template, Linux boxes to Linux_Template.
The rule will be executed every 10 minutes (600 seconds).
When the rule is added, ZABBIX will automatically start discovery and generation of Discovery based events for further processing.
Define an action for adding newly discovered Linux servers.
The action will be activated if:
Define an action for adding newly discovered Windows servers.
Define an action for removing lost servers.
A server will be removed if service “ZABBIX Agent” is Down for more than 24 hours (86400 seconds).
Some of the most used SNMP MIBs are translated automatically to a numeric representation by ZABBIX. For example, ifIndex is translated to 1.3.6.1.2.1.2.2.1.1, ifIndex.0 is translated to 1.3.6.1.2.1.2.2.1.1.0.
The table contains list of the special MIBs.
| Special MIB | Identifier | Description |
|---|---|---|
| ifIndex | 1.3.6.1.2.1.2.2.1.1 | A unique value for each interface. |
| ifDescr | 1.3.6.1.2.1.2.2.1.2 | A textual string containing information about the interface. This string should include the name of the manufacturer, the product name and the version of the hardware interface. |
| ifType | 1.3.6.1.2.1.2.2.1.3 | The type of interface, distinguished according to the physical/link protocol(s) immediately `below' the network layer in the protocol stack. |
| ifMtu | 1.3.6.1.2.1.2.2.1.4 | The size of the largest datagram which can be sent / received on the interface, specified in octets. |
| ifSpeed | 1.3.6.1.2.1.2.2.1.5 | An estimate of the interface's current bandwidth in bits per second. |
| ifPhysAddress | 1.3.6.1.2.1.2.2.1.6 | The interface's address at the protocol layer immediately `below' the network layer in the protocol stack. |
| ifAdminStatus | 1.3.6.1.2.1.2.2.1.7 | The current administrative state of the interface. |
| ifOperStatus | 1.3.6.1.2.1.2.2.1.8 | The current operational state of the interface. |
| ifInOctets | 1.3.6.1.2.1.2.2.1.10 | The total number of octets received on the interface, |
| Special MIB | Identifier | Description | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| including framing characters. | |||||||||||||||
| ifInUcastPkts | 1.3.6.1.2.1.2.2.1.11 | The | number | of | subnetwork | ||||||||||
| unicast packets delivered higher-layer protocol. | to | a | |||||||||||||
| ifInNUcastPkts | 1.3.6.1.2.1.2.2.1.12 | The number of non-unicast (i.e., subnetwork-broadcast or | |||||||||||||
| subnetwork-multicast) packets delivered to a higher-layer protocol. | |||||||||||||||
| ifInDiscards | 1.3.6.1.2.1.2.2.1.13 | The number of inbound packets which were chosen to be | |||||||||||||
| discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space. | |||||||||||||||
| ifInErrors | 1.3.6.1.2.1.2.2.1.14 | The number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol. | |||||||||||||
| ifInUnknownPr otos | 1.3.6.1.2.1.2.2.1.15 | The number of packets received via the interface which were | |||||||||||||
| discarded | because | of | an | ||||||||||||
| unknown protocol. | or | unsupported | |||||||||||||
| ifOutOctets | 1.3.6.1.2.1.2.2.1.17 | The | total | number | of | octets | |||||||||
| transmitted out of the interface, including framing characters. | |||||||||||||||
| ifOutNUcastPkt s | 1.3.6.1.2.1.2.2.1.18 | The total number of packets that higher-level protocols requested be transmitted to a subnetwork | |||||||||||||
| unicast address, including those that were discarded or not sent. | |||||||||||||||
| ifOutDiscards | 1.3.6.1.2.1.2.2.1.19 | The number of outbound packets which were chosen to be | |||||||||||||
| discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space. | |||||||||||||||
| ifOutErrors | 1.3.6.1.2.1.2.2.1.20 | The number of outbound packets that could not be transmitted | |||||||||||||
| because of errors. | |||||||||||||||
| Copyright 2008 ZABBIX SIA | Page 181 of 320 | ||||||||||||||
A special syntax for item OID can be used in order to deal with dynamic data (random IDs of network interfaces, etc).
The syntax:
<base OID of data>[“index”,”<base OID of index>”,”<string to search for>”]
For example, to get the ifInOctets value for the GigabitEthernet0/1 interface on a Cisco device, yo may following OID:
ifInOctets[“index”,”ifDescr”,”GigabitEthernet0/1”]
| Parameter | Description |
| base OID of data | Base OID to use for data retrieval. |
| index | Method of processing. Currently one method is supported: index – search for index and append it to the base OID |
| base OID of index | The OID will be used to make a lookup for the string. |
| string to search for | The string is used for exact match with a value when doing lookup. Case sentitive. |
Another example, getting memory usage of apache process:
HOST-RESOURCES-MIB::hrSWRunPerfMem[“index”,”HOST-RESOURCESMIB::hrSWRunPath”, “/usr/sbin/apache2”]
...
HOST-RESOURCES-MIB::hrSWRunPath.5376 = STRING: "/sbin/getty" HOST-RESOURCES-MIB::hrSWRunPath.5377 = STRING: "/sbin/getty"
HOST-RESOURCES-MIB::hrSWRunPath.5388 = STRING: "/usr/sbin/apache2"
HOST-RESOURCES-MIB::hrSWRunPath.5389 = STRING: "/sbin/sshd" ...
Now we have index, 5388. The index will be appended to the Data OID in order to receive value we are interested in:
HOST-RESOURCES-MIB::hrSWRunPerfMem.5376 = INTEGER: 528 KBytes
HOST-RESOURCES-MIB::hrSWRunPerfMem.5377 = INTEGER: 528 KBytes
HOST-RESOURCES-MIB::hrSWRunPerfMem.5388 = INTEGER: 31468 KBytes
HOST-RESOURCES-MIB::hrSWRunPerfMem.5389 = INTEGER: 31740 KBytes HOST-RESOURCES-MIB::hrSWRunPerfMem.5390 = INTEGER: 32116 KBytes HOST-RESOURCES-MIB::hrSWRunPerfMem.5391 = INTEGER: 30420 KBytes HOST-RESOURCES-MIB::hrSWRunPerfMem.5392 = INTEGER: 32560 Kbytes
Use dynamic indexes with care as it leads to more SNMP queries. ZABBIX does not perform caching, so the lookup is performed anytime the item value is retrieved.
There are several goals of ZABBIX IPMI monitoring:
Remote restart, shutdown, halt, and other commands can be executed either automatically or manually from ZABBIX front-end.
ZABBIX IPMI monitoring works only for devices having IPMI support (HP iLO, Sun hardware, etc).
In order to use IMPI monitoring, a host must be configured to process IPMI commands. IPMI agent's IP address, port number, user name and password must be configured properly.
See configuration of hosts for more details.
Two types of actions can be defined:
ZABBIX Proxies may greatly simplify maintenance of ZABBIX environment and increase performance of central ZABBIX server.
Also, use of ZABBIX Proxies is the easiest way of implementing centralized and distributed monitoring, when all Agents and Proxies report to one ZABBIX server and all data is collected centrally.
ZABBIX Proxy can be used for many purposes:
When making a choice between use of a Proxy or a Node, several considerations must be taken into account.
| Lightweight |
|---|
| GUI |
| Works independently |
| Easy maintenance |
| Automatic DB creation |
| Local administration |
| Ready for embedded hardware |
| One way TCP connections |
| Centralised configuration |
| Generates notifications |
No
No
No
No
Yes
No
Node
Yes
Yes
Yes
Yes
No
No
No
Proxy Yes
Yes
Yes
Yes
Yes
Yes
Yes
Every host can be monitored either by ZABBIX Server or by ZABBIX Proxy. This is configured in host definition screen:
If a host is configured to be monitored by a Proxy, the Proxy will perform gathering of performance and availability data for the host. The data will be collected by the Proxy and sent to ZABBIX Server for further processing.
ZABBIX can be configured to support hierarchical distributed monitoring.
There are several goals of the distributed monitoring:
Monitoring thousands of hosts using single ZABBIX server? This may be for you!
ZABBIX provides effective and reliable way of monitoring distributed IT infrastructure. Configuration of the whole distributed setup can be done from a single location via common WEB interface.
ZABBIX supports up-to 1000 (one thousand) Nodes in a distributed setup. Each Node is responsible for monitoring of its own Location. Node can be configured either locally or by its Master node which has a copy of configuration data of all Child Nodes. Configuration of Child Nodes can be done in off line mode, i.e. when there are no connectivity between Master and Child Node.
Hierarchical distributed monitoring allows having tree-like structure of Nodes. Each Node reports to its Master Node only.
All Nodes may work even in case of communication problems. Historical information and events are stored locally. When communication is back, Child Nodes will optionally send the data to Master Node.
New Nodes can be attached to and detached from the ZABBIX distributed setup without any loss of functionality of the setup. No restart of any Node required.
Each Node has its own configuration and works as a normal ZABBIX Server.
17.3.1.Configuration of Nodes
Parameters of a Node:
| Parameter | Description |
| Name | Unique node name. |
| Id | Unique Node ID. |
| Type | Local – Local node Remote – Remote node |
| Time zone | Time zone of the Node. ZABBIX automatically converts time stamps to local timezone when transferring time related data across nodes. |
| IP | Node IP address. ZABBIX trapper must be listening on this IP address. |
| Port | Node Port number. ZABBIX trapper must be listening on this port number. Default is 10051. |
| Do not keep history older than (in sec) | For non local historical data only. ZABBIX won’t keep history of the node longer than N seconds. |
| Do not keep trends older than (in sec) | For non local trend data only. ZABBIX won’t keep trends of the node longer than N seconds. |
Our simple configuration consists of a Central Node and a Child One.
Central Node will have total control over configuration of Child Node. ChildNode will report to central node events, history and trends. Central Node will have NodeID=1, while Child Node’s NodeID=2. Central Node IP: 192.168.3.2, Port: 10051 Child Node IP: 192.168.3.5, Port: 15052
For Central Node:
Install ZABBIX.
Follow standard installation instructions to create database, install ZABBIX frontend and binaries. Setup NodeID in server configuration file. In file zabbix_server.conf:
NodeID=1
Convert database data.
ZABBIX server has to be executed to covert unique IDs for use by first node.
cd bin ./zabbix_server -n 1 -c /etc/zabbix/zabbix_server.conf Converting tables .................................................................. done.
Conversion completed.
Note: This should be executed only once. This option is not required to start ZABBIX server!
Configure Node parameters.
Add child node.
Start Master Node.
We should see NodeID in stratup messages of server log file:
31754:20070629:150342 server #16 started [Node watcher. Node ID:1]
For Child Node:
Install ZABBIX.
Follow standard installation instructions to create database, install ZABBIX frontend and binaries. Setup NodeID in server configuration file. In file zabbix_server.conf:
NodeID=2
Convert database data.
ZABBIX server has to be executed to covert unique IDs for use by first node.
cd bin ./zabbix_server -n 2 -c /etc/zabbix/zabbix_server.conf Converting tables .................................................................. done.
Conversion completed.
Note: This should be executed only once. This option is not required to start ZABBIX server!
Configure Node parameters.
Add master node.
Start Child Node.
We should see NodeID in stratup messages of server log file:
27524:20070629:150622 server #9 started [Node watcher. Node ID:2]
Does it work?
Selection of active nodes will appear automatically after nodes are defined:
Add host for monitoring for Child Node node and see events coming to Master Node:
The setup consists of seven Nodes. Each Node may be configured either locally (using local WEB interface) or from one of its Master Nodes.
In this example, Riga (node 4) will collect events from all child nodes. It may also optionally collect historical information as well.
A node may use its own platform (OS, hardware) and database engine independently of other nodes. Also child nodes can be installed without ZABBIX frontend.
It may be practical to use less powerful hardware with ZABBIX Server running SQLite or MySQL MyISAM while nodes of higher levels may use combination of a better hardware with MySQL InnoDB, Oracle or PostgreSQL backend.
Every Node in distributed environment must be properly configured to have a unique Node ID.
Additional steps
Follow standard installation procedure.
Follow standard installation procedure but do not start ZABBIX Server. ZABBIX front end must be installed and configured. ZABBIX database must be created and populated with data from data.sql.
Configure zabbix_server.conf.
Add NodeID to ZABBIX Server configuration file. NodeID must be a unique Node ID.
Configure Master and Child Nodes.
Use ZABBIX Frontend to configure details of Nodes having direct communication with the Node. Make sure that all IP addresses and port numbers are correct.
Start ZABBIX Node.
Start ZABBIX Server:
shell> ./zabbix_server
If everything was configured properly, ZABBIX node will automatically start configuration and data exchange with all nodes in distributed setup. You may see the following messages in server log file:
...
11656:20061129:171614 NODE 2: Sending data of node 2 to node 1 datalen 3522738 11656:20061129:171614 NODE 2: Sending data of node 2 to node 1
datalen 20624 ...
When connecting to a node in distributed setup, a list of available child nodes is accessible in right-upper corner of the GUI. It displays current node.
All information available in the GUI belongs to the selected node.
Each Child Node periodically sends configuration changes, historical data and events to its Master Node.
| Data | Frequency |
| Configuration changes | Every 120 seconds. |
| Events | Every 10 seconds. |
| History | Every 10 seconds. |
Child Node will resend data in case of communication problems. Trends are calculated locally based on received historical data. ZABBIX does not send operational data across the nodes. For example, item-
related information (last check, last value, etc) exists only locally.
Note: Sending of Events and History can be controlled by configuration parameters NodeNoEvents and NodeNoHistory.
Each Master Node (a node with at least one child) periodically sends configuration changes to Child Nodes either directly or via other Child Nodes directly connected to the Master Node.
| Data | Frequency |
| Configuration changes | Every 120 seconds. |
ZABBIX does not send configuration of a Master Node to Childs.
Inter-node communications use TCP protocol only.
| Data flow | Source port | Destination port | |
| Child | to | Any | 10051 |
| Master | |||
| Master Child | to | Any | 10051 |
This is default port used by ZABBIX trapper process.
Any node requires more processing resources in a distributed setup. Master Node must be powerful enough to process and store not only local data but also data received from its all Child Nodes. Network communications must be also fast enough for timely transfer of new data.
ZABBIX GUI can be temporarily disabled in order to prohibit access to the front-end. This can be useful for protection of ZABBIX database from any changes initiated by users, thus protecting integrity of database.
ZABBIX database can be stopped while ZABBIX GUI is in the maintenance mode.
There are several goals of the maintenance mode:
In order to enable maintenance mode, file conf/maintenance.conf.php must be modified to uncomment the following lines:
// Maintenance mode define('ZBX_DENY_GUI_ACCESS',1);
// IP range, who allowed to connect to FrontEnd $ZBX_GUI_ACCESS_IP_RANGE = array('127.0.0.1');
// MSG showed on Warning screen! $_REQUEST['warning_msg'] = 'ZABBIX is under maintenance.';
| Parameter | Details |
| ZBX_DENY_GUI_ACCESS | Enable maintenance mode: 1 – maintenance mode is enabled, disabled otherwise |
| ZBX_GUI_ACCESS_IP_RANGE | Connections from these IP addresses will be allowed with no maintenance mode. For example: 192.168.1.1-255 |
| warning_msg | Informative message. |
The following screen will be displayed while in maintenance mode. The screen is refreshed every 30 seconds in order to return to normal state withiout user intervention when maintenance is over.
There are several useful features of ZABBIX WEB interface:
By default, ZABBIX provides number of predefined themes. You may follow this step-by-step procedure in order to create your own. Feel free to share result of your work with ZABBIX community if you created something nice.
Create your own CSS file.
The file can be based on existing CSS files coming with ZABBIX. For example, you may take Black&Blue CSS file from styles/css_bb.css and create new css_new.css.
Place the new CSS file into correct location.
The file you created, css_new.css, into directory styles/.
Edit include/forms.inc.php.
Open this file for editing, search for css_bb.css. There are two pieces of code that have to be amended. Original code:
$cmbTheme = new CComboBox('theme',$theme); $cmbTheme->AddItem(ZBX_DEFAULT_CSS,S_SYSTEM_DEFAULT); $cmbTheme->AddItem('css_ob.css',S_ORIGINAL_BLUE); $cmbTheme->AddItem('css_bb.css',S_BLACK_AND_BLUE);
Modified code:
$cmbTheme = new CComboBox('theme',$theme); $cmbTheme->AddItem(ZBX_DEFAULT_CSS,S_SYSTEM_DEFAULT); $cmbTheme->AddItem('css_ob.css',S_ORIGINAL_BLUE);
$cmbTheme->AddItem('css_bb.css',S_BLACK_AND_BLUE);
$cmbTheme->AddItem('css_new.css','MY_COOL_THEME');
Activate new theme.
In ZABBIX GUI, you may either set this theme to be a default one or change your theme in user profile.
Enjoy new look and feel!
The screen defines event related settings.
Configuration parameters:
| Parameter | Description |
| Event acknowledges | This parameter defines if event acknowledges are activated in ZABBIX interface. |
| Show events no older (Days) | This parameter defines for how many days event are displayed in Status of Triggers screen. Default is 7 days. |
| Mac count of events per trigger to show | Maximum number of event to show for each trigger in Status of Triggers screen. Default is 100. |
The Housekeeper is a periodical process which is executed by ZABBIX Server. The process removes outdated information and information deleted by user.
Configuration parameters:
| Parameter | Description |
|---|---|
| Do not keep actions older than (in days) | This parameter defines how many days of executed actions (emails, jabber, SMS, etc) history ZABBIX will keep in the database. Older actions will be removed. |
| Do not keep events older than (in days) | This parameter defines how many days of events history ZABBIX will keep in the database. Older events will be removed. |
List of images
Image definition
ZABBIX images are stored in the database. There are two types of images:
Icons are used in for displaying System Map elements. Backgrounds are used as background images of System Maps. Image attributes:
| Parameter | Description |
| Name | Unique name of an image. |
| Type | Either Icon or Background |
| Upload | Name of local file (PNG, JPEG) to be uploaded to ZABBIX |
Note: Note that you may upload image of any size, however images bigger than 1.5MB may not be displayed in maps. Increase value of max_memory_size in php.ini if you have this problem.
ZABBIX support themes, which are used to customize look and feel of ZABBIX front-end.
Possible parameters:
| Parameter | Description |
| Default theme | Theme used for all users. Default theme is “Original blue”. An user may override the default theme in user profile. |
Value maps are used to create a mapping between numeric values and string representations.
Value mappings are used for representation of data in both ZABBIX front-end and information sent by email/jabber/SMS/whatever.
For example, an item which has value ‘0’ or ‘1’ can use value mapping to represent the values in a human readable form: ‘0’ => ‘Not Available’ ‘1’ => ‘Available’
Note: Value mapping can be used only for items having type ‘Unsigned integer’.
Value mapping definition
Parameters of a value mapping:
| Parameter | Description |
|---|---|
| Name | Unique name of set of value mappings. |
| Mapping | Set of mappings. |
| New mapping | Single mapping for addition. |
Working time is system-wide parameter which defines working time.
Currently this is used for graphs only. Working time is displayed as a white background, while non-working time is displayed as grey.
Working time has the following format:
dd-dd,hh:mm-hh:mm;dd-dd,hh:mm-hh:mm,…
| FORMAT | DESCRIPTION |
| dd | Day of week: |
| 1 – Monday, 2 – Tuesday ,… , 7 – Sunday | |
| hh | Hours: 00-24 |
| mm | Minutes: 00-59 |
Empty format is equal to 01-07,00:00-23:59
For example: 1-5,09:00-18:00
1-5,09:00-18:00;6-7,10:00-16:00
Refresh unsupported items
Some items may become unsupported due to errors in User Parameters or possible an item is not supported by an agent.
ZABBIX can be configured to periodically make unsupported items active.
Database watchdog
Availability of ZABBIX server depends on availability of back-end database very much. It cannot work without a database.
Database watchdog, a special ZABBIX server process, is created in order to alarm ZABBIX administrators in case of disaster.
The watchdog will send notifications to a user group in case if the database is down. ZABBIX server will not stop; it will wait until the database is back again to continue processing.
| Parameter | Description |
| Refresh unsupported items (in sec) | ZABBIX will activate unsupported item every N seconds. If set to 0, the automatic activation will be disabled. Proxies check unsupported items every 10 minutes. This is not configurable for Proxies. |
Parameter
Description User group for
User group for sending alarm message or ‘None’. database down message
Note: Database watchdog is supported for MySQL only!
The screen can be used to manage monitoring of WEB scenarios.
List of WEB scenarios
It provides list of active WEB scenarios.
Displayed data:
| Parameter | Description |
| Name | Unique name of a WEB scenario. |
| Number of steps | Number of individual steps (HTTP requests) the scenario consists of. |
| Update interval | Frequency of execution of the WEB scenario. |
| Parameter | Description |
| Status | Status of the scenario: |
| Active – the scenario is active | |
| Disabled – the scenario is disabled. Note that disabled | |
| scenarios are not displayed by default. |
WEB scenarios configuration
The screen is used to define parameters of an individual WEB scenario.
Configuration parameters:
| Parameter | Description |
| Application | Host application the scenario is linked to. |
| Name | Unique name of the WEB scenario. |
| Update interval (in sec) | Frequency of execution of the WEB scenario. |
| Agent | Client agent string. ZABBIX will pretend that it is Firefox, MS Explorer or any other application. Useful when WEB site returns different content for different browsers. |
| Status | Status of the scenario: |
Parameter
Description Active – the scenario is active Disabled – the scenario is disabled. Note that disabled
scenarios are not displayed by default.
List of variables (macros) that can be used in scenario steps (URL and Post variables). It has the following format: {macro1}=value1 {macro2}=value2 For example: username=Alexei
password=kj3h5kJ34bd The macros can be referenced as {username} and {password}. ZABBIX will automatically replace them with actual values.
Variables
List of steps executed by the scenario: Name – step name Timeout – timeout URL – location to connect to Required – required string Status – step status
Steps WEB step configuration
The screen is used to define parameters of each individual step of the WEB scenario.
Configuration parameters:
| Parameter | Description |
| Name | Unique step name. |
| URL | URL to connect and retrieve data. For example: http://www.zabbix.com https://www.google.com |
| Post | List of POST variables. GET variables can be passed in the URL parameter. |
| Timeout | ZABBIX will not spend more than Timeout second on processing the URL. |
| Required | Required string. Retrieved content (HTML) must contain this string, otherwise the step will fail. If empty, no check is performed. |
| Status codes | List of expected HTTP codes. If ZABBIX get a code, which is not in the list, the step will fail. If empty, no check is performed. For example: 200,201,210-299 |
The screen is used to manage host related information.
List of Hosts
The screen provides list of monitored hosts..
Displayed data:
| Parameter | Description |
| Name | Unique host name. |
| DNS | Host DNS name if used. |
| IP | Host IP address if used. |
| Port | ZABBIX Agent port number. It is ignored by ZABBIX if no agent used. |
| Templates | List of templates linked to the host. |
| Status | Host Status: |
| Parameter | Description |
| Monitored – Host is active and being monitored Disabled – Host disabled | |
| Availability | Agent (Zabbix, SNMP) availability: Available – agent is up and running Unknown – agent is not available |
| Error | Any errors related to use of agent based checks. |
Host mass-update screen
The screen is accessible by selecting hosts and clicking on button “Mass update”. It is very effective way of changing attributes of a number of hosts.
Host configuration
The screen give access to host details.
Configuration parameters:
| Parameter | Description |
| Name | Unique host name. |
| Groups | List of host groups the host belongs to. |
| New group | New group can be created and linked to the host. Ignored, if empty. |
| DNS name | Optional host DNS name. |
| IP address | Optional host IP address. |
| Connect to | ZABBIX server will use this setting to retrieve data from agents: DNS name – Connect to host DNS name IP address – Connect to host IP (recommended) |
| Port | ZABBIX agent TCP port number. Default value is 10050. |
| Monitored by proxy | The host can be monitored either by ZABBIX Server or one of Proxies: (no proxy) – host is monitored by ZABBIX Server Proxy name – host is monitored by Proxy “Proxy |
| Parameter | Description |
| name” | |
| Status | Host status: |
| Monitored – Host is active ,ready to be monitored | |
| Not monitored – Host is not active, thus not monitored | |
| Link with template | Link host with one or more templates. Information about |
| items, triggers and graphs will be inherited from the | |
| templates. | |
| Unlink – unlink from template, but reserve information | |
| about items, triggers and graphs | |
| Unlink and clear – unlink from template and remove all | |
| information inherited from the template | |
| Use IPMI | Enable IMPI management functionality for this host. |
| IPMI IP address | IP address of IPMI management device. |
| IPMI port | Port number of the IPMI device. |
| IPMI privilege level | Keep default setting here, User. |
| IPMI username | User name for authentication. |
| IPMI password | Password for authentication. |
| Use profile | Enable or disable use of Host profile. |
| Use extended profile | Enable or disable use of extended Host profile. |
The screen is used to manage host templates.
List of Templates
The screen provides list of templates.
Displayed data:
| Parameter | Description |
|---|---|
| Name | Template name. |
| Templates | List of hosts linked to this template. |
Template configuration
The screen give access to template details.
Configuration parameters:
| Parameter | Description |
| Name | Unique template name. |
| Groups | List of host groups the template belongs to. |
| New group | New group can be created and linked to the template. Ignored, if empty. |
| Link with template | Link template with one or more templates. Information about items, triggers and graphs will be inherited from the templates. |
The screen is used to manage proxies.
List of Proxies
The screen provides list of proxies.
Displayed data:
| Parameter | Description |
| Name | Unique Proxy name. |
| Last seen (age) | Last time we received a heart beat message or data from the Proxy. |
| Members | List of hosts monitored by this Proxy. |
Proxy configuration
The screen give access to proxy details.
Configuration parameters:
| Parameter | Description |
| Proxy name | Unique Proxy name. |
| Hosts | List of hosts monitored by this Proxy. |
The screen is used to manage host groups.
List of Host Groups.
The screen provides list of host groups..
Displayed data:
| Parameter | Description |
|---|---|
| Name | Host Group name. |
| # | Number of group members (hosts). |
| Members | List of host group members. |
Host group configuration
The screen give access to host group details.
Configuration parameters:
| Parameter | Description |
| Group name | Unique host group name. |
| Hosts | List of hosts, members of the group. |
The screen is used to manage host template linkage.
List of Templates
The screen provides list of template and linked hosts.
Displayed data:
| Parameter | Description |
| Templates | Host template name. |
| Hosts | List of hosts linked to the template. |
Template linkage
The screen give access to management of host template linkage.
Configuration parameters:
| Parameter | Description |
| Template | Template name. |
| Hosts | List of hosts linked to the template. |
The screen is used to manage applications.
List of Applications
The screen provides list of applications.
Displayed data:
| Parameter | Description |
| Application | Application name. |
| Show | Link to host items, also displays number of items (members of the application). |
Configuration of application
The screen give access to management of applications.
Configuration parameters:
| Parameter | Description |
|---|---|
| Name | Application name. Must be unique within one host. |
| Hosts | Host name the application is linked to. |
The screen is used to manage item related information.
List of Items
The screen provides list of items linked to a host.
Displayed data:
| Parameter | Description |
| Description | Item description (name). |
| Key | Unique item key. |
| Update interval | Frequency of the check. |
| History | Number of days ZABBIX keeps detailed historical data. |
| Trends | Number of days ZABBIX keeps trends data. |
| Type | Item type. |
| Status | Item status. |
| Applications | List of applications the item belongs to. |
| Error | Any errors related to this item. |
Item mass-update screen
The screen is accessible by selecting items and clicking on button “Mass update”. It is very effective way of changing attributes of a number of items.
Click on a parameter you would like to change, enter new value and press “Save”.
Copy selected to...
The screen makes possible copy of a selected item to a number of hosts.
Select hosts you would like to copy items and press “Copy”.
Item configuration
The screen provides access to configuration of a single item.
Item attributes:
| Parameter | Description |
| Description | Item description. It may contain macros: $1 – first parameter of item key $2 – second parameter $N -Nth parameter For example: Free disk space on $1 If item key is “vfs.fs.size[/,free]”, the description will be automatically changed to “Free disk space on /” |
| Type | Item type. See sections below for detailed description of each type. |
| Key | Item key. The key must be unique within a single host. For The key value must be supported by an agent or ZABBIX server, if key type is ZABBIX Agent, ZABBIX Agent (active), Simple check, or ZABBIX aggregate. |
| Type of information | Type of received data. Numeric (integer 64bit) – 64bit unsigned integer Numeric (float) – floating point number Character – character (string) data limited to 255 bytes |
| Parameter | Description | ||||
|---|---|---|---|---|---|
| Log – log file. Must be set for keys log[]. | |||||
| Text – text of unlimited size | |||||
| Data type | The data type is used for integer items in order to specify expected data type. | ||||
| Decimal – data in decimal format | |||||
| Octal – data in octal format | |||||
| Hexadecimal – data in hexadecimal format | |||||
| Zabbix will numeric. | automatically | perform | conversion | to | |
| This is supported starting from version 1.8. | |||||
| Units | If set, ZABBIX will add prefix K,M or G if required and the unit postfix to all received values (1024 is 1K). | ||||
| For example, if units set to ‘B’, ZABBIX will display: | |||||
| 1 as 1B | |||||
| 1024 as 1KB | |||||
| 1536 as 1.5KB | |||||
| Some units have special processing: | |||||
| b, bps -1000 is 1K, special processing for bits. | |||||
| unixtime – translated to “yyyy.mm.dd hh:mm:ss” | |||||
| uptime – translated to “hh:mm:ss” or “N days, hh:mm:dd”, parameter is treated as number of seconds since 01/01/1970. | |||||
| s – translated to “yyymmmdddhhhmmm”, parameter is treated as number of seconds since 01/01/1970. For example, 2y10m14d3h54m1s | |||||
| Use multiplier | Pre-process received values. | ||||
| Do not use -do not pre-process received values | |||||
| Custom multiplier – multiply received values by value defined in Custom multiplier | |||||
| Use this option to convert values received in KB, MBps, etc into B, Bps. Otherwise ZABBIX cannot correctly set prefixes (K, M and G). | |||||
| Custom multiplier | Multiply all received value by this integer or floating-point value. | ||||
| Update interval (in sec) | Refresh this item every N seconds. | ||||
| Flexible intervals | List of exceptions for Update Interval. For example: | ||||
| 10 sec, 1-5,09:00-18:00 – refresh set to 10 seconds for working hours. Otherwise default update interval will be | |||||
| Copyright 2008 ZABBIX SIA | Page 235 of 320 | ||||
Parameter Description
used. Period format: dd-dd,hh:mm-hh:mm;dd-dd,hh:mm-hh-mm For example, 1-5,09:00-18:00;6-7,10:00-12:00 1-Monday, …,7 -Sunday
Keep detailed history N days in the database. Older data will be removed by Housekeeper.
Keep history (in days)
Keep aggregated (hourly min,max,avg,count) detailed history N days in the database. Older data will be removed by Housekeeper.
Keep trends (in days)
Status
Active -active (normal) status. ZABBIX will process this item.
Disabled – item is disabled. This item will not be processed.
Not supported – item is not supported by ZABBIX or SNMP agent. This item will not be processed, however ZABBIX may try to periodically set status of such items to Active if configured.
Store value
As is – no pre-processing
Delta (speed per second) – evaluate value as (valprev_value)/(time-prev_time), where value – current value value_prev – previously received value time – current timestamp prev_time – timestamp of previous value This setting is extremely useful to get speed per second
based on constantly growing value.
Delta (simple change) – evaluate as (valueprev_value), where value – current value value_prev – previously received value
Apply value mapping to this item. Value mapping does not change received values, it is for displaying data only.
It works with integer items only.
For example, “Windows service states”.
Show value
Link item to one or more applications.
Applications
See more details about items in other sections of the Manual.
The screen is used to manage triggers.
List of Triggers
The screen provides list of triggers linked to a host.
Displayed data:
| Parameter | Description |
| Severity | Colored trigger severity. |
| Status | Trigger status. Note that Disable status are hidden by default. |
| Name | Trigger name. |
Trigger mass-update screen
The screen is accessible by selecting triggers and clicking on button “Mass update”. It is very effective way of changing attributes of a number of triggers.
Click on a parameter you would like to change, enter new value and press “Save”.
Copy selected to...
The screen makes possible copy of a selected trigger to a number of hosts.
Select hosts you would like to copy items and press “Copy”.
Trigger configuration
The screen provides access to configuration of a single trigger.
Trigger attributes:
| Parameter | Description |
| Name | Trigger name. The name may contain macros. |
| Expression | Logical expression used for calculation of trigger state. |
| The trigger depends on | List of triggers the trigger depends on. |
| New dependency | Add new dependency. |
| Event generation | Normal – events are generated normally, on TRIGGER status change Normal + Multiple TRUE events – events are also generated on every TRUE evaluation of the trigger |
| Severity | Trigger severity. |
| Comments | Text field used to provide more information about this trigger. May contain instructions for fixing specific problem, contact detail of responsible staff, etc. |
| URL | If not empty, the URL is used in the screen ‘Status of Triggers’. |
| Disabled | Trigger can be disabled if required. |
See more details about triggers in other sections of the Manual.
The screen is used to manage actions.
List of Actions
The screen provides list of actions.
Displayed data:
| Parameter | Description |
| Name | Action name. |
| Conditions | List of conditions for this action. |
| Operations | List of operations for execution. |
| Status | Status of the action. |
Action configuration
The screen provides access to configuration of a single action.
More configuration options are available If escalation is enabled:
See more details about configuration of actions, conditions and operations in other sections of the Manual.
The screen is used to manage custom graphs.
List of Graphs
The screen provides list of graphs.
Displayed data:
| Parameter | Description |
| Name | Graph name. |
| Width | Graph width in pixels. |
| Height | Graph height in pixels. |
| Graph type | Graph type: Normal Stacked Pie Pie exploded |
Graph configuration
The screen provides access to configuration of a single custom graph.
Graph attributes:
| Parameter | Description |
| Name | Unique graph name. |
| Width | Graph width in pixels. |
| Height | Graph height in pixels. |
| Graph type | Graph type: Normal – normal graph, values displayed as lines. Stacked – stacked graph. Pie – pie graphs. Exploded – exploded pie graph. |
| Show working time | If selected, non-working hours will be shown with gray background. |
| Show triggers | If selected, simple triggers will be displayed as red lines. |
| Percentile line (Left) | Display percentile for left Y axis. Normally used for displaying 95% percentile. |
| Percentile line (Right) | Display percentile for right Y axis. Normally used for displaying 95% percentile. |
| Comments | Text field used to provide more information about this trigger. May contain instructions for fixing specific |
| Parameter | Description |
| problem, contact detail of responsible staff, etc. | |
| Y axis type | Type of Y axis: Calculated – Y axis value will be automatically calculated Calculated [min=0] – Y min value is set to 0, maximum value will be automatically calculated. Fixed – fixed min and max value for Y axis. |
| 3D view | Enable 3D style. For Pie graphs only. |
| Legend | Display legend. For Pie graphs only. |
| Items | List of graph elements (items) to be displayed for this graph. |
Graph element:
Attributes of a graph element:
| Parameter | Description |
| Parameter | Selection if host item, which will be displayed. |
| Type | Type: Simple |
| Parameter Description |
|---|
| Aggregated |
| Function What values will be displayed, used when more than |
| one value exists for a single pixel (X-coordinate): |
| All – all (minimum, average and maximum) |
| Min – minimum only |
| Avg – average only |
| Max – maximum only |
| Draw style Draw style: |
| Line – draw lines |
| Filled region – draw filled region |
| Bold line – draw bold lines |
| Dot – draw dots |
| Dashed line – draw dashed line |
| Color RGB color in HEX notation. |
| Aggregated periods |
| count |
| Y axis side What Y axis side the element is assigned to. |
| Sort order (0->100) Draw order, 0 will be processed first. |
The screen is used to manage screens.
List of Screens
The screen provides list of screens.
Displayed data:
| Parameter | Description | ||
| Name | Screen name. | ||
| Dimension rows) | (cols | x | Screen size, number of columns and rows. |
Screen configuration (high-level)
The screen provides access to configuration of a single screen.
Screen high-level attributes:
| Parameter | Description |
| Name | Unique screen name. |
| Columns | Number of columns in the screen. |
| Rows | Number of rows in the screen. |
Screen configuration (screen elements)
The screen provides access to configuration of a single screen giving access to configuration of all elements.
Click on a screen element (cell) to change what information should be displayed in the screen cell.
Screen high-level attributes:
| Parameter | Description |
| Resource | Information displayed in the cell: Clock – digital or analog clock displaying current server or local time Data overview – latest data for a group of hosts Graph – single custom graph History of actions – history of recent actions History of events – latest events Hosts info – high level host related information Map – single map Plain text – plain text data Screen – screen (one screen may contain other screens inside) Server info – server high-level information Simple graph – single simple graph Triggers info – high level trigger related information Triggers overview -status of triggers for a host group URL – include content from an external resource |
| Horizontal align | Possible values: Center Left Right |
| Vertical align | Possible values: Middle Top Bottom |
| Column span | Extend cell to a number of columns, same way as HTML column spanning works. |
| Row span | Extend cell to a number of rows, same way as HTML row spanning works. |
The screen is used to manage user-defined maps.
List of Maps
The screen provides list of maps.
Displayed data:
| Parameter | Description |
| Name | Map name |
| Width | Map width in pixels. |
| Height | Map height in pixels. |
Map configuration (high-level)
The screen provides access to configuration of a user-defined screen.
Map high-level attributes:
| Parameter | Description |
| Name | Unique map name. |
| Width | Map width in pixels. |
| Height | Map height in pixels. |
| Background image | Use background image: No image – no background image (white background) Image – selected image to be used as a background image. No scaling is performed. |
| Icon label type | Label type used for all map icons: Label – icon label only IP address – IP addressonly Element name – element name (for example, host name) Status only – status only (OK or PROBLEM) Nothing -no icon labels are displayed |
| Icon label location | Display icon label on: Bottom – bottom (under the icon) |
Parameter
Description Left – left side Right – right side Top – top of the icon
Map configuration (configuration of map elements)
The screen provides access to configuration of map icons and links. List of map elements (icons):
List of links:
Configuration of map element
The screen provides access to configuration of a single map element.
Map element attributes:
| Parameter | Description |
| Type | Type of the element: Host – icon representing status of all triggers of the selected host Map – icon representing status of all elements of a map Trigger – icon representing status of a single trigger Host group – icon representing status of all triggers of all hosts belonging to Image – just an icon not linked to any resources |
| Label | Icon label, any string. Macros and multi-line string can be used in labels starting from version 1.8 |
| Label location | Label location: Default – Map's default label location Bottom – bottom (under the icon) Left – left side Right – right side Top – top of the icon |
| Parameter | Description |
| Host | Status of triggers of this hosts will be used. |
| Map | Status of all elements of this map will be used. |
| Trigger | Status of this triggers will be used. |
| Host group | Status of all triggers of this host group will be used. |
| Icon (ok) | Icon to be used when no problem exists. |
| Icon (problem) | Icon to be used in case of problems (one or more). |
| Icon (unknown) | Icon to be used in case of problems (one or more). |
| Icon (disabled) | Icon to be used if the selected host is disabled. |
| Coordinate X | X coordinate for the map element. |
| Coordinate Y | Y coordinate for the map element. |
| URL | If set, the URL will be used when an user clicks on the |
| screen element. |
Configuration of a link
The screen provides access to configuration of a link.
Map link attributes:
| Parameter | Description |
| Element 1 | Unique screen name. |
| Element 2 | Number of columns in the screen. |
| Link status indicators | List of triggers linked to the link. In case if a trigger has status PROBLEM, its style is applied to the link. |
| Type (OK) | Default link style: Line – single line Bold line – bold line Dot -dots Dashed line – dashed line |
| Color (OK) | Default link color. |
The screen is used to manage IT Services.
List of IT Services
The screen provides list of IT Services.
Displayed data:
| Parameter | Description |
| Service | Service name. |
| Status calculation | How the service updates its status. |
| Trigger | Linked to a trigger: none – no linkage trigger name – linked to the trigger, thus dependson the trigger status |
IT Service configuration
The screen provides access to configuration of a user-defined screen.
IT Service attributes:
| Parameter | Description |
| Name | Service name. |
| Parent service | Parent service. For reference only, it cannot be changed. |
| Depends on | List of child services the service depends on. |
| Status calculation algorithm | How to calculate status of the service: Do not calculate – do not calculate service status Problem, if it least one child has a problem – consider problem if at least one child service has a problem Problem, if all children have problems – consider problem if all children have problems |
| Calculate SLA | Select to display SLA data. |
| Acceptable SLA (in %) | SLA percentage for this service. It is used for reporting. |
| Service times | By default, all service operates 24x7x365. Add new service times to make exceptions. |
| New service time | Service times: |
| Parameter | Description |
| One-time downtime – a single downtime. Service state within this period does not affect SLA. Uptime – service uptime Downtime – Service state within this period does not affect SLA. | |
| Link to trigger | Services of the lowest level must be linked to triggers. |
| Sort order | Display sort order, lowest comes first. |
The screen is used to manage discovery rules.
List of discovery rules
The screen provides list of discovery rules.
Displayed data:
| Parameter | Description |
| Name | Name of discovery rule. |
| IP range | Range of IP addresses affected by the discovery rule. |
| Delay | Frequency in seconds. |
| Checks | List of checks executed by the discovery rule. |
| Status | Status of the discovery rule: Active – the rule is active Disabled – the rule is disabled |
Discovery rule configuration
The screen provides access to configuration of a discovery rule.
Discovery rule attributes:
| Parameter | Description |
| Name | Unique name of the discovery rule. |
| Discovery by proxy | Who performs discovery: |
| (no proxy) – ZABBIX Server is doing discovery | |
| proxy name – This proxy performs discovery | |
| IP range | Range of IP addresses for discovery. Format: |
| Single IP: 192.168.1.33 | |
| Range of IP addresses: 192.168.1.1-255 | |
| List: 192.168.1.1-255,192.168.2.1-100,192.168.2.200 | |
| Delay (seconds) | This parameter defines how often ZABBIX should |
| execute this rule in seconds. | |
| Checks | List of supported checks: |
| SSH, LDAP, SMTP, FTP, HTTP, POP, NNTP, IMAP, | |
| TCP, ZABBIX Agent, SNMPv1 Agent, SNMPv2 Agent | |
| New check | SLA percentage for this service. It is used for reporting. |
| Port | This parameter may be one of following: |
| Single port: 22 | |
| Range of ports: 22-45 | |
| List: 22-45,55,60-70 | |
| Status | Status of the discovery rule: |
| Active – the rule is active | |
| Disabled – the rule is disabled | |
| New service time | Service times: |
| One-time downtime – a single downtime. Service | |
| state within this period does not affect SLA. | |
| Uptime – service uptime | |
| Downtime – Service state within this period does not | |
| affect SLA. | |
| Link to trigger | Services of the lowest level must be linked to triggers. |
| Sort order | Display sort order, lowest comes first. |
The screen is used to export hosts, items, triggers and graphs.
Export
The screen provides list of hosts and their elements for export.
Select elements you would like to export, then press “Preview” or “Export”. Displayed data:
| Parameter | Description |
| Name | Host name. |
| DNS | Host DNS name. |
| IP | IP address of ZABBIX agent. |
| Port | ZABBIX agent port number. |
| Status | Host status. |
| Templates | Select to export template related information. |
| Items | Select to export host items. |
| Triggers | Select to export host triggers. |
Preview page:
The screen is used to perform XML import of host related data.
Discovery rule attributes:
| Parameter | Description |
| Import file | XML file to import. |
| Rules | Set of rules for each type of element: |
| Existing – what to do if element already exists Missing – what do to if element is missing Possible actions: | |
| Update – update existing element Add – add element | |
| Skip – do not process new data |
Press “Import” to import selected file.
The Administration Tab is available to users Super Administrators only.
The screen can be used to enable Apache based (HTTP) authentication. The authentication will be used to check user names and passwords. Note that an user must exist in ZABBIX as well, however his ZABBIX password will not be used.
Configuration parameters:
| Parameter | Description |
| HTTP Authentication Enabled | This parameter defines if Apache based authentication is enabled. |
Note: Be careful! Make sure that Apache authentication is configured and works properly before switching it on.
Note: In case of Apache authentication all users (even with GUI Access set to Internal) will be authorised by Apache, not by ZABBIX!
The screen can be used to enable external LDAP authentication. The authentication will be used to check user names and passwords. Note that an user must exist in ZABBIX as well, however his ZABBIX password will not be used.
ZABBIX LDAP authentication works at least with Microsoft Active Directory and OpenLDAP.
Configuration parameters:
| Parameter | Description |
| LDAP Host | Name of LDAP server. For example: ldap://ldap.zabbix.com For secure LDAP server use ldaps//...: ldaps://ldap.zabbix.com |
| Port | Port of LDAP server. Default is 389. For secure LDAP connection port number is normally 636. |
| Base DN | ou=Users,ou=system |
Parameter Description
uid
Search Attribute
uid=Admin,ou=system
Bind DN
Password for binding to the LDAP server.
Bind Password
Enable LDAP authentication.
LDAP Authentication
Enabled
-
Test Authentication
Name of a test user. The user must exist in LDAP.
Login
LDAP password of the test user. ZABBIX will not activate LDAP authentication if it is unable to authenticate the test user.
User Password
Note: Some user group can still be authorised by ZABBIX. These group must have GUI Access set to Internal.
The screen can be used to manage ZABBIX users.
List of users
It provides list of users.
Displayed data:
| Parameter | Description |
| Alias | User short-name, i.e. login name. |
| Name | User name. |
| Surname | User surname. |
| User type | User type, one of following: ZABBIX User ZABBIX Admin ZABBIX Super Admin |
| Groups | List of all group the user belong to. |
| Is online? | Is user online. |
| GUI Access | Access to GUI, depends on settings of user groups: System default – ZABBIX, HTTP Authentication, LDAP Authentication Internal – the user is authenticated by ZABBIX regardless of system settings Disabled – GUI access is restricted to this user |
| Parameter Status | Description User status, depends on settings of user groups: Enabled – the user is active |
|---|---|
| Disabled – the user is disabled. The user is ignored by ZABBIX. | |
| Actions |
User configuration
The screen provides user details and gives control to change user attributes.
Configuration parameters:
| Parameter | Description |
| Alias | User short-name, i.e. login name. Must be unique! |
| Name | User name. |
| Surname | User surname. |
| User type | User type, one of following: ZABBIX User – access to Monitoring tab only. ZABBIX Admin – access to Monitoring and Configuration tabs. ZABBIX Super Admin – access to everything, including Administration tabs. |
| Groups | List of all group the user belong to. |
| Media | List of all medias. The medias are used by ZABBIX for sending notifications. |
| Language | Language of ZABBIX GUI. |
| Theme | Defines how the GUI looks like: |
Parameter
Description System Default -use system settings Original Blue – standard blue theme Black & Blue – alternative theme
Auto-login (1 month)
Enable if you want ZABBIX to remember you. Browser cookies are used for this.
User will be logouted after N seconds if inactivity. Set it
Auto-logout (0
to 0 to disable auto-logout. URL (after login)
disable)
Make ZABBIX to transfer you to the URL after successful login.
Refresh used for graphs, screens, plain text data, etc. Can be set to 0 to disable.
Refresh (in seconds)
Click on User Right Show to display user rights. It is impossible to change user rights here, the rights depend on user group membership!
The information is available read-only.
The screen can be used to manage ZABBIX user groups.
List of user groups
It provides list of user groups.
Displayed data:
| Parameter | Description |
| Name | Host group name. Must be unique. |
| User status | Enabled – users are active Disabled – all users of the group are disabled |
| GUI Access | Displays how the users are authenticated. System default – use default authentication Internal – use ZABBIX authentication Disabled – access to ZABBIX GUI is forbidden |
| Members | List of group members |
User group configuration
Configuration parameters:
| Parameter | Description |
| Group name | Unique group name. |
| Users | List of members of this group. |
| GUI Access | How the users of the group are authenticated. System default – use default authentication Internal – use ZABBIX authentication Disabled – access to ZABBIX GUI is forbidden |
| Users Status | Status of group members: Enabled – users are active Disabled – users are disabled |
| Rights | Three lists for different host permissions: Read-write – host groups with read-write access Read-only – host groups with read-only access Deny – host groups with deny access |
Click on User rights (Show) to see what permissions the user group have:
The screen can be used to manage ZABBIX users.
List of media types
It provides list of media types. Media type is a delivery method for user notifications.
Displayed data:
| Parameter | Description |
| Type | Media type: Email – email notification |
| SMS – SMS notifications sent using serial GSM modem | |
| Jabber – Jabber notification | |
| Script – script based notification | |
| Description | Name of the media. |
| Details | Configuration details, depends on media type. |
Media configuration
The screen provides user details and gives control to change media attributes.
Configuration parameters:
| Parameter | Description |
| Description | Unique media name. |
| Type | Media type: Email – email notification |
| SMTP Server -server name | |
| SMTP Hello – Hello string, normally domain name SMTP Email – sender email address | |
| SMS – SMS notifications sent using serial GSM modem GSM Modem -serial device name of GSM modem | |
| Jabber – Jabber notification | |
| Jabber Identifier -Jabber ID | |
| Password – Password of the Jabber ID |
Parameter
Description Script – script based notification Script name -name of the custom script
The screen can be used to manage user-defined scripts. The scripts are executed on ZABBIX Server side even for hosts monitored by a proxy.
List of scripts
It provides list of scripts known to ZABBIX. Depending on permission, ZABBIX user may execute a script from the front-end by clicking on host from certain screens.
Displayed data:
| Parameter | Description |
| Name | Unique script name. |
| Command | Command to be executed. |
| User group | The script is available to members of the user group only. |
| Host group | The script is available for hosts of the host group only. |
| Parameter | Description |
| Host access | Read -an user must have read permission for the host to execute the script |
| Write -an user must have write permission for the host to execute the script. |
Script configuration
The screen provides script details and gives control to change script attributes.
Configuration parameters:
| Parameter | Description |
| Name | Unique script name. |
| Command | Full patch to a command, which will be executed on user request. The command will run on ZABBIX Server side. The following macros are supported here: {HOST.CONN} {HOST.DNS} |
| Parameter | Description |
| {IPADDRESS} For example: /bin/ping-c 3 {HOST.CONN} A special syntax for IPMI commands must be used: IPMI <ipmi control> [value] For example: IPMI power off | |
| User group | The script is available to members of the user group only. |
| Host group | The script is available for hosts of the host group only. |
| Host access | Read -an user must have read permission for the host to execute the script Write -an user must have write permission for the host to execute the script. |
The screen can be used to see front-end audit records and list of notifications sent to users.
Audit logs
Displayed data:
| Parameter | Description |
| Time | Time stamp when an action took place. |
| User | User name. |
| Resource | Object, which was affected: Application Graph Host Item User |
| Action | Performed action: Added Login Logout Removed Updated |
| Details | More detailed information about action. |
Audit actions
The screen provides access to history of notifications and remote commands.
Displayed data:
| Parameter | Description |
| Time | Time stamp when an action took place. |
| Type | Type of executed operation: Notifications Remote command |
| Status | Status: Not sent Sent |
| Retires left | Number of retires left. |
| Recipient(s) | List of recipients. |
| Message | Message used in notification. |
| Error | Error if the notification was not sent. |
The Queue provides information about performance of ZABBIX.
Overview
The view gives information about overall performance of ZABBIX including ZABBIX Server and Proxies.
For each item type the following data is displayed:
| Parameter | Description |
| Items | Item type |
| 5 seconds | Data is delayed for 5-10 seconds. |
| 10 seconds | Data is delayed for 10-30 seconds. |
| 30 seconds | Data is delayed for 30-60 seconds. |
| 1 minute | Data is delayed for 1-5 minutes. |
| 5 minutes | Data is delayed for 5-10 minutes. |
| More than 10 minutes | Data is delayed for more than 10 minutes. |
Overview by proxy
The view gives more detailed information about performance of ZABBIX Server and Proxies.
For each Proxy and local ZABBIX Server the following data is displayed:
| Parameter | Description |
| Proxy | Proxy name or Server. Server, displayed last, shows statistics about local server. |
Details
The view gives very detailed information about delayed items.
List of items is displayed with the following details:
| Parameter | Description |
| Next check | Expected time stamp of next data retrieval. The time stamps will always be in the past. |
| Host | Host name. |
| Description | Item name. |
This is report on number of notifications sent to each user grouped by media types.
For each user number of notifications is displayed per each media type.
Locales provides functionality for easy editing of translations of ZABBIX front-end.
Locale selection
Select locale you'd like to select for further processing.
Parameters:
| Parameter | Description |
| Take for default locale | The locale will be used as a base one. |
| Locale to extend | Select language you'd like to improve. |
| New entries | Do not add – if something is not translated, ignore it Leave empty – if something is not translated, leave translation empty Fill with default value – if something is not translated, fill translation with default value |
Translation form
This form is used to translate phrases used in ZABBIX front-end. Left side is filled with default language, right side consists of translated phrases.
Once translation is ready, press button “Download” to have translation file, which can be used to replace files under include/locales.
The screen makes possible creation of ZABBIX front-end configuration file.
Server with ZABBIX 1.0 installed (RedHat Linux 8.0, kernel 2.4.18-14, MySQL/MyISAM 3.23.54a-4, Pentium IV 1.5Ghz, 256Mb, IDE) is able to collect more than 200 parameters per second from servers being monitored (assuming no network delays).
How many servers can be monitored by ZABBIX on the hardware, one may ask? It depends on number of monitored parameters and how often ZABBIX should acquire these parameters. Suppose, each server you monitor has ten parameters to watch for. You want to update these parameters once in 30 seconds. Doing simple calculation, we see that ZABBIX is able to handle 600 servers (or 6000 checks). In case if these parameters need to be updated once in a minute, the hardware configuration will be able to handle 600x2=1200 servers. These calculations made in assumption that all monitored values are retrieved as soon as required (latency is 0). If this is not a requirement, then number of monitored servers can be increased even up to 5x-10x times.
It is very important to have ZABBIX system properly tuned for maximum performance.
General advices on hardware:
ZABBIX configuration parameters
Many parameters may be tuned to get optimal performance.
zabbix_server
StartPollers
General rule -keep value of this parameter as low as possible. Every additional instance of zabbix_server adds known overhead, in the same time, parallelism is increased. Optimal number of instances is achieved when queue, on average, contains minimum number of parameters (ideally, 0 at any given moment). This value can be monitored by using internal check zabbix[queue].
DebugLevel
Optimal value is 3.
DBSocket
MySQL only. It is recommended to use DBSocket for connection to the database. That is the fastest and the most secure way.
This is probably most important part of ZABBIX tuning. ZABBIX heavily depends on availability and performance of database engine.
At least three methods (or combination of all methods) may be used in order to monitor availability of a server.
WinPopUps maybe very useful if you're running Windows OS and want to get quick notification from ZABBIX. It could be good addition for email-based alert messages. Details about enabling of WinPopUps can be found at https://sourceforge.net/forum/message.php?msg_id=2721722.
IBM AS/400 platform can be monitored using SNMP. More information is available at http://publibb.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg244504.html?Open.
21.2.2.MySQL
Configuration file misc/conf/zabbix_agentd.conf contains list of parameters that can be used for monitoring of MySQL.
### Set of parameter for monitoring MySQL server (v3.23.42 and later) ### Change -u and add -p if required #UserParameter=mysql[ping],mysqladmin -uroot ping|grep alive|wc -l #UserParameter=mysql[uptime],mysqladmin -uroot status|cut f2 -d”:”|cut -f1 -d”T” #UserParameter=mysql[threads],mysqladmin -uroot status|cut f3 -d”:”|cut -f1
-d”Q”
#UserParameter=mysql[questions],mysqladmin -uroot status|cut f4 -d”:”|cut -f1 -d”S” #UserParameter=mysql[slowqueries],mysqladmin -uroot status|cut f5 -d”:”|cut -f1
-d”O” #UserParameter=mysql[qps],mysqladmin -uroot status|cut -f9 d”:” #UserParameter=version[mysql],mysql -V
Number of MySQL threads
Number of processed queries
Number of slow queries
Queries per second Version of MySQL
Example: mysql Ver 11.16 Distrib 3.23.49, for pc-linux-gnu (i686)
Use SNMP agent provided by Mikrotik. See http://www.mikrotik.com for more information.
Use ZABBIX W32 agent included (pre-compiled) into ZABBIX distribution.
Use MRTG Extension Program for NetWare Server (MRTGEXT.NLM) agent for Novell. The agent is compatible with protocol used by ZABBIX. It is available from http://forge.novell.com/modules/xfmod/project/?mrtgext.
Items have to be configured of type ZABBIX Agent and must have keys according to the MRTGEXT documentation.
For example:
Full list of parameter supported by the agent can be found in readme.txt, which is part of the software.
Tuxedo command line utilities tmadmin and qmadmin can be used in definition of a UserParameter in order to return per server/service/queue performance counters and availability of Tuxedo resources.
Standard Informix utility onstat can be used for monitoring of virtually every aspect of Informix database. Also, ZABBIX can retrieve information provided by Informix SNMP agent.
First of all, you need to configure your jvm to allow jmx monitoring. How do you know if you can do this? You can use the sun jconsole utility that comes with the jdk and point it at your machine running the jvm. If you can connect, you are good.
In my tomcat environment, I enable it by setting the following options for the jvm:
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=xxxxx \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=true \
-
Dcom.sun.management.jmxremote.password.file=/path/java/jre/lib/management/j
mxremote. password"
This tells the jmx server to run on port XXXXX, to use password authentication, and to refer to the passwords stored in the jmxremote.password file. See the sun docs on jconsole for details. (You might consider enabling ssl to make the connection more secure.)
Once that is done, I can then run jconsole and see everything that is currently exposed (and to verify that I can connect properly). jconsole will also provide you the information you need to query specific jmx attributes from the information tab.
Now, since I use Tomcat, there are two ways that I can grab the jmx attribute values (or effect a jmx operation). The first way is I can use the servlet provided by Tomcat. (Don't know what jboss has). The second way is I can send well formatted requests via a jmx command line tool.
Let's say I am interested in peak threads used by the system. I browse down through the jmx objects via jconsole, find it under java.lang, Threading. After selecting Threading, I click on the info tab, and I can see the name of the mbean is "java.lang:type=Threading"
With tomcat, I can do the following:
curl -s -u<jmxusername>:<jmxpassword> 'http://<tomcat_hostname>/manager/jmxproxy/?qry=java.lang:type=Threading'
where the jmx username and password are the ones defined in the file defined in the jvm options above, the qry string is the one obtained from jconsole.
The output from this will be all the metrics from this jmx key. Parse the output and grab the number of your choice.
If you don't have a servlet that will allow you to make a http request to the jmx interface, you can use the command line tool like this
/<pathTo>/java -jar /<pathTo>/cmdline-jmxclient.jar <jmxusername>:<jmxpassword> <jvmhostname>:<jmxport> java.lang:type=Threading PeakThreadCount
The difference with the command line client is you need to specify the attribute you are interested in specifically. Leaving it out will give you a list of all the attributes available under Threading.
Again, parse the output for the data of your choice.
Once you can reliably grab the data you are interested in, you can then turn that command into a zabbix userparm.
e.g.
UserParameter=jvm.maxthreads, /usr/bin/curl -s -u<jmxusername>:<jmxpassword> 'http://<tomcat_hostname>/manager/jmxproxy/?qry=java.lang:type=Threading' | / bin/awk '/^PeakThreadCount\:/ { gsub( /[^0123456789]/, "" ); print $1 }'
or
UserParameter=jvm.maxthreads, /<pathTo>/java -jar /<pathTo>/cmdlinejmxclient.jar <jmxusername>:<jmxhostname> <jvmhostname>:<jmxport> java.lang:type=Threading PeakThreadCount | <some filter to grab just the number you need -left as an exercise to the reader>
That's it.
I prefer getting my stats from the servlet via http rather than using the java command line client as it is much "lighter" to start up and grab the information.
Need a command line jmx client? I use the one from here:
http://crawler.archive.org/cmdline-jmxclient/
Information on setting up jmx monitoring for your jvms
http://java.sun.com/j2se/1.5.0/docs...ment/agent.html
General Information on JMX http://java.sun.com/j2se/1.5.0/docs...verviewTOC.html
PS: apparently the 1.5 jvm also supports snmp which provides another option.
ZABBIX can be configured to send messages to OpenView server. The following steps must be performed:
Define new media.
The media will execute a script which will send required information to OpenView.
Define new user.
The user has to be linked with the media.
Configure actions.
Configure actions to send all (or selected) trigger status changes to the user.
Write media script.
The script will have the following logic. If trigger is ON, then execute OpenView command opcmsg -id application=<application> msg_grp=<msg_grp> object=<object> msg_text=<text>. The command will return unique message ID which has to be stored somewhere, preferrably in a new table of ZABBIX database. If trigger is OFF then opcmack <message id> has to be executed with message ID retrieved from the database.
Refer to OpenView official documentation for more details about opcmsg and opcmack. The media script is not given here.
ZABBIX daemons generate error and warning messages in case of any problems. The messages are written to log files or syslog depending on configuration parameters.
Some of the messages are numbered.
The table contains complete list of numbered messages with additional details.
| Error | Message | Details |
|---|---|---|
| Z3001 | Connection to database '%s' failed: [%d] %s | ZABBIX daemon is unable to establish connection to the database. Additional information: database name database error code database error string |
| Z3002 | Cannot create database '%s': [%d] %s | ZABBIX daemon is unable to create database. Additional information: database name database error code database error string |
| Z3003 | No connection to the database. | This should never happen. Report to Zabbix Team. |
| Z3004 | Cannot close database: [%d] %s | ZABBIX daemon is unable to close connection to the database. Additional information: database error code database error string |
| Z3005 | Query failed: [%d] %s [%s] | SQL query execution failed. Additional information: database error code database error string SQL query string |
| Z3006 | Fetch failed: [%d] %s | Record fetch failed. |
Note: The numbered error messages are supported starting from ZABBIX 1.8.
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope.
The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
print such an announcement, your work based on the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the
| Program) | on | a | volume of | a | storage | or | distribution medium | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| does | not | bring | the | other | work | under | the | scope | of | this | ||||
| License. | ||||||||||||||
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
END OF TERMS AND CONDITIONS
There are several ways to contribute to the project:
Please, consider discussing your ideas with ZABBIX developers before writing actual code.
I believe this policy guarantees high quality of the software and makes support more efficient.
My wish list at Amazon.com
If ZABBIX just saved you from a disaster or if you want to be nice to me, you can purchase something from my wish list at Amazon.com available at
http://www.amazon.com/exec/obidos/wishlist/2MXT84ZA4ZNNA
Thanks to all who sent me something from Amazon!
Contributors
Please, see ZABBIX Manual for a complete list of contributors.
WEB Hosting
WEB Hosting is freely provided by Clearcut Networks. Check it out if you want an affordable hosting in Netherlands.
ZABBIX team wants to thank the guys from http://sourceforge.net for providing hosting for the project. Our team also wants to thank all the ZABBIX users who have sent corrections and suggestions. This sort of feedback helps us make the software better.
Many significant improvements mostly related to PHP front-end and ZABBIX agents.
I am sorry for not mentioning all who contributed to ZABBIX/ In alphabetical order:
Patch to allow connection to MySQL using UNIX socket. Support for graceful shutdown in case MySQL server goes down (not implemented yet). Idea and initial code for ZABBIX screens.
Plenty of interesting ideas based on real use of ZABBIX in large monitoring environment.
Support for system[procload] on Solaris 2.6. Improvements for graphs. Improvements for system maps.
Native ZABBIX agent for WIN32 platforms.
ZABBIX SIA Dzelzavas Street 117 Office #417 LV-1021 Riga, Latvia
Tel +371 6 7784742 Fax +371 6 7784744
Email sales@zabbix.com Web www.zabbix.com
Copyright © 2008 by ZABBIX SIA.
ZABBIX is a registered trademark of ZABBIX SIA. All other names and products are trademarks or registered trademarks of their respective owners.