Microgateway as a data source for Prometheus metrics

Airlock Microgateway components can act as a data source for Prometheus metrics for time-series-based real-time events and alert monitoring.
Prometheus can statically scrape metrics from configured Kubernetes resources or retrieve the scrape targets with service discovery. Since Microgateway can be scaled horizontally, a static configuration might be impractical.

This article describes the configuration and gives an overview of available metrics.

For security reasons, metrics usually should not be accessible outside your network. We strongly recommend setting appropriate network policies for metrics access.

To allow scraping metrics from web applications with injected Airlock Microgateway Engines, the application's corresponding metrics port should be excluded via a Pod annotation. Multiple ports can be excluded in a comma-separated list.

Example:
sidecar.microgateway.airlock.com/excludeInboundPorts: "<YourWebApplicationMetricsPort>"

See also Labels and annotations for Airlock Microgateway.

Default ports for metrics scraping

The default Airlock Microgateway ports are noted in the following table:

Type

Port

Engine metric

19002

Operator metric

8080

  • Keep in mind:
  • A metric is published when there has been at least one sample point. The reason is that a sample is required before any output can be generated.
  • Statistically relevant statements such as the average number of requests per second always require a sufficient basis.

For available metrics, see the reference article Available metrics in Prometheus format.

Prometheus example configuration

The following configuration example uses the kube-prometheus-stack and may serve as a starting point for your specific Prometheus deployment.

  1. Deploy the Prometheus Operator with the Helm chart from kube-prometheus-stack (ArtifactHub):
  2. copy
    helm install <PROMETHEUS-OPERATOR-RELEASE> prometheus-community/kube-prometheus-stack
  3. With the Airlock Microgateway Operator helm chart installation, the serviceMonitor and podMonitor resources can be created automatically. To do so, configure the helm values create: true and labels: {release: <PROMETHEUS-OPERATOR-RELEASE>} for each Prometheus resource:
  4. copy
    operator:  
      serviceMonitor:  
        create: true 
        labels:  
          release: <PROMETHEUS-OPERATOR-RELEASE> 
    engine:  
      sidecar:  
        podMonitor:  
          create: true 
          labels:  
            release: <PROMETHEUS-OPERATOR-RELEASE>