Fehlerbehebung beim von Google entwickelten OpenTelemetry Collector

In diesem Dokument werden Schritte zur Fehlerbehebung und häufige Probleme bei der Verwendung eines OpenTelemetry Collector, z. B. des von Google entwickelten OpenTelemetry Collector, zum Senden von Daten an Google Cloud Observability beschrieben.

Fehlerbehebung bei der Datenerfassung

In diesem Abschnitt werden Strategien beschrieben, mit denen Sie Probleme bei der Datenerfassung beheben können.

Den debug-Exporter verwenden

Der debug Exporter ist die beste Möglichkeit, die Daten auf OpenTelemetry Collector-Ebene anzusehen. Der Exporter nimmt alle empfangenen Daten auf und schreibt sie in einem für Menschen lesbaren Format in die Standardausgabe. Das ist besonders nützlich, wenn Sie prüfen müssen, ob Transformationen in Ihrer Pipeline das gewünschte Ergebnis liefern.

Der debug-Exporter ist im von Google entwickelten OpenTelemetry Collector enthalten. Sie können den debug-Exporter mit verbosity: detailed konfigurieren, um die gesamte Telemetrie-Nutzlast zu sehen.

exporters:
  debug:
    verbosity: detailed

So fügen Sie den Exporter in Ihre Pipeline ein:

service:
  pipelines:
    metrics:
      receivers: [
        # ...
      ]
      processors: [
        # ...
      ]
      exporters: [
        debug, # can be added alongside any other configured exporters
        # ...
      ]

OpenTelemetry Transformation Language (OTTL) mit der OTTL Playground online testen

Die OTTL Playground ist ein von der Community entwickeltes Tool, mit dem Sie interaktiv eine OpenTelemetry Transformation Language-Pipeline entwickeln können. Dazu geben Sie OTLP-JSON als Eingabe an, schreiben Ihre Pipeline mit derselben Konfiguration wie für Ihren OpenTelemetry Collector und prüfen die Ergebnisse visuell.

Die beste Möglichkeit, OTLP-JSON aus einer Pipeline zu erhalten, besteht darin, einen file Exporter an der Stelle vor dem Transformationsprozessor zu platzieren. Konfigurieren Sie zuerst einen file-Exporter:

exporters:
  file:
    path: example.json

Wenn Sie eine Pipeline wie diese haben:

service:
  pipelines:
    metrics:
      receivers: [hostmetrics]
      processors: [
        memorylimiter,
        groupbyattrs,
        transform, # where your OTTL pipeline will go
        cumulativetodelta,
        metricstarttime,
      ]
      exporters: [
        otlp,
      ]

Sie können Ihre Pipeline vorübergehend so ändern, dass die Daten so exportiert werden, wie sie für den transform-Prozessor aussehen, an dem Sie gerade arbeiten.

service:
  pipelines:
    metrics:
      receivers: [hostmetrics]
      processors: [
        memorylimiter,
        groupbyattrs,
        # transform,
        # cumulativetodelta,
        # metricstarttime,
      ]
      exporters: [
        # otlp,
        file,
      ]

Der file-Exporter schreibt jede empfangene Nutzlast in eine Zeile in der Datei. Sie können eine einzelne Datenzeile als Eingabe für die OTTL Playground verwenden.

Bekannte Probleme

In diesem Abschnitt werden bekannte Probleme mit dem OpenTelemetry Collector/von Google entwickelten OpenTelemetry Collector und mögliche Problemumgehungen beschrieben.

Zu viele connect: network is unreachable-Fehler bei Verwendung des otlp-Exporters

HINWEIS: Dieses Problem betrifft nur den gRPC-otlp-Exporter, nicht den entsprechenden HTTP- -Exporter namens otlphttp.

HINWEIS: Dieses Problem wurde bisher nur in Compute Engine-Umgebungen beobachtet. Aufgrund der Art des Problems können wir jedoch nicht bestätigen, dass es wirklich auf Compute Engine beschränkt ist.

Ab der Version 0.147.0 des von Google entwickelten OpenTelemetry Collector und der Version 0.145.0 des OpenTelemetry Collector wird der otlp Exporter standardmäßig die clientseitige Load-Balancing Strategie round_robin verwenden. Zuvor war es pick_first. Wenn der Exporter zuvor die Strategie pick_first verwendet hat, hatte er auch ein voll funktionsfähiges IPV4-Fallback in einem Szenario, in dem IPV6 nicht funktioniert. Die Strategie round_robin hat diese Eigenschaft nicht und versucht wiederholt, Daten an alle Adressen zu senden, die beim Start des Exporters aufgelöst werden, auch wenn sie nicht funktionieren.

Wenn Sie den otlp-Exporter verwenden, um Daten an die Telemetry API zu senden, werden möglicherweise Fehlermeldungen wie diese angezeigt:

2026-02-13T20:50:00.665Z        warn    grpc@v1.78.0/clientconn.go:1526 [core] [Channel #1 SubChannel #18] grpc: addrConn.createTransport failed to connect to {Addr: "[2607:f8b0:4001:c62::5f]:443", ServerName: "telemetry.googleapis.com:443", }. Err: connection error: desc = "transport: Error while dialing: dial tcp [2607:f8b0:4001:c62::5f]:443: connect: network is unreachable"   {"resource": {"service.instance.id": "feb467f0-ecc6-4a0c-b1e2-90c908131fdd", "service.name": "otelcol-google", "service.version": "v0.147.0"}, "grpc_log": true}

So isolieren Sie den tatsächlichen Fehler im Log:

transport: Error while dialing: dial tcp [2607:f8b0:4001:c62::5f]:443: connect: network is unreachable

Um diesen Fehler zu umgehen, können Sie entweder zum otlphttp Exporter (ein Beispiel finden Sie in unserem OTLP-Messwerte-Nutzerhandbuch ) oder den pick_first Balancer manuell für den otlp Exporter konfigurieren:

exporters:
  otlp:
    # ...
    balancer_name: pick_first
    # ...

Wenn der Fehler nach einer der beiden Problemumgehungen weiterhin besteht, ist es wahrscheinlich, dass diese Fehlermeldung ein Symptom tatsächlicher Probleme mit der Netzwerkverbindung ist. Sie müssen also dafür sorgen, dass Ihr Collector das Netzwerk tatsächlich erreichen kann.