so adding bearer auth is just adapting the basic auth block? but the bearer auth is shared across all apps, like the basic auth. i mean, it's generated by this recipe.
looks great, thanks! i'll test it this week :D
so adding bearer auth is just adapting the basic auth block? but the bearer auth is shared across all apps, like the basic auth. i mean, it's generated by this recipe.
so adding bearer auth is just adapting the basic auth block? but the bearer auth is shared across all apps, like the basic auth. i mean, it's generated by this recipe.
Yes, one basic auth secret and one bearer secret that is used for every metric that requires it. But of course, we could extend this if needed. We could add a label like prometheus.io/authsecret=default to specify using another secret.
> looks great, thanks! i'll test it this week :D
>
> so adding bearer auth is just adapting the basic auth block? but the bearer auth is shared across all apps, like the basic auth. i mean, it's generated by this recipe.
Yes, one basic auth secret and one bearer secret that is used for every metric that requires it. But of course, we could extend this if needed. We could add a label like `prometheus.io/authsecret=default` to specify using another secret.
@dannygroenewegen please check coop-cloud/garage#19 in combination with bearer auth.
where would i find indication that the labels are getting discovered?
i noticed no coopcloud container is on the docker_gwbridge network, so i added alloy to the proxy and changed the network filter on config.alloy.tmpl. this way i could curl metrics from garage on the alloy container, but i still don't see them appearing on grafana (other metrics such as alloy_build_info are appearing, so sending metrics works)
@dannygroenewegen please check https://git.coopcloud.tech/coop-cloud/garage/pulls/19 in combination with bearer auth.
where would i find indication that the labels are getting discovered?
i noticed no coopcloud container is on the `docker_gwbridge` network, so i added alloy to the `proxy` and changed the network filter on `config.alloy.tmpl`. this way i could `curl` metrics from garage on the alloy container, but i still don't see them appearing on grafana (other metrics such as `alloy_build_info` are appearing, so sending metrics works)
got it to work by scraping and relabeling from dockerswarm! the only issue is that swarm doesn't expose the domain names, so jobs are labeled by service names (instance="git.sutty.abyaya.la" to job="git_sutty_abyaya_la_app" on the screenshot)
<img width="278" alt="image.png" src="attachments/a1d6cfc8-6b8c-4dd6-9c97-3b3e5d61858f">
got it to work by scraping and relabeling from dockerswarm! the only issue is that swarm doesn't expose the domain names, so jobs are labeled by service names (`instance="git.sutty.abyaya.la"` to `job="git_sutty_abyaya_la_app"` on the screenshot)
so far it's working for bearer and noauth. @dannygroenewegen let me know if this is what you intended and we can merge back to alloy
Yes, great that you got it working! Some thoughts:
Should there be a seperate secret for bearer auth? It guess it works to reuse one secret for basicauth and bearer since they both accept a similar value. But bearer_token = "{{ secret "basic_auth" }}" reads a bit confusing. The basic_auth is also used for the loki and prometheus write url. Should we add something like a scrapemetric secret? Which can then be used in the scrape blocks for basicauth and bearer?
I don't understand the changes in 03227f1907. Doesn't this result in scraping every container and resulting in errors? Many won't have any metrics endpoint.
The live debugging could be useful. Should we put the 0.0.0.0:12345 listen address and the Traefik labels for that in a separate compose.alloydebug.yml? That would prevent unnecessarily exposing the alloy web ui publicly.
Anyway, I think it's ok to merge this into alloy so there's only one branch to work with. Once I get to testing, I could also address the above points.
> so far it's working for bearer and noauth. @dannygroenewegen let me know if this is what you intended and we can merge back to alloy
Yes, great that you got it working! Some thoughts:
- Should there be a seperate secret for bearer auth? It guess it works to reuse one secret for basicauth and bearer since they both accept a similar value. But `bearer_token = "{{ secret "basic_auth" }}"` reads a bit confusing. The basic_auth is also used for the loki and prometheus write url. Should we add something like a `scrapemetric` secret? Which can then be used in the scrape blocks for basicauth and bearer?
- I don't understand the changes in 03227f1907. Doesn't this result in scraping every container and resulting in errors? Many won't have any metrics endpoint.
- The live debugging could be useful. Should we put the `0.0.0.0:12345` listen address and the Traefik labels for that in a separate compose.alloydebug.yml? That would prevent unnecessarily exposing the alloy web ui publicly.
Anyway, I think it's ok to merge this into alloy so there's only one branch to work with. Once I get to testing, I could also address the above points.
I don't understand the changes in 03227f1907. Doesn't this result in scraping every container and resulting in errors? Many won't have any metrics endpoint.
it's to collect every metric produced, it doesn't go through relabeling and i didn't want to lose it
The live debugging could be useful. Should we put the 0.0.0.0:12345 listen address and the Traefik labels for that in a separate compose.alloydebug.yml? That would prevent unnecessarily exposing the alloy web ui publicly.
it's protected by basicauth like prometheus, but it could be moved to save on resources, alloy uses a lot of ram for a small vps!
> I don't understand the changes in 03227f1907. Doesn't this result in scraping every container and resulting in errors? Many won't have any metrics endpoint.
it's to collect every metric produced, it doesn't go through relabeling and i didn't want to lose it
> The live debugging could be useful. Should we put the 0.0.0.0:12345 listen address and the Traefik labels for that in a separate compose.alloydebug.yml? That would prevent unnecessarily exposing the alloy web ui publicly.
it's protected by basicauth like prometheus, but it could be moved to save on resources, alloy uses a lot of ram for a small vps!
fauno
marked the pull request as ready for review 2026-06-17 12:52:14 +00:00
fauno
approved these changes 2026-06-17 12:52:44 +00:00
fauno
merged commit 1d9eb10004 into alloy2026-06-17 12:53:09 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
To be merged into alloy branch #21
looks great, thanks! i'll test it this week :D
so adding bearer auth is just adapting the basic auth block? but the bearer auth is shared across all apps, like the basic auth. i mean, it's generated by this recipe.
Yes, one basic auth secret and one bearer secret that is used for every metric that requires it. But of course, we could extend this if needed. We could add a label like
prometheus.io/authsecret=defaultto specify using another secret.@dannygroenewegen please check coop-cloud/garage#19 in combination with bearer auth.
where would i find indication that the labels are getting discovered?
i noticed no coopcloud container is on the
docker_gwbridgenetwork, so i added alloy to theproxyand changed the network filter onconfig.alloy.tmpl. this way i couldcurlmetrics from garage on the alloy container, but i still don't see them appearing on grafana (other metrics such asalloy_build_infoare appearing, so sending metrics works)got it to work by scraping and relabeling from dockerswarm! the only issue is that swarm doesn't expose the domain names, so jobs are labeled by service names (
instance="git.sutty.abyaya.la"tojob="git_sutty_abyaya_la_app"on the screenshot)so far it's working for bearer and noauth. @dannygroenewegen let me know if this is what you intended and we can merge back to alloy
Yes, great that you got it working! Some thoughts:
bearer_token = "{{ secret "basic_auth" }}"reads a bit confusing. The basic_auth is also used for the loki and prometheus write url. Should we add something like ascrapemetricsecret? Which can then be used in the scrape blocks for basicauth and bearer?03227f1907. Doesn't this result in scraping every container and resulting in errors? Many won't have any metrics endpoint.0.0.0.0:12345listen address and the Traefik labels for that in a separate compose.alloydebug.yml? That would prevent unnecessarily exposing the alloy web ui publicly.Anyway, I think it's ok to merge this into alloy so there's only one branch to work with. Once I get to testing, I could also address the above points.
it's to collect every metric produced, it doesn't go through relabeling and i didn't want to lose it
it's protected by basicauth like prometheus, but it could be moved to save on resources, alloy uses a lot of ram for a small vps!