Loki do scentralizowanego zarządzania logami w hostingu

Wyraźne rozdzielenie Loki, Alloy i Grafana

Centralne zarządzanie logami zaczyna się od systemów, które generują zdarzenia: hostów z systemem Linux, serwerów wirtualnych, kontenerów i aplikacji. To właśnie tam powstają na przykład wpisy dziennika systemu systemd, logi dostępu i błędów serwera Nginx oraz standardowe dane wyjściowe kontenerów Docker. Grafana Alloy odczytuje takie źródła, przetwarza je przed wysłaniem i przekazuje do Loki. Alloy pełni zatem rolę modułu zbierającego dane, a nie centralnego magazynu logów.

Grafana Loki przyjmuje dane logów, grupuje je i przechowuje na potrzeby późniejszych zapytań. Pamięć obiektowa może w tym przypadku przechowywać zarchiwizowane dane. Z kolei Grafana często zapewnia interfejs do funkcji Explore, pulpitów nawigacyjnych i alertów, ale z technicznego punktu widzenia nie jest częścią samego Loki. Takie rozdzielenie ułatwia jasne przypisanie odpowiedzialności w przypadku zmian, awarii i uprawnień dostępu.

W prostym przykładzie hostingu Alloy odczytuje na serwerze VPS dziennik systemd, pliki Nginx oraz logi kontenerów. Wysyła wybrane wiersze do Loki; administrator przegląda je następnie w Grafanie, zamiast logować się osobno na każdy host w celu wstępnej analizy błędów. Przed Loki powinien znajdować się serwer proxy odwrotny lub warstwa tożsamości, która zapewniałaby uwierzytelnianie, TLS, routing oraz, w razie potrzeby, przypisanie do klienta.

Centralna agregacja skraca ścieżki wyszukiwania, nie zastępuje jednak ani analizy przyczyn, ani procesów operacyjnych. Ochrona dostępu należy określić, kto ma prawo wglądu do poszczególnych danych; zasada minimalizacji danych decyduje już przed wysłaniem, które pola zostaną usunięte. Również koncepcja tworzenia kopii zapasowych i przywracania danych pozostaje odrębnym zadaniem: Loki ułatwia wyszukiwanie istniejących logów, ale sam w sobie nie gwarantuje ich ochrony, kompletności ani przechowywania zgodnego z przepisami prawa.

W praktyce więc wdrożenie Loki opłaca się dopiero po przeprowadzeniu inwentaryzacji źródeł: które logi pomagają w eksploatacji i rozwiązywaniu incydentów, które zawierają poufne informacje lub dane osobowe oraz kto potrzebuje do nich dostępu? Dopiero odpowiedzi na te pytania określają filtry, okres przechowywania i uprawnienia. Niesprawdzona centralizacja wszystkich logów systemu Linux powoduje jedynie przeniesienie poufnych informacji do magazynu, który jest łatwiejszy do przeszukiwania.

Zrozumieć strumienie, etykiety i LogQL

Loki nie organizuje przychodzących wierszy przede wszystkim w formie indeksu pełnotekstowego. Łączy je na podstawie identyfikatora klienta i zbioru etykiet w jeden Strumień razem. Same dane dziennika są przechowywane w postaci skompresowanych fragmentów (chunków); indeks łączy zestawy etykiet z tymi fragmentami. Dlatego podczas wyszukiwania Loki najpierw zawęża listę pasujących strumieni na podstawie etykiet, a następnie pobiera odpowiednie dane w celu ich dalszego filtrowania lub analizowania.

Etykiety powinny odzwierciedlać trwały, przejrzysty kontekst: na przykład env, service oraz przy stabilnych serwerach host. W środowiskach kontenerowych sensowne może być również stosowanie klastrów, przestrzeni nazw lub aplikacji. Każda unikalna kombinacja tworzy jednak strumień. Identyfikatory żądań, użytkowników i śladów, zmieniające się identyfikatory kontenerów lub adresy IP klientów generują bardzo wiele wartości i dlatego zazwyczaj nie powinny być umieszczane w etykietach.

