feat(monitoring): add uptime-kuma for status page, see #97 #118

Open
kiaragrouwstra wants to merge 6 commits from kiaragrouwstra/infra:feature-service-uptime-kuma into main
First-time contributor

Adds a config for a status page using uptime-kuma.
Open questions here included:

  • what machine to run this on
    (and if a new one how to configure their network bits);
  • who could help set the secret in the age file;
  • who could set up the application password (currently a manual step in
    services.uptime-kuma), after which the stateless client can be re-built;
  • what to monitor -- i for now commented some sub-domains i could not
    publicly access to test.
Adds a config for a status page using uptime-kuma. Open questions here included: - what machine to run this on (and if a new one how to configure their network bits); - who could help set the secret in the age file; - who could set up the application password (currently a manual step in services.uptime-kuma), after which the stateless client can be re-built; - what to monitor -- i for now commented some sub-domains i could not publicly access to test.
kiaragrouwstra added 1 commit 2024-09-27 06:51:52 +00:00
Adds a config for a status page using uptime-kuma.
Open questions here included:
- what machine to run this on
(and if a new one how to configure their network bits);
- who could help set the secret in the age file;
- who could set up the application password (currently a manual step in
services.uptime-kuma), after which the stateless client can be re-built;
- what to monitor -- i for now commented some sub-domains i could not
publicly access to test.
janik requested changes 2024-09-28 17:47:47 +00:00
janik left a comment
Owner

what machine to run this on

I think we should add this to public01.

who could help set the secret in the age file;

That would be @raito afaik.
(btw we should document the secret management)

who could set up the application password (currently a manual step in services.uptime-kuma), after which the stateless client can be re-built;

Isn't the passwordFile set using agenix in line 82 or does someone have to ssh onto the host and run some uptime-kuma management command? (I'm unfamiliar with uptime-kuma)

what to monitor -- i for now commented some sub-domains i could not publicly access to test.

Anything with a public facing web interface, which should basically be everything.
You might not be able to access domains such as fodwatch or news at the time because we (try to) shut down the bare metal servers if the services aren't actively in use.

> what machine to run this on I think we should add this to public01. > who could help set the secret in the age file; That would be @raito afaik. (btw we should document the secret management) > who could set up the application password (currently a manual step in services.uptime-kuma), after which the stateless client can be re-built; Isn't the passwordFile set using agenix in line 82 or does someone have to ssh onto the host and run some uptime-kuma management command? (I'm unfamiliar with uptime-kuma) > what to monitor -- i for now commented some sub-domains i could not publicly access to test. Anything with a public facing web interface, which should basically be everything. You might not be able to access domains such as fodwatch or news at the time because we (try to) shut down the bare metal servers if the services aren't actively in use.
@ -0,0 +5,4 @@
...
}:
let
subdomains = [
Owner

It would be preferable to pull the domain information from the terraform/dnsimple.nix, so we avoid maintaining the list of domains twice.

It would be preferable to pull the domain information from the `terraform/dnsimple.nix`, so we avoid maintaining the list of domains twice.
Owner

This should probably be injected via specialArgs I assume to make it available.

This should probably be injected via `specialArgs` I assume to make it available.
Author
First-time contributor

hm. i agree, tho i'm not entirely sure yet what the best approach would here.
if the file were imported (edit: / injected) i'm under the impression it would go thru a mkIf check.
maybe the data-y bits could be e.g. factored out into a separate file to reuse from both uptime-kuma (if not also from gandi which has lotsa overlap with dnsimple)?
feedback welcome. 😶

hm. i agree, tho i'm not entirely sure yet what the best approach would here. if the file were `import`ed (edit: / injected) i'm under the impression it would go thru a `mkIf` check. maybe the data-y bits could be e.g. factored out into a separate file to reuse from both `uptime-kuma` (if not also from `gandi` which has lotsa overlap with `dnsimple`)? feedback welcome. 😶
Owner

Let's keep it simple for now, we can do it in a further PR. It's unclear how to extract the data-y bits, maybe Terranix could expose a data-only module we could re-import in the whole expr, unclear to me yet.

Let's keep it simple for now, we can do it in a further PR. It's unclear how to extract the data-y bits, maybe Terranix could expose a data-only module we could re-import in the whole expr, unclear to me yet.
@ -0,0 +26,4 @@
# "news"
];
host = "status.forkos.org";
Owner

