See every pod.
Pay for the right number of them.
Datadog Container Monitoring shows every container, pod and node across Kubernetes, ECS and Fargate, live. We implement it, scope the collection so the container count stays inside the allotment where it can, and run it every month so the cluster on the dashboard is the cluster you have.
Quick facts
Related
- Infrastructure Monitoring, the hosts the containers run on
- Kubernetes Autoscaling, rightsizing from the data already collected
- Log Management, where the container logs end up
The cluster, as it is right now, not as the manifest says
A deployment is stuck at two of three replicas. The third pod has restarted eleven times in an hour and the node it keeps landing on is under memory pressure. kubectl will tell you all of this, one command at a time, if you know which cluster to ask. Container Monitoring tells you before you ask.
Every container, live. The Containers Explorer refreshes resource metrics every two seconds while you watch, across every cluster and every launch type, with facets for namespace, image, node and tag.
The cluster as Kubernetes sees it. The Orchestrator Explorer shows deployments, pods, nodes and the rest of the API objects, with their manifests and their state, so the restart loop and the pending pod are visible without a terminal.
Logs next to the container. Live tail on the container you are looking at, and indexed logs for the time range you choose, with the pod and namespace tags already on every line.
ECS and Fargate on the same screen. Tasks, services and the containers inside them, whether they run on EC2 nodes or on Fargate with no node at all, under the same tags as the rest of the estate.
A sidecar on every pod, a cluster with no name, and a tag cardinality setting nobody read
How it bills. Containers ride on the Infrastructure host meter. Each host carries an allotment of containers, pooled across the estate, and the allotment size depends on the Infrastructure tier. Usage is sampled every five minutes and averaged per hour, so short-lived containers are billed for the minutes they lived. Usage above the pooled allotment is metered per container hour. Pause containers and the Agent's own containers are excluded. Fargate has no host, so ECS Fargate tasks and EKS Fargate pods are billed on concurrent monitored tasks instead. Datadog publishes the rates. We publish nothing here, because the price is not the problem. The configuration is.
The configuration traps. Container collection is on by default, which is right, and it counts every container on the node, which is also right, including the ones nobody thinks of as part of the application. A service mesh adds a sidecar to every pod and doubles the count overnight. A CronJob that runs every minute keeps a stream of containers alive that each lives for seconds. The Helm chart disables the Orchestrator Explorer silently when no cluster name is set. Tag cardinality set to high on container metrics turns every pod name into a custom metric series. None of this looks like an error. All of it reaches the invoice or empties the dashboard.
Field noteThe most common surprise we see is the service mesh. Every pod gains a proxy sidecar, every sidecar is a container, and the container line on the invoice doubles in the month the mesh goes live. The mesh rollout and the container meter live in different consoles, so the first place the two meet is the invoice.
Field noteThe Kubernetes views are empty because the cluster name was never set in the Helm values. The Agent logs say so, once, at startup. The ticket that reaches us says Datadog does not support our cluster.
Field noteDogStatsD tag cardinality was set to high during a debugging session to get a container ID on a metric. It stayed at high. Every application metric now carries a per-container tag, and the custom metric count climbs with every deployment.
Field noteBatch jobs are the containers nobody counts. A CronJob on a one-minute schedule, a queue worker that scales to zero and back, a test suite in the production cluster. They are short, they are many, and the five-minute samples add them all up.
Cluster Agent first. Cluster name second. Scope before anyone sees a bill.
A new cluster rollout starts with LaunchPad, which runs the implementation as a managed project with a named engineer and a written scope. If the Agent is already running in the cluster, a Datadog HealthScan comes first. It is read-only and fully automated, and it reports Agent versions, container counts per host and the state of the Kubernetes views before we change anything. Either way, the sequence is the same.
- Inventory the clusters and launch types. Every cluster, its distribution, its node groups, and whether any of it runs on Fargate. Each one is a meter decision.
- Deploy the Agent and the Cluster Agent properly. Datadog Operator or Helm chart, versions pinned, cluster name set, Kubernetes State Core enabled. We confirm the Orchestrator Explorer works on the first cluster before the second starts.
- Set unified service tags on the workloads. env, service and version from pod labels, applied by the deployment pipeline. The same values the tracer and the log pipeline will use.
- Scope the collection. Which containers send logs, which metrics carry which tag cardinality, which namespaces are excluded. Written down, with the reason for each exclusion.
- Build the monitors and the dashboard pack. Restart loops, pending pods, node pressure, replica mismatch and image pull failures. Thresholds come from a fortnight of the cluster's own data, not a round number.
- Hand over, in writing. What was configured, what was excluded and why. The container count per host and the Fargate task count on the day we finished.
Access is admin on the Datadog organisation plus read access to the cluster manifests and the deployment pipeline. We do not need cluster-admin on production to implement Container Monitoring, and we do not ask for it.
Clusters are rebuilt. Agent versions drift. The allotment does not grow on its own.
A new namespace ships without labels. A cluster is upgraded and the Helm values are copied from an older one. A team adds a sidecar to its pods for a good reason. Managed Observability is the monthly service that keeps Container Monitoring matching the clusters it watches.
Every month, we review the meters. Container hours against the pooled allotment, Fargate task counts against last month, custom metric series from container tags. Anything that moved gets a reason or a fix.
Coverage follows the clusters. A new cluster, a new namespace or a new node group is found in the Orchestrator Explorer review and tagged, scoped and monitored before it is the one everyone is looking for.
Agent versions are kept together. The oldest cluster is brought up to the newest, on a schedule, so the same restart loop looks the same on every dashboard.
The incident is ours to take. Under Critical Support our engineers answer the page the cluster raised, 24x7, and fix the cause rather than report it. Datadog has published that our work reduces mean time to resolve incidents by 40 to 60 per cent.
We operate the stack. You own the product.
An implementation partner installs the Helm chart and hands over. A managed partner is still there when the mesh goes in and the container count doubles. We are the second kind. The Helm values, the Operator manifests, the exclusions and the decisions behind them stay in your repositories and your Datadog organisation, documented, and you can take them in-house whenever you choose.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Container Monitoring, answered plainly
How is Datadog Container Monitoring billed?
Containers ride on the Infrastructure host meter. Each host carries an allotment of containers, the allotment is pooled across the estate, and the size of it depends on the Infrastructure tier. Container usage is sampled every five minutes and averaged per hour, so a container that lives for ten minutes is billed for ten minutes. Usage above the pooled allotment is metered per container hour. Kubernetes pause containers and the Agent's own containers are excluded. ECS Fargate and EKS Fargate are different: there is no host, so Datadog bills on the number of tasks or pods monitored concurrently. We do not publish prices. The meters are what we tune.
Do Fargate tasks count as Datadog hosts?
No. A Fargate task has no host for the Agent to sit on, so Datadog runs the Agent as a sidecar inside the task and bills on concurrent monitored tasks rather than on hosts. The same applies to EKS Fargate pods. A cluster that mixes EC2 nodes and Fargate tasks therefore has two meters, and the dashboard that explains the invoice needs both.
Do we need the Datadog Cluster Agent?
For Kubernetes, yes. The node Agents collect container metrics, and the Cluster Agent collects cluster-level state from the Kubernetes API once rather than from every node. It is what the Orchestrator Explorer, the Kubernetes State Core metrics, cluster checks and Kubernetes Autoscaling depend on. Deploying it with the Datadog Operator or the Helm chart, with the cluster name set, is the first step of every Kubernetes implementation we do.
Can Datadog Container Monitoring collect container logs as well?
Yes. The same Agent collects container logs from stdout and stderr, and the Containers Explorer shows them next to the container through live tail. Logs are billed on the Log Management meters, not the container meter, so the decision about which containers send logs is made separately and deliberately. By default, when log collection is on, every container sends. We scope it.
What does Critical Cloud do with Container Monitoring every month?
Managed Observability runs it. Every month we review container hours against the pooled allotment and Fargate task counts against the previous month. We check the Agent and Cluster Agent versions across clusters and confirm new namespaces and clusters are tagged and covered. We retire monitors that no longer fire for a real reason, and report what changed. Under Critical Support our engineers also take the page when a cluster goes wrong, 24x7.
- Datadog products: every product, and how we implement and run each one
- Datadog Kubernetes Autoscaling: rightsizing from the metrics Container Monitoring already collects
- Infrastructure Observability Accelerator: infrastructure, APM and logs operational in four weeks
Every pod visible. Every container accounted for.
Tell us how many clusters you run and which ones are on Fargate. We will tell you what Container Monitoring is doing today, what it should be doing, and what it costs to get there.