监控工具 开源_4种开源监控工具

监控工具 开源

监视不只是监视吗？ 它不包括日志记录，可视化和时间序列数据吗？

多年来，围绕监视的术语引起了很多混乱，并导致一些不良的工具吹捧以一种格式进行所有操作的能力。 可观察性的支持者认为，观察系统有很多层次。 指标聚合主要是时间序列数据，这就是我们将在本文中讨论的内容。

时序数据的特征

专柜

计数器是代表只会增加数值的指标。 （换句话说，计数器永远不能减少。）计数器会累加值，并在请求时显示当前总数。 这些通常用于诸如Web请求的总数，错误数，访问者数之类的事情。这类似于在事件入口处带有计数器设备的人，该设备对所有进入的人进行计数。 通常不选择不重置计数器就递减计数器。

量规

量表与计数器类似，因为它代表单个数值，但也可以减小。 它本质上是某个时间点的某些值的表示。 温度计就是一个很好的例子：温度计随温度上下移动，并提供时间点读数。 其他用途包括CPU使用率，内存使用率，网络使用率和线程数。

分位数

分位数不是度量标准的类型，但它们与以下两个部分密切相关：直方图和摘要。 让我们用一个例子来阐明我们对分位数的理解：

百分位数是一种分位数。 百分位是我们经常看到的东西，它们应该帮助我们更容易地理解一般概念。 一个百分位数具有100个“存储桶”值。 我们经常看到它们与测试或性能相关，并且通常表示为某人得分，例如，在第85个百分点之内或其他某个值。 这意味着在该百分比中得分的人的真实价值落在第85至86个百分点之间。 此人在所有学生中也得分最高的15％。 我们不知道基于该指标的存储桶中的分数，但是可以基于存储桶中所有分数的总和除以这些分数的计数得出。

分位数使我们比使用均值或其他不考虑离群值和不均匀分布的统计函数更好地理解我们的数据。

直方图

直方图比计数器或量规要复杂一些。 这是观察的样本。 它由一个计数器组成，该计数器对所有观察值进行计数，本质上是一个将观察值相加的量表。 它使用“存储桶”或分组对值进行分段，以有效地绑定数据集。 在与请求服务级别协议（SLA）相关的分位数中通常会看到这种情况。 假设我们要确保95％的请求低于500ms。 我们可以使用上限为0.5s的存储桶来收集所有500ms以下的值。 然后，我们将能够确定有多少总请求属于该请求。 我们还可以确定距SLA有多远，但这可能很难做到（如Prometheus文档中所述 ）。

直方图是从多个实例累积到中央服务器的聚合指标。 这提供了一个机会来了解整个系统，而不是逐个节点地了解系统。

总结

汇总与直方图相似，因为它们是观察值的样本，但是汇总发生在服务器端。 同样，分位数的估计比直方图更准确。 摘要使用滑动时间窗，因此它的情况与直方图略有不同，但通常用于相同类型的指标。 我通常使用直方图，除非我需要非常精确的分位数度量。

推拉

如果不解决“推与拉”的争论，就无法撰写有关度量聚合工具的文章。

辩论围绕着将指标推送到数据聚合系统还是让指标聚合系统通过抓取端点来获取并收集数据更好。 多篇文章讨论了这一点（例如本篇和本篇 ）。 我的观点是，这几乎没有关系。 其他研究由读者自行决定。

工具选项

有许多可用的工具，包括开源和商业工具。 我们将重点关注开放源代码工具，但是其中一些工具包含带有付费组件的开放核心模型。

其中一些工具具有可观察性的其他组件-主要是警报和可视化。 这些将作为附加功能在本节中介绍，并且在后续文章中将不介绍。

普罗米修斯

这是针对云原生应用程序的最公认的时间序列监视解决方案。 它由Cloud Native Computing Foundation （CNCF）托管，但是它是由Matt Proud和Julius Volz创建的，并由SoundCloud赞助，并有早期的外部贡献者来帮助开发它。 Robust Perception的 Brian Brian建立了帮助公司采用Prometheus的业务。 他的网站上还有一个很棒的博客 。 Prometheus文档内容丰富，为理解和使用该工具提供了许多详细信息。