W przypadku sporadycznych szczegółowych analiz takie dynamiczne dane pozostają w wierszu dziennika i są analizowane dopiero podczas zapytania, na przykład poprzez parsowanie JSON lub Logfmt. Często potrzebne dane kontekstowe o wysokiej kardynalności mogą być bardziej odpowiednie w postaci ustrukturyzowanych metadanych. Kluczowe znaczenie ma przetestowanie modelu danych na rzeczywistych źródłach przed wdrożeniem, zamiast niefiltrowanego oznaczania wszystkich dostępnych pól.

Zapytanie LogQL przeznaczone wyłącznie do odczytu, dotyczące błędów Nginx, może wyglądać następująco. Należy je wprowadzić np. w Grafana Explore lub LogCLI i zakłada, że wybrane etykiety zostały faktycznie przypisane podczas gromadzenia danych.

{env="prod", service="nginx"} |= " 500 "

Selektor przed potokiem najpierw ogranicza dane do strumieni produkcyjnych usługi Nginx; dopiero |= " 500 " wyszukaj tekst. Jakość zapytania zależy jednak od przedziału czasowego, objętości logów, opóźnień w pamięci masowej oraz struktury etykiet. Loki nie gwarantuje w związku z tym stałego czasu odpowiedzi. Krótkie przedziały czasowe oraz precyzyjne, stabilne selektory stanowią sensowny punkt wyjścia do stopniowej analizy.

Która architektura Loki nadaje się do hostingu

W przypadku pojedynczego serwera VPS, laboratorium lub niewielkich ilości logów zaleca się działanie monolityczne Często jest to najprostszy sposób na rozpoczęcie: proces Loki łączy w jedną całość wszystkie niezbędne komponenty. W dokumentacji tryb ten jest przeznaczony do eksperymentów oraz niewielkich wolumenów odczytu i zapisu, sięgających około 20 GB dziennie. Jest to wytyczna producenta dotycząca tego obszaru zastosowań, a nie gwarancja wydajności dla każdej struktury pamięci masowej, zapytań lub etykiet.

Jeśli wymagania dotyczące dostępności rosną, a nie ma potrzeby celowego skalowania poszczególnych ról Loki, można rozważyć monolityczny model działania o wysokiej dostępności. W przypadku bardzo dużych klastrów lub środowisk Kubernetes, w których komponenty mają być skalowane oddzielnie, przewidziano tryb mikrousług. Taka szczegółowość nie eliminuje jednak konieczności planowania: zwiększa liczbę elementów operacyjnych, a tym samym nakład pracy związany z diagnostyką i konserwacją.

Tryb Simple Scalable Deployment nie stanowi neutralnego kompromisu przy podejmowaniu nowych decyzji. Grafana uznała SSD za przestarzały i zapowiedziała jego usunięcie wraz z wprowadzeniem Loki 4.0. Kto dzisiaj rozpoczyna wdrażanie, powinien zatem rozważyć podejście monolityczne z odpowiednią dostępnością lub mikrousługi w oparciu o rzeczywiste potrzeby w zakresie skalowalności, zamiast planować architekturę przejściową w perspektywie długoterminowej.

Przy podejmowaniu decyzji nie liczą się tylko gigabajty generowane codziennie. Istotne są również szczytowe obciążenia podczas zapisu, liczba i kardynalność strumieni, wymagana separacja klientów, okres przechowywania danych, a także wiedza zespołu na temat Kubernetes i komponentów rozproszonych. Projekty z globalnie rozproszoną infrastrukturą i dostawą i tak wymagają wyraźnego rozróżnienia między centralnymi usługami operacyjnymi a komponentami brzegowymi; w tym kontekście warto również zapoznać się z artykułem na temat Hosting dla renderowania brzegowego i zdecentralizowanego dostarczania.

Zacznij od niewielkich zmian, jeśli źródła logów, etykiety i dostępy nie są jeszcze stabilnie zdefiniowane. Zmiana architektury powinna wynikać z zaobserwowanych wymagań, takich jak ukierunkowane skalowanie lub wyższa dostępność, a nie z ogólnych oczekiwań dotyczących przyszłego wzrostu. W ten sposób nakład pracy związany z Zarządzanie logami w porównaniu z korzyściami płynącymi z centralnej wyszukiwarki i obsługi zgłoszeń.

