• OpenTelemetry – wspólny standard dla telemetryki
    Informatyka

    OpenTelemetry – wspólny standard dla telemetryki

    Marek „Netbe” Lampart Opublikowane w

    OpenTelemetry – wspólny standard dla telemetryki

    OpenTelemetry (OTel) to otwarty, vendor-neutral standard i zestaw narzędzi do zbierania metryk, logów i śladów rozproszonych (traces).

    To ważne, bo w naszej dotychczasowej układance OpenTelemetry nie jest bezpośrednim konkurentem Zabbixa, Loki czy Wazuha. Ono przede wszystkim łączy świat aplikacji z systemami observability.

                        APPLICATION
                         |
              +----------+----------+
              |          |          |
           Metrics      Logs      Traces
              |          |          |
              +----------+----------+
                         |
                  OpenTelemetry
                         |
             +-----------+-----------+
             |           |           |
          Prometheus    Loki       Tempo
             |           |           |
             +-----------+-----------+
                         |
                       Grafana

    Co właściwie zbiera OpenTelemetry?

    Trzy podstawowe rodzaje telemetryki:

                     Telemetry
                     |
        +------------+------------+
        |            |            |
      Metrics       Logs        Traces
        |            |            |
     "ile?"       "co?"       "gdzie?"

    Metrics

    Informują o stanie i wydajności:

    CPU
Requests/sec
Memory
Latency
Error rate

    Logs

    Informują o wydarzeniach:

    ERROR Database connection failed
User login successful
Payment completed

    Traces

    Pokazują drogę konkretnego żądania przez system:

    User
 |
 v
API
 |
 v
Auth Service
 |
 v
Database
 |
 v
Redis

    I właśnie traces są jednym z najważniejszych elementów odróżniających OpenTelemetry od klasycznego monitoringu.

    Distributed Tracing

    Załóżmy, że użytkownik otwiera sklep internetowy:

    Browser
   |
   v
Frontend
   |
   v
API
   |
   +----> Authentication
   |
   +----> Product Service
   |          |
   |          v
   |       Database
   |
   +----> Payment

    Użytkownik widzi:

    Page load: 3.8 seconds

    Ale dlaczego?

    OpenTelemetry może pokazać:

    Frontend          100 ms
API               150 ms
Authentication     80 ms
Product Service   120 ms
Database         2800 ms  ← problem
Payment            50 ms

    Nagle wiadomo, że problemem nie jest frontend, tylko baza danych.

    Trace

    Trace reprezentuje całą operację:

    Trace ID: abc123

User Request
    |
    +-- Span: API
    |
    +-- Span: Auth
    |
    +-- Span: Product
          |
          +-- Span: PostgreSQL

    Każdy fragment operacji jest reprezentowany przez span.

    Trace
 |
 +-- Span
 |
 +-- Span
      |
      +-- Child Span
      |
      +-- Child Span

    Dlaczego Trace ID jest ważny?

    Możemy połączyć:

    Metric
   +
Log
   +
Trace

    na podstawie wspólnego kontekstu.

    Przykład:

    HTTP 500
    |
    v
Trace ID
    |
    +--> API
    +--> Payment
    +--> PostgreSQL

    Zamiast szukać ręcznie po tysiącach logów, możemy przejść od alertu bezpośrednio do konkretnego requestu.

    OpenTelemetry Collector

    Jednym z najważniejszych komponentów jest OpenTelemetry Collector.

    Możemy go potraktować jako centralny punkt zbierania i przesyłania telemetryki:

    Applications
     |
     v
OpenTelemetry Collector
     |
 +---+---+---+
 |   |   |   |
 v   v   v   v
Prom Loki Tempo Elastic

    Collector może:

    • odbierać dane,
    • przetwarzać je,
    • filtrować,
    • wzbogacać,
    • eksportować do różnych backendów.

    Collector jako „router telemetryki”

    To bardzo dobre mentalne uproszczenie:

                      OpenTelemetry
                      Collector
                         |
        +----------------+----------------+
        |                |                |
     Metrics            Logs             Traces
        |                |                |
        v                v                v
   Prometheus           Loki             Tempo

    Dzięki temu aplikacja nie musi być bezpośrednio związana z jednym dostawcą observability.

    Vendor-neutral

    To jedna z najważniejszych idei OTel.

    Bez OpenTelemetry:

    Application
    |
    v
Vendor SDK
    |
    v
Vendor Backend

    Migracja może być problematyczna.

    Z OpenTelemetry:

    Application
    |
    v
OpenTelemetry
    |
    v
