After a Cloud environment recovers from an unplanned outage (503 Service Unavailable, requiring a host reboot to bring it back), the usual diagnostic logs (mtctl-style logs, database alert logs, Event Viewer) don't show anything useful, since most of what's captured only starts after the restart — where else can you look to find the actual root cause?

All FAQ questions / Developer Studio, deployment, and upgrades

Answer

Use kubectl logs <podName> -c <containerName> --previous -n <namespace> to retrieve the logs from the previous (crashed) instance of a pod's container, before it restarted — this captures activity right up to the crash that a fresh restart's own logs won't show. It's worth checking this specifically for the deployments most likely to surface a root cause: ifsapp-proxy, ifsapp-odata, ifsapp-iam, and ifsapp-client. Redirecting that output to a file for offline analysis is the practical way to dig through it for the actual error that caused the outage.

Documentation-based answer. Confirm the product and release before applying it. This answer has not been verified in an IFS environment.

← Browse Developer Studio, deployment, and upgrades questions