配置

浏览 0      扫码          2019-11-16 20:18:15     码农文档      译文原文 英文原文

公告:如果您也想加入翻译队伍,或者您有相关中文文档想要贡献给大家,请联系coderdocument@163.com ,谢谢!

Prometheus是通过命令行选项和配置文件进行配置的。虽然命令行选项配置不可变的系统参数(例如存储位置、要保存在磁盘和内存中的数据量等),但是配置文件定义了与抓取作业及其实例相关的所有内容,以及要加载哪些规则文件

可以运行 ./prometheus -h来查看所有可用命令行选项。

Prometheus可以在运行时重新加载配置。如果新配置格式有问题,则不会应用更改。通过向Prometheus进程发送SIGHUP或向/-/reload端点发送HTTP POST请求来触发配置重新加载(当启用了--web.enable-lifecycle 选项)。这还将重新加载任何已配置的规则文件。

配置文件

要指定要加载哪个配置文件,请使用--config.file 选项。

该文件以YAML格式编写,由下面描述的shcema进行定义。方括号表示参数是可选的。对于非列表参数,该值设置为指定的默认值。

通用占位符的定义如下:

  • <boolean>:一个可以取truefalse值的布尔值
  • <duration>:匹配正则表达式 [0-9]+(ms|[smhdwy])的持续时长
  • <labelname>:匹配正则表达式[a-zA-Z_][a-zA-Z0-9_]*的字符串
  • <labelvalue>:unicode字符串
  • <filename>:在当前工作目录的有效路径
  • <host>:由主机名或IP后跟可选端口号组成的有效字符串
  • <path>:有效的URL路径
  • <scheme>:值为httphttps的字符串
  • <string>:常规字符串
  • <secret>:保密的常规字符串,如密码
  • <tmpl_string>:在使用之前经过模板扩展的字符串

其他占位符是单独指定的。

这里可以找到一个有效的示例文件。

全局配置指定在所有其他配置上下文中生效的参数。它们还可以作为其他配置部分的默认值。


   
       

<scrape_config>

scrape_config部分指定了一组目标和参数,描述了如何抓取它们。一般情况下,一个抓取配置指定一个作业。在高级配置中,这可能会改变。

可以通过static_configs参数静态配置目标,也可以使用支持的服务发现机制之一动态发现目标。

此外,relabel_configs允许在抓取之前对任何目标及其标签进行高级修改。


   
       

其中<job_name>必须在所有抓取配置中是唯一的。

<tls_config>

tls_config允许配置TLS连接。


   
       

<azure_sd_config>

Azure SD配置允许从Azure虚拟机中检索抓取目标。

以下元标签在目标重新标记时可用:

  • __meta_azure_machine_id: 机器ID
  • __meta_azure_machine_location: 机器运行所在位置
  • __meta_azure_machine_name: 机器名称
  • __meta_azure_machine_os_type: 机器的操作系统
  • __meta_azure_machine_private_ip: 机器的私有IP
  • __meta_azure_machine_public_ip: 机器的公网IP(如果有)
  • __meta_azure_machine_resource_group: 机器的资源组
  • __meta_azure_machine_tag_<tagname>: 机器的每个标记(tag)值
  • __meta_azure_machine_scale_set: 虚拟机所属的伸缩集(scale set)名称(只有在使用伸缩集时才设置此值)
  • __meta_azure_subscription_id: 订阅ID
  • __meta_azure_tenant_id: 租户ID

Azure发现的配置选项如下:


   
       

<consul_sd_config>

Consul SD配置允许从Consul的目录(catalog)API检索抓取目标。

以下元标签在目标重新标记时可用:

  • __meta_consul_address: 目标地址
  • __meta_consul_dc: 目标所在的数据中心名称
  • __meta_consul_tagged_address_<key>: 目标的每个标记的(tagged)地址键值对
  • __meta_consul_metadata_<key>: 目标的每个节点元数据键值对
  • __meta_consul_node: 为目标定义的节点名称
  • __meta_consul_service_address: 目标的服务地址
  • __meta_consul_service_id: 目标的服务ID
  • __meta_consul_service_metadata_<key>: 目标的每个服务元数据键值对
  • __meta_consul_service_port: 目标的服务端口
  • __meta_consul_service: 目标所属的服务名称
  • __meta_consul_tags: 由标签分隔符连接的目标标记(tag)列表

   
       

