feat(monitoring): blackbox-http probe for shelly-manager /health (REN-533) #1105

2026-10-03T16:29:14Z

Ghost commented

2026-10-03 16:29:14 +00:00

What

Adds http://shelly-manager.home-assistant.svc.cluster.local:80/health to the blackbox-http Probe (kubernetes/apps/monitoring-rules/probes-blackbox.yaml). blackbox-http goes from 20 to 21 targets. The other Probes are unchanged.

Why

REN-533 / REN-531: app-health signal for shelly-manager from the in-cluster vantage. The external hostname sits behind the shelly-manager-gate outpost, so an external probe reports the gate, not the app. The existing BlackboxProbeFailing rule (job=blackbox-http, not in its exclusion list) covers the new target. No new rule.

How verified

Service shelly-manager :80 → targetPort http = containerPort 8080. /health is the pod's kubelet liveness/readiness path.
App source: MapGet("/health", ...Results.Ok).AllowAnonymous(). Test Health_IsUnauthenticated asserts 200 (not 3xx). AllowedHosts: "*", so http_2xx passes.
Network: home-assistant-ns.yaml default-deny admits the whole monitoring namespace on every port. The monitoring namespace has no egress policy. No CNP change.
YAML parses: blackbox-http 21, edge-wan 3, tcp-relays 2, negative-control 4.
Not yet live. After merge, check probe_success{job="blackbox-http",instance="http://shelly-manager.home-assistant.svc.cluster.local:80/health"} and probe_http_status_code, which should be 200.

Risk

Prometheus-side only. No workload restarts and no Home Assistant impact.

Revert

Delete the target line (and its comment block), or git revert this commit.

🤖 Generated with Claude Code

## What Adds `http://shelly-manager.home-assistant.svc.cluster.local:80/health` to the `blackbox-http` Probe (`kubernetes/apps/monitoring-rules/probes-blackbox.yaml`). blackbox-http goes from 20 to 21 targets. The other Probes are unchanged. ## Why REN-533 / REN-531: app-health signal for shelly-manager from the in-cluster vantage. The external hostname sits behind the shelly-manager-gate outpost, so an external probe reports the gate, not the app. The existing `BlackboxProbeFailing` rule (job=blackbox-http, not in its exclusion list) covers the new target. No new rule. ## How verified - Service `shelly-manager` :80 → targetPort `http` = containerPort 8080. `/health` is the pod's kubelet liveness/readiness path. - App source: `MapGet("/health", ...Results.Ok).AllowAnonymous()`. Test `Health_IsUnauthenticated` asserts 200 (not 3xx). `AllowedHosts: "*"`, so http_2xx passes. - Network: `home-assistant-ns.yaml` default-deny admits the whole `monitoring` namespace on every port. The monitoring namespace has no egress policy. No CNP change. - YAML parses: blackbox-http 21, edge-wan 3, tcp-relays 2, negative-control 4. - Not yet live. After merge, check `probe_success{job="blackbox-http",instance="http://shelly-manager.home-assistant.svc.cluster.local:80/health"}` and `probe_http_status_code`, which should be 200. ## Risk Prometheus-side only. No workload restarts and no Home Assistant impact. ## Revert Delete the target line (and its comment block), or `git revert` this commit. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Ghost added 1 commit 2026-10-03 16:29:15 +00:00

feat(monitoring): blackbox-http probe for shelly-manager /health (REN-533)

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

ci/woodpecker/pr/pr-review Pipeline was successful

Details

ci/woodpecker/pr/ci-manifests-test Pipeline failed

Details

6649e5b560

In-cluster app-health target via the ClusterIP Service, so a dead app
behind the live shelly-manager-gate outpost no longer reads green.
Covered by the existing BlackboxProbeFailing rule; no CNP change needed
(home-assistant default-deny already admits the monitoring namespace).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Ghost approved these changes

2026-10-03 16:30:50 +00:00

Ghost left a comment

