#Monitoring

Alauda Application Services Identity Management E1 exposes built-in metrics compatible with Prometheus. Enabling metrics allows you to monitor Keycloak's health, performance, and usage in your observability stack.

#Enable Metrics

Metrics are enabled by setting the metrics-enabled option in the Keycloak CR:

spec:
  additionalOptions:
    - name: metrics-enabled
      value: "true"

Once enabled, Keycloak exposes a metrics endpoint on the management port (default: 9000), configurable via spec.httpManagement.port:

• Within the cluster: http://<keycloak-service-name>.<namespace>:9000/metrics
• From within a Pod: http://localhost:9000/metrics

The management port is separate from the main HTTP/HTTPS port.

#Key Metrics

The following categories of metrics are available:

#Recommended Alerting Indicators

The following metrics are recommended as starting points for alerting rules:

#Configure Prometheus Scraping

Add the following scrape configuration to your Prometheus instance to collect Keycloak metrics:

scrape_configs:
  - job_name: keycloak
    static_configs:
      - targets:
          - <keycloak-service>:9000
    metrics_path: /metrics

If you are using the Prometheus Operator, create a ServiceMonitor:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: keycloak-metrics
  namespace: <namespace>
spec:
  selector:
    matchLabels:
      app: keycloak
  endpoints:
    - port: management
      path: /metrics
      interval: 30s

#Liveness and Readiness Probes

The Keycloak Operator configures liveness and readiness probes automatically. You can customize the probe parameters in the Keycloak CR:

spec:
  livenessProbe:
    periodSeconds: 10
    failureThreshold: 3
  readinessProbe:
    periodSeconds: 10
    failureThreshold: 3

The probes use the management endpoint at http://<pod>:9000/health/live and http://<pod>:9000/health/ready.

#Health Endpoints

Keycloak exposes health endpoints on the management port for monitoring and orchestration:

#Observability Integration

For a complete observability stack, combine Keycloak's built-in capabilities with cluster-level tooling:

spec:
  tracing:
    enabled: true
    endpoint: "http://tempo.observability:4317"
    samplerType: traceidratio
    samplerRatio: 0.1

#Event Auditing

Keycloak provides a built-in event system that records login events and admin operations. Events can be stored in the database and forwarded to external listeners.

#Enable Login Events

1. In the Admin Console, go to Realm Settings > Events tab.
2. In the User events settings section:
   • Enable Save events.
   • Set Expiration to control how long events are retained (for example, 30 days).
   • Select the Event types to record (or leave blank to record all types).
3. Click Save.

#Key Login Event Types

#Enable Admin Events

1. In the Admin events settings section:
   • Enable Save events.
   • Enable Include representation to record the full request body of admin operations (useful for audit trails, but increases storage usage).
2. Click Save.

Admin events record all operations performed via the Admin Console or Admin REST API, including resource type, operation type (CREATE, UPDATE, DELETE), and the admin user who performed the action.

#View Events

• Login events: Go to Events > User events tab. Filter by event type, user, date range, or client.
• Admin events: Go to Events > Admin events tab. Filter by operation type, resource type, or admin user.

#Event Listeners

Event listeners process events as they occur. Keycloak includes two built-in listeners:

Configure listeners in Realm Settings > Events > Event listeners.

#Query Events via REST API

# Get recent login events
curl -s -H "Authorization: Bearer $ACCESS_TOKEN" \
  "https://<keycloak-host>/admin/realms/<realm>/events?type=LOGIN_ERROR&first=0&max=50"

# Get admin events
curl -s -H "Authorization: Bearer $ACCESS_TOKEN" \
  "https://<keycloak-host>/admin/realms/<realm>/admin-events?first=0&max=50"