注意,用于抓取目标的IP和端口由<__meta_consul_address>:<__meta_consul_service_port>组成。然而,在一些Consul设置中,相关地址在__meta_consul_service_address中 。在这种情况下,你可以使用relabel特性来替换特殊的__address__ 标签。

重新标记阶段是筛选基于任意标签的服务或服务节点的首选和更强大的方法。对于拥有数千个服务的用户,直接使用Consul API会更有效,因为它支持过滤节点(目前是通过节点元数据和单个标记)。

<dns_sd_config>

基于DNS的服务发现配置允许指定一组DNS域名,这些域名将定期查询以发现目标列表。从/etc/resolv.conf中读取要通信的DNS服务器。

此服务发现方式只支持基本的DNS A、AAAA和SRV记录查询,不支持RFC6763中指定的高级DNS-SD方式。

重新标记阶段,元标签__meta_dns_name 在每个目标上可用,并被设置为产生所发现目标的记录名。


   
       

其中<domain_name>是一个有效的DNS域名,<query_type>SRVAAAAA

<ec2_sd_config>

EC2 SD配置允许从AWS EC2实例中检索抓取目标。缺省情况下使用私有IP地址,但是可以通过重新标记将其更改为公网IP地址。

以下元标签在目标重新标记时可用:

  • __meta_ec2_availability_zone: 实例运行所在的可用性区域(zone)
  • __meta_ec2_instance_id: EC2实例ID
  • __meta_ec2_instance_state: EC2实例状态
  • __meta_ec2_instance_type: EC2实例类型
  • __meta_ec2_owner_id: 拥有EC2实例的AWS账户ID
  • __meta_ec2_platform: 操作系统平台,在windows服务器上设置为“windows”,否则不存在
  • __meta_ec2_primary_subnet_id: 主网络接口的子网ID(如果可用)
  • __meta_ec2_private_dns_name: 实例的私有DNS名称(如果可用)
  • __meta_ec2_private_ip: 实例的私有IP地址(如果存在)
  • __meta_ec2_public_dns_name: 实例的公网DNS名称(如果可用)
  • __meta_ec2_public_ip: 实例的公网IP地址(如果可用)
  • __meta_ec2_subnet_id: 正在运行实例的,逗号分隔的子网络ID列表(如果可用)
  • __meta_ec2_tag_<tagkey>: 实例的每个标记(tage)值
  • __meta_ec2_vpc_id: 正在运行实例的VPC的ID(如果可用)

下面是EC2发现的配置选项:


   
       

重新标记阶段是基于任意标签筛选目标的首选和更强大的方法。对于拥有数千个实例的用户,直接使用支持过滤实例的EC2 API可能更有效。

<openstack_sd_config>

OpenStack SD配置允许从OpenStack Nova实例中检索抓取目标。

可以配置以下<openstack_role>类型之一来发现目标:

hypervisor

hypervisor角色为每个Nova hypervisor节点发现一个目标。目标地址默认为hypervisor的host_ip属性。

以下元标签在目标重新标记时可用:

  • __meta_openstack_hypervisor_host_ip: hypervisor节点的IP地址
  • __meta_openstack_hypervisor_name: hypervisor节点名称
  • __meta_openstack_hypervisor_state: hypervisor节点的状态(state)
  • __meta_openstack_hypervisor_status: hypervisor节点的状态(status)
  • __meta_openstack_hypervisor_type: hypervisor节点类型

instance

instance角色为Nova实例的每个网络接口发现一个目标。目标地址默认为网络接口的私有IP地址。

