homelab-codex-ws/services/fleet-prometheus/rules/kb-mail-sync.yml

41 lines
2.5 KiB
YAML
Raw Permalink Normal View History

feat(mail-sync): scheduler PIHA, takt kb-ingest, runbook i dokumentacja Domkniecie Kroku 7. Realizuje Decyzje (d) reconu (host schedulera + korekta kadencji indeksowania) i doklada dokumentacje wg konwencji OKF. Scheduler (NIEAKTYWOWANY — wlacza operator): - jobs/mail-imap-sync/systemd/{service,timer,run.sh} — wzorzec 1:1 z kb-ingest, OnCalendar=hourly, Persistent=true, log do pliku (nigdy sam journal). - hosts/piha/jobs.yaml — deklaracja jednostek host-level na PIHA. Nowy plik, bo services.yaml jest dla kontenerow (supervisor dopasowuje jego wpisy do world-state i wpis niekontenerowy dryfowalby wiecznie jako missing_service). Nic tego pliku nie czyta — istnieje po to, zeby "shadow-deploy family" z otwartego pytania 5 reconu multiagentowego byla spisana, a nie tylko na nodzie. Takt indeksowania (Decyzja (d), recon §3.3): - kb-ingest.timer: 03:30 raz na dobe -> co 2 h. O 03:30 SOLARIA prawie na pewno spi (potwierdzone odczytem kb_ingest_embed_skipped 1 z 2026-08-06), a tick dostaje teraz etap mailowy: ~60 nowych chunkow na dobe pomijanych kazdej nocy sprawiloby, ze backlog rosnie monotonicznie i KbEmbedBacklogGrowing zapala sie NA STALE. Co 2 h zamiast stalej godziny — probe Ollamy sam wybiera okno, wiec ktorys tick w nie trafi niezaleznie od nawykow operatora. - cyclic_ingest: etap mailowy (mail_body_ingest --only-unchunked), import miekki, wiec venv bez tego pakietu pomija etap zamiast wywracac wrapper. Predykat bledu JEST luzniejszy niz wlasne main() tamtego joba i to jedyne takie miejsce w tym wrapperze: pojedynczy trwale nieparsowalny mail nie moze zamrozic last_success_timestamp i zapalic KbIngestStale na zawsze. Bledy per-mail sa publikowane jako kb_ingest_mail_parse_errors, nie chowane. Obserwowalnosc: KbMailSyncStale (6 h bez udanego ticku). Alert na cisze w skrzynce ODRZUCONY (decyzja operatora, zgodna z reconem §3.4) — zero nowych maili to legalny stan skrzynki, a alert zapalajacy sie na zdrowym systemie zostaje wyciszony i przestaje dzialac wtedy, gdy jest potrzebny. Dokumentacja: - kb/services/job-mail-imap-sync.md (OKF), kb/runbooks/mail-sync-run.md — 9 krokow pierwszego uruchomienia, w tym checklista 4 punktow [do weryfikacji na zywo] z reconu (polityki dostawcow — do sprawdzenia, nie do zgadniecia) oraz pomiar STATUS (MESSAGES) na Fastmailu, na ktorym zapada ODLOZONA decyzja o historii. - kb-mail-pillar.md: KOREKTA JMAP -> IMAP dla Fastmaila jako decyzja 2026-08-06; stary zapis zostaje jako historia z data. Zamkniete "unifikacja adaptera" i "sizing Gmaila"; otwarte zostaje "sizing Fastmaila" — celowo, bo rozstrzyga je pomiar, nie dyskusja. - kb-m5-faza-mailowa.md: Krok 7 IN PROGRESS + tabela zakresu wdrozonego, kb-m5-faza3.md: korekta harmonogramu i sekwencji wrappera, pkg-kb-mail.md: rozpisany ze stubu, kb-postgres.md: lista migracji + 005. Testy: 642 passed (calosc kb-mail, kb-retrieval i jobs). systemd-analyze verify na timerze przechodzi, OnCalendar=0/2:00:00 normalizuje sie do co 2 h. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-06 14:49:58 +02:00
# fleet-prometheus kb-mail-sync rules — faza mailowa Krok 7
# (recon kb/audits/mail-sync-2026-08-06.md §3.4).
#
# Same delivery convention as kb-ingest.yml and liveness.yml: no Alertmanager. These rules
# only make alerts FIRING (visible at GET /api/v1/alerts on this Prometheus instance);
# brain-watchdog@PIHA polls that API and forwards to Telegram. Do NOT add Alertmanager here.
#
# Metrics come from jobs/mail-imap-sync's textfile output
# (/opt/homelab/state/node-exporter/kb-mail-sync.prom), scraped by node_exporter on PIHA —
# every series from that target already carries node="piha" (fleet-node job's static label).
#
# Until the operator installs and enables kb-mail-sync.timer the metric does not exist, and
# `time() - <missing series>` produces no result — so this file is inert on a fleet where the
# job has not been set up. It does not need to be deployed in lockstep with the job.
groups:
- name: kb-mail-sync
rules:
- alert: KbMailSyncStale
# 6 missed hourly ticks. This is the ONE alert this job gets, and deliberately so:
# it answers "is the poller working at all", which has no false positives — unlike
# any threshold on how much mail arrived.
#
# "No new mail for X days" was considered and REJECTED (recon §3.4). Zero new mail is
# a legal state of a mailbox — a holiday, a weekend, traffic moved to the other
# account. An alert that fires on a healthy system gets muted, and a muted alert is
# not there on the day it is needed.
expr: time() - kb_mail_sync_last_success_timestamp{node="piha"} > 21600
for: 5m
labels:
severity: critical
annotations:
summary: "kb-mail-sync stale on {{ $labels.node }}"
description: "kb-mail-sync.timer has not completed a successful run in over 6h on {{ $labels.node }} — the mail corpus has stopped growing. Check `journalctl -u kb-mail-sync.service` and the latest /opt/homelab/logs/kb-mail-sync/run-*.log; an expired or revoked IMAP app password is the most likely cause."
# Deliberately NOT defined here, pending a month of observation (recon §3.4):
# a per-account warning on kb_mail_sync_last_message_ts (age of the newest mail).
# It needs a per-account threshold — gmail is the junk account and days of silence
# there would be odd, while for fastmail it would not be — and that threshold should
# come from measured behaviour, not from a guess made before the first run.