View source for 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 [https://api.dmon.io/docs API docs] for models.

Example POST body:
 <nowiki>
{
  "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
  }
}</nowiki>


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 [https://prometheus.io/docs/concepts/metric_types/ 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.