Platform
Logging and monitoring
What the platform records while it runs, what it exports, and what a bank can see.
Drafted from the Everest framework reference. The metric families, exporters and event transports are what the framework provides; which of them this installation switches on, and what a bank is given access to, is not confirmed.
- Log retention, and whether a bank can query the platform's logs or only its own.
- Whether trace context propagates across the boundary so a bank can correlate its request id with a platform trace.
- Which metric families each of the seven services enables.
Three separate things get called monitoring, and they answer different questions. This page separates them because the answer to "why did that call fail" is in one of them and not the other two.
Logs — what happened on one call
Every service writes structured logs. The thing to know as an integrator is what identifies your call inside them.
A card operation carries a reference number or a log id in its response, and mutations return one specifically so they can be reversed. That value is the handle. When you raise a support case, the reference is what makes it answerable; a timestamp and an endpoint name are not enough on a platform handling every card in a portfolio.
What never reaches a log: card numbers, CVVs and PIN blocks are encrypted at field level, so a log line carries the ciphertext or the masked value. That holds on your side too — a response body logged wholesale is the one place this protection can be undone, and it would be undone by you rather than by the platform.
Metrics — what is happening across all calls
The platform emits OpenTelemetry metrics through a single meter and exports them to Prometheus through a collector. Grafana draws from Prometheus.
Three metric families ship with the framework:
OpenTelemetry · metric families
| Family | What it counts |
|---|---|
| HTTP | Requests received, response duration, requests in flight, client latency, outbound calls |
| Transactions | One-way messages accepted, end-to-end latency, queued, active |
| Hosting | Thread pool usage |
A service can define its own family on top, named everest_<service>_, so a
custom counter reads everest_cardissuing_total rather than a bare name that
collides with another service's.
Metrics are per service. A capability spanning three services shows up in three places, which is why the dashboard question on the monitoring page matters: the useful view is assembled, not emitted.
Events — what other systems need to know
Services consume events through one interface with the transport chosen by configuration: Kafka, RabbitMQ, NATS or HTTP polling. A service with no transport configured falls back to a null consumer and starts normally rather than failing, which means an unconfigured environment looks healthy and is simply quiet.
That fallback is worth knowing during integration testing. If you are expecting events in the sandbox and seeing none, "no transport configured" and "no events produced" look identical from outside.
The topic catalogue is not published. What a bank can subscribe to, under what names, with what payload and what ordering guarantee, is the open question listed on the monitoring page — and naming topics here without confirmation would be handing you a subscription contract nothing upholds.
What a bank can see today
Honestly: less than this page might suggest. The platform emits all of the above; what is exposed to an integrating bank rather than to DgPays operations is not settled. Treat the metric families as real and the access model as an open question, and raise it during programme design.