Prometheus

Prometheus is an open source monitoring system and time series database. You can use Prometheus with Istio to record metrics that track the health of Istio and of applications within the service mesh. You can visualize metrics using tools like Grafana and Kiali.

Installation

Option 1: Quick start

Istio provides a basic sample installation to quickly get Prometheus up and running:

  1. $ kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.22/samples/addons/prometheus.yaml

This will deploy Prometheus into your cluster. This is intended for demonstration only, and is not tuned for performance or security.

While the quick-start configuration is well-suited for small clusters and monitoring for short time horizons, it is not suitable for large-scale meshes or monitoring over a period of days or weeks. In particular, the introduced labels can increase metrics cardinality, requiring a large amount of storage. And, when trying to identify trends and differences in traffic over time, access to historical data can be paramount.

Option 2: Customizable install

Consult the Prometheus documentation to get started deploying Prometheus into your environment. See Configuration for more information on configuring Prometheus to scrape Istio deployments.

Configuration

In an Istio mesh, each component exposes an endpoint that emits metrics. Prometheus works by scraping these endpoints and collecting the results. This is configured through the Prometheus configuration file which controls settings for which endpoints to query, the port and path to query, TLS settings, and more.

To gather metrics for the entire mesh, configure Prometheus to scrape:

  1. The control plane (istiod deployment)
  2. Ingress and Egress gateways
  3. The Envoy sidecar
  4. The user applications (if they expose Prometheus metrics)

To simplify the configuration of metrics, Istio offers two modes of operation.

Option 1: Metrics merging

To simplify configuration, Istio has the ability to control scraping entirely by prometheus.io annotations. This allows Istio scraping to work out of the box with standard configurations such as the ones provided by the Helm stable/prometheus charts.

While prometheus.io annotations are not a core part of Prometheus, they have become the de facto standard to configure scraping.

This option is enabled by default but can be disabled by passing --set meshConfig.enablePrometheusMerge=false during installation. When enabled, appropriate prometheus.io annotations will be added to all data plane pods to set up scraping. If these annotations already exist, they will be overwritten. With this option, the Envoy sidecar will merge Istio’s metrics with the application metrics. The merged metrics will be scraped from :15020/stats/prometheus.

This option exposes all the metrics in plain text.

This feature may not suit your needs in the following situations:

  • You need to scrape metrics using TLS.
  • Your application exposes metrics with the same names as Istio metrics. For example, your application metrics expose an istio_requests_total metric. This might happen if the application is itself running Envoy.
  • Your Prometheus deployment is not configured to scrape based on standard prometheus.io annotations.

If required, this feature can be disabled per workload by adding a prometheus.istio.io/merge-metrics: "false" annotation on a pod.

Option 2: Customized scraping configurations

To configure an existing Prometheus instance to scrape stats generated by Istio, several jobs need to be added.

  • To scrape Istiod stats, the following example job can be added to scrape its http-monitoring port:
  1. - job_name: 'istiod'
  2.   kubernetes_sd_configs:
  3.   - role: endpoints
  4.     namespaces:
  5.       names:
  6.       - istio-system
  7.   relabel_configs:
  8.   - source_labels: [__meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
  9.     action: keep
  10.     regex: istiod;http-monitoring
  • To scrape Envoy stats, including sidecar proxies and gateway proxies, the following job can be added to scrape ports that end with -envoy-prom:
  1. - job_name: 'envoy-stats'
  2.   metrics_path: /stats/prometheus
  3.   kubernetes_sd_configs:
  4.   - role: pod
  6.   relabel_configs:
  7.   - source_labels: [__meta_kubernetes_pod_container_port_name]
  8.     action: keep
  9.     regex: '.*-envoy-prom'
  • For application stats, if Strict mTLS is not enabled, your existing scraping configuration should still work. Otherwise, Prometheus needs to be configured to scrape with Istio certs.

TLS settings

The control plane, gateway, and Envoy sidecar metrics will all be scraped over cleartext. However, the application metrics will follow whatever Istio authentication policy has been configured for the workload.

  • If you use STRICT mode, then Prometheus will need to be configured to scrape using Istio certificates as described below.
  • If you use PERMISSIVE mode, the workload typically accepts TLS and cleartext. However, Prometheus cannot send the special variant of TLS Istio requires for PERMISSIVE mode. As a result, you must not configure TLS in Prometheus.
  • If you use DISABLE mode, no TLS configuration is required for Prometheus.

Note this only applies to Istio-terminated TLS. If your application directly handles TLS:

  • STRICT mode is not supported, as Prometheus would need to send two layers of TLS which it cannot do.
  • PERMISSIVE mode and DISABLE mode should be configured the same as if Istio was not present.

See Understanding TLS Configuration for more information.

One way to provision Istio certificates for Prometheus is by injecting a sidecar which will rotate SDS certificates and output them to a volume that can be shared with Prometheus. However, the sidecar should not intercept requests for Prometheus because Prometheus’s model of direct endpoint access is incompatible with Istio’s sidecar proxy model.

To achieve this, configure a cert volume mount on the Prometheus server container:

  1. containers:
  2.   - name: prometheus-server
  3.     ...
  4.     volumeMounts:
  5.       mountPath: /etc/prom-certs/
  6.       name: istio-certs
  7. volumes:
  8.   - emptyDir:
  9.       medium: Memory
  10.     name: istio-certs

Then add the following annotations to the Prometheus deployment pod template, and deploy it with sidecar injection. This configures the sidecar to write a certificate to the shared volume, but without configuring traffic redirection:

  1. spec:
  2.   template:
  3.     metadata:
  4.       annotations:
  5.         traffic.sidecar.istio.io/includeInboundPorts: ""   # do not intercept any inbound ports
  6.         traffic.sidecar.istio.io/includeOutboundIPRanges: ""  # do not intercept any outbound traffic
  7.         proxy.istio.io/config: |  # configure an env variable `OUTPUT_CERTS` to write certificates to the given folder
  8.           proxyMetadata:
  9.             OUTPUT_CERTS: /etc/istio-output-certs
  10.         sidecar.istio.io/userVolumeMount: '[{"name": "istio-certs", "mountPath": "/etc/istio-output-certs"}]' # mount the shared volume at sidecar proxy

Finally, set the scraping job TLS context as follows:

  1. scheme: https
  2. tls_config:
  3.   ca_file: /etc/prom-certs/root-cert.pem
  4.   cert_file: /etc/prom-certs/cert-chain.pem
  5.   key_file: /etc/prom-certs/key.pem
  6.   insecure_skip_verify: true  # Prometheus does not support Istio security naming, thus skip verifying target pod certificate

Best practices

For larger meshes, advanced configuration might help Prometheus scale. See Using Prometheus for production-scale monitoring for more information.