prometheus 监控服务端口

一、监控元数据管理系统 Amundsen 安装及使用

默认是服务在根目录：/var/lib/docker，修改到数据盘：/data/docker，端口使用软链接方式。监控

service docker stop

mv/var/lib/docker/data/

ln-sf/data/docker/var/lib/docker

service docker start

确保您至少有 3GB可用空间供 docker使用。服务

git clone--recursive []()

# For Neo4j Backend

docker-compose-f docker-amundsen.yml up

如有报错，端口解决方法可参考 FAQ

后台启动命令：

docker-compose-f docker-amundsen.yml up-d

prometheus+grafana搭建及配置参考

使用cadvisor服务监控docker容器运行，监控它本身也是服务一个容器。

运行 cadvisor容器

添加prometheus配置

添加grafana监控，端口导入code码： 193

[2021-12-01T08:02:56,监控599][INFO ][o.e.b.BootstrapChecks ] [PD4Rw8t] bound or publishing to a non-loopback address, enforcing bootstrap checks

es_amundsen_atlas| ERROR: [1] bootstrap checks failed

es_amundsen_atlas| [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

sqlalchemy.exc.OperationalError:(MySQLdb._exceptions.OperationalError)(1055,"Expression#1 of SELECT list is not in GROUP BY clause and contains nonaggregated column'hive.A0.CREATE_TIME' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by")

[SQL:

SELECT From_unixtime(A0.create_time) as create_time,

....

解决办法：先打开防火墙，打开5000端口限制，服务再关闭防火墙。端口然后搜索正常访问5000端口。监控

systemctl start firewalld

firewall-cmd--zone=public--add-port=5000/tcp--permanent

firewall-cmd--reload

systemctl stop firewalld

systemctl disable firewalld

二、服务普罗米修斯 Prometheus 入门

官方文档

Prometheus从被监控目标设备通过检索 metrics HTTP endpoints收集metrics。端口因为Prometheus自身也以同样的方式发布数据，所以它也可以监控自身的健康状态。

虽然Prometheus server仅采集自身的数据没什么意义，但是作为开始的范例很合适。

将下面的内容保存为 Prometheus配置文件prometheus.yml：

实际上安装包内已经包含了该文件，无需修改

查看其他配置项，请参阅 configuration documentation。

新开一个bash shell，查看服务和端口

访问测试

访问测试

我们试试查看Prometheus收集的自身的数据。要使用 Prometheus自带的 expression browser，导航到 ，选择"Graph" tab内的"Console" view。

既然你可以从 localhost:9090/metrics查看数据，那么可以看到一个Prometheus自己发布的指标 prometheus_target_interval_length_seconds(目标采集的实际间隔实际)。输入到expression console，然后点击"Execute":

如上，返回了一些不同的时间序列(along with the latest value recorded for each),都是 prometheus_target_interval_length_seconds的metric name，但是拥有不同的标签。这些标签显示了不同的时间段( latency percentiles)和目标组间隔(target group intervals)。

如果我们只对 99th percentile latencies有兴趣，我们可以通过如下查询：

要统计返回的时间序列数量，可以查询如下：

更多表达式语言参见 expression language documentation.

要图形表示，导航到 ，点击"Graph" tab。

比如，使用如下查询，图形表示demo Prometheus的per-second rate of chunks：

Experiment with the graph range parameters and other settings.

开始接入几个sample targets来演示。

Node Exporter用来作为范例，怎么使用参见 see these instructions.

范例监听在 , , and 。

现在我们配置 Prometheus来采集这些对象。我们把三个endpoints组成一个group到job内，称为node。假设，前两个是生产，第三个是金丝雀实例。为了在Prometheus区分，我们增加了数个endpoint组，给每个组增加标签。在范例中，我们将增加 group="production"标签给第一个组， group="canary"给第二个。

要实现这些，在prometheus.yml文件添加如下job定义到scrape_configs section，然后重启Prometheus实例。

回到 expression browser，确认 Prometheus现在已经有了关于这三个范例的信息，比如查询

虽然在范例中没有这个问题，但是当computed ad-hoc，跨成千上万时间序列的查询会变慢。为提升效率， Prometheus允许通过配置recording rules将预记录的表达式插入到新时间序列中。假设我们需要5分钟时间窗口(job, instance and mode dimensions)的平均值 per-second rate of cpu time(node_cpu_seconds_total)。我们可以查询如下：

实施图形展示。

要将这个表达式的值放到一个新metric job_instance_mode:node_cpu_seconds:avg_rate5m，使用下面的recording rule保存为 prometheus.rules.yml:

要让 Prometheus使用这个 rule，在 prometheus.yml添加 rule_files声明部分。如下是范例：

使用新配置文件重启 Prometheus，确认一个新指标 job_instance_mode:node_cpu_seconds:avg_rate5m可以通过expression browser查询了。

三、prometheus配置详解

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

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

因为部署在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访问 获取监控数据

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

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

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

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

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

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

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

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

获取的metrics的信息如下：

参考资料:业务性能指标