Bezpieczne gromadzenie logów systemu Linux za pomocą Alloy

Przed wdrożeniem należy sporządzić spis źródeł: które logi faktycznie pomagają w eksploatacji i rozwiązywaniu incydentów? Na serwerze WWW z systemem Linux są to często dziennik systemd, logi dostępu i błędów Nginx, PHP-FPM, zdarzenia SSH oraz zadania Cron. W przypadku kontenerów dochodzą do tego dane wyjściowe środowiska uruchomieniowego oraz protokoły specyficzne dla aplikacji. Równie ważna jest wstępna kontrola haseł, kluczy API, identyfikatorów sesji i danych osobowych; treści tego rodzaju nie mogą być przekazywane centralnie bez uprzedniej weryfikacji.

W przypadku nowych instalacji należy Grafana Alloy obsługiwany sposób gromadzenia i przekazywania danych. Nie należy już zakładać, że Promtail będzie standardowym rozwiązaniem: jego cykl życia zakończył się 2 marca 2026 r., a dokumentacja odsyła w kwestii migracji oraz nowych konfiguracji do Alloy lub innego obsługiwany klienta. Istniejąca instalacja Promtail wymaga zatem zaplanowanej migracji zamiast cichej aktualizacji.

Schemat konfiguracji pozostaje przejrzysty: źródło odczytuje pliki, dziennik lub logi kontenerów; opcjonalny moduł przetwarzania może odrzucać niepożądane wiersze lub przygotowywać pola; następnie przekazuje loki.write dane do Loki. Alloy udostępnia komponenty m.in. dla plików, dzienników systemd, Dockera, Kubernetes, Syslogu i zdarzeń systemu Windows. Wybór źródła zależy od tego, gdzie aplikacja niezawodnie wysyła swoje zdarzenia.

Szablon nie jest jeszcze konfiguracją gotową do wdrożenia. Uprawnienia do plików muszą zapewniać procesowi Alloy jedynie niezbędny dostęp do odczytu; dostęp do dziennika, adres docelowy, weryfikacja certyfikatu, TLS, buforowanie w przypadku zakłóceń sieciowych oraz sposób postępowania w przypadku awarii należy sprawdzić w zależności od konkretnej instalacji. Dane dostępowe i informacje o klientach nie powinny znajdować się we wspólnie udostępnianych plikach przykładowych. Zacznij od niewielkiej liczby źródeł, sprawdź zawartość i objętość, a dopiero potem rozszerz zakres gromadzenia danych.

Filtrowanie na poziomie agenta nie zmniejsza odpowiedzialności za źródło danych ani nie zastępuje systemu uprawnień. Zapobiega jednak przedostawaniu się znanych komunikatów debugowania lub jednoznacznie zidentyfikowanych informacji poufnych do centralnej bazy danych. W przypadku treści niezbędnych z punktu widzenia merytorycznego powinno być jasne, która usługa je wysyła, kto może je później odczytać oraz jak długo będą potrzebne.

Koncepcja marki i planowanie przed wprowadzeniem na rynek

A Koncepcja marki określa, w jakim stabilnym kontekście można znaleźć logi. W przypadku wielu hostów i środowisk odpowiednie są na przykład env, cluster, namespace, app, service oraz, jeśli odniesienie ma charakter trwały, nazwę hosta. Ich wartości powinny być ograniczone i przewidywalne. Każdy odrębny zbiór etykiet tworzy osobny strumień; w związku z tym model ma bezpośredni wpływ na wprowadzanie danych, indeksowanie i późniejsze zapytania.

Z kolei identyfikatory żądań, śladów i użytkowników, adresy IP klientów oraz dynamiczne identyfikatory kontenerów nie są odpowiednimi etykietami. Generują one zbyt wiele różnych wartości, a tym samym wiele małych strumieni. Informacje o wysokiej kardynalności można w razie potrzeby przekazywać jako ustrukturyzowane metadane. W przypadku sporadycznej analizy często bardziej sensowne jest pobieranie treści logów dopiero w momencie zapytania za pomocą json, logfmt, pattern lub regexp przetworzyć.

