prometheus 监控（prometheus监控应用程序）

本篇文章给大家谈谈prometheus 监控，以及prometheus监控应用程序对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享prometheus 监控的知识，其中也会对prometheus监控应用程序进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、Prometheus简介
• 2、Prometheus
• 3、普罗米修斯怎么监控主机oom detect
• 4、【实践】2.Prometheus命令和配置详解
• 5、prometheus配置详解
• 6、Prometheus局限性

Prometheus简介

Prometheus是一套开源的系统监控报警框架。如今越来越多的公司开始广泛使用Prometheus来提供近实时的、基于动态云环境和容器微服务、服务以及应用程序的内省监控。同时也用于监控传统架构的资源。

Prometheus作为新一代的云原生监控系统，拥有易于管理、查询功能强大、便于可视化、存储高效以及操作简单等特点。

在Prometheus之前市面已经出现了很多的监控系统，如Zabbix、Open-Falcon等。下表通过多维度展现了各自监控系统的优缺点

Prometheus是一个开源系统监控和警报工具包，最初是在SoundCloud构建的。自2012年成立以来，许多公司和组织都广泛运用了Prometheus，该项目拥有非常活跃的开发人员和用户社区。它现在是一个独立的开源项目，独立于任何公司进行维护。为了强调这一点，Prometheus在2016年加入了云计算基金会，成为继Kubernetes之后的第二个托管项目。

Prometheus有以下几个主要特点：

Prometheus生态系统包含多个组件，其中许多是可选的：

大多数Prometheus组件都是用Go编写的，因此易于构建和部署为静态二进制文件。

下图说明了Prometheus的架构及其生态系统组件：

Prometheus 直接或通过pushgateway抓取metrics。将数据存储在本地，并对这些数据运行规则，以便从现有数据聚合和记录新时间序列，或者生成警报。Grafana或其他API consumers可以用来将抓取的数据可视化。

Prometheus非常适合记录任何纯数字时间序列。它既适用于machine-centric监控，也适用于高度动态的service-oriented的架构监控。在微服务的领域，其对多维数据抓取和查询的支持是一种特别的优势。

Prometheus是您在中断期间也能正常使用并快速诊断问题的系统，是十分值得信赖的伙伴。每个Prometheus服务器都是独立的，而不依赖于网络存储或其他远程服务。当基础结构的其他部分损坏时，您仍可以依靠它来进行监控，并且无需设置广泛的基础结构也可使用它,在故障的情况下，仍可以查看系统可用的统计信息。如果您需要100%精确的统计数据的话，Prometheus可能不能完全满足您的需求，如果是这种情况，您可以运用其他系统来抓取和分析这部分需要精确的数据，然后将Prometheus用于余下的监控环节。

Prometheus

Prometheus是一个开源系统监控和报警工具包，具有活跃的生态系统。是一个多维数据模型，其中的时间序列数据由指标名称和键/值对识别。它不依赖分布式存储，单个服务器节点是自治的。通过一个中间网关支持推送时间序列，可以通过服务发现或静态配置来发现目标，支持多种模式的图表和仪表盘制作。

Prometheus具体架构图如下：

Prometheus 直接或通过中介推送网关从检测的作业中抓取指标，用于短期作业。 它将所有抓取的样本存储在本地，并对这些数据运行规则，以从现有数据聚合和记录新的时间序列或生成警报。 Grafana 或其他 API 使用者可用于可视化收集的数据。

--config.file="prometheus.yml" Prometheus配置文件路径。

--web.listen-address="0.0.0.0:9090" 用于监听UI、API和遥测的地址。

--web.config.file="" [EXPERIMENTAL] 可以启用TLS或认证的配置文件的路径。

--web.read-timeout=5m 超时读取请求和关闭空闲连接之前的最大持续时间。

--web.max-connections=512 最大同时连接数。

