-
Epic
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
Publish per-broker connection count/creation rate and limits metrics
-
False
-
None
-
False
-
No
-
To Do
-
MGDSRVS-170 - Improve Monitoring, Metrics and Observability capabilities to support Production Workloads
-
0% To Do, 0% In Progress, 100% Done
-
---
-
---
-
-
Currently Red Hat OpenShift Streams for Apache Kafka publishes an instance wide metrics for connection count and connection create rate. Sometimes, connections won't be exactly balanced across all the brokers of the instance and in these cases, the user needs a per broker view.
The following article describes the current state:
| Metric | Description |
|---|---|
| kafka_namespace:kafka_server_socket_server_metrics_connection_count:sum | Number of current client connections to the cluster. Kafka clients use persistent connections to interact with brokers in the cluster. For example, a consumer holds a connection to each broker it is receiving data from and a connection to its group coordinator. The Kafka instance type determines the maximum number of active connections. |
| kafka_namespace:kafka_server_socket_server_metrics_connection_creation_rate:sum | Number of client connection creations per second for the cluster. Kafka clients use persistent connections to interact with brokers in the cluster. A constant high number of connection creations might indicate a client issue. The Kafka instance type determines the maximum connection creation rate. |
The service actually publishes the limits per broker, but these aren't currently documented:
- kafka_instance_connection_limit
- kafka_instance_connection_creation_rate_limit
Proposed solution
The service should be changed to publish the follow metrics per broker.
- kas_broker_connection_total
- kas_broker_connection_limit
- kas_broker_connection_creation_rate
- kas_broker_connection_creation_rate_limit
The Console should continue to offer its instance wide connection view, but it should also offer the user the ability to drill down to the per-broker view. Following the same UI approach as is being taken for MGDSTRM-8891 would work.
The existing metrics should be maintained for a period in a deprecated state and then be removed.
- blocks
-
MGDSTRM-10092 Create a blog post demonstrating how to monitor your usage against service limits
-
- Closed
-
