„Przejrzyj wszystkie CloudWatch Log Groups. Te, które mają retencję ustawioną na
Never expire, przestaw na 30, 60 albo 90 dni. Nie ma sensu tyle płacić za stare logi”.
Szczerze mówiąc, od zawsze uważałem tę radę za głupią. Tylko że nie za każdym razem, gdy ją słyszałem, miałem ochotę walczyć z wiatrakami, więc często po prostu milczałem.
Logika tej rady jest żelazna: No bo przecież logi kosztują. Za stare dane też się płaci. A jak coś usuniemy, to rachunek będzie mniejszy.
Tylko że po kilku latach pracy z AWS dochodzę do wniosku, że to jedna z głupszych porad, jakie można dać komuś w ramach „optymalizacji kosztów”. Szczególnie gdy mówimy o produkcji.
I piszę to trochę bijąc się we własną pierś.
Przy okazji modernizacji serwisu serverlessowego, który napisałem jakieś pięć lat temu, przejrzałem Log Groups dla produkcyjnych Lambd. Ku mojemu zdziwieniu część z nich miała retencję ustawioną na cztery miesiące.
Cztery miesiące. 😬
Czyli dzisiaj, kiedy próbuję zrozumieć historię tego systemu, nie mam już dostępu do większości zdarzeń, które miały miejsce wcześniej. Nie dlatego, że AWS ich nie przechował. To ja zdecydowałem, że nie są mi potrzebne.
Sam nie wiem, jak to się stało. Najwyraźniej konfiguracja przygotowana dla środowiska dev została bez refleksji przekopiowana na prod. To było ustawione tak dawno temu, że nie mogę tego zrzucić na AI. To ja zawaliłem.
I zapewne zaoszczędziłem na tym kilkanaście centów. Może kilka dolarów przez kilka lat.
Super interes.
Prawdziwy problem to ingest logów, nie ich retencja
Tu jest najważniejszy szczegół, który zazwyczaj ginie w tych wszystkich poradach o „sprzątaniu CloudWatcha”.
Samo przechowywanie logów w CloudWatch jest tanie. W przykładzie AWS dla regionu us-east-1 przechowywanie kosztuje 0,03 USD za GB miesięcznie.
Za ingest standardowych logów płacisz tam 0,50 USD za GB.
Czyli ingest jest ponad 16 razy droższy niż trzymanie już zapisanych danych.
To ważne, bo skracając retencję nie zmieniasz nic w koszcie ingestu. Log już przyszedł do CloudWatch. AWS już go przyjęło i rozliczyło. Największy koszt już poniosłeś.
AWS pokazuje to bardzo dobrze we własnym przykładzie cenowym (Example 2). Aplikacja wysyła 1 GB logów dziennie, czyli około 30 GB miesięcznie. Sam ingest to 6.25 USD miesięcznie. Z kolei dane w archiwum, po przyjętym w przykładzie skompresowaniu do 6 GB, kosztują 0,03 USD miesięcznie po uwzględnieniu pierwszych 5 GB bez opłaty.
Monthly ingested log charges
Total log data ingested = 1 GB * 30 days = 30 GB
Charges for log data ingestion (0 to 5 GB): = $0
Charges for log data ingestion (5 to 30 GB) = $0.25 * 25 = $6.25
Monthly archived log charges (assume log data compresses to 6 GB)
Charges for 0 to 5 GB = $0
Charges for 5 GB to 6 GB = $0.03 * 1 GB = $0.03
6.25 USD za dostarczenie danych. 3 centy za ich dalsze przechowanie.
Jeśli więc ktoś ma realny problem z kosztem logów, to powinien przede wszystkim sprawdzić, co wysyła do CloudWatch. Debug logi na produkcji, ten sam payload wypisany trzy razy, ogromne obiekty JSON, logowanie każdej pierdoły na poziomie INFO - tu jest miejsce, w którym można coś faktycznie ugrać.
Usuwanie historii po 30 dniach tylko dlatego, że logi „są drogie”, jest trochę jak sprzedaż książek z biblioteki, bo zajmują półkę. Tak, półka będzie wolna. Tylko potem nagle okazuje się, że właśnie tej jednej książki potrzebujesz.
AWS najwyraźniej też zakłada kompresję
Miałem intuicję, że AWS raczej nie przechowuje naszych logów w formie dokładnie takiej, w jakiej je wysyłamy. Moje przypuszczenia wreszcie potwierdziłem 🙂
W przykładach cenowych AWS liczy koszt archiwum na danych po kompresji. Nie oznacza to oczywiście, że możemy sobie założyć konkretny współczynnik dla każdego systemu. Logi tekstowe i JSON zwykle kompresują się dobrze, ale nie ma sensu wpisywać na sztywno jakiejś magicznej liczby do Excela.
Wystarczy jednak spojrzeć na proporcje: storage jest bardzo tani, a koszt ingestu wielokrotnie wyższy.
To powinno kompletnie zmienić kolejność działań w optymalizacji CloudWatch Logs.
Najpierw ogranicz śmieci, które wpadają do logów. Dopiero później zastanów się, czy naprawdę chcesz usuwać historię.
Rzadkie eventy nie pytają, czy masz retencję 90 dni
Największy problem z krótką retencją pojawia się wtedy, gdy system nie jest nowy.
W nowym projekcie cztery miesiące brzmią jeszcze rozsądnie. Masz świeży kod, pamiętasz architekturę, wiesz, jak działają integracje.
Ale po dwóch, trzech albo pięciu latach system zaczyna żyć własnym życiem.
Zmieniają się ludzie w zespole. Zmieniają się integracje. Zmieniasz format eventów. Coś zostało dopisane na szybko, bo był incydent. Potem ktoś to poprawił. A później jeszcze ktoś uznał, że można to zrefaktoryzować.
I nagle w trakcie migracji chcesz sprawdzić, czy konkretny event w ogóle kiedyś wystąpił. Albo jak wyglądał payload od partnera przed zmianą integracji. Albo od kiedy ten nietypowy błąd zaczął się pojawiać.
Niektóre zdarzenia biznesowe występują raz na rok. Niektóre raz na kilka lat. Nie dlatego, że system jest popsuty. Po prostu taki jest biznes.
Jeżeli usuniesz logi po 120 dniach, to w wielu przypadkach nie będziesz już miał żadnego sposobu, żeby zrozumieć, co naprawdę wydarzyło się w produkcji. Stracisz też prawdziwe zdarzenia, które mogły posłużyć za realne przypadki do testów (po anonimizacji).
Zostanie Ci pamięć ludzi, stare tickety i klasyczne: „wydaje mi się, że kiedyś to działało inaczej”.
Powodzenia.
Optymalizacja kosztów nie polega na kasowaniu wszystkiego, co kosztuje
W FinOps bardzo łatwo pomylić obniżenie jednej linijki na fakturze z optymalizacją.
Można oczywiście obniżyć koszt storage. Wystarczy usunąć dane.
Tylko że pytanie brzmi: jaki jest koszt tego, że tych danych już nie masz?
Jedna godzina pracy seniora przy szukaniu przyczyny starego problemu może kosztować więcej niż kilka lat przechowywania logów małej aplikacji serverlessowej. A w prawdziwym życiu rzadko kończy się na jednej godzinie, bo brak danych powoduje kolejne hipotezy, kolejne testy i kolejne zgadywanie.
Nie mówiąc już o sytuacji, w której problem dotyczy klienta albo pieniędzy.
Dla mnie dobra optymalizacja kosztów to taka, która usuwa wydatek bez usuwania wartości. Usunięcie nieużywanego EBS-a, starego snapshotu albo NAT Gatewaya, który nie ma ruchu, to jest dobry przykład. Tych zasobów nikt nie będzie potrzebował za pięć lat.
Logi produkcyjne są inne. Często nie są potrzebne. Do momentu, w którym są absolutnie potrzebne.
Nie ustawiaj Never expire wszędzie bez zastanowienia
Żeby było jasne: nie twierdzę, że każda Log Group w każdym koncie AWS ma mieć retencję bez końca.
Środowiska developerskie i testowe spokojnie mogą mieć 30 albo 90 dni, chociaż nawet tam często nie widzę problemu z półroczną retencją. Tak samo bardzo głośne logi techniczne, które nie niosą istotnej informacji biznesowej. W systemach o naprawdę ogromnym wolumenie danych trzeba świadomie zaprojektować archiwizację, czasem przenieść starsze logi do S3 i ustawić lifecycle.
Są też dane wrażliwe, regulacje i wewnętrzne wymagania bezpieczeństwa. Retencja musi wtedy wynikać z tych zasad, a nie z mojego artykułu.
Natomiast produkcyjna Lambda, która obsługuje ważny proces biznesowy, nie powinna dostawać 30 albo 90 dni retencji tylko dlatego, że ktoś robi przegląd FinOps i potrzebuje znaleźć szybkie oszczędności.
Zanim skrócisz retencję, odpowiedz sobie na kilka pytań.
- Czy to logi z produkcji?
- Czy ten proces obsługuje rzadkie eventy albo integracje zewnętrzne?
- Czy mam gdzie indziej pełną historię tego, co się wydarzyło?
- Ile faktycznie płacę za storage, a ile za ingest?
- Czy koszt odzyskania tej wiedzy za dwa lata będzie mniejszy niż koszt przechowywania logów?
Jeżeli nie masz bardzo dobrej odpowiedzi, to naprawdę nie oszczędzaj na tej retencji.
Jedna ważna rzecz na koniec
Logi nie są dobrym systemem źródłowym dla najważniejszych danych biznesowych.
Jeżeli zdarzenie ma znaczenie księgowe, audytowe albo prawne, powinno mieć własny, świadomie zaprojektowany zapis. Nie liczyłbym na to, że przypadkowy wpis z console.log będzie jedynym dowodem na to, co zrobił system.
Ale logi są świetnym kontekstem. Pokazują, co działo się przed błędem, jakie dane przyszły do funkcji, gdzie system podjął inną decyzję, niż się spodziewaliśmy.
I właśnie tego kontekstu dzisiaj mi brakuje w tym pięcioletnim systemie.
Więc moja zasada jest bardzo prosta: najpierw optymalizuję ingest. Potem pilnuję, żeby do logów nie trafiały dane, których nie powinno tam być. A retencję produkcyjnych logów skracam dopiero wtedy, gdy naprawdę wiem, co tracę.
Bo kilka centów oszczędności miesięcznie to kiepska wymiana za kilka lat pamięci systemu.