Collector
    |
 +--+--+--+
 |  |  |
 A  B  C

    Możemy zmienić backend bez przepisywania całej instrumentacji aplikacji.

    Instrumentacja

    Aplikacja musi wiedzieć, jakie dane telemetryczne generować.

    Możemy zrobić to na kilka sposobów:

    Application
    |
    +--> Automatic Instrumentation
    |
    +--> Manual Instrumentation
    |
    +--> Libraries

    Przykładowo aplikacja może automatycznie generować informacje dotyczące:

    HTTP
Database
gRPC
Redis
Messaging

    OpenTelemetry i Kubernetes

    OpenTelemetry bardzo dobrze pasuje do Kubernetes.

                        Kubernetes
                        |
        +---------------+---------------+
        |               |               |
       Pod             Pod             Pod
        |               |               |
       OTel            OTel            OTel
        +---------------+---------------+
                        |
                        v
                OTel Collector
                        |
              +---------+---------+
              |         |         |
           Metrics     Logs     Traces

    W dużym klastrze Collector może działać jako centralny komponent telemetryczny.

    OpenTelemetry + Prometheus

    OpenTelemetry może zbierać metryki, które następnie trafiają do systemu metryk.

    Application
     |
OpenTelemetry
     |
Collector
     |
     v
Prometheus
     |
     v
Grafana

    Czyli:

    OTel → telemetry collection
Prometheus → metrics backend
Grafana → visualization

    OpenTelemetry + Loki

    Możemy również przesyłać logi:

    Application
     |
OpenTelemetry
     |
Collector
     |
     v
Loki
     |
     v
Grafana

    Wtedy OpenTelemetry staje się warstwą zbierania, a Loki warstwą przechowywania i wyszukiwania logów.

    OpenTelemetry + Tempo

    To szczególnie naturalne połączenie dla traces.

    Application
     |
OpenTelemetry
     |
Collector
     |
     v
Tempo
     |
     v
Grafana

    Tempo jest backendem przeznaczonym do distributed tracing.

    OpenTelemetry + Elastic

    Możemy również wysyłać telemetrykę do Elastic:

    Applications
      |
OpenTelemetry
      |
Collector
      |
      v
Elastic
      |
      v
Kibana

    Daje to możliwość wykorzystania jednego ekosystemu do analizy różnych typów danych.

    OpenTelemetry + Graylog

    Podobnie można wykorzystać OTel w architekturze z Graylogiem, szczególnie gdy chcemy ujednolicić sposób zbierania telemetryki z aplikacji.

    Application
     |
OpenTelemetry
     |
Collector
     |
     v
Log Backend
     |
   Graylog

    Trzeba jednak dobrać odpowiedni sposób transportu i format danych do konkretnej instalacji.

     

    OpenTelemetry – wspólny standard dla telemetryki
    OpenTelemetry – wspólny standard dla telemetryki

    OpenTelemetry vs Zabbix

    To nie są zamienniki.

    Zabbix:

    Server
 |
 +--> CPU
 +--> RAM
 +--> Disk
 +--> Network
 +--> Availability

    OpenTelemetry:

    Application
 |
 +--> Metrics
 +--> Logs
 +--> Traces

    Zabbix jest bardzo mocny w monitoringu infrastruktury.

    OpenTelemetry jest szczególnie mocne w application observability.

    OpenTelemetry vs Prometheus

    Również nie są bezpośrednimi odpowiednikami.

    OpenTelemetry
→ zbieranie i transport telemetryki

Prometheus
→ monitoring i przechowywanie/odpytywanie metryk

    Możemy więc mieć:

    Application
     |
OpenTelemetry
     |
Collector
     |
Prometheus

    OpenTelemetry vs Loki

    OpenTelemetry → collect/process
Loki           → store/search logs

    To może być współpraca, a nie konkurencja.

    OpenTelemetry vs Wazuh

    Tutaj różnica jest jeszcze większa:

    OpenTelemetry
→ Observability

Wazuh
→ Security

    OpenTelemetry może dostarczać telemetrykę, ale nie jest systemem SIEM ani narzędziem do wykrywania zagrożeń w rozumieniu Wazuha.

    OpenTelemetry vs ELK

    Elastic jest przede wszystkim platformą backendową/analityczną, natomiast OTel może być warstwą instrumentacji i transportu.

    Application
     |
OpenTelemetry
     |
Collector
     |
Elastic
     |
Kibana

    To bardzo sensowna architektura.

    Correlation – największa wartość

    Największa siła nowoczesnego observability pojawia się wtedy, gdy możemy połączyć:

    Metrics
  +
