45 lines
1.6 KiB
Markdown
45 lines
1.6 KiB
Markdown
# 019 — Ntfy sink delivery
|
|
|
|
## Summary
|
|
|
|
Deliver a fired alert ([018](018-alert-trigger-evaluation.md)) to the
|
|
[ntfy](https://ntfy.sh) topic configured on its `AlertRule` ([017](017-ntfy-alerts.md)):
|
|
a plain HTTP POST of the notification body to `{server}/{topic}`, no SDK
|
|
needed.
|
|
|
|
## Scope
|
|
|
|
- A small async sender: `POST {server}/{topic}` with the alert's message as
|
|
the request body (ntfy's plain-text publish API — no auth, no extra
|
|
dependency beyond an HTTP client ottyl can already reach for, or a minimal
|
|
one if none exists yet).
|
|
- Message content: rule name plus enough context to be useful (matched log
|
|
line for Immediate/New value, current value vs. threshold for
|
|
Threshold/Ratio).
|
|
- Delivery runs off the ingest hot path — spawn it (e.g.
|
|
`tokio::spawn`/an mpsc queue) so a slow or unreachable ntfy server never
|
|
blocks log ingestion.
|
|
- Failure handling: log the error to stderr and drop the notification — no
|
|
retry queue or backoff for this ticket (matches the project's existing
|
|
"best-effort, log and move on" style, e.g. `remove_css`'s file-removal
|
|
fallback).
|
|
|
|
## Acceptance criteria
|
|
|
|
- A fired alert results in exactly one HTTP POST to the rule's configured
|
|
`{server}/{topic}`.
|
|
- Ntfy being unreachable/erroring is logged but does not panic, block
|
|
ingestion, or crash the process.
|
|
- Covered by a test against a local mock HTTP server asserting the request
|
|
path/body.
|
|
|
|
## Depends on
|
|
|
|
- [017 — Alert definitions & settings persistence](017-ntfy-alerts.md)
|
|
- [018 — Alert trigger evaluation](018-alert-trigger-evaluation.md)
|
|
|
|
## Depended on by
|
|
|
|
- [020 — Alerts webapp UI](020-alerts-webapp-ui.md) (for a "send test
|
|
notification" action)
|