Grafana Alloy – Part 2 – Replacing Prometheus Node Exporter

As discussed in the First Article of this series, Grafana Alloy was introduced to the official repositories starting with SLES 15 SP7. With the release of SLES 16, this transition is now complete. Alloy has fully replaced all legacy collectors.

This article will describe the key considerations for migrating from Prometheus Node Exporter to Alloy and outlines the process of forwarding the metrics to a Prometheus server.

From Prometheus Node Exporter to Alloy – How to migrate

Unlike the Migration from Promtail to Alloy  there is no built-in conversion command for the Node Exporter. This is because the Node Exporter does not really utilize a configuration file. Because of this Prometheus Node Exporter was very straightforward to use. For most use cases, the standard approach was simply to install it and let it run. Grafana Alloy requires a configuration file so that users can take advantage of its flexibility. This allows you to process your data and choose exactly which backends to push it to – we come to that later in more detail.

As already mentioned, Grafana Alloy is shipped starting with SLES 15 SP7. This means it can be installed directly from the SUSE repositories:

# zypper in alloy

The configuration file can be found under:

/etc/alloy/config.alloy

Comparing Old Workflows with Modern Standards

Prometheus Node Exporter was pulled based. This has introduced several drawbacks:

1. Firewall Configuration: Since the Prometheus Server had to pull the data from the client, every monitored client required specific firewall ports to be opened to allow external access.

2. Manual Server Configuration: The Prometheus Server configuration needs a manual entry (target) for every single client system you intended to monitor.

With Alloy this has been changed. The agent can now push its collected metrics directly to the Prometheus Server or any other backend. There is also no need to add each monitoring client to the backend configuration (like on prometheus server under /etc/prometheus/prometheus.yml).

The Alloy configuration

While the original Node Exporter required no configuration file at all, Grafana Alloy does utilize a small configuration. This might seem like an extra step, but it actually provides far more flexibility. Because this configuration can be a standardized file it makes it perfect for deploying with tools like Ansible across your entire infrastructure.

Like mentioned in my Last Blogpost, Grafana Alloy follows the  dataflow model where data can be captured, filtered and manipulated and finally pushed to the target.

Source → Collector → Processor → Writer

This design enables pushing metrics to a wide array of different backends, tailored to your observability strategy.

The following example configuration highlights these main sections (Source → Collector → Processor → Writer), introduced by the following corresponding comments.

Let’s take a look at each of the sections:

Source

// Source (1)
prometheus.exporter.unix "localhost" { 
}

Collector

// Collector (2)
prometheus.scrape "unix" {
    scrape_interval = "10s"
    targets    = prometheus.exporter.unix.localhost.targets
    forward_to = [ prometheus.relabel.to_be_compatible.receiver, ]
}

Processor

// Processor (3)
prometheus.relabel "to_be_compatible" {
    forward_to = [ prometheus.remote_write.to_prom.receiver, ]

    rule {
        source_labels  = ["exporter"]
        target_label   = "exporter"
        replacement    = "alloy"
    }
    rule {
        source_labels  = ["job"]
        target_label   = "job"
        replacement    = sys.env("monitoring_group")
    }
}

Writer

// Output/Writer (4)
prometheus.remote_write "to_prom" {
    endpoint { url = "http://prometheus.server:9090/api/v1/write" }
}

The Complete config for Alloy

// Source (1)
prometheus.exporter.unix "localhost" { 
}

// Collector (2)
prometheus.scrape "unix" {
    scrape_interval = "10s"
    targets    = prometheus.exporter.unix.localhost.targets
    forward_to = [ prometheus.relabel.to_be_compatible.receiver, ]
}

// Processor (3)
prometheus.relabel "to_be_compatible" {
    forward_to = [ prometheus.remote_write.to_prom.receiver, ]

    rule {
        source_labels  = ["exporter"]
        target_label   = "exporter"
        replacement    = "alloy"
    }
    rule {
        source_labels  = ["job"]
        target_label   = "job"
        replacement    = sys.env("monitoring_group")
    }
}

// Output/Writer (4)
prometheus.remote_write "to_prom" {
    endpoint { url = "http://prometheus.server:9090/api/v1/write" }
}

Conclusion

Using a single tool for both logs and system metrics makes life much easier for administrators. Instead of managing multiple agents, you only have one tool to maintain on your clients. While the configuration style is new, the logic is consistent and easy to follow once you understand the basics. The real strength of Grafana Alloy is its flexibility by allowing you to manipulate data locally before it is pushed to a backend. It also allows you to keep your current Prometheus server but still work with a modern, high-performance standard. If you decide to change your backend later, you can do it easily without any hassle. Whether you are working with old servers or building something completely new, Grafana Alloy is a great tool for the job.