Revision 9ef3e121 doc/design-monitoring-agent.rst
b/doc/design-monitoring-agent.rst | ||
---|---|---|
204 | 204 |
Format of the report |
205 | 205 |
-------------------- |
206 | 206 |
|
207 |
TBD (this part needs to be completed with the format of the JSON and the |
|
208 |
types of the various variables exported, as they get evaluated and |
|
209 |
decided) |
|
207 |
The report of the will be in JSON format, and it will present an array |
|
208 |
of report objects. |
|
209 |
Each report object will be produced by a specific data collector. |
|
210 |
Each report object includes some mandatory fields, to be provided by all |
|
211 |
the data collectors, and a field to contain data collector-specific |
|
212 |
data. |
|
213 |
|
|
214 |
Here follows a minimal example of a report:: |
|
215 |
|
|
216 |
[ |
|
217 |
{ |
|
218 |
"name" : "TheCollectorIdentifier", |
|
219 |
"version" : "1.2", |
|
220 |
"format_version" : 1, |
|
221 |
"timestamp" : 1351607182000000000, |
|
222 |
"data" : { "plugin_specific_data" : "go_here" } |
|
223 |
}, |
|
224 |
{ |
|
225 |
"name" : "AnotherDataCollector", |
|
226 |
"version" : "B", |
|
227 |
"format_version" : 7, |
|
228 |
"timestamp" : 1351609526123854000, |
|
229 |
"data" : { "plugin_specific" : "data", |
|
230 |
"some_late_data" : { "timestamp" : "SPECIFIC_TIME", |
|
231 |
... } |
|
232 |
} |
|
233 |
} |
|
234 |
] |
|
235 |
|
|
236 |
Here is the description of the mandatory fields of each object: |
|
237 |
|
|
238 |
name |
|
239 |
the name of the data collector that produced this part of the report. |
|
240 |
It is supposed to be unique inside a report. |
|
241 |
|
|
242 |
version |
|
243 |
the version of the data collector that produces this part of the |
|
244 |
report. Built-in data collectors (as opposed to those implemented as |
|
245 |
plugins) should have "B" as the version number. |
|
246 |
|
|
247 |
format_version |
|
248 |
the format of what is represented in the "data" field for each data |
|
249 |
collector might change over time. Every time this happens, the |
|
250 |
format_version should be changed, so that who reads the report knows |
|
251 |
what format to expect, and how to correctly interpret it. |
|
252 |
|
|
253 |
timestamp |
|
254 |
the time when the reported data were gathered. Is has to be expressed |
|
255 |
in nanoseconds since the unix epoch (0:00:00 January 01, 1970). If not |
|
256 |
enough precision is available (or needed) it can be padded with |
|
257 |
zeroes. If a report object needs multiple timestamps, it can add more |
|
258 |
and/or override this one inside its own "data" section. |
|
259 |
|
|
260 |
data |
|
261 |
this field contains all the data generated by the data collector, in |
|
262 |
its own independently defined format. The monitoring agent could check |
|
263 |
this syntactically (according to the JSON specifications) but not |
|
264 |
semantically. |
|
210 | 265 |
|
211 | 266 |
|
212 | 267 |
Data collectors |
... | ... | |
218 | 273 |
report specific data about its subsystem and will be documented |
219 | 274 |
separately. |
220 | 275 |
|
276 |
If a data collector is run independently, it should print on stdout its |
|
277 |
report, according to the format corresponding to a single data collector |
|
278 |
report object, as described in the previous paragraph. |
|
279 |
|
|
221 | 280 |
|
222 | 281 |
Mode of operation |
223 | 282 |
----------------- |
... | ... | |
256 | 315 |
|
257 | 316 |
We will implement the agent system in this order: |
258 | 317 |
|
259 |
- initial example data collectors (eg. for drbd and instance status) |
|
318 |
- initial example data collectors (eg. for drbd and instance status. |
|
319 |
Data collector-specific report format TBD). |
|
260 | 320 |
- initial daemon for exporting data |
261 | 321 |
- RPC updates for instance status reasons and disk to instance mapping |
262 | 322 |
- more data collectors |
Also available in: Unified diff