Service metrics
Service metrics are provided for specific service types. You can use these to keep track of how a service is behaving under load.
Metrics monitor specific resources within your application, such as a specific Data Server query, or Event Handler event.
Consolidator
The consolidator exposes metrics to measure latency.
A high latency indicates that the consolidator is struggling to keep up.
| Metric | Explanation |
|---|---|
| calculation_latency | latency for performing a calculation |
| consolidator_input_latency | latency for processing an update |
| consolidator_output_latency | latency for writing to database |
Data Server
The data server metrics expose a number of metrics to help monitor the service. These metrics expose the number of users connected, and various latency statistics.
Data Servers provide real-time views to users, so each connection to a query has a resource cost. This is not a problem under normal usage, where connections are managed by the Genesis framework. The Genesis client automatically releases these connections when they are no longer required. However, if a bespoke client is used, then these connections might not be closed properly.
A high user or connection count can indicate a problem here.
The latency metrics track how well a Data Server is handling requests.
| Metric | Explanation |
|---|---|
| user_count | The number of users connected to a query |
| connection_count | The number of connections to a query |
| data_logon.processing_latency | The latency for processing DATA_LOGON request |
| enriched_lookup_latency | The latency for enriching data |
| lookup_latency | The latency for a look-up |
| message_publication_latency | The latency for publishing an update |
Event Handler
The event handler latency metrics show how long it takes for a specific eventHandler in the Event Handler to process a message.
| Metric | Explanation |
|---|---|
| processing_latency | The latency for processing events (kts event handler) |
| latency | The latency for processing events (kotlin/java event handler |
Request Server
The Request Server latency metrics show how long it takes for a specific requestReply in the Request Server to process a message.
| Metric | Explanation |
|---|---|
| message_processing_latency | The latency for processing requests |
Router
The metrics for Genesis Router measure the number of connections and the processing latency.
| Metric | Explanation |
|---|---|
| active_connections | The number of client connections |
| message_processing_latency | The latency for processing messages |
Streamer
The metrics for Streamer measure how long it takes to receive a response.
| Metric | Explanation |
|---|---|
| replay_processing_latency | The latency for processing a reply |
Streamer Client
The Streamer Client has a processing latency. As part of the process, it tracks the number of unreplied messages.
The Streamer Client publishes messages, and tracks ACKs received in response to those messages.
In order not to overwhelm the consumer, the Streamer Client has a setting for the maximum number of unreplied messages. When the maximum number is reached, it stops sending messages.
If the unreplied message size stays at a high number, the possible causes are:
- The consumer is unable to keep up with the message flow.
- The consumer is not sending an ack in response to the messages.
| Metric | Explanation |
|---|---|
| unreplied_messages_size | The number of outstanding messages |
| outbound_processing_latency | The processing latency |