Grafana Loki – centralne logowanie dla nowoczesnej infrastruktury
Grafana Loki to system agregowania i przechowywania logów, zaprojektowany przede wszystkim z myślą o środowiskach cloud-native, Kubernetes, Docker i dużych infrastrukturach.
Najprościej można to przedstawić tak:
Serwery
|
+---- logi ----+
| |
Kontenery Kubernetes
| |
+-------+------+
|
v
Loki
|
v
Grafana
Loki jest często używany razem z Prometheusem i Grafaną, tworząc podstawowy stack observability:
Prometheus → Metrics
Loki → Logs
Grafana → Visualization
Czym różni się Loki od klasycznego systemu logowania?
Tradycyjny system może indeksować bardzo dużą część treści logów.
Loki został zaprojektowany inaczej.
Jego istotną cechą jest to, że nie indeksuje całej zawartości logów tak jak klasyczne rozwiązania wyszukiwania pełnotekstowego. Zamiast tego wykorzystuje etykiety (labels) do identyfikacji strumieni logów, a samą treść przechowuje w skompresowanej postaci.
Schemat:
Log line
|
+--> Labels → indexed
|
+--> Log content → stored
To pozwala ograniczyć koszty przechowywania w porównaniu z systemami, które tworzą indeks dla ogromnej liczby elementów znajdujących się w treści logów.
Loki + Grafana
Najpopularniejszy model:
Grafana
/ \
/ \
Prometheus Loki
| |
Metrics Logs
Dzięki temu w Grafanie można analizować jednocześnie:
CPU: 92%
RAM: 81%
HTTP 5xx: 14%
oraz:
ERROR database connection timeout
ERROR database connection timeout
ERROR database connection timeout
To daje znacznie lepszy obraz problemu.
Jak logi trafiają do Loki?
W typowej instalacji potrzebujemy agenta, który zbiera logi.
Popularnym rozwiązaniem jest Grafana Alloy.
Schemat:
Linux
|
+--> /var/log/*
|
v
Grafana Alloy
|
v
Loki
|
v
Grafana
W starszych konfiguracjach można również spotkać Promtail, ale dla nowych wdrożeń warto zwrócić uwagę na aktualny kierunek rozwoju ekosystemu Grafany.
Loki nie jest agentem
To ważne rozróżnienie.
Loki:
Loki
|
przechowuje
logi
Agent:
Alloy
|
zbiera logi
|
v
Loki
Grafana:
Grafana
|
pokazuje
logi
Czyli:
Alloy → Loki → Grafana
LogQL
Do wyszukiwania logów Loki wykorzystuje LogQL.
Przykładowe zapytanie:
{job="varlogs"}
oznacza pobranie logów należących do określonego strumienia.
Możemy następnie filtrować zawartość:
{job="varlogs"} |= "error"
Czyli:
job = varlogs
+
contains "error"
Przykład wyszukiwania błędów
Jeżeli aplikacja generuje:
INFO User logged in
INFO Request received
ERROR Database connection failed
INFO Request received
ERROR Database connection failed
możemy wyszukać:
{app="api"} |= "ERROR"
i otrzymać tylko interesujące wpisy.
Labels
Labels są jednym z najważniejszych elementów Loki.
Przykład:
{app="nginx", environment="production"}
Możemy mieć:
app=nginx
environment=production
host=web01
Następnie:
{app="nginx", environment="production"}
wybierze odpowiedni strumień.
Uwaga na cardinality
Podobnie jak w Prometheusie, trzeba uważać na high cardinality.
Złym pomysłem może być dodawanie jako label:
user_id
request_id
session_id
transaction_id
Jeżeli każdy log będzie miał inną wartość, liczba strumieni może gwałtownie wzrosnąć.
Lepsze:
app
environment
host
namespace
container
a szczegółowe wartości pozostawić w treści logu.
Loki + Kubernetes
To jedno z najważniejszych zastosowań.
Kubernetes
|
+--------------+--------------+
| | |
Pod Pod Pod
| | |
Logs Logs Logs
| | |
+--------------+--------------+
|
Grafana Alloy
|
v
Loki
|
v
Grafana
Możemy wtedy przeszukiwać logi:
namespace
pod
container
application
node
Przykład Kubernetes
Załóżmy:
namespace=production
app=api
W Grafanie możemy przejść od:
production
|
v
api
|
v
pod/api-7f8c9
|
v
ERROR
To bardzo przyspiesza analizę problemów.
Loki + Docker
W Dockerze każdy kontener może generować własne logi.
Docker Host
|
+---+---+---+
| | | |
Web API DB Redis
| | | |
+---+---+---+
|
Alloy
|
v
Loki
W Grafanie możemy filtrować:
container="api"
albo:
container="nginx"
Loki + Linux
Możemy zbierać:
/var/log/syslog
/var/log/auth.log
/var/log/nginx/*
/var/log/app/*
Przykładowa architektura:
Linux Server
|
+--> auth.log
+--> syslog
+--> nginx.log
+--> application.log
|
v
Grafana Alloy
|
v
Loki
Loki i SSH
To interesujący przypadek z punktu widzenia bezpieczeństwa.
Możemy analizować:
Failed password
Invalid user
Accepted publickey
Accepted password
Przykładowe zapytanie:
{job="auth"} |= "Failed password"
Można dzięki temu szybko znaleźć nieudane próby logowania.
Loki + bezpieczeństwo
Loki nie jest SIEM-em.
Ale może być bardzo wartościowym źródłem danych dla systemów bezpieczeństwa.
Przykładowo:
SSH failures
Firewall logs
Web server logs
Application logs
Authentication logs
mogą być gromadzone centralnie.
Loki + Prometheus
To bardzo ważne połączenie.
Prometheus odpowiada za:
METRICS
Loki:
LOGS
Grafana:
VISUALIZATION
Czyli:
Grafana
/ \
/ \
Prometheus Loki
| |
Metrics Logs
Metrics → Logs
Jedną z największych zalet połączenia Prometheusa z Lokim jest możliwość przechodzenia od metryk do logów.
Przykład:
CPU
|
| nagły wzrost
v
Grafana
|
v
Server web01
|
v
Logs
|
+--> ERROR
+--> ERROR
+--> ERROR
Administrator nie musi ręcznie szukać odpowiedniego serwera.
Logs → Metrics
Możliwe jest również spojrzenie w drugą stronę.
Załóżmy, że widzimy:
ERROR database connection
Możemy następnie sprawdzić:
CPU
RAM
Network
Latency
Requests
dla tego samego okresu.
To jest właśnie wartość observability.
Loki + Grafana + Prometheus
Pełny podstawowy stack:
Grafana
/ \
/ \
Prometheus Loki
| |
Metrics Logs
| |
Exporters Alloy
| |
+-----+---------------+-----+
| |
Linux Kubernetes
| |
Docker Apps
Loki + Tempo
Możemy dodać jeszcze tracing:
Metrics
|
Prometheus
Logs
|
Loki
Traces
|
Tempo
\ | /
\|/
Grafana
Wtedy otrzymujemy trzy podstawowe filary observability:
Metrics
Logs
Traces
Przykład problemu z aplikacją
Załóżmy, że użytkownicy zgłaszają:
Aplikacja działa bardzo wolno.
Najpierw Grafana:
Latency p95
|
+---- 120 ms
+---- 180 ms
+---- 420 ms
+---- 1.2 s
Następnie Prometheus pokazuje:
Database connections
|
v
95%
Przechodzimy do Loki:
ERROR connection pool exhausted
ERROR connection timeout
ERROR connection timeout
W ciągu kilku chwil mamy hipotezę:
Application
|
v
Database connection pool
|
v
Exhausted
Loki + SIEM
W większym środowisku Loki może współistnieć z SIEM.
Logs
|
+--------+--------+
| |
Loki SIEM
| |
Observability Security
| |
+--------+--------+
|
SOC
Loki może być świetny do operacyjnego przeglądania logów, natomiast SIEM może odpowiadać za:
- korelację zdarzeń,
- detekcję,
- reguły bezpieczeństwa,
- incident response,
- długoterminową analizę.
Loki + Suricata
Możemy centralizować logi Suricaty:
Suricata
|
+--> alerts
+--> DNS
+--> HTTP
+--> TLS
|
v
Alloy
|
v
Loki
|
v
Grafana
Dashboard może pokazywać:
IDS Alerts
----------------
Critical 12
High 48
Medium 321
Low 904
Loki + Zeek
Podobnie:
Zeek
|
+--> conn.log
+--> dns.log
+--> http.log
+--> ssl.log
+--> ssh.log
|
v
Loki
|
v
Grafana
Dzięki temu można analizować zdarzenia sieciowe w kontekście innych logów.
Loki + DNS Filtering
Wracając do poprzedniego tematu:
DNS Filtering
|
+--> Allowed
+--> Blocked
|
v
Logs
|
v
Loki
|
v
Grafana
Można wyszukać np. wszystkie zablokowane zapytania dotyczące określonej kategorii.
Centralne logowanie
Bez Loki:
Server 1 → /var/log
Server 2 → /var/log
Server 3 → /var/log
Server 4 → /var/log
Administrator musi logować się na wiele maszyn.
Z Loki:
Server 1 \
Server 2 \
Server 3 +--> Alloy --> Loki --> Grafana
Server 4 /
Wszystkie logi są dostępne centralnie.
Retencja
Logi zajmują dużo miejsca.
Dlatego trzeba określić:
Hot data
↓
Recent logs
Long-term storage
↓
Older logs
W większych instalacjach Loki może korzystać z obiektowego storage, np. S3-compatible storage.
Architektura:
Loki
|
v
Object Storage
|
+----------+----------+
| | |
Logs Chunks Data
Loki i skalowanie
Małe środowisko:
Alloy
|
v
Loki
|
v
Grafana
Większe:
Agents
|
v
Load Balancer
|
+--------+--------+
| | |
Loki Loki Loki
| | |
+--------+--------+
|
Object Storage
|
Grafana
Pozwala to skalować system wraz ze wzrostem liczby logów.
Najczęstsze błędy
❌ Wszystko jako label
Nie należy zamieniać każdej wartości dynamicznej w label.
❌ Brak retencji
Logi mogą bardzo szybko zająć storage.
❌ Brak struktury
Dobrze ustandaryzowane logi są znacznie łatwiejsze do analizy.
❌ Logowanie danych wrażliwych
Nie należy bez potrzeby zapisywać:
Hasła
Tokeny
Klucze API
Sesje
Dane osobowe
❌ Traktowanie Loki jako SIEM
Loki jest systemem logowania i observability, a nie pełnym rozwiązaniem SOC.
Dobre praktyki
1. Standaryzuj logi
Preferuj strukturalne logowanie:
{
"level": "error",
"service": "api",
"message": "database timeout"
}
2. Używaj sensownych labels
service
environment
host
namespace
container
3. Kontroluj cardinality
Unikaj:
request_id
user_id
session_id
jako labels.
4. Ustal retencję
Nie każdy log musi być przechowywany przez lata.
5. Chroń dane
Logi mogą zawierać informacje bardzo wrażliwe.
Loki w architekturze Defense in Depth
Łącząc Loki z wcześniejszymi elementami:
INTERNET
|
Firewall
|
GeoIP Block
|
DNS Filtering
|
TLS Inspection
|
Suricata
|
Zeek
|
Microsegmentation
|
+-------------+-------------+
| | |
Linux Kubernetes Apps
| | |
Metrics Metrics Metrics
| | |
Prometheus Prometheus Prometheus
| | |
+-------------+-------------+
|
Grafana
/ \
/ \
Prometheus Loki
| |
Metrics Logs
|
Alloy
Możemy do tego dodać tracing:
Metrics → Prometheus
Logs → Loki
Traces → Tempo
|
v
Grafana
Prometheus vs Loki vs Grafana
| Narzędzie | Główne zadanie |
|---|---|
| Prometheus | Metryki |
| Loki | Logi |
| Grafana | Wizualizacja |
| Alloy | Zbieranie/transport telemetry |
| Tempo | Tracing |
| Alertmanager | Zarządzanie alertami |
Najprostszy model:
OBSERVABILITY
|
+-----------+-----------+
| | |
Metrics Logs Traces
| | |
Prometheus Loki Tempo
| | |
+-----------+-----------+
|
Grafana
I właśnie w takim układzie Loki jest odpowiednikiem warstwy logów – pozwala zebrać ogromną liczbę wpisów z serwerów, kontenerów i Kubernetes, a następnie analizować je razem z metrykami Prometheusa w Grafanie.
W przyszłości mogą pojawić się nowe standardy sieci bezprzewodowej, które będą działały pod nazwą WiFi 10. Przypuszcza się, że nowy Czytaj dalej
