Skip to main content

Run the Wakora agent in Docker

The natural way to monitor a Docker host is the normal package install: the agent on the host recognises dockerd and monitors every container through the Docker socket, grouped by image. Running the agent itself as a container is for hosts where nothing may be installed outside a container. It sees the same things, with two flags that give it host visibility.

Planned

A published image on a public registry is planned. Today you build it from the public source; the Dockerfile is four lines.

Build the image​

git clone https://github.com/wakora-io/agent.git
cd agent/packaging
curl -fsSL https://get.wakora.io/bin/wakora -o wakora
docker build -t wakora-agent:latest .

Verify the downloaded binary first if your policy asks for it: Verifying the download yourself.

Register, then run​

Registration and the long-running agent must see the same host identity, which is why both commands use --network=host (the identity is bound to the machine id and the hostname):

docker run --rm --network=host -v wakora-config:/etc/wakora \
  wakora-agent:latest --key <YOUR_TEAM_KEY>

docker run -d --name wakora --restart=always \
  --pid=host --network=host --cap-add=SYS_PTRACE \
  -v wakora-config:/etc/wakora -v wakora-state:/var/lib/wakora \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  wakora-agent:latest
  • --pid=host lets the agent enumerate the host's processes and ports, and read the stacks of sibling PHP-FPM containers for CPU flame graphs.
  • --network=host gives it the host's addresses and a loopback the applications can reach.
  • SYS_PTRACE is the capability the profiling layer needs.
  • the Docker socket, read-only, is what the Docker probe uses; the CLI is not needed.

APM for applications in containers​

An application in another container exports its traces to the agent over the Docker bridge. Start the agent with --otlp-bind <bridge address> (the host's own address on the docker0 network, 172.17.0.1 on a default install) in addition to the default loopback listener, and point the application's exporter at http://<that address>:4318. The bind stays on the bridge address, never 0.0.0.0, so only containers on that network can reach it. See Local ports and APM.

Notes​

  • Processes inside other containers are excluded from host-level service discovery, so a containerised PostgreSQL does not match the host PostgreSQL definition. It is covered by the Docker probe as part of its image group, and by APM if it exports traces.
  • eBPF needs a kernel that allows it from the container's context; on most setups the containerised agent falls back to access-log request rates for the APM first layer.
  • wakora uninstall inside the container makes little sense; remove the container and the two volumes, and remove the host from the console.

See also Monitoring Docker.