Using Python data source plugins in Zenoss is a great way to collect data, and probably a better way than using command datasources. Python data sources come with the introduction of the PythonCollector ZenPack, so this ZenPack is required in order to start using Python data sources in our own ZenPacks.
Python data source plugins work exceptionally great in replacing data collection logic in custom daemons written in Python. This means that the ZenPacks's code is greatly reduced because we do not have to create configuration service, and custom daemon code.
Moreover, while Python data source plugins are Python-based, we can still execute shell commands within the plugin.
Example Scenario: BMC Power Status
For this post, I will be using an example where we will be executing an ipmitool command to check the power chassis status of a BMC device.
If I run the following command from my shell:
ipmitool -H $BMC_IP -I lanplus -U admin -P admin power status
I get the following output:
Chassis Power is on
What we want is our data source plugin to periodically and continuously execute this command and obtain the value. Our ZenPack will then proceed to:
Map the value into a boolean property of a custon zenpacklib class.
Create a CRITICAL event if the power status is off or if the command fails. Create a CLEAR event if the power status is on.
Update the device model with the new property value.
The Zenoss Zendmd Tips Wiki page contains a few useful tricks using zendmd to perform tasks. In this post I am adding more tricks that I discover and learn along the way.
Removing Device Classes
We can easily remove device classes within zendmd with a simple command. Assuming we want to remove the default “KVM” device class:
Juju is a great tool that allows us to deploy many services in a local or cloud environment. Services are deployed into virtual containers and can be removed and re-deployed at any time. It is perfect for creating sandbox and test environments for specific kind of services that you develop for.
In this post I will explain how easy it is to get started with Juju in a local environment.
Installation
To start we will need to add the necessary repository from where we will retrieve the Juju packages:
Before we set up the local environment, let's first generate a configuration file. This file will contain the configuration for many kinds of environments (OpenStack, AWS, MaaS, etc.), including a local environment configuration. We will generate the file and then switch to the local environment:
juju generate-config
juju switch local
Once we have switched to the local environment, we can simply bootstrap the environment with the following command:
juju bootstrap
After the process is complete, we are now ready to start using Juju.
Similar to my post on some must-know concepts about JavaScript for beginners, this is a list of concepts that show how C differs from other programming languages. These are concepts that you must know if you are to become a good C programmer.
Boolean Types
C actually does not have a boolean type. They are usually defined like this:
#define BOOL char#define FALSE 0#define TRUE 1
However it is argued that it is a better practice to simply use integers instead (0 and 1).
Memory Address of Array Elements
In C, arrays have a contiguous memory allocation. We can verify this by printing the memory addresses of each element of an array. We can do so using & to access the memory location of the array element:
intmain(){charvowels[]={'a','e','i','o','u'};for(inti=0;i<5;i++){printf("Address of vowel [%d]: %u\n",i,&vowels[i]);}return0;}
The above code will produces the following output for me:
When monitoring OpenStack using the OpenStack Infrastructure ZenPack integrated with Ceilometer, it is possible to get fast virtual machine state changes (on/off powering, etc.) by receiving events sent from Ceilometer to Zenoss.
However I discovered that when trying to get the same effect for live migration (live migrating a virtual machine from one compute node to another) scenarios, this would not work. I proceeded to investigate why.
Ceilometer Dispatcher Live Migration Events
I decided that the first thing to check was if the Zenoss Ceilometer dispatcher was capturing and sending the live migration events to Zenoss. Indeed, the logs can be found in Ceilometer under /var/log/ceilometer/ceilometer-collector.log: