Prometheus service discovery for teams whose targets change constantly
Prometheus service discovery replaces hand-maintained target lists with discovery providers that feed the same pull scrape loop Prometheus uses for every target. Rather than an operator editing a scrape file each time a pod is rescheduled, a Consul registration appears, or an autoscaling group adds an instance, the server asks a provider for the current set of targets and scrapes what it finds. The Prometheus overview describes this pull model: the server fetches metrics over HTTP from targets found through service discovery or static configuration. If your targets come and go with deployments, autoscaling or failover, this is the difference between a monitoring estate that tracks current workloads and one that quietly misses new services while it keeps scraping addresses that no longer exist.
You need dynamic discovery when target membership changes faster than people can update configuration, or when one Prometheus server must cover several clusters or clouds. Kubernetes discovery reads pods, services, endpoints and nodes from the API server. Consul discovery reads service catalog registrations. Cloud providers offer their own discovery for compute instances, and DNS-based discovery resolves record names into targets. Each provider needs read access to its source system, so the team must decide which credentials the Prometheus server holds, how they are rotated and who owns each source. Ask those owners how changes reach the source system before you design anything on the Prometheus side.
Static configuration remains a sound choice for a small, stable set of hosts or appliances whose addresses rarely change. File-based discovery sits between the two: a separate process writes target files that Prometheus reloads, which suits a team that already keeps an inventory in a configuration management tool or CMDB. Before choosing, measure how often targets change and how long a stale list could go unnoticed. A static list for a fixed set of database servers may hold for years, while a Kubernetes namespace that deploys several times a day will not. Choose the simplest option that keeps the target list accurate at the rate your systems actually change.
Which discovery mechanism fits Kubernetes, Consul, cloud, DNS, HTTP and file targets
This table compares the discovery mechanisms Prometheus offers for finding scrape targets, with the platform each one suits, the target identity it produces, the access it needs and what to confirm for your version. Use it to narrow the choice first, then check the configuration docs for the exact permissions and metadata labels your release provides.
| Discovery mechanism | Platform that fits and target identity | Access it needs | What to confirm in the docs for your version |
|---|---|---|---|
| Kubernetes | Clusters you run. Produces targets for pods, services, endpoints, nodes and ingresses, each with __meta_kubernetes labels describing its namespace and object. | A service account with list and watch permission on the object types you select, reachable through the API server. | Which resource roles exist, the exact RBAC verbs required, and the __meta_kubernetes labels available for each role. |
| Consul | Environments that register services in Consul. Produces one target per registered service instance, with labels for node, service name and tags. | An ACL token with read access to the services and nodes you want to scrape, and network access to the Consul agents or servers. | How the token policy must be written, which service and node labels exist, and how health filtering and datacenter selection behave. |
| Cloud provider | Virtual machine fleets and managed services in a provider account. Produces one target per discovered instance, with labels from the provider's metadata such as region, tags and addresses. | An identity with read or describe permissions for the instances, regions and tags in scope, plus network routes to the private addresses. | The provider-specific discovery block for your version, the permissions it calls, the metadata labels it exposes and any rate limits the provider applies. |
| DNS | Hosts published under DNS names, including SRV records for services that advertise ports. Produces targets from the records returned by the resolver. | Network access from the Prometheus server to the DNS resolver that holds the records. No credentials are usually involved. | The record types supported in your version, how SRV port handling works, and how the refresh interval interacts with your DNS TTLs. |
| HTTP | Your own inventory or CMDB exposed as an endpoint that returns a list of targets in JSON. Produces one target per listed address with labels you define. | Network access from Prometheus to the endpoint, with TLS and authentication configured for it. Access to the endpoint should be restricted to the Prometheus servers. | The JSON response format the version expects, the supported authentication options, and how failed refreshes keep the last known target list. |
| File | Teams that generate targets from a pipeline, script or configuration management tool. Produces targets from JSON or YAML files that Prometheus watches for changes. | Read access to the files on the Prometheus host, and a controlled process that writes them with the correct ownership and permissions. | The supported file formats, the watch and refresh behavior, and whether changes are picked up without a reload in your version. |
| Static configuration (baseline) | Small, stable estates with a fixed list of hosts. Produces targets exactly as written in the configuration file, with no dynamic changes. | Write access to the configuration file and a reload process, with no external permissions needed. | How configuration reloads are triggered, whether the lifecycle endpoint is enabled in your deployment, and how static and dynamic blocks combine in one job. |
How discovered targets become scrape jobs and series
Every series Prometheus stores passes through the same path: a service discovery provider returns a list of candidate targets, relabeling rules decide which of them are scraped and which labels they carry, and Prometheus then pulls metrics from each surviving target over HTTP. The provider itself does not decide what gets scraped. It returns addresses and metadata labels, typically prefixed with a meta label namespace such as __meta_kubernetes_, __meta_consul_ or the cloud provider's equivalent, and those meta labels exist only during relabeling. Before you design any rule, confirm the exact meta labels your chosen provider emits in the version you run, because the names differ between providers and between releases.
Within a scrape configuration, the job name comes from the job_name field you set, and it is written to the job label of every series from that configuration. The scrape_interval and scrape_timeout values come from the scrape configuration, unless you override them per job. The instance label is derived from the target address after relabeling, and by default it is the host and port that Prometheus scrapes. The __address__ and __scheme__ and __metrics_path__ labels control where the request goes, so a relabeling rule that rewrites __address__ changes the instance value as well as the destination. Check these three derivations in the configuration reference and in the /targets page of a test server before you rely on them.
Relabeling runs in two stages. Relabel rules in relabel_configs act on targets before the scrape, and metric_relabel_configs act on samples after the scrape and before storage. Only labels that survive these stages are stored. Meta labels that you do not copy into a normal label are discarded, so a dashboard or alert cannot filter on them later. A rule that drops a target with action: drop removes the whole target, while a rule with action: labeldrop or labelkeep affects which labels remain on every series. Each of these choices shapes the label set that PromQL queries, recording rules and alerting rules will see for the life of the data.
Treat label decisions here as a contract with everything downstream. Label names such as cluster, environment, team and service should be chosen once, documented, and mapped from provider metadata in one place. Avoid copying high-cardinality meta labels such as pod UID or container ID into series labels unless a specific query needs them, because each distinct value creates another series. Use the /config and /targets pages, and the scrape duration and sample count metrics that Prometheus exposes for itself, to verify what was kept. Ask your team to name the owner of the relabeling configuration, because a silent change there can alter every dashboard without any error.
Using relabeling to keep labels consistent and cardinality under control
Target relabeling runs before a scrape happens. It acts on the metadata that service discovery attaches to each candidate target, so it decides which targets are scraped at all and which labels they carry into storage. Most label consistency is won or lost here, because every series from a target inherits these labels.
- Keep and drop by metadata: use keep and drop actions on discovery labels, such as a namespace, a service name or an annotation that marks a workload as monitored.
- Build standard labels: map cluster, environment, team and service from discovery metadata into fixed label names so dashboards and alerts share one vocabulary.
- Set addresses and paths: derive the port or metrics path from annotations where services expose metrics differently.
- Remove discovery-only labels: discovery metadata is verbose, so keep only the labels you query on.
Check the target page after rollout and confirm that every expected target appears with the labels your team agreed on, including with the owners of each cluster or cloud account.
Metric relabeling runs after a scrape, on the samples a target returned, before they are stored. It is the place to drop series nobody reads and to align exporter output with your naming standard. Because it runs after the scrape, it does not reduce the load on the target or the network, but it does reduce what reaches storage.
- Drop metric families: match metric names with a regular expression when a library exposes families that no dashboard or alert uses.
- Drop label names: remove a verbose label from one family when it duplicates information held in another label.
- Rename or copy labels: align exporter labels with your convention so queries work across teams.
- Version the rules: keep rule files in source control and review them with alert and dashboard changes, because a dropped metric silently breaks any query that depends on it.
After rollout, run a query for each dropped family to confirm the series are gone, and confirm the dependent dashboards still return data.
Cardinality is the number of distinct label combinations a metric produces. A label with a bounded set of values, such as an environment or an HTTP status class, adds a small multiplier. A label with unbounded values, such as a request ID, pod UID or user identifier, creates a new series for almost every value. The cost of that label grows with the number of series stored, in memory, disk and query time.
Illustrative example: a counter labeled only with method and status stays within a fixed set of series, while the same counter with a request_id label creates a new series for every request. A drop rule removes the label before storage:
```yaml metric_relabel_configs:
- regex: request_id
action: labeldrop ```
- Find the offenders: list the labels with the most distinct values per job before you write a rule.
- Drop at the right stage: remove unbounded labels in metric relabeling, and fix the instrumentation if the label is needed in logs or traces instead.
- Check for collisions: confirm that the remaining labels stay unique within each scrape, because samples that collide after a label is removed can be rejected.
- Track the total: watch the active series count per job over time.
Before and after rollout, compare the series count per job and confirm that the label you removed is no longer present in storage.
Prometheus writes to a local time series database. The storage documentation states that local storage is not clustered or replicated and should be managed like any other single-node database. Cardinality decisions therefore land on one disk and one process, so sizing must account for the series you allow, not only the samples per second.
- Size from series count: estimate disk and memory from the active series count you measure after relabeling, not from the count you expected.
- Bound retention: set retention by time or size so disk use has a ceiling, and confirm the flags for your release.
- Plan node backups: design backup and restore for the single node, because replication is not built in.
- Offload long-term data: use remote write to send samples to external long-term storage when retention needs exceed one node's disk, and confirm that system's own limits.
Ask your implementation partner or platform team for the active series count per job before and after relabeling, and confirm the node's disk and memory headroom against that figure.
How to set up discovery and verify targets before go-live
This sequence takes Prometheus from an inventory of platforms to a configuration where every discovered target is expected, labeled consistently and checked before any dashboard or alert depends on it. Each step ends with an output and a check that must pass before the next step starts.
Inventory platforms and their access model
Your team lists every platform Prometheus will discover from, including each Kubernetes cluster, Consul datacenter, cloud account, DNS zone, HTTP endpoint and file source. For each one, record who owns it, which identity Prometheus will use to read it (a service account, Consul ACL token, cloud IAM role or network path) and what that identity is allowed to see. Record the expected number of targets per platform. Done when every platform has an owner, an identity and an expected target count that the platform owners have confirmed.
Choose a discovery mechanism per platform
Map each platform to one discovery mechanism: Kubernetes, Consul, a cloud provider, DNS, HTTP or file-based discovery. Native mechanisms read the platform API directly, so they need credentials and generate API load in proportion to how often they refresh. File-based discovery moves that work into a generator process that someone must own and monitor. Note any exporter, such as SNMP or Blackbox, that takes targets from URL parameters, because the Prometheus security model warns that anyone with HTTP access can make it send requests to arbitrary endpoints. Done when each platform has one mechanism, a written reason and a named owner for its credentials.
Decide the reload method before go-live
Prometheus does not expose its reload and shutdown endpoints unless the lifecycle flag is set, and its admin HTTP APIs are disabled by default. The admin API flag enables destructive operations, so it should stay off unless there is a documented need. Choose one reload method before go-live: a process signal sent by the service manager, or an enabled lifecycle endpoint reachable only from the configuration pipeline and protected by authentication. Ask your team to confirm the flags for your version against the Prometheus security model. Done when the method is written into the runbook and tested in a non-production environment, and only the intended caller can reach it.
Write the label scheme
Define the labels every target must carry, such as environment, team, service and region, and state where each value comes from. Separate source labels, which come from discovery metadata, from the labels that remain on stored series. Keep identifiers that change on every deploy, such as pod names, IP addresses or container IDs, out of the labels that dashboards and alerts group by. Set a cardinality limit for each label that your team agrees on, and list the allowed value sets for every bounded label. Done when the platform and observability owners have reviewed the scheme and each label has a documented source and bound.
Add relabeling rules and test them
Write relabeling rules that turn platform metadata into the labels from the scheme, keep only the endpoints that belong to the inventory and set job and instance values consistently. Use relabel configurations to shape targets before they are scraped, and metric relabel configurations to drop unwanted series after scraping. Keep drop rules narrow and commented, because a broad rule can silently remove a whole platform. Test the rules against sample discovery output and compare the kept and dropped counts with the inventory from step one. Done when each rule has a stated purpose and the test output matches the expected counts.
Load configuration and confirm the reload
Deliver the configuration through the reload method chosen earlier and confirm that Prometheus has loaded the new file. Check the logs and the status page for parse or reload errors before reading any target state. Load the same configuration first in a non-production environment, then in production, and keep the running file in version control so the two can be compared. Done when the running configuration matches the file in version control and no error is reported after the reload.
Check targets and labels before dashboards
Open the targets page and compare the number of up and down targets for each job with the expected inventory from step one. Investigate any difference: a shortfall usually points to a discovery or permission gap, and an excess usually points to a relabeling rule that kept too much. Then inspect the discovered labels on a sample of targets to confirm that every required label is present, that values fall within the allowed sets and that no label exceeds the agreed cardinality limit. Done when those checks pass, and only then should dashboards and alerts be built on these labels.
Security risks in discovered targets, credentials and reload endpoints
Prometheus exposes its web UI, API and some exporters over HTTP, and discovery feeds those endpoints with targets, labels and addresses. The risks below sit where those pieces meet: transport security, login, browser-facing controls, outbound requests made on behalf of users, and endpoints that change running configuration. Review each one before the first scrape reaches production.
TLS and client certificates
Prometheus can serve its own web endpoints over TLS and can require client certificates, with TLS 1.2 as the minimum version it accepts. Decide early which endpoints need it: the web UI, the API, and any exporter that serves metrics to the server. Check the certificate chain, expiry dates and renewal process for each scrape job, because discovered targets in Kubernetes, Consul and cloud accounts often appear and disappear faster than certificates are reissued. Confirm the TLS options against the security model for the release you run, since supported settings change between versions.
Basic authentication and cleartext exposure
Basic authentication stores passwords as bcrypt hashes in the web configuration file, so that file should be readable only by the Prometheus service account. The credentials travel with every request, and without TLS they cross the network in cleartext. Treat basic authentication as a fallback for small or internal setups, and enable TLS on every listener that accepts it. Check that each scrape configuration and remote write client uses its own credential, stored where your secrets tooling can rotate it without editing the main configuration.
Single sign-on and CSRF protection
Prometheus has no built-in single sign-on, and its security model notes that it has no built-in CSRF protection on mutating endpoints. In practice, place an authenticating reverse proxy in front of the web UI and API so users sign in through your identity provider before any request reaches Prometheus. Confirm that the proxy rejects cross-site requests to endpoints that change state, and that the Prometheus port cannot be reached directly from the cluster or cloud network. Document the proxy as part of the monitoring design, because its team owns the login path.
Exporter target parameters
Exporters such as SNMP and Blackbox take the target to probe from URL parameters. The security model warns that anyone with HTTP access to them can make them send requests to arbitrary endpoints. Service discovery and relabeling can fill those parameters from labels such as Kubernetes annotations or Consul tags, so a person who can edit a service definition may be able to steer a probe. Restrict who can reach exporter ports, review any relabel rule that copies annotations or tags into the target parameter, and confirm whether your exporter version supports an allow list for probe targets.
Admin and lifecycle endpoints
The admin HTTP API is disabled by default. The --web.enable-admin-api flag enables destructive operations, and --web.enable-lifecycle enables the reload and shutdown endpoints. Keep both flags off unless a documented runbook needs them. If your configuration pipeline depends on lifecycle reloads, restrict the endpoint to that pipeline's network path and log every caller, because a reload applies whatever configuration is on disk, including discovery and relabeling changes. Verify the flags on the running process, not only in the deployment manifest.
Deciding who owns the label scheme across teams
Label ownership decides whether a Prometheus service discovery design stays readable a year from now, and it is a governance question before it is a technical one. Before you write a single relabel_configs block for Kubernetes, Consul or cloud discovery, decide which team owns the standard labels (environment, cluster, service and team), who can add a new label name, and who signs off when a relabeling rule changes which targets are kept or how they are named. In most estates the platform or observability team owns the core set, application teams own the service and team values they supply through pod annotations, Consul service tags or cloud resource tags, and security or compliance stakeholders review anything that carries personal or regulated data.
Write the approval path down before the first rollout. A practical version has three parts: a short register of standard label names with their meaning and allowed values, a request step for any new label that names a requester, a reason and the dashboards or alert rules that would use it, and a review step for relabeling changes. Keep relabeling configuration in version control, require a second reviewer for changes to keep, drop or replace rules, and record which release of the scrape configuration was live when an incident happened. Confirm with your own change process whether these reviews fit into existing merge and change-approval workflows. Prometheus does not enforce this process on its own, and we have not confirmed that any tooling in your environment enforces it either, so check that with your team and vendors before you rely on it.
The trade-off is simple to state and easy to underestimate. A stricter scheme takes more design effort at the start: someone has to agree on names, value formats and exceptions, and teams wait on approvals when they want a new label. A looser scheme moves faster at the start and then produces surprises: the same service appears under three spellings, a dashboard filters on a label that one cluster stopped emitting, and an alert rule quietly matches nothing after a discovery change. Because dashboards and alert rules depend on label names, every renamed label is a breaking change for them, so the cost of a loose scheme usually appears during an incident rather than during design.
Pick the level of strictness deliberately for each label. Environment and cluster values are usually worth tight control because they drive routing, access and alert scope. Team and service values may need a registry with a named owner, so that ownership questions have an answer during an on-call handover. Free-form labels that come from application instrumentation need a limit on how many values they can take, because unbounded values inflate series counts and storage. Ask your platform team to produce a list of the labels currently emitted by each discovery source, mark which ones dashboards and alerts depend on, and decide the owner and approval rule for each one before the scrape configuration reaches production.
What to confirm in your environment before committing to a discovery design
Service discovery decides which targets Prometheus scrapes, and each choice below changes how many series, identities and servers you run. Confirm these six items in your own environment before you fix a design. The answers show whether one Prometheus server per site is enough or whether you need a central store.
Discovery providers and configuration keys
Each discovery mechanism you plan to use, such as Kubernetes, Consul, cloud provider integrations, DNS, HTTP or file-based discovery, is configured with specific keys. Check the provider list and the exact configuration fields in the documentation for the Prometheus version you will run, and test your configuration against that version. Your upgrade plan sets the version reference. The current long-term support line is 3.13, supported until July 31, 2027, so confirm that the line fits your upgrade schedule before you commit.
Access for discovery identities
Discovery needs read access to the objects it lists: pods, services and endpoints in Kubernetes, the service catalog in Consul, and instance or inventory APIs in each cloud. Define one identity per platform and scope it to the namespaces, regions, tags or accounts that hold the targets you intend to scrape. Confirm where credentials are stored, how they rotate and who can read them. A discovery identity with broad access exposes your full inventory to anyone who can reach the Prometheus host.
Expected target counts and churn
Count the targets each provider returns at steady state and during deployments, scaling events and failovers. High churn means the target set changes constantly, which increases reload activity and produces gaps in series when instances are replaced. Ask platform owners for peak pod counts, autoscaling limits and how often instances are recycled. Use those figures to set scrape intervals and to decide how many Prometheus servers each cluster, region or site needs.
Series budget and label cardinality
A series budget is the number of active time series your Prometheus servers can hold and query without overload. Relabeling decides which labels survive discovery, and a label copied from a pod annotation or instance tag can multiply series quickly. Estimate active series per target from a sample scrape, multiply by the expected target count, and compare the result with the memory and CPU you plan to provide. Assign an owner who approves changes to labels that come from discovery.
Retention and local storage
Prometheus stores samples in a local time series database built from two-hour blocks and a write-ahead log. Default retention is 15 days, and you can configure retention by time or by size, so decide which limit applies first in your environment. Local storage is not clustered or replicated, so plan disk capacity, snapshots and recovery as you would for any single-node database. Confirm how far back your dashboards, alert reviews and incident investigations need to look.
Central storage and accuracy needs
If you need history beyond local retention or queries across many Prometheus servers, decide whether remote write to a long-term storage system belongs in the design. Remote write adds a queue, a network path and a second system to operate and secure. Also confirm that the data meets your accuracy requirements. Prometheus values reliability over precision, so it is a poor fit where every request must be counted exactly, such as per-request billing.
What Prometheus service discovery costs and what the work needs from your team
What drives the cost of Prometheus service discovery work?
The cost comes from infrastructure, storage, implementation and operations, because Prometheus is open source under Apache-2.0 with no paid enterprise edition. The main drivers of implementation effort are the number of platforms you discover from, such as Kubernetes, Consul, cloud provider APIs, DNS, HTTP endpoints and files, along with the complexity of your label scheme. The number of clusters and clouds matters too, as do the access approvals you need, the amount of existing configuration to migrate and the testing required before production changes. Ask any implementation partner to itemize these drivers in the written scope so you can compare the proposal with your own team's estimate.
Is there a license fee for Prometheus itself?
No. Prometheus is licensed under Apache-2.0 according to its GitHub repository, and there is no paid enterprise edition of the project. Any quote for the work covers services only, and the software itself carries no fee. Confirm with your legal team that each exporter, remote storage system or reverse proxy you add is also reviewed, because those are separate projects with their own licenses. Your budget should therefore show servers, storage, network capacity, implementation services and the staff who operate the monitoring.
Which Prometheus costs are one-time and which recur after go-live?
One-time work covers discovery of your platforms, the label and relabeling design, the initial build, testing and handover documentation. Recurring cost covers the infrastructure and storage that run Prometheus, rule and label changes as services are added or renamed, version upgrades and the people on call for monitoring. Prometheus starts a new minor release cycle every six weeks, and a minor release generally stops receiving bug fixes after those six weeks, while long-term support lines receive fixes for one year. Because upgrades recur, ask for upgrade and support terms to be priced separately from the initial build.
How long does Prometheus service discovery take to implement?
The duration depends on the drivers that shape the work, and no fixed figure applies to every estate. The schedule grows with the number of platforms, clusters and cloud accounts, and with how long access approvals take in your organization. Existing scrape configuration to migrate, an undocumented label scheme and the testing needed before cutover also extend the timeline. Change windows limit how often production can change, so they often set the final date. Ask for a timeline in the written scope that lists these dependencies and the client-side tasks that must finish first.
What does the work need from our team before it starts?
Plan for access, information and decisions. You need read access to each discovery source, including Kubernetes permissions for the relevant namespaces, Consul catalog access, cloud read roles, DNS zones and any HTTP or file sources. You also need an inventory of targets, the teams that own them and a named owner for each label, such as environment, team and service. Your team must approve changes in advance, provide change windows for cutover and review dashboards and alert rules that depend on renamed labels. Confirm the access model and approval steps early, since they often set the pace of the project.
Can our internal team build Prometheus service discovery without outside help?
Yes, an internal team can build it, because Prometheus is open source and its configuration is written in files your engineers can read, test and version. The useful questions are whether your team already knows PromQL, relabeling and the platforms you need to discover from, and whether it has capacity for design review, testing and cutover without pulling people from production work. Outside help is often considered when several platforms, many clusters or strict approval processes must be coordinated at once. Whichever route you choose, add time for security hardening, because Prometheus has no built-in single sign-on and its admin APIs are disabled by default.
What does the engagement cover for Prometheus discovery and hardening?
The scope is agreed in writing before work starts, and it usually includes the discovery design, relabeling rules, configuration for each source, testing, handover documentation and hardening of the Prometheus endpoints. Hardening can include TLS with TLS 1.2 as the minimum, client certificate authentication or basic authentication with bcrypt-hashed passwords, which should only be used over TLS. Single sign-on is normally added with an authenticating reverse proxy in front of the web UI and API. Exporters such as Blackbox and SNMP take targets from URL parameters, so access to them must be restricted. Confirm which of these items are included in your scope.
How do label choices change Prometheus storage and query load?
Every unique combination of metric name and labels creates a separate time series, so labels taken from pod names, container IDs or request paths multiply storage and query cost. Relabeling lets you drop, keep or rewrite labels during discovery and before ingestion, which is where cardinality control starts. Local storage uses two-hour blocks and a write-ahead log, has a default retention of 15 days that you can configure by time or size, and is not clustered or replicated. Test your relabeling against a copy of the target list, check series counts before production, and plan remote write if you need longer retention.
How DeployOpen scopes and delivers Prometheus discovery work
DeployOpen plans Prometheus service discovery for Kubernetes, Consul and cloud accounts as part of a written scope, inside infrastructure you control. The work starts from the targets you must monitor, the labels your teams rely on, and the cardinality your storage can carry, then turns those decisions into tested configuration and a handover your team can run.
How we scope
- We inventory the target sources in scope, such as Kubernetes clusters, Consul catalogs, cloud accounts, DNS and file-based lists.
- We agree the label schema, naming conventions and relabeling rules that every discovered target must follow before any configuration is written.
- Engagements are fixed-scope, and the written scope states which discovery mechanisms, clusters and environments are covered and which are not.
How we build
- We write discovery configuration per source, with relabeling that drops unneeded targets and keeps high-cardinality labels out of series.
- We test discovered target lists against expected inventories in a non-production environment and record the results for your review.
- We check that each Prometheus instance can reach its targets and that discovery credentials follow least privilege in your accounts.
How we hand over
- We deliver versioned configuration, a label and relabeling reference, and runbooks for adding a new cluster, service or cloud account.
- We document how to confirm discovery health, including target counts, failed discovery signals and stale target cleanup steps.
- We walk your operations team through the configuration and the troubleshooting steps, and record what remains open at handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer that covers discovery changes after handover.
- Retainers can cover reviews of new labels and cardinality growth when teams add services or clusters over time.
- We confirm with your team which Prometheus release line you run and plan configuration changes against its support window.
