Open Source Enterprise Monitoring with Zabbix

Alexei Vladishev, Founder of Zabbixwww.zabbix.com

What is Zabbix:

• Zabbix overview• Highlights of Zabbix features• Monitoring of large distributed environments

Future:

• Zabbix Roadmap

Plan

Zabbix overview

Most important reasons:

• Warn and act in case of any problems.• Downtimes are very expensive!• To identify and fix problems ASAP before customers start calling.• More productive work of IT staff• To automate routine tasks, check of availability of resources• To plan hardware resources. Capacity planning and trends. • To measure and analyse quality of provided and used services (SLA)

A good monitoring system makes us confident our business is running!

Why shall we use monitoring?

Zabbix is celebrating its 8th anniversary!

• Choice of 1998 — HP OpenView, IBM, BMC: expensive to buy and maintain• How to name it? ABCDE...Zabbix! • April 2001 — the first public release Zabbix 1.0alpha1• April 2004 — the first stable release Zabbix 1.0• April 2005 — the company Zabbix SIA was established: commercial support

Zabbix today. We have made a good progress!

Zabbix 1.6.4, 500 downloads per day, 15.000 forum usersZabbix company is growing, 20 Zabbix partners (Europe, Japan, the US)

History

Zabbix is an Open Source distributed monitoring system capable of monitoring availability and performance of servers, network devices, applications.

Zabbix functionality:• Agent-less/based monitoring• Auto-discovery• Escalations and repeated notifications• Pro-active monitoring, remote actions• WEB monitoring• Graphs, maps, screens• IT Services (SLA), reports• Distributed monitoring, IPv6 and more!

What is Zabbix?

Zabbix: main componentsServer:• Zabbix core, system logic• Data processing, escalations

WEB front-end:• Access to historical data• Configuration

Agent:• Server data collection, actions

Proxy:• Remote data collection

Important technical decisions:• WEB front-end for data visualisation and configuration• Written in the C language, PHP front-end. No Java/Python/Perl/Ruby on the server and agent side! No fork(), native syscalls() are used instead.• Support of virtually all platforms (Linux, *BSD, Solaris, AIX, HP-UX, Windows,...)• Choice of database engines: MySQL, PostgreSQL, Oracle, SQLite• We do not reuse Nagios, RRD, Cacti

Key principles of Zabbix development:• Keep things simple (KISS), yet be very flexible• Maintain low hardware requirements, should not affect production

Technical details

What makes Zabbix so special?• All-in-one solution only when it comes to monitoring!• All historical data, trends and configuration is stored in a database• Ready for monitoring of small and LARGE distributed environments• True Open Source (GPLv2) solution, no commercial versions.• All logic is on the server side, agents are for data collection only• Extremely flexible! Triggers, escalations, new checks, screens, and more.• Designed to deal with unstable communications• Full support of IPv6

Why would we choose Zabbix?

How to monitorService checks:• FTP, SSH, HTTP, SMTP, DNS ...

Zabbix Agent:• Аctive and passive checks• Monitoring of logs, event logs• Easy to extend• Remote command execution• Extremely efficient!

Other: WMI, JMX, Nagios plugins

SNMP v1,v2,v3:• Network devices• Normally NET-SNMP for servers• Monitoring of applications (Oracle, Weblogic, Websphere, PostgreSQL, MySQL, ...)• SNMP traps

IPMI:• Monitoring of hardware• Remote management (reboot, reset, halt)

Use of Zabbix agentActive checks:• Highly efficient• Buffering of collected data

Passive checks:• Requires polling on the Zabbix server side• Additional performance hit because of polling and network bandwidth

Zabbix Highlights

Mmm... Triggers!Trigger is a flexible logical expression used to define a problem condition.• Status (value) of a trigger represents system state• Change of trigger value generates events• It is one of the ways to deal with flapping

CPU load is too high: {host:cpuload.last(0)}>5CPU load is too high: {host:cpuload.min(300)}>2CPU load is too high: {host:cpuload.min(300)}>2 & {host:cpuuser.min(300)}>50CPU load is too high: {host:cpuload.min(300)}>2 & {host2:backup.last(0)}=0

We decide how to define «CPU load is too high» not Zabbix itself!

DependenciesThey are used to:

• Avoid notifications• Define dependencies between different problems (related to networks, applications, anything). No host dependencies!

