Logging-Stack installieren:
der komplette Fahrplan

SNO- und Edge-Cluster haben oft keine StorageClass. Lösung: Local Storage Operator (oder LVM Storage) macht aus rohen Block-Devices eine StorageClass.

oc adm new-project openshift-local-storage

apiVersion: local.storage.openshift.io/v1
kind: LocalVolume
metadata:
  name: local-block
  namespace: openshift-local-storage
spec:
  nodeSelector:
    nodeSelectorTerms:
    - matchExpressions:
      - key: kubernetes.io/hostname
        operator: In
        values:
        - <node_name>
  storageClassDevices:
  - storageClassName: local-block   # wird deine neue StorageClass
    volumeMode: Block               # Block empfohlen für Loki
    devicePaths:
    - /dev/disk/by-id/<device_id>   # stabile by-id-Pfade nutzen
    fsType: ""

Danach: oc get storageclass local-block und nach LokiStack-Erstellung oc get pvc -n openshift-logging – PVCs müssen binden.

LokiStack braucht dynamisch provisionierten ReadWriteOnce-Blockspeicher für WAL, Index-Cache und Compactor. Ohne StorageClass bleiben PVCs Pending und kein Pod startet – bei trotzdem grünem LokiStack-Status.

# Alle StorageClasses auflisten
oc get storageclass

# Default-StorageClass ermitteln
oc get storageclass -o=jsonpath='{.items[?(@.metadata.annotations.storageclass\.kubernetes\.io/is-default-class=="true")].metadata.name}'

Auf den Provisioner achten (z. B. ebs.csi.aws.com, csi.vsphere.vmware.com, openshift-storage.ceph.rbd) – Blockspeicher bevorzugen, Filesystem bremst Loki. Kapazität gegen die Sizing-Tabelle prüfen (1x.medium mit Ruler: 910 Gi über alle PVCs).

SNO/Edge ohne StorageClass: Local Storage Operator installieren und aus rohen Devices eine StorageClass bauen:

oc adm new-project openshift-local-storage
# Local Storage Operator via OperatorHub oder Subscription (stable) installieren, dann:
cat <<'EOF' | oc apply -f -
apiVersion: local.storage.openshift.io/v1
kind: LocalVolume
metadata:
  name: local-block
  namespace: openshift-local-storage
spec:
  nodeSelector:
    nodeSelectorTerms:
    - matchExpressions:
      - key: kubernetes.io/hostname
        operator: In
        values:
        - <your_node_name>
  storageClassDevices:
  - storageClassName: local-block
    volumeMode: Block
    devicePaths:
    - /dev/disk/by-id/<device_id>
    fsType: ""
EOF
oc get storageclass local-block

Bucket auf dem S3-kompatiblen Storage anlegen (StorageGRID, Cloudian, Ceph RGW, MinIO-artige …) und einen Account mit genau diesen Rechten ausstatten: ListBucket, PutObject, GetObject, DeleteObject, GetObjectTagging, PutObjectTagging. Ohne DeleteObject läuft der Bucket trotz Retention voll.

# Referenz-IAM-Policy (AWS-Syntax, sinngemäß auf den Provider übertragen)
{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::<bucket_name>" },
    { "Effect": "Allow",
      "Action": ["s3:PutObject","s3:GetObject","s3:DeleteObject",
                 "s3:GetObjectTagging","s3:PutObjectTagging"],
      "Resource": "arn:aws:s3:::<bucket_name>/*" }
  ]
}

Kapazität nicht überplanen – vorab nicht schätzbar. Mit ~1 TB starten, nach Deployment beobachten. Erreichbarkeit des Endpoints von den Cluster-Nodes testen (gerade air-gapped).

Log-Volumen ist vor der Installation nicht vorhersagbar – deshalb nach Clustergröße wählen, nicht raten:

≤ 10 Nodes                → 1x.extra-small
> 10 Nodes                → 1x.medium
SNO/Edge                  → 1x.pico (minimal lauffähig)
Edge, knappe Kapazität    → Forwarding an zentralen Hub

