Domain 1 of 4 · Chapter 7 of 7

Monitor and troubleshoot AKS and Container Apps

Unlock the complete study guide + 1,040 practice questions across 16 full exams.

Bundled into the existing Developing AI Cloud Solutions on Azure premium course — no separate purchase.

14-day money-back guarantee — no questions asked.

Included in this chapter:

  • Two records: what the platform did, what your code said
  • Read the pod's events before its logs
  • Reading a CrashLoopBackOff to its root cause
  • Which probe failed decides what you see
  • Diagnosing a blocked call from inside the pod
  • Container insights: evidence after the pod is gone
  • Container Apps: streaming the two log types live
  • Container Apps: querying the stored logs
  • Exam-pattern recognition

The two records, and where each one lives per platform

What you needAKSAzure Container Apps
Platform record, livekubectl describe pod, kubectl get eventsaz containerapp logs show --type system; az containerapp env logs show
Container output, livekubectl logs -f, kubectl logs --previousaz containerapp logs show --type console --follow
Platform record, storedKubeEvents table (Container insights)ContainerAppSystemLogs_CL table
Container output, storedContainerLogV2 table (Container insights)ContainerAppConsoleLogs_CL table
Shell inside a running containerkubectl exec -it <pod> -- <command>az containerapp exec
What storing requiresContainer insights enabled on the clusterA logs destination other than Don't save logs

Decision tree

Did the container everreach a running state?Is it restarting?RESTARTS climbingAre requests reaching it?check the READY columnIs it still happening now?live, or after the factNothing of yours ran: read the platform recordAKS: kubectl describe pod (FailedScheduling, image pull)Container Apps: --type system, or az containerapp env logs showRead the instance that diedAKS: kubectl logs --previous; Reason + exit code (137 = OOMKilled)Container Apps: system log names ErrImagePull, Timeout, ContainerCrashingReadiness, not livenessREADY column, pod Conditions, Unhealthy events; RESTARTS stays 0Container Apps: the revision reads unhealthy while its replicas runAttach live and test from insideAKS: kubectl logs -f, kubectl exec -itContainer Apps: logs show --follow, az containerapp execQuery the stored copyAKS: ContainerLogV2, KubeEvents (needs Container insights)Container Apps: ContainerAppConsoleLogs_CL, ContainerAppSystemLogs_CLnoyesyesnonoyesyesno

Cheat sheet

  • kubectl describe surfaces pod events first
  • kubectl logs --previous reads a crashed container's output
  • CrashLoopBackOff means repeated container exits
  • Liveness probe failures restart the container
  • Readiness probe traffic-gating vs liveness restart
  • Diagnosing OOMKilled (137) and Pending/Unschedulable pods
  • Container Apps logs land in Log Analytics tables
  • az containerapp logs show streams live output
  • System logs carry platform events, console logs carry process output
  • Container Insights collects AKS metrics and logs
  • kubectl exec tests in-pod end-to-end connectivity
  • NetworkPolicy can silently block pod traffic

Unlock with Premium — includes all practice exams and the complete study guide.

References

  1. Debug Running Pods
  2. Application logging in Azure Container Apps
  3. Pod Lifecycle
  4. Debug Pods
  5. Troubleshoot OOMKilled errors in AKS clusters
  6. Resource Management for Pods and Containers
  7. kubectl logs
  8. Liveness, Readiness, and Startup Probes
  9. Configure Liveness, Readiness and Startup Probes
  10. Health probes in Azure Container Apps
  11. Connect to a container console in Azure Container Apps
  12. Network Policies
  13. Secure pod traffic with network policies in AKS
  14. Monitor Azure Kubernetes Service (AKS)
  15. Query container logs in Azure Monitor
  16. View log streams in Azure Container Apps
  17. Log storage and monitoring options in Azure Container Apps
  18. Monitor logs in Azure Container Apps with Log Analytics