Knative Eventing metrics¶
Administrators can view metrics for Knative Eventing components.
Broker - Ingress¶
Use the following metrics to debug how broker ingress performs and what events are dispatched via the ingress component.
By aggregating the metrics over the http code, events can be separated into two classes, successful (2xx) and failed events (5xx).
| Metric Name | Description | Type | Tags | Unit | Status |
|---|---|---|---|---|---|
| event_count | Number of events received by a Broker | Counter | broker_name event_type namespace_name response_code response_code_class unique_name |
Dimensionless | Stable |
| event_dispatch_latencies | The time spent dispatching an event to a Channel | Histogram | broker_name event_type namespace_name response_code response_code_class unique_name |
Milliseconds | Stable |
Broker - Filter¶
Use the following metrics to debug how broker filter performs and what events are dispatched via the filter component. Also user can measure the latency of the actual filtering action on an event. By aggregating the metrics over the http code, events can be separated into two classes, successful (2xx) and failed events (5xx).
| Metric Name | Description | Type | Tags | Unit | Status |
|---|---|---|---|---|---|
| event_count | Number of events received by a Broker | Counter | broker_name container_name= filter_type namespace_name response_code response_code_class trigger_name unique_name |
Dimensionless | Stable |
| event_dispatch_latencies | The time spent dispatching an event to a Channel | Histogram | broker_name container_name filter_type namespace_name response_code response_code_class trigger_name unique_name |
Milliseconds | Stable |
| event_processing_latencies | The time spent processing an event before it is dispatched to a Trigger subscriber | Histogram | broker_name container_name filter_type namespace_name trigger_name unique_name |
Milliseconds | Stable |
In-memory Dispatcher¶
In-memory channel can be evaluated via the following metrics. By aggregating the metrics over the http code, events can be separated into two classes, successful (2xx) and failed events (5xx).
| Metric Name | Description | Type | Tags | Unit | Status |
|---|---|---|---|---|---|
| event_count | Number of events dispatched by the in-memory channel | Counter | container_name event_type= namespace_name= response_code response_code_class unique_name |
Dimensionless | Stable |
| event_dispatch_latencies | The time spent dispatching an event from a in-memory Channel | Histogram | container_name event_type namespace_name= response_code response_code_class unique_name |
Milliseconds | Stable |
Note
A number of metrics eg. controller, Go runtime and others are omitted here as they are common across most components. For more about these metrics check the Serving metrics API section.
Eventing sources¶
Eventing sources are created by users who own the related system, so they can trigger applications with events. Every source exposes by default a number of metrics to help user monitor events dispatched. Use the following metrics to verify that events have been delivered from the source side, thus verifying that the source and any connection with the source work as expected.
| Metric Name | Description | Type | Tags | Unit | Status |
|---|---|---|---|---|---|
| event_count | Number of events sent by the source | Counter | event_source event_type name namespace_name resource_group response_code response_code_class response_error response_timeout |
Dimensionless | Stable |
| retry_event_count | Number of events sent by the source in retries | Counter | event_source event_type name namespace_name resource_group response_code response_code_class response_error response_timeout |
Dimensionless | Stable |