telegraf简介
Telegraf是InfluxData开发的一个数据采集器(collector), 用来收集各种监控数据, 因为其非常灵活的插件体系, 社区贡献了大量的采集插件, 从操作系统层面的指标到各种数据库, 中间件的插件应有尽有.
Telegraf vs Prometheus Exporter
在开源届另一个非常流行的监控方案是Prometheus, 在云原生里几乎就是标准, Prometheus本身是pull模型, 因此对于使用者来说只需要把需要采集的监控数据暴露出来, 最主要的方式就是exporter. 官网也有一个长长的exporter列表: Exporters and integrations | Prometheus
可以看出来telegraf和Prometheus exporter实现的功能是比较类似的, 但由于Prometheus exporter本身是只给Prometheus使用的, 因此他跟telegraf之间也有一些差别:
开发模式
Prometheus exporter是独立开发的, 每个exporter都有自己的代码仓库和维护人员, 没有统一的社区进行管理, telegraf则是将所有插件维护在一个代码仓库下, 好处是可以在全局进行考虑, 例如类似功能的插件可以进行合并, 以减少用户的选择成本, 或者当某个功能可以通过一些配置组合实现时就不必重新开发, 代码可以复用
部署方式
Prometheus exporter是独立部署的, 每个exporter需要监听一个端口来提供http服务, 而telegraf是单实例部署, 也不监听端口
在某些场景下, 比如jvm的监控, exporter有更好的集成, 通过一个javaagent就可以完成对jmx指标的采集和暴露, 对于telegraf来说则需要借助jolokia将jmx协议转换成http协议再进行采集
配置管理
每个Prometheus exporter都有自己的配置文件, 也没有共通的配置文件规范, 意味着开发者可以自行选择, 可以用yaml也可以用json, 或者用命令行参数控制等, telegraf则有统一的配置文件规范, 使用toml格式, 其中相同名称的字段含义也是相同的, 因为在同一个代码仓库维护, 维护者会进行把关
当需要对label做一些自定义时, 例如重命名一个label, 或者添加删除某个label, 忽略一些不需要的metric, Prometheus的配置维护在服务端, telegraf中这些配置是和采集配置在一起的, 可以通过processor插件做各种处理
对于小规模的用户自行围绕Prometheus构建监控系统来说, Prometheus exporter提供了更好的灵活性, 同时和Prometheus, grafana的整合都更好, 但当平台需要集成采集的配置管理时, 会带来额外的复杂度, 基于以上考虑, SLS决定集成telegraf作为一个logtail的插件, 提供各种监控采集的能力
当然, 由于SLS出色的开放性, 原先使用Prometheus的用户无需改变使用习惯, 我们支持Prometheus remote write写入, 并且兼容查询API, 因此telegraf接入的方式对于这部分用户来说只是多了一个选择
使用telegraf的痛点
- 需要自行管理配置文件的下发, 更新等
- 开源软件总是提供尽量灵活的配置, 但缺少最佳实践, 需要用户去探索
- 数据之间难以打通, 需要制定label的规范(exporter也有同样的问题)
SLS通过将telegraf作为logtail的插件来统一管理他的部署和配置下发更新, 提供了图形化配置界面, 统一了label等规范, 并且提供了内置的dashboard来解决以上问题
logtail telegraf插件的工作机制
自动安装
当logtail初次获取到telegraf插件的配置时, 会自动下载telegraf进行安装
中心化配置管理
logtail配置中包含了telegraf配置, logtail拿到时会将其提取出来, 生成对应的telegraf配置, 更新和删除也与logtail配置同步, 由于logtail配置在sls服务端进行管理, 因为telegraf也同时拥有了中心化配置管理的能力
采集
logtail实现了influxdb的http协议, 在telegraf中的output使用influxdb, 输出目标填写logtail地址(用户无需填写, 创建采集配置时自动生成), telegraf的数据将通过logtail中转写入sls服务端存储
模板化监控配置
SLS不仅负责了telegraf的配置的生命周期管理, 甚至也会帮助用户来生成最佳实践的配置, 对用户来说只需要通过图形化的界面wizard即可完成配置:
在这个简单的页面背后, 我们也做了不少工作, 例如其中集群名称是我们作为最佳实践要求用户填写的, 否则需要依赖采集插件是否产出了相关的label, 如果没有则用户的数据就会混在一起. 统一提供了instance label, 让用户在采集不同的中间件时都可以用相同的label识别, 实际telegraf插件的开发者在表达instance这个含义时可能使用instance, 也可能使用server, host等名称, 很容易混淆; 我们也根据最佳实践去除了一些几乎没用的指标来节省存储空间, 对一些指标的命名做了规范化等
完成接入配置后, 我们也提供了自动生成的dashboard:
后续也会进一步整合预置的告警规则, 让用户一键开启即可完成整个监控所需工作
数据源支持情况
新的数据源在持续开发中, 也欢迎大家反馈需要接入的数据源, 如果认可我们做的事情, 也欢迎加入: SLS团队长期招聘人才，欢迎对大数据、监控、可观察性、前端可视化、移动端开发、机器学习等有兴趣的同学可发简历至邮箱: luoxing.klx@alibaba-inc.com
也欢迎加入我们的用户交流群或微信公众号了解SLS的最新信息