Server is down → Switch1 is down → Switch2 is down

WEB App is down → MySQL is not responsive → No free disk space on /tmp

EscalationsDifferent scenarios:• Delayed notifications• Repeated notifications• Execution of commands• Escalation to other users• Recovery messages• Different actions for acknowledged and not acknowledges events

Example (reaction to a failed WEB check):

Increase step every 5 minutes Step 1-3: Send message to Unix Admins Step 3-5: Send message to Boss if not ACK Step 6: Restart Apache if not ACK Step 7: Reboot server if not ACK Step 10: Send message to all of not ACK

Visualisation: DashboardFavourite resources:• Maps• Graphs• Screens

High-level view:• Problems by host group• Zabbix statistics• List of the latest issues• WEB monitoring info• Auto-discovery

Visualisation: GraphsImmediate access:• Any period of time• Easy time-navigation• Two mouse-click zooming• Problem conditions displayed• Non-working time is marked• Not generated in advance!

Graph types:• Standard (dots, lines, colors)• Stacked• Pie

Visualisation: ScreensDifferent blocks:• Graphs• Maps• Plain text data• List of problems• High level stats

Slide shows:• Combination of screens• Displayed one after another

WEB monitoringGoals:• Monitoring of user experience• Support of complex scenarios• Performance monitoring• Availability monitoring

Example:Step 1 Access home pageStep 2 Login (POST, GET)Step 3 Run reportStep 4 Logout

IT ServicesGoals:• Business level monitoring• SLA monitoring• We care about services• Escalation of problems• Root cause of the problem

Tree structure based on:• Dependencies• Physical location• Type of service, etc

User managementAuthentication:• Standard: Zabbix database• LDAP (Active Directory)• Apache (Kerberos, Unix, etc)

Permissions:• Depends of user type• User group level permissions

Also:• Notifications-only user groups

Extending ZabbixNew Zabbix agent-side check: UserParameter=mysql.qps,mysqladmin –uroot status|cut –f9 –d”:”UserParameter=sum[*],echo “$1+$2”|bcExamples: mysql.qps = 456, sum[4,5] = 9

New notification methods:• Just a matter of writing a shell script (voice generation, Skype call, anything)

New server side checks:• Just a matter of writing a shell script

Monitoring of large environments

Our environmentSituation:• Several thousands of servers and network devices• Distributed accross 2-100 data centers or branches• Centralised monitoring is required

Zabbix: several approaches

• One Zabbix server does everything

• One Zabbix server• One Proxy per data center or company branch

DistributedDistributed1 Server1 ServerMany ProxiesMany Proxies1 Server1 Server

• One Zabbix server per data center• More effort to maintain• Can be used with Proxies

What is Proxy?Proxy is a data collector. It is also used for auto-discovery.

Advantages:• Makes architecture easier• Does not require significant resources• Offloads Zabbix server

Proxy: how does it work?Connection loss processing:• Data is buferred in the Proxy database• Will be sent on connection recovery• No notifications about local problems!

Management:

• Data collection only• Fully managed via WEB front-end• Configuration is stored on the Zabbix server side• All connections are initiated by Proxy• Collection of thousands of values per second

Distributed monitoringBasic attributes:• Tree-like structure• Node is a Zabbix server• Nodes are platform independent

Managements:• Two-way replication of configuration• Parent node controls child nodes

Processing of connection lossWhat will stop working?• Data sending to parent node• Synchronisation of configuration

Everything else will keep working!

Thousands of devices: solutionsProblems and solutions:• Huge data volume: use database partitions for historical data• Integration with existing systems: LDAP authentication, notifcation methods to open tickets, XML import/export for configuration management and inventory• Maintenance: templates, mass updates• Upgrades: all Zabbix components are compatible within one major release 1.6.x

Choice of the best schema

Getting used to ZabbixAdopt Open Source

Adding Proxies

DistributedDistributed1 Server1 Server

Many ProxiesMany Proxies1 Server1 Server Distributed monitoring

Depends on the requirements:• Local administration• Full-featured monitoring when no connection between data centers (branches)

Zabbix Roadmap

General directions

• Better integration• REST API/RPC• Better scalability

• Flexible Dashboard• Personalization (widgets)

OtherOtherGUIGUIGeneralGeneral

• Infrastructure for widgets• Business level monitoring

Questions?Today and tomorrow I am around!