Lambda无法向同VPC内的APM服务器发送追踪数据求助

1. 优先检查VPC网络配置 #

• 确认Lambda函数已部署在APM服务器所在的VPC内，关联的子网路由表需指向VPC内部（避免仅配置互联网网关导致同VPC内流量走公网）。
• 检查安全组规则：
  • Lambda的安全组需允许出站访问TCP 8001端口（APM服务器的gRPC监听端口）。
  • APM服务器的安全组需允许来自Lambda安全组的TCP 8001端口入站请求。
• 尝试用APM服务器的私有IP地址替换域名配置exporter endpoint，排查是否存在DNS解析异常（同VPC内域名可能被解析到公网IP，导致跨VPC访问失败）。

2. 验证Collector gRPC Exporter配置 #

• 确认insecure: true与APM服务器的TLS配置匹配：如果APM服务器启用了TLS加密，需将该值改为false，并添加CA证书路径：

  tls:
    insecure: false
    ca_file: "/path/to/ca.crt"
  

• 检查authorization header中的Bearer Token是否有效，可临时移除headers配置进行测试，排除认证失败导致的发送阻塞。
• 确认APM服务器的8001端口确实监听gRPC协议（部分服务默认将OTLP gRPC端口设为4317，需核对服务器配置）。

3. 检查ADOT层的环境变量配置 #

• 确保已设置AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-instrument：该变量是ADOT自动注入追踪逻辑的核心，未配置可能导致追踪数据无法被Collector接收（虽X-Ray正常，但需确认X-Ray是否为ADOT转发还是Lambda原生集成）。
• 验证OPENTELEMETRY_COLLECTOR_CONFIG_URI指向的配置文件路径正确：若配置文件存于S3，需确保Lambda有读取该对象的权限；若为本地文件，需确认路径无误（用户代码已打印该变量，可查看CloudWatch日志确认值是否正确）。
• 排查冲突环境变量：如OTEL_TRACES_EXPORTER等变量可能覆盖Collector配置，需确保未设置此类优先级更高的变量。

4. 利用日志定位问题 #

• 查看Lambda的CloudWatch日志，重点关注ADOT Collector的输出：
  • 搜索failed to send、connection refused、unauthorized等关键词，定位发送阶段的具体错误。
  • 检查debug exporter的日志输出：若能看到完整trace数据，说明Collector接收正常，问题出在gRPC exporter发送环节；若debug无数据，则需排查追踪数据的生成或接收配置。

5. 直接测试gRPC连通性 #

在Lambda代码中添加gRPC连接测试，快速验证网络可达性：

import json
import os
import grpc

print('Loading function')

def test_grpc_connection():
    try:
        # 替换为APM服务器的域名或私有IP
        channel = grpc.insecure_channel('observability.dev.my-service.io:8001')
        grpc.channel_ready_future(channel).result(timeout=5)
        print("✅ GRPC connection to APM server successful")
    except Exception as e:
        print(f"❌ GRPC connection failed: {str(e)}")

def lambda_handler(event, context):
    test_grpc_connection()
    print(os.getenv('OPENTELEMETRY_COLLECTOR_CONFIG_URI'))
    print("value1 = " + event['key1'])
    print("value2 = " + event['key2'])
    print("value3 = " + event['key3'])
    return event['key1']

执行后查看日志，若连接失败可明确是网络或服务器端问题；若连接成功，则需回到Collector配置或权限排查。

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