Im bardziej skomplikowany jest system, tym więcej pojawia się różnych alertów. Wzrasta potrzeba reagowania na te alerty, ich agregacji i wizualizacji. Myślę, że to sytuacja znajoma wielu osobom, aż do nerwowego tiku.
Rozwiązanie, o którym mowa, nie jest zaskakujące, ale nie ma pełnego artykułu na ten temat w wyszukiwarce.
Dlatego postanowiłem podzielić się doświadczeniem FunCorp i opisać, jak wygląda proces dyżurów, kto dzwoni, dlaczego i jak to wszystko można monitorować.
Czym jest PagerDuty?
Aby rozwiązać te wszystkie problemy, zaczęliśmy szukać wygodnego narzędzia. Po krótkich poszukiwaniach zdecydowaliśmy się na PagerDuty. PD wydaje się być wystarczająco kompletnym i zwięzłym rozwiązaniem z dużą liczbą integracji i ustawień. Czym dokładnie jest?
W skrócie, PagerDuty to platforma do zarządzania incydentami, która potrafi obsługiwać przychodzące incydenty poprzez różne integracje, ustawiać harmonogram dyżurów, a następnie powiadamiać dyżurnego inżyniera w zależności od poziomu incydentu (przy wysokim poziomie — telefon, przy niskim — powiadomienie z aplikacji/SMS).
Kim jest dyżurny?
Prawdopodobnie to pierwsza kwestia, od której należy rozpocząć konfigurację PD.
W FunCorp, podobnie jak w innych firmach, istnieje honorowa rola dyżurnego. Przechodzi ona z inżyniera do inżyniera raz dziennie. Istnieją także tzw. pierwsza i druga linia reakcji na alerty z PagerDuty. Powiedzmy, że przychodzi alert o wysokim priorytecie, i jeśli po 10 minutach od telefonu do dyżurnego z pierwszej linii nie ma reakcji (tzn. nie został on oznaczony jako acknowledged lub resolved), telefon przechodzi do drugiego dyżurnego inżyniera. To wszystko konfiguruje się w samym PagerDuty poprzez polityki eskalacji.
Jeśli drugi dyżurny również nie odpowiada, powiadomienie wraca z powrotem do głównego dyżurnego.
W ten sposób żaden przychodzący alert o wysokim priorytecie nie może pozostać nieprzetworzony.
Teraz przyjrzyjmy się, skąd mogą pochodzić incydenty.
Jakie integracje wykorzystujemy?
W PD napływa wiele różnorodnych incydentów z różnych usług. Obecnie mamy około 25 takich usług, a do ich obsługi wykorzystujemy kilka gotowych integracji.
- Prometheus
Podstawowym systemem zbierania metryk jest Prometheus. O nim wiele już napisano na Habrze, powiem tylko, że mamy ich kilka do różnych środowisk: jeden zbiera metryki z wirtualek i dockerów, inny - z usług Amazona, trzeci - z "fizycznych maszyn". W głównej mierze jako eksporter metryk używany jest Telegraf.
Tutaj też, myślę, wszystko jasne z nazwy. Ta integracja służy do wysyłania powiadomień z niektórych skryptów, wykonywanych według harmonogramu. PD daje wam pewny adres, na który wysyłacie wiadomości. Przy tworzeniu usługi z taką integracją możecie ustawić priorytety, w jakiej kolejności będą przetwarzane przychodzące incydenty, jak dokładnie tworzyć alert (na każdą przychodzącą wiadomość, na przychodzącą wiadomość + pewną regułę itd.).
- Slack
Moim zdaniem, to bardzo interesująca integracja. Zdarzają się sytuacje, gdy coś się dzieje, ale nie obejmuje to incydentów. Dlatego dodaliśmy integrację z Slackiem do tworzenia incydentów. T. j. w korporacyjnym Slacku można napisać /callofduty все тормозит и скоро сломается a PD to przetworzy i wyśle incydent do dyżurnego inżyniera.
Zróbmy:
Widzimy:
- API
Integracja przez HTTP. Tutaj, tak naprawdę, nie ma nic specjalnie ciekawego, po prostu zapytanie POST z ciałem w formacie JSON. Na przykład, z interesujących rzeczy: używamy jej do zewnętrznego monitorowania za pomocą . Ta usługa sprawdza dostępność naszych stron z różnych punktów na świecie. W przypadku, gdy otrzymujemy nieakceptowalny kod odpowiedzi (np. 502), tworzony jest incydent, a następnie wszystko idzie zgodnie z opisanym wcześniej ciągiem. W StatusCake istnieje możliwość monitorowania wewnętrznych adresów URL, wygasania certyfikatu SSL lub domeny.
- LibreNMS
To kolejny system monitorowania, więcej o nim można przeczytać na ich stronie . Dzięki niemu monitorujemy interfejsy sieciowe i iDRAC z serwerów.
Były również takie integracje jak Datadog, CloudWatch. Więcej o tym, co się z nimi stało, można zobaczyć .
Wizualizacja
Podstawowym systemem informowania o incydencie jest Slack. W specjalnym czacie zapisywane są wszystkie przychodzące incydenty PD, a jeśli zmienia się ich status, również jest to widoczne w czacie.
Kiedy pojawiła się możliwość wyświetlania przydatnych danych na monitorach wiszących na suficie, nagle zrozumieliśmy, że w naszym dziale DevOps nie mamy nic, co moglibyśmy na nich pokazać. Istnieje wspaniała Grafana, ale nie obejmuje wszystkiego, a pracownicy reagują na alerty, a nie na wykresy.
Po dokładnych, ale bezskutecznych poszukiwaniach na GitHubie zwięzłej i informacyjnej "tablicy" dla PD, postanowiliśmy napisać własną — tylko z tym, co jest nam potrzebne. Choć początkowo pojawił się pomysł, aby wyświetlić na ekranie sam interfejs PD, wyglądało to jeszcze bardziej nieporęcznie.
Aby ją napisać, wystarczy uzyskać klucz od PD z prawami tylko do odczytu.
Oto, co udało nam się osiągnąć:
Na ekranie wyświetlane są aktualne otwarte incydenty, imię obecnego inżyniera dyżurnego z wybranego harmonogramu oraz czas bez incydentu wysokiego priorytetu (panel z incydentem wysokiego priorytetu będzie wyróżniony na czerwono).
.
W rezultacie otrzymaliśmy wygodny pulpit nawigacyjny do przeglądania wszystkich naszych incydentów. Będę glad, jeśli nasze doświadczenie przyda się któremuś z was.
Źródło: habr.com
