Jak zmniejszyć koszty pozyskiwania danych w Log Analytics?

Najskuteczniejszą strategią obniżania kosztów jest filtrowanie niepotrzebnych danych dziennika u źródła za pomocą reguł zbierania danych (DCR), tak aby hałaśliwe, nieczytane dzienniki debugowania były odrzucane, zanim trafią do płatnego obszaru roboczego.

Cennik Azure Log Analytics: jak powstrzymać eksplozję kosztów monitoringu w chmurze

Q: Czy utworzenie obszaru roboczego Azure Log Analytics jest bezpłatne?

Tak, samo utworzenie obszaru roboczego nie wiąże się z żadnymi opłatami podstawowymi. Płacisz wyłącznie za ilość danych pozyskanych do obszaru roboczego oraz za czas ich przechowywania.

Q: Czym różnią się plany dziennika Analytics, Basic i Auxiliary?

Plan Analytics zapewnia szybkie, w pełni indeksowane przechowywanie, zoptymalizowane pod kątem alertów bezpieczeństwa w czasie rzeczywistym i szybkich zapytań interaktywnych. Plany Basic i Auxiliary oferują znacznie tańsze opcje przechowywania danych, do których sięga się rzadko, a które są przede wszystkim przechowywane ze względów zgodności z przepisami lub archiwizacji.

Q: Dlaczego należy unikać dziennych limitów pozyskiwania danych?

Dzienne limity pozyskiwania danych całkowicie zatrzymują zbieranie danych po osiągnięciu progu wydatków. Oznacza to, że systemy bezpieczeństwa i monitoringu są pozbawione widoczności do końca dnia, co stwarza niedopuszczalne ryzyko podczas awarii systemów lub naruszeń bezpieczeństwa.

By Mirko Peters · 2026-10-23

Dowiedz się, jak kontrolować cennik Azure Log Analytics, optymalizować plany tabel w obszarze roboczym, filtrować szum w pozyskiwanych danych i zapobiec gwałtownemu wzrostowi kosztów monitoringu w chmurze.

Automatically translated with AI from the original post. Read the English original

Kontrolowanie cennika Azure Log Analytics wymaga zrozumienia wolumenu pozyskiwanych danych, planów danych tabel oraz kosztów długoterminowego przechowywania. Wczesne filtrowanie danych za pomocą KQL, wybór odpowiednich poziomów, takich jak Basic i Auxiliary, oraz unikanie niebezpiecznych dziennych limitów zbierania pozwalają administratorom zapobiec wymknięciu się rachunków za monitoring Azure spod kontroli.

Najważniejsze wnioski

Cennik Azure Log Analytics zależy przede wszystkim od ilości pozyskiwanych danych i czasu ich przechowywania.
Plany tabel mocno wpływają na wydatki: przechowywanie w planie Basic może być znacznie tańsze niż w standardowym planie Analytics, a plany Auxiliary oferują ogromne zniżki na masowo archiwizowane dane.
Odfiltrowanie u źródła hałaśliwych, nieczytanych wierszy dziennika za pomocą reguł zbierania danych to najskuteczniejsza dźwignia obniżania kosztów monitoringu w chmurze.
Poleganie na sztywnych dziennych limitach pozyskiwania danych może nieumyślnie pozbawić zespoły bezpieczeństwa i operacyjne widoczności, zatrzymując zbieranie wszystkich danych w środku dnia.
Zrównoważenie okresów przechowywania interaktywnego z długoterminowym przechowywaniem typu cold zapewnia zgodność z przepisami bez przepłacania za szybkie zapytania.

Prawdziwe czynniki kosztowe Log Analytics

Gdy organizacje po raz pierwszy wdrażają monitoring w chmurze, uwaga skupia się niemal wyłącznie na widoczności — na tym, by systemy się ze sobą komunikowały, a każdy błąd był rejestrowany. Rzeczywistość uderza jednak, gdy nadejdzie miesięczna faktura za chmurę. Log Analytics jest rozliczany przede wszystkim na podstawie dwóch wektorów zużycia: wolumenu gigabajtów przesłanych do obszaru roboczego oraz czasu, przez jaki rekordy są dostępne do interaktywnych zapytań.

