# Traffic Metrics

Kuma facilitates consistent traffic metrics across all data plane proxies in your mesh.

You can add metrics to a mesh configuration, or to an individual data plane proxy configuration. For example, you might need metrics for individual data plane proxies to override the default metrics port if it's already in use on the specified machine.

Kuma provides full integration with Prometheus:

  • Each proxy can expose its metrics in Prometheus format (opens new window).
  • Because metrics are part of the mesh configuration, We can leverage the control plane api to automatically find every proxy in the mesh.

To collect metrics from Kuma, you need to expose metrics from proxies and applications.

In the rest of this page we assume you have already configured your observability tools to work with Kuma. If you haven't already read the observability docs.

# Expose metrics from data plane proxies

To expose metrics from every proxy in the mesh, configure the Mesh resource:

    This tells Kuma to configure every proxy in the default mesh to expose an HTTP endpoint with Prometheus metrics on port 5670 and URI path /metrics.

    The metrics endpoint is forwarded to the standard Envoy Prometheus metrics endpoint (opens new window) and supports the same query parameters. You can pass the filter query parameter to limit the results to metrics whose names match a given regular expression. By default all available metrics are returned.

    # Expose metrics from applications

    In addition to exposing metrics from the data plane proxies, you might want to expose metrics from applications running next to the proxies. Kuma allows scraping Prometheus metrics from the applications endpoint running in the same Pod or VM. Later those metrics are aggregated and exposed at the same port/path as data plane proxy metrics. It is possible to configure it at the Mesh level, for all the applications in the Mesh, or just for specific applications.

    Here are reasons where you'd want to use this feature:

    • Application metrics are labelled with your mesh parameters (tags, mesh, data plane name...), this means that in mixed Universal and Kubernetes mode metrics are reported with the same types of labels.
    • Both application and sidecar metrics are scraped at the same time. This makes sure they are coherent (with 2 different scrapers they can end up scraping at different intervals and make metrics harder to correlate).
    • If you disable passthrough and your mesh uses mTLS but Prometheus is outside the mesh (skipMTLS: true) this will be the only way to retrieve these metrics as the application is completely hidden behind the sidecar.

    Any configuration change requires redeployment of the data plane.

      This configuration will cause every application in the mesh to be scrapped for metrics by the data plane proxy. If you need to expose metrics only for the specific application it is possible through annotation for Kubernetes or Dataplane resource for Universal deployment.

        # Override Prometheus settings per data plane proxy

          # Filter Envoy metrics

          In case you don't want to retrieve all Envoy's metrics, it's possible to filter them. Configuration is dynamic and doesn't require a restart of a sidecar. You are able to specify regex (opens new window) which causes that metric's endpoint returns only matching metrics. Also, you can set flag usedOnly (opens new window) that returns only metrics updated by Envoy.

            # Secure data plane proxy metrics

            Kuma lets you expose proxy metrics in a secure way by leveraging mTLS. Prometheus needs to be a part of the mesh for this feature to work, which is the default deployment mode on Kubernetes when using kumactl install observability.

              Last Updated: 8/23/2022, 4:31:24 PM