Monitor the service behind the container
A Docker container can be running while its application cannot answer requests. A Compose service can also appear healthy now after repeatedly restarting earlier. Useful Docker monitoring separates process state, healthcheck results, restart history and the behaviour your users experience.
MetriBeacon combines supported Docker Compose readings in a server profile with host measurements, histories and alarms. Add a public HTTP monitor when you also need an outside view of your website or API. This guide shows how to assemble those signals without treating one green indicator as proof that everything works.
Understand four different container signals
Choose measurements by the question they answer. Supported Compose service readings include:
| Signal | What it tells you | What to check alongside it |
|---|---|---|
| Service running | Whether the observed service instances are running | Healthcheck result and application response |
| Service health | The reported health state, including an absent healthcheck | What the configured probe actually tests |
| Service ready | Whether the instances are running and meet the available health condition | Freshness and the scope of the healthcheck |
| Restarts | Docker's reported restart counter for the current instances | Changes over a selected period and instance replacement |
For readiness, configured healthchecks must be healthy; where no healthcheck exists, the running state counts. That fallback is useful process evidence, but it is not a successful application test. Inspect the separate health reading before interpreting readiness as a verified healthy application.
Docker's HEALTHCHECK documentation explains the starting, healthy and unhealthy states. A probe answers only the question you put into it. Testing a local HTTP route does not establish that DNS, public TLS, a reverse proxy and a user's workflow all work.
Connect your Docker host and select a Compose service
Begin with a Linux Docker host and a current MetriBeacon agent that supports the readings you need. Follow the agent installation and connection guide, choose your workspace and connect a Server monitor. Keep the device identity and keys private.
Open the monitor's server profile. Review discovered components and select the relevant Compose project and service. For example, a project named example-app might contain a service named api. These are placeholders for your own configuration, not names you should copy blindly.
Compose project and service identity let monitoring follow a service when Docker replaces its container. Confirm the selected identity, especially when several projects use a service named “web” or “db”. A service name without its project context can be ambiguous.
Select the supported running, readiness, health and restart readings you need, then review reporting intervals and the quota preview. Detected components are suggestions until you enable their readings. Save the profile, wait for the agent to confirm the configuration and check that the first observations arrive with recent timestamps.
Keep Docker access local and deliberate
Container observations can require approval for a local permission policy. Grant only the checks for the Compose service you intend to monitor. If collection reports unavailable or permission denied, inspect that local access and the agent's status; do not turn an access failure into a fabricated stopped-container value.
Docker daemon access is powerful, as the Docker Engine security guide explains. Keep monitoring access local and use the supported restricted collection path. Publishing an unauthenticated Docker API or granting every process general daemon access is not a necessary monitoring step.
For a separate local diagnostic, docker compose ps can help you inspect the project you are currently in. Verify the project before comparing its output with the selected MetriBeacon component. A diagnostic command and a recorded monitoring series should refer to the same service and time.
Add a check of the application response
Create a public HTTP monitor for a meaningful website or API endpoint. The API monitoring article explains status, response text and JSON checks. Choose a condition that reflects the operation you care about rather than assuming every HTTP 200 means the entire application is healthy.
The public HTTP checker cannot reach private Docker networks or localhost. Observe local sources with the agent or a suitable local integration, and use an HTTP check for an intentionally public endpoint. Do not expose a private database or administration endpoint merely to make an external check possible.
This gives you useful combinations to investigate:
- Containers are running, but the public API check fails: investigate routing, the application response and its dependencies.
- A container healthcheck is unhealthy while the host looks normal: inspect what the probe tests and whether the application is ready.
- Restart counts grow alongside host memory pressure: compare timestamps and local diagnostics before concluding that memory caused the restarts.
These are investigation paths, not automatic diagnoses.
Read restart history as a counter
A restart counter is not a count of new failures in every displayed chart bucket. A historical value of eight does not mean eight restarts happened in the latest minute. Use the period's observed increments to understand recent activity.
MetriBeacon identifies replacement of container instances as a counter reset. A new instance can begin with a smaller value without representing a negative number of restarts. Missing observations also remain gaps; do not infer the exact timing of unobserved changes from a smooth chart.
Open the measurement history for a useful window and inspect the counter interpretation. Container timelines show states, while restart bars show new restarts per displayed time bucket. Compare that period with deployments, changes in health state and server resource readings.
Host CPU, memory and filesystem measurements describe the host. They are not automatically per-container resource measurements. Keep each chart's scope and unit clear when investigating a single Compose service.
Configure alarms with a practical first action
Use a state rule for a supported boolean or named-state condition, and choose which observed state should trigger it. Allow for normal startup and the healthcheck's own timing. Required duration or repeated observations should fit the reporting interval and the application's startup behaviour.
Add an appropriate missing-data rule when you need to notice collection stopping. A last recorded healthy state can become stale. Device contact and fresh container readings are separate signals.
Connect a confirmed destination and test it using the notification setup guide. Decide who investigates an alert and which local check they should start with. For planned deployments, review maintenance or muting deliberately; measurements and a notification pause have different purposes.
Test a controlled state change on a development service you own. Confirm that MetriBeacon receives the expected reading, the rule opens an incident and the chosen recipient gets the message. Restore the service and verify the configured recovery condition. Monitoring reports the observation; container restart and repair policies remain your application's responsibility.
A short Docker monitoring checklist
- The monitor refers to the intended Docker host, Compose project and service.
- Selected readings are supported and the agent has the required local approval.
- Readiness is interpreted together with healthcheck configuration and freshness.
- Restart charts show observed changes with replacement resets respected.
- A suitable public application endpoint has its own HTTP check when needed.
- Alarms have a tested destination, an owner and a useful first action.
If customers need a public explanation of an outage, publish selected information through a status page. Internal container names and diagnostic details do not need to become public.
Frequently asked questions about Docker monitoring
Does a running container mean my website is available?
No. Running describes process state. Use meaningful healthchecks and a separate HTTP observation of the public service to understand application behaviour.
What does readiness mean without a healthcheck?
For an observed instance without a configured healthcheck, the running state contributes to readiness. That does not prove that an application route or dependency has been tested. Check the separate health state and configure a useful probe where appropriate.
Why did a restart counter decrease?
Docker may have replaced the container instance. MetriBeacon recognises instance replacement as a reset. Interpret recent increments within the relevant instance history rather than subtracting unrelated totals.
Can I use MetriBeacon for free?
Yes, within the documented technical quotas. Selected series, reporting intervals, HTTP checks and notifications use account budgets. Review the profile's quota preview before enabling additional readings.
Start with one Compose service
Create a free MetriBeacon account, connect your Docker host and choose one important Compose service. Confirm recent readings, inspect a meaningful history window and test one actionable alert. The Website/API template below helps you add the complementary public HTTP check.
