Metrics

Problem

Due to Prisma being quite of a black box, I suggest adding a metrics functionality to the client, allowing users to get a snapshot of the current state of the Query Engine.

Suggested solution

We’d have a method prisma.metrics() that’d return an object with information about the underlying engine, for example:

• Current maximum connections
• Current connections in use
• Requests processed so far
• Number of errors
• Histogram data of response times

Alternatives

People might say structured logs are an alternative for metrics, but it’s more of an addition. With logs, users can detect and inspect events in the system, with metrics, they can observe the general status of the system. Also stats like histograms are easier to do with metrics than from structured logs. And structured logs are useful for investigating failures.

Logs are also expensive to store and transfer, which means storage over a few days is costing a lot of money. Metrics can be stored for some months with the same money.

Additional context

Prisma should provide an object of the current status. Users can then convert this to a Prometheus endpoint, or additionally send the data to timescale databases such as InfluxDB to be graphed with Grafana.

Metrics are one of the key points of monitoring a running system, and we should provide as much data as possible from Prisma for our users to graph.

[pimeys]

Yay, thank you for the team for the hard work to make this happen. I’ll try it ASAP.

[pimeys]

And, not to discard your suggestion, telemetry is extremely important to tackle as well as metrics and structured logs.