Größe notieren – sie kommt in Schritt 9 in die LokiStack-CR und wird in Schritt 17 gegen echte Messwerte geprüft.

Die gewählte Größe muss ins Cluster passen (siehe Sizing-Tabelle in Etappe 3). Beispiele der Gesamt-Requests:

1x.extra-small : 14 vCPU / 31 Gi RAM / 430 Gi Disk   (mit Ruler: 16 / 35 Gi / 750 Gi)
1x.small       : 34 vCPU / 67 Gi RAM / 430 Gi        (mit Ruler: 42 / 83 Gi / 750 Gi)
1x.medium      : 54 vCPU / 139 Gi RAM / 590 Gi         (mit Ruler: 70 / 171 Gi / 910 Gi)

Ruler nur einrechnen, wenn Alerting-/Recording-Rules geplant sind.

Der Loki Operator gehört nach openshift-operators-redhat – nicht nach openshift-operators (Community-Metrik-Konflikte). Quelle zwingend redhat-operators: im Community-Katalog liegt ein gleichnamiger, nicht supporteter Operator mit anderen Kanälen.

cat <<'EOF' | oc apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-operators-redhat
  labels:
    openshift.io/cluster-monitoring: "true"
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  upgradeStrategy: Default
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: stable-6.6
  installPlanApproval: Automatic
  name: loki-operator
  source: redhat-operators        # disconnected: eigene CatalogSource
  sourceNamespace: openshift-marketplace
EOF

# Verifizieren – muss Succeeded zeigen
oc get csv -n openshift-operators-redhat
# NAME                   DISPLAY         VERSION   PHASE
# loki-operator.v6.6.0   Loki Operator   6.6.0     Succeeded

Hier laufen LokiStack, Collector und alle Logging-Workloads. Das Monitoring-Label sorgt dafür, dass Cluster-Monitoring die Metriken scrapt.

cat <<'EOF' | oc apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
  labels:
    openshift.io/cluster-monitoring: "true"
EOF

Das Secret verbindet LokiStack mit der Lagerhalle. Name nach Konvention logging-loki-s3, im Namespace openshift-logging. S3-kompatibel: forcepathstyle="true" Pflicht, kein region, Endpoint ohne Bucket-Namen.

# S3-kompatibler On-Prem-Storage
oc create secret generic logging-loki-s3 \
  -n openshift-logging \
  --from-literal=bucketnames="<bucket_name>" \
  --from-literal=endpoint="https://s3.example.com:9000" \
  --from-literal=access_key_id="<access_key>" \
  --from-literal=access_key_secret="<secret_key>" \
  --from-literal=forcepathstyle="true"

# Kontrolle
oc get secret logging-loki-s3 -n openshift-logging

# Alternative AWS S3 (Standard-Auth)
oc create secret generic logging-loki-s3 \
  -n openshift-logging \
  --from-literal=bucketnames="<bucket_name>" \
  --from-literal=endpoint="https://s3.<region>.amazonaws.com" \
  --from-literal=access_key_id="<aws_access_key_id>" \
  --from-literal=access_key_secret="<aws_access_key_secret>" \
  --from-literal=region="<aws_region>"

GCS/Azure/Swift/ODF: siehe Provider-Aufklapper in Etappe 2.

Pflicht bei On-Prem-Storage mit eigener CA – sonst werden Logs still verworfen, obwohl alles Ready meldet.

# 1. CA-Zertifikat vom Storage-Endpoint ziehen
openssl s_client -connect <storage_endpoint>:<port> -showcerts </dev/null 2>/dev/null \
  | openssl x509 -out storage-ca.crt

# 2. ConfigMap im Logging-Namespace anlegen
oc create configmap loki-s3-ca-bundle \
  -n openshift-logging \
  --from-file=ca-bundle.crt=./storage-ca.crt

