833e5946fe
A powerful metric to watch for a swift cluster is the number of handoff partitions on a drive on a storage node. A build up of handoff nodes on a particular server could indicate a disk problem somewhere in the cluster. A bottleneck somewhere. Or better, when would be a good time to rebalance the ring (as you'd want to do it when existing backend data movement is at a minimum. So it turns out to be a great visualisation of the health of a cluster. That's what this check plugin does. Each instance check takes the following values: ring: <path to a Swift ring file> devices: <path to the directory of mountpoints> granularity: <either server or device> To be able to determine primary vs handoff partitions on a drive the swift ring needs to be consulted. If a storage node stores more then 1 ring, and an instance would be defined for each. You give swift a bunch of disks. These disks are placed in what swift calls the 'devices' location. That is a directory where a mount point for each mounted swift drive is located. Finally, you can decide on the granularity, which defaults to `server` if not defined. Only 2 metrics are created from this check: swift.partitions.primary_count swift.partitions.handoff_count But with the hostname dimension a ring dimension will also be set. Allowing the graphing of the handoff vs partitions of each ring. When the granularity is set to device, then an additional dimension to the metric is added, the device name (the name of the devices mount point). This allows the graphing and monitoring of each device in a server if a finer granularity is required. Because we need to consult the Swift ring there is a runtime requirement on the Python Swift module being installed. But this isn't required for the unit tests. Making it a runtime dependency means when the check is loaded it'll log an error and then exit if it can't import the swift module. This is the second of two Swift check plugins I've been working on. For more details see my blog post[1] [1] - https://oliver.net.au/?p=358 Change-Id: Ie91add9af39f2ab0e5b575390c0c6355563c0bfc |
||
---|---|---|
conf.d | ||
docker | ||
docs | ||
monasca_agent | ||
monasca_setup | ||
packaging | ||
playbooks | ||
tests | ||
tests_to_fix | ||
.gitignore | ||
.gitreview | ||
.stestr.conf | ||
.testr.conf | ||
.zuul.yaml | ||
agent.yaml.template | ||
bindep.txt | ||
LICENSE | ||
mkdocs.yml | ||
README.rst | ||
requirements.txt | ||
setup.cfg | ||
setup.py | ||
test-requirements.txt | ||
tox.ini |
Team and repository tags
Introduction
The Monasca Agent is a modern Python monitoring agent for gathering metrics and sending them to the Monasca API. The Agent supports collecting metrics from a variety of sources as follows:
- System metrics
-
such as cpu and memory utilization.
- Prometheus
-
The Monasca Agent supports scraping metrics from endpoints provided by Prometheus exporters or Prometheus instrumented applications.
- Statsd
-
The Monasca Agent supports an integrated StatsD daemon which can be used by applications via a statsd client library.
- OpenStack metrics
-
The agent can perform checks on OpenStack processes.
- Host alive
-
The Monasca Agent can perform active checks on a host to determine if it is alive using ping (ICMP) or SSH.
- Process checks
-
The Monasca Agent can check a process and return several metrics on the process such as a number of instances, memory, io and threads.
- Http Endpoint checks
-
The Monasca Agent can perform active checks on http endpoints by sending an HTTP request to an API.
- Service checks
-
The Monasca Agent can check services such as MySQL, RabbitMQ, and many more.
- Nagios plugins
-
The Monasca Agent can run Nagios plugins and send the status code returned by the plugin as a metric to the Monasca API.
The Agent can automatically detect and setup checks on certain processes and resources.
The Agent is extensible through the configuration of additional plugins, written in Python.
Detailed Documentation
For an introduction to the Monasca Agent, including a complete list of the metrics that the Agent supports, see the "Agent" detailed documentation.
The Agent is extensible through the configuration of additional check and setup plugins, written in Python. See the "Agent Customizations" detailed documentation.
- Agent
-
https://opendev.org/openstack/monasca-agent/src/branch/master/docs/Agent.md
- Agent Customizations
-
https://opendev.org/openstack/monasca-agent/src/branch/master/docs/Customizations.md
- Monasca Metrics
-
https://opendev.org/openstack/monasca-agent/src/branch/master/docs/MonascaMetrics.md
- Agent Plugin details
-
https://opendev.org/openstack/monasca-agent/src/branch/master/docs/Plugins.md
- License: Simplified BSD License
- Source: https://opendev.org/openstack/monasca-agent
- Bugs: https://storyboard.openstack.org/#!/project/861 (please use bug tag)