以下元标签在目标重新标记时可用:

  • __meta_openstack_address_pool: 私有IP池
  • __meta_openstack_instance_flavor: OpenStack实例的风格(flavor)。
  • __meta_openstack_instance_id: OpenStack实例ID
  • __meta_openstack_instance_name: OpenStack实例名称
  • __meta_openstack_instance_status: OpenStack实例状态
  • __meta_openstack_private_ip: OpenStack实例私有IP
  • __meta_openstack_project_id: 拥有此实例的项目(租户)
  • __meta_openstack_public_ip: OpenStack实例公网IP
  • __meta_openstack_tag_<tagkey>: 实例标记(tage)值
  • __meta_openstack_user_id: 拥有租户的用户帐户

OpenStack发现的配置选项如下:


   
       

<file_sd_config>

基于文件的服务发现为配置静态目标提供了一种更通用的方法,并可作为插入自定义服务发现机制的接口。

它读取包含0个或多个<static_config>列表的一组文件。所有已定义文件的更改将通过磁盘监控检测到并立即应用。文件可能以YAML或JSON格式提供。只应用良好格式的目标组的更改。

JSON文件必须包含一个静态配置列表,使用如下格式:


   
       

作为回滚,文件内容也会在指定的刷新间隔内定期重新读取。

重新标记阶段,每个目标都有一个元标签__meta_filepath 。它的值被设置为抓取目标的文件路径。

此发现机制有一个集成列表。


   
       

其中<filename_pattern>可以是以.json.yml.yaml结尾的路径。最后一个路径部分可能包含一个匹配任何字符序列的*,例如:my/path/tg_*.json

<gce_sd_config>

GCE SD配置允许从GCP GCE实例中检索抓取目标。缺省情况下使用私有IP地址,但是可以通过重新标记将其更改为公网IP地址。

以下元标签在目标重新标记时可用:

  • __meta_gce_instance_id: 实例ID
  • __meta_gce_instance_name: 实例名称
  • __meta_gce_label_<name>: 实例的每个GCE标签
  • __meta_gce_machine_type: 实例的机器类型的完整或部分URL
  • __meta_gce_metadata_<name>: 实例的每个元数据项
  • __meta_gce_network: 实例的网络URL
  • __meta_gce_private_ip: 实例的私有IP地址
  • __meta_gce_project: 运行实例的GCP项目
  • __meta_gce_public_ip: 实例的公网IP地址(如果存在)
  • __meta_gce_subnetwork: 实例的公共IP地址(如果存在)
  • __meta_gce_tags: 用逗号分隔的实例标记列表
  • __meta_gce_zone: 实例运行所在的GCE区域URL

下面是GCE发现的配置选项:


   
       

谷歌云SDK默认客户端通过查找以下位置发现凭证,选择找到的第一个位置:

  1. GOOGLE_APPLICATION_CREDENTIALS环境变量指定的JSON文件
  2. 已知的$HOME/.config/gcloud/application_default_credentials.json JSON文件
  3. 从GCE元数据服务器获取

如果Prometheus是在GCE中运行的,那么与它所运行的实例相关联的服务帐户至少应该对计算资源具有只读权限。如果运行在GCE之外,请确保创建适当的服务帐户,并将凭证文件放置在预期的位置之一。

<kubernetes_sd_config>

Kubernetes SD配置允许从Kubernetes的REST API中检索抓取目标,并且始终与集群状态保持同步。

可以配置下列role类型之一来发现目标:

node

node角色为每个集群节点发现一个目标,地址默认为Kubelet的HTTP端口。目标地址默认为Kubernetes节点对象的第一个已存在地址,地址类型顺序为NodeInternalIPNodeExternalIPNodeLegacyHostIPNodeHostName

可用的元标签如下:

  • __meta_kubernetes_node_name: 节点对象名称
  • __meta_kubernetes_node_label_<labelname>: 节点对象的每个标签
  • __meta_kubernetes_node_labelpresent_<labelname>: 对于节点对象中的每个标签都为true
  • __meta_kubernetes_node_annotation_<annotationname>: 节点对象的每个注解
  • __meta_kubernetes_node_annotationpresent_<annotationname>: 对于节点对象中的每个注解都为true
  • __meta_kubernetes_node_address_<address_type>: 每个节点地址类型的第一个地址(如果存在的话)。

此外,节点的instance标签将设置为从API服务器检索到的节点名称。

