Page tree
Skip to end of metadata
Go to start of metadata

Katalog Aplikacji posiada szereg skryptów działających w tle, zajmujących się badaniem stanu modułów aplikacji zainstalowanych na klastrach oraz poprawności działania aplikacji na tychże klastrach. Odpowiednie informacje Katalog Aplikacji uzyskuje z systemu Nagios. Częstotliwość napływania tej informacji do Katalogu Aplikacji jest uzależniona od częstotliwości wykonywania testów aplikacji przez Nagiosa (obecnie jest to dwa razy na dobę, zarówno na produkcyjnej instancji w Cyfronecie, jak i testowej w PCSS).

Klastry i instancje aplikacji, dla których istnieją aktualne przestoje są pomijane. Ewentualne informacje o niepowodzeniach testów są ignorowane.

Monitorowanie modułów

Katalog Aplikacji analizuje obecność modułów na klastrach. Interesują go tylko moduły znajdujące się w ścieżce rozpoczynającej się od plgrid/apps, plgrid/libs i plgrid/tools. Moduły znajdujące się w innych lokalizacjach nie są brane pod uwagę. Dla wykrytych modułów tworzone są automatycznie instancje aplikacji i jeśli potrzeba także wersje aplikacji lub same aplikacje.

(warning) Administratorzy będą mieć potrzebę dodawania nowych aplikacji (Administratora Katalogu Aplikacji - AKA), wersji (Globalny Opiekun Aplikacji - GOA) i instancji (Lokalny Opiekun Aplikacji - LOA) raczej w rzadkich przypadkach. Większość pracy powinien za nich wykonać Katalog Aplikacji.

 

Dla instancji aplikacji zgromadzonych w bazie Katalogu Aplikacji odbywa się także sprawdzanie czy na klastrze istnieją odpowiadające im moduły. W przypadku gdy takiego modułu brakuje informowani są administratorzy opiekunowie i mają możliwość podjęcia odpowiedniej reakcji. Jeżeli moduł zniknął z klastra przypadkowo, na skutek błędu, po przywróceniu go na klastrze Katalog Aplikacji wykryje tę sytuację i przestanie zgłaszać problemy. Jeżeli natomiast moduł zniknął na skutek przemyślanej decyzji administratora i instancja aplikacji jest rzeczywiście przewidziana do wycofania, to należy to odpowiednio zaznaczyć w Katalogu Aplikacji. LOA może wycofać instancję aplikacji. Wycofanie wersji znajduje się w kompetencjach GOA, a wycofanie całej aplikacji AKA. Możliwe jest także porzucanie aplikacji/wersji/instancji, na zasadach podobnych jak w przypadku wycofywania. Należy z tego korzystać jeżeli jakiś moduł pojawił się na klastrze na skutek błędu, jest to ewidentna pomyłka i należy z niej się wycofać, nie pokazując tego faktu użytkownikom. 

(warning) Usuwać aplikacje, wersje i instancje mogą tylko AKA, GOA i LOA, każdy na przewidzianym dla siebie poziomie. Powinni jednak podejmować takie akcje tylko w wyjątkowych przypadkach, jeśli aplikacje, wersje, bądź instancje zostały dodane do Katalogu Aplikacji pomyłkowo i nie warto zostawiać po nich śladów w systemie. Aplikacje wycofane z oferty PL-Gridu nie powinny być usuwane z systemu, a jedynie oznaczane jako wycofane w Katalogu Aplikacji. Pomyłki, przy których chcemy by zostały w systemie można oznaczać jako porzucone.

 

Dla aplikacji/wersji/instancji będących w trakcie zmian ścieżek modułów zainicjowanych przez GOA (aplikacje i wersje) lub LOA (instancje) monitoring analizuje wyniki testów modułów i automatycznie wykrywa sytuacje, że oczekiwane zmiany zostały wprowadzone w życie. Wówczas kasuje z systemu informacje o zmianach.

 

O istotnych sytuacjach administratorzy i opiekunowie powiadamiani są mailowo. Jest także możliwość śledzenia powiadomień w Dashboardzie w sekcji Powiadomienia.

Monitorowanie działania aplikacji

