System obsługi dokumentacji w naszym banku stale się rozwija i skaluje, a wymagania dotyczące szybkości i odporności na awarie tylko rosną. W pewnym momencie utrzymanie LMS bez skutecznego scentralizowanego monitorowania stało się zbyt ryzykowne. Aby zabezpieczyć procesy biznesowe w VTB i uprościć pracę administratorów, wdrożyliśmy rozwiązanie oparte na stosie otwartych technologii. Za jego pomocą możemy proaktywnie reagować na incydenty, zapobiegając potencjalnym problemom. Poniżej fragmentu znajduje się opowieść o naszych doświadczeniach w korzystaniu z darmowego oprogramowania do monitorowania dużych systemów biznesowych.
Po co monitorować swój system zarządzania dokumentami?
Od 2005 roku obsługą dokumentacji w VTB Banku „zarządza” system CompanyMedia. W LMS pracuje ponad 60 tysięcy użytkowników, którzy co miesiąc tworzą ponad milion nowych dokumentów. Nasze serwery muszą działać 24 godziny na dobę: niemal w każdej chwili w systemie jest podłączonych 2500–3000 osób, które są połączone na terenie całego kraju, od Pietropawłowska Kamczackiego po Kaliningrad. Każda sekunda działania LMS to 10–15 zmian.
Aby mieć pewność, że system dokładnie wykonuje przypisane mu zadania, wdrożyliśmy odporną na awarie infrastrukturę wykorzystującą serwery proxy, równoważenie żądań, ochronę informacji, wyszukiwanie pełnotekstowe, ścieżki integracji i tworzenie kopii zapasowych. Wsparcie i administrowanie projektem tej skali wymaga ogromnych zasobów. Administratorzy monitorują podstawowe informacje o działaniu serwera, obciążeniu pamięci RAM, czasie procesora, podsystemie we/wy itd. przez całą dobę. Ale poza tym potrzebne są bardziej subtelne analizy:
- obliczanie czasu poświęconego na realizację scenariuszy biznesowych;
- monitorowanie dynamiki pracy systemu i jego obciążenia;
- poszukiwanie odstępstw w elementach systemu od zatwierdzonych wymagań niefunkcjonalnych.
11 lat po wprowadzeniu LMS kwestia proaktywnego reagowania na różnego rodzaju błędy stała się szczególnie dotkliwa. Zarząd banku zdał sobie sprawę, że praca bez monitorów i konsoli życia systemu to igranie z ogniem: najmniejsza awaria w systemie biznesowym na tym poziomie może skutkować wielomilionowymi stratami.
W 2016 roku rozpoczęliśmy wprowadzanie narzędzi pozwalających na szybką identyfikację problemów w funkcjonowaniu LMS, w tym monitorowanie interesujących nas parametrów w czasie rzeczywistym. Wcześniej zastosowany system monitorowania został wdrożony i przetestowany w ramach infrastruktury firmy InterTrust.
Jak to się wszystko zaczęło
Dziś scentralizowany system monitorowania aplikacji VTB LMS, oparty na oprogramowaniu open source, pomaga zapobiegać większości błędów związanych z obiegiem dokumentów, szybko i trafnie klasyfikować problemy oraz szybko reagować na wszelkie zdarzenia. Zawiera dwa podsystemy:
- do monitorowania infrastruktury informatycznej usług systemowych;
- monitorowanie występowania błędów w działaniu LMS.
Wszystko zaczęło się od jednej bezpłatnej aplikacji monitorującej. Po przejrzeniu kilku opcji zdecydowaliśmy się na Zabbix – darmowe oprogramowanie, które pierwotnie zostało napisane dla usług i sprzętu bankowego. Ten internetowy system PHP, który może przechowywać dane w MySQL, PostgreSQL, SQLite lub Oracle Database, idealnie wpasował się w nasze potrzeby.
Zabbix uruchamia swoich agentów na każdym serwerze i gromadzi w czasie rzeczywistym informacje o interesujących Cię wskaźnikach w jednej bazie danych. Korzystając z aplikacji, wygodnie jest zbierać dane o obciążeniu procesorów i pamięci RAM, wykorzystaniu sieci i innych komponentów, sprawdzać dostępność i reakcję standardowych usług (SMTP lub HTTP), uruchamiać programy zewnętrzne oraz wspierać monitorowanie poprzez SNMP.
Po wdrożeniu Zabbixa skonfigurowaliśmy standardowe metryki sprzętu i na początku to wystarczyło. Ale VTB SDO stale się rozwija i rośnie: w 2016 roku zauważalnie wzrosła liczba serwerów, pojawiły się procesy migracyjne, do systemu dołączył Bank Moskwy, VTB Capital i VTB24. Nie ma już wystarczającej liczby standardowych wskaźników i nauczyliśmy Zabbixa śledzić informacje o obecności kolejek na każdym z woluminów podłączonych do serwera (od razu po uruchomieniu Zabbix odzwierciedla tylko ogólną kolejkę dyskową), a także czas potrzebny aby zakończyć określoną procedurę.
Dodatkowo wyposażyliśmy system w wiele wyzwalaczy – warunków wysłania powiadomienia do administratora (wiadomość w Telegramie, SMS na numer telefonu lub e-mail). Wyzwalacze można skonfigurować dla dowolnego zestawu parametrów. Na przykład możesz określić określony procent wolnego miejsca na dysku, a system powiadomi administratora o osiągnięciu określonego progu lub poinformuje, jeśli procedura w tle trwa dłużej niż zwykle.
Łączność Java i wizualizacja danych
Znacząco rozszerzyliśmy zakres analizowanych danych, ale wkrótce to nie wystarczyło do skutecznego monitorowania. Wykorzystując fakt, że LMS CompanyMedia jest aplikacją Java, połączyliśmy się z wirtualną maszyną Java za pośrednictwem interfejsu JMX i mogliśmy bezpośrednio pobrać metryki Java. I to nie tylko standardowe parametry istotnej aktywności Java, takie jak intensywność pracy GC czy zużycie sterty, ale także konkretne testy związane bezpośrednio z wykonywalnym kodem aplikacji.
W 2017 roku, około rok po wdrożeniu systemu monitorowania, stało się jasne, że aby normalnie pracować z kolosalną ilością danych zgromadzonych w Zabbixie, nie wystarczyła wizualizacja – skomplikowane ekrany. Najlepszym rozwiązaniem tego problemu okazało się ponownie darmowe oprogramowanie – Grafana, wygodny dashboard do metryk, pozwalający agregować wszystkie dane na jednym ekranie.
Interfejs Grafany jest interaktywny, przypominający system OLAP. Podsystem wyświetla dane otrzymane przez Zabbix na jednym ekranie, prezentując je w formie łatwych do analizy wykresów i diagramów. Administrator może z łatwością dostosować potrzebne mu plasterki.
Monitorowanie i zapobiegawcze usuwanie błędów w systemie LMS
Platforma oprogramowania typu open source ELK pomaga filtrować i analizować informacje otrzymane podczas monitorowania. Ten produkt open source składa się z trzech potężnych narzędzi do gromadzenia, przechowywania i analizowania danych: Elasticsearch, Logstash i Kibana. Implementacja tego podsystemu pozwala w szczególności zobaczyć w czasie rzeczywistym, ile błędów wystąpiło w systemie, na jakich serwerach i czy błędy te się powtarzają.
Teraz administrator może wykryć problem na wczesnym etapie, jeszcze zanim napotka go użytkownik. Takie proaktywne monitorowanie pozwala zapobiegać awariom systemu poprzez terminową eliminację błędów. Ponadto możemy zrozumieć, jak zmieniło się zachowanie systemu po aktualizacji, a także wykryć nowe problemy, jeśli się pojawią.
Monitorowanie operacji biznesowych
Oprócz podstawowych funkcji monitorowania zużycia zasobów, system posiada możliwość analizowania i kontrolowania operacji biznesowych.
Monitorowanie całkowitego czasu realizacji operacji biznesowych pozwala na identyfikację nowych czynników i zrozumienie ich wpływu na działanie systemu.
Monitorowanie czasu realizacji żądań dla każdej usługi biznesowej pozwala wykryć operacje odbiegające od normy.
Powyższy zrzut ekranu jest przykładem monitorowania zadania w tle pod kątem jego odchyleń od normy.
Lista kontrolowanych zadań pod kątem ich aktywności na konkretnym serwerze pozwala na identyfikację błędów – w tym powielania wykonywania zadań – na wszystkich serwerach.
Monitorowane są także trendy w czasie realizacji procedur w tle.
System rośnie, rozwija się i pomaga radzić sobie z problemami
Dzięki wdrożeniu opisywanego systemu monitorowanie pracy serwerów LMS zostało znacznie uproszczone. Niemniej jednak od czasu do czasu pojawiają się różnego rodzaju konflikty, wpływające na szybkość przepływu dokumentów i powodujące skargi użytkowników. Zrozumieliśmy więc, że konieczna jest kontrola zachowania samej aplikacji, a nie tylko serwerów.
Aby rozwiązać ten problem, do systemu monitorującego poprzez API podłączony został balanser, który współpracuje z klastrem serwerów aplikacji. Dzięki temu administrator może zobaczyć, ile czasu potrzebuje serwer, aby odpowiedzieć na każde żądanie użytkownika.
Do analizy udostępniono dane o czasach odpowiedzi serwerów, co umożliwiło powiązanie spowolnienia LMS-a z procesami zachodzącymi na serwerze. W szczególności pojawiła się interesująca sytuacja: serwer działa wolno, chociaż w tej chwili nie jest obciążony. Analizując anomalię odkryliśmy odchylenia w działaniu Java Garbage Collector. Ostatecznie okazało się, że to nieprawidłowe działanie tej usługi doprowadziło do tej sytuacji. Przejmując kontrolę nad Garbage Collector Java, całkowicie wyeliminowaliśmy problem.
W ten sposób wolne oprogramowanie pomaga rozwijać się i rozwijać system zarządzania dokumentami w branży bankowej. Poruszyliśmy jedynie główne zagadnienia związane z systemem monitoringu VTB SDO. Jeśli interesują Cię szczegóły, zapytaj w komentarzach, chętnie podzielimy się z Tobą naszymi doświadczeniami.
Źródło: www.habr.com