Performance considerations
by Andrea Vacche, Patrik Uytterhoeven, Rihards Olups
Zabbix: Enterprise Network Monitoring Made Easy
- Zabbix: Enterprise Network Monitoring Made Easy
- Table of Contents
- Zabbix: Enterprise Network Monitoring Made Easy
- Zabbix: Enterprise Network Monitoring Made Easy
- Credits
- Preface
- I. Module 1
- 1. Getting Started with Zabbix
- The first steps in monitoring
- Zabbix features and architecture
- Installation
- Summary
- 2. Getting Your First Notification
- 3. Monitoring with Zabbix Agents and Basic Protocols
- 4. Monitoring SNMP Devices
- 5. Managing Hosts, Users, and Permissions
- 6. Detecting Problems with Triggers
- 7. Acting upon Monitored Conditions
- 8. Simplifying Complex Configurations with Templates
- 9. Visualizing Data with Graphs and Maps
- 10. Visualizing Data with Screens and Slideshows
- 11. Advanced Item Monitoring
- 12. Automating Configuration
- 13. Monitoring Web Pages
- 14. Monitoring Windows
- 15. High-Level Business Service Monitoring
- 16. Monitoring IPMI Devices
- 17. Monitoring Java Applications
- 18. Monitoring VMware
- 19. Using Proxies to Monitor Remote Locations
- 20. Encrypting Zabbix Traffic
- 21. Working Closely with Data
- 22. Zabbix Maintenance
- A. Troubleshooting
- B. Being Part of the Community
- 1. Getting Started with Zabbix
- II. Module 2
- 1. Zabbix Configuration
- 2. Getting Around in Zabbix
- 3. Groups, Users, and Permissions
- 4. Monitoring with Zabbix
- Introduction
- Active agents
- Passive agents
- Extending agents
- SNMP checks
- Internal checks
- Zabbix trapper
- IPMI checks
- JMX checks
- Aggregate checks
- External checks
- Database monitoring
- Checks with SSH
- Checks with Telnet
- Calculated checks
- Building web scenarios
- Monitoring web scenarios
- Some advanced monitoring tricks
- Autoinventory
- 5. Testing with Triggers in Zabbix
- 6. Working with Templates
- 7. Data Visualization and Reporting in Zabbix
- 8. Monitoring VMware and Proxies
- 9. Autodiscovery
- 10. Zabbix Maintenance and API
- C. Upgrading and Troubleshooting Zabbix
- III. Module 3
- 1. Deploying Zabbix
- 2. Distributed Monitoring
- 3. High Availability and Failover
- Understanding high availability
- Understanding the levels of IT service
- Some considerations about high availability
- Implementing high availability on a web server
- Configuring the Zabbix server for high availability
- Implementing high availability for a database
- Summary
- 4. Collecting Data
- 5. Visualizing Data
- 6. Managing Alerts
- 7. Managing Templates
- 8. Handling External Scripts
- 9. Extending Zabbix
- 10. Integrating Zabbix
- D. Bibliography
- Index
Zabbix tends to perform nicely for small installations, but as the monitored environment grows, one might run into performance problems. A full Zabbix performance discussion is out of scope here, but let's discuss the starting points to having a healthy configuration and the directions for further research:
- Monitor only what you really need, as rarely as possible, and keep the data only for as long as really needed. It is common to new users of Zabbix to use default templates as-is, add a lot of new items with low intervals...and never look at the data. It is suggested to clone the default templates, eliminate all that is not needed, and increase the intervals as much as possible. This involves trimming item lists, increasing intervals, and reducing history and trend-retention periods. There are also events, alerts, and other data—we will discuss their storage settings a bit later.
- When using Zabbix agents, use active items. Active items will result in a smaller number of network connections and reduce the load on the Zabbix server. There are some features not supported with active items, so sometimes, you will have to use passive items. We discussed what can and cannot be done with active items in Chapter 3, Monitoring with Zabbix Agents and Basic Protocols.
- Use Zabbix proxies. They will provide bulk data to Zabbix Server, reducing the work the server has to do even further. We discussed proxies in Chapter 19, Using Proxies to Monitor Remote Locations.
We already know about the history and trend-retention periods for items—but for how long does Zabbix store events, alerts, acknowledgment messages, and other data? This is configurable by going to Administration | General and choosing Housekeeping in the dropdown in the upper-right corner:
Here, we may configure for how long to keep the following data:
- Events: We may choose separate storage periods for trigger, internal, network discovery, and active agent autoregistration events. Note that removing an event will also remove all associated alerts and acknowledgment messages.
- IT service data: The IT service up and down state is recorded separately from trigger events, and its retention period can be configured separately as well.
- Audit data: This specifies how long to store the audit data for. We will discuss what that actually is in a moment.
- User sessions: User sessions that have been closed will be removed more frequently, but active user sessions will be removed after 1 year by default. This means that one may not be logged in longer than a year
These values should be kept reasonably low. Keeping data for a long period of time will increase the database size, and that can impact the performance a lot.
What about the history and trend settings in here? While they're configurable per item normally, we may override those here. Also, for each of the entries, internal housekeeping may be disabled. These options are aimed at users who have to manage large Zabbix installations. When the database grows really large, its performance significantly degrades, and can be improved by partitioning the biggest tables—splitting them up by some criteria. With Zabbix, it is common to partition the history and trends tables, sometimes adding events and alerts tables. If partitioning is used, parts of tables (partitions) are removed, and the internal housekeeping for those tables should be disabled. A lot of people in the Zabbix community will eagerly suggest partitioning at the first opportunity. Unless you plan to have a really large installation or know database partitioning really well, it might be better to hold off. There is no officially supported or built-in partitioning scheme yet, and one might appear in the future. If it does and your partition scheme is different, it will be up to you to synchronize it with the official one.
-
No Comment