nixos/prometheus: abbility to add downstream exporters

[mkg20001]

Description of changes

This adds the abbility to add downstream exporters while profiting from upstream's exporter config generator

Documentation of the new method: https://github.com/mgit-at/nixpkgs/blob/downstream-exporter/nixos/modules/services/monitoring/prometheus/exporters.md#adding-a-downstream-exporter-module-services-prometheus-exporters-downstream-exporter

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.05 Release Notes (or backporting 23.05 and 23.11 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.

[nbraud]

Why does this need to be passed via a file? Being able to pass that inline seems useful, at least for exporters with little-to-no configurability; it seems better from a readability standpoint, than having to jump files (and mental contexts) to get potentially-little information.

[mkg20001]

Current exporters are also files, this fits the pattern.

I could extend it to take a function too and call the option "module" therefore keeping it similar to how "imports" works right now

[nbraud]

Current exporters are also files, this fits the pattern.

I'm not saying it's necessarily wrong to put it in a separate file, especially in the current case: folder full of exporters, which the module automatically maps through mkExporter. However, I think it would be pretty natural to either take in an already-resolved attrset, or a function (taking pkgs, lib, etc.)

Importing the file can be the responsibility of the caller then, which leaves them the ability to implement whatever conventions they use; for instance, if something ships a bunch of exporters which use a common configuration format (incl. cmdline parameters) the drv's author may want to automate the option and service definitions, which seems simpler to do if they can programatically generate that part before passing it to mkExporter.
(In principle it's entirely possible to do the same thing with pass-by-file, using IFD, but that gets kind of gnarly.)

[nbraud]

Could this be exposed under utils or such, instead of hardcoding that path in every caller?

[mkg20001]

Does it fit there? Certainly could be done

[nbraud]

Seems useful, but I had a couple questions about the proposed implementation.