-
Notifications
You must be signed in to change notification settings - Fork 51
Add error handling for Modbus exception response #69
Description
A modbus exception response returned from the modbus module or gateway, currently gives an HTTP 500 Internal Server Error to Prometheus. This seems ambiguous when modbus already has these exception codes, and it can be parsed along to Prometheus in order to get more insight earlier in the debugging.
This issue is inspired while looking for the error that caused me to create merge request #66, where a modbus exception 11 (Gateway Target Device Failed to Respond) was thrown, due to a race condition where Prometheus was querying the same target for a different sub module before getting a response from the modbus module / gateway of an earlier query. I currently only know of this device where it cannot handle such rate of requests: Power meter module: Peacefair PZEM-003/017.
A bit of reading on the modbus exception response: simplymodbus.com and schneider-electric
While Prometheus was only giving a HTTP 500 error, the modbus exporter showed ts=2024-03-11T11:49:04.880Z caller=modbus_exporter.go:134 level=error msg="failed to scrape" target=siteA.company.net:502 module=powermeter_peacefair_pzem_017 err="failed to scrape metrics for module 'powermeter_peacefair_pzem_017': metric 'power_voltage', address '400000': modbus: exception '11' (gateway target device failed to respond), function '132'" .
However, a tcpdump of the traffic between Prometheus and the modbus_exporter, and visualized with Wireshark, gives more light on what caused the modbus exception 11, a race condition as described above. Hint: filter in Wireshark for modbus.