A thousand integrations.
Forty of them for a reason.
Datadog's integration catalogue connects the cloud accounts, the databases, the queues and the tools the estate already runs, with nothing to build. We implement the ones the estate needs and scope each one so it does not quietly add hosts or custom metrics. Then we keep them current every month, so a dashboard that went flat is a page rather than a mystery.
Quick facts
Related
- Infrastructure Monitoring, the hosts the cloud integrations add
- Fleet Automation, the Agent configuration the checks live in
- Database Monitoring, where the database check becomes query-level detail
The database, the queue and the cloud account, on the same timeline as the service that depends on them
The checkout slowed at 14:10 and the trace says the time went into PostgreSQL. Without the PostgreSQL integration, that is where the investigation ends. With it, the same minute shows the connection pool at its limit and a vacuum that started at 14:09. Integrations are how the thing next to the service gets onto the graph.
Cloud accounts, read through a role. AWS, Azure and Google Cloud metrics and resources collected through an API role with nothing installed. Load balancers, managed databases, queues and functions arrive with their cloud tags attached, so the dashboard can be sliced the way the bill is.
Agent checks for whatever is next to the host. PostgreSQL, MySQL, Redis, Kafka, RabbitMQ, NGINX, the JVM, Windows services and several hundred more, each with its own dashboard and recommended monitors. The metrics from a standard check are included, not custom.
Containers that configure themselves. With Autodiscovery, a pod's annotations tell the Agent which check to run and how, as the pod starts. A new Redis appears in the cluster and is monitored before anyone files a ticket to monitor it.
The tools the on-call already uses. Slack, PagerDuty, Microsoft Teams, Jira, GitHub, Terraform and the rest, so the alert reaches a person, the incident gets a channel, and the deploy that caused it is marked on the graph.
A batch fleet counted as hosts, a /metrics endpoint counted as custom metrics, and a check that stopped in June
How it bills. The integrations carry no meter. Their consequences do. A cloud integration that collects EC2 metrics makes every instance it sees an infrastructure host, Agent or no Agent, unless collection is limited by tag. An Agent host is not counted twice, provided the Agent can read the instance metadata. Active Lambda functions land on the serverless meter. Metrics from most standard checks are included. Metrics from OpenMetrics, Prometheus, JMX, Windows performance counter and WMI checks are custom metrics, and so are custom queries on the database checks and custom CloudWatch metrics, all counted against the allotment each host brings. CloudWatch polling also shows up on the AWS bill. Datadog publishes the rates. The scope of each integration is the configuration that decides the number.
The configuration traps. The AWS integration enabled with every service tile on, including the ones the estate does not use, so the role polls CloudWatch for things that do not exist. No tag filter on EC2 collection, so the autoscaled batch fleet is a hundred hosts on Tuesday afternoons. An OpenMetrics check with a wildcard for its metric list, so the whole endpoint from every pod becomes custom metrics. A check configured by hand on one host and never put in the deployment tooling, so the rebuild loses it. No monitor on the integration's own health, so a rotated credential looks like a quiet month.
Field noteThe most common gap we see is the cloud integration with no tag filter. It was enabled to see the load balancers. It also saw every EC2 instance in the account, and every one of them appeared on the invoice as an infrastructure host without a single Agent being installed.
Field noteAn OpenMetrics check pointed at an application's /metrics endpoint with a wildcard for its metric list. The endpoint exposes everything the framework knows how to export, per pod, and the custom metric count climbs with every scale-out. The three metrics anyone looks at are in there somewhere.
Field noteThe pattern we keep finding is the flat line read as calm. The database credential was rotated on schedule, the check started failing, and the dashboard showed nothing for weeks. Nobody noticed because nothing was alerting, and nothing was alerting because nothing was being collected.
Field noteA check configured by hand on one host, during an incident, to see one thing. It worked, the incident closed, and the configuration lived only on that host. The next rebuild removed it, and the next incident on the same component started from nothing again.
Inventory first. Scope every integration before it is on. Configuration in code, never on a host.
For a new estate, integrations are set up inside LaunchPad, the project-managed rollout. If the integrations are already on and the invoice is the reason for the call, a Datadog HealthScan reports what is enabled, what is reporting and what each one contributes to the meters, read-only and fully automated. The sequence is the same either way.
- Inventory the estate. Every cloud account, database, cache, queue, web server and tool, with its owner and whether it matters at 2am. The integration list comes from this, not from the catalogue.
- Scope the cloud integrations. Only the service tiles the estate uses. EC2 collection limited by tag, so the batch fleet is a decision rather than a surprise. Resource collection on where Cloud Security needs it.
- Configure Agent checks in the deployment tooling. Check configuration in the same code that deploys the Agent, with Autodiscovery annotations for containers. Nothing is configured by hand on a host.
- Set the metric scope on the expensive ones. An allowlist on every OpenMetrics, Prometheus and JMX check. Custom SQL queries justified one by one. Checked against the custom metric allotment before the first week of data.
- Put a monitor on every check. Each integration's own health is monitored, so a rotated credential or a changed trust policy pages as a configuration fault within the hour. Credential lifecycles are recorded, with who rotates what and when.
- Hand over, in writing. The integrations enabled and why, the cloud collection filters, the metric allowlists, the credential register, and the host and custom metric counts each integration contributed on the day we finished.
Access is admin on the Datadog organisation, cloud roles applied through your infrastructure as code, and Agent configuration through your deployment tooling. Integration credentials for databases and SaaS tools are issued by you, with read-only scope, and recorded in your secret store rather than ours.
Integrations are switched on in a hurry and never switched off at all
A new queue appears in the service map with no integration. A proof of concept leaves a SaaS integration connected to nothing. An Agent upgrade changes what a check collects by default. Managed Observability is the monthly service that keeps the integration set matching the estate and the meters.
Every month, enabled is compared with used. Integrations that feed no dashboard, monitor or investigation are retired. The host and custom metric contribution of each one is reviewed, and anything that moved gets a reason or a fix.
Coverage follows the service map. A new database, cache or queue that the traces depend on and no integration covers is found in the monthly review and configured, in code, before it is the component everyone is asking about.
Checks are kept reporting. Integration health monitors are reviewed, credentials due for rotation are flagged ahead of time, and a check that stopped is treated as the fault it is rather than as a calm month.
Versions are kept current. Integration updates arrive with Agent releases. Changed defaults are read before the upgrade rather than discovered on the invoice, and rollouts go through Fleet Automation one group at a time.
We operate the stack. You own the product.
Anyone can enable an integration. The work is in knowing which ones to enable, what each one does to the host count and the custom metric count, and noticing when one stops. We have switched on most of the catalogue at some point in ten years of running Datadog, and we have switched most of it off again somewhere else. The integration configuration lives in your deployment tooling, the credentials live in your secret store, and both are documented so you could take it in-house tomorrow.
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 integrations, answered plainly
What kinds of Datadog integrations are there?
Datadog lists more than a thousand, in three broad kinds. Cloud integrations read metrics and resources from AWS, Azure and Google Cloud through an API role, with nothing installed. Agent checks run on the host and talk to the thing next to them: PostgreSQL, Redis, Kafka, NGINX, a JVM, a Windows service. SaaS and tooling integrations connect Slack, PagerDuty, Jira, GitHub and the like for routing and context. Containers add Autodiscovery, where the Agent configures the check from the pod's annotations as it starts. Each kind is set up differently and bills differently, which is why the list is sorted before anything is switched on.
How are Datadog integrations billed?
The integrations themselves carry no meter. Their consequences do. A cloud integration that collects EC2 metrics makes every instance it sees an infrastructure host, Agent or no Agent, unless collection is limited by tag. Active Lambda functions are counted on the serverless meter. Metrics from most standard integrations are included. Metrics from OpenMetrics, Prometheus, JMX, Windows performance counter and WMI checks are custom metrics, and so are custom queries on the database checks and custom CloudWatch metrics, all counted against the allotment that comes with each host. CloudWatch polling also appears on the AWS bill. Datadog publishes the rates. We do not publish prices. We decide the scope of each integration with you before it is enabled.
Why does enabling the AWS integration add hosts to our Datadog bill?
Because the integration discovers EC2 instances and Datadog counts each one it collects metrics for as an infrastructure host, whether or not an Agent is installed. An instance with an Agent is not counted twice, provided the Agent can read the instance metadata. The autoscaled batch fleet nobody meant to monitor is the usual surprise. Collection can be limited by tag, so only the instances that carry the monitoring tag, or none of the ones that carry an exclusion tag, are collected. Setting that filter is the first thing we do on an AWS integration.
What happens when an integration credential is rotated?
The check fails, and unless something is watching for that, the dashboard goes flat and flat is read as quiet. A database integration with a rotated password, a cloud role with a changed trust policy and a SaaS token that expired all look the same from the graph: a line that stopped. We put a monitor on every integration's own health, so a check that stops reporting pages as a configuration fault rather than being mistaken for a calm week. The credential lifecycle is recorded at handover, so rotation does not come as news.
What does Critical Cloud do with integrations every month?
Managed Observability reviews which integrations are enabled against which are used, and retires the ones feeding nothing. It checks the host count and custom metric count each integration contributes, confirms every check is reporting, and updates integration versions through the Agent release. It adds integrations for the new database or queue that appeared in the service map. What changed, and what it did to the meters, is reported.
- Datadog products: every product, and how we implement and run each one
- Infrastructure Monitoring and Fleet Automation: the hosts the cloud integrations add, and the Agent configuration the checks live in
- Datadog custom metrics cost optimisation: where the OpenMetrics and JMX checks send the bill
- LaunchPad: the project-managed rollout where the integration set is scoped and configured in code
Every integration for a reason. Every check still reporting.
Tell us which cloud accounts and databases the estate runs on and what the host count on the last invoice was. We will tell you which integrations are earning their place, which are adding hosts and metrics by accident, and what it takes to keep the set honest.