如何在ELK中查看X-Ray追踪？如何将AWS X-Ray数据导入Elasticsearch

结合你现有 Elasticsearch + Kibana + Metricbeat 的技术栈，按生产落地优先级推荐以下方案：

首选方案：S3归档 + Filebeat 接入（生产环境最稳定） #

这套方案完全复用你现有的Beat运维体系，没有额外的自研维护成本，适合所有规模的无服务器应用：

• 在X-Ray控制台配置原生数据导出规则，按固定时间间隔（建议5分钟）将全量*原始追踪段（Trace Segment）*以JSON Lines格式归档到指定S3桶，该过程为AWS后台原生任务，不会占用Lambda计算资源、也不会造成链路追踪的性能损耗
• 直接在你现有部署Metricbeat的同批节点上启用Filebeat的AWS S3 Input插件，配置轮询对应S3桶的权限，插件可原生识别X-Ray导出的字段结构，无需手动编写Grok解析规则
• 在Elasticsearch端配置匹配的索引模板，将duration等延迟类字段映射为数值类型、trace_id/segment_id等标识类字段映射为keyword类型，即可直接在Kibana中搭建链路延迟分布、错误率、服务调用拓扑的可视化看板

次选方案：OpenTelemetry Collector 直连拉取（轻量低延迟） #

适合数据规模较小、对追踪数据实时性要求较高的场景，省去S3存储的中间环节：

• 在现有集群中部署与Metricbeat同节点的OpenTelemetry Collector实例，为实例绑定具备X-Ray只读权限的IAM角色（需包含xray:BatchGetTraces、xray:GetTraceSummaries操作权限）
• 配置X-Ray Receiver定时拉取最近时间窗口内的追踪数据，通过OTLP协议直接批量写入现有Elasticsearch集群，Collector已内置X-Ray字段的适配转换逻辑，无需二次格式加工
• 相比S3归档方案，数据端到端延迟可降低1-3分钟，且不会产生S3存储的额外成本

不推荐的应急方案：CloudWatch Logs 触发自定义转发 #

仅适合临时验证场景，长期运维成本较高：

• 开启X-Ray追踪数据的CloudWatch Logs投递功能，将追踪日志推送到指定日志组
• 编写简单的Lambda函数订阅日志组的数据流，批量将日志内容通过Elasticsearch的_bulk接口写入索引
• 该方案需自行实现错误重试、限流、数据去重逻辑，容易出现追踪数据丢点，且CloudWatch日志投递本身存在固定延迟，不适合长期生产使用

实操避坑提示

• X-Ray导出到S3的文件默认是gzip压缩格式，Filebeat可原生支持解压，无需手动处理压缩流程
• 同步时按需过滤X-Ray的全量注解、自定义元数据字段，仅保留观测所需的核心字段，可将索引存储体积降低60%以上
• 若使用Elasticsearch Serverless版本，可直接通过内置的AWS云服务数据连接器完成X-Ray数据接入，无需额外部署采集组件

内容的提问来源于stack exchange，提问作者Joey Yi Zhao