Monitorowaniem instancji aplikacji na klastrach zajmuje się system Nagios. Katalog Aplikacji analizuje efekty tego monitorowania i tworzy na tej podstawie odpowiedni obraz aplikacji, wersji i instancji we własnej bazie. W przypadku stwierdzenia problemów z jakąś aplikacją generowane są powiadomienia mailowe. Administratorzy i opiekunowie mogą wówczas podjąć jakieś kroki. Powiadomienia można także śledzić w Dashboardzie.

Statusy wykonywanych testów można przeglądać w Dashboardzie w sekcji Status testów.

Ze statusami monitorowania instancji aplikacji można się także zapoznawać w zakładce Monitoring na stronie aplikacji/wersji/instancji. Tam w formie tabelarycznej przedstawione jest jakie instancje aplikacji są dostępne na jakich klastrach. Za pomocą ikony określony jest ich aktualny status.

Uwagi

Raz na dobę Katalog Aplikacji sprawdza czy posiada aktualną informację. Jeżeli w trakcie tej analizy okaże się, że testy istnienia modułów albo testy działania instancji aplikacji na klastrach są starsze niż konfigurowalna liczba godzin (na razie ustalona roboczo na 26h) to w Dashboardzie w sekcji Powiadomienia pojawią się informacje na ten temat.

Atrybuty Testowana oraz Monitorowana

Atrybut Monitorowana jest to fizyczny atrybut, który można ustawić dla aplikacji, wersji oraz instancji. Atrybut Testowana jest atrybutem wyliczanym dynamicznie, na podstawie wartości atrybutu Monitorowana danego obiektu oraz obiektów dla niego nadrzędnych i/lub podrzędnych.

Atrybut Monitorowana można ustawić na jedną z dwóch wartości: Tak lub Nie.

Atrybut Testowana, jest określany następująco:

  • Dla instancji – wartość Tak, jeśli dana instancja i nadrzędne wersja i aplikacja są oznaczone jako Monitorowane. Wartość Nie w przeciwnym wypadku.
  • Dla wersji – wartość Nie, jeśli dana wersja lub nadrzędna aplikacja nie są monitorowane. Ostateczna wartość jest określana na podstawie wartości atrybutu Monitorowana podrzędnych instancji: jeśli żadne nie są monitorowane wartość jest Nie, jeśli wszystkie są monitorowane wartość jest Tak, w pozostałych wypadkach wartość jest Częściowo
  • Dla aplikacji – wartość Nie, jeśli dana aplikacja nie jest monitorowana. Ostateczna wartość jest określana na podstawie wartości atrybutu Monitorowana podrzędnych instancji: jeśli żadne nie są monitorowane wartość jest Nie, jeśli wszystkie są monitorowane wartość jest Tak, w pozostałych wypadkach wartość jest Częściowo

Zdefiniowane tutaj zasady są stosowane również przy określaniu stanu aplikacji, wersji i instancji. Przy ustalaniu stanu dla aplikacji, które oznaczone są jako testowane, pod uwagę brane są wyniki ostatniego testu działania aplikacji. Jest to specjalnie zdefiniowany test/skrypt w Nagiosie uruchamiający tę aplikację, testy te istnieją jedynie dla wybranych aplikacji. Aplikacje, dla których wartość atrybutu Testowana to Tak i ostatni test poprawności działania zakończył się powodzeniem prezentowane są jako Dostępne. Aplikacje, dla których wartość atrybutu Testowana to Nie prezentowane są jako Nietestowane. Dodatkowo, przy określaniu stanu aplikacji bezwzględnie pod uwagę brany jest wynik testu obecności modułu na maszynach roboczych poszczególnych klastrów. Jeśli taki test zakończy się niepowodzeniem – aplikacja nie jest dostępna w podanej ścieżce modułu na danym klastrze – aplikacja jest prezentowana jako Niedostępna.

Tak określone zasady pozwalają hierarchicznie zmieniać prezentowany stan aplikacji. Ustawiając atrybut Monitorowana na Nie dla wybranej wersji aplikacji, wszystkie jej instancje będą traktowane i prezentowane jako nietestowane.

  • No labels