Problems with "null" values: possibly return 0 or a default value?

[jeremyvisser]

I am trying to scrape the JSON data feed off a hardware appliance with json_exporter, but the problem is that it sometimes returns a number, but other times returns null. This causes non-continuous metrics in Prometheus, which causes a cascade of difficulties.

The hardware appliance in question is an SMA Sunny Boy solar inverter, and I'm trying to avoid writing my own shim to ingest the data into Prometheus. The JSON it outputs looks roughly like (snipped for clarity):

{"result": { "0199-B3549FA1": {"6100_40263F00": {"1": [{"val": 1200}]}}}}

Using this config:

metrics:
- name: pv_power
  path: "{ .result..['6100_40263F00']..val }"

I get the sane value of:

pv_power 1200

However, when the sun sets, the solar inverter for some bizarre reason outputs null:

{"result": { "0199-B3549FA1": {"6100_40263F00": {"1": [{"val": null}]}}}}

This results in the metric becoming NaN:

pv_power NaN

And this makes it impossible to do certain formulas in Prometheus (e.g. calculating my house power (pv_power - grid_power_supplied) + grid_power_absorbed because when one of the metrics is missing, the entire calculation fails).

To avoid writing my own shim to parse the input JSON, I would need either NaN to be interpreted as 0, or have the ability to specify a default value.

[rustycl0ck]

Having an option to specify a default value for null seems reasonable to me. Maybe we can have something like replace_null_with: option for each metric. The default can remain NaN, but can be overridden for specific metrics if needed. If you can send a PR, I can review it.

[SuperQ]

From a Prometheus best practice, null data should be dropped/ignored. Using NaN for null is not recomended.

[rustycl0ck]

Thanks @SuperQ , I see how replacing null data with a zero or NaN or any other value can lead to wrong calculations later (like if we replace null with a zero, the calculation of average for this data would then shift towards zero which would be incorrect). I guess it is a bug in the current version of this exporter then.