JSONLevels

njmon can operate generating multiple or single level JSON output

I decided that multiple levels is easier to understand and parse so all testing is done with the default Multiple level style.

There was a lot of debate on single or multiple levels of JSON in the njmon output file question, so I implemented both. They both have merits. I think the multiple level in willing as it makes any Python code any order of magnitude simpler.

Single level: Simple all at one level in a long list of "name": value pairs - in Python terms this is a single dictionary:

{
    "cpu_usr": 50,
    "cpu_sys": 10,
    "cpu_wait": 5,
    "cpu_idle": 35,
    "mem_size": 32000,
    "mem_free": 320,
. . . 
}

To extract data of a particular resources you have to look for labels including "cpu_" or "mem_" The code has to be aware of the label names.

Multiple level: stats are grouped together by function (CPU, memory, disks etc.). While this looks more complex it has advantages. You don't need to evaluate the "names" to determine for example where CPU stats end and memory stats start. In Python terms this is dictionaries inside the main dictionary. Python allows looping on a dictionary to extract each element within it one at a time.

>>> for statname in jsondata["cpu"]:
...     print("name=%s value=%d" % (statname, j["cpu"][statname]))
...
name=usr value=50
name=sys value=10
name=wait value=5
name=idle value=35

This is very helpful as most servers have different numbers of CPU, disks and networks etc.

{
      "cpu": {
           "usr": 50,
           "sys": 10,
           "wait": 5,
           "idle": 35
       },
    "memory": {
           "size": 32000,
           "free": 320
      }
. . .
}

So multiple level JSON allows Python code to parse the data transparently (i.e. not hard coded njmon specific label names) and handle any changes to the data or numbers of elements like changing numbers of CPU, disk, network etc.