Interpreting the question about diagnosing a distroless looping service without stdout or shell access by identifying indirect signals and the lowest-cost option.Enumerating indirect signals and ranking them by collection cost.Extending the signal list to include orchestrator state and dependency metrics while prioritizing zero-instrumentation API calls. Without a shell you lose `exec`, not `logs` - `kubectl logs` reads from the container runtime, no shell needed. If you *also* have no stdout, you've lost app logs entirely. Don't try to fix the pod, observe what observes the pod: ### 1. What remains - blackbox only **a) Control plane - already free:** `status.containerStatuses`, Conditions, Events, probe results. No agent, no code change, 1 API call. **b) Node resource accounting - already free:** cAdvisor via kubelet / metrics-server. CPU, mem, network, throttling, restarts. **c) Neighbors - already free if you have them:** Ingress / Service / mesh / downstream DB QPS, latency, errors. You don't touch the broken pod at all. You get no stacks, no pprof, no `ps/top`, no ephemeral debug - that's process-level, excluded. ### 2. Cheapest first: kubelet + API server That's cheapest because it's always-on, low-cardinality, no sampling, no sidecar. Runbook: ```bash kubectl describe pod -n # Look at: RestartCount, LastState {ExitCode, Reason: OOMKilled/Error/Completed}, # Ready 0/1 vs 1/1, Liveness/Readiness failures kubectl get events -n --sort-by=.lastTimestamp | grep kubectl top pod -n kubectl top node kubectl rollout history deploy/ ``` PromQL if you have Prometheus / kube-state-metrics: ``` rate(container_cpu_usage_seconds_total{pod="<...>"}[5m]) container_memory_working_set_bytes{pod="<...>"} rate(container_network_transmit_bytes_total{pod="<...>"}[5m]) kube_pod_container_status_restarts_total{pod="<...>"} kube_pod_container_status_waiting_reason{pod="<...>"} ``` This alone classifies 90% of loops: * **CrashLoop:** RestartCount climbing, `Waiting: CrashLoopBackOff`, Last Exit 1/2/137/139. Check deploy time correlation -> bad image/config. * **Hot CPU spin:** `Running, Ready 1/1, Restarts 0`, CPU pinned to limit, `container_cpu_cfs_throttled_seconds` climbing. Latency up downstream, but no restarts. * **Deadlock / blocked loop:** `Running, Ready 0/1`, Readiness failing, CPU ~0, mem flat, egress ~0. Not spinning, just stuck. * **Retry storm:** CPU moderate, egress network spike, restarts 0. Downstream shows N*x QPS amplification, DB connection / 429 / 5xx spike. Pod looks healthy, neighbors are on fire. Second cheapest is caller-side: ingress p99, service mesh `destination_workload` error rate, queue depth, DB slow query. If *you* can't see the looper, see who it calls. Don't go to tracing, packet capture, eBPF `kubectl debug`, Parca/Pyroscope continuous profiling until these two layers fail to classify.

SCB SCB-supervision-T2 MK3