wildum
commented
1 month ago @tpaschalis
Open thiennn-neji opened 1 month ago
wildum
commented
1 month ago @tpaschalis
tpaschalis
commented
1 month ago Hey there @thiennn-neji 👋
Just for context:
I'd like to understand what you're trying to achieve and what was the expected result.
So if I understand correctly the following file is what is passed to alloy run as the /test.alloy
// Grafana Alloy config (Both revision 9e290c693 and 800739fab)
remotecfg {
url = "http://127.0.0.1:8888"
id = constants.hostname
poll_frequency = "10s"
attributes = {
"template_name" = "test-remotecfg",
}
}And the following is what the remotecfg server returns
prometheus.exporter.self "default" { }Is that correct? Are there any other pieces of configuration to either side (either the 'local' or the 'remote' configuration?).
Could you also please provide
remotecfg directory inside of the storage path (in your example, /tmp/alloy/remotecfg)make generate-ui and run commands from the repo root)tpaschalis
commented
1 month ago Ok, I was able to get a little closer to the root cause.
I have my test remotecfg server return the following configuration, with a root exporter and one wrapped inside of a module.
prometheus.exporter.self "default" { }
prometheus.scrape "default" {
targets = prometheus.exporter.self.default.targets
forward_to = []
}
declare "mymodule" {
prometheus.exporter.self "inner" { }
prometheus.scrape "inner" {
targets = prometheus.exporter.self.inner.targets
forward_to = []
}
}
mymodule "default" { }The curl command fails on the first one, but works on the second one
$ curl http://localhost:12345/api/v0/component/remotecfg/prometheus.exporter.self.default/metrics
failed to parse URL path "/api/v0/component/remotecfg/prometheus.exporter.self.default/metrics": invalid path
$ curl http://localhost:12345/api/v0/component/remotecfg/mymodule.default/prometheus.exporter.self.inner/metrics
# HELP alloy_build_info A metric with a constant '1' value labeled by version, revision, branch, goversion from which alloy was built, and the goos and goarch for the build.
# TYPE alloy_build_info gauge
alloy_build_info{branch="main",goarch="amd64",goos="linux",goversion="go1.22.7",revision="9e1b6e827",tags="unknown",version="v1.5.0-devel+wip"} 1I hadn't come across this as I always wrap my configuration in a module.
Did you have any specific issues to point towards that components aren't working at all, or just that they're not reachable via api/v0 here?
As far as I can tell, the scrape components are scheduled and try to scrape, but the first one fails because of the error you pointed out.
tmarshall98
commented
1 month ago I can confirm this just got released in 1.4.0
prometheus.exporter.unix "default" {}
prometheus.scrape "unix_exporter" {
targets = prometheus.exporter.unix.default.targets
forward_to = [prometheus.remote_write.mimir.receiver]
}
prometheus.remote_write "mimir" {
endpoint {
url = "https://<mimir_url>/api/v1/push"
headers = {
"X-Scope-OrgID" = "tenant",
}
}
}Wrapping this in a module makes it work
Did you have any specific issues to point towards that components aren't working at all, or just that they're not reachable via api/v0 here?
I believe its the latter, I see logs of the components starting, and they are visible in the UI - just the failed to parse URL path at scrape time seems to be the problem
github-actions[bot]
commented
1 week ago This issue has not had any activity in the past 30 days, so the needs-attention label has been added to it.
If the opened issue is a bug, check to see if a newer release fixed your issue. If it is no longer relevant, please feel free to close this issue.
The needs-attention label signals to maintainers that something has fallen through the cracks. No action is needed by you; your issue will be kept open and you do not have to respond to this comment. The label will be removed the next time this job runs if there is new activity.
Thank you for your contributions!
What's wrong?
The Grafana Alloy remotecfg feature was fixed in pull request #1372, and I tested it with Grafana Alloy Revision 800739fab, where it worked smoothly. However, starting from pull request #1501, it seems to no longer work.
It appears that the
componentIDfor remotecfg components is in the formatremotecfg/example.component.labelrather than justexample.component.label. However, in line 183 of pull request #1501 (see here), it assumes that thecomponentIDin formatexample.component.labelIn my opinion, the
s.componentHandlershould references.componentHttpPathPrefixRemotecfginstead ofs.componentHttpPathPrefixSteps to reproduce
Step 0: An
alloy-remote-config-serveris serving gRPC at127.0.0.1:8888with the following template (also specfied in Configuration section):Step 1: Use two Docker images for two Grafana Alloy revisions: (Revision 9e290c693, v1.4.0-rc.0) and (Revision 800739fab). Run the same configuration:
with the command line options:
Step 2: In each Grafana Alloy instance, use cURL to fetch metrics
Step 3: Check the output of cURL command and Grafana Alloy logs
remotecfgcomponent works as expected.Alloy log
cURL log
remotecfgcomponent does not work.Alloy log
cURL log
System information
Linux 6.10.6 x86_64 (Ubuntu 24.04.1 LTS)
Software version
Grafana Alloy (Revision 9e290c693, v1.4.0-rc.0) and Grafana Alloy (Revision 800739fab)
Configuration
Logs
No response