Search This Blog

Saturday, July 26, 2014

Zabbix Templates for Microsoft Exchange 2010 Server Roles

This article describes how to build Zabbix templates for Microsoft Exchange 2010 Enterprises and includes Zabbix Templates for Exchange Enterprises.  Zabbix Template items must be unique because duplicate items may not be assigned to the same host.  In an enterprise Exchange environment, a thorough understanding of the Application Roles and their architecture is required to successfully define templates for automated deployment.

Zabbix Template Formats

Zabbix Applications

Applications 

Applications are logical groupings of Items.  These should reflect physical and logical aspects of the device monitored.  For Exchange Server, this includes Services (both Operating System and TCP) and Performance Counters.  The underlying hardware is monitored at the Operating System level, described in the article Zabbix Templates for Windows 2008 R2 OS and Domain Controllers.
Zabbix Items

Items

Items are individual, measurable counters that may be retrieved by querying the OS or Zabbix Agent.  The administrator may easily define time-weighted average sampling to smooth "peaks" and "valleys" in the calculated values.  A sampling rate (frequency) and period (time) define a time-weighted average.  For instance, if the sampling period is defined as 300 seconds and the rate at one sample per 30 seconds, a time-weighted average value for each stored Item value consists of the mean of ten samples.
Zabbix Triggers

Triggers

Triggers are counter values that represent degraded conditions.  Zabbix provides the following classifications of Trigger values:

  1. Not Classified
  2. Information
  3. Warning
  4. Average
  5. High
  6. Disaster

Each Trigger also has administratively-assigned fields for Description and URL.  These are very useful as the administrator may assign the URL of a reliable source and description of the Trigger (e.g. Microsoft Technet Performance Monitor references for descriptions and thresholds) and a brief description copied into the trigger. 
Zabbix Graphs

Graphs

Graphs are the primary visualization for collected data and the feature at which Zabbix excels.  Multiple, related items may be assigned to a single graph (e.g. Processor Idle % and Processor Utilization %) for easy comparison.  Graphs should be grouped according to the types of data present (e.g. rates in counters/sec for one graph, percentages in a second, total counters in a third, etc.).

Graphs, unlike those generated by many RRDTool implementations, are generated just-in-time, saving resource utilization.  That is, without a CGI implementation, RRDTool typically generates all graphs simultaneously using cron jobs.  For an example, see this article on Munin and this article on Icinga/Nagios graphing for examples.  Zabbix only generates graphs when called upon by the administrator, thus saving much of the periodic processing time a cron job implementation requires.
Zabbix Screens

Screens

Screens are logical groupings of graphs and may be designed to present a quick overview of a partial or entire subsystem (e.g. several graphs of processor counters that present the entire set of collected processor data).
Zabbix Screens

The Importance of Defining Appropriate Sets of Zabbix Template Information for Exchange Enterprises

Exchange Server Roles

Zabbix will not allow you to assign Templates to a host if there are duplicates in the Templates.  Thus, if Template A defines and item "service_state[MSExchangeADTopology]" and Template B defines the same item, Zabbix will only allow you to assign one of the Templates.  It is critical to design Templates in advance so that Item, Trigger, Graph and Screen names are not duplicated.  For an Exchange Enterprise, the author has selected a framework based upon the overall architecture of the Application, its Performance Counters and its Services.  Yet even then it is more complex than just those three general groups.


Exchange Server 2010 allows the administrator to install different roles.
  1. Mailbox Role (Mandatory)
  2. Hub Transport Role (Mandatory)
  3. Client Access Server Role (Mandatory)
  4. Unified Messaging Server Role (Optional)
  5. Edge Transport Role (Optional and Unique)
The first three roles must be present in the enterprise. They may be deployed on a single server or deployed individually or in combination on multiple servers.  The Unified Messaging role is optional; the Edge Transport Role is also optional and (if installed) no other roles may be present.  A more detailed description of Exchange 2010 Roles is available in the article Exchange 2010 Architecture.



The templates for each Role/Role Service/Feature set monitor the availability of services using both the Zabbix "service_state" check to query the OS and "net.tcp.listen" (or variant thereof) to query the NIC TCP service(s) in question.  For instance, you may check the Service state "Microsoft Exchange IMAP Service" and associated TCP services on ports 143 (IMAP) and 993 (IMAPS) to determine if the IMAP Mailbox Access service is available.  Service state queries may have multiple triggers that depend on the state returned by Windows (Up, Down, Restarting, etc.) and TCP services a single trigger for Up or Down.  Templates also collect fundamental Performance Counters.

There is still another set of definitions for Templates -- information important for day-to-day monitoring and information important for troubleshooting, trend analysis and scalability design.  The second set includes primarily Performance Counters.  Thus, for each set of Exchange data collected, there is a standard set of data including Application service checks, TCP service checks and Performance Counters and a second, more detailed set that includes primarily Performance Counters.  Flowing from the examples above, the "Exchange 2010 Client Access Server" Template would provide important day-to-day triggers and performance information while a second, "exchange 2010 Client Access Server Performance Counters" provides highly detailed data for troubleshooting, trend analysis, etc.

Implementation

Avoiding duplicate definitions that may lead to the inability to assign multiple Templates to a Zabbix host requires planning and a thorough understanding of Exchange Server Architecture and Topology.  A thorough understanding of the critical core Items versus specialized troubleshooting ones is also very important to provide both day-to-day functionality and less-commonly used troubleshooting, trend analysis, and scalability design information.

Using the above guidelines, we may define an (incomplete) example set of Templates to be implemented for Exchange Enterprises:
  1. Exchange Common Servers
  2. Exchange Common Servers Performance Counters
  3. Exchange Mailbox Servers
  4. Exchange Mailbox Servers Performance Counters
  5. Exchange Hub Transport Servers
  6. Exchange Hub Transport Servers Performance Counters
  7. Exchange Client Access Servers
  8. Exchange Client Access Servers Performance Counters
The optional Unified Messaging and Edge Transport Roles are not included in this list, but may also be defined.  The Edge Transport Role is a subset of the Hub Transport Role functionality and the Templates may be easily added by cloning and modifying the existing Hub Transport Templates.

Each Template contains (where available and appropriate):
  1. Item and Trigger Descriptions
  2. Time-weighted Item collection (generally a 30 second collection interval averaged over a 300 second collection period)
  3. Trigger URL references to the source reference page for the definition
  4. Graphs of individual and sets of items
  5. Screens of Application Groups that collect various screens into logical and complete visualization sets

 Discovery

Discovery uses the same methodology as described in the article Automated Zabbix Deployment and Configuration for Windows Enterprises.  The Zabbix configuration file deployed to each node through Active Directory Group Policy Objects uses Windows commands to check for specific services -- unique to Roles -- during discovery.  In the case of Exchange, the following service check statements are added to the file:

Common to All Exchange Servers
UserParameter=services.MSExchangeServiceHost,net start MSExchangeServiceHost
 
Mailbox Servers
UserParameter=services.MSExchangeIS,net start MSExchangeIS 

Hub Transport Servers
UserParameter=services.MSExchangeTransport,net start MSExchangeTransport

Client Access Servers

UserParameter=services.MSExchangeFBA,net start MSExchangeFBA
 

The Zabbix Discovery Process runs those queries only during discovery and adds the hosts to the proper groups and templates using Actions.



Zabbix Actions for Exchange 2010


No comments :

Post a Comment