My to často děláme tak, že pokud se zachytí nějaký stav, který by neměl existovat, pošleme si zprávu na Telegram do k tomu zřízené skupiny.
...
Specializované systémy, které mají sloužit jen pro monitoring jsem nepochopil. Jsou složité a nic moc navíc to nepřinese.
Tohle funguje v malém týmu a situaci, kde se těch problémů moc neděje a může si tam člověk tyhle custom věci snadno dodělat. Pokud by ten kanál mělo monitorovat sto lidí, a chodilo tam furt něco, tak to začnou všichni ignorovat. Takže se musí rozdělit role a scope (developera v týmu X možná zajímá, že jeho služba má problém, ale fakt nepotřebuje vědět, že na serveru týmu Y umřel disk), různé priority problémů, je potřeba udržet jednotnost monitoringu v rámci projektu, do toho se přidají požadavky na certifikaci...
A to je zatím jen detekce stavů pro alerty. Já ale chci vidět, co třeba dělá nová změna mojí služby s počtem spojení na databázi. Ale abych to mohl posoudit, potřebuji vidět i kolik chodí požadavků na tu službu, nestačí si jen grepnout něco v terminálu. Obzvlášť, když ani nemám do produkčního prostředí přístup na shell.
Nebo pokud jde o nějakou službu/server od někoho jiného - asi bude mít nějaký endpoint co bude produkovat metriky pro Prometheus, ale těžko do něj budu dělat binární patche, abych si tam přidal http call. Nedej bože, když to ani neběží na mém železe. To se pak najednou nějaké monitorovací systémy, kde se to všechno sbírá dohromady, začnou pořádně hodit.
Zní to rozumně, velký projekt a tým má jiné požadavky. Nicméně předpokládám, že většina projektů (alespoň v době kdy začínají) jede spíše v menším týmu a vyhnout se parním mlátičkám může být výhoda. Alespoň pro začátečníky určitě.
Problém nezahltit je zde vždy. Na telegram je třeba posílat opravdu jen urgentní věci, jako že něco opravdu spadlo nebo to bezprostředně hrozí. Zbytek stačí do mailu nebo jiného systému, nebo jen logovat případně posílat jednou za čas reporty.
Poslední příspěvky
.... a provize aukru