Die Referenz (spec.storage.tls.caName) kommt im nächsten Schritt in die LokiStack-CR. ODF/NooBaa: ggf. service-ca.crt aus der ConfigMap openshift-service-ca.crt nutzen.

Jetzt kommt alles zusammen: Größe (Schritt 3), Secret (Schritt 7), CA-Bundle (Schritt 8), StorageClass (Schritt 1). Merken: storageClassName = Blockspeicher, das S3 steckt im Secret.

cat <<'EOF' | oc apply -f -
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  size: 1x.small                     # aus Schritt 3
  storage:
    schemas:
    - effectiveDate: '2023-10-15'
      version: v13
    secret:
      name: logging-loki-s3          # aus Schritt 7
      type: s3
    tls:
      caName: loki-s3-ca-bundle      # aus Schritt 8, sonst Block weglassen
  storageClassName: <storage_class>  # aus Schritt 1
  tenants:
    mode: openshift-logging
EOF

# PVCs müssen binden, Pods laufen
oc get pvc -n openshift-logging
oc get pods -n openshift-logging | grep lokistack

# Keine Zertifikatsfehler? Muss leer bleiben:
oc logs -n openshift-logging <lokistack_ingester_pod> | grep -i "x509\|certificate"

Gleicher Kanal wie der Loki Operator (stable-6.6) – die Versionen müssen zusammenpassen. Namespace ist hier openshift-logging.

cat <<'EOF' | oc apply -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  upgradeStrategy: Default
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  channel: stable-6.6
  installPlanApproval: Automatic
  name: cluster-logging
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

oc get csv -n openshift-logging
# cluster-logging.v6.6.0   Red Hat OpenShift Logging   6.6.0   Succeeded

Kritischste Reihenfolge im ganzen Ablauf: fehlt beim Anlegen der ClusterLogForwarder-CR ein Binding für einen genutzten Input-Typ, wird das komplette Collector-DaemonSet zerstört.

oc create sa logging-collector -n openshift-logging

oc adm policy add-cluster-role-to-user logging-collector-logs-writer \
  -z logging-collector -n openshift-logging
oc adm policy add-cluster-role-to-user collect-application-logs \
  -z logging-collector -n openshift-logging
oc adm policy add-cluster-role-to-user collect-infrastructure-logs \
  -z logging-collector -n openshift-logging

# Nur wenn Audit-Logs gesammelt werden sollen:
oc adm policy add-cluster-role-to-user collect-audit-logs \
  -z logging-collector -n openshift-logging

Rollen: logging-collector-logs-writer schreibt in die LokiStack, collect-application-logs / collect-infrastructure-logs lesen die jeweiligen Container-Logs.

Die Routenkarte des Briefträgers: welche Inputs in welchen Output. Der tls.ca-Block ist Pflicht – ohne ihn scheitern die Collector-Pods mit certificate verify failed, während der CLF-Status trotzdem Ready: True zeigen kann.

cat <<'EOF' | oc apply -f -
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  serviceAccount:
    name: logging-collector          # aus Schritt 11
  outputs:
  - name: lokistack-out
    type: lokiStack
    lokiStack:
      target:
        name: logging-loki           # aus Schritt 9
        namespace: openshift-logging
      authentication:
        token:
          from: serviceAccount
    tls:                             # PFLICHT
      ca:
        key: service-ca.crt
        configMapName: openshift-service-ca.crt
  pipelines:
  - name: infra-app-logs
    inputRefs:
    - application
    - infrastructure                 # audit nur mit RBAC aus Schritt 11!
    outputRefs:
    - lokistack-out
EOF

oc get clusterlogforwarder instance -n openshift-logging -o yaml
# Erwartete Conditions: observability.openshift.io/Authorized,
# observability.openshift.io/Valid, Ready

# Ein Collector-Pod pro Node
oc get pods -n openshift-logging -l app.kubernetes.io/component=collector

