Doplnění. Uptime Kuma umí eskalace přidáním více monitorovacích služeb kontrolující stejný endpoint, ale s nastavením rozdílné tolerance na výpadek.
--
Dlužím vysvětlení. Ačkoliv správná odpověď na anketu je "Kombinace více problémů", příčinu vidím jen a pouze na své straně. Vysvětlím proč.
Fórum běží na LXC kontejneru ve dvou Docker Compose projektech. První je reverzní proxy (caddy:2-alpine) a druhý projekt obsahuje aplikační server (caddy:2-alpine) + PHP FPM kontejnery (php8.3-fpm) + MySQL (mysql:8.4) + Redis (redis:7.4-alpine) + nějaké provozní kontejnery pro správu. Dvakrát denně se vytváří snapshoty pro zálohu (BTRFS), přičemž v inkriminovatný čas se nějakým způsobem poškodil běh na aplikačním serveru. Důvod přičítám na vrub softwarovému RAIDU, resp. životnosti SSD disků v něm, protože pravidelně registruju zmenšování SMART Available Spare Threshold. Stát se to může a migraci na nové železo + přehození na Kubernetes jsem měl stejně v plánu ještě letos.
Proč mluvím o svém selhání souvisí s tím, že jsem v daný den ignoroval mobilní notifikace (ntfy) od Uptime Kuma, která 404 správně vyhodnotila jako závadu. Reagoval jsem až s mnohahodinovým zpožděním. Funguje mi sice hlídání služeb, ale nefunguje eskalace. Tedy, aby v případě, že je služba nefunkční delší dobu (v řádech desítek minut), tak by notifikace měly zvýšit invazivnost (mobilní notifikace > SMS > prozvonění). Samozřejmě od věci by nebyla ani delegace na záložní druhou osobu. Tady je nedostatek, který musím napravit a napravím.
Jak řešíte hlídání služeb v malých týmech a one-man-show projektech vy? Co se vám osvědčilo a na co nedáte dopustit?
