Gdzie powinny mieszkać logi systemu ERP? Baza operacyjna vs cold storage vs Application Insights

W każdej dyskusji o redukcji bazy Dynamics 365 Finance & Operations logi zajmują szczególne miejsce: są jednocześnie jednym z najcięższych i najmniej kwestionowanych składników. Ciężkie, bo przyrastają przy każdej operacji w systemie, nieprzerwanie, latami. Niekwestionowane, bo hasło „audyt” skutecznie ucina rozmowę o ich czyszczeniu. Tymczasem właściwe pytanie nie brzmi „czy logować” ani „czy przechowywać”, lecz „gdzie przechowywać”. Bo między potrzebą audytowalności a składowaniem logów w najdroższej możliwej warstwie nie ma żadnego logicznego związku. W tym artykule rozbieramy trzy architektury docelowe i pokazujemy, jak przenieść logi bez utraty ich funkcji.

‍

Po co w ogóle logujemy: audyt, compliance, diagnostyka

Zacznijmy od uczciwego przyznania racji zwolennikom logowania. Bo mają rację co do potrzeby, tylko nie co do miejsca. Potrzebujemy danych, które pozwolą obsłudze administracyjnej rozwiązania przeanalizować, co się wydarzyło: kto coś zmienił, kto przełączył ustawienie, kto zmodyfikował wartość w konkretnej komórce. To jest zrozumiałe i niepodważalne.

„Kto przełączył wajchę”. Realna wartość śladu audytowego

Ślad audytowy pełni trzy funkcje. Diagnostyczną: przy analizie incydentu odpowiedź na pytanie „co się zmieniło przed awarią” skraca czas rozwiązania z dni do godzin. Kontrolną: compliance i wartości wynikające z audytu pomagają wyplewić błędy procesowe. Powtarzające się ręczne korekty w jednym miejscu systemu to sygnał, że proces wymaga naprawy, a nie kolejnych korekt. Dowodową: w sporach wewnętrznych i zewnętrznych historia zmian bywa jedynym rozstrzygającym materiałem. Żadna z tych funkcji nie zniknie po przeniesieniu logów poza bazę operacyjną. Wszystkie wymagają jedynie, by logi istniały i dały się przeszukać.

‍

Dlaczego baza operacyjna ERP to najdroższe miejsce przechowywania logów

Skoro funkcje logów są niezależne od miejsca składowania, o miejscu powinien decydować rachunek. A ten jest jednoznaczny.

Koszt gigabajta: limit Database Storage Capacity vs zimne składowanieKoszt gigabajta: limit Database Storage Capacity vs zimne składowanie

Każdy gigabajt logów w bazie operacyjnej konsumuje limit Database Storage Capacity na równi z danymi transakcyjnymi. A przekroczenie limitu kosztuje od 337,20 do 448,80 EUR za gigabajt rocznie (stan na 2026 rok). Co gorsza, ciężar ten jest mnożony: środowiska testowe powstają jako kopie produkcji, więc każdy gigabajt logów produkcyjnych jest powielany w każdym sandboksie i liczony do wspólnej puli tenanta. Tymczasem zimne składowanie w chmurze kosztuje ułamki tych kwot. Mówimy o różnicy rzędów wielkości, nie procentów. Trzymanie wieloletniej historii logów w bazie ERP to płacenie stawki apartamentu w centrum za magazyn dokumentów, do którego zagląda się raz na kwartał.

Wpływ logów na wydajność operacji bieżących

Drugi koszt jest wydajnościowy. Tabele logów należą do najintensywniej zapisywanych w systemie. A im są większe, tym droższy staje się każdy kolejny zapis i tym dłużej trwają operacje utrzymaniowe na bazie: backupy, refreshe środowisk, konserwacja. Rosnące logi spowalniają więc nie tylko siebie, ale całe środowisko. Użytkownicy płacą czasem oczekiwania za dane, których nigdy nie zobaczą.

‍

Trzy architektury docelowe

Wybór docelowego miejsca zależy od tego, jak organizacja z logów korzysta. A konkretnie: jak często i jak wygodnie musi je przeszukiwać.

Cold storage: tanio, ale bez wygodnego przeszukiwania

