https://docs.airlock.com/microgateway/5.2/configuration-guides/observability/ This chapter contains configuration guides for observability. Hugo en-US https://docs.airlock.com/microgateway/5.2/configuration-guides/observability/monitor-microgateway-licenses/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.airlock.com/microgateway/5.2/configuration-guides/observability/monitor-microgateway-licenses/ A valid license is required unless Airlock Microgateway is used in the Community Edition. To use premium features, request an evaluation license or obtain a premium license from your sales partner. The available editions are compared in Editions. License validity and behavior The possible license states and their effects are described in the following table. License validity Definition Microgateway Engine behavior Valid license Valid license (metric microgateway_license_valid = 1). Traffic is secured according to the configuration. Expired license The license is expired (metric microgateway_license_valid = 0) as soon as the license expiry timestamp metric value is reached. Use microgateway_license_expiry_timestamp_seconds to monitor the license expiry date. Gateway pods created before the license expiry timestamp run normally.Gateway pods created after the license expiry timestamp block all traffic. Insufficient license ContentSecurity is configured as secured in the GatewayParameters, but it is not covered by the licensed modules. All traffic is blocked. ExamplesA policy is configured for an HTTPRoute, but the required module is not licensed.ExamplesAn AccessControlPolicy is configured for an HTTPRoute, but the auth module is not licensed.ContentResponsePolicy, ICAPPolicy, or similar policies are configured for an HTTPRoute, but the filter module is not licensed. The policy is rejected.Traffic for the affected HTTPRoute is blocked. Invalid license Invalid license (metric microgateway_license_valid = 0). All traffic is blocked. Notice If no license is provided, Airlock Microgateway operates in Community Edition mode. If premium features are configured, the resulting license state is Insufficient license. https://docs.airlock.com/microgateway/5.2/configuration-guides/observability/grafana-dashboards-for-metrics-and-log-visualization/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.airlock.com/microgateway/5.2/configuration-guides/observability/grafana-dashboards-for-metrics-and-log-visualization/ In Airlock Microgateway, Grafana dashboards can be deployed either from GitHub release artifacts or via Helm chart. Metrics are obtained using Prometheus and logs are aggregated using Loki in combination with a suitable log agent (e.g., Alloy or similar). Prerequisites Grafana For a list of supported versions, see Requirements and limitations » Additional components. For metrics dashboards: Prometheus For logs dashboards: Loki Configuration Create the PodMonitor and ServiceMonitor Run the following example to create a new Microgateway Helm release which creates the PodMonitor and ServiceMonitor: https://docs.airlock.com/microgateway/5.2/configuration-guides/observability/tracing/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.airlock.com/microgateway/5.2/configuration-guides/observability/tracing/ Tracing records the end-to-end path of a request as a set of timed operations (spans). It helps identify latency hotspots and locate failures, especially in distributed systems. Airlock Microgateway can add gateway-specific attributes to spans, for example routing decisions and upstream/backend interactions. This provides visibility into how requests are handled at the gateway. By default, Microgateway does not export traces to a tracing backend. This guide describes how to enable tracing export and configure sampling and the exporter endpoint. https://docs.airlock.com/microgateway/5.2/configuration-guides/observability/log-masking/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.airlock.com/microgateway/5.2/configuration-guides/observability/log-masking/ Log masking helps prevent sensitive information from being exposed in access logs by masking selected log fields values before they are written. Rules defined in a LogMaskingPolicy custom resource specify which log fields to mask, helping prevent credentials, tokens, passwords, and API keys from being logged. Masked values are rendered as ****. Log masking can be configured in three ways: Built-in field categories (recommended) Mask entire groups of request data (e.g., credentials or tokens). Header rules