--web.external-url=<URL 外部可访问Prometheus所在的URL（例如，如果Prometheus通过反向代理提供服务）。用于生成返回到Prometheus本身的相对和绝对链接。如果URL有路径部分，它将用于为Prometheus服务的所有HTTP端点添加前缀。如果省略，将自动派生相关的URL组件。

--web.route-prefix=<path Web端点的内部路线的前缀。默认为-web.external-url的路径。

--web.user-assets=<path 静态资源目录的路径，位于 /user。

--web.enable-lifecycle 通过HTTP请求启用关闭和重新加载。

--web.enable-admin-api 启用管理控制行动的API端点。

--web.console.templates="consoles" 控制台模板目录的路径，位于/consoles。

--web.console.libraries="console_libraries" 控制台库目录的路径。

--storage.tsdb.path="data/" 指标存储的基本路径。仅用于server模式。

--storage.tsdb.retention.time = 样本在储存中保留多长时间。设置此标志后，它会覆盖“storage.tsdb.retention”。如果此标志、“storage.tsdb.retention”或“storage.tsdb.retention.size”均未设置，则保留时间默认为15d。支持的单位：y、w、d、h、m、s、ms。仅用于server模式。

--storage.tsdb.retention.size = 块存储的最大字节数。需要一个单位，支持的单位：B、KB、MB、GB、TB、PB、EB。例如：“512MB”。仅用于server模式。

--storage.tsdb.no-lockfile 不在数据目录中创建锁文件。仅用于server模式。

--storage.tsdb.allow-overlapping-blocks 允许重叠块，从而启用垂直压缩和垂直查询合并。仅用于服务器模式。

--storage.agent.path="data-agent/" 指标存储的基本路径。仅用于agent模式。

--storage.agent.wal-compression 压缩代理WAL。仅用于agent模式。

--storage.agent.retention.min-time= 当WAL被截断时，样本在被强行删除之前的最小年龄，仅用于agent模式。

--storage.agent.retention.max-time= 当WAL被截断时，样本在被强行删除之前的最大年龄，仅用于agent模式。

--storage.agent.no-lockfile 不在数据目录中创建锁文件。仅用于agent模式。

--storage.remote.flush-deadline=<duration 在关闭或重新加载配置时等待刷新样本的时间。

--storage.remote.read-sample-limit=5e7 在单个查询中通过远程读取接口返回的最大样本总数。 0 表示没有限制。对于流式响应类型，将忽略此限制。仅用于server模式。

--storage.remote.read-concurrent-limit=10 并发远程读取调用的最大数量。 0 表示没有限制。仅用于server模式。

--rules.alert.for-outage-tolerance=1h 为恢复“for”警报状态而容忍Prometheus中断的最长时间。仅用于server模式。

--rules.alert.for-grace-period=10m 警报和恢复“for”状态之间的最短持续时间。这仅适用于配置的“for”时间大于宽限期的警报。仅用于server模式。

--rules.alert.resend-delay=1m 在向 Alertmanager 重新发送警报之前等待的最短时间。仅用于server模式。

--alertmanager.notification-queue-capacity=10000 等待Alertmanager通知的队列容量。仅用于server模式。

--query.lookback-delta=5m 在表达式评估和联合期间，检索指标的最长回溯持续时间。仅用于server模式。

--query.timeout=2m 查询在中止之前可能需要的最长时间。仅用于server模式。

--query.max-concurrency=20 并发执行的最大查询数。仅用于server模式。

--query.max-samples=50000000 单个查询可以加载到内存中的最大样本数。请注意，如果查询尝试将比这更多的样本加载到内存中，查询将失败，因此这也限制了查询可以返回的样本数量。仅用于server模式。

--enable-feature= 逗号分隔的要启用的功能名称。有效选项：agent、exemplar-storage、expand-external-labels、memory-snapshot-on-shutdown、promql-at-modifier、promql-negative-offset、remote-write-receiver。extra-scrape-metrics、new-service-discovery-manager。

--log.level=info 只记录给定严重程度或以上的信息。其中之一：[debug, info, warn, error]。

--log.format=logfmt 日志信息的输出格式。其中之一：[logfmt, json]。

