编辑 | 张婵
一些好用且开源的监控工具
监控系统是整个 IT 架构中的重中之重, 小到故障排查, 问题定位, 大到业务预测, 运营管理, 都离不开监控系统, 可以说一个稳定, 健康的 IT 架构中必然会有一个可信赖的监控系统.
但是, 难道监控就只是监控? 多年来, 对于监控的术语一直都有很多困惑, 一些很糟糕的工具也宣称能够以一种格式完成所有事情.
在 DevOps 和云原生时代, 今年,"可观察性"(Observability)被引入到了 IT 领域, 其首先表现为 CNCF-Landscape 出现了 Observability 分组. 从该分组的内容看包含了监控, 日志, Tracing 等领域的项目. 可观察性与监控有什么不同? 简单说来, 后者是前者的一个子集. 监控关注系统的失败因素, 从而定义出系统的失败模型. 它的核心是运维, 是监控设施. 而可观察性除了关注失败之外, 其核心是研发, 是应用, 是对系统的一种自我审视. 是站在创造者的角度去探究系统应如何恰当的展现自身的状态. 一个由外向内, 一个由内向外.
观察工具包括: 度量聚合(Metrics aggregation)(主要是时序数据), 日志聚合(Log aggregation), 告警 / 可视化(Alerting/visualizations), 分布式追踪(Distributed tracing).
监控工具
Prometheus
Prometheus 是云原生应用程序最受认可的时间序列监控解决方案, 由 CNCF 托管, 使用 Go 语言开发, 是 Google BorgMon 监控系统的类似实现.
Prometheus 使用的是 Pull 模型, Prometheus Server 通过 HTTP 的 pull 方式到各个目标拉取监控数据. 它使用局部配置来描述要收集的端点和收集所需的间隔. 每个端点都有一个客户端收集数据并在每次请求时更新该表示(或者客户端是配置的). 收集此数据并将其保存在本地磁盘上的高效存储引擎中. 存储系统使用每个度量标准的仅附加文件.
Prometheus 包含一种高级表达式语言, 用于选择和显示名为 PromQL 的数据. 此数据可以通过 REST API 以图形或表格显示或由外部系统使用. 表达式语言允许用户创建回归, 分析实时数据或趋势历史数据. 标签也是用于过滤和查询数据的绝佳工具. 标签可以与每个度量标准名称相关联.
Prometheus 附带 AlertManager 来处理警报. AlertManager 允许进行警报聚合以及更复杂的流量以限制发送警报的时间. 假设在开关关闭的同时 10 个节点突然出问题, 你可能不需要发送有关这 10 个节点的告警, 因为接到报警的每个人在开关修好之前可能无法执行任何操作. 使用 AlertManager, 可以仅向网络团队发送有关开关告警, 并在其中包含其他可能受影响系统的信息; 也可以向系统团队发送电子邮件(而不是页面), 以便他们知道这些节点已关闭, 除非系统在开关修复后没有恢复, 否则他们不需要响应.
如果发生这种情况, 则 AlertManager 将重新激活那些被开关警报抑制的警报.
Graphite
Graphite 是一款用 Python 写的开源企业级监控绘图工具, 可以在廉价机硬件上运行. Graphite 可以实时收集, 存储, 显示时间序列类型的数据, 它由三个软件组件组成:
carbon - 基于 Twisted 的进程, 用于监听并接收数据;
whisper - 专门存储时序数据的小型数据库, 在设计上类似于 RRD;
graphite webapp - 基于 Django 的网页应用程序, 可以从 whisper 数据库获取时间序列数据并且进行展示.
Graphite 架构图
Graphite 是一个基于推送的系统, 通过让应用程序推送数据到 Graphite 的 Carbon 组件中, 从应用程序接收数据. Carbon 将此数据存储在 Whisper 数据库中, Graphite Web 组件读取 Carbon 它的和数据库, 允许用户在浏览器中绘制数据图或通过 API 提取数据. 一个非常酷的功能是能够将这些图形导出为图像或数据文件, 以便将它们轻松嵌入到其他应用程序中.
Graphite 的另一个有趣功能是能够存储与时序指标相关的任意事件. 可以在 Graphite 中添加和跟踪应用程序或基础架构部署, 这允许运维人员或开发人员对问题进行故障排除, 能获得正在调查的异常行为环境中更多的背景信息.
Graphite 监控上手指南: http://www.infoq.com/cn/articles/graphite-intro
InfluxDB
InfluxDB 是一个相对较新的时序数据库, 使用 Go 语言编写, 无需外部依赖, 安装配置非常方便, 适合构建大型分布式系统的监控系统.
其设计目标是实现分布式和水平伸缩扩展.
InfluxDB 的一些主要特征:
无结构 (无模式): 可以是任意数量的列
可以设置 metric 的保存时间
支持与时间有关的相关函数 (如 min,max,sum,count,mean,median 等), 方便统计
支持存储策略: 可以用于数据的删改.(influxDB 没有提供数据的删除与修改方法)
支持连续查询: 是数据库中自动定时启动的一组语句, 和存储策略搭配可以降低 InfluxDB 的系统占用量.
原生的 HTTP 支持, 内置 HTTP API
支持类似 sql 语法
支持设置数据在集群中的副本数
支持定期采样数据, 写入另外的 measurement, 方便分粒度存储数据
自带 Web 管理界面, 方便使用 (登入方式: http://<InfluxDB-IP>:8083)
OpenTSDB
OpenTSDB 是基于 Hbase 的分布式的, 可伸缩的时序数据库, 确切地说, 它只是一个 HBase 的应用. OpenTSDB 主要用途就是做监控系统; 譬如收集大规模集群 (包括网络设备, 操作系统, 应用程序, 环境状态) 的监控数据并进行存储, 查询.
OpenTSDB 可以动态的增加 metrics, 灵活支持任何语言的收集器, 极大的方便了运维人员, 降低了开发和维护成本.
存储到 OpenTSDB 的数据, 是以 metric 为单位的, metric 就是一个监控项, 譬如服务器的话, 会有 CPU 使用率, 内存使用率这些 metric;
OpenTSDB 使用 HBase 作为存储, 由于有良好的设计, 因此对 metric 的数据存储支持到秒级别;
OpenTSDB 支持数据永久存储, 即保存的数据不会主动删除; 并且原始数据会一直保存(有些监控系统会将较久之前的数据聚合之后保存)
日志聚合工具
一些日志记录规则:
包括时间戳
格式为 JSON
请勿记录无意义的事件
请记录所有应用程序错误
可以有日志警告
打开日志记录
以可读的形式写消息
请勿在生产中记录信息数据
请勿记录无法阅读或反应的任何内容
ELK
ELK 是 Elasticsearch,Logstash 和 Kibana 的缩写, 在实时数据检索和分析场合, 三者通常是配合共用, 是市场上最受欢迎的开源日志聚合工具. 它被 Netflix,Facebook,Microsoft,LinkedIn 和 Cisco 使用. 这三个组件都是由 Elastic 开发和维护的. Elasticsearch 本质上是一个 NoSQL, 以 Lucene 搜索引擎实现.
Logstash 是一个日志管道系统, 可以提取, 转换数据并将其加载到像 Elasticsearch 这样的商店中. Kibana 是 Elasticsearch 之上的可视化层.
几年前出现了数据收集器 Beats, 能简化数据传输到 Logstash 的过程. 用户可以安装 Beat, 能导出 NGINX 日志或 Envoy 代理日志, 以便在 Elasticsearch 中有效使用, 无需了解每种类型日志的正确语法.
在安装生产级 ELK 堆栈时, 可能会包含 Kafka,Redis 和 NGINX 等其他部分. 此外, Logstash 通常可以用 Fluentd 替换. 这个系统操作起来很复杂, 早期有很多问题导致了很多抱怨. 这些问题很大程度上都被修复了, 但它仍然是一个复杂的系统, 所以对于较小的操作, 你可能不想尝试它.
ELK 堆栈还通过 Kibana 提供了出色的可视化工具, 但它缺乏警报功能. Elastic 在付费 X-Pack 插件中提供警报功能, 但开源系统中没有内置任何功能. Yelp 为这个问题提供了名为 ElastAlert 的解决方案, 可能还有其他类似的工具. 这个额外的软件非常强大, 但它进一步增加了 ELK 堆栈的复杂性.
ELK Stack 在最近两年迅速崛起, 和传统的日志处理方案相比, ELK Stack 具有如下几个优点:
处理方式灵活. Elasticsearch 是实时全文索引, 不需要像 storm 那样预先编程才能使用 ;
配置简易上手. Elasticsearch 全部采用 JSON 接口, Logstash 是 Ruby DSL 设计, 都是目前业界最通用的配置语法设计 ;
检索性能高效. 虽然每次查询都是实时计算, 但是优秀的设计和实现基本可以达到全天数据查询的秒级响应 ;
集群线性扩展. 不管是 Elasticsearch 集群还是 Logstash 集群都是可以线性扩展的 ;
前端操作炫丽. Kibana 界面上, 只需要点击鼠标, 就可以完成搜索, 聚合功能, 生成炫丽的仪表板.
Graylog
Graylog 是强大的日志管理, 分析工具, 基于 Elasticsearch, Java 和 MongoDB, 这使得它像 ELK 堆栈一样运行起来很复杂, 甚至更加复杂. 但是, Graylog 开源版本带有内置的警报, 以及其他一些值得注意的功能, 如流式传输, 消息重写和地理定位.
流式传输功能允许数据在处理时能实时路由到特定 Stream. 使用此功能, 用户可以在一个 Stream 中查看所有数据库错误, 在另一个 Stream 中查看 Web 服务器错误. 当添加新项目或超过阈值时, 告警甚至可以基于这些 Stream. 延迟可能是日志聚合系统的最大问题之一, Graylog 中的 Streams 中消除了这个问题, 一旦日志进入, 无需处理即可通过 Stream
路由到其他系统.
消息重写功能使用开源规则引擎 Drools, 允许根据用户定义的规则文件来评估所有传入消息. 该文件可以丢弃消息(称为黑名单), 添加或删除字段, 以及修改信息.
Graylog 最酷的功能可能是地理位置功能, 它支持在地图上绘制 IP 地址. 这样功能相当常见, Kibana 中也有这个功能, 但 Graylog 中增加了很多价值, 特别是你想将它用作 SIEM 系统时. 地理定位功能在 Graylog 的开源版本中提供.
来源: https://juejin.im/entry/5ba37d94e51d450e6973531e