Przyjmowanie danych OpenTelemetry za pomocą Zerobus Ingest

Zerobus Ingest OTLP to natywny punkt końcowy protokołu OpenTelemetry (OTLP) wbudowany w usługę Zerobus Ingest. Umożliwia przesyłanie śladów, dzienników i metryk bezpośrednio do tabel Delta w katalogu Unity przy użyciu standardowych zestawów SDK i modułów zbierających OpenTelemetry, bez konieczności używania bibliotek niestandardowych.

Aby skonfigurować klienta OTLP do wysyłania danych do Zerobus Ingest, zobacz Konfigurowanie klientów OpenTelemetry (OTLP) w celu wysyłania danych do Unity Catalog.

Azure Databricks rozlicza pozyskiwanie danych OTLP jako użycie usługi Zerobus Ingest. Aby poznać ceny i jak monitorować wydatki, zobacz Koszty.

Koncepcje

Poniższe pojęcia są przydatne do zrozumienia, jak działa Zerobus Ingest OTLP.

Zgodność OTLP

Zerobus Ingest OTLP implementuje standardowe usługi kolektora OTLP zgodnie ze specyfikacją OpenTelemetry, zarówno przez gRPC, jak i HTTP (Protobuf). Każdy eksporter zgodny z OTLP, taki jak OpenTelemetry SDK, OpenTelemetry Collector lub inna biblioteka instrumentacji, może przesyłać dane do tego punktu końcowego.

Obsługiwane sygnały

Zerobus Ingest OTLP udostępnia jedną usługę na każdy typ sygnału telemetrycznego. Każdy sygnał jest dostępny zarówno za pośrednictwem OTLP/gRPC, jak i OTLP/HTTP (Protobuf):

Sygnał ścieżka usługi gRPC Ścieżka HTTP
Ślady: Rozproszone ślady z pełną obsługą zdarzeń, połączeń i stanu. /opentelemetry.proto.collector.trace.v1.TraceService/Export /v1/traces
Dzienniki: Rekordy dzienników z poziomem ważności, treścią i korelacją ze śladami za pomocą trace_id i span_id. /opentelemetry.proto.collector.logs.v1.LogsService/Export /v1/logs
Metryki: wszystkie pięć typów metryk OTLP: Wskaźnik, Suma, Histogram, Histogram wykładniczy i Podsumowanie. /opentelemetry.proto.collector.metrics.v1.MetricsService/Export /v1/metrics

Powodzenie częściowe

Zerobus Ingest OTLP obsługuje częściowe powodzenie zgodnie ze specyfikacją OTLP. Jeśli żądanie zawiera kombinację prawidłowych i nieprawidłowych rekordów, prawidłowe rekordy są pozyskiwane, a nieprawidłowe rekordy są odrzucane. Odpowiedź zawiera liczbę odrzuconych rekordów (rejected_spans, rejected_log_records lub rejected_data_points) i error_message, które opisuje przyczynę.

Kompresja

Kompresja Gzip jest obsługiwana we wszystkich trzech usługach OTLP, zarówno przez gRPC, jak i HTTP. Dla gRPC ustaw nagłówek grpc-encoding na .gzip Dla HTTP ustaw nagłówek Content-Encoding na .gzip Alternatywnie, skonfiguruj eksporter OTLP tak, aby używał kompresji gzip.

Ograniczenia

  • Obsługiwane jest tylko kodowanie w formacie Protobuf dla OTLP/HTTP. OTLP/HTTP z treścią w formacie JSON nie jest obsługiwany, a żądania z elementem Content-Type o wartości application/json są odrzucane.
  • Każde żądanie dotyczy jednej tabeli określonej przy użyciu nagłówka x-databricks-zerobus-table-name . Aby pozyskiwać ślady, dzienniki i metryki, skonfiguruj oddzielne eksportery wskazujące na różne tabele.
  • Tabele muszą zostać utworzone z wyprzedzeniem przy użyciu poprawnego schematu. Zerobus Ingest nie tworzy ani nie modyfikuje tabel.
  • Domyślny limit przydziału to 10 000 żądań na sekundę. Jeśli potrzebujesz wyższego limitu przydziału, skontaktuj się z przedstawicielem usługi Databricks.
  • Niektóre pola numeryczne OTLP mogą tracić precyzję lub ulegać przepełnieniu podczas mapowania na typy Delta. Zobacz Precyzja numeryczna i typy znaków.
  • Pełną listę kwot Zerobus Ingest można znaleźć w artykule Zerobus Ingest quotas.

Dodatkowe zasoby

  • Last updated on