Logs
  +
Traces

    Przykład:

                  HTTP latency ↑
                     |
                     v
                  Trace
                     |
             +-------+-------+
             |               |
           API             Database
                             |
                             v
                       Slow Query
                             |
                             v
                            Log

    Teraz administrator nie tylko wie, że aplikacja jest wolna, ale również dlaczego.

    OpenTelemetry w mikroserwisach

    W monolicie:

    Application
    |
Database

    jest stosunkowo łatwo znaleźć problem.

    W mikroserwisach:

    API
 |
 +--> Auth
 |
 +--> Orders
 |      |
 |      +--> Database
 |
 +--> Payment
        |
        +--> External API

    jedno żądanie może przechodzić przez kilkanaście usług.

    Distributed tracing staje się wtedy niezwykle wartościowy.

    Przykład realnego problemu

    Użytkownik zgłasza:

    Strona zamówienia działa bardzo wolno.

    Prometheus pokazuje:

    API latency ↑

    Loki pokazuje:

    Database timeout

    OpenTelemetry pokazuje:

    Order API
   |
   +--> Auth: 30ms
   +--> Orders: 50ms
   +--> Payment: 80ms
   +--> PostgreSQL: 4200ms

    Zabbix pokazuje:

    Database Server
CPU: 35%
RAM: 60%
Disk: OK

    Czyli problem nie wynika z przeciążenia serwera.

    Trace wskazuje natomiast konkretną operację bazodanową.

    To jest właśnie różnica między zwykłym monitoringiem a pełnym observability.

    OpenTelemetry w pełnej architekturze

    Patrząc na wszystkie narzędzia, które omawialiśmy:

                                  APPLICATIONS
                                   |
                    +--------------+--------------+
                    |              |              |
                 Metrics          Logs          Traces
                    |              |              |
                    +--------------+--------------+
                                   |
                           OpenTelemetry
                                   |
                            OTel Collector
                                   |
             +---------------------+---------------------+
             |                     |                     |
             v                     v                     v
        Prometheus               Loki                 Tempo
             |                     |                     |
             +---------------------+---------------------+
                                   |
                                Grafana

    A równolegle:

    INFRASTRUCTURE
      |
      v
    Zabbix
      |
Metrics / Availability

    oraz:

    SECURITY
   |
   +--> Wazuh
   +--> Suricata
   +--> Zeek
   +--> Graylog / Elastic

    Najważniejsza układanka

    Po dodaniu OpenTelemetry cały zestaw można uporządkować tak:

    Zabbix
→ Infrastructure Monitoring

Prometheus
→ Metrics

OpenTelemetry
→ Telemetry Collection / Instrumentation

Loki
→ Logs

Tempo
→ Traces

Grafana
→ Visualization

Graylog
→ Log Management

Elastic
→ Search / Analytics / SIEM

Wazuh
→ Security Monitoring

Suricata
→ IDS/IPS

Zeek
→ Network Visibility

    OpenTelemetry jest więc swego rodzaju „kręgosłupem telemetrycznym” nowoczesnej aplikacji. Nie musi zastępować Prometheusa, Loki, Tempo czy Elastic — jego zadaniem jest sprawić, żeby aplikacja mogła w ustandaryzowany sposób dostarczać metrics + logs + traces do wybranego backendu.

    Polecane wpisy
    Darknet, czyli ciemna strona internetu
    Darknet, czyli ciemna strona internetu

    Darknet, czyli ciemna strona internetu, to część sieci, która nie jest widoczna dla zwykłych przeglądarek internetowych. Jest to miejsce, gdzie Czytaj dalej

    Podłączenie telewizora do internetu przez WiFi
    Podłączenie telewizora do internetu przez WiFi

    Podłączenie telewizora do internetu przez WiFi Współczesne telewizory Smart TV oferują szereg funkcji, które wymagają dostępu do internetu. Dzięki temu Czytaj dalej

    Marek „Netbe” Lampart
    Marek "Netbe" Lampart Inżynier informatyki Marek Lampart to doświadczony inżynier informatyki z ponad 25-letnim stażem w zawodzie. Specjalizuje się w systemach Windows i Linux, bezpieczeństwie IT, cyberbezpieczeństwie, administracji serwerami oraz diagnostyce i optymalizacji systemów. Na netbe.pl publikuje praktyczne poradniki, analizy i instrukcje krok po kroku, pomagając administratorom, specjalistom IT oraz zaawansowanym użytkownikom rozwiązywać realne problemy techniczne.
    Zobacz wszystkie wpisy

    Może ci się spodobać również