Revision 777a3109
b/doc/design-monitoring-agent.rst | ||
---|---|---|
321 | 321 |
for lvm storage, "unreachable" for network based storage or "filesystem error" |
322 | 322 |
for filesystem based implementations. |
323 | 323 |
|
324 |
Diskstats collector |
|
325 |
******************* |
|
326 |
|
|
327 |
This storage data collector will gather information about the status of the |
|
328 |
disks installed in the system, as listed in the /proc/diskstats file. This means |
|
329 |
that not only physical hard drives, but also ramdisks and loopback devices will |
|
330 |
be listed. |
|
331 |
|
|
332 |
Its ``kind`` in the report will be ``0`` (`Performance reporting collectors`_). |
|
333 |
|
|
334 |
Its ``category`` field in the report will contain the value ``storage``. |
|
335 |
|
|
336 |
When executed in verbose mode, the ``data`` section of the report of this |
|
337 |
collector will be a list of items, each representing one disk, each providing |
|
338 |
the following fields: |
|
339 |
|
|
340 |
``major`` |
|
341 |
The major number of the device. |
|
342 |
|
|
343 |
``minor`` |
|
344 |
The minor number of the device. |
|
345 |
|
|
346 |
``name`` |
|
347 |
The name of the device. |
|
348 |
|
|
349 |
``reads`` |
|
350 |
This is the total number of reads completed successfully. |
|
351 |
|
|
352 |
``mergedReads`` |
|
353 |
Reads which are adjacent to each other may be merged for efficiency. Thus |
|
354 |
two 4K reads may become one 8K read before it is ultimately handed to the |
|
355 |
disk, and so it will be counted (and queued) as only one I/O. This field |
|
356 |
specifies how often this was done. |
|
357 |
|
|
358 |
``secRead`` |
|
359 |
This is the total number of sectors read successfully. |
|
360 |
|
|
361 |
``timeRead`` |
|
362 |
This is the total number of milliseconds spent by all reads. |
|
363 |
|
|
364 |
``writes`` |
|
365 |
This is the total number of writes completed successfully. |
|
366 |
|
|
367 |
``mergedWrites`` |
|
368 |
Writes which are adjacent to each other may be merged for efficiency. Thus |
|
369 |
two 4K writes may become one 8K read before it is ultimately handed to the |
|
370 |
disk, and so it will be counted (and queued) as only one I/O. This field |
|
371 |
specifies how often this was done. |
|
372 |
|
|
373 |
``secWritten`` |
|
374 |
This is the total number of sectors written successfully. |
|
375 |
|
|
376 |
``timeWrite`` |
|
377 |
This is the total number of milliseconds spent by all writes |
|
378 |
|
|
379 |
``ios`` |
|
380 |
The number of I/Os currently in progress. |
|
381 |
The only field that should go to zero, it is incremented as requests are |
|
382 |
given to appropriate struct request_queue and decremented as they finish. |
|
383 |
|
|
384 |
``timeIO`` |
|
385 |
The number of milliseconds spent doing I/Os. This field increases so long |
|
386 |
as field ``IOs`` is nonzero. |
|
387 |
|
|
388 |
``wIOmillis`` |
|
389 |
The weighted number of milliseconds spent doing I/Os. |
|
390 |
This field is incremented at each I/O start, I/O completion, I/O merge, |
|
391 |
or read of these stats by the number of I/Os in progress (field ``IOs``) |
|
392 |
times the number of milliseconds spent doing I/O since the last update of |
|
393 |
this field. This can provide an easy measure of both I/O completion time |
|
394 |
and the backlog that may be accumulating. |
|
395 |
|
|
324 | 396 |
DRBD status |
325 | 397 |
*********** |
326 | 398 |
|
Also available in: Unified diff