社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
Prometheus是一个最初在SoundCloud上构建的开源系统监视和警报工具包 。自2012年成立以来，许多公司和组织都采用了Prometheus，该项目拥有一个非常活跃的开发人员和用户社区。它现在是一个独立的开源项目，可以独立于任何公司进行维护。为了强调这一点，并澄清项目的治理结构，Prometheus 于2016年加入 云计算本地计算基金会，作为继Kubernetes之后的第二个托管项目。
普罗米修斯的主要特点是：
Prometheus生态系统由多个组件组成，其中许多组件是可选的：
大多数Prometheus组件都是用Go编写的，因此很容易构建和部署为静态二进制文件。
此图说明了Prometheus的体系结构及其一些生态系统组件：
什么时候适合？
Prometheus适用于录制任何纯数字时间序列。它适用于以机器为中心的监控以及高度动态的面向服务架构的监控。在微服务的世界中，它对多维数据收集和查询的支持是一种特殊的优势。
什么时候不适合？
Prometheus专为提高可靠性而设计，是您在停电期间可以快速诊断问题的系统。每个Prometheus服务器都是独立的，不依赖于网络存储或其他远程服务。当基础架构的其他部分损坏时，您可以依赖它，并且您不需要设置大量的基础架构来使用它。
为您的平台下载最新版本的Prometheus，然后将其解压缩：
tar xvfz prometheus-*.tar.gz
cd prometheus-*
Prometheus服务器是一个名为prometheus（或prometheus.exe在Microsoft Windows上）的二进制文件。我们可以运行二进制文件并通过传递--help标志来查看其选项的帮助。
./prometheus --help
usage: prometheus [<flags>]
The Prometheus monitoring server
. . .
在启动Prometheus之前，让我们配置它。
普罗米修斯配置是YAML。Prometheus下载附带一个文件中的示例配置，称为prometheus.yml开始使用的好地方。
我们已经删除了示例文件中的大部分注释，使其更简洁（注释是以前缀为a的行#）。
global:
scrape_interval: 15s
evaluation_interval: 15s
rule_files:
# - "first.rules"
# - "second.rules"
scrape_configs:
- job_name: prometheus
static_configs:
- targets: ['localhost:9090']
有示例配置文件中配置的三个模块：global，rule_files，和scrape_configs。
该global块控制Prometheus服务器的全局配置。我们有两种选择。第一个，scrape_interval控制普罗米修斯刮擦目标的频率。您可以为单个目标覆盖此值。在这种情况下，全局设置是每15秒刮一次。该evaluation_interval选项控制普罗米修斯评估规则的频率。Prometheus使用规则创建新的时间序列并生成警报。
该rule_files块指定我们希望Prometheus服务器加载的任何规则的位置。现在我们没有规则。
最后一个块scrape_configs控制Prometheus监视的资源。由于Prometheus还将自己的数据公开为HTTP端点，因此它可以抓取并监控自身的健康状况。在默认配置中，有一个名为job的作业，prometheus它会擦除Prometheus服务器公开的时间序列数据。作业包含一个静态配置的目标，即localhoston端口9090。普罗米修斯希望指标可以在路径上的目标上获得/metrics。所以这个默认的工作是通过URL抓取：http：// localhost：9090 / metrics。
返回的时间序列数据将详细说明Prometheus服务器的状态和性能。
有关配置选项的完整规范，请参阅 配置文档。
要使用我们新创建的配置文件启动Prometheus，请切换到包含Prometheus二进制文件的目录并运行：
./prometheus --config.file=prometheus.yml
普罗米修斯应该启动。您还应该能够在http：// localhost：9090浏览到自己的状态页面。给它大约30秒的时间从自己的HTTP指标端点收集有关自己的数据。
您还可以通过导航到其自己的指标端点来验证Prometheus是否正在提供有关自身的指标：http：// localhost：9090 / metrics。
让我们试着看一下普罗米修斯收集的关于自己的一些数据。要使用Prometheus的内置表达式浏览器，请导航到 http：// localhost：9090 / graph并在“Graph”选项卡中选择“Console”视图。
您可以从http：// localhost：9090 / metrics收集，调用Prometheus自身导出的一个指标promhttp_metric_handler_requests_total（/metricsPrometheus服务器提供的请求总数）。继续并将其输入表达式控制台：
promhttp_metric_handler_requests_total
这应该返回许多不同的时间序列（以及为每个记录的最新值），所有时间序列都具有度量标准名称promhttp_metric_handler_requests_total，但具有不同的标签。这些标签指定不同的请求状态。
如果我们只对导致HTTP代码的请求感兴趣200，我们可以使用此查询来检索该信息：
promhttp_metric_handler_requests_total{code="200"}
要计算返回的时间序列数，您可以写：
count(promhttp_metric_handler_requests_total)
有关表达式语言的更多信息，请参阅 表达式语言文档。
要绘制表达式图表，请导航到http：// localhost：9090 / graph并使用“图表”选项卡。
例如，输入以下表达式来绘制在自我擦除的普罗米修斯中发生的返回状态代码200的每秒HTTP请求率：
rate(promhttp_metric_handler_requests_total{code="200"}[1m])
您可以尝试图形范围参数和其他设置。
仅从普罗米修斯那里收集指标并不能很好地反映普罗米修斯的能力。为了更好地了解普罗米修斯可以做什么，我们建议您浏览有关其他出口商的文档。在使用节点监控出口Linux或MacOS的主机指标指南是一个良好的开端。
Graphite专注于成为具有查询语言和图形功能的被动时间序列数据库。外部组件解决了任何其他问题。
Prometheus是一个完整的监控和趋势系统，包括基于时间序列数据的内置和主动抓取，存储，查询，绘图和警报。它了解世界应该是什么样的（应该存在哪些端点，什么时间序列模式意味着麻烦等），并积极尝试找出错误。
Graphite存储指定时间序列的数值样本，就像Prometheus一样。但是，Prometheus的元数据模型更丰富：虽然Graphite度量标准名称由隐式编码维度的点分隔组件组成，但Prometheus将维度显式编码为附加到度量标准名称的键值对（称为标签）。这允许通过查询语言通过这些标签轻松过滤，分组和匹配。
此外，特别是当Graphite与StatsD结合使用 时，通常只在所有受监视的实例上存储聚合数据，而不是将实例保留为维度并能够深入查看单个有问题的实例。
例如，将带有响应代码500和方法的HTTP服务器的HTTP请求数存储POST到/tracks端点通常会在Graphite / StatsD中进行编码：
stats.api-server.tracks.post.500 -> 93
在Prometheus中，相同的数据可以像这样编码（假设有三个api-server实例）：
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample1>"} -> 34
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample2>"} -> 28
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample3>"} -> 31
Graphite以Whisper格式将时间序列数据存储在本地磁盘上，这 是一种RRD样式的数据库，期望样本定期到达。每个时间序列都存储在一个单独的文件中，新的样本会在一定时间后覆盖旧的样本。
Prometheus还为每个时间序列创建一个本地文件，但允许在刮擦或规则评估发生时以任意间隔存储样本。由于简单地附加了新样本，因此旧数据可以任意长。普罗米修斯也适用于许多短暂的，经常变化的时间序列集。
Prometheus提供更丰富的数据模型和查询语言，并且更易于运行并集成到您的环境中。如果您想要一个可以长期保存历史数据的集群解决方案，Graphite可能是更好的选择。
InfluxDB是一个开源时间序列数据库，具有扩展和集群的商业选项。InfluxDB项目在普罗米修斯开发近一年后发布，因此当时我们无法将其视为替代方案。仍然，Prometheus和InfluxDB之间存在显着差异，两个系统都面向略有不同的用例。
为了公平比较，我们还必须将Kapacitor与InfluxDB一起考虑 ，因为它们可以解决与Prometheus和Alertmanager相同的问题空间。
与Graphite相同的范围差异 适用于InfluxDB本身。此外，InfluxDB提供连续查询，这相当于Prometheus录制规则。
Kapacitor的范围是Prometheus录制规则，警报规则和Alertmanager通知功能的组合。Prometheus 为图形和警报提供了更强大的查询语言。Prometheus Alertmanager还提供分组，重复数据删除和静音功能。
与Prometheus一样，InfluxDB数据模型将键值对作为标签，称为标签。此外，InfluxDB还有第二级标签称为字段，其使用范围更为有限。InfluxDB支持高达纳秒分辨率的时间戳，以及float64，int64，bool和字符串数据类型。相比之下，Prometheus支持float64数据类型，对字符串和毫秒分辨率时间戳的支持有限。
InfluxDB使用日志结构合并树的变体进行存储，其中包含按时间分片的预写日志。这比事件记录更适合于每个时间序列方法的Prometheus附加文件。
日志和指标和图表，哦，我的！ 描述事件记录和度量记录之间的差异。
Prometheus服务器彼此独立运行，仅依靠其本地存储来实现其核心功能：抓取，规则处理和警报。InfluxDB的开源版本与此类似。
商业InfluxDB产品按照设计是一个分布式存储集群，存储和查询由多个节点同时处理。
这意味着商业InfluxDB将更容易横向扩展，但这也意味着您必须从一开始就管理分布式存储系统的复杂性。Prometheus将更容易运行，但在某些时候，您将需要明确地沿着可扩展性边界（如产品，服务，数据中心或类似方面）对服务器进行分片。独立服务器（可以并行冗余运行）也可以为您提供更好的可靠性和故障隔离。
Kapacitor的开源版本没有用于规则，警报或通知的内置分布式/冗余选项。Kapacitor的开源版本可以通过用户的手动分片进行缩放，类似于Prometheus本身。Influx提供Enterprise Kapacitor，它支持HA /冗余警报系统。
相比之下，Prometheus和Alertmanager通过运行Prometheus的冗余副本并使用Alertmanager的高可用性 模式提供完全开源的冗余选项 。
系统之间有许多相似之处。两者都有标签（在InfluxDB中称为标签），以有效地支持多维度量。两者都使用基本相同的数据压缩算法。两者都有广泛的集成，包括彼此。两者都有钩子，允许您进一步扩展它们，例如分析统计工具中的数据或执行自动操作。
关于InfluxDB更好的地方：
普罗米修斯更好的地方：
InfluxDB由一家商业公司按照开放核心模型进行维护，提供封闭源集群，托管和支持等高级功能。Prometheus是一个完全开源和独立的项目，由许多公司和个人维护，其中一些还提供商业服务和支持。
OpenTSDB是一个基于Hadoop和HBase的分布式时间序列数据库 。
与Graphite相同的范围差异 适用于此处。
OpenTSDB的数据模型几乎与普罗米修斯相同：时间序列由一组任意键值对（OpenTSDB标签是Prometheus标签）标识。度量标准的所有数据都 存储在一起，从而限制了度量标准的基数。但是有一些细微差别：Prometheus允许标签值中的任意字符，而OpenTSDB则更具限制性。OpenTSDB还缺少完整的查询语言，只允许通过其API进行简单的聚合和数学运算。
OpenTSDB的存储是在Hadoop和HBase之上实现的 。这意味着可以轻松地水平扩展OpenTSDB，但您必须接受从一开始就运行Hadoop / HBase集群的整体复杂性。
Prometheus最初可以更简单地运行，但是一旦超过单个节点的容量就需要显式分片。
Prometheus提供了更丰富的查询语言，可以处理更高的基数指标，并构成完整监控系统的一部分。如果您已经在运行Hadoop并重视长期存储而不是这些优势，那么OpenTSDB是一个不错的选择。
Nagios是一个监控系统，起源于20世纪90年代的NetSaint。
Nagios主要基于脚本的退出代码进行警报。这些被称为“检查”。存在单个警报的静音，但没有分组，路由或重复数据删除。
有各种各样的插件。例如，允许管道几千字节的perfData插件返回到时间序列数据库（如Graphite）或使用NRPE 在远程计算机上运行检查。
Nagios是基于主机的。每个主机可以有一个或多个服务，每个服务可以执行一次检查。
没有标签或查询语言的概念。
除了当前的检查状态，Nagios本身没有存储空间。有些插件可以存储数据，例如可视化。
Nagios服务器是独立的。检查的所有配置都是通过文件。
Nagios适用于黑盒探测就足够的小型和/或静态系统的基本监控。
如果您想进行白盒监控，或者拥有动态或基于云的环境，那么Prometheus是一个不错的选择。
Sensu是一个可组合的监控管道，可以重用现有的Nagios检查。
与Nagios相同的一般范围差异适用于此处。
还有一个客户端套接字允许将特殊检查结果推送到Sensu。
Sensu与Nagios具有相同的粗略数据模型。
Sensu使用Redis来持久监控数据，包括Sensu客户端注册表，检查结果，检查执行历史记录和当前事件数据。
Sensu有许多组件。它使用RabbitMQ作为传输，使用Redis作为当前状态，使用单独的服务器进行处理和API访问。
可以对Sensu部署的所有组件（RabbitMQ，Redis和Sensu Server / API）进行集群，以实现高可用性和冗余配置。
如果您希望按原样扩展Nagios设置，或者想要利用Sensu的自动注册功能，那么Sensu是一个不错的选择。
如果您想进行白盒监控，或者拥有一个非常动态或基于云的环境，那么Prometheus是一个不错的选择。
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