Tabela nie zawiera prognozy dotyczącej miejsca na dysku, lecz stanowi podstawę do podjęcia decyzji. Zwłaszcza okres przechowywania jest częścią planu, ponieważ nie można go wywnioskować na podstawie objętości logów: branżowe obowiązki dotyczące przechowywania, wymogi bezpieczeństwa i wytyczne dotyczące usuwania mogą się od siebie różnić. Możliwość odtworzenia danych stanowi również odrębny wymóg; automatyczne usuwanie przeterminowanych logów nie zastępuje koncepcji tworzenia kopii zapasowych ani planu przywracania danych.

Praktycznym pierwszym standardem może być na przykład env, service oraz host używać w przypadku klasycznych serwerów internetowych; platformy kontenerowe stanowią uzupełnienie tylko wtedy, gdy cluster oraz namespace, o ile rzeczywiście stosują je selektywnie podczas wyszukiwania błędów. Schemat ten powinien być uzgodniony z programistami i działem operacyjnym. Dodane później, niejednolite etykiety utrudniają porównywanie środowisk i sprawiają, że centralne wyszukiwanie staje się mniej wiarygodne.

Przy planowaniu liczy się nie tylko to, co da się uchwycić pod względem technicznym, ale także podział obowiązków. Jeden zespół powinien odpowiadać za źródła i filtry, a inny – w razie potrzeby – za przechowywanie danych i dostęp do nich. Dzięki temu widać, czy brakujące pole w formacie logu należy uzupełnić, potraktować jako ustrukturyzowane metadane, czy też celowo nie gromadzić.

Skuteczne zabezpieczanie klientów i dostępów

Loki może przetwarzać dane dziennika z uwzględnieniem podziału na klientów. Jeśli podział na klientów jest włączony, Loki oczekuje nagłówka dla każdego zapytania X-Scope-OrgID. Nagłówek ten nie stanowi jednak logowania ani dowodu uprawnień: w przeciwnym razie klient mógłby samodzielnie określić jego wartość. Loki nie zawiera pełnej warstwy uwierzytelniającej; zabezpieczenia i wymuszone przypisanie muszą nastąpić wcześniej.

Niezawodny proces rozpoczyna się od zaufanego serwera proxy odwrotnego lub warstwy tożsamości. Po pomyślnym zalogowaniu warstwa ta identyfikuje uprawnioną organizację, ustawia identyfikator klienta po stronie serwera, wymusza użycie protokołu TLS i przekazuje do Loki wyłącznie dozwolone żądania. Bezpośrednie punkty końcowe Loki dostępne z sieci ominęłyby tę kontrolę. Również operacje zapisu wykonywane przez agentów wymagają jednoznacznie ograniczonej tożsamości oraz zabezpieczonego kanału transmisji.

Koncepcja uprawnień określa, kto może odczytywać lub wprowadzać dane do logów. Nie zastępuje ona ani filtrowania informacji poufnych, ani kontroli ochrony danych: tokeny, identyfikatory sesji i dane osobowe mogą stanowić problem nawet w ramach prawidłowo przypisanej instancji klienta. Dlatego minimalizacja danych musi mieć zastosowanie już na etapie źródła i przetwarzania, podczas gdy uprawnienia ograniczają pozostały zbiór danych zgodnie z zadaniami i klientami.

W przypadku rozproszonych architektur hostingowych warto traktować punkt dostępu jako odrębną granicę bezpieczeństwa. Artykuł na temat hosting zdecentralizowany i kwestie związane z jego architekturą wyjaśnia, dlaczego komponenty rozproszone nie znoszą scentralizowanej odpowiedzialności za tożsamości i dostęp do danych. W przypadku Loki oznacza to konkretnie: każde przekierowanie musi być w sposób identyfikowalny przypisane do zaufanego podmiotu oraz do określonej reguły klienta.

Dlatego regularne kontrole nie powinny ograniczać się wyłącznie do pulpitów nawigacyjnych. Należy sprawdzić, czy serwer proxy odrzuca anonimowe połączenia, czy klient może nadpisać określony nagłówek klienta oraz czy konta z uprawnieniami do zapisu docierają wyłącznie do przewidzianych miejsc docelowych. Takie kontrole nie gwarantują pełnego bezpieczeństwa, ale pozwalają wcześnie wykryć typowe luki między logowaniem, routingiem a przechowywaniem logów.