Prometheus是基于拉的系统，它使用本地配置来描述要收集的端点以及收集所需的时间间隔。 每个终结点都有一个客户端，该客户端收集数据并根据每个请求更新该表示（或配置客户端）。 收集这些数据并将其保存在本地磁盘上的高效存储引擎中。 存储系统每个指标使用仅附加文件。 这种存储不会造成损失，这意味着一年前数据的保真度与您今天所收集的数据一样高。 但是，您可能不想在本地保留那么多数据。 幸运的是，有一个远程存储选项可以长期保留和分析。

Prometheus包括一种用于选择和显示数据的高级表达语言，称为PromQL 。 可以以图形，表格形式显示此数据，或者由外部系统通过REST API使用这些数据。 表达式语言允许用户创建回归，分析实时数据或趋势历史数据。 标签也是过滤和查询数据的好工具。 标签可以与每个度量标准名称相关联。

Prometheus还提供了联盟模型，该模型通过允许团队拥有自己的Prometheis来鼓励更多本地化的控制，而中央团队也可以拥有自己的Prometheis 。 中央系统可以刮擦与本地Prometheis相同的端点，但是它们也可以刮擦本地Prometheis以获取本地实例正在收集的聚合数据。 这减少了端点上的开销。 该联合模型还允许本地实例相互收集数据。

Prometheus随附AlertManager来处理警报。 该系统允许警报以及更复杂的流的聚合，以限制警报的发送时间。

假设有10个节点在交换机关闭的同时突然关闭。 您可能不需要发送有关10个节点的警报，因为接收到它们的每个人在固定交换机之前可能将无能为力。 使用AlertManager，可以仅将警报发送给交换机的网络团队，并包括有关可能受影响的其他系统的其他信息。 还可以向系统团队发送电子邮件（而不是页面），以便他们知道那些节点已关闭，并且除非在交换机维修后系统没有启动，否则它们无需响应。 如果发生这种情况，则AlertManager将重新激活那些被开关警报抑制的警报。

石墨

石墨已经存在了很长时间，James Turnbull的最新著作《监测的艺术》详细介绍了石墨。 石墨在该行业中已无处不在，许多大型公司都在大规模使用它。

Graphite是基于推送的系统，通过使应用程序将数据推送到Graphite的Carbon组件中，可以从应用程序接收数据。 Carbon将这些数据存储在Whisper数据库中，该数据库和Carbon由Graphite Web组件读取，该组件允许用户在浏览器中绘制其数据图或通过API提取数据。 一个非常酷的功能是能够将这些图形导出为图像或数据文件，以将其轻松嵌入其他应用程序中。

Whisper是一个固定大小的数据库，可随时间提供快速，可靠的数字数据存储。 这是一个有损数据库，这意味着指标的分辨率会随着时间的推移而降低。 它将为最新系列提供高保真度指标，并随着时间的推移逐渐降低保真度。

石墨还使用点分隔命名，这意味着尺寸。 此维度允许对度量以及度量之间的关系进行一些创造性的汇总。 这样一来，就可以跨不同版本或数据中心聚合服务，并（具体而言）在特定Kubernetes集群的一个数据中心中运行一个版本。 还可以进行粒度比较，以确定特定集群是否表现不佳。

Graphite的另一个有趣功能是能够存储与时间序列指标有关的任意事件。 特别是，可以在Graphite中添加和跟踪应用程序或基础架构部署。 这使操作员或开发人员对问题进行故障排除，可以更深入地了解环境中与正在调查的异常行为相关的事件。

石墨还有大量可应用于度量标准系列的功能列表 。 但是，它缺少一些其他工具所包含的强大查询语言。 它还缺少任何警报功能或内置警报系统。

InfluxDB

