In.dmon.io

GET

A GET to the /{telemetryKey}/{jobName} endpoint acts as a heartbeat check-in for a job/device. Get {telemetryKey} from the dmon.io UI.

POST

A POST to the same /{telemetryKey}/{jobName} endpoint performs the same heartbeat check-in function, but also requires a JSON body including optional metrics ingest values. See the "Metrics" schema in the API docs for models.

Example POST body:

{
  "base": {
    "c_cpu_s": 872709277.5,
    "g_cpu_temp_C": 41.9,
    "c_netrx_B": 76160876159,
    "c_nettx_B": 8765972577,
  },
  "disk": [
    {
      "n": "/",
      "sz_B": 4000000000000,
      "g_av_B": 1859230828522,
      "c_ior": 2828522,
      "c_iow": 1852752
    }
  ],
  "container": [
    {
      "n": "nginx",
      "c_cpu_s": 281.5282,
      "g_mem_B": 91255
    }
  ],
  "info": {
    "cpus": 2
  }
}

Each of the metrics under "base" is optional to send.

• "c_" denotes a COUNTER metric, representing a total counter, not a point in time value
• "g_" denotes a GAUGE metric, representing a point in time value
• See prometheus.io/docs/concepts/metric_types/ for conceptual explanation.

For "disk":

• There are a maximum of 4 entries. More than this and the entire disk portion is dropped at ingest.
• Disk/mountpoint names can be a maximum of 20 characters. This is truncated if longer.
• Items are ordered in the API and UI in the order in which they are sent at ingest.

For "container":

• There are a maximum of 20 entries. More than this and the entire container portion is dropped at ingest.
• Same 20 char limit as for "disk".
• Same ordering note as for "disk".
• dmon_linux.py can be prompted to send this data with the "--container" flag. Note that you might have to edit the script if you're not using cgroup2 and some other assumptions made so far.

For "info":

• "cpus" is only used for the UI to do some division on percentages of reported cpu seconds.