Kontrolowane zarządzanie retencją i przechowywaniem danych

Logi centralne nie powinny być przechowywane po prostu tak długo, jak długo jest miejsce w pamięci obiektowej. Te Zatrzymanie musi być zgodny z ustawowymi, umownymi i wewnętrznymi obowiązkami dotyczącymi przechowywania danych – a także z momentem, od którego dane nie mają już żadnej wartości dla analizy błędów. Zgodnie z dokumentacją, bez włączonej funkcji przechowywania logi wysłane do Loki są przechowywane bezterminowo. Może to zwiększyć koszty, ryzyko związane z ochroną danych oraz zakres późniejszej odbudowy.

W przypadku TSDB i BoltDB-Shipper program Compactor realizuje skonfigurowane terminy usuwania danych. Powinien on działać jako pojedyncza instancja i mieć przypisany trwały katalog roboczy, aby jego praca nie została utracona w wyniku ponownego uruchomienia. Pamięć obiektowa zawiera zarówno fragmenty dzienników, jak i dane indeksowe; dlatego też jej projektowanie stanowi część koncepcji operacyjnej, a nie tylko planowania pojemności.

Różne okresy przechowywania dla poszczególnych strumieni logów mogą być uzasadnione, na przykład gdy zdarzenia związane z bezpieczeństwem wymagają dłuższego przechowywania niż szczegółowe wypisy z debugowania. Takie reguły związane ze strumieniami wymagają co najmniej 24-godzinnego okresu przechowywania i działają wyłącznie w oparciu o selektory etykiet. Filtry merytoryczne ani dowolne wyrażenia LogQL nie są do tego przeznaczone. Dlatego etykiety muszą już wcześniej rzetelnie odzwierciedlać kontekst merytoryczny, zanim reguły przechowywania będą się na nich opierać.

Ostrzeżenie: Zastosowanie ogólnej reguły cyklu życia do całego zasobnika pamięci masowej może spowodować usunięcie obiektów indeksu lub stanu klastra oraz uszkodzić zapytania. Lepiej jest zastosować ukierunkowaną strategię usuwania, uwzględniającą retencję Loki, klasy pamięci oraz oddzielne zasobniki lub prefiksy. Ponadto retencja nie zastępuje kopii zapasowej: określa ona planowane usuwanie danych dziennika, podczas gdy wymagania dotyczące przywracania danych określają, jakie konfiguracje, ścieżki dostępu i, w razie potrzeby, dane przechowywane muszą być dostępne po awarii.

Wykrywanie fal błędów i sprawdzanie problemów z nagrywaniem

W Grafana Explore można analizować zdarzenia z wielu hostów w tym samym przedziale czasowym. Skraca to czas reakcji w przypadku incydentu: zamiast logować się kolejno na serwery WWW, analizę można najpierw zawęzić według środowiska i usługi. Centralne wyszukiwanie pokazuje jednak jedynie korelacje, a nie automatycznie przyczynę; wskaźniki, ślady, wdrożenia i stan aplikacji pozostają ważnymi elementami uzupełniającymi w procesie diagnozy.

W przypadku fali błędów LogQL może wyliczyć wskaźnik na podstawie odpowiednich wierszy. Poniższe zapytanie, na przykład, zlicza wiersze Nginx o statusie HTTP 500 jako wskaźnik w okresie pięciu minut. Stanowi ono podstawę do analizy lub generowania alertu, ale nie określa, jaka wartość jest krytyczna w konkretnej aplikacji.

sum(rate({env="prod", service="nginx"} |= " 500 " [5m]))

Sensowny Próg alarmowy wynika z normalnego wskaźnika błędów, zachowania aplikacji oraz dostępnych sygnałów monitorujących. Pojedynczy błąd 500 w rzadko używanej funkcji administracyjnej może być oceniany inaczej niż w przypadku realizacji transakcji. Dlatego najpierw sprawdź historyczne wzorce i przypisz alarm do konkretnego zespołu odpowiedzialnego, zanim zostanie on eskalowany do środowiska produkcyjnego.

