【可观测性系列】 OpenTelemetry Collector的部署模式分析
🎬作者简介:大家好,我是蓝胖子🥇
☁️博客首页:主页蓝胖子的编程梦
⭐️热门专题:我的服务监控实践 ,500行代码手写Docker**🌄每日一句:白日莫闲过,青春不再来
大家好,我是蓝胖子,在前面我介绍了下OpenTelemetry的概念,但是究竟在项目中应该如何来使用OpenTelemetry 来帮助我们完成可观测性的构建?接下来,我将会谈谈有关 OpenTelemetry如何落地的一些问题。
这一节我们来看看OpenTelemetry Collector 的部署模式,OpenTelemetry Collector 是OpenTelemetry 项目中的一个代理软件,作为遥测数据(也就是日志,指标,trace数据)的中转站,能够对遥测数据做一些预处理的逻辑。
不使用OpenTelemetry Collector#
OpenTelemetry Collector 并不是必须的,我们可以直接使用OpenTelemetry 客户端SDK发送遥测数据到监控组件中,比如将trace数据发送到jaeger,发送metric数据到prometheus。部署模式如下图所示,
代理模式部署#
如果要使用OpenTelemetry Collector 对遥测数据的预处理功能,则需要在应用程序和后端监控组件之间部署上OpenTelemetry Collector,OpenTelemetry Collector和应用程序之间是通过OTLP协议传输遥测数据,这个协议是OpenTelemetry 客户端SDK封装好的。
但这种模式有个问题,如果应用程序产生的遥测数据太多,一个OpenTelemetry Collector 已经不能满足快速处理数据的要求,那应该怎么办呢?
集群网关模式#
这就要提到第三种部署模式,集群网关模式部署OpenTelemetry Collector ,如下图所示,通过在多个OpenTelemetry Collector 前面部署一个拥有负载均衡功能的OpenTelemetry Collector 来让分发发往整个集群的遥测数据。
负载均衡的策略一般也是按trace id去划分,这样同一个请求轨迹的trace数据会被同一个OpenTelemetry Collector所处理,这对于某些类型的Collector中的处理器而言非常重要,比如后置采样处理器( Tail Sampling processor) ,它需要分析完整的trace链才能决定该条trace数据是否应该被采样。
从OpenTelemetry Collector导出遥测数据的功能是其组成部分之一exporter完成的,社区目前已经有现成的exporter可以配置在Opentelemetry Collector里,Trace ID/Service-name aware load-balancing exporter ,通过该exporter将遥测数据分发到Opentelemetry Collector集群里,在集群节点中做复杂的过滤清洗遥测数据的工作,在负载均衡网关Collector节点上,只做简单的分发操作。
作者:蓝胖子的编程梦
出处:https://www.cnblogs.com/hobbybear/p/18006757
版权:本作品采用「署名-非商业性使用-相同方式共享 4.0 国际」许可协议进行许可。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 我与微信审核的“相爱相杀”看个人小程序副业
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求