Local.file for prometheus metrics with Grafana Alloy

Grafana Configuration
1

Hello

Disclaimer: I am very new to Grafana Alloy (started looking at this today)

  • What Grafana version and what operating system are you using?

Grafana Alloy 1.0.0 on Ubuntu 22.04

  • What are you trying to achieve?

I am experimenting to see if it is possible to use the content of a file to then present to prometheus.scrape and forward to a prometheus remote write target. It looks like this is not possible, but I’m really checking here amongst experts to see if it is or is not for sure.

I am doing this because I’m trying to collect metrics from a textfile. The exporter I’m using is pkg-exporter and is meant to be consumed using node-exporter’s --collector.textfile.directory option. The reason for this is that we are not currently using node-exporter and wish to avoid installing/configuring if we can.

  • How are you trying to achieve it?

Using a local.file block to point to the file and using this as a target with prometheus.scrape

  • What happened?

The error received is:

Error: /etc/alloy/config.alloy:13:21: expected =, got .

interrupt received

I’m guessing this is because Alloy is expecting to parse a simple key/value pair and is getting a prometheus metrics textfile instead

  • What did you expect to happen?

To be able to read the file in and parse as prometheus output to be sent on to the rest of our prometheus config

  • Can you copy/paste the configuration(s) that you are having problems with?
local.file "pkgexporter" {
  filename = "/var/prometheus/pkg-exporter.prom"
}

prometheus.scrape "pkgexporter" {
  targets = [ {local.file.pkgexporter.content} ]
  forward_to = [prometheus.remote_write.main.receiver]
}
  • Did you receive any errors in the Grafana UI or in related logs? If so, please tell us exactly what they were.
Error: /etc/alloy/config.alloy:13:21: expected =, got .

interrupt received
  • Did you follow any online instructions? If so, what is the URL?

No, I couldn’t find any instructions online, which suggests that this is not actually possible. I did want to check here, however.

2

I am receiving the same error but when scraping an https endpoint:

prometheus.scrape "servicebus_monitor" {

targets=[{"__address" = "test.com:443"}]

}

This seems to be equivalent to the few examples I’ve seen referencing prometheus scrapes where the target is not a discover target - but I cannot find examples that work adn so far have not worked out the syntex itself.

3

@ticktockhouse I figured out my issues - but not with documentation however, or messages retrieved when reloading the API, or from the default alloy web-page, since that would not load due to configuration issues.

I resolved by issues in two steps, both using the alloy command-line:
My environment is windows x64, so my alloy executable is actually alloy-windows-amd65.exe, I will just refer to it as alloy in the steps below:

  1. Stop Alloy Service
  2. Copy contents of Alloy directory to an unprotected directory (Windows would not allow the commandline version of alloy to create the directory: data-alloy on startup from the Programs\GrafanaLabs\Alloy directory
  3. Change directory to Temp\Alloy
  4. run command alloy fmt config.alloy
    This command formats the file per standards formatting - but also provided some basic error messages which helped me correctly construct the targets setting for prometheus.scrape

Once “fmt” produced no errors:
5. run command alloy run config.alloy
I still had errors.
In my case it turned out the ‘expected “,”’ message related to an undocumented required portion of the targets line:

targets = [{"__address" = "topicmon.com:443","instance" = "p-servicebus-01"}]

It appears the instance name is also required even though documentation does not include one.

The forward_to line is also required for a basic prometheus.scrape config, which was clearly identified in the error message from the alloy run command.

In short - the key to resolving my issues was using the more detailed error messaging available with the command-line tools.

4

Did you ever figure out the problem you were having with the local.file block?