Spis treści
1. Issue, które przetrwało kilka pomysłów
Temat powstał jako szerokie pytanie klienta: czym zastąpić lub uzupełnić centralne logowanie? Na liście były Elastic, Loki, OpenObserve, gotowy stack obserwowalności i działający już Seq. To był dobry problem do pozostawienia otwartego. Wybór silnika logów jest prosty w prezentacji, ale kosztowny w odwróceniu po zapisaniu setek milionów zdarzeń.
Ostatecznie wybraliśmy VictoriaLogs, ale nie dlatego, że tabela porównawcza obiecała najwięcej. Zbudowaliśmy lokalny PoC na produkcyjnej ścieżce .NET: Serilog wysyłał OTLP/HTTP protobuf bezpośrednio do VictoriaLogs. Sprawdziliśmy pola strukturalne, wyjątki, korelację, alert w Grafanie, restart z zachowaniem danych oraz obciążenie 2 621 440 rekordami.
2. Migracja bez skoku na głęboką wodę
Pierwsze wdrożenie nie usuwało Seq. Usługi klienta wysyłały te same logi równolegle do starego i nowego systemu. VictoriaLogs dostało osobny PVC, 14-dniową retencję, limit 80% zajęcia dysku, alerty Prometheusa i datasource w Grafanie. Najpierw canary, później wszystkie workloady produkcyjne.
Dual-write był polisą i narzędziem pomiarowym. Mogliśmy porównać liczbę zdarzeń dla tej samej usługi i tego samego okna czasu, sprawdzić kompletność pól oraz wycofać tylko nową gałąź eksportu. Dopiero po potwierdzeniu świeżych logów ze wszystkich aplikacji objętych migracją usunęliśmy sink Seq. Sam runtime i PVC Seq zniknęły w osobnym, ręcznie kontrolowanym kroku.
PoC
Prawdziwy format logów, zapytania, alerty i test obciążenia.
Dual-write
Ten sam ruch trafiał do Seq i VictoriaLogs podczas porównania.
Cutover
Najpierw wszystkie workloady, później osobne usunięcie starego storage.
3. Co naprawdę oznacza kompresja 20,72×
VictoriaLogs publikuje dwa liczniki: logiczny rozmiar danych przed kompresją i rozmiar skompresowanych bloków. Ich iloraz jest współczynnikiem kompresji. W migawce produkcyjnej suma wszystkich warstw storage wynosiła 576 120 523 443 bajty bez kompresji oraz 27 798 540 623 bajty po kompresji.
576,1 GB ÷ 27,8 GB = 20,72×
To nie jest marketingowy benchmark producenta ani porównanie wielkości plików z różną retencją. To bezpośredni odczyt metryk naszej instancji: vl_uncompressed_data_size_bytes podzielone przez vl_compressed_data_size_bytes. W tym samym momencie storage zawierał 433 453 901 rekordów, a liczniki odrzuconych wierszy raportowały zero.
Dokumentacja metryk VictoriaLogs →4. Dlaczego 50 GiB wystarcza
Stary Seq miał zaalokowany PVC 450 GiB. VictoriaLogs działa na 50 GiB, czyli dysku 9× mniejszym, i utrzymuje 14-dniowe okno logów. Limit 80% pozostawia miejsce na merge oraz operacje tymczasowe, a próg 10 GiB wolnej przestrzeni chroni bazę przed wejściem w niekontrolowany stan przy pełnym filesystemie.
20,72× i 9× opisują dwie różne rzeczy. Pierwsza liczba to efektywność kompresji danych zapisanych dziś. Druga to redukcja zaalokowanej pojemności względem starego systemu. Nie publikujemy procentu oszczędności rachunku, bo zależy on od cennika dostawcy i klasy wolumenu. Wiemy natomiast, że przestaliśmy utrzymywać 400 GiB zapasu na centralne logi, nie rezygnując z ustrukturyzowanych pól ani długości retencji VictoriaLogs.
5. MCP: od dashboardu do rozmowy z logami
VictoriaLogs ma oficjalny datasource do Grafany, więc logi i alerty można włączyć do istniejącego stacku obserwowalności. To wygodne, ale w tym wdrożeniu nie było dużym skokiem. Zespół korzysta głównie z natywnego VictoriaLogs VMUI, udostępnionego prywatnie przez Tailscale. Codzienny sposób ręcznego przeglądania logów pozostał więc podobny.
Rzeczywistą zmianą interfejsu jest dopiero oficjalny serwer VictoriaLogs MCP. Udostępnia klientom AI niemal wszystkie read-only API znane z interfejsu webowego. Agent może odkrywać streamy i pola, wykonywać LogsQL, liczyć zdarzenia i korzystać z osadzonej dokumentacji. Nie potrzebuje dostępu do powłoki klastra ani uprawnień do zmiany produkcji.
Przykład z przygotowania tego artykułu
Poprosiliśmy MCP o liczbę logów według service.name dla jednego pełnego dnia. Jedno zapytanie zwróciło 35 171 083 zdarzenia z siedmiu usług klienta. Najbardziej aktywny worker wygenerował 30 075 497 rekordów. Agent nie dostał eksportu CSV i nie przeklikiwał paneli. Zapytał źródło danych, dostał ustrukturyzowany wynik i mógł od razu zawęzić dalszą diagnozę.
To jest właściwy sens „AI-ready observability”. Nie chodzi o chatbot doklejony do Grafany. Chodzi o mały, kontrolowany interfejs, przez który agent potrafi sam zebrać dowody: policzyć błędy po usłudze, znaleźć pola korelacyjne, porównać okna przed i po wdrożeniu oraz pokazać konkretne zdarzenia. Człowiek nadal ocenia wniosek, ale przestaje ręcznie wykonywać każdy krok wyszukiwania.
Oficjalny serwer VictoriaLogs MCP →6. Co zmieniło się kosztowo i operacyjnie
Mniej storage
50 GiB zamiast 450 GiB zaalokowanej pojemności dla centralnych logów.
Mniej elementów
Aplikacje wysyłają OTLP bezpośrednio. Alloy i Jaeger nie są potrzebne w tej ścieżce.
Te same dane operacyjne
service.name, środowisko, SourceContext, severity, trace/span ID i exception.* pozostają polami zapytań.
Szybsza diagnoza
Ludzie korzystają z natywnego VMUI przez Tailscale, a MCP daje agentom read-only dostęp do tych samych logów.
Najważniejszą lekcją nie jest „zamień każdy system logów na VictoriaLogs”. Jest nią kolejność: najpierw rzeczywisty PoC, potem dual-write i porównanie, następnie wspólny cutover wszystkich producentów logów, a usunięcie starego storage dopiero na końcu. Kompresja daje oszczędność. MCP sprawia, że te same dane pracują częściej i szybciej podczas codziennego developmentu oraz incydentów.
Metodologia: wartości 20,72×, 576,1 GB, 27,8 GB i 433,5 mln rekordów pochodzą z endpointu /metrics produkcyjnej instancji z 9 września 2026. Dane identyfikujące klienta oraz nazwy jego usług zostały pominięte.
Masz trudny problem techniczny do rozwiązania?
Budujemy i rozwijamy systemy, kierując się metrykami DORA. Interesują nas precyzja, niezawodność i efektywność w CI/CD oraz na produkcji.
