grafana-alloy: add NixOS module

[flokli]

cc @vunso @hbjydev @claudiiii

Description of changes

This adds a NixOS module for grafana-alloy.

I started from the grafana-agent, one but dropped all settings and
config management whatsoever.

grafana-alloy uses its own Alloy config format (similar to HCL), which
is not really possible to express in Nix.
Simply pointing to a path in `/etc`, and leaving it up to the user to configure
it via `environment.etc` allows the user to arrange config files however
it makes most sense for them.

It also adds a VM test, ensuring it starts up healthy (with empty config),
and adds it to the package passthru.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[hbjydev]

LGTM

[flokli]

Deployed this to some of my infrastructure (using my old grafana flow configs). Also verified changes in the config file cause a reload (not restart), and are picked up successfully.

[hbjydev]

So, on a second (more thorough) readthrough, I've got more stuff to add to this; as payment for being a PITA though I'm happy to also add myself to the maintainers list on this one :)

Apologies, just want to make sure it's got decent consistency with the upstream stuff, primarily for the sake of it being an easy transition for people coming from something like Ubuntu where the naming is all just alloy, not grafana-alloy.

Once these are addressed (even if they're dismissed), I'm happy for this to go through one more build-test cycle and then look to get it merged. I'll deploy it to my own machines later today if I can, but without binary cache it'll be a tad painful lol

[flokli]

Hmmh, okay, their debian package also calls this alloy. I'd wish we could rename this alloy gloabbly, but that package already exist.

I'll push a new version shortly, updating the module, unit files etc.

[flokli]

Everything done except for the adm group change. I propose we merge this in as-is.

if adding the group becomes necessary, we can still fix it in a followup. It wasn't necessary for grafana-agent to get systemd journal logs collected, so I'd be surprised it'd be necessary for alloy.

[hbjydev]

@flokli it's not for journal, it's because adm has read access to most of /var/log, so it opens up syslog and stuff. I'd like to avoid removing groups from the user if it's not necessary personally.

[flokli]

@flokli it's not for journal, it's because adm has read access to most of /var/log, so it opens up syslog and stuff. I'd like to avoid removing groups from the user if it's not necessary personally.

There's nothing in the tmpfiles shipped with NixOS granting access to /var/log, only /var/log/journal, so this has no effect in terms of allowing more log files to be read out of the box.

I'd prefer this to be opt in, due to the security implications and principle of least privilege, and adm being used to allow sudo in some cases.

After all, it's only a systemd.services.alloy.serviceConfig.SupplementaryGroups away, or even better, access be allowed on the logs themselves, by granting the alloy user access to log files through ACLs.

[flokli]

Okay, apparently it's admin, not to be confused with adm, which should not hand out sudo access. At least assuming stock sudoers files, and noone confusing it the other way round 😱 .

I still think there's very little on NixOS these days still logging to /var/log , which is not to the journal, so I'd prefer to not add this group to the alloy service by default.

Considering we don't configure ACLs for other files in /var/log, users need to do some work to make it available for the alloy service, so I'd rather keep it opt-in (and granting the alloy user access might be the cleaner choice).