Samo utworzenie obszaru roboczego nic nie kosztuje, co często daje złudne poczucie bezpieczeństwa. Zespoły zwykle traktują repozytoria dzienników jak niekończące się szuflady na śmieci: wrzucają do jednego kontenera rozwlekłe dane debugowania aplikacji, zbędne sygnały heartbeat i niezweryfikowane ślady. Ponieważ płacisz za każdy gigabajt, który trafia do obszaru roboczego — niezależnie od tego, czy ktokolwiek kiedykolwiek otworzy daną tabelę — niekontrolowane pozyskiwanie danych szybko prowadzi do przekroczenia budżetu.

Poruszanie się po planach tabel: Analytics, Basic i Auxiliary

Jedną z najbardziej wpływowych decyzji, jakie może podjąć administrator, jest przypisanie właściwego planu cenowego do poszczególnych tabel. Nie wszystkie dane dziennika wymagają tego samego poziomu wydajności, a Microsoft oferuje warstwowe plany, które odzwierciedlają te kompromisy operacyjne.

Standardowy poziom Analytics

Standardowy plan Analytics przeznaczony jest dla danych, które monitorujesz na bieżąco i potrzebujesz szybko przeszukiwać. Obsługuje wykrywanie zagrożeń w czasie rzeczywistym i szybkie rozwiązywanie problemów. Jest to jednak także najdroższa opcja. Utrzymuje pełne indeksowanie, co pozwala wykonywać zapytania w języku Kusto Query Language (KQL) w czasie poniżej sekundy, nawet w złożonych instrukcjach.

Poziomy Basic i Auxiliary

W przypadku danych, do których zaglądasz wyłącznie reaktywnie, gdy coś przestaje działać, lub rekordów o dużej objętości przechowywanych wyłącznie do celów audytu, plany Basic i Auxiliary oferują ogromne oszczędności. Podczas gdy standardowy plan Analytics może kosztować około 2,30 USD za gigabajt, plany Basic mogą obniżyć tę cenę znacząco, a poziomy Auxiliary mogą zejść do ułamka standardowych stawek (w dolnym przedziale nawet 46 razy taniej).

Haczyk tkwi w funkcjonalności operacyjnej. Tańsze plany są wolniejsze w wyszukiwaniu, nie oferują pełnego indeksowania i zupełnie nie nadają się do alertowania o zagrożeniach w czasie rzeczywistym. Łączenie tych planów w jednym obszarze roboczym pozwala kierować krytyczne sygnały bezpieczeństwa do drogich tabel o wysokiej wydajności, a głośne logi zgodności przechowywać w tanich, pomocniczych magazynach.

Jak znacząco obniżyć koszty dzięki wczesnemu filtrowaniu i regułom zbierania danych

Najpoważniejszym błędem administratorów jest próba porządkowania danych dopiero wtedy, gdy trafiły już do obszaru roboczego. Od chwili zapisania rekordu dziennika płacisz już za jego pozyskanie.

Właściwe podejście opiera się na regułach zbierania danych (DCR) w połączeniu z agentem Azure Monitor. Reguły DCR działają jak zestawy instrukcji wdrażane na maszynach wirtualnych i klastrach kontenerów. Określają dokładnie, które zdarzenia zbierać, jak je przekształcać i do której tabeli trafiać. Co ważniejsze, pozwalają odrzucać powtarzalne szumy już u źródła.

Jeśli aplikacja generuje tysiące powtarzalnych logów informacyjnych co godzinę, których zespół nigdy nie przeszukuje, odrzuć je już na wejściu. Przekształcanie i filtrowanie danych przed trafieniem do silnika magazynowania sprawia, że nigdy nie zapłacisz za telemetrię, z której nie korzystasz.

Zagrożenia związane z dziennymi limitami pozyskiwania

