Logging, monitoring en reporting in OpenShift

OpenShift heeft ingebouwde stacks voor zowel monitoring (metrics, alerting) als logging (centrale logverzameling) — je hoeft niet vanaf nul een eigen Prometheus of log-aggregatiesysteem op te zetten. Dit artikel behandelt beide, plus hoe je die data omzet in bruikbare reporting.

Monitoring: de Cluster Monitoring Operator

OpenShift installeert standaard de Cluster Monitoring Operator (CMO): een vooraf geconfigureerde combinatie van Prometheus, Alertmanager en Thanos Querier, direct zichtbaar in de OpenShift Console onder "Observe". Dit dekt clustercomponenten (API server, etcd, nodes) automatisch — zonder dat je zelf iets hoeft te installeren.

User Workload Monitoring: ook je eigen applicaties

Standaard bewaakt de CMO alleen clustercomponenten zelf, niet je eigen applicaties. Daarvoor schakel je User Workload Monitoring (UWM) in — een aparte, geïsoleerde Prometheus-instantie specifiek voor workload-metrics:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    enableUserWorkload: true

Zodra dit actief is, kan een applicatie zijn eigen metrics laten oppikken via een ServiceMonitor:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: mijn-app-metrics
  namespace: productie-app
spec:
  selector:
    matchLabels:
      app: mijn-app
  endpoints:
    - port: metrics
      interval: 30s

Alerting: PrometheusRule

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: mijn-app-alerts
  namespace: productie-app
spec:
  groups:
    - name: foutrate
      rules:
        - alert: HogeFoutrate
          expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Foutrate boven 5% gedurende 10 minuten"

Praktijktip: Test een nieuwe PrometheusRule eerst met een ruime for-duur en severity "warning" vóórdat je het op "critical" zet met een korte duur — zo voorkom je een stortvloed aan meldingen bij een nieuwe, nog niet goed afgestelde regel.

Logging: de moderne Loki/Vector-stack

Belangrijk om te weten als je recentere documentatie of cursusmateriaal tegenkomt: OpenShift Logging gebruikte historisch de EFK-stack (Elasticsearch, Fluentd, Kibana). Die aanpak is inmiddels volledig vervangen: de Elasticsearch Operator is sinds november 2025 uit de Operator Catalog verwijderd, en Kibana wordt sinds OpenShift 4.16 niet meer ondersteund. De huidige, aanbevolen stack (Red Hat OpenShift Logging 6.x) bestaat uit:

• Vector — de log-collector, draait als DaemonSet op elke node (vervangt het oudere Fluentd)
• LokiStack — de opslaglaag, via de Loki Operator (vervangt Elasticsearch)
• OpenShift Console — ingebouwde log-viewer met LogQL-ondersteuning (vervangt Kibana), optioneel aan te vullen met een externe Grafana

Installatie

# Via de OperatorHub in de Console, of via CLI:
oc apply -f - <<EOF
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: stable
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

Een LokiStack aanmaken

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  size: 1x.small
  storage:
    schemas:
      - version: v13
        effectiveDate: "2024-01-01"
    secret:
      name: loki-object-storage
      type: s3
  storageClassName: gp3-csi

De grootte (size) volgt een format Nx.formaat — bijvoorbeeld 1x.small voor kleinere clusters, oplopend voor grotere logvolumes. Dit is direct aan te passen zonder de onderliggende architectuur te wijzigen.

Logs routeren met ClusterLogForwarder

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  serviceAccount:
    name: logging-collector
  outputs:
    - name: default-loki
      type: lokiStack
      lokiStack:
        target:
          name: logging-loki
          namespace: openshift-logging
    - name: extern-splunk
      type: splunk
      splunk:
        url: https://splunk.voorbeeld.nl:8088
  pipelines:
    - name: alle-logs
      inputRefs: [application, infrastructure, audit]
      outputRefs: [default-loki, extern-splunk]

Praktijktip: De ClusterLogForwarder is het centrale routeringsobject — je kunt in dezelfde configuratie tegelijk naar de interne LokiStack én naar een extern systeem (Splunk, Elasticsearch, Kafka) sturen, bijvoorbeeld als een compliance-eis vereist dat logs ook buiten het cluster bewaard blijven.

Logs doorzoeken met LogQL

{ log_type="application", kubernetes_namespace_name="productie-app" } |= "error"n{ log_type="audit" } | json | verb="delete"

Reporting: van ruwe data naar bruikbare rapportages

Monitoring en logging leveren de ruwe data; reporting gaat over het omzetten daarvan naar iets wat je periodiek kunt delen — met een team, een auditor, of een klant.

Recording rules: vooraf berekende metrics

Voor rapportages die regelmatig dezelfde, potentieel dure query herhalen (bijvoorbeeld een maandelijkse uptime-berekening), gebruik je een recording rule: Prometheus berekent en bewaart het resultaat vooraf, in plaats van de zware query telkens opnieuw uit te voeren.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: mijn-app-recording-rules
  namespace: productie-app
spec:
  groups:
    - name: dagelijkse-rapportage
      rules:
        - record: mijnapp:foutrate:24u
          expr: rate(http_requests_total{status=~"5.."}[24h])

Compliance-reporting

Voor SOC 1/SOC 2-doeleinden zijn audit-logs (via ClusterLogForwarder met inputRefs: [audit]) en bewaartermijnen van de LokiStack direct relevant bewijsmateriaal — zie onze uitgebreide boeken over SOC 1 en SOC 2 voor Kubernetes-platformen voor hoe deze technische logging zich vertaalt naar daadwerkelijke controles.

Dashboards delen

De OpenShift Console-dashboards zijn gebonden aan RBAC — een gebruiker ziet alleen metrics van namespaces waar die toegang toe heeft. Voor bredere, gedeelde rapportage (bijvoorbeeld een managementdashboard) koppel je vaak een externe Grafana-instantie aan dezelfde Prometheus/Thanos-databron, met eigen, losstaande toegangscontrole.

Relatie tot certificeringen

• EX280 — basiskennis van de ingebouwde monitoring-stack en het raadplegen van logs is examenstof
• EX380 — centrale logaggregatie over meerdere clusters (ClusterLogForwarder naar externe systemen) is expliciet examenstof op gevorderd niveau

Veelgestelde vragen

Moet ik nog steeds Elasticsearch gebruiken voor logging?

Nee — voor nieuwe implementaties is dat inmiddels afgeraden: de Elasticsearch Operator is niet meer beschikbaar in de Operator Catalog. Gebruik de LokiStack. Draai je nog een oudere Elasticsearch-gebaseerde installatie, plan dan een migratie; dit gebeurt niet automatisch bij een clusterupgrade.

Is Grafana nog nodig als de Console al dashboards heeft?

Voor de meeste gevallen niet — de ingebouwde Console-dashboards en log-viewer dekken het merendeel van de behoefte. Een losstaande Grafana is vooral zinvol voor sterk aangepaste dashboards, of om metrics over meerdere clusters heen samen te voegen op één plek.

Wat is het verschil tussen ClusterLogging en ClusterLogForwarder?

ClusterLogging (het oude, brede configuratieobject) is effectief verouderd; de huidige aanpak splitst verantwoordelijkheden op: LokiStack regelt opslag, ClusterLogForwarder regelt routering (pipelines, filters, outputs) — kleinere, specifiekere objecten in plaats van één allesomvattend object.