通用占位符定义如下：

全局配置区域：

scrape_config部分指定了一组描述如何抓取它们的目标和参数，目标可以通过static_configs参数静态配置或使用支持的服务发现机制之一动态发现。

Prometheus自身支持basic验证和TLS（将来可能会改变），也可以通过nginx开启basic验证。

Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。

一般来说可以将Exporter分为2类：

Prometheus UI提供了快速验证PromQL以及临时可视化支持的能力，而在大多数场景下引入监控系统通常还需要构建可以长期使用的监控数据可视化面板（Dashboard）。这时用户可以考虑使用第三方的可视化工具如Grafana，Grafana是一个开源的可视化平台，并且提供了对Prometheus的完整支持。

在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由AlertManager进行管理。在AlertManager中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式。AlertManager即Prometheus体系中的告警处理中心。

Alertmanager 处理客户端应用程序（例如 Prometheus 服务器）发送的警报。 它负责对它们进行重复数据删除、分组和路由到正确的接收器集成，例如Email、PagerDuty 或 OpsGenie。 它还负责警报的静音和抑制。

报警全家桶 https://github.com/feiyu563/PrometheusAlert

普罗米修斯怎么监控主机oom detect

一、监控主机（其prometheus 监控他主机一样）
1、被监控服务器需要安装node_exporter
（1）下载node_exporter-1.1.2.linux-amd64.tar.gz，解压到/usr/local目录下并重命名node_exporter
（2）启动 node_exporter
2、添加grafana服务器监控节点信息并重启，重启prometheus
3、查看是否添加成功打开浏览器输入prometheus 监控：
4、访问grafana，添加图像界面浏览器访问IP:3000端口
1、添加数据源5、导入模板，模板可以到官网下载，docker 主机监控模板prometheus 监控：193Liunx主机监控模板：9276
二、监控docker容器1、添加监控节点同理
2、在被监控服务器部署cadvisor容器
3、验证浏览器访问
4、添加数据源同理
5、导入模板同理。

【实践】2.Prometheus命令和配置详解

Prometheus配置方式有两种：
（1）命令行，用来配置不可变命令参数，主要是Prometheus运行参数，比如数据存储位置
（2）配置文件，用来配置Prometheus应用参数，比如数据采集，报警对接

不重启进程配置生效方式也有两种：
（1）对进程发送信号SIGHUP
（2）HTTP POST请求，需要开启--web.enable-lifecycle选项curl -X POST reload

配置文件格式是yaml格式，说明：
.yml或者.yaml 都是 yaml格式的文件，
yaml格式的好处: 和json交互比较容易
python/go/java/php 有yaml格式库，方便语言之间解析,并且这种格式存储的信息量很大。

命令行可用配置可通过prometheus -h来查看。

配置文件使用yml格式，配置文件中一级配置项如下，说明参考#备注内容。

配置文件中通用字段值格式
<boolean: 布尔类型值为true和false
<scheme: 协议方式包含http和https

原始配置文件内容：

全局默认的数据拉取间隔

全局默认的单次数据拉取超时，当报context deadline exceeded错误时需要在特定的job下配置该字段。

全局默认的规则(主要是报警规则)拉取间隔

该服务端在与其他系统对接所携带的标签

该字段配置与Alertmanager进行对接的配置
样例：

上面的配置中的 alert_relabel_configs 是指警报重新标记在发送到Alertmanager之前应用于警报。 它具有与目标重新标记相同的配置格式和操作，外部标签标记后应用警报重新标记，主要是针对集群配置。

这个设置的用途是确保具有不同外部label的HA对Prometheus服务端发送相同的警报信息。

Alertmanager 可以通过 static_configs 参数静态配置，也可以使用其中一种支持的服务发现机制动态发现，我们上面的配置是静态的单实例。

此外， relabel_configs 允许从发现的实体中选择 Alertmanager，并对使用的API路径提供高级修改，该路径通过 __alerts_path__ 标签公开。

