Docker Monitors

Docker monitors read a container's state from the Docker Engine API and map it to a Kener status. If the container has a HEALTHCHECK, its result is used too. The connection to the daemon is part of the monitor, like every other monitor type.

Minimum setup

1. Create a monitor with the type Docker Container.
2. Check the connection type and the socket path or daemon address. They start on DOCKER_HOST when it is set.
3. Enter the container name, or click Browse to pick one from the daemon.
4. Click Save. Test Monitor runs against the saved settings.
5. Click Test Monitor.

Kener talks to the daemon from the machine it runs on. If Kener itself runs in a container, mount the socket:

services:
    kener:
        volumes:
            - /var/run/docker.sock:/var/run/docker.sock

Connection types

The address may carry a scheme (tcp://host:port). Without a port, Kener uses 2375 for tcp and 2376 for tls.

Default connection

A new Docker monitor starts on the local socket. Behind a socket proxy, set the standard Docker variable once, and every new Docker monitor starts on the proxy instead:

services:
    kener:
        environment:
            - DOCKER_HOST=tcp://docker-socket-proxy:2375

Any other scheme, such as ssh:// or npipe://, logs one warning and keeps the local socket. A saved monitor keeps its own connection. The variable only fills the dashboard form: a monitor created through the API must send connectionType and daemon. TLS certificates stay per monitor, as below.

Keeping the TLS key out of the database

The three PEM fields accept $SECRET references, the same substitution API monitor headers use. Set the PEM in an environment variable and reference it:

DOCKER_TLS_KEY="-----BEGIN PRIVATE KEY-----
..."

Then enter $DOCKER_TLS_KEY as the client key. Kener resolves it on every check, so the key never reaches the database or the browser. The certificate and key are a pair: provide both or neither.

Status logic

Docker daemon checks call GET /_ping: UP when the daemon answers, otherwise DOWN. Use one as the parent monitor for a host.

Container checks use this table:

Latency is the round-trip time of the Docker API call, so the latency chart shows daemon responsiveness, not the application inside the container.

Configuration fields

Example

{
    "monitor_type": "DOCKER",
    "type_data": {
        "connectionType": "tls",
        "daemon": "docker.example.com:2376",
        "tlsCa": "$DOCKER_TLS_CA",
        "tlsCert": "$DOCKER_TLS_CERT",
        "tlsKey": "$DOCKER_TLS_KEY",
        "checkType": "container",
        "containerName": "kener-app",
        "timeout": 10000
    }
}

Verify

Save the monitor, then click Test Monitor. A healthy container returns UP with the API round-trip time. A stopped one returns DOWN with the container state and exit code.

Troubleshooting

• "Docker socket not found": the socket is not mounted into the Kener container, or the path is wrong.
• "Permission denied on the Docker socket": the Kener process cannot read the socket. Use a socket proxy rather than loosening the socket permissions.
• "Container ... not found": the daemon answered, but no container has that name or id. Click Browse to see what the daemon reports.
• Browse fails behind a socket proxy: the proxy must allow CONTAINERS. Container checks fail the same way until it does.
• TLS errors: give the CA that signed the daemon's certificate, and the client certificate and key together if the daemon runs with --tlsverify.

Related: Monitors Overview, API Monitors for the $SECRET substitution rules