Jeśli podczas pisania Loki zwraca kod 429, nie należy odruchowo zwiększać limitów. Najpierw należy ustalić, czy dana usługa generuje niezwykle dużą liczbę wierszy, czy pętla powtarza błędy, czy też etykiety dynamiczne tworzą dużą liczbę małych strumieni. Loki ogranicza rejestrację zarówno globalnie, jak i dla poszczególnych strumieni w celu ochrony platformy. Dopiero po przeprowadzeniu tej weryfikacji można zdecydować, czy konieczne jest zastosowanie filtrowania, korekt etykiet lub uzasadnionego dostosowania limitów.

Właściwe i odpowiedzialne wykorzystanie Lokiego

W przypadku pojedynczego serwera VPS z Nginxem, systemd i niewielką liczbą kontenerów Loki może zapewnić przejrzyste, scentralizowane wyszukiwanie w trybie monolitycznym, o ile źródła logów, pamięć i dostępy są jasno uregulowane. Dokumentacja przeznacza ten tryb do zastosowań eksperymentalnych oraz przy niewielkich ilościach operacji odczytu i zapisu; około 20 GB dziennych logów stanowi w tym przypadku wskazówkę producenta, a nie gwarancję wydajności dla każdej struktury pamięci masowej, zapytań lub etykiet.

Wiele serwerów WWW z systemem Linux czerpie szczególne korzyści ze wspólnej osi czasu dla zdarzeń internetowych, dziennika i aplikacji. W przypadku wdrożeń kontenerowych o tym, czy takie wyszukiwanie pozostanie wykonalne, decyduje stabilny model etykiet dla środowiska i usługi. Bardzo duże środowiska Kubernetes lub role, które mają być skalowane oddzielnie, mogą uzasadniać stosowanie trybu mikrousług, wiąże się to jednak ze znacznie większym nakładem pracy związanym z obsługą i analizą błędów. W przypadku nowych projektów dyski SSD nie są stałą opcją domyślną, ponieważ tryb ten został oznaczony jako przestarzały.

Platforma obsługująca wielu klientów wymaga dodatkowo niezawodnego łańcucha dostępu. Loki rozdziela żądania na podstawie identyfikatora klienta, ale nie zapewnia pełnej warstwy uwierzytelniania. Wiarygodny serwer proxy lub warstwa tożsamości musi uwierzytelniać dostęp, wymuszać protokół TLS oraz ustalać przypisania po stronie serwera. Częścią podstawy jest również obsługiwany agent: Promtail nie jest już obsługiwany; w przypadku nowych instalacji zalecanym rozwiązaniem jest na przykład Grafana Alloy.

• Pojedynczy serwer VPS: przed wdrożeniem należy sporządzić spis zasobów, skonfigurować filtry dotyczące informacji niejawnych oraz ustalić proste i możliwe do zweryfikowania zasady przechowywania danych.
• Wiele hostów: należy uzgodnić spójne etykiety dla środowiska i usługi, aby centralne wyszukiwanie faktycznie skracało czas rozwiązywania incydentów.
• Platforma kontenerowa: nie należy używać dynamicznych identyfikatorów jako etykiet; należy na bieżąco monitorować liczbę strumieni oraz zachowanie podczas rejestracji.
• Praca w trybie wielodostępnym: wdrożenie uwierzytelniania, przypisywania klientów po stronie serwera oraz uprawnień przed udostępnieniem punktów końcowych Loki.
• Każde środowisko: należy dokumentować wymagania dotyczące przywracania danych oraz regularnie weryfikować konfigurację, koncepcję przechowywania danych i terminy usuwania danych.

Jeśli brakuje osób odpowiedzialnych za źródła logów, koncepcji dotyczącej treści wrażliwych lub jasnych celów przywracania danych, należy najpierw... Podstawy działalności należy wyjaśnić. Loki może agregować logi i umożliwić ich przeszukiwanie, ale nie zastępuje ani zasady minimalizacji danych, ani kopii zapasowych, kontroli dostępu ani fachowej analizy przyczyn. Korzyści pojawiają się dopiero wtedy, gdy technologia, zakres odpowiedzialności i przechowywanie danych są planowane wspólnie.