# 6. Service Discovery # Introduction In this article, we explore how Prometheus leverages service discovery to streamline monitoring in dynamic environments. Understanding service discovery is essential for managing ever-changing infrastructures where servers and services frequently scale up or down. Imagine you have a Prometheus configuration file that defines a static list of targets for scraping metrics. Initially, your configuration might look like this: ```plaintext scrape_configs: - job_name: "web" static_configs: - targets: ["localhost:9090"] - job_name: "node" static_configs: - targets: ["192.168.1.168:9100"] - job_name: "docker" static_configs: - targets: ["localhost:9323"] ``` Over time, as new servers join your infrastructure, you must update the Prometheus configuration with additional scrape targets. For example, when adding a new database server, the configuration is updated as follows: ```plaintext scrape_configs: - job_name: "web" static_configs: - targets: ["localhost:9090"] - job_name: "node" static_configs: - targets: ["192.168.1.168:9100"] - job_name: "docker" static_configs: - targets: ["localhost:9323"] - job_name: "database" static_configs: - targets: ["localhost:9090"] ``` Similarly, if you decide to decommission your web server or change its port, you would need to manually remove or update its configuration. For example, updating the web server target's port might result in: ```plaintext scrape_configs: - job_name: "web" static_configs: - targets: ["localhost:9008"] - job_name: "node" static_configs: - targets: ["192.168.1.168:9100"] - job_name: "docker" static_configs: - targets: ["localhost:9323"] - job_name: "database" static_configs: - targets: ["localhost:9090"] ``` **Note** In fast-growing and dynamic environments, managing these manual configuration changes can be both tedious and error-prone. This is where service discovery in Prometheus becomes invaluable. By automatically populating a list of scrape endpoints, service discovery dynamically updates monitoring targets as new instances emerge or get decommissioned, eliminating the need for constant manual adjustments. ![The image contains a text explanation about service discovery, stating that it allows Prometheus to dynamically update a list of endpoints to scrape as new endpoints are created and destroyed.](https://kodekloud.com/kk-media/image/upload/v1752883097/notes-assets/images/Prometheus-Certified-Associate-PCA-Introduction/service-discovery-prometheus-endpoints.jpg align="left") Prometheus supports several built-in service discovery mechanisms to accommodate various environments. It integrates with popular cloud providers such as [**Amazon Elastic Compute Cloud (EC2)**](https://learn.kodekloud.com/user/courses/amazon-elastic-compute-cloud-ec2) and [**Microsoft Azure Fundamentals (AZ900)**](https://learn.kodekloud.com/user/courses/az900-microsoft-azure-fundamentals). In addition, Prometheus offers compatibility with other major cloud platforms and tools like Consul, Nomad, and Kubernetes—the latter being renowned for its dynamic orchestration. ![The image shows a slide about Prometheus having built-in support for several service discovery mechanisms, including EC2, Azure, GCE, Consul, Nomad, and Kubernetes.](https://kodekloud.com/kk-media/image/upload/v1752883098/notes-assets/images/Prometheus-Certified-Associate-PCA-Introduction/prometheus-service-discovery-slide.jpg align="left") Even the static configuration method discussed earlier is technically a basic form of service discovery, as it explicitly defines which HTTP endpoints Prometheus should monitor. In the sections that follow, we will delve deeper into the various service discovery methods supported by Prometheus and demonstrate how they simplify the management of dynamic and scalable environments. # File In this lesson, we'll explore file service discovery—a straightforward yet flexible mechanism to import jobs and target configurations into Prometheus from an external file. Although this method is less dynamic compared to other alternatives, it proves especially useful when integrating with service discovery systems that Prometheus does not directly support. File service discovery supports both JSON and YAML file formats, allowing you to manage configurations in multiple files. This approach provides the flexibility to use any file containing valid configuration data, and you can even leverage glob patterns (e.g., `*.json`) to include multiple files at once. **Tip** When using glob patterns, ensure the pattern correctly matches all intended files to avoid missing any configurations. ## Configuring File Service Discovery in Prometheus To enable file service discovery, add a `file_sd_configs` block to your Prometheus configuration file (typically named `prometheus.yaml`). Within this block, specify the file or files holding your configuration details. For example, you can list files individually or use a glob pattern to import all JSON files. ### Example JSON Configuration Below is an example configuration file in JSON format defining three job setups: ```plaintext [ { "targets": ["node1:9100", "node2:9100"], "labels": { "team": "dev", "job": "node" } }, { "targets": ["localhost:9090"], "labels": { "team": "monitoring", "job": "prometheus" } }, { "targets": ["db1:9090"], "labels": { "team": "db", "job": "database" } } ] ``` ### Example Prometheus YAML Configuration Here is how you can reference the JSON configuration in your Prometheus YAML file: ```plaintext scrape_configs: - job_name: file-example file_sd_configs: - files: - 'file-sd.json' - '*.json' ``` In this setup, Prometheus imports labels and targets defined in the JSON file. For instance: * A job with the label `job: node` targets specific nodes. * Another job is dedicated to Prometheus monitoring. * A third job is defined for database monitoring. After configuring file service discovery in your `prometheus.yaml`, restart Prometheus. On restart, you should see all endpoints appear as if they were defined directly in the configuration file. **Restart Prometheus** Remember to restart Prometheus after updating the configuration to ensure that all new targets are properly detected. ## Viewing Discovered Targets Once Prometheus restarts, navigate to the **Status** section and then to **Service Discovery** in the Prometheus dashboard. Here, you can review detailed information about how Prometheus has discovered the endpoints. The interface displays both the original target labels and any additional labels from your file configuration which are used to annotate the scraped metrics. The following figures illustrate key aspects of file service discovery: ![The image explains file service discovery, highlighting that jobs/targets can be imported from files, supporting JSON and YAML formats, and mentions Prometheus integration. It includes an icon of a document and a flame symbol connected by a dashed arrow.](https://kodekloud.com/kk-media/image/upload/v1752883095/notes-assets/images/Prometheus-Certified-Associate-PCA-File/file-service-discovery-json-yaml.jpg align="left") ![The image shows a "File Service Discovery" interface with a table listing discovered and target labels for file examples. It includes a search bar for filtering by labels.](https://kodekloud.com/kk-media/image/upload/v1752883096/notes-assets/images/Prometheus-Certified-Associate-PCA-File/file-service-discovery-interface.jpg align="left") ## Summary File service discovery offers a simple and flexible way to integrate external configuration data into Prometheus. By using external files (JSON or YAML) and incorporating glob patterns, you can easily manage a dynamic set of targets without modifying the Prometheus configuration directly. For additional details, consider reviewing the [**Prometheus Documentation**](https://prometheus.io/docs/). This approach is particularly helpful when working with service discovery systems that are not natively supported by Prometheus, providing a seamless bridge that enhances your monitoring capabilities. # AWS Cloud infrastructure is inherently dynamic—especially with auto-scaling enabled. Resources are continuously deployed and terminated, making real-time EC2 service discovery essential for Prometheus to maintain an updated list of instances to scrape. In this guide, you'll configure EC2 service discovery by setting up the EC2 SD configuration block within Prometheus. This setup requires three pieces of information: * The AWS region of interest * The access key * The secret key These credentials must belong to an IAM user with Amazon EC2 read-only access. **Important** Ensure that the IAM user you create has only the necessary read-only permissions to enhance security. Below is an example configuration snippet for Prometheus: ```plaintext scrape_configs: - job_name: EC2 ec2_sd_configs: - region: access_key: secret_key: ``` Once configured, Prometheus begins collecting extensive metadata from your EC2 instances. You can view many discovered labels—such as tags, instance types, VPC IDs, and private IPs. By default, Prometheus uses the private IP as the instance label because it is typically deployed close to its targets within the same cloud environment. If needed, you can also access the public IP via metadata labels, which is useful when some EC2 instances lack a public IP address. ![The image shows an EC2 Service Discovery interface with a list of discovered labels and target labels for an EC2 instance. It includes details like instance ID, state, type, and various metadata.](https://kodekloud.com/kk-media/image/upload/v1752883088/notes-assets/images/Prometheus-Certified-Associate-PCA-AWS/ec2-service-discovery-interface.jpg align="left") ## Configuring AWS Access for Prometheus To enable Prometheus to access AWS EC2 metadata, you need to create an IAM user specifically for this purpose. Follow these steps in the AWS Management Console: 1. Navigate to the IAM section. 2. Create a new user named "Prometheus". This account is exclusively for programmatic access and will not use the AWS Console. 3. Enable programmatic access by generating an access key. 4. Attach the "Amazon EC2 read-only access" policy to the user. ![The image shows an AWS Management Console screen for adding a new user, where you can set user details and select the AWS access type. Options include programmatic access via access keys and console access via a password.](https://kodekloud.com/kk-media/image/upload/v1752883089/notes-assets/images/Prometheus-Certified-Associate-PCA-AWS/aws-management-console-add-user.jpg align="left") After attaching the required permissions, review the configuration and create the user. Once the new user is created, be sure to note the displayed access key and secret key, as these credentials are required in your Prometheus configuration. ![The image shows an AWS IAM interface for setting permissions while adding a user, with a list of EC2-related policies displayed.](https://kodekloud.com/kk-media/image/upload/v1752883091/notes-assets/images/Prometheus-Certified-Associate-PCA-AWS/aws-iam-user-permissions-ec2-policies.jpg align="left") ![The image shows an AWS Management Console screen where a new user named "prometheus" has been successfully created, displaying their access key ID and secret access key.](https://kodekloud.com/kk-media/image/upload/v1752883092/notes-assets/images/Prometheus-Certified-Associate-PCA-AWS/aws-management-console-new-user-prometheus.jpg align="left") ## Updating Prometheus Configuration Edit your Prometheus configuration file, typically located at `/etc/prometheus/prometheus.yaml`, to add a new job definition for EC2 service discovery. Below is an example configuration integrating the EC2 SD setup with other scrape configurations: ```plaintext # Global configurations global: scrape_interval: 15s # Scrape every 15 seconds (default is 1 minute). evaluation_interval: 15s # Evaluate rules every 15 seconds (default is 1 minute). # Alertmanager configuration alerting: alertmanagers: - static_configs: - targets: - alertmanager:9093 # Rule files configuration (load rules periodically) rule_files: # - "first_rules.yml" # - "second_rules.yml" # Scrape configurations scrape_configs: # Scrape configuration for Prometheus itself - job_name: "prometheus" static_configs: - targets: ['localhost:9090'] # Scrape configuration for Node Exporter - job_name: "node" static_configs: - targets: ['192.168.1.168:9100'] # Scrape configuration for EC2 instances - job_name: "ec2" ec2_sd_configs: - region: "us-east-1" # Replace with your desired region access_key: "" # Replace with your actual access key secret_key: "" # Replace with your actual secret key ``` After saving the configuration file, restart Prometheus to apply these changes: ```plaintext sudo systemctl restart prometheus ``` Once Prometheus restarts, navigate to the **Status > Service Discovery** section within the Prometheus interface. You should see discovered targets under the EC2 job, along with associated labels such as the AMI, architecture, owner ID, instance type, and private IP. ![The image shows a Prometheus monitoring interface displaying discovered and target labels for two EC2 instances, including details like IP addresses, instance types, and availability zones.](https://kodekloud.com/kk-media/image/upload/v1752883093/notes-assets/images/Prometheus-Certified-Associate-PCA-AWS/prometheus-monitoring-ec2-instances.jpg align="left") Keep in mind that if the Prometheus server cannot reach the EC2 instances, they may be marked as "down." Once proper network connectivity is confirmed, the targets should display as "up." Additionally, as new EC2 instances are launched or terminated, Prometheus will automatically update the service discovery, ensuring only active servers are monitored. ![The image shows a Prometheus monitoring dashboard displaying the status of various targets. Two EC2 instances are down, while a node and Prometheus instance are up.](https://kodekloud.com/kk-media/image/upload/v1752883094/notes-assets/images/Prometheus-Certified-Associate-PCA-AWS/prometheus-monitoring-dashboard-ec2-status.jpg align="left") This completes the setup for AWS EC2 service discovery in Prometheus. With this configuration, your Prometheus instance will consistently monitor current EC2 instances, ensuring accurate and dynamic target discovery. # Re Labeling In this lesson, we explore the relabeling feature in Prometheus, which enables you to classify and filter targets and metrics by rewriting their label sets. Relabeling is especially useful when you have service discovery that identifies multiple targets, but you only want to scrape those in a specific environment (e.g., production). With relabeling, you can filter out unwanted targets, rename or drop labels, and even modify label values before or after scraping. **Overview** Relabeling in Prometheus operates in two distinct phases: * **Pre-scrape (relabel\_configs):** Processes labels provided by service discovery. * **Post-scrape (metric\_relabel\_configs):** Processes all collected metric labels. ![The image illustrates the concept of re-labeling in Prometheus, showing how targets and metrics can be classified or filtered by rewriting their label set, with a flow diagram including servers and a recycling bin icon.](https://kodekloud.com/kk-media/image/upload/v1752883102/notes-assets/images/Prometheus-Certified-Associate-PCA-Re-Labeling/prometheus-relabeling-flow-diagram.jpg align="left") ## Key Relabeling Options There are two primary options for relabeling in Prometheus: 1. **relabel\_configs:** * Specified under `scrape_configs` and executed **before** a scrape. * Has access only to the labels provided by service discovery. 2. **metric\_relabel\_configs:** * Executes **after** a scrape. * Has access to all collected metrics and labels. ### Example Configuration for EC2 Service Discovery Below is an example configuration using [**Amazon Elastic Compute Cloud (EC2)**](https://learn.kodekloud.com/user/courses/amazon-elastic-compute-cloud-ec2) service discovery. Notice that both relabeling options are included: ```plaintext scrape_configs: - job_name: EC2 relabel_configs: # Executes before scraping; only service discovery labels are available. metric_relabel_configs: # Executes after scraping; all metric labels are available. ec2_sd_configs: - region: access_key: secret_key: ``` ## Filtering Targets Based on Labels Consider a scenario where EC2 service discovery finds two targets. AWS provides considerable metadata through labels, for example: ```plaintext __meta_ec2_tag_env=dev | prod ``` You can use this meta label to decide which targets to scrape. For instance, if you only want to scrape targets with `__meta_ec2_tag_env` set to "prod", define a rule to keep only matching targets. Non-matching targets are dropped implicitly. ### Keeping Targets for Production ```plaintext scrape_configs: - job_name: example relabel_configs: - source_labels: [__meta_ec2_tag_env] regex: prod action: keep ``` In this configuration, any target that does not have `__meta_ec2_tag_env` set to "prod" will be dropped. ### Dropping Targets for Development Alternatively, if you want to drop targets where `__meta_ec2_tag_env` is "dev", the configuration would be: ```plaintext scrape_configs: - job_name: example relabel_configs: - source_labels: [__meta_ec2_tag_env] regex: dev action: drop ``` ## Combining Multiple Labels When you need to filter based on more than one label, specify multiple source labels. By default, Prometheus joins these values with a semicolon. For example, to keep targets where "env" equals "dev" and "team" equals "marketing": ```plaintext scrape_configs: - job_name: example relabel_configs: - source_labels: [env, team] regex: dev;marketing action: keep ``` If you require a different separator (e.g., a dash), use the `separator` property: ```plaintext scrape_configs: - job_name: example relabel_configs: - source_labels: [env, team] regex: dev-marketing action: keep separator: "-" ``` ## Managing Target Labels Target labels are added to every time series returned from a scrape. During relabeling, discovered labels (typically starting with `__`) are dropped unless explicitly preserved. For example, if your EC2 instances return metadata that includes the IP address and port, you may want to create a target label that extracts just the IP address. ### Extracting the IP Address ```plaintext scrape_configs: - job_name: example relabel_configs: - source_labels: [__address__] regex: (.*):.* target_label: ip action: replace replacement: $1 ``` This rule uses a regular expression to capture the IP address from the `__address__` label, assigning it to the new "ip" label. ## Dropping and Keeping Labels You can also drop labels using `labeldrop` or restrict to a subset of labels using `labelkeep`. ### Dropping a Specific Label To drop the label `__meta_ec2_owner_id`: ```plaintext scrape_configs: - job_name: example relabel_configs: - regex: __meta_ec2_owner_id action: labeldrop ``` ### Keeping Only Specific Labels To keep only the labels named "instance" or "job": ```plaintext scrape_configs: - job_name: example relabel_configs: - regex: instance|job action: labelkeep ``` Below is an example of labels you might observe from a scrape (labels starting with two underscores are removed after relabeling): ```plaintext address="172.31.11.156:80" meta_ec2_ami="ami-026b7f3c838c2eec" meta_ec2_architecture="x86_64" meta_ec2_availability_zone="us-east-1b" meta_ec2_availability_zone_id="e0a2391e6c198db" meta_ec2_instance_state="running" meta_ec2_instance_type="t2.micro" meta_ec2_owner_id="404497317140" meta_ec2_primary_subnet_id="subnet-0fdeb557c6c80641" meta_ec2_private_dns_name="ip-172-31-11-156.ec2.internal" meta_ec2_private_ip="172.31.11.156" meta_ec2_public_dns_name="ec2-3-80-117-102.compute-1.amazonaws.com" meta_ec2_public_ip="3.80.117.102" meta_ec2_region="us-east-1" meta_ec2_subnet_id="subnet-0fdc973dfc680614" meta_ec2_Name="web" meta_ec2_tag_env="dev" meta_ec2_id="i-9c1e294f5535" metrics_path="/metrics" scheme="http" scrape_interval="15s" scrape_timeout="10s" job="ec2" ``` ### Mapping Discovery Labels To preserve and convert labels that begin with `__meta_ec2_`, use the `labelmap` action. This action modifies the label names rather than their values. For example: ```plaintext scrape_configs: - job_name: example relabel_configs: - regex: __meta_ec2_(.*) action: labelmap replacement: ec2_$1 ``` This rule converts a discovered label such as `__meta_ec2_AMI` into a target label `ec2_AMI` with the same value. ## Metric Relabeling After scraping, metric relabeling via `metric_relabel_configs` allows you to modify metrics directly. The structure is similar to `relabel_configs`, but you have access to all metric labels. ### Dropping a Metric To drop a metric named `http_errors_total` (stored in the `__name__` label): ```plaintext scrape_configs: - job_name: example metric_relabel_configs: - source_labels: [__name__] regex: http_errors_total action: drop ``` ### Renaming a Metric To rename a metric from `http_errors_total` to `http_failures_total`: ```plaintext scrape_configs: - job_name: example metric_relabel_configs: - source_labels: [__name__] regex: http_errors_total action: replace target_label: __name__ replacement: http_failures_total ``` ### Dropping a Metric Label To drop a metric label named "code": ```plaintext scrape_configs: - job_name: example metric_relabel_configs: - regex: code action: labeldrop ``` ### Modifying Metric Labels Suppose you have a metric label "path" with values like "/cars" and you want to create a new label "endpoint" that contains just "cars". You can strip off the forward slash as follows: ```plaintext scrape_configs: - job_name: example metric_relabel_configs: - source_labels: [path] regex: \/(.*) action: replace target_label: endpoint replacement: $1 ``` This rule uses a regular expression to remove the leading forward slash from the "path" label and stores the result in the "endpoint" label. ## Conclusion This lesson provided a comprehensive overview of both `relabel_configs` and `metric_relabel_configs`. By understanding these relabeling techniques, you can effectively filter, rename, drop, and map metrics and labels within Prometheus, ensuring that only the relevant data is scraped and stored. # Re Labeling Demo In this lesson, we dive into Prometheus relabeling configurations, demonstrating how to manipulate discovered labels before target scraping and adjust scraped metrics afterward. You'll learn how to filter targets by labels, combine label values, drop unwanted labels, and even rename metrics. This guide provides a step-by-step explanation to help you tailor your monitoring configurations effectively. --- ## Filtering Targets with relabel\_configs When Prometheus performs service discovery for a job, it gathers targets along with a variety of discovered labels (e.g., environment, team, size, type). For instance, targets might include an environment label such as dev, staging, or prod, and a team label that identifies ownership (like "web" or "database"). You can configure Prometheus to include or exclude targets using relabeling rules before scraping. In the following example, we configure Prometheus to scrape only the targets where the environment is set to production. The configuration below uses file-based service discovery for simplicity. ```plaintext global: scrape_interval: 15s scrape_timeout: 10s scrape_configs: - job_name: "prometheus" static_configs: - targets: ["localhost:9090"] - job_name: "nodes" relabel_configs: - source_labels: [env] regex: prod action: keep file_sd_configs: - files: - file-sd.json ``` In this configuration: * The rule examines the `env` label. * The regular expression `prod` selects targets labeled with production. * The `keep` action ensures that only matching targets are scraped, while all others are dropped. **Note** To drop production targets instead, simply change the action from `keep` to `drop`: ```plaintext scrape_configs: - job_name: "prometheus" static_configs: - targets: ["localhost:9090"] - job_name: "nodes" relabel_configs: - source_labels: [env] regex: prod action: drop file_sd_configs: - files: - file-sd.json ``` After saving and restarting Prometheus, verify the filtered targets in the service discovery section of the web UI. ![The image shows a Prometheus Service Discovery page in a web browser, displaying discovered and target labels for various nodes. The interface includes details such as addresses, metrics paths, and environment settings.](https://kodekloud.com/kk-media/image/upload/v1752883099/notes-assets/images/Prometheus-Certified-Associate-PCA-Re-Labeling-Demo/prometheus-service-discovery-page.jpg align="left") --- ## Combining Labels with Replacement Another powerful operation is combining two or more labels into a new one. For example, you can merge the `team` and `env` labels into a new target label called `info`. This new label might have values such as `database-prod` or `web-dev`. Below is an example rule that demonstrates this operation: ```plaintext scrape_configs: - job_name: "prometheus" static_configs: - targets: ["localhost:9090"] - job_name: "nodes" relabel_configs: - source_labels: [team, env] regex: (.*);(.*) action: replace target_label: info replacement: $1-$2 file_sd_configs: - files: - file-sd.json ``` Key points of this configuration: * Two source labels (`team` and `env`) are combined. * The regular expression `(.*);(.*)` extracts their values, using the semicolon as an internal separator. * The `replace` action creates the new `info` label formatted as “team-environment” using `$1-$2`. --- ## Dropping Unwanted Labels Sometimes it is beneficial to eliminate extraneous labels that do not contribute any useful information. For example, if the `size` label is unnecessary, you can remove it using the `labeldrop` action: ```plaintext scrape_configs: - job_name: "prometheus" static_configs: - targets: ["localhost:9090"] - job_name: "nodes" relabel_configs: - regex: size action: labeldrop file_sd_configs: - files: - file-sd.json ``` In this configuration, any discovered label matching `size` is dropped while preserving all other labels. --- ## Renaming Metrics with metric\_relabel\_configs Metric relabeling takes place after scraping, allowing you to modify the metrics themselves. For example, suppose you want to rename the metric `node_cpu_seconds_total` to `host_cpu_seconds_total`. Use the following configuration: ```plaintext scrape_configs: - job_name: "prometheus" static_configs: - targets: ["localhost:9090"] - job_name: "nodes" metric_relabel_configs: - source_labels: [__name__] regex: node_cpu_seconds_total action: replace replacement: host_cpu_seconds_total target_label: __name__ file_sd_configs: - files: - file-sd.json ``` Highlights of the configuration: * The special label `__name__`, representing the metric name, is used. * If it matches `node_cpu_seconds_total`, the metric name is replaced with `host_cpu_seconds_total`. After applying this change and restarting Prometheus, use the query interface to verify that the new metric name is available. --- ## Keeping or Dropping Specific Metrics There may be instances where you want to focus on a specific metric and filter out the rest. For example, to keep only the metric `node_arp_entries`, add the following rule under the metric relabeling section: ```plaintext scrape_configs: - job_name: "prometheus" static_configs: - targets: ["localhost:9090"] - job_name: "nodes" metric_relabel_configs: - source_labels: [__name__] regex: node_arp_entries action: keep file_sd_configs: - files: - file-sd.json ``` This rule ensures that only `node_arp_entries` is retained while all other metrics are dropped from that particular target. --- ## Renaming a Label Within a Metric You can also modify labels attached to a metric. For instance, if you want to rename the `mountpoint` label to `path`, the following metric relabel configuration can be used: ```plaintext scrape_configs: - job_name: "prometheus" static_configs: - targets: ["localhost:9090"] - job_name: "nodes" metric_relabel_configs: - source_labels: [mountpoint] regex: (.*) action: replace target_label: path replacement: $1 file_sd_configs: - files: - file-sd.json ``` Main points to note: * The rule captures the original `mountpoint` label value. * The regex `(.*)` grabs the entire value. * The new `path` label is created with the same value. * The original `mountpoint` label remains unless you add an additional rule to remove it. Once applied, the Prometheus interface will display the new `path` label while the `mountpoint` remains visible if not dropped. ![The image shows a Prometheus web interface displaying query results for `node_filesystem_avail_bytes`, listing various filesystem metrics in a table format. The interface includes options for enabling query history, autocomplete, highlighting, and linter.](https://kodekloud.com/kk-media/image/upload/v1752883100/notes-assets/images/Prometheus-Certified-Associate-PCA-Re-Labeling-Demo/prometheus-query-results-filesystem-metrics.jpg align="left") --- ## Final Notes This lesson demonstrated how to: * Filter targets before scraping using the `keep` or `drop` actions. * Combine multiple labels into a new composite label with the `replace` action. * Remove unnecessary labels using `labeldrop`. * Rename metrics and adjust labels post-scraping with metric relabeling. **Helpful Tips** Understanding and utilizing relabeling configurations enhances your metric management in Prometheus, enabling you to optimize which data gets scraped and stored. For more details on Prometheus configurations, review the [**Prometheus Documentation**](https://prometheus.io/docs/introduction/overview/).