Ce document décrit les étapes de dépannage et les problèmes courants liés à l'utilisation d'un collecteur OpenTelemetry, tel que le collecteur OpenTelemetry conçu par Google, pour envoyer des données à Google Cloud Observability.
Résoudre les problèmes de collecte de données
Cette section décrit les stratégies que vous pouvez utiliser pour résoudre les problèmes de collecte de données.
Utiliser l'exportateur debug
L'
debug exportateur
est le meilleur moyen d'afficher les données au niveau du collecteur OpenTelemetry. L'exportateur prend toutes les données qu'il reçoit et les écrit dans stdout dans un format lisible. Cela est particulièrement utile lorsque vous devez vérifier que les transformations de votre pipeline produisent le résultat souhaité.
L'exportateur debug est inclus dans le collecteur OpenTelemetry conçu par Google. Vous pouvez configurer l'exportateur debug avec verbosity: detailed pour afficher l'intégralité de la charge utile de télémétrie.
exporters:
debug:
verbosity: detailed
Vous pouvez inclure l'exportateur dans votre pipeline :
service:
pipelines:
metrics:
receivers: [
# ...
]
processors: [
# ...
]
exporters: [
debug, # can be added alongside any other configured exporters
# ...
]
Tester OpenTelemetry Transformation Language (OTTL) en ligne avec OTTL Playground
Le OTTL Playground est un outil développé par la communauté qui vous permet de développer de manière interactive un pipeline OpenTelemetry Transformation Language. Vous commencez par fournir du JSON OTLP en entrée, écrivez votre pipeline en utilisant la même configuration que pour votre collecteur OpenTelemetry, puis inspectez visuellement les résultats.
La meilleure façon d'obtenir du JSON OTLP à partir d'un pipeline consiste à placer un
file exportateur
à l'endroit où votre processeur de transformation se trouverait. Commencez par configurer un exportateur file :
exporters:
file:
path: example.json
Si vous aviez un pipeline comme celui-ci :
service:
pipelines:
metrics:
receivers: [hostmetrics]
processors: [
memorylimiter,
groupbyattrs,
transform, # where your OTTL pipeline will go
cumulativetodelta,
metricstarttime,
]
exporters: [
otlp,
]
Vous pouvez modifier temporairement votre pipeline pour exporter les données telles qu'elles apparaîtront dans le processeur transform sur lequel vous travaillez.
service:
pipelines:
metrics:
receivers: [hostmetrics]
processors: [
memorylimiter,
groupbyattrs,
# transform,
# cumulativetodelta,
# metricstarttime,
]
exporters: [
# otlp,
file,
]
L'exportateur file écrit chaque charge utile qu'il reçoit sur une ligne du fichier.
Vous pouvez utiliser une seule ligne de données comme entrée pour OTTL Playground.
Problèmes connus
Cette section décrit les problèmes connus liés au collecteur OpenTelemetry/collecteur OpenTelemetry conçu par Google et explique comment les contourner lorsque cela est possible.
Erreurs connect: network is unreachable excessives lors de l'utilisation de l'exportateur otlp
REMARQUE : Ce problème ne s'applique qu'à l'exportateur gRPC otlp, et non à l'exportateur HTTP
équivalent appelé otlphttp.
REMARQUE : Jusqu'à présent, ce problème n'a été observé directement que dans les environnements Compute Engine, mais en raison de sa nature, nous ne pouvons pas confirmer qu'il est réellement limité à Compute Engine.
À partir de la version
0.147.0 du collecteur OpenTelemetry conçu par Google et de la version 0.145.0 du collecteur OpenTelemetry en amont, l'exportateur otlpcommencera à utiliser par défaut la stratégie d'équilibrage de charge côté client
round_robin, alors qu'auparavant il s'agissait de pick_first. Lorsque l'exportateur utilisait auparavant la stratégie pick_first, il disposait également d'un basculement IPV4 entièrement fonctionnel dans un scénario où IPV6 ne fonctionnait pas. La stratégie round_robin ne possède pas cette propriété et tente à plusieurs reprises d'envoyer des données à toutes les adresses qu'elle résout au démarrage de l'exportateur, même lorsqu'elles ne fonctionnent pas.
Par conséquent, si vous utilisez l'exportateur otlp pour envoyer des données à l'API Telemetry, vous pouvez voir des messages d'erreur comme celui-ci :
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}
Isolation de l'erreur réelle du journal :
transport: Error while dialing: dial tcp [2607:f8b0:4001:c62::5f]:443: connect: network is unreachable
Pour contourner cette erreur, vous pouvez passer à l'exportateur otlphttp
(consultez notre guide de l'utilisateur sur les métriques OTLP pour obtenir un
exemple) ou configurer manuellement l'équilibreur pick_first sur l'exportateur otlp
:
exporters:
otlp:
# ...
balancer_name: pick_first
# ...
Si l'erreur persiste après l'une ou l'autre des solutions de contournement, il est probable que ce message d'erreur soit un symptôme de problèmes de connectivité réseau réels. Vous devrez donc vous assurer que votre collecteur peut réellement accéder au réseau.