You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since I can see there are many open issues with connection/compatibility issues and race conditions, maybe it would make sense to implement some metrics for central systems. I think it would be helpful to have real-time insights into a central system and do it in a standardized way.
There are two things that we could instrument: the websocket connection and the OCPPj layer. I'm particularly interested in the OCPPj layer instrumentation, as It would be useful in debugging OCPP-related issues, e.g. compatibility between a Charge point and a Central System/CPMS.
As to what format to expose the metrics in, I would suggest OpenTelemetry over Prometheus metrics, since it is being set as an industry standard, and you can easily convert/map from one format to another (using the OTel Collector for example).
I was thinking about:
Currenctly active connections/clients (gauge)
Connection ping/pong response time (per client)
Message rate (inbound/outbound)
Response success rate (inbound/outbound, per clientId, per message type, with error reason)
Request/response time (per client, message type)
Let me know your thoughs.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Since I can see there are many open issues with connection/compatibility issues and race conditions, maybe it would make sense to implement some metrics for central systems. I think it would be helpful to have real-time insights into a central system and do it in a standardized way.
There are two things that we could instrument: the websocket connection and the OCPPj layer. I'm particularly interested in the OCPPj layer instrumentation, as It would be useful in debugging OCPP-related issues, e.g. compatibility between a Charge point and a Central System/CPMS.
As to what format to expose the metrics in, I would suggest OpenTelemetry over Prometheus metrics, since it is being set as an industry standard, and you can easily convert/map from one format to another (using the OTel Collector for example).
I was thinking about:
Let me know your thoughs.
The text was updated successfully, but these errors were encountered: