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 par l'humain. Cela est particulièrement utile lorsque vous devez vérifier que les transformations de votre pipeline produisent le résultat escompté.
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 le langage de transformation OpenTelemetry (OTTL) en ligne avec le bac à sable OTTL
Le bac à sable OTTL est un outil développé par la communauté qui vous permet de développer de manière interactive un pipeline de langage de transformation OpenTelemetry. Pour commencer, fournissez du JSON OTLP en entrée, écrivez votre pipeline en utilisant la même configuration que celle de votre collecteur OpenTelemetry, puis inspectez visuellement les résultats.
Le meilleur moyen d'obtenir du JSON OTLP à partir d'un pipeline consiste à placer un
file exportateur
à l'endroit où se trouverait votre processeur de transformation. 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 dans le bac à sable OTTL.
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, si 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 le 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.