service

service角色为每个服务的每个服务端口发现一个目标。这通常对于服务的黑盒监控非常有用。地址将设置为服务的Kubernetes DNS名称和相应的服务端口。

可用的元标签如下:

  • __meta_kubernetes_namespace: 服务对象的命名空间
  • __meta_kubernetes_service_annotation_<annotationname>: 服务对象的每个注解
  • __meta_kubernetes_service_annotationpresent_<annotationname>: 对于服务对象中的每个注解都为true
  • __meta_kubernetes_service_cluster_ip: 服务的群集IP地址。(不适用于ExternalName类型的服务)
  • __meta_kubernetes_service_external_name: 服务的DNS名称。(不适用于ExternalName类型的服务)
  • __meta_kubernetes_service_label_<labelname>: 服务对象的每个标签
  • __meta_kubernetes_service_labelpresent_<labelname>: 对于服务对象中的每个标签都为true
  • __meta_kubernetes_service_name: 服务对象名称
  • __meta_kubernetes_service_port_name: 目标的服务端口名称
  • __meta_kubernetes_service_port_protocol: 目标的服务端口名称协议

pod

pod角色发现所有pod并将它们的容器作为目标。对于容器声明的每个端口,都会生成一个目标。如果容器没有指定端口,则为每个容器创建一个无端口目标,以便通过重新标记手动添加端口。

可用的元标签如下:

  • __meta_kubernetes_namespace: pod对象的命名空间
  • __meta_kubernetes_pod_name: pod对象的名称
  • __meta_kubernetes_pod_ip: pod对象的pod IP
  • __meta_kubernetes_pod_label_<labelname>: pod对象的每个标签
  • __meta_kubernetes_pod_labelpresent_<labelname>: 对于pod对象中的每个标签都为true
  • __meta_kubernetes_pod_annotation_<annotationname>: pod对象的每个注解
  • __meta_kubernetes_pod_annotationpresent_<annotationname>: 对于pod对象中的每个注解都为true
  • __meta_kubernetes_pod_container_init: 如果容器是一个Init容器则为true
  • __meta_kubernetes_pod_container_name: 目标地址指向的容器的名称
  • __meta_kubernetes_pod_container_port_name: 容器端口名称
  • __meta_kubernetes_pod_container_port_number: 容器端口号
  • __meta_kubernetes_pod_container_port_protocol: 容器端口协议
  • __meta_kubernetes_pod_ready: pod的就绪状态,可设置为truefalse
  • __meta_kubernetes_pod_phase: pod生命周期,可设置为PendingRunningSucceededFailedUnknown
  • __meta_kubernetes_pod_node_name: pod调度所在的节点名称。
  • __meta_kubernetes_pod_host_ip: 对象的当前主机IP
  • __meta_kubernetes_pod_uid: pod对象的UID
  • __meta_kubernetes_pod_controller_kind: pod控制器的对象类型(kind)
  • __meta_kubernetes_pod_controller_name: pod控制器名称

endpoints

endpoint角色从列出的服务端点发现目标。对于每个端点地址,每个端口都发现一个目标。如果端点背后是一个pod,那么该pod的所有其它容器端口(没绑定到端点的端口)也将作为目标被发现。

可用的元标签如下:

  • __meta_kubernetes_namespace: 端点对象的命名空间
  • __meta_kubernetes_endpoints_name: 端点对象名称
  • 对于直接从端点列表中发现的所有目标(非根据底层pod中推断出的目标),添加了以下额外标签:
    • __meta_kubernetes_endpoint_hostname: 端点主机名
    • __meta_kubernetes_endpoint_node_name: 承载端点的节点的名称。
    • __meta_kubernetes_endpoint_ready: 端点的就绪状态,可设置为truefalse
    • __meta_kubernetes_endpoint_port_name: 端点端口的名称
    • __meta_kubernetes_endpoint_port_protocol: 端点端口的协议
    • __meta_kubernetes_endpoint_address_target_kind: 端点地址目标的类型
    • __meta_kubernetes_endpoint_address_target_name: 端点地址目标的名称
  • 如果端点属于某个服务,则附加 role: service发现的所有标签。
  • 对于所有背后为pod的端点,将附加 role: pod发现的所有标签。

