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.

Default ports for metrics scraping

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

Type

Port

Port configuration

Engine metric

19002

  • Templates that must be configured to change the port:
  • engine_bootstrap_config_template.yaml
  • engine_container_template.yaml

Note that both template files must be changed equally using the same port.

Operator metric

8080

No configuration is required.

License guard

9102

No configuration is required.

  • 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 reference article Available metrics in Prometheus format.

Prometheus example configuration

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

Metrics can be scraped using a ServiceMonitor, or PodMonitor.

  • In most cases, it's a good choice to configure a ServiceMonitor, as this allows scraping aggregated metrics from all Pods behind a Service.
  • Choose PodMonitor where you need to have separated metrics per Pod. When running multiple Pods in the same namespace, you must create a dedicated PodMonitor per Pod and configure unique port numbers.
  1. Example deployment
  2. Deploy the Prometheus Operator with the Helm chart from here: kube-prometheus-stack (ArtifactHub).
  3. Create a ServiceMonitor for the Airlock Microgateway Operator.
    4. copy
    apiVersion: monitoring.coreos.com/v1 
kind: ServiceMonitor 
metadata: 
  name: airlock-microgateway-operator 
  namespace: airlock-microgateway-system 
  labels: 
    release: prometheus 
spec: 
  selector: 
    matchLabels: 
      control-plane: airlock-microgateway-operator 
  endpoints: 
    - path: /metrics 
      port: metrics 
      scheme: http
  4. Create a ServiceMonitor for the Airlock Microgateway License Guard.
    5. copy
    apiVersion: monitoring.coreos.com/v1 
kind: ServiceMonitor 
metadata: 
  name: airlock-microgateway-license-guard 
  namespace: airlock-microgateway-system 
  labels: 
    release: prometheus 
spec: 
  selector: 
    matchLabels: 
      app.kubernetes.io/name: airlock-microgateway-license-guard 
      app.kubernetes.io/component: server 
  endpoints: 
    - path: /metrics 
      port: metrics 
      scheme: http
  5. Finally, create a PodMonitor for the Airlock Microgateway Engine.
    6. copy
    apiVersion: monitoring.coreos.com/v1 
kind: PodMonitor 
metadata: 
  name: airlock-microgateway-engine 
  namespace: airlock-microgateway-system 
  labels: 
    release: prometheus 
spec: 
  namespaceSelector: 
    any: true 
  selector: 
    matchLabels: 
      sidecar.microgateway.airlock.com/injected: "true" 
  podMetricsEndpoints: 
    - targetPort: 19002 
      path: /metrics 
      scheme: http

To scrape metrics from web applications with injected Microgateway Engines, the application's corresponding metrics port must be excluded in the Engine configuration. Multiple ports can be excluded in a comma-separated list.

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

See also Annotations for Microgateway Engine injection.