Please add the domain to terraform ^^

Please add the domain to terraform ^^
@ -0,0 +29,4 @@
host = "status.forkos.org";
port = 3001;
in
{
Owner

Please guard the config behind a mkIf with an enable option like options.bagel.status.enable = mkEnableOption "status page";. Currently, applying this change would enable this service on every host.

Please guard the config behind a mkIf with an enable option like `options.bagel.status.enable = mkEnableOption "status page";`. Currently, applying this change would enable this service on every host.
raito marked this conversation as resolved
@ -0,0 +31,4 @@
in
{
imports = [ "${inputs.stateless-uptime-kuma}/nixos/module.nix" ];
nixpkgs.overlays = [ (import "${inputs.stateless-uptime-kuma}/overlay.nix") ];
Owner

We maintain all the input related overlays directly in the flake.nix.

We maintain all the input related overlays directly in the flake.nix.
Owner

Yeah, all modules and overlays should be applied uniformly to all machines.

Yeah, all modules and overlays should be applied uniformly to all machines.
raito marked this conversation as resolved
@ -0,0 +35,4 @@
services.uptime-kuma.enable = true;
services.nginx = {
Owner

The nginx stuff is fine for now, but we should generalize proxying a bit in the future. (having every service add their own firewall rules, and nginx config is redundant and error prone)

The nginx stuff is fine for now, but we should generalize proxying a bit in the future. (having every service add their own firewall rules, and nginx config is redundant and error prone)
raito marked this conversation as resolved
Owner

@kiaragrouwstra I'm available to help you get this PR to the finishline, if you need my help on anything.

@kiaragrouwstra I'm available to help you get this PR to the finishline, if you need my help on anything.
kiaragrouwstra added 1 commit 2024-09-28 20:15:09 +00:00
kiaragrouwstra added 1 commit 2024-09-28 20:18:22 +00:00
kiaragrouwstra added 1 commit 2024-09-28 20:20:57 +00:00
kiaragrouwstra added 1 commit 2024-09-28 20:22:43 +00:00
kiaragrouwstra added 1 commit 2024-09-28 20:25:16 +00:00
Author
First-time contributor

i pushed updates to address some of the feedback now.

who could set up the application password (currently a manual step in services.uptime-kuma), after which the stateless client can be re-built;

Isn't the passwordFile set using agenix in line 82 or does someone have to ssh onto the host and run some uptime-kuma management command? (I'm unfamiliar with uptime-kuma)

i thought so too.
unfortunately, as it turns out, the credential popped in there is essentially for a client thing to access the actual service so as to populate it declaratively from nix.
as such, it seems that the service itself at present still needs to manually be assigned those seemed credentials imperatively right now.

i pushed updates to address some of the feedback now. > > who could set up the application password (currently a manual step in services.uptime-kuma), after which the stateless client can be re-built; > > Isn't the passwordFile set using agenix in line 82 or does someone have to ssh onto the host and run some uptime-kuma management command? (I'm unfamiliar with uptime-kuma) i thought so too. unfortunately, as it turns out, the credential popped in there is essentially for a client thing to access the actual service so as to populate it declaratively from nix. as such, it seems that the service itself at present still needs to manually be assigned those seemed credentials imperatively right now.
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u feature-service-uptime-kuma:kiaragrouwstra-feature-service-uptime-kuma
git checkout kiaragrouwstra-feature-service-uptime-kuma

Merge

Merge the changes and update on Forgejo.
git checkout main
git merge --no-ff kiaragrouwstra-feature-service-uptime-kuma
git checkout main
git merge --ff-only kiaragrouwstra-feature-service-uptime-kuma
git checkout kiaragrouwstra-feature-service-uptime-kuma
git rebase main
git checkout main
git merge --no-ff kiaragrouwstra-feature-service-uptime-kuma
git checkout main
git merge --squash kiaragrouwstra-feature-service-uptime-kuma
git checkout main
git merge --ff-only kiaragrouwstra-feature-service-uptime-kuma
git checkout main
git merge kiaragrouwstra-feature-service-uptime-kuma
git push origin main
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: the-distro/infra#118
No description provided.