Pierwsza architektura to eksport logów do zimnego składowania. Taniego magazynu obiektowego, w którym dane leżą jako pliki. Zalety: minimalny koszt i praktycznie nieograniczona pojemność, więc można trzymać historię tak długo, jak wymaga tego polityka. Wada: przeszukiwanie wymaga załadowania danych do narzędzia analitycznego, więc odpowiedź na pytanie audytowe zajmuje godziny, nie sekundy. To architektura właściwa dla logów starych, po które sięga się rzadko i bez presji czasu.

Application Insights: przeglądanie i alertowanie

Druga architektura to skierowanie logów do Application Insights. Usługi zaprojektowanej do gromadzenia i przeglądania danych diagnostycznych. Zalety: wygodne zapytania, wizualizacje i możliwość alertowania na wzorce zdarzeń, czyli funkcje, których baza ERP nigdy nie zaoferuje. To architektura właściwa dla logów świeżych, używanych czynnie w diagnostyce i monitoringu. Tam, gdzie liczy się czas dostępu do odpowiedzi.

Model hybrydowy: świeże pod ręką, historia na zewnątrz

W praktyce najlepiej sprawdza się połączenie: krótkie okno logów najświeższych pozostaje w zasięgu bieżącej diagnostyki, warstwa środkowa trafia do Application Insights, a historia. Do zimnego składowania. Granice między warstwami wyznacza realny wzorzec użycia: jak stare logi zespół faktycznie przeszukuje na co dzień, a po jakie sięga tylko przy audytach. Model hybrydowy godzi trzy interesy naraz. Koszt, wygodę i kompletność śladu. I dlatego to od niego warto zaczynać projektowanie.

‍

Jak przeprowadzić migrację logów bez utraty audytowalności

Przeniesienie logów to projekt o czterech krokach. Pierwszy: inwentaryzacja. Które tabele logów istnieją w środowisku, ile ważą i co dokładnie rejestrują; częstym odkryciem tego etapu jest logowanie włączone „na wszystko” lata temu i nigdy nierewidowane, więc sama rewizja zakresu logowania bywa pierwszym uzyskiem. Drugi: ustalenie wymagań. Z audytem wewnętrznym i compliance. Co musi pozostać przeszukiwalne, w jakim horyzoncie i z jakim czasem dostępu; to te odpowiedzi wyznaczają granice warstw modelu hybrydowego. Trzeci: uruchomienie eksportu do warstw docelowych i weryfikacja, że dane docierają kompletne i dają się przeszukać, zanim cokolwiek zostanie usunięte ze źródła. Czwarty: dopiero po tej weryfikacji czyszczenie historii z bazy operacyjnej i włączenie reguły cyklicznej, która utrzymuje w bazie tylko ustalone okno. Kolejność kroków jest istotą bezpieczeństwa tej operacji: w żadnym momencie nie istnieje luka, w której ślad audytowy byłby niedostępny.

‍

Ile można odzyskać: szacunek dla typowej instalacji

Skala uzysku zależy od wieku środowiska i zakresu logowania, ale kierunek jest wspólny: w instalacjach, w których logowanie działało latami bez rewizji, tabele logów należą do ścisłej czołówki najcięższych obiektów bazy. A ponieważ ich ciężar jest powielany w każdym sandboksie, realny uzysk liczy się razy liczba środowisk. Co równie ważne, to uzysk trwały: po wdrożeniu eksportu i reguły cyklicznej kategoria przestaje rosnąć w bazie operacyjnej, więc efekt nie eroduje z czasem, jak przy jednorazowym sprzątaniu. Dokładną wartość dla konkretnego środowiska wskazuje analiza rozmiarów tabel. I to od niej warto zacząć.

Od inwentaryzacji: które tabele logów istnieją, ile ważą i co rejestrują. Wykonanej na wiernej kopii produkcji analizą rozmiarów tabel. Częstym odkryciem jest zakres logowania włączony przed laty i nigdy nierewidowany, więc pierwszym uzyskiem bywa sama rewizja tego, co w ogóle warto rejestrować. Ile ważą logi w Twoim środowisku. I w ilu kopiach za nie płacisz? Skontaktuj się z nami. Wyślemy prostą instrukcję self-checku. Wystarczą zrzuty z Power Platform Admin Center i wynik skryptu SQL badającego rozmiary tabel na środowisku testowym, a przygotujemy estymację możliwych uzysków i ofertę fixed price na ich realizację.