Difference between revisions of "Zabbix-agent-adoption"
m (→Introduction) |
m (→Introduction) |
||
| Line 13: | Line 13: | ||
including two CPUPollster cares about: VCPU number and running time. | including two CPUPollster cares about: VCPU number and running time. | ||
| − | Such pollsters work well for those data easily available to a hypervisor (http://www.mirantis.com/blog/openstack-metering-using-ceilometer/), while ignoring | + | Such pollsters work well for those data easily available to a hypervisor (http://www.mirantis.com/blog/openstack-metering-using-ceilometer/), while ignoring detailed and precise<br /> |
guest system metrics which are not provided by a hypervisor. As a simple case study,<br /> | guest system metrics which are not provided by a hypervisor. As a simple case study,<br /> | ||
we can compare what CPUPollster provides with those CPU monitoring items supported<br /> | we can compare what CPUPollster provides with those CPU monitoring items supported<br /> | ||
| Line 29: | Line 29: | ||
This work aims at leveraging existing monitoring assets and expertises in system<br /> | This work aims at leveraging existing monitoring assets and expertises in system<br /> | ||
administration teams to the best extent, instead of removing or replacing them with<br /> | administration teams to the best extent, instead of removing or replacing them with<br /> | ||
| − | efforts. An adoption mechanism between | + | efforts. An adoption mechanism between 3rd-party monitoring agents in instances<br /> |
| − | compute agents in compute nodes is added, therefore Ceilometer | + | and Ceilometer compute agents in compute nodes is added, therefore Ceilometer<br /> |
| − | + | can poll data from those agents directly to enhance its capability of monitoring<br /> | |
| − | + | instances. | |
| − | |||
== Design and implementation == | == Design and implementation == | ||
To be added | To be added | ||
Revision as of 13:52, 1 November 2013
- Launchpad Entry: CeilometerSpec:Zabbix-agent-adoption
- Created: Oct. 25, 2013
- Contributors: Yu Zhang
Introduction
Currently, Ceilometer collects instance data via compute agents installed on every
OpenStack compute nodes. PollingTasks in a compute agent invoke multiple pollsters,
which then call hypervisor-dependent inspectors for metering various metrics. As
an example, the CPUPollster calls the inspect_cpus() method of a hypervisor-dependent
inspector object to get VCPU data. If the hypervisor is KVM, inspect_cpus() calls
the info() method of the virDomain class of libvirt, then returns a list of 5 data elements,
including two CPUPollster cares about: VCPU number and running time.
Such pollsters work well for those data easily available to a hypervisor (http://www.mirantis.com/blog/openstack-metering-using-ceilometer/), while ignoring detailed and precise
guest system metrics which are not provided by a hypervisor. As a simple case study,
we can compare what CPUPollster provides with those CPU monitoring items supported
by Zabbix, one of the most pupular system monitor tool. A snapshot of Zabbix web
console is shown in the following figure.
In practice those guest system metrics provided by Zabbix are highly valuable for
both OpenStack Admins and tenants, which is verified by our own experiences and
feedback from other companies using OpenStack. Therefore, Zabbix has been
deployed in many product-oriented OpenStack clouds to achieve detailed and precise
monitoring. Other popular 3rd-party monitoring tools include Nagios, Ganglia, etc.
This work aims at leveraging existing monitoring assets and expertises in system
administration teams to the best extent, instead of removing or replacing them with
efforts. An adoption mechanism between 3rd-party monitoring agents in instances
and Ceilometer compute agents in compute nodes is added, therefore Ceilometer
can poll data from those agents directly to enhance its capability of monitoring
instances.
Design and implementation
To be added