Approved on 6649e5b5. Checked: Service shelly-manager :80 -> targetPort http = containerPort 8080; /health is the pod's liveness/readiness path, pod Ready, endpoint 8080 ready. home-assistant-ns CNP admits monitoring ns on all ports; monitoring CNPs are ingress-only, no egress. js-yaml parse: blackbox-http 20->21, other three Probes unchanged (3/2/4). BlackboxProbeFailing (job=blackbox-http, for 10m, warning) does not exclude the target. Prometheus-only, revert = drop one line.

Approved on 6649e5b5. Checked: Service shelly-manager :80 -> targetPort http = containerPort 8080; /health is the pod's liveness/readiness path, pod Ready, endpoint 8080 ready. home-assistant-ns CNP admits monitoring ns on all ports; monitoring CNPs are ingress-only, no egress. js-yaml parse: blackbox-http 20->21, other three Probes unchanged (3/2/4). BlackboxProbeFailing (job=blackbox-http, for 10m, warning) does not exclude the target. Prometheus-only, revert = drop one line.

Ghost merged commit e553c37cb3 into master

2026-10-03 16:30:51 +00:00

Ghost referenced this issue from a commit

2026-10-03 16:30:53 +00:00

Merge pull request 'feat(monitoring): blackbox-http probe for shelly-manager /health (REN-533)' (#1105) from atlas/ren-533-shelly-manager-probe into master

review-bot reviewed

2026-10-03 16:31:52 +00:00

review-bot left a comment

🤖 Automated review — model CLI default (complexity: unknown), commit 6649e5b560aae6c8de146b39926a001fd2aca38c.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

Adds one new blackbox-http target — http://shelly-manager.home-assistant.svc.cluster.local:80/health — following the exact monitoring-vantage-point-rule pattern already established for the navidrome/lidarr and paperless app-health probes in the same file. No blocking issues; the change is small, well-scoped, and its claims check out against the checkout.

Verified against the repo:

shelly-manager-service.yaml: :80 → targetPort: http → container port 8080 (shelly-manager-deployment.yaml) — matches the PR's port claim.
shelly-manager-deployment.yaml liveness/readiness probes already use /health and the file's own comment states it is "the app's unauthenticated liveness endpoint" — corroborates the PR's unauthenticated-200 claim (the actual ASP.NET test referenced lives in the shelly-manager app repo, not here, so that specific assertion can't be directly verified from this checkout).
home-assistant-ns.yaml default-deny-ingress: the "Prometheus scrape" fromEndpoints rule for namespace monitoring (lines 90-93) has no toPorts restriction, so it already admits blackbox-exporter to any port in home-assistant, including :8080 — no CNP change is needed, as claimed.
monitoring-ns.yaml: no policy selecting the monitoring namespace declares an egress: block, so blackbox-exporter isn't in egress enforcement — egress to home-assistant is unaffected, consistent with the existing navidrome/paperless targets.
prometheusrule-blackbox.yaml: BlackboxProbeFailing's exclusion regex (line 36) does not mention shelly-manager, so the new target is covered by the existing alert as claimed, with no rule change needed.
Counted static targets in blackbox-http: 21 after this change (20 before) — matches the PR body's count.
AllowedHosts: "*" is an app-level (shelly-manager repo) setting not visible in this checkout; nothing here contradicts it (no AllowedHosts/host-restriction env var is set in the Deployment to override an app default), but it isn't independently verifiable from this repo.

🟡 Suggestions

Unlike the navidrome/lidarr and paperless app-health probes (which each note an external UptimeRobot/gatus counterpart "REN-2 adds ... the other half of the pair"), this change adds no mention of an external reachability check for shelly.renner.uno behind the gate. If one isn't already tracked elsewhere (REN-531?), it's a gap in the pairing this file otherwise establishes consistently — worth a one-line confirmation in the PR description rather than a code change.
The PR body's "How verified" section leans on an external repo's test (Health_IsUnauthenticated) and app config (AllowedHosts: "*") that can't be checked from this checkout. The in-repo corroboration (kubelet probes already targeting /health, deployment comment calling it unauthenticated) is reasonably strong, but the post-merge verification step the PR already proposes (probe_success/probe_http_status_code on first scrape) is the real confirmation and should be followed up on, per the PR's own "Not yet live" note.

Tests

No test suite applies to this YAML-only Probe addition; the repo's own convention for this file is self-verification (YAML parses, target counts, CNP tracing) rather than automated tests, which the PR already did. Nothing further is expected here.

Recommendation

Looks reasonable — no blocking issues; comments above are optional.

🤖 **Automated review** — model `CLI default` (complexity: unknown), commit `6649e5b560aae6c8de146b39926a001fd2aca38c`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary Adds one new `blackbox-http` target — `http://shelly-manager.home-assistant.svc.cluster.local:80/health` — following the exact `monitoring-vantage-point-rule` pattern already established for the navidrome/lidarr and paperless app-health probes in the same file. No blocking issues; the change is small, well-scoped, and its claims check out against the checkout. Verified against the repo: - `shelly-manager-service.yaml`: `:80` → `targetPort: http` → container port `8080` (`shelly-manager-deployment.yaml`) — matches the PR's port claim. - `shelly-manager-deployment.yaml` liveness/readiness probes already use `/health` and the file's own comment states it is "the app's unauthenticated liveness endpoint" — corroborates the PR's unauthenticated-200 claim (the actual ASP.NET test referenced lives in the `shelly-manager` app repo, not here, so that specific assertion can't be directly verified from this checkout). - `home-assistant-ns.yaml` `default-deny-ingress`: the "Prometheus scrape" `fromEndpoints` rule for namespace `monitoring` (lines 90-93) has no `toPorts` restriction, so it already admits blackbox-exporter to any port in `home-assistant`, including `:8080` — no CNP change is needed, as claimed. - `monitoring-ns.yaml`: no policy selecting the monitoring namespace declares an `egress:` block, so blackbox-exporter isn't in egress enforcement — egress to `home-assistant` is unaffected, consistent with the existing navidrome/paperless targets. - `prometheusrule-blackbox.yaml`: `BlackboxProbeFailing`'s exclusion regex (line 36) does not mention `shelly-manager`, so the new target is covered by the existing alert as claimed, with no rule change needed. - Counted static targets in `blackbox-http`: 21 after this change (20 before) — matches the PR body's count. - `AllowedHosts: "*"` is an app-level (shelly-manager repo) setting not visible in this checkout; nothing here contradicts it (no `AllowedHosts`/host-restriction env var is set in the Deployment to override an app default), but it isn't independently verifiable from this repo. ## 🟡 Suggestions - Unlike the navidrome/lidarr and paperless app-health probes (which each note an external UptimeRobot/gatus counterpart "REN-2 adds ... the other half of the pair"), this change adds no mention of an external reachability check for `shelly.renner.uno` behind the gate. If one isn't already tracked elsewhere (REN-531?), it's a gap in the pairing this file otherwise establishes consistently — worth a one-line confirmation in the PR description rather than a code change. - The PR body's "How verified" section leans on an external repo's test (`Health_IsUnauthenticated`) and app config (`AllowedHosts: "*"`) that can't be checked from this checkout. The in-repo corroboration (kubelet probes already targeting `/health`, deployment comment calling it unauthenticated) is reasonably strong, but the post-merge verification step the PR already proposes (`probe_success`/`probe_http_status_code` on first scrape) is the real confirmation and should be followed up on, per the PR's own "Not yet live" note. ## Tests No test suite applies to this YAML-only Probe addition; the repo's own convention for this file is self-verification (YAML parses, target counts, CNP tracing) rather than automated tests, which the PR already did. Nothing further is expected here. ## Recommendation Looks reasonable — no blocking issues; comments above are optional.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#1105