ingress

ingress角色为每个ingress路径发现一个目标。这对于黑盒监控ingress通常是有用的。地址将被设置为ingress规约中指定的主机。

可用的元标签如下:

  • __meta_kubernetes_namespace: ingress对象的命名空间
  • __meta_kubernetes_ingress_name: ingress对象的名称
  • __meta_kubernetes_ingress_label_<labelname>: ingress对象的每个标签
  • __meta_kubernetes_ingress_labelpresent_<labelname>: 对于ingress对象中的每个标签都为true
  • __meta_kubernetes_ingress_annotation_<annotationname>: ingress对象的每个注解
  • __meta_kubernetes_ingress_annotationpresent_<annotationname>: 对于ingress对象中的每个注解都为true
  • __meta_kubernetes_ingress_scheme: ingress的协议schema,如果设置了TLS配置,则为https,默认值为http
  • __meta_kubernetes_ingress_path: ingress规约路径,默认为/

下面是Kubernetes发现的配置选项:


   
       

其中 <role> 必须为 endpointservicepodnodeingress

参见此示例Prometheus配置文件,以获得为Kubernetes配置Prometheus的详细示例。

你可能想要检出第三主的 Prometheus Operator,它可以实现Prometheus在Kubernetes上自动安装。

<marathon_sd_config>

Marathon SD配置允许使用 Marathon REST API检索抓取目标。Prometheus将定期检查REST端点当前运行的任务,并为每个至少有一个健康任务的应用程序创建一个目标组。

以下元标签在目标重新标记时可用:

  • __meta_marathon_app: 应用程序的名称(用破折号代替斜线)
  • __meta_marathon_image: 使用的Docker镜像名称(如果可用)
  • __meta_marathon_task: Mesos任务ID
  • __meta_marathon_app_label_<labelname>: 添加到应用的任何Marathon标签
  • __meta_marathon_port_definition_label_<labelname>: 端点定义标签
  • __meta_marathon_port_mapping_label_<labelname>: 端点映射标签
  • __meta_marathon_port_index: 端点索引号,例如: PORT1的为1

下面是Marathon发现的配置选项:


   
       

默认情况下,每一个在Marathon中列出的应用程序都将被Prometheus进行抓取。如果不是所有的服务都提供了Prometheus指标,那么你可以使用Marathon标签和Prometheus重新添加标签来控制哪些实例将被真正地抓取。参见Prometheus marathon-sd配置 ,以获得如何设置Marathon应用程序和Prometheus配置的实际示例。

默认情况下,所有的应用程序都会在Prometheus(配置文件中指定的)中显示为一个单独的作业,你也可以通过重新添加标签来改变它。

<nerve_sd_config>

Nerve SD配置允许从AirBnB的Nerve 中检索抓取目标,这些目标存储在Zookeeper中。

以下元标签在目标重新标记时可用:

  • __meta_nerve_path: 指向Zookeeper中端点节点的完整路径
  • __meta_nerve_endpoint_host: 端点的主机
  • __meta_nerve_endpoint_port: 端点的端口
  • __meta_nerve_endpoint_name: 端点的名称

   
       

<serverset_sd_config>

Serverset SD配置允许从存储在Zookeeper中的 Serverset中检索抓取目标。FinagleAurora.通常使用Serverset。

以下元标签在目标重新标记时可用:

  • __meta_serverset_path: Zookeeper中serverset成员节点的完整路径
  • __meta_serverset_endpoint_host: 默认端点的主机
  • __meta_serverset_endpoint_port: 默认端点的端口
  • __meta_serverset_endpoint_host_<endpoint>: 指定端点的主机
  • __meta_serverset_endpoint_port_<endpoint>: 指定端点的端口
  • __meta_serverset_shard: 成员的分片号
  • __meta_serverset_status: 成员的状态

   
       

Serverset数据必须是JSON格式,当前不支持Thrift格式。

<triton_sd_config>

