Koszt logów w Elastic: LogsDB, pattern_text i tiery

Logi rosną szybciej niż budżet. Po kilku miesiącach od wdrożenia Elastic zespół zwykle odkrywa, że najwięcej kosztują nie licencje, tylko dyski i węzły, na których leżą dane starsze niż tydzień, do których prawie nikt nie zagląda. Elastic ma kilka mechanizmów, które pozwalają to obniżyć bez ucinania retencji. Poniżej opisujemy cztery, w kolejności, w jakiej zwykle je sprawdzamy, i zaznaczamy, które wymagają aktualizacji do 9.x.

1. LogsDB: tryb indeksu dla logów

LogsDB to tryb indeksu zaprojektowany dla danych logów. Dokumentacja Elastic podaje, że w testach zmniejsza zajętość miejsca nawet o 60%, przy wpływie rzędu 10 do 20% na wydajność indeksowania. Wynik zależy od danych i wersji, więc traktuj te liczby jako górną granicę do sprawdzenia, a nie obietnicę.

Ważny szczegół dla firm po aktualizacji: w Elastic Stack 9.0 i nowszych LogsDB jest domyślny dla nowych strumieni logs-*-*, ale w klastrze zaktualizowanym z 8.x obejmuje je tylko wtedy, gdy w chwili aktualizacji nie istniał żaden taki strumień. Istniejące strumienie z 8.x (także integracji i APM) nie przełączają się same. Jeśli aktualizowałeś klaster z 8.x, istnieje spora szansa, że płacisz za logi bez tej oszczędności.

Włączenie polega na ustawieniu index.mode na logsdb w szablonie indeksu lub w komponencie @custom dla integracji:

PUT _component_template/logs-system.syslog@custom
{
  "template": {
    "settings": {
      "index.mode": "logsdb"
    }
  }
}

Zmiana zaczyna działać od następnego rolloveru, więc stare indeksy zostają, jak były. Dokumentacja ostrzega, że zapytanie PUT nadpisuje istniejący szablon, więc najpierw pobierz bieżącą konfigurację. Nazwa komponentu powyżej to przykład: dla swojej integracji sprawdź właściwą nazwę.

2. pattern_text dla komunikatów

Pole pattern_text rozdziela powtarzalne komunikaty na szablon i zmienne. W Elastic Stack ma status GA od wersji 9.3, a Elastic mówi o oszczędności nawet 50% miejsca na polach z komunikatem. Ograniczenia (brak zapytań span, stała ocena dla fraz, jedna wartość na dokument) opisaliśmy w tekście o Elastic 9.3, razem ze sposobem testu na próbce danych. Warto go wykonać razem z LogsDB, bo oba mechanizmy działają na różnych elementach dokumentu.

3. Warstwy danych i migawki do przeszukiwania

Logi mają prosty profil: najnowsze dane czyta się często, starsze rzadko. Elastic odzwierciedla to w warstwach danych (tierach):

Warstwa	Dane	Co mówi dokumentacja
Hot	najnowsze, najczęściej czytane	szybkie dyski, wymagana
Warm	ostatnie tygodnie, rzadziej czytane	słabszy sprzęt niż hot, zalecane repliki
Cold	rzadko przeszukiwane	w pełni zamontowane migawki do przeszukiwania, bez replik, zajętość dysku niższa o ok. 50%
Frozen	prawie nie czytane, nigdy nie aktualizowane	częściowo zamontowane migawki, do 20 razy większa pojemność niż w warm, wolniejsze wyszukiwanie

Przejścia między warstwami zarządza ILM albo cykl życia strumienia danych. Przykładowa polityka, w której dane po 30 dniach trafiają do warstwy cold, po 90 do frozen, a po roku są usuwane:

PUT _ilm/policy/logi-retencja
{
  "policy": {
    "phases": {
      "hot": {
        "actions": { "rollover": { "max_primary_shard_size": "50gb", "max_age": "1d" } }
      },
      "cold": {
        "min_age": "30d",
        "actions": { "searchable_snapshot": { "snapshot_repository": "repo-logi" } }
      },
      "frozen": {
        "min_age": "90d",
        "actions": { "searchable_snapshot": { "snapshot_repository": "repo-logi" } }
      },
      "delete": {
        "min_age": "365d",
        "actions": { "delete": {} }
      }
    }
  }
}

Progi 30, 90 i 365 dni to tylko przykład: dobieraj je do tego, jak długo realnie szukasz w logach i jakie masz wymagania co do retencji. Migawki do przeszukiwania wymagają repozytorium migawek, na przykład w magazynie obiektowym. Sprawdź, czy Twoja subskrypcja obejmuje tę funkcję, zanim zaplanujesz na niej architekturę.

Od wersji 9.5 cykl życia strumienia danych potrafi przenosić indeksy do warstwy frozen przy użyciu ustawienia frozen_after, co ma status GA. To prostsza alternatywa dla pełnej polityki ILM, jeśli nie potrzebujesz jej szczegółowych faz.

4. Metryki i kolumnowy tryb logów

W wersji 9.5 Elastic zapowiada kodek ES95 dla metryk, który ma zmniejszyć zajętość do około 3 bajtów na próbkę, czyli o ok. 20% mniej niż wcześniej. Opisuje także tryb kolumnowy (Columnar Mode) z profilem dla logów. Tryb kolumnowy ma status podglądu technicznego, więc nie nadaje się jeszcze na dane produkcyjne, ale jest powodem, by obserwować kolejne wydania. Szczegóły metryk opisujemy w tekście o Elastic 9.4 dla metryk.

Warto pamiętać, że oszczędności z kilku mechanizmów się nie sumują mechanicznie. Wyniki producenta dotyczą konkretnych zestawów danych, a efekt LogsDB, pattern_text i przeniesienia na tańsze warstwy zależy od tego, jak wyglądają Twoje logi. Dlatego mierzymy każdy krok osobno, na tej samej próbce danych, zanim zmienimy cały klaster.

Downsampling metryk a ILM

Jeśli oprócz logów trzymasz metryki z downsamplingiem, pamiętaj o zmianie z wersji 9.4: akcja downsamplingu w ILM nie wykonuje już domyślnie force merge. Jeśli Twoja polityka na tym polegała, dodaj akcję force merge albo ustaw force_merge_index na true. Bez tego indeksy po downsamplingu mogą zajmować więcej miejsca, niż zakładasz w planie pojemności, a różnicę zobaczysz dopiero po kilku tygodniach.

Jak podejść do przeglądu kosztów

1. Zmierz, co zajmuje miejsce. Sprawdź rozmiar indeksów według źródeł logów, np. poleceniem GET _cat/indices?v&h=index,docs.count,store.size&s=store.size:desc. Zwykle kilka źródeł odpowiada za większość danych.
2. Sprawdź, czy działa LogsDB. To pierwszy krok po aktualizacji do 9.x.
3. Przeanalizuj retencję. Czy wszystkie logi muszą być przeszukiwalne w hot przez 30 dni? Zwykle nie.
4. Przesuń starsze dane do cold i frozen, jeśli subskrypcja na to pozwala.
5. Ogranicz szum u źródła. Logi debugowania z produkcji i duplikaty kosztują tyle samo co ważne zdarzenia.

Rząd wielkości kosztów licencji i chmury Elastic możesz oszacować w kalkulatorze kosztu Elastic Stack. Przegląd kosztów przechowywania na Twoim klastrze wykonujemy w ramach zarządzania logami.