OpenObserve jako alternatywa dla Datadog i Elasticsearch

Logi rzadko trafiają na zebranie zarządu. Do momentu, w którym ktoś zauważa, że rachunek za ich przechowywanie jest wyższy niż za serwery, na których działa sama aplikacja. Wtedy pada pytanie, czy da się taniej. OpenObserve jako alternatywa dla Datadog i Elasticsearch to jedna z odpowiedzi, które coraz częściej pojawiają się w takich rozmowach.

Datadog i Elasticsearch to dwa różne światy. Pierwszy to usługa w chmurze, za którą płaci się co miesiąc według tego, ile się monitoruje. Drugi to silnik, który firma stawia na własnych serwerach i sama utrzymuje. OpenObserve próbuje zastąpić oba, z innego powodu w każdym przypadku.

OpenObserve jako alternatywa dla Datadog i Elasticsearch - co to jest

OpenObserve to platforma do obserwowalności (observability), czyli zbierania i przeglądania danych o tym, co dzieje się w działającej aplikacji. Obsługuje trzy podstawowe rodzaje takich danych: logi, czyli zapisy zdarzeń, metryki, czyli liczby mierzone w czasie, oraz ślady żądań, które pokazują drogę jednego kliknięcia przez wiele usług. Ten ostatni temat dobrze wyjaśnia wpis o distributed tracing. Do tego dochodzą dashboardy, alerty i monitorowanie doświadczeń użytkowników w przeglądarce.

Projekt jest napisany w języku Rust i udostępniony jako open source. Według repozytorium na GitHubie ma około 21 tys. gwiazdek. Dane można przeszukiwać w SQL, a metryki w PromQL, czyli języku zapytań znanym z Prometheusa. Zespół, który zna te narzędzia, nie musi uczyć się nowego, zamkniętego języka. Najważniejsza różnica leży jednak niżej, w sposobie przechowywania danych. Od niej zależy większość kosztów.

Rachunek pierwszy: abonament i licencja

Datadog rozlicza się w kilku wymiarach jednocześnie: od monitorowanych hostów, od ilości przyjmowanych i przechowywanych logów, od dodatkowych produktów. Cennik Datadog jest szczegółowy, ale przy rosnącej infrastrukturze trudno przewidzieć, ile wyniesie rachunek za pół roku. Każdy nowy serwer i każda nowa usługa coś dokładają. OpenObserve ma prostszy model. Według cennika OpenObserve (stan na październik 2026) wersja w chmurze kosztuje w planie Professional 0,50 USD za każdy przyjęty gigabajt danych przy rocznym zobowiązaniu oraz 0,01 USD za każdy gigabajt przeszukany zapytaniami. Nie ma opłat za użytkownika ani za host. Logi i ślady są przechowywane 30 dni, metryki 15 miesięcy, a dłuższa retencja kosztuje 0,02 USD za gigabajt za każde dodatkowe 30 dni.

Dla porównania orientacyjnego: firma, która wysyła 100 GB logów dziennie, czyli około 3000 GB miesięcznie, zapłaci w chmurze OpenObserve za samo przyjęcie danych około 1500 USD miesięcznie, plus opłaty za zapytania. Gdyby wybrała wersję na własnych serwerach, rachunek za licencję spada do zera. Wersja open source jest darmowa bez limitu, a wersja Enterprise z logowaniem SSO i rozbudowanymi uprawnieniami jest bezpłatna do 50 GB dziennie.

Przy Elasticsearch ten rachunek wygląda inaczej. Sam silnik można uruchomić bez opłat, a płatna jest wersja chmurowa Elastic albo subskrypcja z dodatkowymi funkcjami. Główny koszt Elasticsearch leży gdzie indziej. W drugim rachunku.

Rachunek drugi: serwery i dyski

Elasticsearch, popularny element zestawu ELK, zbudowano przede wszystkim do szybkiego wyszukiwania tekstu. Robi to dzięki indeksowi odwróconemu, czyli spisowi, który dla każdego słowa pamięta, w których dokumentach występuje. To działa świetnie, ale ma cenę: indeks bywa tak duży jak same dane, a dla bezpieczeństwa przechowuje się go w kilku kopiach na szybkich dyskach SSD. Klaster Elasticsearch z logami z kilku miesięcy potrafi zajmować wiele terabajtów drogiej przestrzeni.

OpenObserve robi to inaczej. Zapisuje dane w formacie Parquet, który przechowuje je kolumnami i bardzo dobrze kompresuje powtarzalne wartości, a w logach powtarzalności jest dużo. Pliki trafiają do magazynu obiektowego, takiego jak Amazon S3 lub jego odpowiednik w innej chmurze, gdzie gigabajt kosztuje ułamek ceny dysku SSD w serwerze. Producent podaje, że koszty przechowywania mogą być nawet 140 razy niższe niż w Elasticsearch. Na stronie porównawczej OpenObserve sam zastrzega jednak, że faktyczna oszczędność zależy od rodzaju danych, liczby kopii i długości przechowywania. Traktujemy to jako górną granicę, a nie obietnicę. Nawet kilkukrotna różnica przy kilkudziesięciu terabajtach logów zmienia budżet infrastruktury.

