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