Skip to content

Feature request: Observability (metrics) #334

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
xBlaz3kx opened this issue Jan 16, 2025 · 0 comments
Open

Feature request: Observability (metrics) #334

xBlaz3kx opened this issue Jan 16, 2025 · 0 comments

Comments

@xBlaz3kx
Copy link
Contributor

xBlaz3kx commented Jan 16, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant