Commit 9ef3e121 authored by Michele Tartara's avatar Michele Tartara

Update the monitoring agent design document

This commit updates the design document of the monitoring agent according
to what has already been discussed in various meetings and email threads.
Signed-off-by: default avatarMichele Tartara <>
Reviewed-by: default avatarIustin Pop <>
parent d78970ba
......@@ -204,9 +204,64 @@ beginning it will only be possible to query the full status report.
Format of the report
TBD (this part needs to be completed with the format of the JSON and the
types of the various variables exported, as they get evaluated and
The report of the will be in JSON format, and it will present an array
of report objects.
Each report object will be produced by a specific data collector.
Each report object includes some mandatory fields, to be provided by all
the data collectors, and a field to contain data collector-specific
Here follows a minimal example of a report::
"name" : "TheCollectorIdentifier",
"version" : "1.2",
"format_version" : 1,
"timestamp" : 1351607182000000000,
"data" : { "plugin_specific_data" : "go_here" }
"name" : "AnotherDataCollector",
"version" : "B",
"format_version" : 7,
"timestamp" : 1351609526123854000,
"data" : { "plugin_specific" : "data",
"some_late_data" : { "timestamp" : "SPECIFIC_TIME",
... }
Here is the description of the mandatory fields of each object:
the name of the data collector that produced this part of the report.
It is supposed to be unique inside a report.
the version of the data collector that produces this part of the
report. Built-in data collectors (as opposed to those implemented as
plugins) should have "B" as the version number.
the format of what is represented in the "data" field for each data
collector might change over time. Every time this happens, the
format_version should be changed, so that who reads the report knows
what format to expect, and how to correctly interpret it.
the time when the reported data were gathered. Is has to be expressed
in nanoseconds since the unix epoch (0:00:00 January 01, 1970). If not
enough precision is available (or needed) it can be padded with
zeroes. If a report object needs multiple timestamps, it can add more
and/or override this one inside its own "data" section.
this field contains all the data generated by the data collector, in
its own independently defined format. The monitoring agent could check
this syntactically (according to the JSON specifications) but not
Data collectors
......@@ -218,6 +273,10 @@ node without passing through the agent daemon. Each data collector will
report specific data about its subsystem and will be documented
If a data collector is run independently, it should print on stdout its
report, according to the format corresponding to a single data collector
report object, as described in the previous paragraph.
Mode of operation
......@@ -256,7 +315,8 @@ Implementation order
We will implement the agent system in this order:
- initial example data collectors (eg. for drbd and instance status)
- initial example data collectors (eg. for drbd and instance status.
Data collector-specific report format TBD).
- initial daemon for exporting data
- RPC updates for instance status reasons and disk to instance mapping
- more data collectors
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment