关于prometheus:Prometheus监控神器服务发现篇一

4次阅读

共计 6200 个字符，预计需要花费 16 分钟才能阅读完成。

本章节次要讲主动发现应用场景介绍与 Prometheus 基于文件、DNS 的主动发现配置

当咱们应用各类 exporter 别离对系统、数据库和 HTTP 服务进行监控指标采集，对于所有监控指标对应的 Target 的运行状态和资源应用状况，都是用 Prometheus 的动态配置性能 static_configs 来
手动增加主机 IP 和端口，而后重载服务让 Prometheus 发现。

对于一组比拟少的服务器的测试环境中，这种手动形式增加配置信息是最简略的办法。然而理论生产环境中，对于成千盈百的节点组成的大型集群又或者 Kubernetes 这样的大型集群，很显著，手动形式顾此失彼了。
为此，Prometheus 提前曾经设计了一套服务发现性能。

Prometheus 服务发现可能自动检测分类，并且可能辨认新节点和变更节点。也就是说，能够在容器或者云平台中，主动发现并监控节点或更新节点，动静的进行数据采集和解决。
目前 Prometheus 曾经反对了很多常见的主动发现服务，比方 consul ec2 gce serverset_sd_config openStack kubernetes 等等。
咱们罕用的就是 sd_config、DNS、kubernetes、consul 这些足够了。如果有须要其余配置的探讨，能够与我交换，我能够补上来。

本章节中会对 Prometheus 主动发现中的基于文件、DNS 进行发现解说，consul 在前面会独自开展来讲，如何能够使其完满的解决以后场景下常见的各类服务发现监控。

为什么要用主动发现?

在基于云 (IaaS 或者 CaaS) 的基础设施环境中用户能够像应用水、电一样按需应用各种资源（计算、网络、存储）。按需应用就意味着资源的动态性，这些资源能够随着需要规模的变动而变动。例如在 AWS 中就提供了专门的 AutoScall 服务，能够依据用户定义的规定动静地创立或者销毁 EC2 实例，从而使用户部署在 AWS 上的利用能够主动的适应拜访规模的变动。

这种按需的资源应用形式对于监控零碎而言就意味着没有了一个固定的监控指标，所有的监控对象 (基础设施、利用、服务) 都在动静的变动。对于 Nagias 这类基于 Push 模式传统监控软件就意味着必须在每一个节点上装置相应的 Agent 程序，并且通过配置指向核心的 Nagias 服务，受监控的资源与核心监控服务器之间是一个强耦合的关系，要么间接将 Agent 构建到基础设施镜像当中，要么应用一些自动化配置管理工具 (如 Ansible、Chef) 动静的配置这些节点。当然理论场景下除了基础设施的监控需要以外，咱们还须要监控在云上部署的利用，中间件等等各种各样的服务。要搭建起这样一套中心化的监控系统实施老本和难度是不言而喻的。

而对于 Prometheus 这一类基于 Pull 模式的监控零碎，显然也无奈持续应用的 static_configs 的形式动态的定义监控指标。而对于 Prometheus 而言其解决方案就是引入一个两头的代理人（服务注册核心），这个代理人把握着以后所有监控指标的访问信息，Prometheus 只须要向这个代理人询问有哪些监控指标控即可，这种模式被称为服务发现。

在不同的场景下，会有不同的货色扮演者代理人（服务发现与注册核心）这一角色。比方在 AWS 私有云平台或者 OpenStack 的公有云平台中，因为这些平台本身把握着所有资源的信息，此时这些云平台本身就表演了代理人的角色。Prometheus 通过应用平台提供的 API 就能够找到所有须要监控的云主机。在 Kubernetes 这类容器治理平台中，Kubernetes 把握并治理着所有的容器以及服务信息，那此时 Prometheus 只须要与 Kubernetes 打交道就能够找到所有须要监控的容器以及服务对象。Prometheus 还能够间接与一些开源的服务发现工具进行集成，例如在微服务架构的应用程序中，常常会应用到例如 Consul 这样的服务发现注册软件，Promethues 也能够与其集成从而动静的发现须要监控的应用服务实例。除了与这些平台级的私有云、公有云、容器云以及专门的服务发现注册核心集成以外，Prometheus 还反对基于 DNS 以及文件的形式动静发现监控指标，从而大大的缩小了在云原生，微服务以及云模式下监控施行难度。

