Skip to main content

Business KPIs

A business KPI is a measure of how users use an application. Causely detects when a KPI drops on a Business Application and traces the drop to a diagnosis on one of the application's services.

Concurrent users is the only business KPI supported today.

Step 1: Group services into a Business Application​

Business Applications group services by the Kubernetes pod label app.kubernetes.io/part-of. Causely creates them automatically when it discovers your environment.

For details, see Business Application.

Step 2: Map concurrent users through Prometheus​

Causely maps concurrent users to a Business Application through Prometheus custom metrics. Use the ConcurrentUsersMeasured attribute:

- entity: { business_application: {} }
  discovery:
    - business_application: { name: namespace }
  metrics:
    - attribute: ConcurrentUsersMeasured
      query: sum by (namespace) (mongooseim_session_count)

Add this entry under entities of a custom exporter, as described in How to add custom metrics.

The label named in name must have the same value as the Business Application's name, which comes from the app.kubernetes.io/part-of pod label. In this example, the query groups by namespace, so each namespace value must match a Business Application name. If no Business Application has that name, the metric is not mapped.

Change the query and the discovery block to match your own metric and Business Application names.

Set your own lower threshold (optional)​

Causely uses a lower threshold to decide when concurrent users have dropped. If you know the right value, map the ConcurrentUsersLowerThresholdMeasured attribute in the same way as ConcurrentUsersMeasured. Causely then uses your value.

Learned threshold​

If you do not map a lower threshold, Causely learns one from the application's own history. It uses one day of data, plus the daily history it stores over time.

If there is no mapped threshold and no history yet, the Signal stays unknown.

The learned bound appears as a related attribute of the Signal.

Map an alert instead​

An external alert that is mapped to Concurrent Users Drop can also set the Signal. Causely does not match this Signal by keyword, so you map the alert yourself with an alert_mappings entry. For the entry and an example, see Alert Ingestion and Mapping.

What you get​

Concurrent Users Drop Signal​

Concurrent Users Drop is a Signal on the Business Application. It activates after concurrent users stay below the lower threshold for 1 minute. It clears 3 minutes after concurrent users recover.

Diagnoses that explain a drop​

A problem on a member service can lock users out of the application, which lowers the Business Application's concurrent users. These diagnoses can now explain a drop:

Client Connection Disruption requires concurrent users​

Client Connection Disruption means existing client connections were dropped, for example by a load balancer or proxy change. Clients then reconnect at the same time. This predicts an Endpoint Request Burst and lost concurrent users.

Causely can only identify this diagnosis when the service's Business Application reports concurrent users. If you have not mapped concurrent users, Causely does not identify it.