如何在AKS中部署集成Elastic APM、Filebeat、Metricbeat的ELK栈及排查APM超时问题

• 核对APM Server实际服务地址
  你当前APM资源部署在default命名空间，由ECK Operator自动创建的HTTP服务名称格式为<apm-server-resource名>-apm-http，先通过命令查实际的服务公网IP：
  kubectl get svc -n default | grep apm-new-quickstart
  对比你在Agent环境变量里写的SERVER_URL值http://40.83.185.238:8200，如果IP不匹配，直接修正配置，这是最常见的超时原因。
• 验证网络连通性
  先从集群外执行连通性测试：
  curl -v http://<APM服务实际IP>:8200/health
  如果外部访问直接超时，检查两点：
  1. AKS节点关联的网络安全组是否放行8200端口的入站规则
  2. LoadBalancer服务的后端池是否正确关联了APM Server Pod
• 避免不必要的公网访问
  APM Agent运行在和APM Server同集群的blogdemodeployments命名空间，完全不需要走公网LoadBalancer暴露的IP，直接使用集群内部DNS地址访问即可，从根源避免公网IP漂移、网络层拦截的问题。正确的SERVER_URL配置为：
  http://apm-new-quickstart-apm-http.default.svc.cluster.local:8200
  配置完成后直接在业务Pod内执行连通性测试：
  kubectl exec -n blogdemodeployments <你的业务Pod名> -- curl -v http://apm-new-quickstart-apm-http.default.svc.cluster.local:8200/health
• 修正现有配置的标签错配问题
  你当前业务Deployment的Pod标签是app: azuretest，但下方定义的apmfb服务选择器是app: apmfb，标签完全不匹配，会导致服务流量无法转发到业务Pod，排查时容易和APM连接问题混淆，需要把服务选择器改成和Pod标签一致的app: azuretest。
• 验证APM Server自身运行状态
  如果网络连通正常但依然连接超时，检查APM Server Pod日志，确认APM Server正常监听8200端口，且可以正常输出到Elasticsearch。你当前手动写的ES输出配置存在硬编码公网IP、明文密码的问题，后续可以改成通过ECK的elasticsearchRef自动关联ES，避免配置漂移、密码失效导致的APM Server自身异常。

前置依赖 #

• 集群内提前安装ECK Operator，所有组件统一使用兼容版本（示例中7.10.2版本跨ES、Kibana、APM Server完全兼容）

核心组件配置规范 #

• Elasticsearch
• 测试环境可配置单节点，node.store.allow_mmap: false可降低对节点系统参数的要求
• 生产环境至少3个主节点，关闭公网LoadBalancer暴露，仅保留集群内部ClusterIP服务
• 不要在APM配置中硬编码ES的公网地址和账号密码，通过ECK的引用机制自动关联
• Kibana
  • 版本和Elasticsearch完全对齐，通过elasticsearchRef自动关联ES集群，无需手动配置ES地址
  • 测试环境可禁用自签TLS，生产环境建议开启TLS并配置访问权限
• APM Server
  • 通过elasticsearchRef关联ES集群，自动获取输出配置和TLS证书
  • 集群内部署的Agent优先使用ClusterIP类型服务，无需公网暴露；仅当需要对接集群外部的Agent时，再配置LoadBalancer类型服务并调整NSG放行规则
• Filebeat
  • 不要采用“业务Pod侧挂AzureFile卷存filebeat配置”的模式，通过ECK的Beat CRD独立部署DaemonSet模式的Filebeat，每个节点运行一个采集实例
  • 自动配置容器日志、节点日志的采集规则，自动关联ES输出，避免手动写配置导致的权限问题、配置更新不及时问题
• Metricbeat
  • 同样通过ECK的Beat CRD部署DaemonSet实例，自动采集节点指标、容器运行时指标
  • 自动开启Elasticsearch、Kibana、APM Server的内部监控指标采集，无需手动配置各组件的监控地址

部署优化建议 #

• 所有集群内部的组件访问，统一使用服务DNS地址，不要硬编码公网IP，避免服务重建后IP变化导致的连接失败
• 排查连接问题时，优先从目标Pod内部发起连通性测试，不要从外部公网绕路排查，缩小问题范围
• 统一关闭跨服务的不必要SSL验证，和当前禁用APM自签TLS的配置匹配，避免Agent因为TLS证书问题报错

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