Megjelent az IncidentRelay 2.0 kiadása, amely nyílt rendszert fejleszt a készenléti ügyeletek szervezésére, az értesítések irányítására és az incidensek követésére, önálló szerveren (self-hosted) történő telepítéssel. A projekt célja a SRE, DevOps és infrastruktúra csapatok támogatása, akiknek helyi alternatívára van szükségük a felhőalapú ügyeletkezelő platformokkal szemben. A kód Python nyelven készült, MIT licenc alatt terjesztik.
Az IncidentRelay eseményeket fogad a Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch, Datadog, Uptime Kuma és bármilyen webhook-kezelőtől. Az esemény normalizálása után az azonosíthatóvá válik egy szolgáltatáshoz, csapathoz és rotációhoz, a hozzá irányított szabályok és eszkalációs politikák után értesítés küldésre kerül a jelenlegi ügyeletesnek. A kézbesítéshez a következők támogatottak: Mattermost, Slack, Telegram, Discord, Microsoft Teams, email, webhook, böngésző/PWA push és hanghívás-szolgáltatók.
A 2.0 verzió legfontosabb újdonsága az Event Orchestration mechanizmus volt, amely egy külön réteget biztosít az események feldolgozására a bejövő integrációk és az értesítések életciklusa között. Főbb változások:
- Hozzáadtunk egy vizuális szerkesztőt az orkesztrációs szabályokhoz. A szabályok globálisan vagy egy adott szolgáltatásra alkalmazhatók, beágyazott feltételcsoportokba összegyűjthetők, és fokozatosan módosíthatják a prioritást, a fontossági szintet, a címkéket, a csapatot, a útvonalat, a csoportosítás módját, az értesítési és eszkalációs politikákat;
- Megvalósítottuk az események elnémítására, eldobására és feldolgozásának felfüggesztésére, értékek kinyerésére reguláris kifejezésekkel és JSON Path segítségével, sztringek felosztására, változók létrehozására és értékek átalakítására szolgáló műveleteket;
- Az orkesztráció konfigurációját szerkeszthető tervezetekre és változtathatatlan közzétett verziókra osztottuk. Támogatott a konfiguráció ellenőrzése, közzététel, visszaállás az előző verzióra és megjegyzések hozzáadása a változtatásokhoz;
- A disabled, shadow és active üzemmódok kerültek bevezetésre. A shadow módban a szabályok végrehajtásának eredményei megőrződnek elemzésre, de nem hatnak a tényleges irányításra. Átmeneti időszakban elérhetők a legacy, hybrid és orchestration kompatibilitási módok;
- Hozzáadva eseményszimulációs és eseményújrajátszási eszközök. Ezek lehetővé teszik a szabályok tesztelését egy normalizált eseményen vagy az integráció forráspayloadján anélkül, hogy valódi riasztást kellene létrehozni. Az eredmények elemzéséhez végrehajtási nyomozás, Explain-adatok és árnyéküzemi mutatók állnak rendelkezésre;
- Megvalósítottuk az újrahasználható webhook-tevékenységeket, amelyek aszinkron módon hajtódnak végre az esemény feldolgozása után. A fejlécek titkosított formában tárolódnak, a titkok elrejtésre kerülnek az API-kban és a naplókban, a privát hálózatokhoz való hozzáférés pedig alapértelmezés szerint tilos. Beállíthatók az időtúllépések, újrapróbálkozások és a megengedett belső címek listája;
- Hozzáadva az Uptime Kuma integráció, amely a monitorok állapotjáról szóló standard webhook-üzeneteket fogad. Megvalósítva az UP és DOWN állapotok normalizálását, a fontosság meghatározását, a címkék kezelését és egy új bejövő útvonal típust uptime_kuma;
- A silences és a tervezett karbantartási ablakok esetében megjelentek az apply_to_existing és reactivate_on_end paraméterek. Az előbbi lehetővé teszi a már nyitott riasztások elnyomásának alkalmazását, míg az utóbbi meghatározza, hogy a nyomást követően folytatva kell-e kezelni őket. A figyelmeztetések, emlékeztetők és eszkalációs láncok felfüggesztésre és helyreállításra kerülnek;
- A személyes API-tokenekhez külön jogokat vezettünk be, az olvasás és a módosítás jogai külön függenek a csoportoktól, csapatoktól, felhasználóktól, útvonalaktól, csatornáktól, szolgáltatásoktól, rotációktól, politikáktól, karbantartási ablakoktól, heartbeat-ellenőrzésektől, SSO-tól és orkestrációktól. A régi aggregált jogok resources:read, resources:write és * az visszafelé kompatibilitás érdekében megmaradtak;
- Hozzáadva egy auditnapló interfész szűkítéssel és lapozással. A naplóban rögzítve vannak az orkestrációkkal, webhook-tevékenységekkel, silences-szel és tervezett karbantartási ablakokkal végzett műveletek, miközben a bizalmas értékek törlésre kerülnek a megjelenített adatokból;
- A webes felületen megjelent a sötét téma és a felhasználói nyelvi és megjelenítési beállítások. Hozzáadva a francia lokalizáció, a karbantartás és az orkestrációs szekciók fordítása kibővült, a SSO csoportbeállítások szerkesztése javítva lett;
- Javítottuk a heartbeat-ellenőrzések működését: a lejárati események újbóli létrehozása kiküszöbölve, a jel helyreállítása helyesen lezárja a riasztást és problémamegoldásról szóló értesítést küld, az időbélyegek megjelenítése egységesítve van;
- Elkészült a Kubernetes-ben történő telepítés dokumentációja a Helm segítségével. A Helm chartba került egy külön Slack Socket Mode feldolgozó, amely szükséges az interaktív megerősítő gombok és a incidensek lezárásának működéséhez;
- Megerősítettük a kimenő HTTP-kérések, reguláris kifejezések és érzékeny adatok védelmét, centralizáltuk az UTC és időzónák feldolgozását, átdolgoztuk a rotációs ütemezések számításait, és kiterjesztettük az automatikus tesztekkel való lefedettséget.
Frissítés előtt ajánlott biztonsági másolatot készíteni az adatbázisról. A szükséges séma módosításokat az IncidentRelay beépített migrációs mechanizmusa végzi. Az Event Orchestration fokozatos bevezetéséhez a fejlesztők azt javasolják, hogy először a shadow és hybrid módokat használják, ellenőrizzék a szabályok végrehajtásának nyomait, és csak ezután kapcsolják át az orchestrációt aktív módba.
Forrás: opennet.ru
