Jaka jest dobra praktyka rejestrowania dla zadań rozproszonych?


14

Mam następujące ustawienie:

Utwórz wielu pracowników, wykonaj obliczenia i zakończ je po zakończeniu obliczeń.

Tak więc za każdym razem będzie to inna instancja uruchamiająca zadanie, więc każdy host będzie miał własny plik dziennika, co spowoduje powstanie ogromnej listy plików.

Czy to dobra praktyka? Jeśli nie, jaki byłby lepszy sposób na zarejestrowanie przetwarzania zadania w tym konkretnym przypadku użycia?

PS: Moja infrastruktura jest pozbawiona serwerów. Na razie loguję się do (AWS) CloudWatch. Ale proszę odpowiedzieć na pytanie niezależnie od AWS i jak najbardziej odpowiadać konfiguracji bez serwera.

Odpowiedzi:


12

„Bezserwerowy” oznacza po prostu, że masz stosunkowo proste mikrousługi, zazwyczaj tylko małą aplikację internetową lub pojedynczą funkcję, która jest automatycznie połączona z interfejsem REST. Obowiązują te same koncepcje, jak w przypadku bardziej tradycyjnych usług internetowych: zwykle niektóre kombinacje zdalnych programów zapisujących syslog i ElasticSearch.

Sieciowy lub zdalny syslog istnieje już od dłuższego czasu i ma dość solidny zestaw narzędzi. Będziesz musiał uruchomić centralny serwer (serwery) syslog, ale protokół jest bardzo prosty i istnieją biblioteki czystych klientów w każdym języku, którego można używać do wysyłania dzienników. Jednym z powszechnych problemów ze zdalnym syslogiem jest to, że tradycyjnie opierał się on na UDP. Oznacza to, że pod dużym obciążeniem niektóre komunikaty dziennika mogą zostać utracone. Może to być dobra rzecz, pomagająca uniknąć przeciążenia kaskadowego, ale należy o tym pamiętać. Niektóre nowsze demony syslog obsługują również protokół oparty na TCP, ale obsługa klienta jest mniej ujednolicona, więc po prostu przeprowadź badania.

Nowszym, ale bardzo popularnym jest logowanie do ElasticSearch. Jest to szczególnie przydatne ze względu na pulpit nawigacyjny Kibana i podświetlenie Logstash (często nazywane ELK, ElasticSearch + Logstash + Kibana). Amazon oferuje nawet hostowaną opcję ElasticSearch, co nieco ułatwia rozpoczęcie pracy. ES używa stosunkowo prostego interfejsu API REST, więc każdy język z klientem HTTP (czytaj: wszystkie z nich) powinien być w porządku z logowaniem do ES, ale upewnij się, że jesteś ostrożny w blokowaniu operacji sieciowych w przypadku częściowych awarii systemu (tj. Upewnij się, że twój aplikacja nie utknie w wywołaniu logowania, które nigdy się nie powiedzie i przestanie obsługiwać żądania użytkowników).

Bardziej złożone topologie rejestrowania są ograniczone tylko twoją wyobraźnią, choć w dzisiejszych czasach będziesz dużo korzystać z bazy danych / kolejki Kafka / cokolwiek chcesz zadzwonić jako punktu połączenia w bardzo złożonych systemach dystrybucji logów .

Po stronie „bezserwerowej” zazwyczaj chcesz zintegrować się z tymi systemami bezpośrednio na poziomie sieci, więc wysyłaj dane dziennika bezpośrednio do syslog lub ES z usługi / funkcji, zamiast pisać do plików lokalnych (choć może echo tych plików również do lokalnego debugowania i programowania).


6

Ta odpowiedź dotyczy bardziej kwestii skalowalności - jeśli liczba pracowników może być wysoka i / lub wielu z nich może jednocześnie generować dzienniki z dużą szybkością.

Tak, dobrą praktyką jest używanie wielu plików dziennika jednocześnie.

Próba połączenia w jeden dziennik pliku dziennika z wielu pracowników w czasie rzeczywistym spowoduje problemy:

  • użycie mechanizmów blokowania, aby zapobiec utracie wiadomości, spowolni pracowników
  • komunikaty dziennika mogą pojawiać się poza kolejnością w połączonym pliku dziennika
  • scentralizowana funkcja rejestrowania, która łączy dzienniki, może być przeciążona z powodu ograniczonej prędkości zapisu, wiadomości zostaną utracone

Fragmentowanie plików dziennika (przy użyciu wielu aktywnych plików dziennika jednocześnie) jest techniką stosowaną przez niektórych dostawców hostingu oferujących wysokiej wydajności, skalowalne scentralizowane usługi rejestrowania. Na przykład podczas eksportowania dzienników do plików Google StackDriver Logging tworzy wiele dzielonych plików dziennika. Z wpisów w dzienniku w Google Cloud Storage :

Podczas eksportowania dzienników do segmentu Cloud Storage, Stackdriver Logging zapisuje zestaw plików do segmentu. Pliki są zorganizowane w hierarchie katalogów według typu dziennika i daty. Typ dziennika może być nazwą prostą jak sysloglub nazwą złożoną jak appengine.googleapis.com/request_log. Gdyby te dzienniki były przechowywane w wiadrze o nazwie my-gcs-bucket, katalogi zostałyby nazwane jak w poniższym przykładzie:

my-gcs-bucket/syslog/YYYY/MM/DD/
my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/

Pojedynczy segment może zawierać dzienniki z wielu typów dzienników.

Katalogi liści ( DD/) zawierają wiele plików, z których każdy zawiera wyeksportowane wpisy dziennika przez czas określony w nazwie pliku. Pliki są dzielone, a ich nazwy kończą się numerem odłamka Snlub An(n = 0, 1, 2, ...). Na przykład tutaj są dwa pliki, które mogą być przechowywane w directory my-gcs-bucket/syslog/2015/01/13/:

08:00:00_08:59:59_S0.json
08:00:00_08:59:59_S1.json

Te dwa pliki razem zawierają syslogwpisy dziennika dla wszystkich instancji w godzinie rozpoczynającej się 0800 UTC. Aby uzyskać wszystkie wpisy dziennika, należy przeczytać wszystkie fragmenty dla każdego okresu - w tym przypadku fragmenty pliku 0 i 1. Liczba zapisanych fragmentów pliku może się zmieniać dla każdego przedziału czasu, w zależności od liczby wpisów dziennika.

Takie wysokowydajne usługi rejestrowania mogą również stanowić alternatywę dla logowania do plików, dlatego można całkowicie uniknąć zarządzania plikami dziennika, jeśli jest to interesujące:

Wreszcie - jeśli scalanie pliku dziennika w czasie rzeczywistym nie jest wymagane, posiadanie wielu plików dziennika może pomóc w zarządzaniu dziennikiem w trybie offline:

  • łatwe do opracowania progresywne tworzenie kopii zapasowych dziennika, kompresja, archiwizacja i ewentualne schematy usuwania
  • możliwe jest równoległe przetwarzanie wielu zestawów dzienników (plików dziennika), zmniejszając / unikając efektu wąskiego gardła
  • nie jest konieczne dzielenie i ponowne zapisywanie plików
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.