如上所示，展现了 Push 零碎和 Pull 零碎的外围差别。相较于 Push 模式，Pull 模式的长处能够简略总结为以下几点：

  • 只有 Exporter 在运行，你能够在任何中央（比方在本地），搭建你的监控零碎；
  • 你能够更容易的查看监控指标实例的衰弱状态，并且能够疾速定位故障；
  • 更利于构建 DevOps 文化的团队；
  • 松耦合的架构模式更适宜于云原生的部署环境。

基于文件的服务发现

在 Prometheus 反对的泛滥服务发现的实现形式中，基于文件的服务发现是最通用的形式。这种形式不须要依赖于任何的平台或者第三方服务。对于 Prometheus 而言也不可能反对所有的平台或者环境。通过基于文件的服务发现形式下，Prometheus 会定时从文件中读取最新的 Target 信息，因而，你能够通过任意的形式将监控 Target 的信息写入即可。
用户能够通过 JSON 或者 YAML 格局的文件，定义所有的监控指标。例如，在上面的 yaml 文件中别离定义了 2 个采集工作，以及每个工作对应的 Target 列表：

yaml 格局

- targets: ['192.168.1.220:9100']
  labels:
    app:    'app1'
    env:   'game1'
    region: 'us-west-2'
- targets: ['192.168.1.221:9100']
  labels:
    app:    'app2'
    env:   'game2'
    region: 'ap-southeast-1'

json 格局

[
  {"targets": [ "192.168.1.221:29090"],
    "labels": {
      "app": "app1",
      "env": "game1",
      "region": "us-west-2"
    }
  },
  {"targets": [ "192.168.1.222:29090"],
    "labels": {
      "app": "app2",
      "env": "game2",
      "region": "ap-southeast-1"
    }
  }
]

同时还能够通过为这些实例增加一些额定的标签信息，例如应用 env 标签标示以后节点所在的环境，这样从这些实例中采集到的样本信息将蕴含这些标签信息，从而能够通过该标签依照环境对数据进行统计。