完成以上配置后，重启Prometheus服务，用以加载生效，也可以使用热加载功能，使其配置生效。然后通过浏览器，访问 alerts 就可以看 inactive pending firing 三个状态，没有警报信息是因为我们还没有配置警报规则 rules 。

这里定义和prometheus集成的alertmanager插件，用于监控报警。后续会单独进行alertmanger插件的配置、配置说明、报警媒介以及route路由规则记录。

此项配置和 scrape_configs 字段中 relabel_configs 配置一样，用于对需要报警的数据进行过滤后发向 Alertmanager

说明
relabel-configs的配置允许你选择你想抓取的目标和这些目标的标签是什么。所以说如果你想要抓取这种类型的服务器而不是那种，可以使用relabel_configs

相比之下，metric_relabel_configs是发生在抓取之后，但在数据被插入存储系统之前使用。因此如果有些你想过滤的指标，或者来自抓取本身的指标（比如来自/metrics页面）你就可以使用metric_relabel_configs来处理。

该项目主要用来配置不同的 alertmanagers 服务，以及Prometheus服务和他们的链接参数。 alertmanagers 服务可以静态配置也可以使用服务发现配置。Prometheus以pushing 的方式向alertmanager传递数据。

alertmanager 服务配置和target配置一样，可用字段如下

这个主要是用来设置告警规则，基于设定什么指标进行报警（类似触发器trigger）。这里设定好规则以后，prometheus会根据全局global设定的evaluation_interval参数进行扫描加载，规则改动后会自动加载。其报警媒介和route路由由alertmanager插件实现。
样例：

"first_rules.yml"样例：

Prometheus 支持两种类型的 Rules ，可以对其进行配置，然后定期进行运算：recording rules 记录规则 与 alerting rules 警报规则，规则文件的计算频率与警报规则计算频率一致，都是通过全局配置中的 evaluation_interval 定义。

不论是recording rules还是alerting rules都要在组里面。

要在Prometheus中使用Rules规则，就必须创建一个包含必要规则语句的文件，并让Prometheus通过Prometheus配置中的rule_files字段加载该文件，前面我们已经讲过了。 其实语法都一样，除了 recording rules 中的收集的指标名称 record: <string 字段配置方式略有不同，其他都是一样的。

配置范例：

recording rules 是提前设置好一个比较花费大量时间运算或经常运算的表达式，其结果保存成一组新的时间序列数据。当需要查询的时候直接会返回已经计算好的结果，这样会比直接查询快，同时也减轻了PromQl的计算压力，同时对可视化查询的时候也很有用，可视化展示每次只需要刷新重复查询相同的表达式即可。

在配置的时候，除却 record: <string 需要注意，其他的基本上是一样的，一个 groups 下可以包含多条规则 rules ，Recording 和 Rules 保存在 group 内，Group 中的规则以规则的配置时间间隔顺序运算，也就是全局中的 evaluation_interval 设置。

配置范例：

上面的规则其实就是根据 record 规则中的定义，Prometheus 会在后台完成 expr 中定义的 PromQL 表达式周期性运算，以 job 为维度使用 sum 聚合运算符 计算 函数rate 对http_requests_total 指标区间 10m 内的增长率，并且将计算结果保存到新的时间序列 job:http_requests_total:rate10m 中， 同时还可以通过 labels 为样本数据添加额外的自定义标签，但是要注意的是这个 lables 一定存在当前表达式 Metrics 中。

模板是在警报中使用时间序列标签和值展示的一种方法，可以用于警报规则中的注释（annotation）与标签（lable）。模板其实使用的go语言的标准模板语法，并公开一些包含时间序列标签和值的变量。这样查询的时候，更具有可读性，也可以执行其他PromQL查询 来向警报添加额外内容，ALertmanager Web UI中会根据标签值显示器警报信息。

{{ $lable.<lablename}} 可以获取当前警报实例中的指定标签值

{{ $value }} 变量可以获取当前PromQL表达式的计算样本值。

