CoreDNS and cert-manager: your cluster is probably shipping untagged metrics

A recent beta run against a workforce-scheduling SaaS company's org turned up 47 custom metrics missing required env/service tags. That number alone isn't unusual — we've written before about untagged custom metrics as a checklist item. What's worth a dedicated post is where almost all 47 of them came from: 39 under the coredns.* namespace and 7 under cert_manager.*. Not a developer's hand-rolled application metric. Two of the most common add-ons in any Kubernetes cluster.

Why this is a pattern, not a mistake

CoreDNS is the default cluster DNS server for Kubernetes — if you're running a standard cluster, you're almost certainly running CoreDNS. cert-manager is the de facto standard for automating TLS certificate issuance and renewal inside Kubernetes. Both ship their own metrics, and both are commonly scraped into Datadog through Datadog's own Kubernetes / cluster-level integrations rather than through any application code a team member wrote. That distinction matters: nobody at this company forgot to tag coredns.autopath.success_count the way someone might forget to tag a metric they wrote by hand. The metric was emitted, ingested, and left untagged by the default behavior of a standard integration, at cluster-config level, times 39 sub-metrics.

Which means this finding generalizes unusually well. If a large share of Datadog's customers run any Kubernetes cluster at all, a meaningful share of them are plausibly carrying the same or a similar pattern right now, entirely unnoticed, because 39 untagged metrics under one namespace don't look like 39 separate problems — they look like noise, until someone groups them.

The report groups by namespace on purpose

This run's report listed the finding one row per namespace, not one row per metric — specifically because a single integration routinely produces dozens of sub-metrics that all share the same root cause and the same fix. Seeing "39 metrics, all missing env/service, all under coredns.*" is a five-second read that points straight at cluster-level config. Seeing 39 individually-listed metric names with no grouping would have buried that signal in noise nobody would have read past the first ten rows.

Namespace	Count	Missing tags
coredns.*	39 metrics	env, service
cert_manager.*	7 metrics	env, service

Where the real fix lives — and it isn't 46 individual metric edits

Datadog's answer to exactly this problem is Unified Service Tagging: a standard set of tags — env, service, and version — applied consistently across metrics, traces, and logs. The point of Unified Service Tagging is that you set it once, at the source, and every metric that source emits inherits it automatically. For metrics arriving through a Kubernetes integration, that source is typically the Datadog Agent or the cluster-level integration configuration, not the individual metric. In practice this usually means one or more of: environment variables on the Agent deployment (commonly along the lines of DD_ENV and DD_SERVICE), values set in your Agent's Helm chart configuration, or Kubernetes pod annotations in the style of ad.datadoghq.com/<container>.tags scoped to the relevant workload. Get the tagging right at that level once, and the fix propagates to all 39 CoreDNS metrics and all 7 cert-manager metrics without touching a single metric definition.

We're deliberately not giving you an exact menu path or a specific Helm key to paste in here. The precise configuration surface depends on how your cluster is provisioned, which Datadog Agent version you're running, and whether you're using the Datadog Operator, the Helm chart, or a hand-rolled DaemonSet — those specifics genuinely vary. What's stable across all of them is the target: fix the tagging at the Agent/cluster-integration level, verify against Datadog's own Kubernetes integration documentation for the exact values your setup expects, and confirm afterward that new CoreDNS and cert-manager metrics are arriving with tags attached rather than tagging the historical backlog by hand.

Not every row in this category is namespace-scale

Two other rows in the same finding were nothing like the CoreDNS/cert-manager pattern, and worth naming so the lesson doesn't overgeneralize into "everything untagged is a cluster-config issue":

• A single metric, CustomLogin, was missing only service — a one-metric, one-tag gap, almost certainly a specific application's own custom metric rather than an integration default.
• A metric named Logins came back inconclusive — the tool couldn't determine its missing tags at all, the same honest-uncertainty outcome we cover in a separate post about findings the tool won't guess at.

Same finding category, three genuinely different situations: a cluster-wide integration default affecting 39 metrics, a single missed tag on one application metric, and one metric the tool simply couldn't resolve. Treating all untagged-metric findings as the same problem with the same fix would have missed all three of the actual, different next steps.