创立 Prometheus 配置文件 /data/prometheus/conf/prometheus-file-sd.yml，并增加以下内容：

  - job_name: 'file_sd_test'
    scrape_interval: 10s
    file_sd_configs:
    - files:
       - /data/prometheus/static_conf/*.yml
       - /data/prometheus/static_conf/*.json

这里定义了一个基于 file_sd_configs 的监控采集 test 工作，其中模式的工作名称为 file_sd_test。在 yml 文件中能够应用 yaml 标签笼罩默认的 job 名称，而后重载 Prometheus 服务。

service prometheus restat

在 Prometheus UI 的 Targets 下就能够看到以后从 targets.json 文件中动静获取到的 Target 实例信息以及监控工作的采集状态，同时在 Labels 列下会蕴含用户增加的自定义标签:

Prometheus 默认每 5m 从新读取一次文件内容，当须要批改时，能够通过 refresh_interval 进行设置，例如：

  - job_name: 'file_sd_test'
    scrape_interval: 10s
    file_sd_configs:
    - refresh_interval: 30s # 30s 重载配置文件
      files:
      - /data/prometheus/static_conf/*.yml
      - /data/prometheus/static_conf/*.json

通过这种形式，Prometheus 会主动的周期性读取文件中的内容。当文件中定义的内容发生变化时，不须要对 Prometheus 进行任何的重启操作。

这种通用的形式能够衍生了很多不同的玩法，比方与自动化配置管理工具 (Ansible) 联合、与 Cron Job 联合等等。对于一些 Prometheus 还不反对的云环境，比方国内的阿里云、腾讯云等也能够应用这种形式通过一些自定义程序与平台进行交互主动生成监控 Target 文件，从而实现对这些云环境中基础设施的自动化监控反对。

基于 DNS 的发现

对于一些环境，可能基于文件与 consul 服务发现曾经无奈满足的时候，咱们可能就须要 DNS 来做服务发现了。在互联网架构中，咱们应用主机节点或者 Kubernetes 集群通常是不对外裸露 IP 的，这就要求咱们在一个外部局域网或者专用的网络中部署 DNS 服务器，应用 DNS 服务来实现外部网络中的域名解析工作。
这个时候咱们就能够应用 Prometheus 的 DNS 服务发现，Prometheus 的 DNS 服务发现有俩种办法，第一种是应用 DNA A 记录来做主动发现，第二种办法是 DNS SRV，第一种显然没有没有 SRV 资源记录更为便捷，在这里就把俩种配置全副做一遍，对于取决用什么，依据你本人的环境来抉择。

DNA A 记录发现配置，首先你内网须要有一个 DNS 服务器，或者间接自行配置解析记录即可，我这里应用的 dnsmasq 服务在内网测试

# 验证 test1 DNS 记录
nslookup test1.example.com
Server:        127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:    test1.example.com
Address: 192.168.1.221
# 验证 test2 DNS 记录
nslookup test2.example.com
Server:        127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:    test2.example.com
Address: 192.168.1.222

Prometheus 配置

  # 基于 DNS A 记录发现
  - job_name: 'DNS-A'                  # job 名称
    metrics_path: "/metrics"            # 门路
    dns_sd_configs:
    - names: ["test1.example.com", "test2.example.com"]   # A 记录
      type: A                                   # 解析类型
      port: 29100                     # 端口

重启 Prometheus 在 targets 中能够看到 dns- a 记录

DNS SRV 是 DNS 资源记录中的一种记录类型，用来指定服务器地址与端口，并且能够设置每个服务器的优先级和权重。拜访到服务的时候，本地的 DNS resolver 从 DNS 服务器获取一个地址列表，而后依据优先级和权重来抉择一个地址作为本次申请的指标地址。

SRV 的记录格局：

_service._proto.name. TTL class SRV priority weight port target

| 参数 | 阐明 |
| :—–: | :—-: |
| _service | 服务名称，前缀 _ 是为了避免与 DNS 标签（域名）抵触 |
| proto | 服务应用的通信协定 通常是 tcp udp |
| name | 此记录无效域名 |
| TTL | 规范 DNS class 字段 如 IN |
| priority | 记录优先级，数值越小，优先级越高。[0-65535] |
| weight | 记录权重，数值越大，权重越高。[0-65535] |
| port | 服务应用端口 |
| target | 应用服务的主机地址名称 |

这里没有应用 named，而是应用的 dnsmasq 来做的测试，增加 SRV 记录实现后，须要重启 dnsmasq 服务使其失效。

# 配置 dns 解析
cat /etc/dnsmasq.d/localdomain.conf
address=/test1.example.com/192.168.1.221
address=/test2.example.com/192.168.1.222
# 增加 SRV 记录
cat /etc/dnsmasq.conf
srv-host =_prometheus._tcp.example.com,test1.example.com,29100
srv-host =_prometheus._tcp.example.com,test2.example.com,29100

# 验证 srv 服务是否正确，192.168.1.123 是外部 DNS 服务器，dig @192.168.1.123 +noall +answer SRV _prometheus._tcp.example.com
output...
_prometheus._tcp.example.com. 0    IN    SRV    0 0 9100 test1.example.com.
_prometheus._tcp.example.com. 0    IN    SRV    0 0 9100 test2.example.com.

Prometheus 配置实现当前，重载 Prometheus 服务。

  - job_name: 'DNS-SRV'                # 名称
    metrics_path: "/metrics"            # 获取数据的门路
    dns_sd_configs:                     # 配置应用 DNS 解析
    - names: ['_prometheus._tcp.example.com']   # 配置 SRV 对应的解析地址

这个时候在 targets 中能够看到 DNS 主动发现的记录了。

这个时候，咱们在新加一个记录，用来做主动发现。

# 增加 test0 解析
cat /etc/dnsmasq.d/localdomain.conf
address=/test1.example.com/192.168.1.221
address=/test2.example.com/192.168.1.222
address=/test0.example.com/192.168.1.220

# 增加 test0 SRV 记录
cat /etc/dnsmasq.conf
srv-host =_prometheus._tcp.example.com,test1.example.com,29100
srv-host =_prometheus._tcp.example.com,test2.example.com,29100
srv-host =_prometheus._tcp.example.com,test0.example.com,19100

# 验证 dns SRV 记录是否胜利
dig @192.168.1.123 +noall +answer SRV _prometheus._tcp.example.com
_prometheus._tcp.example.com. 0    IN    SRV    0 0 19100 test0.example.com.
_prometheus._tcp.example.com. 0    IN    SRV    0 0 29100 test2.example.com.
_prometheus._tcp.example.com. 0    IN    SRV    0 0 29100 test1.example.com.

这个时候在去察看 targets 就发现曾经能够主动发现 test0 了。

正文完
prometheus
发表至： prometheus
2020-08-25
 0
关于prometheus:使用VictoriaMetrics监控K8S集群
第03期Prometheus-数据采集二
关于prometheus:端口明明是通着的但WGCLOUD监测端口却显示失败
关于prometheus:第04期Prometheus-数据采集三

站内搜索

-「」