Triton SD配置允许从Container Monitor 发现端点检索抓取目标。

以下元标签在目标重新标记时可用:

  • __meta_triton_groups: 属于目标的组列表,用逗号分隔符连接
  • __meta_triton_machine_alias: 目标容器的别名
  • __meta_triton_machine_brand: 目标容器的brand
  • __meta_triton_machine_id: 目标容器的UUID
  • __meta_triton_machine_image: 目标容器的镜像类型
  • __meta_triton_server_id: 目标容器的服务器UUID

   
       

<static_config>

static_config允许指定目标列表和为它们设置的公共标签。这是在抓取配置中指定静态目标的规范方法。


   
       

<relabel_config>

重新标记是一个强大的工具,可以在目标的标签集合被抓取之前动态地重写它。每个抓取配置可以配置多个重新标记步骤。它们按在配置文件中出现的顺序应用于每个目标的标签集合。

最初,除了为每个目标配置的标签外,还将目标的job标签设置为各个抓取配置的job_name值。将 __address__标签设置为目标的 <host>:<port>地址。重新标记后,如果在重新标记过程中没有设置instance标签,则默认将其设置为 __address__的值。分别为目标的schema和指标路径设置了__scheme____metrics_path__ 标签。将__param_<name> 标签设置为第一个传递的名为<name>的URL参数的值。

在重新标记阶段,可以使用前缀为__meta_的附加标签。它们是由提供目标的服务发现机制设置的,并且在不同的机制之间有所不同。

__开头的标签将在目标重新标记完成后从标签集合中移除。

如果重新标记步骤需要临时存储一个标签值(作为后续重新标记步骤的输入),请使用__tmp 标签名称前缀。这个前缀保证Prometheus自己永远不会使用。


   
       

<regex>是任何有效的RE2正则表达式replacekeepdroplabelmaplabeldroplabelkeep操作都需要它。正则表达式被锚定在两端。要取消对正则表达式的锚定,请使用 .*<regex>.*

<relabel_action>确定要采取的重新标记操作:

  • replace: 将regex与连接的source_labels匹配。然后,将target_label设置为replacement,用匹配组引用(${1}${2},…)替换它们的值。如果regex不匹配,则不进行替换。
  • keep: 删除regex与连接的source_labels不匹配的目标。
  • drop: 删除regex与连接的source_labels匹配的目标。
  • hashmod: 将target_label设置为连接的source_labels的散列modulus
  • labelmap: 将regex与所有标签名匹配。然后将匹配标签的值复制到用匹配组引用(${1}${2},…)替换它们的值所给出的标签名称。
  • labeldrop: 将regex与所有标签名匹配。任何匹配的标签都将从标签集合中删除。
  • labelkeep: 将regex与所有标签名匹配。任何不匹配的标签都将从标签集合中删除。

必须小心处理labeldroplabelkeep,以确保在删除标签之后,指标的标签仍然是唯一的。

<metric_relabel_configs>

作为摄入前的最后一步,对采样进行指标重新标记。它具有与目标重新标记相同的配置格式和操作。指标重新标记不适用于自动生成的时间序列,如up

这样做的一个用途是将那些代价太大而不能摄入的时间序列列入黑名单。

<alert_relabel_configs>

在将告警发送到Alertmanager之前,告警重新标记应用于告警。它具有与目标重新标记相同的配置格式和操作。告警重新标记在外部标签之后。

这样做的一个用途是确保具有不同外部标签的HA对Prometheus服务器发送相同的告警。

<alertmanager_config>

alertmanager_config部分指定Prometheus服务器发告警到的Alertmanager实例。它还提供了一些参数来配置如何与这些Alertmanager通信。

Alertmanager可以通过static_configs参数静态配置,也可以使用支持的服务发现机制之一动态发现。

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


   
       

<remote_write>

write_relabel_configs在将采样发送到远程端点之前对它们进行重新标记。应用写重新标记在外部标签之后。这可以用来限制发送哪些采样。

有一个如何使用这个功能的小演示


   
       

该特性有一个集成列表。

<remote_read>


   
       

该特性有一个集成列表。

返回顶部