InfluxDB是一个相对较新的参与者，比Prometheus更新。 它使用开放核模型，这意味着扩展和群集成本额外增加。 InfluxDB是较大的TICK堆栈 （Telegraf，InfluxDB，Chronograf和Kapacitor的）的一部分，因此在此分析中，我们将包括所有这些组件的功能。

与Prometheus和Graphite相似，InfluxDB使用称为标签的键值对系统为指标添加维数。 结果类似于我们之前在其他系统上讨论的结果。 度量标准数据的类型可以是float64 ， int64 ， bool和具有纳秒分辨率的字符串 。 这比该领域中的大多数其他工具范围更广。 实际上，与本地时间序列指标聚合系统相比，TICK堆栈更像是事件聚合平台。

InfluxDB使用类似于日志结构的合并树的系统进行存储。 在这种情况下，它称为时间结构合并树。 它使用预写日志和只读数据文件的集合，这些文件与“排序的字符串表”相似，但具有系列数据而不是纯日志数据。 这些文件按时间块分片。 要了解更多信息，请在InfluxData网站上查看此有用的资源 。

TICK堆栈的体系结构会有所不同，具体取决于它是开源版本还是商业版本。 开源InfluxDB系统是独立包含在单个主机中的，而商业版本是固有分布的。 其他中心组件也是如此。 在开源版本中，所有内容都在单个主机上运行。 外部系统上没有存储任何数据或配置，因此它相当易于管理，但不如商业版本强大。

InfluxDB包含一种类似SQL的语言，称为InfluxQL，用于从数据库中查询数据。 查询数据的主要手段是HTTP API。 查询语言没有像Prometheus那样多的内置辅助函数，但是熟悉SQL的人可能会对这种语言更满意。

TICK堆栈还包括一个警报系统。 该系统可以进行一些轻微的聚合，但是不具备Prometheus的AlertManager的全部功能。 但是，它确实提供了许多集成。 另外，为了减少InfluxDB的负载，可以安排连续查询来存储Kapacitor将选择用于警报的查询结果。

OpenTSDB

顾名思义， OpenTSDB是一个开源时间序列数据库。 在该工具集合中，它的独特之处在于将其指标存储在Hadoop中。 这意味着它具有固有的可扩展性。 如果您已经拥有Hadoop集群，那么对于要长期存储的指标而言，这可能是一个不错的选择。 如果您没有Hadoop集群，那么操作开销可能会太大而无法承受。 但是，OpenTSDB现在支持Google的Bigtable作为后端，这是您无需运行的云服务。

OpenTSDB与其他系统共享许多功能。 它使用键值配对系统，该系统调用标签以识别指标并增加维度。 它具有查询语言，但比Prometheus的PromQL受限制。 但是，它确实具有几个内置功能，有助于学习和使用。 该API是查询的主要入口点，类似于InfluxDB。 除非在HBase中设置了生存时间，否则该系统还将永久存储所有数据，因此您不必担心保真度下降。

OpenTSDB不提供警报功能，这将使其更难以与事件响应流程集成。 这种类型的系统对于长期Prometheus数据存储以及执行更多历史分析以揭示系统性问题可能非常有用，而不是作为快速识别和响应紧急问题的工具。

OpenMetrics标准

OpenMetrics是一个工作组，致力于为度量标准数据建立标准的展示格式。 它受到普罗米修斯的影响。 如果这项计划成功，我们将获得一个全行业的抽象概念，使我们可以轻松地在工具和提供者之间切换。 像Datadog这样的领先公司已经开始提供可以使用Prometheus博览会格式的工具，一旦发布，它将很容易转换为OpenMetrics标准。

还需要注意的是，该项目的贡献者包括Google和InfluxData（以及其他）。 这可能意味着InfluxDB最终将采用OpenMetrics标准。 这也可能意味着，如果表明Google的参与程度，那么三大云提供商之一将采用它。 当然，博览会格式已经在Google创建的Kubernetes项目中使用。 SolarWinds ， Robust Perception和SpaceNet也参与其中。

接下来要读什么

翻译自: https://opensource.com/article/18/8/open-source-monitoring-tools

监控工具 开源