The idea behind this activity is to provide a number of reference container images (or a telemetry microservice) that is hosted @https://hub.docker.com/r/opnfv/barometer/. Installers would use these containers for OPNFV scenarios. End users would no longer need to build collectd or any of the applications barometer uses from source.
The advantages of the containerisation + ansible support in barometer is the following:
- Easier installation, configuration, collection and visualization of the NFVI Metrics.
- It will also allow us to deploy collectd at scale in an easy manageable way.
- Seemless upgrades support
- Will support a HA and a non HA deployment.
- Speed up deployment of collectd by providing golden images.
The full list of containers includes:
- Collectd container image: barometer-collectd (https://hub.docker.com/r/opnfv/barometer-collectd/)
- SNMPD container image - (WIP)
- Kafka container image: barometer-kafka (https://hub.docker.com/r/opnfv/barometer-kafka/)
- InfluxDB container image: barometer-influxdb (https://hub.docker.com/r/opnfv/barometer-influxdb/)
- Grafana container image: barometer-grafana (https://hub.docker.com/r/opnfv/barometer-grafana/)
- Collectd VES application container: barometer-ves (https://hub.docker.com/r/opnfv/barometer-ves/)
NOTE 1: The containers can run on the same host or on multiple hosts. Default configuration assumes everything is running on a single host, but this is easily overridden
NOTE 2: The Zookeeper container used is the official zookeeper container from docker hub and not a custom built container.
The following sections will describe each of the containers in more detail.
The collectd container should include the following barometer plugins (above and beyond what is included in collectd by default):
- OVS Stats
- OVS Events
- Intel RDT
- Intel PMU
- SNMP Agent
- OVS PMD stats
- The container will run as a privileged container.
- The collectd container should work standalone - Ansible will be used to disable plugins that aren't supported on the platform - but essentially if someone pulls the container image it should have everything built in and configured. It is still advised that the end user overrides the default configuration with appropriate configurations for each of the plugins.
- The container will use a CentOS 7 image.
- Ansible scripts will also be provided so that it can be configured and deployed at scale in any environment.
- NOTE DPDK plugins can be left out until the DPDK community pushes their new stats model and plugin to collectd.
AgentX is a protocol defined in RFC 2741 allowing a master agent to be extended by independent sub-agents. The architecture was designed to be simple in respect of authorisation, privacy and encoding. It offers full support for data retrieval (Get, GetNext and GetBulk), data modifications (Set) and notifications (Trap). AgentX transport mappings are specified for UNIX domain sockets and TCP. Every connection is spit up into several sessions, which in turn can convey several transactions.
The collectd SNMP Agent plugin registers with a SNMP Master Agent as sub agent using net-snmp library. The plugin manages MIBs provided in a configuration file where each OID is mapped to appropriate type of values that are collected by collectd read plugins. The plugin is also responsible for collecting, handling and registration of scalar and tabular values, providing data to master agent when GET/GETNEXT request is received.
The SNMP Master agent in our case is SNMPD - so we need a container running SNMPD in order to be able to send SNMP Replies to a SNMP collector. For more information on the implementation details of the collectd SNMP plugin please see: SNMP Agent HLD
This container simply runs an Influxdb instance we can send the collectd metrics to
This container runs the grafana front end with the barometer dashboards being fed metrics from the influxdb container.
Collectd can send telemetry to a VES application that will normalize metrics it receives into a VES format. The messaging bus being used between collectd and the VES application is Kafka. A container running Kafka is needed to bridge the gap between collectd and the VES application. For more information on Kafka and the VES application please see: VES plugin updates
Collectd can send telemetry to a VES application that will normalize metrics it receives into a VES format. The messaging bus being used between collectd and the VES application is Kafka. A container running the VES application is required to normalize the data and send it to a VES collector. For more information on the VES application please see: VES plugin updates
The barometer container release scheme is being updated to include latest Collectd features in following way:
- Container with latest stable Collectd release
- Container with Collectd master
- Container with Cherrypicked PRs from Collectd.
More details are at 3 Container approach page.