Fleet 负载测试环境中的 SigNoz OpenTelemetry 追踪：Terraform 部署、OTLP 采集与 ClickHouse 存储运维指南

后端前端企业应用运维网络安全【免费下载链接】fleetOpen device management项目地址https://gitcode.com/GitHub_Trending/fl/fleet点击查看免费下载SigNoz 是 Fleet 负载测试loadtesting环境中的 OpenTelemetry 追踪后端以独立 Terraform 根模块root module形式部署确保在 Fleet 主基础设施启动之前即可开始采集遥测数据。本文基于 infrastructure/loadtesting/terraform/signoz/README.md 展开结合模块内的 main.tf、otel-collector-values.yaml、outputs.tf 等源码完整讲解从架构设计、部署顺序、Fleet 侧集成、OTLP Collector 调优到 ClickHouse 存储治理与销毁清理的端到端实战方案。读完本文你将能够独立部署一套面向高并发负载测试的 OpenTelemetry 可观测性栈并正确地把 Fleet 服务器的追踪数据接入 SigNoz 进行链路分析。SigNoz 在 Fleet 负载测试体系中的定位Fleet 的负载测试基础设施位于 infrastructure/loadtesting/terraform 目录由多个相互独立的 Terraform 根模块组成共享 VPCshared、SigNozsignoz、Fleet 主基础设施infra以及 Android AMAPI mock、osquery 性能测试、PMM 监控等配套模块。SigNoz 模块的职责非常单一为 Fleet 负载测试环境提供 OpenTelemetry 追踪能力。为什么选 SigNoz 而不是 Elastic APM从 infra/locals.tf 的注释可以读到关键决策背景OpenTelemetry 是唯一被采用的追踪方案Elastic APM 不被支持。原因是其埋点instrumentation是 gorilla 专属的当 Elastic APM 激活时Fleet 服务器会关闭标准库 ServeMux 的快速路径fast path这对负载测试来说追踪带来的开销远大于收益。因此负载测试默认完全关闭追踪只有显式设置enable_oteltrue时才启用。架构总览SigNoz 模块的架构要点README 中的 Architecture 一节EKS 集群每个工作区workspace一套独立集群命名形如signoz-victor-baseline前缀signoz-加上当前 Terraform workspace 名见 main.tf 中的local.cluster_name signoz-${terraform.workspace}Kubernetes 版本v1.31节点组README 描述为 2 台 t3.xlarge而当前 main.tf 实际配置为单个m6i.8xlarge托管节点min/max/desired 均为 1以承载 ClickHouse 与 OTLP Collector 的高资源需求核心组件SigNoz UI公网 LoadBalancer 暴露端口 8080OTLP Collector内网 LoadBalancer 暴露端口 4317gRPC供 Fleet 服务器发送追踪数据ClickHouse存储追踪数据README 提及 200Gi而当前 main.tf 将持久卷大小设置为 600Gi存储类为 gp3。部署顺序关键约束SigNoz 必须先于 Fleet 主基础设施部署否则无法捕获 Fleet 初始启动阶段的遥测数据。标准顺序为部署共享 EKS VPC一次性、跨工作区共享通常已存在部署 SigNoz即本模块部署 Fleet 基础设施infrastructure/loadtesting/terraform/infra。这个顺序在 infra/signoz.tf 中通过terraform_remote_state数据源体现Fleet 基础设施会读取 SigNoz 模块的远程状态remote state来获取 OTLP 端点因此 SigNoz 必须先 apply。模块文件与前置依赖SigNoz 模块目录结构非常精简infrastructure/loadtesting/terraform/signoz/ ├── README.md # 部署与运维说明 ├── main.tf # 核心资源EKS、EBS CSI、StorageClass、SigNoz Helm Release、销毁清理 ├── otel-collector-values.yaml # OTLP Collector Helm values 覆盖 ├── outputs.tf # 提供给 Fleet 基础设施消费的输出 └── variables.tf # 唯一变量aws_region依赖的 Provider 与版本约束main.tf 声明了 Terraform 与 Provider 版本要求组件版本约束用途Terraform 1.5模块运行的最低版本AWS Provider 5.68.0创建 EKS、IAM、存储相关资源Helm Provider~ 2.11部署 SigNoz chartKubernetes Provider~ 2.23创建 StorageClass、读取 ServiceNull Provider~ 3.2执行销毁前清理脚本远程状态与共享 VPC模块使用 S3 作为远程状态后端配置了 workspace key 前缀、加密、DynamoDB 锁以及assume_rolebackend s3 { bucket fleet-terraform-state20220408141538466600000002 key loadtesting/loadtesting/signoz/terraform.tfstate workspace_key_prefix loadtesting region us-east-2 encrypt true kms_key_id 9f98a443-ffd7-4dbe-a9c3-37df89b2e42a dynamodb_table tf-remote-state-lock assume_role { role_arn arn:aws:iam::353365949058:role/terraform-loadtesting } }EKS 集群创建在共享 VPC 中通过terraform_remote_state读取shared模块的输出获取 VPC ID 与私有子网见 main.tf 与 L107-L117这保证了 SigNoz 的内网 OTLP 端点能被同 VPC 内的 Fleet 服务器访问。部署步骤详解按照 README 的 Usage 一节部署流程如下# 1. 初始化并选择工作区 cd infrastructure/loadtesting/terraform/signoz terraform init terraform workspace new workspace_name # 与你的 infra 工作区保持一致 # 2. 部署 SigNoz terraform apply # 3. 等待部署完成约 10-15 分钟 # OTLP collector 端点会显示在 outputs 中 # 4. 部署 Fleet 主基础设施 cd ../infra terraform apply工作区命名一致性工作区名称至关重要EKS 集群名、IAM 角色名如ebs-csi-driver角色、${local.cluster_name}-ebs-csi-driver、以及 AWS 资源的 default tag 都会引用terraform.workspace见 main.tf。同时Fleet 基础设施infra读取 SigNoz 远程状态时也使用当前工作区infra/signoz.tf 中workspace terraform.workspace因此 SigNoz 与 infra 必须使用同名工作区才能正确关联。部署耗时说明helm_release.signoz设置了timeout 360060 分钟注释明确说明这是为了容忍 AWS 在 apply 与 destroy 阶段的最坏情况延迟main.tf。正常情况下整体部署约 10-15 分钟完成其中包含 EKS 集群创建、EBS CSI Driver 就绪等待time_sleep60 秒、gp3 StorageClass 创建以及 SigNoz 全家桶UI、OTLP Collector、ClickHouse、ZooKeeper、Alertmanager的 Helm 安装。访问 SigNoz UI部署完成后有两种方式获取 UI 地址# 方式一直接输出 UI URL 命令 terraform output -raw get_signoz_ui_url | bash # 方式二配置 kubectl 后手动查询 $(terraform output -raw configure_kubectl) kubectl get svc -n signoz signoz -o jsonpathhttp://{.status.loadBalancer.ingress[0].hostname}:8080对应的输出定义在 outputs.tfconfigure_kubectl生成aws eks update-kubeconfig --region region --name cluster命令用$(...)包裹后可直接执行get_signoz_ui_url查询signoz命名空间下名为signoz的 Service 的 LoadBalancer hostname拼上:8080端口。如果是在infra目录部署完成后访问也可以使用 infra/README.md 提供的等价命令$(terraform output -raw signoz_configure_kubectl) kubectl get svc signoz -n signoz -o jsonpathhttp://{.status.loadBalancer.ingress[0].hostname}:8080输出与 Fleet 基础设施的集成模块 Outputsoutputs.tf 共导出 7 个输出其中被 Fleet 基础设施通过远程状态消费的关键三个是输出说明cluster_nameEKS 集群名称Fleet 基础设施用于关联与诊断otel_collector_endpoint内网 OTLP 端点hostname:4317Fleet 服务器发送追踪数据的地址configure_kubectl配置 kubectl 访问 SigNoz 集群的命令otel_collector_endpoint通过 Kubernetes Provider 的data kubernetes_service数据源读取signoz-otel-collectorService 的 LoadBalancer hostname 并拼接:4317端口outputs.tf。它还提供了get_otlp_endpoint输出方便手动查询 OTLP 端点。Fleet 侧如何消费这些输出Fleet 基础设施模块infra在 signoz.tf 中通过terraform_remote_state读取 SigNoz 的远程状态并使用变量enable_otel默认false定义于 infra/variables.tf控制是否启用追踪data terraform_remote_state signoz { count var.enable_otel ? 1 : 0 backend s3 # ... 与 SigNoz 模块相同的 bucket/key/workspace_key_prefix 配置 workspace terraform.workspace }启用后infra/locals.tf 会为 Fleet 服务器注入以下环境变量otel_environment_variables var.enable_otel ? { OTEL_SERVICE_NAME fleet OTEL_RESOURCE_ATTRIBUTES deployment.environment.name${terraform.workspace},deployment.environment${terraform.workspace} OTEL_EXPORTER_OTLP_ENDPOINT http://${data.terraform_remote_state.signoz[0].outputs.otel_collector_endpoint} FLEET_LOGGING_TRACING_ENABLED true FLEET_LOGGING_TRACING_TYPE opentelemetry } : {}这些环境变量与 Fleet 服务器配置一一对应FLEET_LOGGING_TRACING_ENABLED映射logging.tracing_enabledFLEET_LOGGING_TRACING_TYPE映射logging.tracing_type配置解析见 server/config/config.go 与 server/config/config.go。Fleet 服务器通过OTELEnabled()方法判断是否启用 OpenTelemetry// server/config/config.go#L939-L941 func (f FleetConfig) OTELEnabled() bool { return f.Logging.TracingEnabled f.Logging.TracingType ! elasticapm }即只有tracing_enabledtrue且tracing_type不是elasticapm时OTel 追踪才会生效——这与 infra 模块OpenTelemetry 是唯一选项的设计完全吻合。OTEL_EXPORTER_OTLP_ENDPOINT指向 SigNoz 内网 OTLP Collectorhttp://internal-lb-hostname:4317追踪数据默认通过 gRPC 协议上报。在 infra 中启用追踪按照 infra/README.md 的说明部署 Fleet 基础设施时加上enable_oteltrue即可同时启用 SigNoz 追踪terraform apply -vartagv4.72.0 -varfleet_task_count20 -varfleet_task_memory4096 -varfleet_task_cpu512 -vardatabase_instance_sizedb.t4g.large -vardatabase_instance_count3 -varredis_instance_sizecache.t4g.small -varredis_instance_count3 -varenable_oteltrue源码级深潜Terraform 模块实现要点EKS 集群与插件安装顺序main.tf 中有一处极具工程价值的注释核心插件必须在节点组之前安装否则会死锁。原因在于节点需要 VPC CNI 才能变为 Ready而 Terraform 在创建附加组件addons前会等待节点 Ready两者互相等待导致节点卡在 NotReady。解决方案是使用before_compute true让 vpc-cni、kube-proxy、coredns 三个 addon 在节点组完成之前安装addons { vpc-cni { most_recent true, before_compute true } kube-proxy { most_recent true, before_compute true } coredns { most_recent true, before_compute true } }集群启用了 cluster creator admin 权限enable_cluster_creator_admin_permissions true与 IRSAenable_irsa true为后续 EBS CSI Driver 服务账户授权做准备。EBS CSI Driver 与 gp3 存储类ClickHouse、ZooKeeper、Alertmanager 都需要持久化存储。模块专门为 EBS CSI Driver 创建了 IRSA 角色ebs-csi-driver并单独挂载aws-eks-addon资源以避免与 OIDC Provider 的循环依赖main.tf。随后创建默认的gp3存储类启用加密、容量扩容与WaitForFirstConsumer绑定模式resource kubernetes_storage_class_v1 gp3 { storage_provisioner ebs.csi.aws.com reclaim_policy Delete allow_volume_expansion true volume_binding_mode WaitForFirstConsumer parameters { type gp3, encrypted true, fsType ext4 } }所有 SigNoz 组件ClickHouse 600Gi、ZooKeeper、Alertmanager的持久卷都显式指定storageClass gp3main.tf。SigNoz Helm Release 的关键参数helm_release.signoz使用官方 charthttps://charts.signoz.iochart 名为signoz安装在signoz命名空间main.tf核心覆盖参数如下参数值说明cloudfalse自托管模式不使用 SigNoz Cloudsignoz.service.typeLoadBalancerSigNoz UI 公网暴露otelCollector.service.typeLoadBalancerOTLP Collector 服务暴露otelCollector.service.annotations.service\.beta\.kubernetes\.io/aws-load-balancer-schemeinternal关键OTLP Collector 仅内网可达不对外开放clickhouse.persistence.size600GiClickHouse 持久卷大小clickhouse.persistence.storageClassgp3使用 gp3 存储类zookeeper.persistence.storageClassgp3ZooKeeper 存储类alertmanager.persistence.storageClassgp3Alertmanager 存储类clickhouse.resources.requests.cpu/memory6000m/12GiClickHouse 请求资源clickhouse.resources.limits.cpu/memory12000m/24GiClickHouse 资源上限otelCollector.resources.requests.cpu/memory3000m/24GiOTLP Collector 请求资源otelCollector.resources.limits.cpu/memory12000m/36GiOTLP Collector 资源上限otelCollector.replicaCount3OTLP Collector 三副本保证采集高可用代码注释明确说明了资源调整的动机chart 默认的 ClickHouse100mCPU 与200Mi内存对高吞吐遥测数据来说远远不够必须按负载测试的规模显著放大。OTLP Collector 配置详解模块通过 otel-collector-values.yaml 对 OTLP Collector 进行完全显式的配置覆盖目标是生产级稳定性。这份配置是理解整个追踪链路的钥匙。接收端Receivers接收器协议端点说明otlp/grpcgRPC0.0.0.0:4317标准 OTLP 入口max_recv_msg_size_mib: 16限制单条消息大小otlp/httpHTTP0.0.0.0:4318OTLP HTTP 入口jaeger/grpcgRPC0.0.0.0:14250兼容 Jaeger gRPC 协议jaeger/thrift_httpThrift0.0.0.0:14268兼容 Jaeger Thrift 协议处理管道Processorsbatchsend_batch_size6000、send_batch_max_size7500、timeout5s为 traces/logs/metrics 主链路设计平衡吞吐与内存batch/metersend_batch_max_size75000、send_batch_size60000、timeout1s面向 meter 指标的高容量批处理memory_limiterlimit_mib33792约 33Gi、spike_limit_mib1536、check_interval1s与 Collector 36Gi 的内存上限配合防止 OOMsignozspanmetrics/delta把 span 转换为 RED 指标请求率、错误率、耗时分布latency_histogram_buckets定义了从 100us 到 60s 的 16 档直方图桶dimensions_cache_size100000缓存维度aggregation_temporalityDELTA使用增量聚合。导出端Exporters与管道编排导出器超时重试发送队列目标clickhousetraces60s5s→30s 指数退避最长 300s30 消费者15000 队列追踪数据写入 ClickHouseclickhouselogsexporter60s同上30 消费者15000 队列日志写入 ClickHousesignozclickhousemetrics45s——指标写入 ClickHousemetadataexporter60s同上—元数据导出signozclickhousemeter45s关闭队列—meter 指标写入 ClickHouseservice.pipelines定义了四条链路tracesotlpjaeger → memory_limiter → signozspanmetrics/delta → batch → clickhousetraces metadataexporter signozmeter、metrics、logs、metrics/meter。另有两个值得注意的细节lowCardinalityExceptionGrouping: true开启低基数异常分组压缩异常告警噪声signozmeter连接器设置了metrics_flush_interval: 1h并按service.name、deployment.environment、host.name三个维度聚合service.telemetry.logs.encoding: jsonCollector 自身日志输出为 JSON便于接入日志系统排查。ClickHouse 存储管理与保留期治理README 的 Managing storage and retention 一节是整个运维部分的重心。ClickHouse 存储有限当前配置 600Gi gp3 卷负载测试会产生海量 trace因此必须主动治理。1. 缩短追踪数据保留期在 SigNoz UI 中操作进入Settings → Retention Period针对 traces 降低保留期默认值对负载测试场景过长活跃负载测试环境建议设置为1-3 天。2. 监控 ClickHouse 存储用量# 查看 ClickHouse pod 存储使用情况 kubectl exec -n signoz chi-signoz-clickhouse-cluster-0-0-0 -- df -h /var/lib/clickhouse # 按数据库统计磁盘占用 kubectl exec -n signoz chi-signoz-clickhouse-cluster-0-0-0 -- clickhouse-client --query SELECT database, formatReadableSize(sum(bytes_on_disk)) AS size FROM system.parts WHERE active GROUP BY database ORDER BY sum(bytes_on_disk) DESC第一条命令检查数据目录所在文件系统的剩余空间第二条命令通过 ClickHouse 的system.parts系统表按数据库聚合活跃分区active的磁盘占用并按从大到小排序能够快速定位是 trace、log 还是 metric 库在膨胀。3. 存储写满的后果README 明确列出了存储耗尽时的行为这决定了监控的重要性ClickHouse 会拒绝新的写入请求新的 trace 将无法被采集OTLP Collector 会记录写入失败的报错日志Fleet 服务器继续运行但追踪数据会丢失。换句话说存储写满不会导致负载测试失败但会让追踪数据出现静默缺口误导后续性能分析。因此在长跑型负载测试前务必先调整保留期并确认磁盘水位。销毁流程与已知问题处理基本销毁terraform destroy已知的销毁挂起问题fleetdm/fleet#35405与预销毁清理main.tf 中实现了一个非常值得借鉴的null_resource预销毁清理机制。其背景是SigNoz chart 安装了 Altinity clickhouse-operator该 operator 会在其ClickHouseInstallationCHI自定义资源上放置 finalizer。执行helm uninstall时 operator 先被移除于是没有任何组件来处理这个 finalizer导致 CHI 删除卡死进而拖住 PVC 与命名空间删除最终让helm_releasewait true在销毁时等待到完整超时。清理脚本利用Terraform 在销毁时先销毁依赖方的特性depends_on [helm_release.signoz]保证该资源先于 helm_release 执行依次完成先删除 clickhouse-operator Deployment因为 operator 运行时会立即重新添加 CHI finalizer仅 patch finalizer 会输掉竞争删除后还会等待 pod 真正终止kubectl wait --fordelete上限 120s外加轮询兜底剥离 CHI 的 finalizerkubectl patch clickhouseinstallations.clickhouse.altinity.com signoz-clickhouse -n signoz --type merge -p {metadata:{finalizers:[]}}使 CHI 可以立即删除删除 LoadBalancer Service释放 AWS ELB避免其在 EKS/VPC 拆除阶段残留排队删除 PVC--waitfalse让 EBS CSI Driver 在集群仍存活时释放 EBS 卷包括 600Gi 的 ClickHouse 卷否则集群销毁后这些卷会成为孤儿资源。每个步骤都具备幂等性与容错性on_failure continue、|| exit 0、--ignore-not-found对全新或部分创建的堆栈来说这些清理动作只是无事可做的空操作。输出清单与快速参考部署完成后模块导出的全部输出如下见 outputs.tf输出类型说明cluster_namestringEKS 集群名称cluster_endpointstringEKS 集群 API 端点cluster_certificate_authority_datastring集群 CA 证书configure_kubectlstring配置 kubectl 的命令get_signoz_ui_urlstring获取 SigNoz UI 地址的命令get_otlp_endpointstring获取 OTLP 端点的命令otel_collector_endpointstring内网 OTLP 端点hostname:4317供 Fleet 消费最佳实践小结结合 README 与源码SigNoz 负载测试环境的运维要点可归纳为顺序不可颠倒SigNoz 必须先于 Fleet 基础设施部署否则 Fleet 启动阶段的 trace 无法采集工作区命名必须与 infra 保持一致远程状态才能正确关联。存储治理要前置负载测试开始前先调整 Settings → Retention Period 到 1-3 天并用clickhouse-client查询system.parts持续监控磁盘水位避免 ClickHouse 静默拒绝写入导致 trace 缺口。OTLP 端点保持内网otelCollector.service的 AWS LoadBalancer scheme 被显式设置为internal这是安全基线不应移除。资源规格按负载测试规模调优chart 默认资源远不足以支撑高吞吐遥测当前配置ClickHouse 12Gi/24Gi、Collector 3 副本 24Gi/36Gi、600Gi 存储是经过实践校准的值调整时需同步评估 EKS 节点规格m6i.8xlarge。销毁依赖预清理钩子null_resource的 pre-destroy 清理删 operator、剥离 finalizer、释放 ELB 与 EBS 卷是避免销毁挂起的必要保障涉及 SigNoz 版本升级或重建时应保留该逻辑。通过以上部署与运维流程即可在 Fleet 负载测试环境中稳定获得端到端的 OpenTelemetry 链路追踪能力为性能分析与瓶颈定位提供可靠的数据基础。赞分享后端前端企业应用运维网络安全【免费下载链接】fleetOpen device management项目地址https://gitcode.com/GitHub_Trending/fl/fleet点击查看免费下载相关推荐Fleet 负载测试环境中的 Percona PMM 部署指南用 Terraform 在 ECS Fargate 上监控 Aurora MySQL 内部瓶颈Fleet 负载测试环境中的 Percona PMM 部署指南用 Terraform 在 ECS Fargate 上监控 Aurora MySQL 内部瓶颈后端前端企业应用运维网络安全SigNoz最佳实践生产环境部署与运维指南SigNoz最佳实践生产环境部署与运维指南 概述 SigNoz是一款开源的可观测性平台专为微服务架构设计提供分布式追踪、日志管理和度量指标等功能。在生产环可观测性指标监控链路追踪日志分析后端告警如何将 ClickHouse 的指标与查询追踪接入 OpenTelemetry 采集器如何将 ClickHouse 的指标与查询追踪接入 OpenTelemetry 采集器 如果你已经在运行 ClickHouse 服务器想让它产生的查询追踪数据数据库OLAP列式数据库大数据实时分析数据分析上一篇解密Vibe基于TauriWhisper的本地化语音转录技术深度解析下一篇7个Litellm运营优化技巧流程自动化与效率提升全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考