OpenShift Logging Stack¶
Introduction¶
OpenShift logging depends on collectors, storage, and log query components. Troubleshoot by checking collector DaemonSets, namespace events, and whether logs are reaching the backend.
Why This Matters¶
OpenShift administration relies on operators and cluster-scoped resources. A bad change can affect many projects, so inspect status and events before applying fixes.
Practical Examples¶
oc get pods -n openshift-logging
oc logs daemonset/collector -n openshift-logging --tail=50
oc get events -n openshift-logging --sort-by=.lastTimestamp
oc adm top pods -n openshift-logging
Example output:
NAME READY STATUS RESTARTS AGE
collector-7k9xm 1/1 Running 0 3d
log-storage-0 1/1 Running 0 3d
Verification¶
oc get pods -n openshift-logging
oc logs daemonset/collector -n openshift-logging --tail=50
Troubleshooting¶
Read the operator message, check the namespace where the component runs, inspect related events, and confirm whether the condition is Available, Progressing, or Degraded.
Common Mistakes¶
- Assuming application logs are missing before checking collector health.
- Ignoring storage pressure in the logging backend.
- Collecting logs from the wrong namespace.
Quick Checklist¶
- Confirm the active project.
- Inspect the exact object named in the error.
- Read recent events.
- Apply one focused fix.
- Verify status after the change.
Related Guides¶
Summary¶
OpenShift Logging Stack is an administration task that should be driven by cluster status, operator conditions, and component logs instead of broad restarts.