<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Debugging on Chen Kai Blog</title><link>https://www.chenk.top/en/tags/debugging/</link><description>Recent content in Debugging on Chen Kai Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Wed, 21 Jun 2023 09:00:00 +0000</lastBuildDate><atom:link href="https://www.chenk.top/en/tags/debugging/index.xml" rel="self" type="application/rss+xml"/><item><title>Docker and Containers (6): Debugging and Logging — When Things Go Wrong Inside a Box</title><link>https://www.chenk.top/en/docker-containers/06-debugging-and-logging/</link><pubDate>Wed, 21 Jun 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/docker-containers/06-debugging-and-logging/</guid><description>&lt;p>A container that works is invisible. A container that doesn&amp;rsquo;t work is a black box. The entire point of containerization is isolation — but that same isolation makes debugging harder. You can&amp;rsquo;t just &lt;code>ssh&lt;/code> into a container or browse its filesystem from the host. Docker provides a specific set of tools for inspecting, diagnosing, and understanding what happens inside running (and crashed) containers.&lt;/p>
&lt;hr>
&lt;h2 id="reading-container-logs" class="heading-anchor">Reading Container Logs&lt;a href="#reading-container-logs" class="heading-link" aria-label="Permalink to this section" title="Copy link to this section">#&lt;/a>
&lt;/h2>&lt;p>Logs are your first line of investigation. Docker captures everything a container writes to stdout and stderr.&lt;/p></description></item></channel></rss>