#Inspect logs and Events

There is no integrated log viewer. Use Kubernetes CLI commands.

#Instance status and Events

kubectl -n <namespace> describe valkey <name>
kubectl -n <namespace> get events --sort-by=.lastTimestamp
kubectl -n <namespace> get pods -l buf.red/name=<name> -o wide

Start with .status.message and warning Events. They usually identify admission, scheduling, certificate, Service, storage, or reconciliation failures before container logs are needed.

#Data Pod logs

kubectl -n <namespace> logs <pod-name> -c valkey --tail=200
kubectl -n <namespace> logs <pod-name> -c valkey --previous --tail=200
# Run only when the exporter sidecar is enabled.
kubectl -n <namespace> logs <pod-name> -c exporter --tail=200

Use --previous after a container restart. For an active incident, add --follow and a bounded --since value rather than downloading an unbounded log.

Cluster data Pods and Sentinel Pods also run an agent sidecar container that performs in-Pod reconciliation tasks. Include its logs when diagnosing topology, announcement, or credential problems:

kubectl -n <namespace> logs <pod-name> -c agent --tail=200

#Sentinel logs

Discover Sentinel Pods and inspect the sentinel container:

kubectl -n <namespace> get pods -l buf.red/name=<name>
kubectl -n <namespace> logs <sentinel-pod> -c sentinel --tail=200

#Operator logs

Locate the Operator Deployment instead of assuming its namespace:

kubectl get deployment -A -l app.kubernetes.io/name=valkey-operator
kubectl -n <operator-namespace> logs deployment/<operator-deployment> \
  --all-containers --since=30m

When opening a support case, include the Valkey YAML with Secret data removed, related Events, Pod states, relevant container logs, Operator logs, and the exact time range. Never include Secret values or generated TLS private keys.