Wobec nieprzewidywalnych rachunków za chmurę wielu menedżerów finansowych i IT traktuje funkcję dziennego limitu usługi Azure Log Analytics jako absolutną siatkę bezpieczeństwa. Dzienny limit wyznacza twardy próg pozyskiwania danych: po jego osiągnięciu obszar roboczy przestaje przyjmować nowe rekordy do końca dnia.

Choć zapobiega to nieoczekiwanym skokom kosztów, Microsoft wyraźnie ostrzega przed poleganiem na nim w rutynowym zarządzaniu kosztami. Gdy dzienny limit zostanie osiągnięty, zbieranie danych zatrzymuje się całkowicie. Analitycy bezpieczeństwa tracą widoczność, zespoły operacyjne działają po omacku, a jeśli w nocy wystąpi awaria systemu, przegapisz krytyczne alerty. Całkowita utrata widoczności podczas awarii prawie zawsze kosztuje więcej niż nieco wyższy rachunek za monitorowanie w chmurze.

Równoważenie interaktywnego przechowywania i długoterminowych archiwów

Kontrola kosztów sięga dalej niż pozyskiwanie danych i obejmuje także czas ich przechowywania. Domyślnie interaktywne przechowywanie zapewnia szybki dostęp do zapytań przez 31 dni (lub 90 dni, jeśli włączono usługę Microsoft Sentinel). Po upływie tego okresu dane nie znikają; przechodzą do magazynu długoterminowego.

Utrzymywanie danych dostępnych interaktywnie kosztuje miesięcznie znacznie więcej za gigabajt niż ich archiwizacja w magazynie długoterminowym. W przypadku wymogów zgodności nakazujących przechowywanie danych przez lata koszt archiwum wynosi grosze za gigabajt. Pamiętaj jednak, że odzyskanie zarchiwizowanych danych wymaga uruchomienia zadań wyszukiwania, a nie natychmiastowych zapytań interaktywnych, dlatego kluczowe jest wcześniejsze zaplanowanie strategii.

Podsumowanie i kolejne kroki

Zarządzanie cenami usługi Azure Log Analytics to świadome projektowanie architektury. Odchodząc od strategii zbierania wszystkiego w jednym miejscu, wykorzystując plany dostosowane do tabel i wdrażając rygorystyczne reguły zbierania danych u źródła, możesz zachować widoczność na poziomie przedsiębiorstwa bez przekraczania budżetu na chmurę.

Aby lepiej zrozumieć podstawy działania tych systemów, koniecznie posłuchaj całego odcinka podcastu M365 FM, w którym w przystępny sposób omówiono obszary robocze, tabele i podstawy zapytań KQL.

Często zadawane pytania

Czy utworzenie obszaru roboczego Azure Log Analytics jest bezpłatne?

Tak, utworzenie obszaru roboczego nie wiąże się z żadnymi opłatami podstawowymi. Płacisz wyłącznie za ilość pozyskanych danych w obszarze roboczym oraz za czas ich przechowywania.

Czym różnią się plany Analytics, Basic i Auxiliary Logs?

Plan Analytics zapewnia szybko działający, w pełni indeksowany magazyn zoptymalizowany pod kątem alertów bezpieczeństwa w czasie rzeczywistym i szybkich zapytań interaktywnych. Plany Basic i Auxiliary oferują znacznie tańsze magazyny dla danych, które są przeszukiwane rzadko lub przechowywane głównie na potrzeby zgodności i archiwizacji.

Dlaczego należy unikać dziennych limitów pozyskiwania?

Dzienne limity pozyskiwania całkowicie zatrzymują zbieranie danych po osiągnięciu progu wydatków. Oślepia to systemy bezpieczeństwa i monitorowania do końca dnia, co stwarza niedopuszczalne ryzyko podczas awarii systemów lub naruszeń bezpieczeństwa.

Jak zmniejszyć koszty pozyskiwania danych w usłudze Log Analytics?

Najskuteczniejszą strategią redukcji kosztów jest filtrowanie zbędnych danych logów u źródła za pomocą reguł zbierania danych (DCR – Data Collection Rules), tak aby szumne, nieczytane logi debugowania były odrzucane, zanim trafią do płatnego obszaru roboczego.