Dla firm, które działają w chmurze AWS, oznacza to też prostszą architekturę. Część z nich trzyma dziś logi w Amazon CloudWatch, którego koszt również rośnie wraz z ilością danych. Zamiast klastra z wieloma węzłami i dyskami trzeba utrzymać mniejszą liczbę serwerów obliczeniowych, a dane leżą w S3 z jego trwałością i cyklem życia, na przykład automatycznym przenoszeniem starszych logów do tańszej klasy przechowywania.

Rachunek trzeci: ludzie i utrzymanie

Ten rachunek nie pojawia się na fakturze, a często jest najwyższy. Elasticsearch działa na maszynie wirtualnej Javy, która wymaga strojenia pamięci. Zespół, który go utrzymuje, zna dobrze nocne alerty o przepełnionej pamięci, wolnych zapytaniach i węzłach, które wypadły z klastra. Do tego dochodzą aktualizacje wersji, które w dużym klastrze trzeba planować jak osobny projekt. OpenObserve jest pojedynczym programem, który można uruchomić w kilka minut w kontenerze Docker, a w środowisku produkcyjnym w klastrze Kubernetes w trybie wysokiej dostępności, instalowany na przykład za pomocą pakietów Helm. Rust nie ma problemu z pauzami odśmiecania pamięci, który zna każdy, kto utrzymywał Elasticsearch. To realnie zmniejsza liczbę rzeczy, które mogą się zepsuć. Nie oznacza to, że utrzymanie znika. Ktoś musi aktualizować system, pilnować retencji, konfigurować alerty i odpowiadać, gdy coś przestanie zbierać dane. W większych firmach to zadanie zespołu SRE, odpowiedzialnego za niezawodność systemów. W porównaniu z Datadogiem, gdzie to wszystko robi dostawca, wersja na własnych serwerach przenosi część kosztu z faktury na zespół. Taką pracę wykonuje zespół od DevOps i architektury, wewnętrzny albo zewnętrzny.

Jest jeszcze licencja. Wersja open source OpenObserve jest udostępniona na licencji AGPL-3.0. Przy używaniu narzędzia wewnętrznie do monitorowania własnych aplikacji nie rodzi to żadnych obowiązków. Znaczenie ma dopiero wtedy, gdy firma chce zmodyfikować OpenObserve i udostępniać je jako usługę innym, bo wtedy musi opublikować swoje zmiany. Dla większości firm to szczegół, ale przed wdrożeniem dobrze, żeby ktoś go sprawdził.

Czego OpenObserve nie zastąpi

Elasticsearch jest używany do dwóch zupełnie różnych rzeczy i to łatwo przeoczyć. Pierwsza to logi, i tu OpenObserve jest rozsądną alternatywą. Druga to wyszukiwarka w produkcie, na przykład wyszukiwanie produktów w sklepie internetowym, z podpowiedziami, literówkami i trafnością wyników. Tu OpenObserve nie konkuruje i producent mówi to wprost: w ogólnym wyszukiwaniu dokumentów indeks odwrócony Elasticsearch pozostaje najlepszy w swojej klasie. Jeśli sklep korzysta z Elasticsearch jako wyszukiwarki, ta część zostaje bez zmian. Po stronie Datadoga różnica dotyczy dojrzałości i zasięgu. Datadog ma setki gotowych integracji, rozbudowane funkcje bezpieczeństwa i lata dopracowywania szczegółów. Podobnie jak New Relic czy Splunk, sprzedaje wygodę: instalujesz agenta i większość rzeczy działa od razu. W OpenObserve część tej pracy trzeba wykonać samemu, zwłaszcza przy nietypowych źródłach danych.

Nie zastąpi też narzędzi wyspecjalizowanych. Śledzenie błędów aplikacji z grupowaniem wyjątków i informacją o tym, którego użytkownika dotyczą, lepiej robi Sentry. Wiele zespołów łączy oba narzędzia i nie ma w tym nic złego.

Jak przejść bez dnia przerwy w monitoringu

Zmiana narzędzia do monitoringu ma jedną zasadę: przez cały czas ktoś musi widzieć, co się dzieje w produkcji. Dlatego nie wyłącza się starego systemu, dopóki nowy nie udowodni, że działa. W praktyce przejście wygląda tak:

• wysyłanie danych przez OpenTelemetry, otwarty standard zbierania logów, metryk i śladów, albo przez kolektory takie jak Fluent Bit i Logstash, w których OpenObserve jest zgodne z API Elasticsearch, więc wystarczy dodać drugi adres docelowy,
• równoległe działanie obu systemów przez kilka tygodni, z tymi samymi danymi trafiającymi w dwa miejsca,
• odtworzenie najważniejszych dashboardów i alertów, zaczynając od tych, które budzą ludzi w nocy,
• sprawdzenie alertów na prawdziwym incydencie albo kontrolowanej awarii w środowisku testowym,
• wyłączenie starego systemu dopiero wtedy, gdy zespół przez dłuższy czas pracuje tylko na nowym.

Najwięcej czasu zajmuje zwykle trzeci krok. Dashboardy i alerty w Datadogu czy Kibanie powstawały latami i nikt nie pamięta, po co jest połowa z nich. To dobry moment na porządki, podobny do spłaty długu technologicznego: przenieść tylko to, z czego ktoś naprawdę korzysta.

Wizualizację dla zespołów przyzwyczajonych do Grafany można zostawić bez zmian, bo Grafana łączy się z wieloma źródłami danych. Alerty z OpenObserve mogą trafiać tam, gdzie zespół i tak pracuje, na przykład na Slacka.