调整好rules以后，我们可以使用 curl -XPOST http://localhost:9090/-/reload 或者 对Prometheus服务重启，让警报规则生效。

这个时候，我们可以把阈值调整为 50 来进行故障模拟操作，这时在去访问UI的时候，当持续1分钟满足警报条件，实际警报状态已转换为 Firing，可以在 Annotations中看到模板信息 summary 与 description 已经成功显示。

规则检查

拉取数据配置，在配置字段内可以配置拉取数据的对象(Targets)，job以及实例

定义job名称，是一个拉取单元。每个job_name都会自动引入默认配置如

这些也可以在单独的job中自定义

服务端拉取过来的数据也会存在标签，配置文件中也会有标签，这样就可能发生冲突。

true就是以抓取数据中的标签为准
false就会重新命名抓取数据中的标签为“exported”形式，然后添加配置文件中的标签

切换抓取数据所用的协议

定义可选的url参数

每次抓取数据请求的认证信息

password和password_file互斥只可以选择其一

bearer_token和bearer_token_file互斥只可以选择其一

抓取ssl请求时证书配置

通过代理去主去数据

Prometheus支持多种服务现工具，详细配置这里不再展开

更多参考官网： https://prometheus.io/docs/prometheus/latest/configuratio n/configuration/

服务发现来获取抓取目标为动态配置，这个配置项目为静态配置，静态配置为典型的targets配置，在改配置字段可以直接添加标签

采集器所采集的数据都会带有label，当使用服务发现时，比如consul所携带的label如下:

这些lable是数据筛选与聚合计算的基础。

抓取数据很繁杂，尤其是通过服务发现添加的target。所以过滤就显得尤为重要，我们知道抓取数据就是抓取target的一些列metrics，Prometheus过滤是通过对标签操作操现的，在字段relabel_configs和metric_relabel_configs里面配置，两者的配置都需要relabel_config字段。该字段需要配置项如下

target配置示例

target中metric示例

target中metric示例

使用示例
由以上可知当使用服务发现consul会带入标签__meta_consul_dc，现在为了表示方便需要将该标签变为dc

需要做如下配置，这里面action使用的replacement

过滤采集target

为了防止Prometheus服务过载，使用该字段限制经过relabel之后的数据采集数量，超过该数字拉取的数据就会被忽略

Prometheus可以进行远程读/写数据。字段remote_read和remote_write

（1）Prometheus 配置详解
https://www.dazhuanlan.com/2019/12/12/5df11ada207ce/
（2）Prometheus配置文件prometheus.yml 四个模块详解
http://yunwei.com/archives/7321
（3）官方文档说明
https://prometheus.io/docs/prometheus/latest/configuration/configuration/
（4）Prometheus监控神器-Rules篇
https://zhuanlan.zhihu.com/p/179295676
（5）Prometheus监控神器-Alertmanager篇(1)
https://zhuanlan.zhihu.com/p/179292686
（6）Prometheus监控神器-Alertmanager篇(2)
https://zhuanlan.zhihu.com/p/179294441

prometheus配置详解

本文按照官方文档的相关内容整理整理的配置语法以及实现功能

一个scrape_config 片段指定一组目标和参数prometheus 监控， 目标就是实例，指定采集的端点， 参数描述如何采集这些实例， 配置文件格式如下

因为部署在kubernetes环境中所以我只在意基于kubernetes_sd_configs的服务发现和static_configs静态文件的发现

relable_configss是功能强大的工具，就是Relabel可以在Prometheus采集数据之前，通过Target实例的Metadata信息，动态重新写入Label的值。除此之外，我们还能根据Target实例的Metadata信息选择是否采集或者忽略该Target实例。

relabel_configs

配置格式如下：

其中action主要包括:

replace：默认，通过regex匹配source_label的值，使用replacement来引用表达式匹配的分组
keep：删除regex与连接不匹配的目标 source_labels
drop：删除regex与连接匹配的目标 source_labels
labeldrop：删除regex匹配的标签
labelkeep：删除regex不匹配的标签
hashmod：设置target_label为modulus连接的哈希值source_labels
labelmap：匹配regex所有标签名称。然后复制匹配标签的值进行分组，replacement分组引用（ {2},…）替代

