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.

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	`8443`	No configuration is required. Note that a Bearer token is required to access the metrics endpoint.
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 also configure unique port numbers.

Example deployment
Deploy the Prometheus Operator with the Helm chart from here: kube-prometheus-stack (ArtifactHub).
Create a ServiceMonitor for the Airlock Microgateway Operator metrics on Port 8443.

copy

apiVersion: monitoring.coreos.com/v1 
kind: ServiceMonitor 
metadata: 
  namespace: airlock-microgateway-system 
  name: airlock-microgateway-operator 
  labels: 
    release: prometheus-deploy
 spec: 
  endpoints: 
    - path: /metrics 
      port: https 
      scheme: https 
      bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token 
      tlsConfig: 
        insecureSkipVerify: true 
  selector: 
    matchLabels: 
      control-plane: airlock-microgateway-operator

Create a PodMonitor for the Airlock Microgateway License Guard metrics on Port 9102.

copy

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: airlock-microgateway-license-guard-podmonitor
  namespace: airlock-microgateway-system
  labels:
    release: prometheus-deploy
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: airlock-microgateway-license-guard
      app.kubernetes.io/component: server
  podMetricsEndpoints:
  - port: metrics
    path: /metrics
    scheme: http

Finally, create a PodMonitor for the Airlock Microgateway Engine metrics on port 19002.

copy

apiVersion: monitoring.coreos.com/v1  
kind: PodMonitor  
metadata:  
  name: airlock-microgateway-engine-podmonitor  
  namespace: airlock-monitoring  
  labels:  
    release: prometheus-deploy  
spec:  
  namespaceSelector:  
    any: true  
  selector:  
    matchLabels:  
      sidecar.microgateway.airlock.com/injected: "true"  
  podMetricsEndpoints:  
  - port: metrics  
    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"