• 配置configuration
    • 配置文件 Configuration file
        • 节点node
        • 服务service
      • pod
        • endpoints端点

    配置configuration

    Prometheus可以通过命令行参数和配置文件来配置它的服务参数。命令行主要用于配置系统参数（例如：存储位置，保留在磁盘和内存中的数据量大小等），配置文件主要用于配置与抓取任务和任务下的实例相关的所有内容, 并且加载指定的抓取规则file。

    可以通过运行prometheus -h命令, 查看Prometheus服务所有可用的命令行参数，

    Prometheus服务可以reload它的配置。如果这个配置错误，则更改后的配置不生效。配置reolad是通过给Prometheus服务发送信号量SIGHUP或者通过http发送一个post请求到/-/reload。这也会重载所有配置的规则文件(rule files)。

    配置文件 Configuration file

    使用-config.file命令行参数来指定Prometheus启动所需要的配置文件。

    这个配置文件是YAML格式， 通过下面描述的范式定义, 括号表示参数是可选的。对于非列表参数，这个值被设置了默认值。

    通用占位符由下面定义：

    • \<boolean\>: 一个布尔值，包括true或者false.
    • \<duration\>: 持续时间，与正则表达式[0-9]+(ms|smhdwy)匹配
    • \<labelname\>: 一个与正则表达式[a-zA-Z_][a-zA-Z0-9_]*匹配的字符串
    • \<labelvalue\>: 一个为unicode字符串
    • \<filename\>: 当前工作目录下的有效路径
    • \<host\>: 一个包含主机名或者IP地址，并且可以带上一个非必需的端口号的有效字符串
    • \<path\>: 一个有效的URL路径
    • \<scheme\>: 一个可以是http或者https的字符串
    • \<string\>: 一个正则表达式字符串

    其他的占位符被分开指定：

    一个有效的配置文件示例。

    全局配置指定的参数，在其他上下文配置中是生效的。这也默认这些全局参数在其他配置区域有效。

    1. global:
    2.     # 抓取目标实例的频率时间值，默认10s
    3.     [ scrape_interval: <duration> | default = 10s ]
    5.     # 一次抓取请求超时时间值，默认10s
    6.     [ scrape_timeout: <duration> | default = 10s ]
    8.     # 执行配置文件规则的频率时间值, 默认1m
    9.     [ evaluation_interval: <duration> | default=1m ]
    11.     # 当和外部系统通信时(federation, remote storage, Alertmanager), 这些标签会增加到度量指标数据中
    12.     external_labels:
    13.         [ <labelname>: <labelvalue> ... ]
    15. # 规则文件指定规则文件路径列表。规则和警报是从所有匹配的文件中读取的
    16. rule_files:
    17.     [ - <filepath_glob> ...]
    19. # 抓取配置的列表
    20. scrape_configs:
    21.     [ - <scrape_config> ... ]   
    23. # 警报设置
    24. alerting:
    25.     alert_relabel_configs:
    26.     [  - <relabel_config> ... ]
    27.     alertmanagers:
    28.     [ - <alertmanager_config> ... ]
    30. # 设置涉及到未来的实验特征
    31. remote_write:
    32.     [url: <string> ]
    33.     [ remote_timeout: <duration> | default = 30s ]
    34.     tls_config:
    35.     [ <tls_config> ]
    36.     [proxy_url: <string> ]
    37.     basic_auth:
    38.     [user_name: <string> ]
    39.     [password: <string>  ]
    40.     write_relabel_configs:
    41.     [ - <relabel_config> ... ]

    <scrape_config>区域指定了目标列表和目标下的配置参数, 这些配置参数描述了如何抓取度量指标数据。通常，一个scrape_config只指定一个job，但是可以改变，一个scrape_config可以指定多个job，每个job下有多个targets

    通过static_configs参数静态指定要监控的目标列表，或者使用一些服务发现机制发现目标。

    另外，relabel_configs允许在获取度量指标数据之前，对任何目标和它的标签进行进一步地修改。

    1. # 默认下任务名称赋值给要抓取的度量指标
    2. job_name: <job_name>
    4. # 从这个任务中抓取目标的频率时间值
    5. [ scrape_interval: <duration> | default= <global_config.scrape_interval>]
    7. # 当抓取这个任务的所有目标时，超时时间值
    8. [ scrape_timeout: <duration> | default = <global_config.scrape_timeout> ]
    10. # 从目标列表中抓取度量指标的http资源路径, 默认为/metrics
    11. [ metrics_path: <path> | default = /metrics ]
    13. # honor_labels controls how Prometheus handles conflicts between would labels that are already present in scraped data and labels that Prometheus would attach server-side ("job" and "instance" labels, manually configured target  labels, and labels generated by service discovery implementations).
    14. # If honor_labels is set to "true", label conflicts are resolved by keeping label
    15. # values from the scraped data and ignoring the conflicting server-side labe# ls. If honor_labels is set to "false", label conflicts are resolved by ren# amin conflicting labels in the scraped data to "exported_<original-label>" (for example "exported_instance", "exported_job") and then attaching server-side labels. This is useful for use cases such as federation, where all label#s specified in the target should be preserved. Note that any globally configured "external_labels" are unaffected by this
    16. # setting. In communication with external systems, they are always applied 
    17. # only when a time series does not have a given label yet and are ignored otherwise.
    18. [ honor_labels: <boolean> | default = false ]
    20. # 配置请求的协议范式, 默认为http请求
    21. [ scheme: <scheme> | default = http ]
    23. # 可选的http url参数
    24. params:
    25.     [ <string>:[<string>, ...]]
    27. # 在`Authorization`头部设置每次抓取请求的用户名和密码
    28. basic_auth:
    29. [username: <string>]
    30. [password: <string>]
    32. # Sets the `Authorization` header on every scrape request with
    33. # the configured bearer token. It is mutually exclusive with `bearer_token_file`.
    34. [ bearer_token: <string> ]
    36. # Sets the `Authorization` header on every scrape request with the bearer token read from the configured file. It is mutually exclusive with `bearer_token`.
    37. [ bearer_token_file: /path/to/bearer/token/file ]
    39. # 配置抓取请求的TLS设置
    40. tls_config:
    41.   [ <tls_config> ]
    43. # 可选的代理URL
    44. [ proxy_url: <string> ]
    46. # 微软的Azure服务发现配置列表
    47. azure_sd_configs:
    48.   [ - <azure_sd_config> ... ]
    50. # Consul服务发现配置列表
    51. consul_sd_configs:
    52.   [ - <consul_sd_config> ... ]
    54. # DNS服务发现配置列表
    55. dns_sd_configs:
    56.   [ - <dns_sd_config> ... ]
    58. # 亚马逊EC2服务发现的配置列表
    59. ec2_sd_configs:
    60.   [ - <ec2_sd_config> ... ]
    62. # 文件服务发现配置列表
    63. file_sd_configs:
    64.   [ - <file_sd_config> ... ]
    66. # google GCE服务发现配置列表
    67. gce_sd_configs:
    68.   [ - <gce_sd_config> ... ]
    70. # Kubernetes服务发现配置列表
    71. kubernetes_sd_configs:
    72.   [ - <kubernetes_sd_config> ... ]
    74. # Marathon服务发现配置列表
    75. marathon_sd_configs:
    76.   [ - <marathon_sd_config> ... ]
    78. # AirBnB的Nerve服务发现配置列表
    79. nerve_sd_configs:
    80.   [ - <nerve_sd_config> ... ]
    82. # Zookeeper服务发现配置列表
    83. serverset_sd_configs:
    84.   [ - <serverset_sd_config> ... ]
    86. # Triton服务发现配置列表
    87. triton_sd_configs:
    88.   [ - <triton_sd_config> ... ]
    90. # 静态配置目标列表
    91. static_configs:
    92.   [ - <static_config> ... ]
    94. # 抓取之前的标签重构配置列表
    95. relabel_configs:
    96.   [ - <relabel_config> ... ]
    98. # List of metric relabel configurations.
    99. metric_relabel_configs:
    100.   [ - <relabel_config> ... ]
    102. # Per-scrape limit on number of scraped samples that will be accepted.
    103. # If more than this number of samples are present after metric relabelling
    104. # the entire scrape will be treated as failed. 0 means no limit.
    105. [ sample_limit: <int> | default = 0 ]

    记住：在所有获取配置中<job_name>必须是唯一的。

    <tls_config>允许配置TLS连接。

    1. # CA证书
    2. [ ca_file: <filename> ]
    4. # 证书和key文件
    5. [ cert_file: <filename> ]
    6. [ key_file: <filename> ]
    8. # ServerName extension to indicate the name of the server.
    9. # http://tools.ietf.org/html/rfc4366#section-3.1
    10. [ server_name: <string> ]
    12. # Disable validation of the server certificate.
    13. [ insecure_skip_verify: <boolean> ]

    Azure SD正处于测试阶段：在未来的版本中，仍然可能对配置进行实质性修改

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

    下面的测试标签在relabeling期间在目标上仍然是可用的：

    • __meta_azure_machine_id: 机器ID
    • __meta_azure_machine_location: 机器运行的位置
    • __meta_azure_machine_name: 机器名称
    • __meta_azure_machine_private_ip: 机器的内网IP
    • __meta_azure_machine_resource_group: 机器的资源组
    • __meta_azure_tag_<tagname>: 机器的每个tag值

    对于Azure发现，看看下面的配置选项：

    1. # The information to access the Azure API.
    2. # The subscription ID.
    3. subscription_id: <string>
    4. # The tenant ID.
    5. tenant_id: <string>
    6. # The client ID.
    7. client_id: <string>
    8. # The client secret.
    9. client_secret: <string>
    11. # Refresh interval to re-read the instance list.
    12. [ refresh_interval: <duration> | default = 300s ]
    14. # The port to scrape metrics from. If using the public IP address, this must
    15. # instead be specified in the relabeling rule.
    16. [ port: <int> | default = 80 ]

    Consul服务发现配置允许从Consul’s Catalog API中检索和获取目标。

    下面的meta标签在relabeling期间在目标上仍然是可用的：

    • __meta_consul_address: 目标地址
    • __meta_consul_dc: 目标的数据中心名称
    • __meta_consul_node: 目标的节点名称
    • __meta_consul_service_address: 目标的服务地址
    • __meta_consul_service_id: 目标的服务ID
    • __meta_consul_service_port: 目标的服务端口
    • __meta_consul_service: 这个目标属于哪个服务名称
    • __meta_consul_tags: 由标签分隔符链接的目标的标签列表
    1. # 下面配置是访问Consul API所需要的信息
    2. server: <host>
    3. [ token: <string> ]
    4. [ datacenter: <string> ]
    5. [ scheme: <string> ]
    6. [ username: <string> ]
    7. [ password: <string> ]
    9. # 指定对于某个目标的服务列表被检测， 如果省略，所有服务被抓取
    10. services:
    11.   [ - <string> ]
    13. # The string by which Consul tags are joined into the tag label.
    14. [ tag_separator: <string> | default = , ]

    注意：用于获取目标的IP和PORT，被组装到<__meta_consul_address>:<__meta_consul_service_port>。然而，在一些Consul创建过程中，这个相关地址在__meta_consul_service_address。在这些例子中，你能使用relabel特性去替换指定的__address__标签。

    一个基于DNS的服务发现配置允许指定一系列的DNS域名称，这些DNS域名被周期性地查询，用来发现目标列表。这些DNS服务是从/etc/resolv.conf获取的。

    这些服务发现方法仅仅支持基本的DNS A，AAAA和SRV记录查询，但不支持在RFC6763中指定更高级的DNS-SD方案。

    在重构标签阶段，这个标签__meta_dns_name在每一个目标上都是可用的，并且会设置生产发现的目标到记录名称中。

    1. # 将被查询的DNS域名列表
    2. names:
    3.   [ - <domain_name> ]
    5. # 要执行DNS查询类型，默认为SRV， 其他方式：A、AAAA和SRV
    6. [ type: <query_type> | default = 'SRV' ]
    8. # 如果查询类型不是SRV，这端口被使用
    9. [ port: <number>]
    11. # 刷新周期, 默认30s
    12. [ refresh_interval: <duration> | default = 30s ]

    <domain_name>必须是一个有效的DNS域名。<query_type>必须是SRV, A， AAAA三种之一。

    EC2 SD配置允许从AWS EC2实例中检索目标。默认情况下用内网IP地址, 但是在relabeling期间可以改变成公网ID地址。

    下面meta标签在relabeling期间在目标上是可用的：

    • __meta_ec2_availability_zone: 正在运行的实例的可用域。
    • __meta_ec2_instance_id: EC2的实例ID
    • __meta_ec2_instance_state: EC2的实例状态
    • __meta_ec2_instance_type: EC2的实例类型
    • __meta_ec2_private_ip: 如果存在，表示内网IP的地址
    • __meta_ec2_public_dns_name: 如果可用，表示实例的公网DNS名称
    • __meta_ec2_public_ip: 如果可用，表示实例的公网IP地址
    • __meta_ec2_subnet_id: 如果可用，表示子网IDs的列表。
    • __meta_ec2_tag_<tagkey>: 这个实例的tag值
    • __meta_ec2_vpc_id: 如果可用，表示正在运行的实例的VPC的ID

    对于EC2 discovery，看看下面的配置选项：

    1. # 访问EC2 API的信息
    3. # AWS域
    4. region: <string>
    6. # AWS API keys. 如果空白，环境变量`AWS_ACCESS_KEY_ID`和`AWS_SECRET_ACCESS_KEY`可以被使用
    7. [ access_key: <string> ]
    8. [ secret_key: <string> ]
    9. # Named AWS profile used to connect to the API.
    10. [ profile: <string> ]
    12. # Refresh interval to re-read the instance list.
    13. [ refresh_interval: <duration> | default = 60s ]
    15. # The port to scrape metrics from. If using the public IP address, this must
    16. # instead be specified in the relabeling rule.
    17. [ port: <int> | default = 80 ]

    基于文件的服务发现提供了一些通用方法去配置静态目标，以及作为插件自定义服务发现机制的接口。

    它读取包含零个或者多个<static_config>s的一些文件。通过磁盘监视器检测对所有定义文件的更改，并立即应用。文件可能以YAML或JSON格式提供。只应用于形成良好目标群体的变化。

    这个JSON文件必须包含静态配置的列表，使用这个格式：

    1. [
    2.   {
    3.     "targets": [ "<host>", ... ],
    4.     "labels": {
    5.       "<labelname>": "<labelvalue>", ...
    6.     }
    7.   },
    8.   ...
    9. ]

    文件内容也可以通过周期性刷新时间重新加载。

    在标签重构阶段，每个目标有一个meta标签__meta_filepath。它的值被设置成从目标中提取的文件路径。

    1. # Patterns for files from which target groups are extracted.
    2. files:
    3.   [ - <filename_pattern> ... ]
    5. # Refresh interval to re-read the files.
    6. [ refresh_interval: <duration> | default = 5m ]

    filename_pattern可以是以.json, .yml, .yaml结尾。最后路径段可以包含单个*，它匹配任何字符顺序，例如: my/path/tg_*.json。

    在v0.20, names: 用files:代替。

    GCE SD在测试中：在将来版本中，配置可能会有实质性变化。

    从GCP GCE实例中，GCE SD配置允许检索和获取目标。这个内网IP地址被默认使用，但是在relabeling期间，这个公网IP地址可能会发生变化。

    在relabeling期间，下面的meta标签在目标上是可用的：

    • __meta_gce_instance_name: 实例名称
    • __meta_gce_metadata_<name>: 实例每一个metadata项
    • __meta_gce_network: 实例的网络
    • __meta_gce_private_ip: 实例的内网IP
    • __meta_gce_project: 正在运行的GCP项目
    • __meta_gce_public_ip: 如果存在，表示GCP的公网IP地址
    • __meta_gce_subnetwork: 实例的子网
    • __meta_gce_tags: 实例的tag列表
    • __meta_gce_zone: 正在运行的实例的GCE区域

    对于GCE discovery，看看下面的配置选项：

    1. # The information to access the GCE API.
    3. # The GCP Project
    4. project: <string>
    6. # The zone of the scrape targets. If you need multiple zones use multiple
    7. # gce_sd_configs.
    8. zone: <string>
    10. # Filter can be used optionally to filter the instance list by other criteria
    11. [ filter: <string> ]
    13. # Refresh interval to re-read the instance list
    14. [ refresh_interval: <duration> | default = 60s ]
    16. # The port to scrape metrics from. If using the public IP address, this must
    17. # instead be specified in the relabeling rule.
    18. [ port: <int> | default = 80 ]
    20. # The tag separator is used to separate the tags on concatenation
    21. [ tag_separator: <string> | default = , ]

    Google Cloud SDK默认客户端通过查找一下位置发现凭据，优先选择找到的第一个位置：

    1. 由GOOGLE_APPLICATION_CREENTIALS环境变量指定的JSON文件
    2. 一个JSON文件在大家都熟悉的路径下：$HOME/.config/gclooud/application_default_credentials.json
    3. 从GCE元数据服务器获取

    如果Prometheus运行在GCE上，关联这个正在运行的实例的服务账号，应该至少可以从计算资源上有读取数据的权限。如果运行在GCE外面，需要确保创建一个合适的服务账号，并把证书文件放置在指定的某个地方。

    Kubernets SD在测试中，在将来的版本中，配置可能会有实质性的变化

    从Kubernetes’s REST API上，Kubernets SD配置允许检索和获取目标，并且始终保持与集群状态同步。

    下面role类型中的任何一个都能在发现目标上配置：

    节点node

    这个node角色发现带有地址的每一个集群节点一个目标，都指向Kublelet的HTTP端口。这个目标地址默认为Kubernetes节点对象的第一个现有地址，地址类型为NodeInernalIP, NodeExternalIP, NodeLegacyHostIP和NodeHostName。

    可用的meta标签：

    • __meta_kubernetes_node_name: 节点对象的名称
    • __meta_kubernetes_node_label_<labelname>: 节点对象的每个标签
    • __meta_kubernetes_node_annotation_<annotationname>: 节点对象的每个注释_meta_kubernetes_node_address: 如果存在，每一个节点对象类型的第一个地址

    另外，对于节点的instance标签，将会被设置成从API服务中获取的节点名称。

    服务service

    对于每个服务每个服务端口，service角色发现一个目标。对于一个服务的黑盒监控是通常有用的。这个地址被设置成这个服务的Kubernetes DNS域名, 以及各自的服务端口。

    可用的meta标签：

    • __meta_kubernetes_namespace: 服务对象的命名空间
    • __meta_kubernetes_service_name: 服务对象的名称
    • __meta_kubernetes_service_label_<labelname>: 服务对象的标签。
    • __meta_kubernetes_service_annotation_<annotationname>: 服务对象的注释
    • __meta_kubernetes_service_port_name: 目标服务端口的名称
    • __meta_kubernetes_service_port_number: 目标服务端口的数量
    • __meta_kubernetes_service_port_portocol: 目标服务端口的协议

    pod

    pod角色发现所有的pods，并暴露它们的容器作为目标。对于每一个容器的声明端口，单个目标被生成。 如果一个容器没有指定端口，每个容器的无端口目标都是通过relabeling手动添加端口而创建的。

    可用的meta标签：

    • __meta_kubernetes_namespace: pod对象的命名空间
    • __meta_kubernetes_pod_name: pod对象的名称
    • __meta_kubernetes_pod_ip: pod对象的IP地址
    • __meta_kubernetes_pod_label_<labelname>: pod对象的标签
    • __meta_kubernetes_pod_annotation_<annotationname>: pod对象的注释
    • __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 ready状态为true或者false
    • __meta_kubernetes_pod_node_name: pod调度的node名称
    • __meta_kubernetes_pod_host_ip: 节点对象的主机IP
    endpoints端点

    endpoints角色发现来自于一个服务的列表端点目标。对于每一个终端地址，一个目标被一个port发现。如果这个终端被写入到pod中，这个节点的所有其他容器端口，未绑定到端点的端口，也会被目标发现。

    可用的meta标签：

    • __meta_kubernetes_namespace: 端点对象的命名空间
    • __meta_kubernetes_endpoints_name: 端点对象的名称
    • 对于直接从端点列表中获取的所有目标，下面的标签将会被附加上。
      • __meta_kubernetes_endpoint_ready: endpoint ready状态设置为true或者false。
      • __meta_kubernetes_endpoint_port_name: 端点的端口名称
      • __meta_kubernetes_endpoint_port_protocol: 端点的端口协议
    • 如果端点属于一个服务，这个角色的所有标签：服务发现被附加上。
    • 对于在pod中的所有目标，这个角色的所有表掐你：pod发现被附加上

    对于Kuberntes发现，看看下面的配置选项：

    1. # The information to access the Kubernetes API.
    3. # The API server addresses. If left empty, Prometheus is assumed to run inside
    4. # of the cluster and will discover API servers automatically and use the pod's
    5. # CA certificate and bearer token file at /var/run/secrets/kubernetes.io/serviceaccount/.
    6. [ api_server: <host> ]
    8. # The Kubernetes role of entities that should be discovered.
    9. role: <role>
    11. # Optional authentication information used to authenticate to the API server.
    12. # Note that `basic_auth`, `bearer_token` and `bearer_token_file` options are
    13. # mutually exclusive.
    15. # Optional HTTP basic authentication information.
    16. basic_auth:
    17.   [ username: <string> ]
    18.   [ password: <string> ]
    20. # Optional bearer token authentication information.
    21. [ bearer_token: <string> ]
    23. # Optional bearer token file authentication information.
    24. [ bearer_token_file: <filename> ]
    26. # TLS configuration.
    27. tls_config:
    28.   [ <tls_config> ]

    <role>必须是endpoints, service, pod或者node。

    关于Prometheus的一个详细配置例子，见[路径]（https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml）

    你可能希望查看第三方的Prometheus操作符，它可以自动执行Kubernetes上的Prometheus设置。

    Marathon SD正在测试中：在将来的版本中配置可能会有实质性的变化

    Marathon SD配置使用MarathonREST API允许检索和获取目标。Prometheus将会定期地检查当前运行的任务REST端点，以及对每个app创建一个目标组，这个app至少有一个健康的任务。

    在relabeling期间，下面的meta标签在目标机上是可用的：

    • __meta_marathon_app: app的名称
    • __meta_marathon_image: 正在使用的Docker镜像名称
    • __meta_marathon_task: Mesos任务ID
    • __meta_marathon_app_label_<labelname>: 附加在app上的Marathon标签

    对于Marathon发现，详见下面的配置选项：

    1. # List of URLs to be used to contact Marathon servers.
    2. # You need to provide at least one server URL, but should provide URLs for
    3. # all masters you have running.
    4. servers:
    5.   - <string>
    7. # Polling interval
    8. [ refresh_interval: <duration> | default = 30s ]

    默认情况下，在Markdown的每个列出的app会被Prometheus抓取。如果不是所有提供Prometheus度量指标，你能使用一个Marathon标签和Prometheus relabeling去控制实际过程中被获取的实例。默认情况下所有的app也会以Prometheus系统中的一个任务的形式显示出来，这可以通过使用relabeling改变这些。

    从存储在Zookeeper中的AirBnB’s Nerve上，Nerve SD配置允许检索和获取目标。

    在relabeling期间，下面的meta标签在目标上是可用的：

    • __meta_nerve_path: 在Zookeeper集群中的端节点全路径
    • __meta_nerve_endpoint_host: 端点的IP
    • __meta_nerve_endpoint_port: 端点的端口
    • __meta_nerve_endpoint_name: 端点的名称
    1. # The Zookeeper servers.
    2. servers:
    3.   - <host>
    4. # Paths can point to a single service, or the root of a tree of services.
    5. paths:
    6.   - <string>
    7. [ timeout: <duration> | default = 10s ]

    Serverset SD配置允许检索和获取从存储在Zookeeper中的Serversetsd的目标。Servesets由Finagle和Aurora经常使用。

    在relabeling期间，下面的meta标签在目标上是可用的：

    • __meta_serverset_path: 在zookeeper里的serverset成员的全路径
    • __meta_serverset_endpoint_host: 默认端点的host
    • __meta_serverset_endpoint_port: 默认端点的端口
    • __meta_serverset_endpoint_host_<endpoint>: 给定端点的host
    • __meta_serverset_endpoint_port_<endpoint>: 给定端点的port
    • __meta_serverset_shard: 成员的分片数
    • __meta_serverset_status: 成员的状态
    1. # The Zookeeper servers.
    2. servers:
    3.   - <host>
    4. # Paths can point to a single serverset, or the root of a tree of serversets.
    5. paths:
    6.   - <string>
    7. [ timeout: <duration> | default = 10s ]

    Serverset数据必须是JSON格式，Thrift格式当前不被支持

    Triton SD正在测试中：在将来的版本中配置可能会有实质性的变化

    Triton SD配置允许从容器监控发现端点的目标中检索和获取。

    在relabeling期间，下面的meta标签在目标上是可用的：

    • __meta_triton_machine_id: 目标容器的UUID
    • __meta_triton_machine_alias: 目标容器的别名
    • __meta_triton_machine_image: 目标容器的镜像类型
    • __meta_triton_machine_server_id: 目标容器的服务UUID
    1. # The information to access the Triton discovery API.
    3. # The account to use for discovering new target containers.
    4. account: <string>
    6. # The DNS suffix which should be applied to target containers.
    7. dns_suffix: <string>
    9. # The Triton discovery endpoint (e.g. 'cmon.us-east-3b.triton.zone'). This is
    10. # often the same value as dns_suffix.
    11. endpoint: <string>
    13. # The port to use for discovery and metric scraping.
    14. [ port: <int> | default = 9163 ]
    16. # The interval which should should be used for refreshing target containers.
    17. [ refresh_interval: <duration> | default = 60s ]
    19. # The Triton discovery API version.
    20. [ version: <int> | default = 1 ]
    22. # TLS configuration.
    23. tls_config:
    24.   [ <tls_config> ]

    一个static_config允许指定目标列表，以及附带的通用标签。在获取配置中指定静态目标是规范的方法

    1. # The targets specified by the static config.
    2. targets:
    3.   [ - '<host>' ]
    5. # Labels assigned to all metrics scraped from the targets.
    6. labels:
    7.   [ <labelname>: <labelvalue> ... ]

    Relabeling是一个非常强大的工具，在获取度量指标之前，它可以动态地重写标签集合。 每个获取配置过程中，多个relabeling步骤能够被配置。它们按照出现在配置文件中的顺序，应用到每个目标的标签集中。

    最初，除了配置的每个目标标签之外，目标的作业标签设置为相应获取配置的job_name值，这个__address__标签设置为目标地址:。在relabeling之后，这个instance标签默认设置为__address__标签值。这个__scheme__和__metrics_path__标签设置为各自目标的范式和度量指标路径。 __param_<name>标签设置为成为<name>的第一个传入的URL参数。

    另外以__meta__为前缀的标签在relabeling阶段是可用的。他们由服务发现机制设置。

    在relabeling完成之后，由__开头的标签将会从标签集合从移除。

    如果一个relabeling步骤仅仅需要临时地存储标签值（作为后续relabeling步骤的输入），使用以__tmp为前缀的标签名称。这个前缀需要确保Prometheus本身从没有使用。

    1. # The source labels select values from existing labels. Their content is concatenated
    2. # using the configured separator and matched against the configured regular expression
    3. # for the replace, keep, and drop actions.
    4. [ source_labels: '[' <labelname> [, ...] ']' ]
    6. # Separator placed between concatenated source label values.
    7. [ separator: <string> | default = ; ]
    9. # Label to which the resulting value is written in a replace action.
    10. # It is mandatory for replace actions.
    11. [ target_label: <labelname> ]
    13. # Regular expression against which the extracted value is matched.
    14. [ regex: <regex> | default = (.*) ]
    16. # Modulus to take of the hash of the source label values.
    17. [ modulus: <uint64> ]
    19. # Replacement value against which a regex replace is performed if the
    20. # regular expression matches.
    21. [ replacement: <string> | default = $1 ]
    23. # Action to perform based on regex matching.
    24. [ action: <relabel_action> | default = replace ]

    <regex>是任何有效的正则表达式，它提供replace, keep, drop, labelmap, labeldrop, labelkeep动作，正则表达式处于两端。要取消指定正则表达式，请使用。..。

    <relabel_action>决定要采取的relabeling动作。

    • replace: 匹配与source_labels相反的regex。然后，设置target_label替换source_labels, 返回结果包括(${1}, ${2}, …)。 如果正则表达会不匹配，则不进行任何替换。
    • keep: 放弃与source_labels标签不匹配的目标
    • drop: 放弃与source_labels标签匹配的目标
    • hashmod: 将target_label设置为source_labels的散列模数
    • labelmap: 匹配所有的标签名称，然后将匹配到的标签值复制为由匹配组引用(${1}, ${2},…) 替换的标签名称替换为其值
    • labeldrop: 匹配所有的标签名称。然后删除匹配到的标签集合。
    • labelkeep: 匹配所有的标签名称。然后保留匹配到的标签集合。

    必须注意labeldrop和labelkeep, 以确保除去标签后，度量指标仍然会被唯一标识。

    在警告被发送到Alertmanager之前，警告relabeling应用到alerts。它有相同配置格式和目标relabeling动作。警告relabeling被应用到外部标签。

    一个用途是确保HA对Prometheus服务与不同的外部标签发送相同的警告。

    Alertmanager实例的动态发现是处于alpha状态。在将来的版本中配置会发生较大地更改。通过-alertmanager.url标志使用静态配置

    alertmanager_config区域指定了Prometheus服务发送警告的Alertmanager实例。它也提供参数配置与这些Alertmanagers的通信。

    Alertmanagers可以通过static_configs参数静态配置，或者使用服务发现机制动态发现目标。

    另外，从发现的实体和使用的API路径，relabel_configs允许从发现的实体列表和提供可使用的API路径中选择路径。这个api path是通过__alerts_path__标签暴露出来的。

    1. # Per-target Alertmanager timeout when pushing alerts.
    2. [ timeout: <duration> | default = 10s ]
    4. # Prefix for the HTTP path alerts are pushed to.
    5. [ path_prefix: <path> | default = / ]
    7. # Configures the protocol scheme used for requests.
    8. [ scheme: <scheme> | default = http ]
    10. # Sets the `Authorization` header on every request with the
    11. # configured username and password.
    12. basic_auth:
    13.   [ username: <string> ]
    14.   [ password: <string> ]
    16. # Sets the `Authorization` header on every request with
    17. # the configured bearer token. It is mutually exclusive with `bearer_token_file`.
    18. [ bearer_token: <string> ]
    20. # Sets the `Authorization` header on every request with the bearer token
    21. # read from the configured file. It is mutually exclusive with `bearer_token`.
    22. [ bearer_token_file: /path/to/bearer/token/file ]
    24. # Configures the scrape request's TLS settings.
    25. tls_config:
    26.   [ <tls_config> ]
    28. # Optional proxy URL.
    29. [ proxy_url: <string> ]
    31. # List of Azure service discovery configurations.
    32. azure_sd_configs:
    33.   [ - <azure_sd_config> ... ]
    35. # List of Consul service discovery configurations.
    36. consul_sd_configs:
    37.   [ - <consul_sd_config> ... ]
    39. # List of DNS service discovery configurations.
    40. dns_sd_configs:
    41.   [ - <dns_sd_config> ... ]
    43. # List of EC2 service discovery configurations.
    44. ec2_sd_configs:
    45.   [ - <ec2_sd_config> ... ]
    47. # List of file service discovery configurations.
    48. file_sd_configs:
    49.   [ - <file_sd_config> ... ]
    51. # List of GCE service discovery configurations.
    52. gce_sd_configs:
    53.   [ - <gce_sd_config> ... ]
    55. # List of Kubernetes service discovery configurations.
    56. kubernetes_sd_configs:
    57.   [ - <kubernetes_sd_config> ... ]
    59. # List of Marathon service discovery configurations.
    60. marathon_sd_configs:
    61.   [ - <marathon_sd_config> ... ]
    63. # List of AirBnB's Nerve service discovery configurations.
    64. nerve_sd_configs:
    65.   [ - <nerve_sd_config> ... ]
    67. # List of Zookeeper Serverset service discovery configurations.
    68. serverset_sd_configs:
    69.   [ - <serverset_sd_config> ... ]
    71. # List of Triton service discovery configurations.
    72. triton_sd_configs:
    73.   [ - <triton_sd_config> ... ]
    75. # List of labeled statically configured Alertmanagers.
    76. static_configs:
    77.   [ - <static_config> ... ]
    79. # List of Alertmanager relabel configurations.
    80. relabel_configs:
    81.   [ - <relabel_config> ... ]

    远程写是实验性的：在将来的版本中配置可能会实质性地变化

    url是发送样本的端点URL。remote_timeout指定发送请求到URL的超时时间。目前没有重试机制

    basic_auth, tls_config和proxy_url和在scrape_config区域里有相同的含义。

    write_relabel_configs是relabeling应用到样本数据的。写relabeling是应用到外部标签之后的。这可能有样本发送数量的限制。

    这里有一个小Demo，告诉你怎样使用这个功能