<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Docker Containers on Netdata</title><link>https://www.netdata.cloud/tags/docker-containers/</link><description>Recent content in Docker Containers on Netdata</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 22 Aug 2026 05:09:03 +0300</lastBuildDate><atom:link href="https://www.netdata.cloud/tags/docker-containers/index.xml" rel="self" type="application/rss+xml"/><item><title>Container Monitoring Software With Zero Configuration</title><link>https://www.netdata.cloud/solutions/use-cases/container-monitoring/</link><pubDate>Thu, 18 Dec 2025 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/solutions/use-cases/container-monitoring/</guid><description>Transform container monitoring with Netdata&amp;rsquo;s edge-native platform. Get per-second metrics, automated dashboards, ML anomaly detection, and AI troubleshooting - all without complex setup or unpredictable costs.</description></item><item><title>Docker Compose Networking: Service Discovery &amp; Ports</title><link>https://www.netdata.cloud/academy/docker-compose-networking-mysteries/</link><pubDate>Sun, 10 Aug 2025 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/academy/docker-compose-networking-mysteries/</guid><description>&lt;p&gt;You&amp;rsquo;ve meticulously crafted your docker-compose.yml file, your services build correctly, and the startup process finishes without a single error. Yet, when your application tries to connect to its database, you get a &amp;ldquo;Connection refused&amp;rdquo; or &amp;ldquo;Host not found&amp;rdquo; error. This is a classic and frustrating scenario in Docker Compose networking. Your containers are running, but they&amp;rsquo;re isolated in their own digital worlds, unable to communicate.&lt;/p&gt;&#10;&lt;p&gt;These issues almost always boil down to two core mysteries: service discovery failed events, where containers can&amp;rsquo;t find each other, and docker compose port conflict problems, where port mappings are misunderstood or misconfigured. To build reliable containerized applications, you must look beyond the docker-compose.yml file and understand the virtual network that Docker creates. This guide will demystify that network, providing you with the tools and techniques to troubleshoot and resolve these common connectivity challenges.&lt;/p&gt;</description></item><item><title>How To View Docker Container Logs A Step-by-Step Guide</title><link>https://www.netdata.cloud/academy/docker-logs/</link><pubDate>Mon, 09 Jun 2025 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/academy/docker-logs/</guid><description>&lt;p&gt;Your containerized application is misbehaving. The service is unresponsive, or worse, it&amp;rsquo;s &lt;a href="https://www.netdata.cloud/guides/docker/docker-container-exits-immediately/"&gt;crash-looping&lt;/a&gt;. As a developer or SRE, your first instinct is to ask, &amp;ldquo;What do the logs say?&amp;rdquo; For applications running in &lt;a href="https://www.netdata.cloud/guides/docker/"&gt;Docker&lt;/a&gt;, accessing and understanding container logs is the most fundamental troubleshooting skill you can possess. These logs are the raw, unfiltered story of what your application is doing, thinking, and feeling.&lt;/p&gt;&#10;&lt;p&gt;But &lt;code&gt;docker logging&lt;/code&gt; is more than just a single action. It&amp;rsquo;s a comprehensive system with layers of functionality, from quickly tailing real-time output to implementing robust, production-grade log management strategies. This guide will walk you through everything you need to know to effectively &lt;code&gt;view docker container logs&lt;/code&gt;, starting with the basics and progressing to the best practices that will keep your applications observable and your on-call nights quiet.&lt;/p&gt;</description></item><item><title>Docker Monitoring Tool With Unlimited Containers</title><link>https://www.netdata.cloud/solutions/technologies/docker-monitoring/</link><pubDate>Mon, 27 Jan 2025 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/solutions/technologies/docker-monitoring/</guid><description>Netdata brings the simplicity Docker promised to monitoring. One command install, instant visibility into every container&amp;rsquo;s CPU, memory, disk, and network. No agents per container, no complex pipelines, no surprise bills.</description></item><item><title>Container deployment showdown: Docker or Kubernetes?</title><link>https://www.netdata.cloud/blog/container-deployment-showdown-docker-or-kubernetes/</link><pubDate>Wed, 24 Mar 2021 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/blog/container-deployment-showdown-docker-or-kubernetes/</guid><description>&lt;!--truncate--&gt;&#10;&lt;div class="et_pb_module et_pb_text et_pb_text_0 et_pb_text_align_left et_pb_bg_layout_light"&gt;&#10;&lt;div class="et_pb_text_inner"&gt;&#10;&lt;img class="alignnone wp-image-16433 size-large" src="../wp-archive/uploads/2022/03/Kubernetes_vs_Docker-1200x828.png" alt="" width="1200" height="828" /&gt;&#10;&lt;p&gt;Monitoring the current state and performance of applications is critical for IT Ops and DevOps teams alike. Understanding the health of an application is one of the most effective ways of anticipating potential bottlenecks or slowdowns, yet it’s one of the largest challenges faced by many organizations that build and deploy software. This is largely due to applications’ distributed and diversified nature. A single outage has the potential to interrupt entire processes that, at times, can interfere with business as a whole and result in a negative effect on the bottom line.&lt;/p&gt;</description></item><item><title>Docker container cannot connect to another container</title><link>https://www.netdata.cloud/guides/docker/docker-container-cannot-connect-to-container/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-container-cannot-connect-to-container/</guid><description>&lt;p&gt;Connection timeouts or &amp;ldquo;connection refused&amp;rdquo; between containers on the same host point to a failure in one of four layers: the bridge network, Docker&amp;rsquo;s embedded DNS, iptables, or the application bind address. Inter-container networking relies on Linux bridges, veth pairs, iptables rules, and an embedded DNS resolver at 127.0.0.11. This guide isolates the faulty layer and fixes it.&lt;/p&gt;&#10;&lt;h2 id="what-this-means"&gt;What This Means&lt;/h2&gt;&#10;&lt;p&gt;&lt;a href="https://www.netdata.cloud/guides/docker/"&gt;Docker&lt;/a&gt; isolates each container in its own network namespace. Containers on the same custom bridge communicate through a Linux bridge and resolve each other by name via Docker&amp;rsquo;s embedded DNS. The default &lt;code&gt;bridge&lt;/code&gt; network has no embedded DNS. If containers are on different networks, if the target application binds to 127.0.0.1, or if iptables rules were wiped by an external firewall reload, traffic stops. The symptom appears at the application layer, but the root cause can be Layer 2, Layer 3, or the application itself.&lt;/p&gt;</description></item><item><title>Docker container exits immediately: how to diagnose it</title><link>https://www.netdata.cloud/guides/docker/docker-container-exits-immediately/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-container-exits-immediately/</guid><description>&lt;p&gt;A container that exits immediately prints its ID during &lt;code&gt;docker run&lt;/code&gt;, appears briefly in &lt;code&gt;docker ps&lt;/code&gt;, then vanishes. &lt;code&gt;docker ps -a&lt;/code&gt; lists it as &lt;code&gt;Exited&lt;/code&gt; with an uptime measured in seconds. Unlike a restart loop, it stays stopped.&lt;/p&gt;&#10;&lt;p&gt;A Docker container is a Linux process wrapper, not a virtual machine. Its lifecycle is bound to PID 1 in the container&amp;rsquo;s namespace. When that process completes, crashes, or is killed, the container exits. An immediate exit means the process finished its work, failed to start, or was terminated during initialization. This guide gives you a diagnostic flow to find out why PID 1 terminated, interpret the exit code, and fix the root cause.&lt;/p&gt;</description></item><item><title>Docker container high memory usage: how to diagnose it</title><link>https://www.netdata.cloud/guides/docker/docker-container-high-memory-usage/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-container-high-memory-usage/</guid><description>&lt;p&gt;Your container is sitting at 90% of its memory limit but has not been OOMKilled. Or it is being killed repeatedly and you cannot tell whether the limit is too low or the application is leaking. docker stats shows a single percentage, but that number does not reveal the breakdown between reclaimable page cache and anonymous memory that the kernel cannot reclaim. To diagnose this correctly, you need to decompose cgroup memory.stat, map it to your runtime&amp;rsquo;s actual allocations, and decide whether the problem is cache pressure, a runtime mismatch, or a true leak.&lt;/p&gt;</description></item><item><title>Docker container keeps restarting: causes, checks, and fixes</title><link>https://www.netdata.cloud/guides/docker/docker-container-keeps-restarting/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-container-keeps-restarting/</guid><description>&lt;p&gt;A container that restarts every few seconds is not self-healing. It is a crash loop that wastes CPU, floods logs, and masks the real failure. Docker&amp;rsquo;s restart policy can hide whether the application is OOM-killed, segfaulting, or waiting for a dependency that never arrives. This guide shows how to read the signals, map exit codes to causes, and stop the loop before it degrades the host.&lt;/p&gt;&#10;&lt;h2 id="what-this-means"&gt;What This Means&lt;/h2&gt;&#10;&lt;p&gt;When a container&amp;rsquo;s main process exits or is killed, Docker increments &lt;code&gt;RestartCount&lt;/code&gt; in the container metadata and starts a new instance if the restart policy allows. The count persists across daemon restarts. A container that crashes immediately on every start creates a death spiral: each cycle truncates ephemeral state, writes new log data, and adds overhead to the daemon and storage driver. The container may appear to be &amp;ldquo;running&amp;rdquo; for a few seconds before it disappears again, which makes the failure easy to miss if you only check whether the process exists.&lt;/p&gt;</description></item><item><title>Docker container memory leak: how to find one and prove it</title><link>https://www.netdata.cloud/guides/docker/docker-container-memory-leak/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-container-memory-leak/</guid><description>&lt;p&gt;Memory that only ever climbs is easy to spot. The harder problem is proving whether the growth is a leak, unbounded caching, or a limit set below the working set. During an incident, operators need to decide in minutes whether to page an on-call developer or bump a cgroup limit. This guide shows how to use cgroup memory.stat, process-level RSS, and container restart patterns to build a defensible diagnosis. You will be able to separate anonymous memory growth from &lt;a href="https://www.netdata.cloud/guides/docker/docker-memory-usage-explained/"&gt;reclaimable cache&lt;/a&gt;, identify whether the leak lives in application heap or runtime overhead, and present evidence that justifies either a code fix or a capacity change.&lt;/p&gt;</description></item><item><title>Docker Container Running But Unhealthy: How To Fix</title><link>https://www.netdata.cloud/guides/docker/docker-container-running-but-unhealthy/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-container-running-but-unhealthy/</guid><description>&lt;p&gt;The container is up. &lt;code&gt;docker ps&lt;/code&gt; shows it running. But the status is &lt;code&gt;(unhealthy)&lt;/code&gt; and your load balancer or orchestrator has stopped sending traffic. This means Docker&amp;rsquo;s health check command is returning a non-zero exit code, or timing out, while the container&amp;rsquo;s main process stays alive. The container is running, but Docker does not consider it ready.&lt;/p&gt;&#10;&lt;p&gt;An unhealthy state is not a crash. In Swarm, it triggers replacement. In Compose, &lt;code&gt;depends_on&lt;/code&gt; with &lt;code&gt;condition: service_healthy&lt;/code&gt; blocks downstream services. Even on a single host, an unhealthy mark often precedes a restart loop that buries the real error in noise. You need to distinguish between a broken application, a broken probe, and a broken runtime configuration.&lt;/p&gt;</description></item><item><title>Docker CPU throttling: the hidden cause of container latency</title><link>https://www.netdata.cloud/guides/docker/docker-cpu-throttling/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-cpu-throttling/</guid><description>&lt;p&gt;Your application latency just spiked. p99 response times doubled or tripled. CPU dashboards show the container at 40% utilization. Memory is fine. Network is quiet. You restart the container, redeploy, or blame the code, but the pattern repeats.&lt;/p&gt;&#10;&lt;p&gt;The culprit is often CPU throttling. &lt;a href="https://www.netdata.cloud/guides/docker/"&gt;Docker&lt;/a&gt; uses Linux CFS bandwidth control to enforce CPU limits in discrete 100ms periods. A container can exhaust its quota in a burst, spend the rest of each period throttled by the kernel, and still report a modest average CPU over a longer window. This guide shows how to confirm throttling from cgroup metrics, calculate its severity, and fix it without guessing.&lt;/p&gt;</description></item><item><title>Docker disk space full: how to troubleshoot /var/lib/docker</title><link>https://www.netdata.cloud/guides/docker/docker-disk-space-full/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-disk-space-full/</guid><description>&lt;p&gt;You notice deployments failing with &amp;ldquo;no space left on device,&amp;rdquo; image pulls hanging, or the Docker daemon becoming sluggish. On a &lt;a href="https://www.netdata.cloud/guides/docker/"&gt;Docker&lt;/a&gt; host, everything lives under /var/lib/docker: image layers, container writable layers and logs, named volumes, and build cache. When this filesystem fills, the failure is cascading and abrupt. New containers cannot start, running containers may fail on writes, and daemon operations deadlock.&lt;/p&gt;&#10;&lt;p&gt;This guide walks through identifying which of the five major consumers is dominating your disk, safely reclaiming space without deleting data you still need, and fixing the configuration gaps that let it happen again.&lt;/p&gt;</description></item><item><title>Docker DNS not working inside containers</title><link>https://www.netdata.cloud/guides/docker/docker-dns-not-working/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-dns-not-working/</guid><description>&lt;p&gt;Your application logs show connection timeouts. Health checks against dependency names are failing. &lt;code&gt;curl&lt;/code&gt; from inside a container returns &amp;ldquo;Could not resolve host&amp;rdquo; while the same name resolves fine on the host. DNS inside Docker is not a simple passthrough to the host resolver. It is a stack of namespace-specific forwarders, embedded resolvers, and inherited configuration that breaks in specific, repeatable ways.&lt;/p&gt;&#10;&lt;p&gt;This guide will help you determine whether the failure is a missing embedded DNS, a poisoned resolv.conf, an upstream forwarding issue, or a version regression. You will be able to distinguish between inter-container name resolution failures and external lookup failures, identify the root cause with safe read-only checks, and apply the correct fix without guessing.&lt;/p&gt;</description></item><item><title>Docker exit code 137: OOMKilled or SIGKILL?</title><link>https://www.netdata.cloud/guides/docker/docker-exit-code-137/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-exit-code-137/</guid><description>&lt;p&gt;A container exits with code 137. Docker restarts it, or it stays down, and you need to know why. The number itself only tells you that the process received SIGKILL. What matters for your next step is whether the kernel&amp;rsquo;s cgroup OOM killer fired because the container exceeded its memory limit, or whether an external actor sent the signal. The remediation for an undersized memory limit is completely different from fixing a misconfigured stop timeout or an orchestrator sending a premature kill. This guide shows how to classify the cause in under a minute using only the Docker CLI and cgroup files.&lt;/p&gt;</description></item><item><title>Docker exit code 143: SIGTERM and graceful shutdown failures</title><link>https://www.netdata.cloud/guides/docker/docker-exit-code-143/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-exit-code-143/</guid><description>&lt;p&gt;You are reviewing container exit codes after a deployment or node drain and see 143. If your monitoring alerts on it, you might think something failed. Exit code 143 is not an error. It is 128 plus signal 15 (SIGTERM), and it means the container&amp;rsquo;s PID 1 process received SIGTERM and exited voluntarily. This is exactly what &lt;code&gt;docker stop&lt;/code&gt; is designed to do.&lt;/p&gt;&#10;&lt;p&gt;The operational problem is not the code itself, but what happens around it. If your application never receives the signal, it gets SIGKILL after the timeout and exits 137, potentially dropping connections and corrupting state. If your orchestrator pages you for 143 during a normal rolling restart, your alerts are noisy. If your stop timeout is too short for your database to finish checkpointing, you risk data inconsistency.&lt;/p&gt;</description></item><item><title>Docker image cleanup: safe pruning strategies for production hosts</title><link>https://www.netdata.cloud/guides/docker/docker-image-cleanup/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-image-cleanup/</guid><description>&lt;p&gt;When &lt;code&gt;df -h /var/lib/docker&lt;/code&gt; shows 87% utilization, the urge to run &lt;code&gt;docker system prune -a&lt;/code&gt; is strong. On production hosts, that is a mistake. Cleanup is not about finding the single command that reclaims the most space. It is about knowing exactly what each flag deletes, what it leaves behind, and which filters prevent a 3 a.m. image re-pull because a base layer was removed.&lt;/p&gt;&#10;&lt;p&gt;This guide covers the safe pruning hierarchy: dangling images, unused tagged images, build cache, and the dangerous flags that touch volumes or running workloads. The goal is to reclaim space, automate cleanup safely, and avoid outage patterns caused by aggressive pruning.&lt;/p&gt;</description></item><item><title>Docker JVM memory tuning: heap, off-heap, and the cgroup mismatch</title><link>https://www.netdata.cloud/guides/docker/docker-jvm-memory-tuning/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-jvm-memory-tuning/</guid><description>&lt;p&gt;Your Java container is &lt;a href="https://www.netdata.cloud/guides/docker/docker-oomkilled/"&gt;OOMKilled&lt;/a&gt; at 02:00. Heap usage is 60%. Docker reports exit code 137 and &lt;code&gt;OOMKilled: true&lt;/code&gt;. The JVM never threw an &lt;code&gt;OutOfMemoryError&lt;/code&gt;.&lt;/p&gt;&#10;&lt;p&gt;In a container, the kernel enforces memory limits through cgroups, but the JVM heap is only one component of process RSS. Off-heap memory, metaspace, thread stacks, direct byte buffers, and GC overhead all count against the same cgroup limit. When total RSS crosses that limit, the kernel kills the container without a JVM-level error. In some JDK and kernel combinations, the JVM fails to detect the cgroup limit entirely and sizes the heap against host RAM, which guarantees an OOM kill.&lt;/p&gt;</description></item><item><title>Docker logs taking too much disk space: how to fix log growth</title><link>https://www.netdata.cloud/guides/docker/docker-logs-disk-space/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-logs-disk-space/</guid><description>&lt;p&gt;The default json-file logging driver captures every line a container writes to stdout and stderr and appends it to a file under &lt;code&gt;/var/lib/docker/containers/&lt;/code&gt;. There is no size limit out of the box. A container with verbose logging, a stuck retry loop, or a crash spiral can grow its log file by gigabytes per day until the filesystem is full.&lt;/p&gt;&#10;&lt;p&gt;When &lt;code&gt;/var/lib/docker&lt;/code&gt; fills, the impact is not limited to logging. &lt;a href="https://www.netdata.cloud/guides/docker/"&gt;Docker&lt;/a&gt; cannot create new containers, &lt;a href="https://www.netdata.cloud/guides/docker/docker-image-cleanup/"&gt;image pulls fail&lt;/a&gt;, running containers may error on writes, and the daemon can hang during storage operations. This article shows how to identify which containers are responsible, safely reclaim space without restarting workloads, and configure durable limits so the problem does not recur.&lt;/p&gt;</description></item><item><title>Docker memory limits: how to set them and what happens when they hit</title><link>https://www.netdata.cloud/guides/docker/docker-memory-limits/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-memory-limits/</guid><description>&lt;p&gt;A container without a memory limit can consume all available RAM, force the kernel to reclaim page cache, push the system into swap, and eventually trigger a host-level OOM kill that takes down the Docker daemon or other critical processes. Setting &lt;code&gt;--memory&lt;/code&gt; is not enough: limits can be silently ignored, misread by runtimes, or masked by swap behavior that turns a clean failure into a slow crawl.&lt;/p&gt;&#10;&lt;p&gt;Exit code 137 can mean an OOM kill or an external SIGKILL. The difference matters because the fix for an undersized limit is not the same as the fix for a runtime sizing its heap from host memory instead of the cgroup limit.&lt;/p&gt;</description></item><item><title>Docker memory usage explained: anonymous, file, slab, and what counts</title><link>https://www.netdata.cloud/guides/docker/docker-memory-usage-explained/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-memory-usage-explained/</guid><description>&lt;p&gt;You look at &lt;code&gt;docker stats&lt;/code&gt;, see a container sitting at 1.2 GB of a 1.5 GB limit, and assume it is about to explode. It might be fine. That total includes page cache the kernel will reclaim the second another process asks for memory. Meanwhile, a different container reports 600 MB with no limit set, yet its anonymous memory grows 50 MB per hour and will force a host-level OOM kill before lunch.&lt;/p&gt;</description></item><item><title>Docker Monitoring</title><link>https://www.netdata.cloud/monitoring-101/docker-monitoring/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/monitoring-101/docker-monitoring/</guid><description>&lt;h2 id="docker-monitoring"&gt;Docker Monitoring&lt;/h2&gt;&#10;&lt;h3 id="what-is-docker"&gt;What Is Docker?&lt;/h3&gt;&#10;&lt;p&gt;Docker is an open platform that packages applications and their dependencies into lightweight, portable units called &lt;strong&gt;containers&lt;/strong&gt;. A container bundles everything the software needs to run — code, runtime, system tools, libraries, and settings — so it behaves the same way on a developer&amp;rsquo;s laptop, in staging, and in production. Because containers share the host operating system&amp;rsquo;s kernel instead of shipping a full guest OS, they start in milliseconds and use far fewer resources than virtual machines.&lt;/p&gt;</description></item><item><title>Docker monitoring checklist: the signals every production host needs</title><link>https://www.netdata.cloud/guides/docker/docker-monitoring-checklist/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-monitoring-checklist/</guid><description>&lt;p&gt;Production Docker incidents rarely look like Docker problems at first. They show up as application latency, deployment failures, or hosts that suddenly refuse to schedule containers. By the time you notice, the daemon may be hung, a log file has filled the disk, or a container has been silently throttled into unusable latency. This checklist groups the essential production signals into three priority tiers: must-have alerts that keep the host alive, should-have metrics that expose resource pressure before it becomes an outage, and nice-to-have security and internal signals for mature environments. Every signal includes where to read it from the raw cgroup filesystem or the Docker API so you can instrument hosts without guessing paths.&lt;/p&gt;</description></item><item><title>Docker OOMKilled: causes, detection, and prevention</title><link>https://www.netdata.cloud/guides/docker/docker-oomkilled/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-oomkilled/</guid><description>&lt;p&gt;A container exits with code 137 and restarts. The application loses in-memory state. Dependent services start failing. The restart loop begins. This is the OOMKilled pattern, and it is one of the most common and most misdiagnosed failure modes in Docker environments.&lt;/p&gt;&#10;&lt;p&gt;This article covers how to confirm an OOM kill, distinguish it from an external SIGKILL, understand why it happened, and prevent recurrence. It also covers the JVM-in-container memory mismatch, which is responsible for a large share of OOM kills in Java workloads.&lt;/p&gt;</description></item><item><title>Docker Operations Guides</title><link>https://www.netdata.cloud/guides/docker/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/</guid><description>Learn how Docker actually runs in production, what breaks first, and what to monitor as your operation grows up.</description></item><item><title>Docker published port not reachable: troubleshooting -p and EXPOSE</title><link>https://www.netdata.cloud/guides/docker/docker-published-port-not-reachable/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-published-port-not-reachable/</guid><description>&lt;p&gt;You mapped a port with &lt;code&gt;-p 8080:80&lt;/code&gt;, but &lt;code&gt;curl&lt;/code&gt; against the host IP returns connection refused. &lt;code&gt;docker ps&lt;/code&gt; shows the mapping, the container is running, and the port still appears closed.&lt;/p&gt;&#10;&lt;p&gt;A published port depends on three layers: a runtime mapping rule (&lt;code&gt;-p&lt;/code&gt;), a host forwarding path (iptables DNAT and FORWARD policy), and an application listener inside the container bound to an interface that receives the forwarded packet. EXPOSE in a Dockerfile is metadata. It does not publish ports, create firewall rules, or set bind addresses.&lt;/p&gt;</description></item><item><title>Docker socket security: why /var/run/docker.sock is root access</title><link>https://www.netdata.cloud/guides/docker/docker-socket-security/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-socket-security/</guid><description>&lt;p&gt;Mounting &lt;code&gt;/var/run/docker.sock&lt;/code&gt; into a container grants that container a root-equivalent privilege boundary. This is not a Docker vulnerability. The daemon runs as root, listens on a filesystem socket, and trusts any client that can write to it.&lt;/p&gt;&#10;&lt;p&gt;Symptoms of abuse look like container escape or host compromise, but the container never escaped. It asked the root-owned daemon to perform privileged operations on its behalf. This guide explains the mechanism, how to audit exposure, and what constraints you can apply without rebuilding your pipeline.&lt;/p&gt;</description></item><item><title>Docker volume cleanup: finding and removing orphaned volumes</title><link>https://www.netdata.cloud/guides/docker/docker-volume-cleanup/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-volume-cleanup/</guid><description>&lt;p&gt;Run &lt;code&gt;docker system df&lt;/code&gt; and the &lt;code&gt;Local Volumes&lt;/code&gt; line keeps growing. Run &lt;code&gt;docker system prune&lt;/code&gt; and you reclaim images and build cache, but the volume count barely drops. A few weeks later the disk alert fires again.&lt;/p&gt;&#10;&lt;p&gt;Data persists in &lt;code&gt;/var/lib/docker/volumes/&lt;/code&gt; after its consumer is long gone. These volumes waste disk, complicate capacity planning, and can hide sensitive data in forgotten corners of the filesystem.&lt;/p&gt;&#10;&lt;p&gt;This guide covers how Docker volumes become orphaned, how to distinguish unused volumes from named data stores that should stay, and how to remove them safely.&lt;/p&gt;</description></item><item><title>Reading docker system df: where Docker disk usage actually lives</title><link>https://www.netdata.cloud/guides/docker/docker-system-df/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/docker/docker-system-df/</guid><description>&lt;p&gt;You run &lt;code&gt;docker system df&lt;/code&gt; but the numbers do not add up to what &lt;code&gt;df -h&lt;/code&gt; reports. Maybe the Build Cache row is empty while &lt;code&gt;/var/lib/docker/buildkit/&lt;/code&gt; consumes tens of gigabytes. Maybe RECLAIMABLE is high but &lt;code&gt;docker system prune&lt;/code&gt; barely frees space because overlay2 layer sharing masks the real unique cost. Or the daemon returns &lt;code&gt;Error response from daemon&lt;/code&gt; when the disk is already full. This guide shows how to read &lt;code&gt;docker system df&lt;/code&gt; precisely, what it hides, and how to triage the real consumers on the host.&lt;/p&gt;</description></item></channel></rss>