OpenTelemetry Collector无法向Azure Data Explorer导出数据求助

我在将C++桌面应用的遥测数据发送至Azure Data Explorer（ADX）时遇到异常：遥测数据通过gRPC exporter发送至本地OpenTelemetry Collector后，Collector可成功将数据写入本地文件，但ADX中已创建的目标表始终无数据写入。

OpenTelemetry Collector未输出任何错误信息，增加了排查难度。我已完成ADX的Azure Active Directory应用注册流程。

附上OpenTelemetry Collector的YAML配置文件，希望能得到调试指导或可用示例参考。

配置文件（otel-collector.yml） #

receivers:
    otlp: # 应用发送trace的OTLP接收器
      protocols:
        grpc:
  
exporters:
    azuredataexplorer:
      cluster_uri: "https://<adx-clustor-name>.<region>.kusto.windows.net"
      application_id: "<app_id>"
      application_key: "<app-key>"
      tenant_id: "<tenent-id>" # 注意此处拼写错误：应为tenant_id
      db_name: "MyDatabase"
      metrics_table_name: "OTMetrics"
      logs_table_name: "OTLogs"
      traces_table_name: "OTTraces"
      ingestion_type : "managed"
    logging:
      #logLevel: info
    file: # 将日志写入本地文件的File Exporter
      path: "./app_example.json"
      rotation:
  
processors:
    batch:
  
service:
    pipelines:
      traces:
        receivers: [otlp]
        processors: [batch]
        exporters: [file, azuredataexplorer]
      metrics:
        receivers: [otlp]
        processors: [batch]
        exporters: [file, azuredataexplorer]
      logs:
        receivers: [otlp]
        processors: [batch]
        exporters: [file, azuredataexplorer]

OpenTelemetry Collector运行输出 #

C:\otel-collector>otelcol-contrib.exe  --config=C:\otel-collector\otel-collector-config.yaml
2023-06-06T12:00:07.889-0700    info    service/telemetry.go:113        Setting up own telemetry...
2023-06-06T12:00:07.890-0700    info    service/telemetry.go:136        Serving Prometheus metrics      {"address": ":8888", "level": "Basic"}
2023-06-06T12:00:07.891-0700    info    service/service.go:141  Starting otelcol-contrib...     {"Version": "0.77.0", "NumCPU": 32}
2023-06-06T12:00:07.891-0700    info    extensions/extensions.go:41     Starting extensions...
2023-06-06T12:00:07.891-0700    warn    internal/warning.go:51  Using the 0.0.0.0 address exposes this server to every network interface, which may facilitate Denial of Service attacks        {"kind": "receiver", "name": "otlp", "data_type": "traces", "documentation": "https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks"}
2023-06-06T12:00:07.892-0700    info    otlpreceiver@v0.77.0/otlp.go:94 Starting GRPC server    {"kind": "receiver", "name": "otlp", "data_type": "traces", "endpoint": "0.0.0.0:4317"}
2023-06-06T12:00:07.892-0700    info    service/service.go:158  Everything is ready. Begin running and processing data.

排查与调试建议 #

• 开启详细日志：修改logging exporter配置，将logLevel设为debug，查看ADX exporter的认证、数据发送细节，定位静默失败原因：

  logging:
    logLevel: debug
  

• 修正配置拼写错误：配置中tenant_id被误写为tenent-id，这会导致认证失败，是核心疑点，先修正该参数。
• 验证ADX表结构：确认OTMetrics、OTLogs、OTTraces表的结构与ADX exporter默认要求匹配，字段不匹配会导致数据被静默丢弃。
• 检查应用权限：确保注册的Azure AD应用在目标ADX数据库上拥有ingestor和monitor权限，可在ADX执行以下命令分配：

  .add database MyDatabase ingestors ('aadapp=<app_id>;<tenant_id>')
  .add database MyDatabase monitors ('aadapp=<app_id>;<tenant_id>')
  

• 查看ADX ingestion日志：在ADX中查询 ingestion 失败记录，确认是否有数据被拒绝：

  .show ingestion failures
  | where Database == "MyDatabase"
  

• 切换ingestion类型测试：将ingestion_type改为direct，测试是否能成功写入（direct适合调试，生产环境建议使用managed）。

内容的提问来源于stack exchange，提问作者shivi