prometheus中的数值都是key:value格式， 其中replace、keep、drop都是对value的操作， labelmap、labeldrop、labelkeep都是对key的操作

replace是action的默认值， 通过regex匹配source_label的值，使用replacement来引用表达式匹配的分组

上面的列子中 address 的值为 $1:$2 ， 其中 $1 是正则表达式 ([^:]+)(?::\d+)? 从 address 中获取， $2 是正则表达式 (\d+)从(\d+) 中获取， 最后的 address 的数值为192.168.1.1:9100

上面的例子只要匹配__meta_kubernetes_service_annotation_prometheus_io_probe=true数据就保留， 反正source_labels中的值没有匹配regex中的值就丢弃

drop 的使用和keep刚好相反， 还是使用keep的例子:

上面的例子只要__meta_kubernetes_service_annotation_prometheus_io_probe这个标签的值为true就丢弃， 反之如果__meta_kubernetes_service_annotation_prometheus_io_probe!=true的数据就保留

labelmap的用法和上面说到replace、keep、drop不同， labelmap匹配的是标签名称， 而replace、keep、drop匹配的是value

上面例子中只要匹配到正则表达式 __meta_kubernetes_service_label_(.+) 的标签， 就将标签重写为 (.+) 中的内容， 效果如下：

待续

使用labeldrop则可以对Target标签进行过滤，删除符合过滤条件的标签，例如：

该配置会使用regex匹配当前target中的所有标签， 删除符合规则的标签， 反之保留不符合规则的

使用labelkeep则可以对Target标签进行过滤，仅保留符合过滤条件的标签，例如：

该配置会使用regex匹配当前target中的所有标签， 保留符合规则的标签， 反之不符合的移除

上面我们说到relabel_config是获取metrics之前对标签的重写， 对应的metric_relabel_configs是对获取metrics之后对标签的操作， metric_relabel_configs能够确定我们保存哪些指标，删除哪些指标，以及这些指标将是什么样子。

metric_relabel_configs的配置和relabel_config的配置基本相同， 如果需要配置相关参数请参考 2.scrape_configs

主要用途为指定exporter获取metrics数据的目标， 可以指定prometheus、 mysql、 nginx等目标

此规则主要是用于抓取prometheus自己数据的配置， targets列表中的为prometheus 获取metrics的地址和端口， 因为没有指定metrics_path所以使用默认的/metrics中获取数据，

简单理解就是， prometheus访问 http://localhost:9090/metrics 获取监控数据

还可以配置指定exporter中的目的地址， 如获取node_exporter的数据

简单理解为分别访问 metrics metrics metrics 获取metrics数据

kubernetes的服务发现可以刮取以下几种数据

通过指定kubernetes_sd_config的模式为endpoints，Prometheus会自动从Kubernetes中发现到所有的endpoints节点并作为当前Job监控的Target实例。如下所示，

该配置是使用kubernetes的发现机制发现kube-apiservers

上面的刮取配置定义prometheus 监控了如下信息：

该配置是自动发现kubernetes中的endpoints

可以看到relable_configs中的规则很多， 具体的内容如下

获取的metrics的信息如下：

Prometheus局限性

有三大局限性

Prometheus作为一个基于度量prometheus 监控的系统prometheus 监控，不适合存储事件或者日志等prometheus 监控，它更多的展示的是趋势性的监控，如果需要数据的精准性，可以考虑ELK或者其它日志架构

Prometheus认为只有最近的监控数据才有查询的需要

Prometheus不论是在采用 联邦集群 还是采用 Thanos ，都需要解决细节上的技术问题，比如prometheus 监控：耗尽CPU、消耗机器资源 关于prometheus 监控和prometheus监控应用程序的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 prometheus 监控的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于prometheus监控应用程序、prometheus 监控的信息别忘了在本站进行查找喔。