Cloud stack monitoring with zenoss

Editor's Notes

• #2: ShapeBlue are specialist cloud builders and are the globally leading consultants & integrators of many many cloud technologies. We were the first Citrix Cloud Advisor in Europe and in the last 6  months we have worked with BSkysB, Colt, SunGard AS, Citrix themselves, Centrica, Orange Telecom, Slovak Telecom Trader Media  and a whole range of smaller organisations. Of particular note is our development  of Sungard's Sungard Online cloud, a major global public cloud.
• #3: Zenoss is an application, server, and network management platform based on the Zope application server. Zenoss provides a web interface that allows system administrators to monitor availability, inventory, configuration, performance, and events.The CloudStack ZenPack adds CloudStack/CloudPlatform specific metrics
• #4: ZenPacks provide a plug-in architecture that allows community members to extend Zenoss's functionality. The authors are free to choose how they license their individual ZenPacks. ZenPacks are encapsulated in Python eggs and provide instrumentation and reports for monitored infrastructure components.
• #5: The same list of metrics is available for each zone. The same metrics with the exception of public IPs and secondary storage are also available for each pod
• #6: The following metrics are available aggregated to each cluster, and for each host
• #7: The monitoring of the following metrics is recommended. A lower notification threshold is also suggested along with an alarm threshold, allowing for the ‘rate of consumption’ to be estimated. A high rate of consumption could indicate either a high uptake rate or an issue in the environment; it should therefore be investigated to determine its cause.Once the notification thresholds have been reached (and confirmed due to legitimate consumption) they should be raised to 50% for further ‘rate of consumption’ monitoring.
• #8: Zenoss has event management tools which can annotate system alerts.In addition to monitoring resource levels, Zenoss also extracts events from the CloudStack event logs. These should be monitored particularly for host failures.
• #9: Version 6.x of RHEL or CentOS is recommended.Core-autodeploy-4.2.sh will automatically deploy Zenoss Core 4 for you. It will download Java, MySQL, Zenoss Core 4, all RPM dependencies, and install everything including the Zenoss Core ZenPacks. Perform these steps on a fresh CentOS or Red Hat Enterprise Linux installation:The script will take several minutes (around 10-30) to complete. When done, you should have a fully functioning Zenoss Core install and available at http://localhost:8080/
• #10: This ZenPack has no special installation considerations. You should install the most recent version of the ZenPack for the version of Zenoss you're running.The easiest way to start monitoring CloudStack is to navigate to the Infrastructure page, click the + menu to add a device and choose Add CloudStack. Fill out the URL, API Key, and Secret Key fields then click OK. The URL should only include the protocol, host and port (i.e. http://cloudstack.example.com/). You can find or create the keys by logging into the CloudStack web interface and navigate to Accounts and users.Zenoss will then add the CloudStack device to the system along with all of its associated zones, pods and clusters. Monitoring will also start after the discovery is complete
• #11: Use Simple Network Management Protocol (SNMP) to configure the SNMP agent on CloudStack Management Server to generate asynchronous events, which are called traps. The traps are generated whenever there are abnormal conditions as observed by the Management Server. The traps are then sent to a remote device called a trap listener, which signals the abnormal condition on CloudStack.  The trap listener is typically an external management station such as Microsoft SCOM, HP Openview etc.Logging feature enables logging status and status information collected by various modules and components in a CloudStack environment. SYSLOG is a standard protocol for logging. It has two components -  the SYSLOG auditing module, which runs on the management server (of CloudStack), and the SYSLOG server, which can also run on the management server or on a remote system. SYSLOG uses UDP for the transfer of data.When configured,  the management server starts sending all the log information to the SYSLOG server, and the SYSLOG server can filter the log entries before storing them in a log file. A SYSLOG server can receive log information from more than one client and CloudStack management server can also send log information to more than one SYSLOG server.