Im bardziej skomplikowany system, tym bardziej zostaje on zarośnięty wszelkiego rodzaju alertami. I trzeba na te same alerty reagować, agregować je i wizualizować. Myślę, że jest to sytuacja znana wielu osobom aż do poziomu zdenerwowania.
Rozwiązanie, które zostanie omówione, nie jest najbardziej nieoczekiwane, ale wyszukiwanie nie zwraca pełnego artykułu na ten temat.
Dlatego zdecydowałem się podzielić doświadczeniem FunCorp i porozmawiać o tym, jak zorganizowany jest proces dyżurowy, kto dzwoni, dlaczego i jak na to wszystko spojrzeć.
Co to jest PagerDuty?
Aby więc rozwiązać wszystkie te problemy, zaczęliśmy szukać wygodnego narzędzia. Po krótkich poszukiwaniach wybraliśmy PagerDuty. PD wydawało nam się dość kompletnym i zwięzłym rozwiązaniem z dużą liczbą integracji i ustawień. Jaka ona jest?
Krótko mówiąc, PagerDuty to platforma przetwarzania incydentów, która może przetwarzać przychodzące incydenty poprzez różne integracje, konfigurować polecenia dyżuru, a następnie ostrzegać inżyniera dyżurującego w zależności od poziomu zdarzenia (na wysokim poziomie – wezwanie, na niskim poziomie – push z aplikacji/SMS).
Kim jest oficer dyżurny?
Jest to prawdopodobnie pierwsze miejsce, w którym należy rozpocząć konfigurowanie PD.
W FunCorp, podobnie jak w innych firmach, istnieje honorowe stanowisko oficera dyżurnego. Jest przekazywany od inżyniera do inżyniera raz dziennie. Istnieje tak zwana pierwsza i druga linia reakcji na alert z PagerDuty. Załóżmy, że nadejdzie alert o wysokim priorytecie i jeśli po 10 minutach od wezwania do oficera dyżurnego z pierwszej linii nie będzie na niego reakcji (tzn. inżynier dyżurny. Można to skonfigurować w samym PagerDuty poprzez Zasady eskalacji.
Jeżeli drugi oficer dyżurny nie zareaguje, powiadomienie wraca do Główny do oficera dyżurnego.
Dlatego żaden przychodzący alert o wysokim priorytecie nie może pozostać nieprzetworzony.
Zobaczmy teraz, skąd mogą pochodzić incydenty.
Z jakich integracji korzystamy?
PD otrzymuje wiele różnych zgłoszeń od różnych służb. Obecnie mamy około 25 takich usług i do ich obsługi wykorzystujemy gotowe integracje.
- Prometheus
Głównym systemem zbierania metryk jest Prometheus. Wiele już o tym napisano na Habré, powiem tylko, że mamy ich kilka dla różnych środowisk: jeden zbiera metryki z maszyn wirtualnych i dokerów, drugi z usług Amazon, trzeci z maszyn sprzętowych. Telegraf jest używany głównie jako eksporter metryk.
Myślę, że tutaj także wszystko jest jasne z tytułu. Integracja ta służy do wysyłania powiadomień z niektórych skryptów wykonywanych przez cron. PD podaje Ci konkretny adres, na który wysyłasz listy. Tworząc usługę z taką integracją, możesz ustawić priorytety, w jakiej kolejności będą przetwarzane przychodzące zdarzenia, jak dokładnie utworzyć alert (dla każdego przychodzącego listu, dla przychodzącego pisma + określonej reguły itp.).
- Slack
Moim zdaniem bardzo ciekawa integracja. Są chwile, kiedy coś się dzieje, ale nie jest to objęte incydentami. Dlatego dodaliśmy integrację ze Slacka, aby stworzyć incydent. Oznacza to, że możesz pisać do korporacyjnego Slacka /callofduty wszystko działa powoli i wkrótce się zepsuje PD zajmie się tym i wyśle incydent inżynierowi dyżurnemu.
My robimy:
Widzimy:
- API
Integracja HTTP. Tak naprawdę nie ma tu nic szczególnie interesującego, jedynie żądanie POST z treścią w formacie JSON. Na przykład coś ciekawego: używamy go do zewnętrznego monitorowania za pomocą . Usługa ta sprawdza dostępność naszych stron z różnych części świata. W przypadku gdy otrzymamy nieakceptowalny kod odpowiedzi (np. 502) tworzone jest zdarzenie i dalej wszystko przebiega zgodnie z opisanym powyżej łańcuchem. Sam StatusCake ma możliwość monitorowania wewnętrznych adresów URL, certyfikatu SSL czy wygaśnięcia domeny.
- DarmoweNMS
To już kolejny system monitoringu, więcej o nim można przeczytać na ich stronie internetowej . Za jego pomocą monitorujemy interfejsy sieciowe i iDRAC z serwerów.
Nie zabrakło także integracji takich jak Datadog, CloudWatch. Możesz zobaczyć więcej na temat tego, co się z nimi stało .
Wizualizacja
Głównym systemem zgłaszania incydentów jest Slack. Wszystkie zdarzenia wpływające do PD są zapisywane na specjalnym czacie, a jeśli ich status ulegnie zmianie, jest to również wyświetlane na czacie.
Kiedy pojawiła się możliwość wyświetlenia przydatnych danych na ekranach podwieszonych pod sufitem monitorów, nagle zdaliśmy sobie sprawę, że my (w dziale devops) nie mamy na nich nic do wyświetlenia. Jest wspaniała Grafana, ale to nie wszystko, a pracownicy reagują na alerty, a nie na wykresy.
Po dokładnych, ale nieudanych poszukiwaniach w GitHubie zwięzłej i informacyjnej „tablicy” dla PD, zdecydowaliśmy się napisać własną – zawierającą tylko to, czego potrzebowaliśmy. Choć początkowo pojawił się pomysł, aby wyświetlić sam interfejs PD, wyglądało to jeszcze bardziej niewygodnie.
Aby go napisać wystarczy uzyskać od PD klucz z uprawnieniami tylko do odczytu.
A oto co otrzymaliśmy:
Na ekranie wyświetlane są aktualnie otwarte zdarzenia, nazwisko dyżurującego inżyniera z wybranego harmonogramu oraz czas, w którym nie wystąpiło zdarzenie o wysokim priorytecie (panel ze zdarzeniem o wysokim priorytecie zostanie podświetlony na czerwono).
.
W efekcie otrzymaliśmy wygodny dashboard, na którym możemy przeglądać wszystkie nasze incydenty. Będzie mi miło, jeśli komuś z Państwa nasze doświadczenie się przyda.
Źródło: www.habr.com