# Logs prüfen: gesund = nur WARN über kleine Dateien.
# "certificate verify failed" → tls.ca-Block in Schritt 12 prüfen.
# "429 Too Many Requests" → normal beim Erst-Ingest, legt sich in Minuten.
oc logs -n openshift-logging -l app.kubernetes.io/component=collector --tail=20

Optional, damit das Konsolen-Dashboard „Produced Logs“ Daten zeigt (Singleton – Operator akzeptiert nur openshift-logging/instance):

cat <<'EOF' | oc apply -f -
apiVersion: logging.openshift.io/v1alpha1
kind: LogFileMetricExporter
metadata:
  name: instance
  namespace: openshift-logging
spec:
  nodeSelector: {}
  resources:
    limits:
      cpu: 500m
      memory: 256Mi
    requests:
      cpu: 200m
      memory: 128Mi
  tolerations: []
EOF

oc get pods -l app.kubernetes.io/component=logfilesmetricexporter -n openshift-logging

Optional: Sammeln, Speichern und Forwarden funktionieren ohne COO. Der COO wandert nach openshift-operators (bestehende OperatorGroup, nichts extra anlegen), Kanal development.

cat <<'EOF' | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-observability-operator
  namespace: openshift-operators
spec:
  channel: development
  installPlanApproval: Automatic
  name: cluster-observability-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

oc get csv -n openshift-operators | grep cluster-observability
# cluster-observability-operator.v0.4.2 … Succeeded

COO allein reicht nicht – erst die UIPlugin-CR schaltet Observe → Logs frei. Name muss logging sein, lokiStack.name muss zur LokiStack passen.

cat <<'EOF' | oc apply -f -
apiVersion: observability.openshift.io/v1alpha1
kind: UIPlugin
metadata:
  name: logging
spec:
  type: Logging
  logging:
    lokiStack:
      name: logging-loki             # aus Schritt 9
    logsLimit: 50
    timeout: 30s
    schema: otel                     # otel | viaq | select (Default: viaq)
EOF

Danach Web-Konsole neu laden, Observe → Logs öffnen und testen:

{log_type="infrastructure"}

Ohne explizite Bindings sieht kein normaler Nutzer Logs. Rollen: cluster-logging-application-view, cluster-logging-infrastructure-view, cluster-logging-audit-view.

# Variante A: App-Logs clusterweit für alle authentifizierten Nutzer
cat <<'EOF' | oc apply -f -
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: logging-all-application-logs-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view
subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
EOF

# Variante B: nur ein Namespace für einen Nutzer
cat <<'EOF' | oc apply -f -
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: allow-read-logs
  namespace: log-test-0
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view
subjects:
- kind: User
  apiGroup: rbac.authorization.k8s.io
  name: testuser-0
EOF

ServiceAccounts brauchen bei Namespace-Zugriff zusätzlich Projekt-List-Rechte (z. B. self-provisioner). Admin-Gruppen: spec.tenants.openshift.adminGroups in der LokiStack-CR. cluster-admin mit vielen Namespaces (Parse error > 5120 Zeichen):

oc adm groups new cluster-admin
oc adm groups add-users cluster-admin <username>
oc adm policy add-cluster-role-to-group cluster-admin cluster-admin

Erst jetzt ist das echte Log-Volumen sichtbar. Ingestion-Rate per Prometheus abfragen, in GB/Tag umrechnen, gegen die Sizing-Tabelle halten:

sum by (component_name) (
  rate(vector_component_sent_bytes_total{
    component_type="loki",
    component_kind="sink"}[5m])
)

# Bytes/s × 86400 ÷ 1073741824 = GB/Tag
# Beispiel: 5 242 880 B/s ≈ 421 GB/Tag → 1x.small (500 GB/Tag)

# Größe in der LokiStack-CR anpassen (Wartungsfenster! Rolling Restart)
oc patch lokistack logging-loki -n openshift-logging \
  --type=merge -p '{"spec":{"size":"1x.small"}}'

Danach CPU-/RAM-Auslastung weiter beobachten – Requests sind Minima, reale Last kann darüber liegen.