《Prometheus监控实战》第5章 服务发现

第5章 服务发现

• 服务发现可以通过以下几种机制实现

1. 从配置管理工具生成的文件中接收目标列表
2. 查询API（例如Amazon AWS API）以获取目标列表
3. 使用DNS记录以返回目标列表

5.1 静态配置的局限性

• 数据抓取生命周期

• 在现有的配置中，服务发现机制是在static_configs块中定义的
• 代码清单：静态服务发现

scrape_configs:
- job_name: 'prometheus'
  static_configs:
    - targets: ['localhost:9090']

- job_name: 'node'
  static_configs:
    - targets: ['11.11.11.111:9100', '11.11.11.112:9100', '11.11.11.113:9100']

• 需要更成熟的服务发现方式

1. 基于文件的方式
2. 基于云的方式
3. 基于DNS的方式

5.2 基于文件的服务发现

• 基于文件的发现只比静态配置更先进一小步，但它非常适合配置管理工具
• 代码清单：基于文件的服务发现

- job_name: node
  file_sd_configs:
    - files:
      - targets/nodes/*.json
      refresh_interval: 5m

- job_name: docker
  file_sd_configs:
    - files:
      - targets/docker/*.json
      refresh_interval: 5m

• 我们用file_sd_configs块替换prometheus.yml文件中的static_configs块。在这些块中，已经指定了文件列表，并包含在files列表中。我们在父目录targets下为每个作业指定了对应的文件，并为每个作业创建了一个子目录。你可以创建适合你的任何文件结构
• 每次作业运行或这些文件发生变化时，Prometheus都会重新加载文件的内容。以防万一，我们还指定了refresh_interval选项，该选项将在每个间隔结束时加载文件列表中的目标——对这个示例来说是5分钟
• 提示：还有一个名为prometheus_sd_file_mtime_seconds的指标将告诉你文件的上次更新时间。你可以监控这个指标以识别数据过期问题
• 我们快速创建上述的目录结构
• 代码清单：创建目标文件目录

cd /etc/prometheus
mkdir -p targets/{nodes,docker}

• 将节点和Docker守护进程列表移动到新的JSON文件，创建两个文件来保存这些目标
• 代码清单：创建保存目标的JSON文件

touch targets/nodes/nodes.json
touch targets/docker/daemons.json

• 首先填充node.json文件
• 代码清单：node.json文件

[{
    "targets": ["138.197.26.39:9100", "138.197.30.147:9100", "138.197.30.163:9100"]
}]

• 然后是daemons.json文件
• 代码清单：daemons.json文件

[{
    "targets": ["138.197.26.39:8080", "138.197.30.147:8080", "138.197.30.163:8080"]
}]

• 也可以通过yaml格式实现和使用JSON的目标列表是一样的

- targets:
  - "138.197.26.39:8080"
  - "138.197.30.147:8080"
  - "138.197.30.163:8080"

• 也可以为这些目标添加标签
• 代码清单：添加标签

[{
    "targets": ["138.197.26.39:8080", "138.197.30.147:8080", "138.197.30.163:8080"],
    "labels": {"datacenter": "nj"}
}]

• 基于文件的服务发现会在重新标记阶段自动给每个目标添加一个元数据标签__meta_filepath，它包括配置目标的文件路径和文件名
• 注意：可以访问https://localhost:9090/service-discovery，通过web界面查看服务发现目标的完整列表及其元数据标签

编写文件

• 如果你要自定义编写脚本，则可以遵循以下几条简单的规则：

1. 使你的服务发现可配置——不要采用硬编码方式。最好确保你的文件发现能够使用默认配置自动 运行
2. 不要在配置中暴露API密钥或密码等信息，应该依靠密钥保管库或环境变量（https://www.12factor.net/）
3. 针对输出目标的文件的操作应该是原子的

• 注意：在Prometheus文档中还有一个基于文件的服务发现集成列表（https://prometheus.io/docs/operating/integrations/#file-service-discovery）

5.3 基于API的服务发现

• 当前可用的本机服务发现插件包括以下平台

1. Amazon EC2
2. Azure
3. Consul
4. Google Compute Cloud
5. Kubernetes（https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config）

5.4 基于DNS的服务发现

• DNS服务发现允许你指定DNS条目列表，然后查询这些条目中的记录以发现目标列表。它依赖于A、AAAA或SRV DNS记录查询
• 提示：DNS记录将由Prometheus服务器上本地定义的DNS服务器解析。例如，Linux上的/etc/resolv.conf
• 代码清单：DNS服务发现作业

- job_name: webapp
  dns_sd_configs:
    - names: ['_prometheus._tcp.example.com']

• 我们定义了一个名为webapp的新作业 ，并指定了一个dns_sd_configs块。在该块中，我们指定了names参数，其中包含要查询的DNS条目列表
• 默认情况下，Prometheus的DNS服务发现假定你会查询SRV或服务发现。服务记录是一种在DNS配置中定义服务的方法，服务通常由运行服务的一个或多个目标主机和端口组合组成。DNS SRV条目的格式如下所示
• 代码清单：SRV记录

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

• 其中_service是要查询的服务名称，__proto是服务的协议，通常是TCP或UDP。我们指定条目的名称，后面以"."结尾，然后是记录的TTL（Time To Live）时间。IN是标准的DNS类（通常都会用IN）。我们指定目标主机的优先级（priority）：较低的值 具有较高的优先级
• 代码清单：示例的SRV记录

_prometheus._tcp.example.com 300 IN SRV 10 1 9100 webapp1.
_prometheus._tcp.example.com 300 IN SRV 10 1 9100 webapp2.
_prometheus._tcp.example.com 300 IN SRV 10 1 9100 webapp3.

• 当Prometheus查询目标时，它会通过DNS服务器查找example.com域。然后，它将在该域中搜索名为_prometheus._tcp.example.com的SRV记录，并返回该条目中的服务记录。在该条目中有三条记录，因此我们会看到返回了三个目标
• 代码清单：SRV的DNS目标

webapp1.example.com
webapp2.example.com
webapp3.example.com

• 还可以使用DNS服务发现来查询单个A或AAAA记录。为此，我们需要为抓取明确指定查询类型的端口。之所以需要指定端口，是因为A或AAAA记录只返回主机，而不是像SRV记录那样返回主机和端口组合
• 代码清单：DNS A记录服务发现作业

- job_name: webapp
  dns_sd_configs:
    - names: ['example.com']
      type: A
      port: 9100

• 这只返回example.com域根目录下的所有A记录
• 代码清单：DNS子域A记录服务发现作业

- job_name: webapp
  dns_sd_configs:
    - names: ['web.example.com']
      type: A
      port: 9100

• 我们提取了一个子域web.example.com的A记录解析，并在后面加上9100端口后缀
• 提示：DNS服务发现中只有一个元数据标签__meta_dns_name，它被设置为生成目标的特定DNS记录