├── LICENSE ├── README.md ├── alerting ├── Alerting_overview.md ├── Alertmanager.md ├── Clients.md ├── Configuration.md ├── Notification_template_example.md ├── Notification_template_reference.md └── README.md ├── best_practices ├── Alerting.md ├── Consoles_and_dashboards.md ├── Histograms_and_summaries.md ├── Instrumentation.md ├── Metric_and_label_naming.md ├── README.md ├── Recording_rules.md └── When_to_use_the_pushgateway.md ├── concepts ├── Data_model.md ├── Jobs_and_instances.md ├── Metric_types.md └── README.md ├── guides ├── Basic_auth.md ├── Instrumenting_a_go_application.md ├── Monitoring_docker_container_metrics_using_cadvisor.md ├── Monitoring_linux_host_metrics_with_the_node_exporter.md ├── README.md ├── TLS_encryption.md └── Use_file_based_service_discovert_to_discover_scrape_targets.md ├── instrumenting ├── Client_libraries.md ├── Exporters_and_integrations.md ├── Exposition_formats.md ├── Pushing_metrics.md ├── README.md ├── Writing_client_libaries.md └── Writing_exporters.md ├── introductions ├── Comparison_to_alternatives.md ├── FAQ.md ├── FirstSteps.md ├── Glossary.md ├── Media.md ├── Overview.md ├── README.md └── Roadmap.md ├── operating ├── Integrations.md ├── README.md └── Security.md ├── prometheus ├── API_Stability.md ├── Federation.md ├── Getting_started.md ├── Installation.md ├── Management_API.md ├── Migration.md ├── README.md ├── Storage.md ├── configuration │ ├── Altering_rules.md │ ├── README.md │ ├── Recording_rules.md │ ├── Template_examples.md │ ├── Template_reference.md │ ├── Unit_Testing_for_Rules.md │ └── configuration.md └── querying │ ├── Basics.md │ ├── Examples.md │ ├── Functions.md │ ├── HTTP_API.md │ ├── Operators.md │ └── README.md └── visualization ├── Console_template.md ├── Expression_browser.md ├── Grafana.md └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | Copyright 2019 Alrights 2 | 3 | Licensed under the Apache License, Version 2.0 (the "License"); 4 | you may not use this file except in compliance with the License. 5 | You may obtain a copy of the License at 6 | 7 | http://www.apache.org/licenses/LICENSE-2.0 8 | 9 | Unless required by applicable law or agreed to in writing, software 10 | distributed under the License is distributed on an "AS IS" BASIS, 11 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | See the License for the specific language governing permissions and 13 | limitations under the License. 14 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Prometheus官方文档中文版，个人翻译学习使用 2 | 3 | ![](https://github.com/Alrights/pics/raw/master/prometheus/logo.png) 4 | 5 | Prometheus是一个开源系统监控和警报系统。 6 | 7 | * [介绍](introductions/README.md) 8 | - [总览](introductions/Overview.md) 9 | - [开始](introductions/FirstSteps.md) 10 | - [对比](introductions/Comparison_to_alternatives.md) 11 | - [常见问题](introductions/FAQ.md) 12 | - [路线图](introductions/Roadmap.md) 13 | - [学习媒介](introductions/Media.md) 14 | - [词汇](introductions/Glossary.md) 15 | * [概念](concepts/README.md) 16 | - [数据模型](concepts/Data_model.md) 17 | - [度量指标类型](concepts/Metric_types.md) 18 | - [任务与实例](concepts/Jobs_and_instances.md) 19 | * [prometheus](prometheus/README.md) 20 | - [开始](prometheus/Getting_started.md) 21 | - [安装](prometheus/Installation.md) 22 | - [配置](prometheus/configuration/) 23 | * [配置](prometheus/configuration/configuration.md) 24 | * [记录规则](prometheus/configuration/Recording_rules.md) 25 | * [预警规则](prometheus/configuration/Altering_rules.md) 26 | * [模板例子](prometheus/configuration/Template_examples.md) 27 | * [模板参考](prometheus/configuration/Template_reference.md) 28 | * [规则的单元测试](prometheus/configuration/Unit_Testing_for_Rules.md) 29 | - [查询](prometheus/querying/) 30 | * [基本概念](prometheus/querying/Basics.md) 31 | * [操作符](prometheus/querying/Operators.md) 32 | * [函数](prometheus/querying/Functions.md) 33 | * [举例](prometheus/querying/Examples.md) 34 | * [HttpAPI](prometheus/querying/HTTP_API.md) 35 | - [存储](prometheus/Storage.md) 36 | - [联邦](prometheus/Federation.md) 37 | - [管理API](prometheus/Management_API.md) 38 | - [集成](prometheus/Migration.md) 39 | - [API稳定性](prometheus/API_Stability.md) 40 | * [可视化](visualization/README.md) 41 | - [表达式浏览器](visualization/Expression_browser.md) 42 | - [Grafana](visualization/Grafana.md) 43 | - [控制模板](visualization/Console_template.md) 44 | * [操作](operating/README.md) 45 | - [安全](operating/Security.md) 46 | - [集成](operating/Integrations.md) 47 | * [Instrumenting](instrumenting/README.md) 48 | - [客户端库](instrumenting/Client_libraries.md) 49 | - [写客户端库](instrumenting/Writing_client_libaries.md) 50 | - [推送度量指标](instrumenting/Pushing_metrics.md) 51 | - [导出与集成](instrumenting/Exporters_and_integrations.md) 52 | - [写导出器](instrumenting/Writing_exporters.md) 53 | - [导出格式](instrumenting/Exposition_formats.md) 54 | * [警告](alerting/README.md) 55 | - [警告概览](alerting/Alerting_overview.md) 56 | - [警告管理器](alerting/Alertmanager.md) 57 | - [配置](alerting/Configuration.md) 58 | - [客户端](alerting/Clients.md) 59 | - [通知模板参考](alerting/Notification_template_reference.md) 60 | - [通知模板例子](alerting/Notification_template_example.md) 61 | * [最佳实践](best_practices/README.md) 62 | - [指标和标签命名](best_practices/Metric_and_label_naming.md) 63 | - [控制台和面板](best_practices/Consoles_and_dashboards.md) 64 | - [instrumentation](best_practices/Instrumentation.md) 65 | - [直方图和summaries](best_practices/Histograms_and_summaries.md) 66 | - [预警](best_practices/Alerting.md) 67 | - [录制规则](best_practices/Recording_rules.md) 68 | - [什么时候使用Pushgateway](best_practices/When_to_use_the_pushgateway.md) 69 | * [教程](guides/README.md) 70 | - [基本授权](guides/Basic_auth.md) 71 | - [使用cAdvisor监控Docker容器指标](guides/Monitoring_docker_container_metrics_using_cadvisor.md) 72 | - [使用基于文件的服务发现抓取指标](guides/Use_file_based_service_discovert_to_discover_scrape_targets.md) 73 | - [使用Node Exporter监控Linux主机指标](guides/Monitoring_linux_host_metrics_with_the_node_exporter.md) 74 | - [Go应用指南](guides/Instrumenting_a_go_application.md) 75 | - [TLS加密](guides/TLS_encryption.md) 76 | -------------------------------------------------------------------------------- /alerting/Alerting_overview.md: -------------------------------------------------------------------------------- 1 | 使用普罗米修斯进行警报分为两部分。 Prometheus服务器中的警报规则会向Alertmanager发送警报。 然后，[Alertmanager](https://prometheus.io/docs/alerting/alertmanager/)管理这些警报，包括静音，禁止，聚合以及通过电子邮件，PagerDuty和HipChat等方法发送通知。 2 | 3 | 设置警报和通知的主要步骤如下： 4 | 5 | - 设置并[配置](https://prometheus.io/docs/alerting/configuration/)Alertmanager 6 | - [配置Prometheus](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Calertmanager_config)与Alertmanager交谈 7 | - 在Prometheus中创建[警报规则](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/) 8 | -------------------------------------------------------------------------------- /alerting/Alertmanager.md: -------------------------------------------------------------------------------- 1 | Alertmanager处理客户端应用程序（如Prometheus服务器）发送的警报。 它负责对它们进行重复数据删除，分组和路由，以及正确的接收器集成，例如电子邮件，PagerDuty或OpsGenie。 它还负责警报的静音和抑制。 2 | 3 | 以下描述了Alertmanager实现的核心概念。 请[参阅配置](https://prometheus.io/docs/alerting/configuration/)文档以了解如何更详细地使用它们。 4 | 5 | ##### 一、分组 6 | 分组将类似性质的警报分类为单个通知。 在许多系统一次性失败并且数百到数千个警报可能同时发生的较大中断期间，这尤其有用。 7 | 8 | 示例：发生网络分区时，群集中正在运行数十或数百个服务实例。 一半的服务实例无法再访问数据库。 Prometheus中的警报规则配置为在每个服务实例无法与数据库通信时发送警报。 结果，数百个警报被发送到Alertmanager。 9 | 10 | 作为用户，人们只想获得单个页面，同时仍能够确切地看到哪些服务实例受到影响。 因此，可以将Alertmanager配置为按群集和alertname对警报进行分组，以便发送单个紧凑通知。 11 | 12 | 通过配置文件中的路由树配置警报的分组，分组通知的定时以及这些通知的接收器。 13 | 14 | ##### 二、抑制 15 | 如果某些其他警报已经触发，则抑制是抑制某些警报的通知的概念。 16 | 17 | 示例：正在触发警报，通知无法访问整个集群。 Alertmanager可以配置为在该特定警报触发时将与该集群有关的所有其他警报静音。 这可以防止发送与实际问题无关的数百或数千个触发警报。 18 | 19 | 通过Alertmanager的配置文件配置禁止。 20 | 21 | ##### 三、静默 22 | 沉默是在给定时间内简单地静音警报的简单方法。 基于匹配器配置静默，就像路由树一样。 检查传入警报它们是否匹配活动静默的所有相等或正则表达式匹配器。 如果他们这样做，则不会发送该警报的通知。 23 | 24 | 在Alertmanager的Web界面中配置了静音。 25 | 26 | ##### 四、客户端行为 27 | Alertmanager对其客户的行为有[特殊要求](https://prometheus.io/docs/alerting/clients/)。 这些仅适用于不使用Prometheus发送警报的高级用例。 28 | 29 | ##### 五、高可用 30 | Alertmanager支持配置以创建用于高可用性的集群。 这可以使用--[-*cluster-*](https://github.com/prometheus/alertmanager#high-availability)标志进行配置。 31 | 32 | 重要的是不要在Prometheus和它的Alertmanagers之间加载平衡流量，而是将Prometheus指向所有Alertmanagers的列表。 33 | -------------------------------------------------------------------------------- /alerting/Clients.md: -------------------------------------------------------------------------------- 1 | 免责声明：Prometheus会自动处理由其配置的警报规则生成的警报。 强烈建议根据时间序列数据在Prometheus中配置警报规则，而不是实现直接客户端。 2 | 3 | Alertmanager在`/api/v1/alerts`上侦听API端点上的警报。 只要客户仍处于活动状态（通常为30秒至3分钟），客户就会不断重新发送警报。 客户端可以通过以下格式的POST请求将警报列表推送到该端点： 4 | ``` 5 | [ 6 | { 7 | "labels": { 8 | "alertname": "", 9 | "": "", 10 | ... 11 | }, 12 | "annotations": { 13 | "": "", 14 | }, 15 | "startsAt": "", 16 | "endsAt": "", 17 | "generatorURL": "" 18 | }, 19 | ... 20 | ] 21 | ``` 22 | 标签用于标识警报的相同实例并执行重复数据删除。 注释始终设置为最近收到的注释，而不是识别警报。 23 | 24 | 两个时间戳都是可选的。 如果省略`startsAt`，则当前时间由Alertmanager分配。 endsAt仅在已知警报结束时间时设置。 否则，它将设置为自上次收到警报以来的可配置超时时间。 25 | 26 | `generatorURL`字段是唯一的反向链接，用于标识客户端中此警报的生成实体。 27 | -------------------------------------------------------------------------------- /alerting/Notification_template_example.md: -------------------------------------------------------------------------------- 1 | 以下是警报和相应的Alertmanager配置文件设置（alertmanager.yml）的所有不同示例。 每个都使用Go模板系统。 2 | 3 | ##### 一、自定义Slack通知 4 | 在这个例子中，我们定制了Slack通知，以便向我们组织的wiki发送一个URL，告知如何处理已发送的特定警报。 5 | ``` 6 | global: 7 | slack_api_url: '' 8 | 9 | route: 10 | receiver: 'slack-notifications' 11 | group_by: [alertname, datacenter, app] 12 | 13 | receivers: 14 | - name: 'slack-notifications' 15 | slack_configs: 16 | - channel: '#alerts' 17 | text: 'https://internal.myorg.net/wiki/alerts/{{ .GroupLabels.app }}/{{ .GroupLabels.alertname }}' 18 | ``` 19 | 20 | ##### 二、访问CommonAnnotations中的注释 21 | 在这个例子中，我们再次定制发送给Slack接收器的文本，访问存储在Alertmanager发送的数据的`CommonAnnotations`中的摘要和描述。 22 | 23 | 警报 24 | ``` 25 | groups: 26 | - name: Instances 27 | rules: 28 | - alert: InstanceDown 29 | expr: up == 0 30 | for: 5m 31 | labels: 32 | severity: page 33 | # Prometheus templates apply here in the annotation and label fields of the alert. 34 | annotations: 35 | description: '{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.' 36 | summary: 'Instance {{ $labels.instance }} down' 37 | ``` 38 | 接收器 39 | ``` 40 | - name: 'team-x' 41 | slack_configs: 42 | - channel: '#alerts' 43 | # Alertmanager templates apply here. 44 | text: " \nsummary: {{ .CommonAnnotations.summary }}\ndescription: {{ .CommonAnnotations.description }}" 45 | ``` 46 | 47 | ##### 三、范围内所有收到的警报 48 | 最后，假设与前一个示例相同的警报，我们定制我们的接收器以覆盖从Alertmanager接收的所有警报，在新线路上打印它们各自的注释摘要和描述。 49 | 50 | 接收器 51 | ``` 52 | - name: 'default-receiver' 53 | slack_configs: 54 | - channel: '#alerts' 55 | title: "{{ range .Alerts }}{{ .Annotations.summary }}\n{{ end }}" 56 | text: "{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}" 57 | ``` 58 | 59 | ##### 四、定义可重用模板 60 | 回到我们的第一个例子，我们还可以提供一个包含命名模板的文件，然后由Alertmanager加载，以避免跨越多行的复杂模板。 在`/alertmanager/template/myorg.tmpl`下创建一个文件，并在其中创建一个名为“slack.myorg.txt”的模板： 61 | ``` 62 | {{ define "slack.myorg.text" }}https://internal.myorg.net/wiki/alerts/{{ .GroupLabels.app }}/{{ .GroupLabels.alertname }}{{ end}} 63 | ``` 64 | 配置现在加载具有“text”字段的给定名称的模板，并提供自定义模板文件的路径： 65 | ``` 66 | global: 67 | slack_api_url: '' 68 | 69 | route: 70 | receiver: 'slack-notifications' 71 | group_by: [alertname, datacenter, app] 72 | 73 | receivers: 74 | - name: 'slack-notifications' 75 | slack_configs: 76 | - channel: '#alerts' 77 | text: '{{ template "slack.myorg.text" . }}' 78 | 79 | templates: 80 | - '/etc/alertmanager/templates/myorg.tmpl' 81 | ``` 82 | 此[博客文章](https://prometheus.io/blog/2016/03/03/custom-alertmanager-templates/)中进一步详细说明了此示例。 83 | 84 | -------------------------------------------------------------------------------- /alerting/Notification_template_reference.md: -------------------------------------------------------------------------------- 1 | Prometheus创建并向Alertmanager发送警报，然后Alertmanager根据标签向不同的接收者发送通知。 接收器可以是众多集成中的一种，包括：Slack，PagerDuty，电子邮件或通过通用webhook接口的自定义集成。 2 | 3 | 发送给接收者的通知是通过模板构建的。 Alertmanager附带默认模板，但也可以自定义。 为避免混淆，请务必注意Alertmanager模板与Prometheus中的模板不同，但Prometheus模板还包括警报规则标签/注释中的模板。 4 | 5 | Alertmanager的通知模板基于Go模板系统。 请注意，某些字段将作为文本进行评估，而其他字段将作为HTML进行评估，这将影响转义。 6 | 7 | ##### 一、数据 8 | `Data`是传递给通知模板和webhook推送的结构。 9 | 10 | Name | Type| Notes 11 | ---|---|--- 12 | Receiver| string |定义通知将被发送到的接收者名称（松弛，电子邮件等）。 13 | Status |string| 如果至少有一个警报被触发，则定义为触发，否则解析。 14 | Alerts |Alert| 警报对象列表（见下文）。 15 | GroupLabels |KV |这些警报的标签按分组。 16 | CommonLabels| KV |所有警报共有的标签。 17 | CommonAnnotations| KV |所有警报的常用注释集。 用于有关警报的更长的其他信息串。 18 | ExternalURL |string|反向链接到发送通知的Alertmanager。 19 | 20 | ##### 二、警报 21 | `Alert`为通知模板保留一个警报。 22 | 23 | Name| Type| Notes 24 | ---|---|--- 25 | Status | string | 定义警报是已解决还是当前正在触发。 26 | Labels | KV |要附加到警报的一组标签。 27 | Annotations |KV| 警报的一组注释。 28 | StartsAt| time.Time| 警报开始发射的时间。 如果省略，则当前时间由Alertmanager分配。 29 | EndsAt |time.Time |仅在已知警报结束时间时设置。 否则设置为自上次收到警报以来的可配置超时时间。 30 | GeneratorURL| string |一个反向链接，用于标识此警报的生成实体。 31 | 32 | ##### 三、KV 33 | `KV`是一组用于表示标签和注释的键/值字符串对。 34 | ``` 35 | type KV map[string]string 36 | ``` 37 | 包含两个注释的注释示例： 38 | ``` 39 | { 40 | summary: "alert summary", 41 | description: "alert description", 42 | } 43 | ``` 44 | 除了直接访问存储为KV的数据（标签和注释）之外，还有用于排序，删除和查看LabelSet的方法： 45 | 46 | KV方法 47 | 48 | Name| Arguments| Returns| Notes 49 | ---|---|---|--- 50 | SortedPairs |- |Pairs (list of key/value string pairs.)|返回键/值对的排序列表。 51 | Remove| []string| KV| 返回没有给定键的键/值映射的副本。 52 | Names| - |[]string| 返回LabelSet中标签名称的名称。 53 | Values| - |[]string| 返回LabelSet中的值列表。 54 | 55 | ##### 四、函数 56 | 请注意Go模板也提供的[默认函数](https://golang.org/pkg/text/template/#hdr-Functions)。 57 | 58 | Name |Arguments |Returns 59 | ---|---|--- 60 | title |string |strings.Title, 大写每个单词的第一个字符。 61 | toUpper |string| strings.ToUpper, 将所有字符转换为大写。 62 | toLower |string| strings.ToLower, 将所有字符转换为小写。 63 | match |pattern, string |Regexp.MatchString. 使用Regex匹配字符串。 64 | reReplaceAll| pattern, replacement, text| Regexp.ReplaceAllString Regexp替换，未经修复。 65 | join |sep string, s []string |strings.Join, 连接s的元素以创建单个字符串。 分隔符字符串sep放在结果字符串中的元素之间。 （注意：参数顺序已反转，以便在模板中更容易管道化。） 66 | safeHtml| text string| html/template.HTML, 将字符串标记为不需要自动转义的HTML。 67 | -------------------------------------------------------------------------------- /alerting/README.md: -------------------------------------------------------------------------------- 1 | 译文：https://prometheus.io/docs/alerting/overview/ 2 | -------------------------------------------------------------------------------- /best_practices/Alerting.md: -------------------------------------------------------------------------------- 1 | ## Alerting 2 | --- 3 | 我们建议您根据Rob Ewaschuk在Google上的观察，阅读我的[基于警报的哲学](https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/edit)。 4 | 5 | 总结：保持警报简单，警惕症状，有良好的控制台允许精确定位原因，并避免有页面无关。 6 | 7 | ### What to alert on 8 | 旨在通过警告与最终用户疼痛相关的症状而不是试图捕捉可能导致疼痛的所有可能方式来尽可能少地发出警报。 警报应链接到相关控制台，以便轻松找出哪个组件有故障。 9 | 10 | 允许松弛警报以适应小的昙花一现。 11 | 12 | #### 在线服务系统 13 | 14 | 通常警告高延迟和错误率尽可能高。 15 | 16 | 仅限于堆栈中某一点的延迟。 如果较低级别的组件比它应该慢，但整体用户延迟很好，那么就不需要分页。 17 | 18 | 有关错误率，请参阅用户可见错误页面。 如果堆栈中存在导致此类故障的错误，则无需单独对其进行分页。 但是，如果某些故障不是用户可见的，但在其他方面严重到需要人为参与（例如，您正在损失大量资金），请添加要发送的页面。 19 | 20 | 如果具有不同特征，则可能需要针对不同类型的请求的警报，或者低流量类型的请求中的问题将被高流量请求淹没。 21 | 22 | #### 离线处理 23 | 24 | 对于离线处理系统，关键指标是数据通过系统所需的时间，因此如果页面变得足够高以引起用户影响，那么页面就是如此。 25 | 26 | #### 批量工作 27 | 28 | 对于批处理作业，如果批处理作业最近没有成功，则页面是有意义的，这将导致用户可见的问题。 29 | 30 | 对于批处理作业的2次完整运行，这通常应该至少足够。 对于每4小时运行一小时的工作，10小时将是合理的阈值。 如果您无法承受单次运行失败，请更频繁地运行作业，因为单个故障不应该需要人为干预。 31 | 32 | #### 容量 33 | 34 | 虽然不是造成直接用户影响的问题，但是接近容量通常需要人为干预以避免在不久的将来中断。 35 | 36 | #### 元监控 37 | 38 | 重要的是要确信监控工作正常。 因此，请发出警报以确保Prometheus服务器，Alertmanagers，PushGateways和其他监控基础架构可用并正常运行。 39 | 40 | 与往常一样，如果可以提醒症状而不是原因，这有助于减少噪音。 例如，警报从PushGateway到Prometheus到Alertmanager再到电子邮件的黑盒测试比每个警报更好。 41 | 42 | 通过外部黑盒监控补充对Prometheus的白盒监控可以捕获原本不可见的问题，并且在内部系统完全失效的情况下也可以作为后备。 43 | -------------------------------------------------------------------------------- /best_practices/Consoles_and_dashboards.md: -------------------------------------------------------------------------------- 1 | ## 控制台和面板 consoles and dashboards 2 | --- 3 | 在仪表板上显示尽可能多的数据可能很诱人，尤其是当像普罗米修斯这样的系统能够提供如此丰富的应用程序检测时。这可能导致由于信息太多而无法穿透的控制台，即使系统中的专家也难以从中获取意义。 4 | 5 | 操作控制台不是试图表示您拥有的每个数据，而是考虑最可能的故障模式以及如何使用控制台来区分它们。利用您的服务结构。例如，如果在在线服务系统中有一大堆服务，则某些较低服务的延迟是典型问题。不是在单个大型仪表板上显示每个服务的信息，而是为每个服务构建单独的仪表板，其中包括与之交谈的每个服务的延迟和错误。然后，您可以从顶部开始，继续前进到有问题的服务。 6 | 7 | 我们发现以下指南非常有效： 8 | 9 | - 控制台上的图表不超过5个。 10 | - 每个图表上的图表（行）不超过5个。如果它是堆叠/面积图，你可以逃脱更多。 11 | - 使用提供的控制台模板示例时，请避免在右侧表中输入超过20-30个条目。 12 | 13 | 如果你发现自己超过了这些，那么降低不太重要的信息的可见性是有意义的，可能会将一些子系统拆分到新的控制台。例如，您可以绘制聚合而不是分解数据的图形，将其移动到右侧表格，甚至可以完全删除数据（如果它很少有用） - 您始终可以在表达式浏览器中查看它！ 14 | 15 | 最后，一组控制台很难为一个以上的主人提供服务。你想知道什么是oncall（什么是坏的？）往往与开发功能时你想要的有很多不同（有多少人遇到角落X？）。在这种情况下，两组独立的控制台可能是有用的。 16 | -------------------------------------------------------------------------------- /best_practices/Histograms_and_summaries.md: -------------------------------------------------------------------------------- 1 | ## histograms and summaries 2 | --- 3 | `Histograms and summaries`是更复杂的度量标准类型。 单个`Histogram`或`summary`不仅会创建大量时间序列，而且正确使用这些度量标准类型也更加困难。 本节帮助您为用例选择和配置适当的度量标准类型。 4 | 5 | ### 库支持 6 | 首先，检查库支持[histograms](https://prometheus.io/docs/concepts/metric_types/#histogram)和[summaries](https://prometheus.io/docs/concepts/metric_types/#summary)。 7 | 8 | 许多库仅仅支持`histograms`和`summary`的一种，或者仅仅以有限的方式支持`summaries`（缺乏分位数计算）。 9 | 10 | ### 观察次数和总和 11 | `Histograms and summaries`都是样本观察，通常是请求持续时间或响应大小。 它们跟踪观测数量和观测值之和，使您可以计算观测值的平均值。 请注意，观察的数量（在Prometheus中显示为带有`_count`后缀的时间序列）本质上是一个计`counter`（如上所述，它只会上升）。 只要没有负面观察，观察总和（显示为带有`_sum`后缀的时间序列）的行为就像一个`counter`。 显然，请求持续时间或响应大小永远不会消极。 但是，原则上，您可以使用`Histograms and summaries`来观察负值（例如摄氏温度）。 在这种情况下，观察的总和可能会下降，因此您不能再对它应用`rate()`。 12 | 13 | 要从名为`http_request_duration_seconds`的`Histograms and summaries`计算过去5分钟内的平均请求持续时间，请使用以下表达式： 14 | ``` 15 | rate(http_request_duration_seconds_sum[5m]) 16 | / 17 | rate(http_request_duration_seconds_count[5m]) 18 | ``` 19 | 20 | ### Apdex score 应用性能指数 21 | `Histograms`（但不是`summaries`）的直接使用是计算落入特定观察值桶的观察值。 22 | 23 | 您可能拥有SLA，可在300毫秒内为95％的请求提供服务。 在这种情况下，将`Histogram`配置为具有上限为0.3秒的存储桶。 然后，您可以直接表达300毫秒内提供的相对请求数量，如果值低于0.95，则可以轻松发出警报。 以下表达式按`job`计算最近5分钟内提供的请求。 使用名为`http_request_duration_seconds`的`Histograms`收集请求持续时间。 24 | ``` 25 | sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) by (job) 26 | / 27 | sum(rate(http_request_duration_seconds_count[5m])) by (job) 28 | ``` 29 | 30 | 您可以用类似的方式估算出著名的Apdex分数。 配置目标请求持续时间为上限的桶，以及容忍请求持续时间（通常为目标请求持续时间的4倍）的另一个桶作为上限。 示例：目标请求持续时间为300毫秒。 可容忍的请求持续时间为1.2秒。 以下表达式生成过去5分钟内每个`job`的Apdex分数： 31 | ``` 32 | ( 33 | sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) by (job) 34 | + 35 | sum(rate(http_request_duration_seconds_bucket{le="1.2"}[5m])) by (job) 36 | ) / 2 / sum(rate(http_request_duration_seconds_count[5m])) by (job) 37 | ``` 38 | 39 | 请注意，我们除以两个桶的总和。 原因是`Histograms`桶是累积的。 `le="0.3"`桶也包含在`le="1.2"`桶中; 将它除以2校正。 40 | 41 | 该计算与传统的Apdex分数不完全匹配，因为它包括计算的满意和可容忍部分中的误差。 42 | 43 | ### Quatiles分位数 44 | 您可以使用`Histograms and summaries`来计算所谓的φ-分位数，其中`0≤φ≤1`。-分位数是在N个观测值中按数量`φ* N`排序的观测值。 `φ`-分位数的示例：0.5分位数称为中值。 0.95分位数是第95百分位数。 45 | 46 | `Histograms and summaries`之间的本质区别在于`summaries`计算客户端的流式φ-分位数并直接暴露它们，而`histograms`显示分段观察计数，`histograms`桶的分位数计算在服务器端使用`histogram_quantile()`函数进行。 47 | 48 | 这两种方法有许多不同的含义： 49 | | | Histogram | summary | 50 | |-------------|:----------------------------:|--------------:| 51 | | 所需配置 | 在观察值的范围内挑选合适的桶 |选择所需的φ-分位数和滑动窗口。其他φ-分位数和滑动窗口不能销售计算 52 | | 客户端性能 | 观察是非常低成本的，因为它们仅仅只需要增加计数器值 | 由于流分位数计算，观察是高成本的。 53 | | 服务端性能 | 服务器必须计算分位数。如果临时计算需要花费太长时间（例如：在大型面板中），则可以使用规则记录。| 低服务端成本 54 | | 时间序列数（除`_sum`和`_count`系列除外）| 每个配置桶的一个时间序列 |每个配置分位数的时间序列 55 | | 分位数错误（详见下面） | 观察值的误差受到相关桶的宽度限制| φ的尺寸受限于可配置值 56 | | φ分位数和滑动时间窗的规范 | 带有Prometheus表达式的Ad-hoc | 预先由客户端配置 57 | | 聚合 | 带有Prometheus表达式的Ad-hoc | 一般不聚合 58 | 59 | 请注意表中最后一项的重要性。 让我们回到SLA，在300ms内提供95％的请求。 这次，您不希望显示在300毫秒内提供的请求的百分比，而是显示第95百分位数，即您为95％的请求提供服务的请求持续时间。 要做到这一点，您可以配置一个带有0.95分位数的总数和（例如）一个5分钟的衰减时间，或者在300ms标记周围配置几个桶的`Histogram`，例如： `{le="0.1"}`，`{le="0.2"}`，`{le="0.3"}`和`{le="0.45"}`。 如果您的服务使用多个实例进行复制，您将从每个实例中收集请求持续时间，然后您希望将所有内容聚合到整体的第95个百分位。 但是，从`summaries`中汇总预先计算的分位数很少有意义。 在这种特殊情况下，对分位数求平均值会产生统计上无意义的值。 60 | ``` 61 | avg(http_request_duration_seconds{quantile="0.95"}) // BAD! 62 | ``` 63 | 64 | 使用直方图，使用`histogram_quantile()`函数完全可以进行聚合。 65 | 66 | ``` 67 | histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) // GOOD. 68 | ``` 69 | 70 | 此外，如果您的SLA发生变化并且您现在想要绘制第90个百分点，或者您想要考虑最后10分钟而不是最后5分钟，您只需要调整上面的表达式而您不需要重新配置客户端。 71 | 72 | ### 分位数估计误差 73 | 计算客户端或服务器端的分位数。了解该估计的错误非常重要。 74 | 75 | 继续上面的`histograms`示例，假设您的通常请求持续时间几乎都非常接近220ms，或者换句话说，如果您可以绘制“真实”直方图，您会看到220ms处的非常尖锐的尖峰。在如上配置的Prometheus `histograms`度量中，几乎所有观测值以及因此第95百分位数将落入标记为`{le="0.3"}`的桶中，即桶从200ms到300ms。直方图实现保证真正的第95百分位数介于200ms和300ms之间。为了返回单个值（而不是间隔），它应用线性插值，在这种情况下产生295ms。计算出的分位数给你的印象是你已经接近打破SLA，但实际上，第95百分位数略高于220毫秒，与你的SLA相当舒适。 76 | 77 | 我们的思想实验的下一步：后端路由的更改会为所有请求持续时间添加固定的100毫秒。现在请求持续时间在320毫秒处急剧上升，几乎所有观测值都将从300毫秒降至450毫秒。计算出第95百分位数为442.5ms，但正确值接近320ms。虽然你只是SLA之外的一小部分，但计算出的第95个分位数看起来更糟糕。 78 | 79 | 在两种情况下，总结都没有问题计算正确的百分位数值，至少如果它在客户端使用适当的算法（就像Go客户端使用的算法）。遗憾的是，如果您需要汇总来自多个实例的观察结果，则无法使用总数。 80 | 81 | 幸运的是，由于您适当选择了桶边界，即使在这个设计的观测值分布非常尖锐的示例中，如果您在SLA内部或外部，直方图也能够正确识别。此外，分位数的实际值越接近我们的SLA（或换句话说，我们实际上最感兴趣的值），计算值变得越准确。 82 | 83 | 现在让我们再次修改实验。在新设置中，请求持续时间的分布具有150ms的峰值，但它不像以前那么尖锐，仅包含90％的观测值。 10％的观察结果均匀地分布在150ms到450ms之间的长尾中。通过该分布，第95百分位正好恰好在我们的300毫秒的SLA。使用直方图，计算出的值是准确的，因为第95百分位的值恰好与其中一个桶边界重合。即使稍微不同的值仍然是准确的，因为相关桶内的（人为的）均匀分布正是桶内的线性插值所假设的。 84 | 85 | `summaries`报告的分位数误差现在变得更加有趣。`summaries`中的分位数的误差在φ的维度中配置。在我们的例子中，我们可能已经配置了0.95±0.01，即计算值将在第94百分位和第96百分位之间。具有上述分布的第94个分位数是270ms，第96个分位数是330ms。摘要报告的第95百分位数的计算值可以是270毫秒到330毫秒之间的任何位置，不幸的是，在SLA中明显不同于SLA之外的所有区别。 86 | 87 | 底线是：如果使用`summaries`，则控制φ维度中的误差。如果使用直方图，则可以控制观察值维度中的误差（通过选择适当的铲斗布局）。由于分布广泛，φ的微小变化导致观察值的偏差很大。通过明显的分布，观察值的小间隔覆盖了大的φ间隔。 88 | 89 | 两个经验法则： 90 | - 如果需要聚合，请选择`histograms`。 91 | - 否则，如果您了解要观察的值的范围和分布，请选择`histgorams`。 如果您需要准确的分位数，无论值的范围和分布如何，请选择`summarirs`。 92 | 93 | ### 如果我的客户端库不支持我需要的指标类型，该怎么办 94 | 实施它！ [代码贡献](https://prometheus.io/community/)是受欢迎的。 一般来说，我们希望直方图比总数更迫切需要。 直方图也更容易在客户端库中实现，因此我们建议首先实现直方图，如果有疑问的话。 95 | -------------------------------------------------------------------------------- /best_practices/Instrumentation.md: -------------------------------------------------------------------------------- 1 | ## instrumentation 2 | --- 3 | 此页面提供了一套固定的指导方针，用于检测代码。 4 | 5 | ### How to instrument 6 | 简短的回答是衡量一切。 每个库，子系统和服务都应至少有一些指标，以便您大致了解它的执行情况。 7 | 8 | 仪器应该是代码中不可或缺的一部分。 在您使用它们的同一文件中实例化度量标准类。 当您追踪错误时，这使得从警报到控制台变得容易编码。 9 | 10 | ### 三种类型服务 11 | 出于监控目的，服务通常可以分为三种类型：在线服务，离线处理和批处理作业。 它们之间存在重叠，但每种服务都倾向于适合这些类别之一。 12 | 13 | #### 在线服务系统 14 | 在线服务系统是人或其他系统期望立即响应的系统。 例如，大多数数据库和HTTP请求属于此类别。 15 | 16 | 此类系统中的关键指标是执行的查询数，错误数和延迟。 正在进行的请求数量也很有用。 17 | 18 | 有关计算失败的查询，请参阅下面的“失败”部分 19 | 20 | 应在客户端和服务器端监视在线服务系统。 如果双方看到不同的行为，那么这是非常有用的调试信息。 如果服务有很多客户端，那么服务单独跟踪它们也是不切实际的，所以他们必须依赖自己的统计数据。 21 | 22 | 在查询开始时或结束时是否计算是一致的。 当它们结束时建议，因为它将与错误和延迟统计对齐，并且往往更容易编码。 23 | 24 | #### 线下处理 25 | 对于离线处理，没有人正在积极等待响应，并且批量工作很常见。 可能还有多个处理阶段。 26 | 27 | 对于每个阶段，跟踪进入的项目，正在进行的项目，上次处理的项目以及发送的项目数量。 如果批处理，您还应该跟踪进出的批次。 28 | 29 | 知道系统最后一次处理某些东西对于检测它是否已经停止是有用的，但它是非常本地化的信息。 更好的方法是通过系统发送心跳：一些虚拟项目一直通过并包含插入时的时间戳。 每个阶段都可以导出它看到的最新心跳时间戳，让您知道项目在系统中传播的时间。 对于没有静默期且未进行处理的系统，可能不需要显式心跳。 30 | 31 | #### 批量任务 32 | 离线处理和批处理作业之间存在模糊界限，因为离线处理可以在批处理作业中完成。批处理作业的特征在于它们不会连续运行，这使得难以进行拼写。 33 | 34 | 批处理作业的关键指标是最后一次成功。跟踪作业的每个主要阶段所花费的时间，总体运行时间以及作业完成的最后时间（成功或失败）也很有用。这些都是仪表，应该推到[PushGateway](https://prometheus.io/docs/instrumenting/pushing/)。通常还有一些特定于工作的整体统计数据可用于跟踪，例如处理的记录总数。 35 | 36 | 对于运行时间超过几分钟的批处理作业，使用基于拉式的监控来抓取它们也很有用。这使您可以跟踪与其他类型的作业相同的度量标准，例如与其他系统通信时的资源使用和延迟。如果作业开始变慢，这可以帮助调试。 37 | 38 | 对于经常运行的批处理作业（例如，通常比每15分钟更多），您应该考虑将它们转换为守护程序并将它们作为脱机处理作业处理。 39 | 40 | #### 子系统 41 | 除了三种主要类型的服务之外，系统还有应该监控的子部分。 42 | 43 | #### Libraries库 44 | 库应该提供检测，而不需要用户进行其他配置。 45 | 46 | 如果它是用于访问进程外部某些资源的库（例如，网络，磁盘或IPC），则跟踪整体查询计数，错误（如果可能存在错误）和延迟至少。 47 | 48 | 根据库的重量，跟踪库本身内部的错误和延迟，以及您认为可能有用的任何常规统计信息。 49 | 50 | 应用程序的多个独立部分可以针对不同的资源使用库，因此在适当的情况下注意区分用途和标签。 例如，数据库连接池应该区分它正在与之通信的数据库，而不需要区分DNS客户端库的用户。 51 | 52 | #### 日志 53 | 作为一般规则，对于每行日志记录代码，您还应该有一个递增的计数器。 如果您发现有趣的日志消息，您希望能够查看它发生的频率和持续时间。 54 | 55 | 如果在同一个函数中存在多个密切相关的日志消息（例如，if或switch语句的不同分支），则有时可以为所有这些消息增加一个计数器。 56 | 57 | 导出整个应用程序记录的信息/错误/警告行总数通常也很有用，并在发布过程中检查重大差异。 58 | 59 | #### 失败 60 | 应该像记录一样处理故障。 每次出现故障时，都应增加计数器。 与日志记录不同，根据代码的结构，错误也可能会冒泡到更通用的错误计数器。 61 | 62 | 报告失败时，通常应该有一些其他指标代表总尝试次数。 这使得故障率易于计算。 63 | 64 | #### 线程池 TreadPools 65 | 对于任何类型的线程池，关键指标是排队请求的数量，正在使用的线程数，线程总数，处理的任务数以及它们花费的时间。 跟踪队列中等待的时间也很有用。 66 | 67 | #### Caches缓存 68 | 缓存的关键指标是总查询，命中，总体延迟，然后是缓存所在的任何在线服务系统的查询计数，错误和延迟。 69 | 70 | #### Collectors收集器 71 | 72 | 在实现一个非平凡的自定义指标收集器时，建议导出一个指标，表示收集在几秒钟内所花费的时间以及另一个收集的错误数量。 73 | 74 | 这是可以将持续时间导出为量表而不是汇总或直方图的两种情况之一，另一种是批量作业持续时间。 这是因为两者都代表关于特定`push/scrape`的信息，而不是随时间跟踪多个持续时间。 75 | 76 | ### 关注的事情 77 | 在进行监控时，还有一些需要注意的事项，特别是Prometheus特定的事项。 78 | 79 | #### 使用标签 80 | 很少有监控系统具有标签和表达语言的概念来利用它们，因此需要一些习惯。 81 | 82 | 当你有想要的add/average/sum的多个度量指标时，它们通常应该是一个包含标签而非多个指标的指标。 83 | 84 | 例如，不是`http_responses_500_total`和`http_responses_403_total`，而是创建一个名为`http_responses_total`的度量标准，其中包含HTTP响应代码的代码标签。 然后，您可以将整个指标作为规则和图形中的一个处理。 85 | 86 | 根据经验，度量名称的任何部分都不应该在程序上生成（而是使用标签）。 一个例外是从另一个监视/检测系统代理度量。 87 | 88 | 另请参阅[命名](https://prometheus.io/docs/practices/naming/)部分。 89 | 90 | #### 不要过度使用标签 91 | 每个标签集都是一个额外的时间序列，具有RAM，CPU，磁盘和网络成本。通常开销可以忽略不计，但在具有大量指标和数百个服务器上的数百个标签集的情况下，这可以快速增加。 92 | 93 | 作为一般准则，请尽量将指标的基数保持在10以下，对于超过该指标的指标，我们的目标是将其限制在整个系统中。绝大多数指标都没有标签。 94 | 95 | 如果您有一个基数超过100的指标或可能增长的指标，请研究其他解决方案，例如减少维数或将分析从监控转移到通用处理系统。 96 | 97 | 为了让您更好地了解底层数字，让我们看一下node_exporter。 node_exporter公开每个已安装文件系统的度量标准。每个节点都有几十个时间序列，例如`node_filesystem_avail`。如果你有10,000个节点，你最终会得到大约100,000个`node_filesystem_avail`的时间序列，这对Prometheus来说很好。 98 | 99 | 如果您现在要为每个用户添加配额，您将很快达到10,000个节点上10,000个用户的两位数百万。这对Prometheus目前的实施来说太过分了。即使数量较少，也存在机会成本，因为您无法在此计算机上拥有其他可能更有用的指标。 100 | 101 | 如果您不确定，请在没有标签的情况下开始，并随着具体使用情况的出现添加更多标签。 102 | 103 | #### Counter vs. gauge, summary vs. histogram 104 | 了解用于给定度量的四种主要度量标准类型中的哪一种非常重要。 105 | 106 | 要在`counter`和`gauge`之间进行选择，有一个简单的经验法则：如果值可以下降，那么它就是一个`gauge`。 107 | 108 | `counter`只能上升（并重置，例如进程重启时）。 它们可用于累积事件数量或每个事件的数量。 例如，HTTP请求的总数，或HTTP请求中发送的总字节数。 原始计数器很少有用。 使用`rate()`函数可以获得它们增加的每秒速率。 109 | 110 | `gauge`可以设置，上升和下降。 它们对状态快照很有用，例如正在进行的请求，空闲/总内存或温度。 你永远不应该拿一个表的`rate()`。 111 | 112 | `Summary`和`histogram`是他们[自己部分](https://prometheus.io/docs/practices/histograms/)讨论的更复杂的度量类型。 113 | 114 | #### 时间戳Timestamps, not time since 115 | 如果你想跟踪事件发生的时间，可以导出它发生的Unix时间戳 - 而不是它发生的时间。 116 | 117 | 通过导出时间戳，您可以使用表达式`time() - my_timestamp_metric`来计算自事件以来的时间，无需更新逻辑并保护您免受更新逻辑卡住。 118 | 119 | #### 内部循环 Inner loops 120 | 121 | 一般而言，仪器的额外资源成本远远超过它为运营和开发带来的好处。 122 | 123 | 对于性能至关重要的代码或在给定进程内每秒调用超过100k次的代码，您可能希望关注更新的指标数量。 124 | 125 | `Java counte`r需要12-17ns才能增加，具体取决于竞争条件。 其他语言也会有类似的表现。 如果内部循环的时间量很重要，请限制在内部循环中增加的度量标准数量并尽可能避免使用标签（或者缓存标签查找的结果，例如，`Go`中的`With()`返回值或者`Java`中的`labels()`）。 126 | 127 | 还要注意涉及时间或持续时间的度量标准更新，因为获取时间可能涉及系统调用。 与涉及性能关键代码的所有事项一样，基准测试是确定任何给定代码影响的最佳方法 128 | 129 | #### 避免丢失的度量指标 130 | 在事情发生之前不存在的时间序列很难处理，因为通常的简单操作不再足以正确处理它们。 为了避免这种情况，对于您可能事先知道的任何时间序列，导出`0`（或`NaN`，如果`0`会产生误导）。 131 | 132 | 大多数Prometheus客户端库（包括`Go`，`Java`和`Python`）将自动为您导出`0`以获取没有标签的指标。 133 | -------------------------------------------------------------------------------- /best_practices/Metric_and_label_naming.md: -------------------------------------------------------------------------------- 1 | ## 度量指标和标签命名 2 | --- 3 | 使用Prometheus不需要本文档中提供的度量标准和标签约定，但可以同时用作样式指南和最佳实践集合。 个别组织可能希望采用其中一些做法，例如： 命名约定，不同。 4 | 5 | ### 指标名字 6 | 指标名称...... 7 | 8 | - ... 必须符合有效字符的[数据模型](https://prometheus.io/docs/concepts/data_model/#metric-names-and-labels)。 9 | - ... 应该具有与度量所属的域相关的（单字）应用程序前缀。前缀有时被客户端库称为命名空间。对于特定于应用程序的度量标准，前缀通常是应用程序名称本身。但是，有时候，指标更通用，就像客户端库导出的标准化指标一样。例子： 10 | - `prometheus_notifications_total`(特定于Prometheus服务) 11 | - `process_cpu_seconds_total`(由许多客户库导出) 12 | - `http_request_duration_seconds`(适用于所有HTTP请求) 13 | - ...必须有一个单位（即不要与毫秒混合秒，或与字节混合秒）. 14 | - ...应该有一个基本单位（例如：秒，字节，米，不是毫秒，兆字节，公里）。请参阅下面的基本单位列表。 15 | - ...应该有一个以复数形式描述单位的后缀。请注意，累积计数除了单位（如果适用）外，还有总数作为后缀。 16 | - `http_request_request_seconds` 17 | - `node_memory_usage_bytes` 18 | - `http_requests_total`(对于无单位累计计数) 19 | - `process_cpu_seconds_total`(用于累计计数单位) 20 | - ...应该代表所有标签尺寸上相同的逻辑事物 21 | - 请求持续时间 22 | - 数据传输的字节数 23 | - 瞬时资源使用率百分比 24 | 25 | 根据经验，给定度量的所有维度上的`sum()`或`avg()`应该是有意义的（尽管不一定有用）。如果没有意义，请将数据拆分为多个指标。例如，在一个度量中具有各种队列的容量是好的，而将队列的容量与队列中的当前数量的元素混合则不是。 26 | 27 | ### 标签 28 | 使用标签来区分正在测量的事物特征： 29 | 30 | - `api_http_requests_total`- 区分请求类型： `type="created| update | delete`. 31 | - `api_request_duration_seconds`- 区分请求阶段：`stage="extract | transform | load"` 32 | 33 | 不要将标签名称放在度量标准名称中，因为这会引入冗余，如果聚合了相应的标签，则会引起混淆。 34 | 35 | ### 基本单位 36 | Prometheus没有硬编码的任何单位。 为了更好的兼容性，应使用基本单元。 以下列出了一些具有基本单位的度量标准系列。 该清单并非详尽无遗。 37 | 38 | |Family|基本单位 | 备注| 39 | |---|---|---| 40 | | Time | seconds | | 41 | | Temperature | celsius | 摄氏度是实践中遇到的最常见的摄氏度 | 42 | | Length | meters | | 43 | | Bytes | bytes | | 44 | | Bits | bytes | | 45 | | Percent | ratio(*) | 值为0-1。`*`）通常'ratio'不用作后缀，而是用作A_per_B。 例外是例如disk_usage_ratio | 46 | | Voltage | volts | | 47 | | Electric current | amperes | | 48 | | Energy | joules | | 49 | | Mass | grams | 为了避免千字节前缀的问题，克优于千克。 | 50 | -------------------------------------------------------------------------------- /best_practices/README.md: -------------------------------------------------------------------------------- 1 | 译文：https://prometheus.io/docs/practices/naming/ -------------------------------------------------------------------------------- /best_practices/Recording_rules.md: -------------------------------------------------------------------------------- 1 | ## RECORDING RULES 2 | --- 3 | 用于[记录规则](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/)的一致命名方案使得更容易一目了然地解释规则的含义。 它还通过使错误或无意义的计算脱颖而出来避免错误。 4 | 5 | 本页介绍了如何正确进行聚合并建议命名约定。 6 | 7 | ### 命名和聚合 8 | 录制规则应具有一般形式`level:metric:operations`。 `level`表示聚合级别和规则输出的标签。` metric`是度量标准名称，除了在使用`rate()`或`irate()`时剥离`_total` off计数器之外，应该保持不变。 operations是首先应用于度量标准，最新操作的操作列表。 9 | 10 | 保持度量标准名称不变可以很容易地知道度量标准是什么，并且很容易在代码库中找到。 11 | 12 | 为了保持操作干净，如果有其他操作，则省略`_sum`，如`sum()`。可以合并关联操作（例如，`min_min`与`min`相同）。 13 | 14 | 如果没有明显的操作要使用，请使用`sum`。通过划分获取比率时，使用`_per_`分隔指标并调用操作`rate`。 15 | 16 | 在汇总比率时，分别汇总分子和分母然后除。不要取平均值的平均值或平均值，因为这在统计上无效。 17 | 18 | 当汇总摘要的`_count`和`_sum`并除以计算平均观察大小时，将其视为比率将是笨重的。而是保持度量标准名称不带`_count`或`_sum`后缀，并将操作中的`rate`替换为`mean`。这表示该时间段内的平均观察大小。 19 | 20 | 始终使用要聚合的标签指定`without`子句。这是为了保留所有其他标签，例如`job`，这将避免冲突并为您提供更有用的指标和警报。 21 | 22 | ### 例子 23 | 聚合每秒请求的label标签： 24 | ``` 25 | instance_path:requests:rate5m = 26 | rate(requests_total{job="myjob"}[5m]) 27 | 28 | path:requests:rate5m = 29 | sum without (instance)(instance_path:requests:rate5m{job="myjob"}) 30 | ``` 31 | 32 | 计算请求失败率并聚合到作业级失败率： 33 | ``` 34 | instance_path:request_failures:rate5m = 35 | rate(request_failures_total{job="myjob"}[5m]) 36 | 37 | instance_path:request_failures_per_requests:ratio_rate5m = 38 | instance_path:request_failures:rate5m{job="myjob"} 39 | / 40 | instance_path:requests:rate5m{job="myjob"} 41 | 42 | // Aggregate up numerator and denominator, then divide to get path-level ratio. 43 | path:request_failures_per_requests:ratio_rate5m = 44 | sum without (instance)(instance_path:request_failures:rate5m{job="myjob"}) 45 | / 46 | sum without (instance)(instance_path:requests:rate5m{job="myjob"}) 47 | 48 | // No labels left from instrumentation or distinguishing instances, 49 | // so we use 'job' as the level. 50 | job:request_failures_per_requests:ratio_rate5m = 51 | sum without (instance, path)(instance_path:request_failures:rate5m{job="myjob"}) 52 | / 53 | sum without (instance, path)(instance_path:requests:rate5m{job="myjob"}) 54 | ``` 55 | 56 | 从一个摘要计算一段时间内的平均延迟： 57 | ``` 58 | instance_path:request_latency_seconds_count:rate5m = 59 | rate(request_latency_seconds_count{job="myjob"}[5m]) 60 | 61 | instance_path:request_latency_seconds_sum:rate5m = 62 | rate(request_latency_seconds_sum{job="myjob"}[5m]) 63 | 64 | instance_path:request_latency_seconds:mean5m = 65 | instance_path:request_latency_seconds_sum:rate5m{job="myjob"} 66 | / 67 | instance_path:request_latency_seconds_count:rate5m{job="myjob"} 68 | 69 | // Aggregate up numerator and denominator, then divide. 70 | path:request_latency_seconds:mean5m = 71 | sum without (instance)(instance_path:request_latency_seconds_sum:rate5m{job="myjob"}) 72 | / 73 | sum without (instance)(instance_path:request_latency_seconds_count:rate5m{job="myjob"}) 74 | ``` 75 | 76 | 在实例和路径之间计算平均查询速率是使用`avg()`函数完成的： 77 | ``` 78 | job:request_latency_seconds_count:avg_rate5m = 79 | avg without (instance, path)(instance:request_latency_seconds_count:rate5m{job="myjob"}) 80 | ``` 81 | 82 | 请注意，在聚合时，与输入度量标准名称相比，将从输出度量标准名称的级别中删除`without`子句中的标签。 如果没有聚合，则级别始终匹配。 如果不是这种情况，则规则中可能存在错误。 83 | -------------------------------------------------------------------------------- /best_practices/When_to_use_the_pushgateway.md: -------------------------------------------------------------------------------- 1 | ## WHEN TO USE THE PUSHGATEWAY 2 | --- 3 | Pushgateway是一个中介服务，允许您从不能被刮除的作业推出指标。 有关详细信息，请参阅[推送指标](https://prometheus.io/docs/instrumenting/pushing/)。 4 | 5 | ### 我应该用Pushgateway吗？ 6 | 我们只建议在某些有限的情况下使用Pushgateway。 盲目使用Pushgateway代替Prometheus通常的拉动模型进行一般指标收集时，有几个陷阱： 7 | - 通过单个Pushgateway监控多个实例时，Pushgateway成为单点故障和潜在瓶颈。 8 | - 您通过up metric（在每次抓取时生成）丢失了Prometheus的自动实例运行状况监视。 9 | - Pushgateway永远不会忘记推送到它的系列，并将永远暴露给Prometheus，除非这些系列是通过Pushgateway的API手动删除的。 10 | 当作业的多个实例通过实例标签或类似物区分其在Pushgateway中的度量时，后一点尤其重要。即使重命名或删除了原始实例，实例的度量标准仍将保留在Pushgateway中。这是因为Pushgateway作为指标缓存的生命周期基本上与将指标推送到它的流程的生命周期分开。将此与普罗米修斯通常的拉式监控进行对比：当实例消失（有意或无意）时，其指标会随之自动消失。使用Pushgateway时，情况并非如此，您现在必须手动删除任何过时的指标或自行自动执行此生命周期同步。 11 | 12 | 通常，Pushgateway唯一有效的用例是捕获服务级批处理作业的结果。 “服务级”批处理作业是与特定计算机或作业实例在语义上无关的作业（例如，删除整个服务的多个用户的批处理作业）。此类作业的度量标准不应包含计算机或实例标签，以将特定计算机或实例的生命周期与推送的度量标准分离。这减少了管理Pushgateway中过时指标的负担。另请参阅[监视批处理作业的最佳实践](https://prometheus.io/docs/practices/instrumentation/#batch-jobs) 13 | 14 | ### 替代策略 15 | 如果入站防火墙或NAT阻止您从目标中提取指标，请考虑将Prometheus服务器也移到网络屏障后面。 我们通常建议在与受监控实例相同的网络上运行Prometheus服务器。 16 | 17 | 对于与计算机相关的批处理作业（例如自动安全更新cronjobs或配置管理客户端运行），使用[Node exporter](https://github.com/prometheus/node_exporter)的文本文件模块而不是Pushgateway公开生成的指标。 18 | -------------------------------------------------------------------------------- /concepts/Data_model.md: -------------------------------------------------------------------------------- 1 | Prometheus从根本上存储的所有数据都是[时间序列](http://en.wikipedia.org/wiki/Time_series): 具有时间戳的数据流只属于单个度量指标和该度量指标下的多个标签维度。除了存储时间序列数据外，Prometheus还可以生成临时派生的时间序列作为查询的结果。 2 | 3 | ##### 一、指标名称和标签 4 | 每一个时间序列数据由`metric`度量指标名称和它的标签`labels`键值对集合唯一确定。 5 | 6 | 这个`metric`度量指标名称指定监控目标系统的测量特征（如：`http_requests_total`- 接收http请求的总计数）。 `metric`度量指标可能包含ASCII字母、数字、下划线和冒号，他必须配正则表达式`[a-zA-Z_:][a-zA-Z0-9_:]*` 7 | 。 8 | 9 | 注意：冒号保留用于用户定义的记录规则。 它们不应被`exporter`或直接仪表使用。 10 | 11 | `labels`开启了Prometheus的多维数据模型：对于相同的度量名称，通过不同标签列表的结合, 会形成特定的度量维度实例。(例如：所有包含度量名称为`/api/tracks`的http请求，打上`method=POST`的标签，则形成了具体的http请求)。这个查询语言在这些度量和标签列表的基础上进行过滤和聚合。改变任何度量上的任何标签值，则会形成新的时间序列。 12 | 13 | 标签名称可以包含ASCII字母、数字和下划线。它们必须匹配正则表达式`[a-zA-Z_][a-zA-Z0-9_]*`。带有`_`下划线的标签名称被保留内部使用。 14 | 15 | 标签值包含任意的Unicode码。 16 | 17 | 具体详见[metrics和labels命名最佳实践](https://prometheus.io/docs/practices/naming/)。 18 | 19 | ##### 二、样本 20 | 样本形成了实际的时间序列数据列表。每个采样值包括： 21 | - 一个`float64`类型的值 22 | - 一个精确到毫秒级的时间戳 23 | 24 | ##### 三、符号 25 | 表示一个度量指标和一组键值对标签，需要使用以下符号： 26 | > [metric name]{[label name]=[label value], ...} 27 | 28 | 例如，度量指标名称是`api_http_requests_total`， 标签为`method="POST"`, `handler="/messages"` 的示例如下所示： 29 | > api_http_requests_total{method="POST", handler="/messages"} 30 | 31 | 这些命名和OpenTSDB使用方法是一样的。 32 | -------------------------------------------------------------------------------- /concepts/Jobs_and_instances.md: -------------------------------------------------------------------------------- 1 | 就Prometheus而言，`pull`拉取采样点的端点服务称之为**instance**，通常对应一个过程（实例）。具有相同目的的**instance**，例如，为可伸缩性或可靠性而复制的流程称为`job`。, 则构成了一个**job** 2 | 3 | 例如, 一个被称作**api-server**的`job`有四个相同的`instance`。 4 | - job: `api-server` 5 | - instance 1：`1.2.3.4:5670` 6 | - instance 2：`1.2.3.4:5671` 7 | - instance 3：`5.6.7.8:5670` 8 | - instance 4：`5.6.7.8:5671` 9 | 10 | ##### 一、自动化生成的标签和时间序列 11 | 当Prometheus拉取一个目标，会自动地把两个标签添加到度量名称的标签列表中，分别是： 12 | - **job**: 目标所属的配置任务名称。 13 | - **instance**: 被抓取的目标网址的一部分务: `host:port` 14 | 15 | 如果以上两个标签二者之一存在于采样点中，这个取决于`honor_labels`配置选项。详见[文档](https://prometheus.io/docs/operating/configuration/#%3Cscrape_config%3E) 16 | 17 | 对于每个采样点所在服务instance，Prometheus都会存储以下的度量指标采样点： 18 | - `up{job="[job-name]", instance="instance-id"}`:`1`，表示采样点所在服务健康;`0`，标识抓取失败 19 | - `scrape_duration_seconds{job="[job-name]", instance="[instance-id]"}`: 抓取的持续时间 20 | - `scrape_samples_post_metric_relabeling{job="", instance=""}`: 应用度量标准重新标记后剩余的样本数。 21 | - `scrape_samples_scraped{job="", instance=""}`: 目标暴露的样本数量。 22 | - `scrape_series_added{job="", instance=""}`: 此`scrape`中新系列的大概数量。 v2.10的新功能 23 | 24 | `up`度量指标对服务健康的监控是非常有用的。 25 | -------------------------------------------------------------------------------- /concepts/Metric_types.md: -------------------------------------------------------------------------------- 1 | Prometheus客户端库提供了四个核心的`metrics`类型。这四种类型目前仅在客户端库(启用针对特定类型使用量身定制的API)和`wire`协议中区分。Prometheus服务还没有充分利用这些类型。不久的将来就会发生改变。 2 | 3 | ##### 一、Counter 4 | *counter* 是表示单个[单调递增计数器](https://en.wikipedia.org/wiki/Monotonic_function)的累积度量，其值只能在重启时增加或重置为零。 例如，您可以使用`counter`来表示所服务的请求数，已完成的任务或错误。 5 | 6 | 不要使用`counter`来暴露可能减少的值。例如，不要使用`counter`来处理当前正在运行的进程数; 而是使用`gauge`。 7 | 8 | 客户端使用`counter`的文档： 9 | - [Go](http://godoc.org/github.com/prometheus/client_golang/prometheus#Counter) 10 | - [Java](https://github.com/prometheus/client_java/blob/master/simpleclient/src/main/java/io/prometheus/client/Counter.java) 11 | - [Python](https://github.com/prometheus/client_python#counter) 12 | - [Ruby](https://github.com/prometheus/client_ruby#counter) 13 | 14 | ##### 二、Gauge 15 | *gauge*是一个度量指标，它表示一个既可以递增, 又可以递减的值。 16 | 17 | `Gauge`通常用于测量值，如温度或当前内存使用情况，但也可用于可以上下的"计数"，例如并发请求的数量。 18 | 19 | 客户端使用`gauge`的文档： 20 | - [Go](http://godoc.org/github.com/prometheus/client_golang/prometheus#Gauge) 21 | - [Java](https://github.com/prometheus/client_java/blob/master/simpleclient/src/main/java/io/prometheus/client/Gauge.java) 22 | - [Python](https://github.com/prometheus/client_python#gauge) 23 | - [Ruby](https://github.com/prometheus/client_ruby#gauge) 24 | 25 | ##### 三、Histogram(柱状图) 26 | *histogram*，对观察结果进行采样（通常是请求持续时间或响应大小等），并将其计入可配置存储桶中。它还提供所有观察值的总和。 27 | 28 | 基本度量标准名称为``的直方图在scrape期间显示多个时间序列： 29 | 30 | - 暴露的观察桶的累积计数器：`_bucket{le=""}` 31 | - 所有观测值的总和：`_sum` 32 | - 已观察到的事件数：`_count`，和`_bucket{le="+Inf"}`相同 33 | 34 | 使用[`histogram_quantile()`](https://prometheus.io/docs/querying/functions/#histogram_quantile), 计算直方图或者是直方图聚合计算的分位数阈值。 `histogram`适合计算计算[Apdex值](http://en.wikipedia.org/wiki/Apdex), 当在`buckets`上操作时，记住`histogram`是累计的。详见[ histograms和summaries](https://prometheus.io/docs/practices/histograms) 35 | 36 | 客户库的`histogram`使用文档： 37 | - [Go](http://godoc.org/github.com/prometheus/client_golang/prometheus#Histogram) 38 | - [Java](https://github.com/prometheus/client_java/blob/master/simpleclient/src/main/java/io/prometheus/client/Histogram.java) 39 | - [Python](https://github.com/prometheus/client_python#histogram) 40 | - [Ruby](https://github.com/prometheus/client_ruby#histogram) 41 | 42 | ##### 四、Summary 43 | 类似*histogram*，*summary*是采样点分位图统计(通常是请求持续时间和响应大小等)。虽然它还提供观察的总数和所有观测值的总和，但它在滑动时间窗口上计算可配置的分位数。 44 | 45 | 基本度量标准名称``的`summary`在scrape期间公开了多个时间序列： 46 | - 流φ-quantiles (0 ≤ φ ≤ 1), 显示为`{quantiles="[φ]"}` 47 | - `_sum`， 是指所有观察值的总和 48 | - `_count`, 是指已观察到的事件计数值 49 | 50 | 有关`φ`-分位数，`Summary`用法和`histogram`图差异的详细说明，详见[histogram和summaries](https://prometheus.io/docs/practices/histograms) 51 | 52 | 有关`summaries`的客户端使用文档： 53 | 54 | - [Go](http://godoc.org/github.com/prometheus/client_golang/prometheus#Summary) 55 | - [Java](https://github.com/prometheus/client_java/blob/master/simpleclient/src/main/java/io/prometheus/client/Summary.java) 56 | - [Python](https://github.com/prometheus/client_python#summary) 57 | - [Ruby](https://github.com/prometheus/client_ruby#summary) 58 | -------------------------------------------------------------------------------- /concepts/README.md: -------------------------------------------------------------------------------- 1 | 译文：https://prometheus.io/docs/concepts/data_model/ 2 | -------------------------------------------------------------------------------- /guides/Basic_auth.md: -------------------------------------------------------------------------------- 1 | ## 使用基本知识保护PROMETHEUS API和UI端点 2 | --- 3 | Prometheus不直接支持与Prometheus表达式浏览器和HTTP API连接的[基本身份验证](https://en.wikipedia.org/wiki/Basic_access_authentication)（也称为“基本身份验证”）。 如果您要为这些连接强制执行基本身份验证，我们建议将Prometheus与反向代理结合使用，并在代理层应用身份验证。 您可以使用Prometheus的任何反向代理，但在本指南中我们将提供一个nginx示例。 4 | 5 | ### Nginx例子 6 | 假设你想在运行在`localhost：12321`上的nginx服务器后面运行一个Prometheus实例，并且所有Prometheus端点都可以通过`/prometheus`端点运行。 因此，Prometheus'`/metrics`端点的完整URL将是： 7 | ``` 8 | http://localhost:12321/prometheus/metrics 9 | ``` 10 | 我们还要假设，您需要访问Prometheus实例的所有用户的用户名和密码。 对于此示例，请使用`admin`作为用户名并选择您想要的任何密码。 11 | 12 | 首先，使用`htpasswd`工具创建一个`.htpasswd`文件来存储用户名/密码，并将其存储在`/etc/nginx`目录中： 13 | ``` 14 | mkdir -p /etc/nginx 15 | htpasswd -c /etc/nginx/.htpasswd admin 16 | ``` 17 | 18 | ### Nginx配置 19 | 下面是一个示例`nginx.conf`配置文件（存储在`/etc/nginx/.htpasswd中`）。 使用此配置，nginx将对`/prometheus`端点（代理Prometheus）的所有连接强制执行基本身份验证： 20 | ``` 21 | http { 22 | server { 23 | listen 12321; 24 | 25 | location /prometheus { 26 | auth_basic "Prometheus"; 27 | auth_basic_user_file /etc/nginx/.htpasswd; 28 | 29 | proxy_pass http://localhost:9090/; 30 | } 31 | } 32 | } 33 | 34 | events {} 35 | ``` 36 | 使用上面的配置启动nginx： 37 | ``` 38 | nginx -c /etc/nginx/nginx.conf 39 | ``` 40 | 41 | ### Prometheus配置 42 | 在nginx代理后面运行Prometheus时，您需要将外部URL设置为`http：//localhost：12321/prometheus`，并将路由前缀设置为`/`： 43 | ``` 44 | prometheus \ 45 | --config.file=/path/to/prometheus.yml \ 46 | --web.external-url=http://localhost:12321/prometheus \ 47 | --web.route-prefix="/" 48 | ``` 49 | 50 | ### 测试 51 | 您可以使用cURL与本地nginx / Prometheus设置进行交互。 试试这个请求： 52 | ``` 53 | curl --head http://localhost:12321/prometheus/graph 54 | ``` 55 | 这将返回`401 Unauthorized`响应，因为您未能提供有效的用户名和密码。 响应还将包含由nginx提供的`WWW-Authenticate：Basic realm="Prometheus"`标头，表示强制执行由nginx的auth_basic参数指定的`Prometheus``auth_basic`领域。 56 | 57 | 要使用基本身份验证（例如`/metrics`端点）成功访问Prometheus端点，请使用`-u`标志提供正确的用户名，并在提示时提供密码： 58 | ``` 59 | curl -u admin http://localhost:12321/prometheus/metrics 60 | Enter host password for user 'admin': 61 | ``` 62 | 那应该返回Prometheus指标输出，看起来应该是这样的： 63 | ``` 64 | # HELP go_gc_duration_seconds A summary of the GC invocation durations. 65 | # TYPE go_gc_duration_seconds summary 66 | go_gc_duration_seconds{quantile="0"} 0.0001343 67 | go_gc_duration_seconds{quantile="0.25"} 0.0002032 68 | go_gc_duration_seconds{quantile="0.5"} 0.0004485 69 | ... 70 | ``` 71 | 72 | ### 总结 73 | 在本指南中，您将用户名和密码存储在`.htpasswd`文件中，配置nginx以使用该文件中的凭据来验证访问Prometheus的HTTP端点，启动nginx以及配置Prometheus以进行反向代理的用户。 -------------------------------------------------------------------------------- /guides/Instrumenting_a_go_application.md: -------------------------------------------------------------------------------- 1 | ## INSTRUMENTING A GO APPLICATION FOR PROMETHEUS 2 | --- 3 | Prometheus有一个官方[Go客户端库](https://github.com/prometheus/client_golang)，您可以使用它来检测Go应用程序。 在本指南中，我们将创建一个简单的Go应用程序，通过HTTP公开Prometheus指标。 4 | 5 | ### 安装 6 | 您可以使用go get安装指南所需的`prometheus`，`promauto`和`promhttp`库： 7 | ``` 8 | go get github.com/prometheus/client_golang/prometheus 9 | go get github.com/prometheus/client_golang/prometheus/promauto 10 | go get github.com/prometheus/client_golang/prometheus/promhttp 11 | ``` 12 | 13 | ### Go exposition如何运作 14 | 要在Go应用程序中公开Prometheus指标，您需要提供`/metrics` HTTP端点。 您可以使用`prometheus/promhttp`库的HTTP` Handler`作为处理函数。 15 | 16 | 例如，这个最小的应用程序将通过`http://localhost:2112/metrics`公开Go应用程序的默认指标： 17 | ``` 18 | package main 19 | 20 | import ( 21 | "net/http" 22 | 23 | "github.com/prometheus/client_golang/prometheus/promhttp" 24 | ) 25 | 26 | func main() { 27 | http.Handle("/metrics", promhttp.Handler()) 28 | http.ListenAndServe(":2112", nil) 29 | } 30 | ``` 31 | 启动这个应用： 32 | ``` 33 | go run main.go 34 | ``` 35 | 获取metrics： 36 | ``` 37 | curl http://localhost:2112/metrics 38 | ``` 39 | 40 | ### 添加你自己的指标 41 | 上面的应用程序仅公开默认的Go指标。 您还可以注册自己的自定义应用程序特定度量标准。 此示例应用程序公开`myapp_processed_ops_total`计数器，该计数器计算到目前为止已处理的操作数。 每2秒钟，计数器加1。 42 | ``` 43 | package main 44 | 45 | import ( 46 | "net/http" 47 | "time" 48 | 49 | "github.com/prometheus/client_golang/prometheus" 50 | "github.com/prometheus/client_golang/prometheus/promauto" 51 | "github.com/prometheus/client_golang/prometheus/promhttp" 52 | ) 53 | 54 | func recordMetrics() { 55 | go func() { 56 | for { 57 | opsProcessed.Inc() 58 | time.Sleep(2 * time.Second) 59 | } 60 | }() 61 | } 62 | 63 | var ( 64 | opsProcessed = promauto.NewCounter(prometheus.CounterOpts{ 65 | Name: "myapp_processed_ops_total", 66 | Help: "The total number of processed events", 67 | }) 68 | ) 69 | 70 | func main() { 71 | recordMetrics() 72 | 73 | http.Handle("/metrics", promhttp.Handler()) 74 | http.ListenAndServe(":2112", nil) 75 | } 76 | ``` 77 | 启动这个应用： 78 | ``` 79 | go run main.go 80 | ``` 81 | 获取metrics： 82 | ``` 83 | curl http://localhost:2112/metrics 84 | ``` 85 | 在metrics输出中，您将看到`myapp_processed_ops_total`计数器的帮助文本，类型信息和当前值： 86 | ``` 87 | # HELP myapp_processed_ops_total The total number of processed events 88 | # TYPE myapp_processed_ops_total counter 89 | myapp_processed_ops_total 5 90 | ``` 91 | 您可以[配置](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Cscrape_config)本地运行的Prometheus实例以从应用程序中删除指标。 这是`prometheus.yml`配置示例： 92 | ``` 93 | scrape_configs: 94 | - job_name: myapp 95 | scrape_interval: 10s 96 | static_configs: 97 | - targets: 98 | - localhost:2112 99 | ``` 100 | 101 | ### 其他Go客户端特征 102 | 在本指南中，我们仅介绍了Prometheus Go客户端库中的一小部分功能。 您还可以公开其他度量标准类型，例如[gauges](https://godoc.org/github.com/prometheus/client_golang/prometheus#Gauge)和[直方图](https://godoc.org/github.com/prometheus/client_golang/prometheus#Histogram)，[非全局注册表](https://godoc.org/github.com/prometheus/client_golang/prometheus#Registry)，将[指标推送](https://godoc.org/github.com/prometheus/client_golang/prometheus/push)到Prometheus [PushGateways](https://prometheus.io/docs/instrumenting/pushing/)的功能，桥接Prometheus和[Graphite](https://godoc.org/github.com/prometheus/client_golang/prometheus/graphite)等等。 103 | 104 | ### 总结 105 | 在本指南中，您创建了两个示例Go应用程序，这些应用程序向Prometheus公开指标 - 一个仅公开默认Go指标，另一个公开自定义Prometheus计数器 - 并配置Prometheus实例以从这些应用程序中提取指标。 -------------------------------------------------------------------------------- /guides/Monitoring_docker_container_metrics_using_cadvisor.md: -------------------------------------------------------------------------------- 1 | ## 使用CADVISOR监控DOCKER容器的指标 2 | --- 3 | [cAdvisor](https://github.com/google/cadvisor)（容器顾问的简称）分析并公开运行容器的资源使用和性能数据。 cAdvisor开箱即用暴露Prometheus指标。 在本指南中，我们将： 4 | 5 | - 创建一个本地多容器[Docker Compose](https://docs.docker.com/compose/)安装，其中包括分别运行Prometheus，cAdvisor和[Redis](https://redis.io/)服务器的容器 6 | - 检查由Redis容器生成的一些容器指标，由cAdvisor收集并由Prometheus抓取 7 | 8 | ### Prometheus配置 9 | 首先，您需要配置Prometheus以从cAdvisor中获取指标。 创建一个prometheus.yml文件并使用以下配置填充它： 10 | ``` 11 | scrape_configs: 12 | - job_name: cadvisor 13 | scrape_interval: 5s 14 | static_configs: 15 | - targets: 16 | - cadvisor:8080 17 | ``` 18 | ### Docker Compose配置 19 | 现在我们需要创建一个Docker Compose[配置](https://docs.docker.com/compose/compose-file/)，指定哪些容器是我们安装的一部分，以及每个容器暴露的端口，使用哪些卷等等。 20 | 21 | 在您创建`prometheus.yml`文件的同一文件夹中，创建一个`docker-compose.yml`文件并使用此Docker Compose配置填充它： 22 | ``` 23 | version: '3.2' 24 | services: 25 | prometheus: 26 | image: prom/prometheus:latest 27 | container_name: prometheus 28 | ports: 29 | - 9090:9090 30 | command: 31 | - --config.file=/etc/prometheus/prometheus.yml 32 | volumes: 33 | - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro 34 | depends_on: 35 | - cadvisor 36 | cadvisor: 37 | image: google/cadvisor:latest 38 | container_name: cadvisor 39 | ports: 40 | - 8080:8080 41 | volumes: 42 | - /:/rootfs:ro 43 | - /var/run:/var/run:rw 44 | - /sys:/sys:ro 45 | - /var/lib/docker/:/var/lib/docker:ro 46 | depends_on: 47 | - redis 48 | redis: 49 | image: redis:latest 50 | container_name: redis 51 | ports: 52 | - 6379:6379 53 | ``` 54 | 55 | 此配置指示Docker Compose运行三个服务，每个服务对应一个Docker容器： 56 | 57 | 1. `prometheus`服务使用本地`prometheus.yml`配置文件（由`volumes`参数导入容器）。 58 | 2. `cadvisor`服务公开端口8080（cAdvisor度量标准的默认端口）并依赖于各种本地卷（`/`，`/var/run`等）。 59 | 3. `redis`服务是标准的Redis服务器。 cAdvisor将自动从该容器收集容器指标，即无需进一步配置。 60 | 61 | 要运行安装： 62 | ``` 63 | docker-compose up 64 | ``` 65 | 如果Docker Compose成功启动所有三个容器，您应该看到如下输出： 66 | ``` 67 | prometheus | level=info ts=2018-07-12T22:02:40.5195272Z caller=main.go:500 msg="Server is ready to receive web requests." 68 | ``` 69 | 您可以使用ps命令验证所有三个容器是否都在运行： 70 | ``` 71 | docker-compose ps 72 | ``` 73 | 您的输出将如下所示： 74 | ``` 75 | Name Command State Ports 76 | ---------------------------------------------------------------------------- 77 | cadvisor /usr/bin/cadvisor -logtostderr Up 8080/tcp 78 | prometheus /bin/prometheus --config.f ... Up 0.0.0.0:9090->9090/tcp 79 | redis docker-entrypoint.sh redis ... Up 0.0.0.0:6379->6379/tcp 80 | ``` 81 | ### 探索cAdvisor Web UI 82 | 您可以访问位于`http://localhost:8080`的cAdvisor Web UI。 您可以在我们的安装位置`http://localhost:8080/docker/`中浏览特定Docker容器的统计信息和图形。 例如，可以在`http://localhost:8080/docker/redis`，Prometheus在`http://localhost:8080/docker/prometheus`上访问Redis容器的度量标准，依此类推。 83 | 84 | ### 在表达式浏览器中探索指标 85 | cAdvisor的Web UI是一个有用的界面，用于探索cAdvisor监控的各种事物，但它没有提供用于探索容器度量的界面。 为此，我们需要Prometheus表达式浏览器，它可以在`http://localhost:9090/graph`中找到。 您可以在表达式栏中输入Prometheus表达式，如下所示： 86 | 87 | ![prometheus-expression-bar](https://prometheus.io/assets/prometheus-expression-bar.png) 88 | 89 | 让我们首先探索`container_start_time_seconds`指标，该指标记录容器的开始时间（以秒为单位）。 您可以使用`name=""`表达式按名称选择特定容器。 容器名称对应于Docker Compose配置中的`container_name`参数。 例如，`container_start_time_seconds{name="redis"}`表达式显示了`redis`容器的开始时间。 90 | 91 | ### 其他表达式 92 | 下表列出了一些其他示例表达式： 93 | 94 | |表达式|描述|目的| 95 | |---|---|---| 96 | | `rate(container_cpu_usage_seconds_total{name="redis"}[1m])` | cgroup在最后一分钟的CPU使用率（按核心划分） | `redis`容器 | 97 | | `container_memory_usage_bytes{name="redis"}` | cgroup的总内存使用量（以字节为单位） | `redis`容器 | 98 | | `rate(container_network_transmit_bytes_total[1m])` | 在最后一分钟，容器每秒通过网络传输的字节数 | 所有容器 | 99 | | `rate(container_network_receive_bytes_total[1m])` | 在最后一分钟，容器每秒接收网络传输的字节数 | 所有容器 | 100 | 101 | ### 总结 102 | 在本指南中，我们使用Docker Compose在一个安装中运行了三个独立的容器：一个Prometheus容器从cAdvisor容器中抓取指标，该容器反过来收集由Redis容器生成的指标。 然后，我们使用Prometheus表达式浏览器探索了一些cAdvisor容器指标。 -------------------------------------------------------------------------------- /guides/Monitoring_linux_host_metrics_with_the_node_exporter.md: -------------------------------------------------------------------------------- 1 | ## 使用NODE EXPORTER监控LINUX主机指标 2 | --- 3 | Prometheus [Node Exporter](https://github.com/prometheus/node_exporter)公开了各种与硬件和内核相关的指标。 4 | 5 | 在本指南中，您将： 6 | 7 | - 在`localhost`上启动node exporter 8 | - 在`localhost`上启动一个Prometheus实例，该实例配置为从正在运行的node exporter中获取指标 9 | 10 | ### 安装并运行Node Exporter 11 | Prometheus节点导出器是一个可以[通过tarball](https://prometheus.io/docs/guides/node-exporter/#tarball-installation)安装的单个静态二进制文件。 从Prometheus[下载页面](https://prometheus.io/download/#node_exporter)下载后，将其解压缩并运行： 12 | ``` 13 | wget https://github.com/prometheus/node_exporter/releases/download/v*/node_exporter-*.*-amd64.tar.gz 14 | tar xvfz node_exporter-*.*-amd64.tar.gz 15 | cd node_exporter-*.*-amd64 16 | ./node_exporter 17 | ``` 18 | 您应该看到这样的输出，表明Node Exporter现在正在运行并在端口9100上公开指标： 19 | ``` 20 | INFO[0000] Starting node_exporter (version=0.16.0, branch=HEAD, revision=d42bd70f4363dced6b77d8fc311ea57b63387e4f) source="node_exporter.go:82" 21 | INFO[0000] Build context (go=go1.9.6, user=root@a67a9bc13a69, date=20180515-15:53:28) source="node_exporter.go:83" 22 | INFO[0000] Enabled collectors: source="node_exporter.go:90" 23 | INFO[0000] - boottime source="node_exporter.go:97" 24 | ... 25 | INFO[0000] Listening on :9100 source="node_exporter.go:111" 26 | ``` 27 | 28 | ### Node Exporter指标 29 | 安装并运行节点导出程序后，您可以通过cURLing `/metrics`端点验证是否正在导出度量标准： 30 | ``` 31 | curl http://localhost:9100/metrics 32 | ``` 33 | 你应该看到像这样的输出： 34 | ``` 35 | # HELP go_gc_duration_seconds A summary of the GC invocation durations. 36 | # TYPE go_gc_duration_seconds summary 37 | go_gc_duration_seconds{quantile="0"} 3.8996e-05 38 | go_gc_duration_seconds{quantile="0.25"} 4.5926e-05 39 | go_gc_duration_seconds{quantile="0.5"} 5.846e-05 40 | # etc. 41 | ``` 42 | 成功！ Node Exporter现在公开了Prometheus可以抓取的指标，包括输出中更多的系统指标（以`node_`为前缀）。 要查看这些指标（以及帮助和类型信息）： 43 | ``` 44 | curl http://localhost:9100/metrics | grep "node_" 45 | ``` 46 | 47 | ### 配置你的Prometheus实例 48 | 需要正确配置本地运行的Prometheus实例才能访问节点导出器指标。 以下`scrape_config`块（在`prometheus.yml`配置文件中）将告诉Prometheus实例通过`localhost：9100`从节点导出器中删除： 49 | ``` 50 | scrape_configs: 51 | - job_name: 'node' 52 | static_configs: 53 | - targets: ['localhost:9100'] 54 | ``` 55 | 要安装Prometheus，请下载适用于您平台的最新版本并解压缩它： 56 | ``` 57 | wget https://github.com/prometheus/prometheus/releases/download/v*/prometheus-*.*-amd64.tar.gz 58 | tar xvf prometheus-*.*-amd64.tar.gz 59 | cd prometheus-*.* 60 | ``` 61 | 安装Prometheus后，您可以启动它，使用`--config.file`标志指向您在上面创建的Prometheus配置： 62 | ``` 63 | ./prometheus --config.file=./prometheus.yml 64 | ``` 65 | 66 | ### 通过Prometheus表达式浏览器探索节点导出器指标 67 | 现在Prometheus正在从正在运行的Node Exporter实例中抓取指标，您可以使用Prometheus UI（也就是表达式浏览器）来探索这些指标。 在浏览器中导航到`localhost：9090 / graph`，然后使用页面顶部的主表达式栏输入表达式。 表达式栏看起来像这样： 68 | 69 | ![prometheus-expression-bar](https://prometheus.io/assets/prometheus-expression-bar.png) 70 | 71 | 特定于节点导出器的度量标准以`node_`为前缀，并包含`node_cpu_seconds_total`和`node_exporter_build_info`等度量标准。 72 | 73 | 点击下面的链接查看一些示例指标： 74 | 75 | | 指标 | 含义 | 76 | |---|---| 77 | | `rate(node_cpu_seconds_total{mode="system"}[1m])` | 系统模式下每秒平均花费的CPU时间（以秒为单位） | 78 | | `node_filesystem_avail_bytes` | 非root用户可用的文件系统空间（以字节为单位） | 79 | | `非root用户可用的文件系统空间（以字节为单位）` | 每秒接收的平均网络流量（以字节为单位） | -------------------------------------------------------------------------------- /guides/README.md: -------------------------------------------------------------------------------- 1 | 译文：https://prometheus.io/docs/guides/basic-auth/ -------------------------------------------------------------------------------- /guides/TLS_encryption.md: -------------------------------------------------------------------------------- 1 | ## 使用TLS加密保护PROMETHEUS API和UI端点 2 | --- 3 | Prometheus不直接支持与Prometheus实例（即表达式浏览器或HTTP API）连接的[传输层安全性](https://en.wikipedia.org/wiki/Transport_Layer_Security)（TLS）加密。 如果您想为这些连接强制执行TLS，我们建议将Prometheus与[反向代理](https://www.nginx.com/resources/glossary/reverse-proxy-server/)结合使用，并在代理层应用TLS。 您可以使用Prometheus的任何反向代理，但在本指南中我们将提供一个[nginx示例](https://prometheus.io/docs/guides/tls-encryption/#nginx-example)。 4 | 5 | ### nginx例子 6 | 假设您想要在`example.co`m域（您拥有）的nginx服务器后面运行Prometheus实例，并且可以通过`/prometheus`端点获得所有Prometheus端点。 因此，Prometheus'`/metrics`端点的完整URL将是： 7 | ``` 8 | https://example.com/prometheus/metrics 9 | ``` 10 | 我们还假设你使用[OpenSSL](https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs)或类似工具生成了以下内容： 11 | 12 | - `/root/certs/example.com/example.com.crt`上的SSL证书 13 | - `/root/certs/example.com/example.com.key`上的SSL密钥 14 | 15 | 您可以使用以下命令生成自签名证书和私钥： 16 | ``` 17 | mkdir -p /root/certs/example.com && cd /root/certs/example.com 18 | openssl req \ 19 | -x509 \ 20 | -newkey rsa:4096 \ 21 | -nodes \ 22 | -keyout example.com.key \ 23 | -out example.com.crt 24 | ``` 25 | 根据提示填写相应的信息，并确保在`Common Name`提示符下输入`example.com`。 26 | 27 | ### nginx配置 28 | 下面是一个示例`nginx.conf`配置文件。 使用此配置，nginx将： 29 | 30 | - 使用您提供的证书和密钥强制执行TLS加密 31 | - 将与`/prometheus`端点的所有连接代理到在同一主机上运行的Prometheus服务器（同时从URL中删除`/prometheus`） 32 | 33 | ``` 34 | http { 35 | server { 36 | listen 443 ssl; 37 | server_name example.com; 38 | ssl_certificate /root/certs/example.com/example.com.crt; 39 | ssl_certificate_key /root/certs/example.com/example.com.key; 40 | 41 | location /prometheus { 42 | proxy_pass http://localhost:9090/; 43 | } 44 | } 45 | } 46 | 47 | events {} 48 | ``` 49 | 以root身份启动nginx（因为nginx需要绑定到端口443）： 50 | ``` 51 | sudo nginx -c /usr/local/etc/nginx/nginx.conf 52 | ``` 53 | 54 | ### Prometheus配置 55 | 在nginx代理后面运行Prometheus时，您需要将外部URL设置为`http://example.com/prometheus`，并将路由前缀设置为`/`： 56 | ``` 57 | prometheus \ 58 | --config.file=/path/to/prometheus.yml \ 59 | --web.external-url=http://example.com/prometheus \ 60 | --web.route-prefix="/" 61 | ``` 62 | 63 | ### 测试 64 | 如果您想使用`example.com`域在本地测试nginx代理，可以在`/etc/hosts`文件中添加一个条目，将`example.com`重新路由到`localhost`： 65 | ``` 66 | 127.0.0.1 example.com 67 | ``` 68 | 然后，您可以使用cURL与本地nginx / Prometheus设置进行交互： 69 | ``` 70 | curl --cacert /root/certs/example.com/example.com.crt \ 71 | https://example.com/prometheus/api/v1/label/job/values 72 | ``` 73 | 您可以使用`--insecure`或`-k`标志连接到nginx服务器而不指定证书： 74 | ``` 75 | curl -k https://example.com/prometheus/api/v1/label/job/values 76 | ``` -------------------------------------------------------------------------------- /guides/Use_file_based_service_discovert_to_discover_scrape_targets.md: -------------------------------------------------------------------------------- 1 | ## 使用基于文件的服务发现来抓取目标 2 | --- 3 | Prometheus提供各种[服务发现](https://github.com/prometheus/prometheus/tree/master/discovery)选项，用于发现抓取目标，包括[Kubernetes](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Ckubernetes_sd_config)，[Consul](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Cconsul_sd_config)等等。 如果您需要使用当前不支持的服务发现系统，Prometheus[基于文件的服务发现机制](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Cfile_sd_config)可以最好地为您的用例提供服务，该机制允许您列出JSON文件中的scrape目标（以及有关这些目标的元数据））。 4 | 5 | 在本指南中，我们将： 6 | 7 | - 在本地安装并运行Prometheus [Node Exporter](https://prometheus.io/docs/guides/node-exporter/) 8 | - 创建一个`targets.json`文件，指定Node Exporter的主机和端口信息 9 | - 安装并运行配置为使用`targets.json`文件发现Node Exporter的Prometheus实例 10 | 11 | ### 安装并运行Node Exporter 12 | 请参阅[使用节点导出器指南监视Linux主机指标](https://prometheus.io/docs/guides/node-exporter/)的此部分。 节点导出程序在端口9100上运行。要确保节点导出程序正在公开指标： 13 | ``` 14 | curl http://localhost:9100/metrics 15 | ``` 16 | 指标输出应该像这样： 17 | ``` 18 | # HELP go_gc_duration_seconds A summary of the GC invocation durations. 19 | # TYPE go_gc_duration_seconds summary 20 | go_gc_duration_seconds{quantile="0"} 0 21 | go_gc_duration_seconds{quantile="0.25"} 0 22 | go_gc_duration_seconds{quantile="0.5"} 0 23 | ... 24 | ``` 25 | 26 | ### 安装，配置并运行Prometheus 27 | 与Node Exporter一样，Prometheus是一个可以通过tarball安装的静态二进制文件。 [下载适用于您平台的最新版本](https://prometheus.io/download/#prometheus)并解压缩它： 28 | ``` 29 | wget https://github.com/prometheus/prometheus/releases/download/v*/prometheus-*.*-amd64.tar.gz 30 | tar xvf prometheus-*.*-amd64.tar.gz 31 | cd prometheus-*.* 32 | ``` 33 | untarred目录包含`prometheus.yml`配置文件。 用以下内容替换该文件的当前内容： 34 | ``` 35 | scrape_configs: 36 | - job_name: 'node' 37 | file_sd_configs: 38 | - files: 39 | - 'targets.json' 40 | ``` 41 | 此配置指定存在一个名为`node`（用于节点导出器）的作业，该作业从`targets.json`文件中检索节点导出器实例的主机和端口信息。 42 | 43 | 现在创建`targets.json`文件并将其添加到其中： 44 | ``` 45 | [ 46 | { 47 | "labels": { 48 | "job": "node" 49 | }, 50 | "targets": [ 51 | "localhost:9100" 52 | ] 53 | } 54 | ] 55 | ``` 56 | 此配置指定存在具有一个目标的`node`作业：`localhost:9100`。 57 | 58 | 现在你可以启动Prometheus了： 59 | ``` 60 | ./prometheus 61 | ``` 62 | 如果Prometheus已成功启动，您应该在日志中看到如下所示的行： 63 | ``` 64 | level=info ts=2018-08-13T20:39:24.905651509Z caller=main.go:500 msg="Server is ready to receive web requests." 65 | ``` 66 | 67 | ### 探索已发现服务的指标 68 | 启动并运行Prometheus后，您可以使用Prometheus表达式浏览器探索`node`服务公开的指标。 例如，如果您浏览`up{job="node"}`指标，则可以看到正在正确发现节点导出器。 69 | 70 | ### 动态更改目标列表 71 | 使用Prometheus基于文件的服务发现机制时，Prometheus实例将侦听对文件的更改并自动更新scrape目标列表，而无需重新启动实例。 为了演示这一点，请在端口9200上启动第二个Node Exporter实例。首先导航到包含Node Exporter二进制文件的目录，然后在新的终端窗口中运行此命令： 72 | ``` 73 | ./node_exporter --web.listen-address=":9200" 74 | ``` 75 | 现在通过为新的Node Exporter添加一个条目来修改`targets.json`中的配置： 76 | ``` 77 | [ 78 | { 79 | "targets": [ 80 | "localhost:9100" 81 | ], 82 | "labels": { 83 | "job": "node" 84 | } 85 | }, 86 | { 87 | "targets": [ 88 | "localhost:9200" 89 | ], 90 | "labels": { 91 | "job": "node" 92 | } 93 | } 94 | ] 95 | ``` 96 | 保存更改后，Prometheus将自动收到新目标列表的通知。 `up{jo ="node"}`指标应显示两个`instance`标签为`localhost：9100`和`localhost：9200`。 97 | 98 | ### 总结 99 | 在本指南中，您安装并运行了Prometheus节点导出程序并配置了Prometheus，以使用基于文件的服务发现从节点导出程序中发现和搜索指标。 -------------------------------------------------------------------------------- /instrumenting/Client_libraries.md: -------------------------------------------------------------------------------- 1 | 客户端库向其代码添加检测。 这些实现了Prometheus度量标准类型。 2 | 3 | 选择与您的应用程序编写语言相匹配的Prometheus客户端库。 这允许您通过应用程序实例上的HTTP端点定义和公开内部指标： 4 | 5 | - [Go](https://github.com/prometheus/client_golang) 6 | - [Java or Scala](https://github.com/prometheus/client_java) 7 | - [Python](https://github.com/prometheus/client_python) 8 | - [Ruby](https://github.com/prometheus/client_ruby) 9 | 10 | 非正式的第三方客户端库 11 | - [Bash](https://github.com/aecolley/client_bash) 12 | - [C](https://github.com/digitalocean/prometheus-client-c) 13 | - [C++](https://github.com/jupp0r/prometheus-cpp) 14 | - [Common Lisp](https://github.com/deadtrickster/prometheus.cl) 15 | - [Elixir](https://github.com/deadtrickster/prometheus.ex) 16 | - [Erlang](https://github.com/deadtrickster/prometheus.erl) 17 | - [Haskell](https://github.com/fimad/prometheus-haskell) 18 | - [Lua for Nginx](https://github.com/knyar/nginx-lua-prometheus) 19 | - [Lua for Tarantool](https://github.com/tarantool/prometheus) 20 | - [.Net/C#](https://github.com/andrasm/prometheus-net) 21 | - [Node.js](https://github.com/siimon/prom-client) 22 | - [PHP](https://github.com/Jimdo/prometheus_client_php) 23 | - [Rust](https://github.com/pingcap/rust-prometheus) 24 | 25 | 当Prometheus擦除实例的HTTP端点时，客户端库会将所有跟踪的度量标准的当前状态发送到服务器。 26 | 27 | 如果您的语言没有可用的客户端库，或者您希望避免依赖性，那么您也可以自己实现一种受支持的[展示格式](https://prometheus.io/docs/instrumenting/exposition_formats/)以公开指标。 28 | 29 | 在实施新的Prometheus客户端库时，请[遵循编写客户端库的指导原则](https://prometheus.io/docs/instrumenting/writing_clientlibs/)。 请注意，此文档仍在进行中。 另请考虑咨询[开发邮件列表](https://groups.google.com/forum/#!forum/prometheus-developers)。 我们很乐意就如何使您的库尽可能有用和一致提供建议。实现一个新的Prometheus客户端库时，请遵循[客户端指南](https://prometheus.io/docs/instrumenting/writing_clientlibs)。注意，这个文档在仍然在更新中。同时也请关注[开发邮件列表](https://groups.google.com/forum/#!forum/prometheus-developers)。我们非常乐意地给出合适的意见或者建议。 30 | 31 | -------------------------------------------------------------------------------- /instrumenting/Exporters_and_integrations.md: -------------------------------------------------------------------------------- 1 | 有许多库和服务器可帮助从第三方系统导出现有指标作为Prometheus指标。 这对于无法直接使用Prometheus指标（例如，HAProxy或Linux系统统计信息）检测给定系统的情况非常有用。 2 | 3 | ##### 一、第三方导出器 4 | 其中一些出口商作为[普罗米修斯GitHub官方组织](https://github.com/prometheus)的一部分进行维护，这些出口商被标记为官方，其他出口商则由外部提供和维护。 5 | 6 | 我们鼓励创建更多出口商，但不能审查所有出口商的[最佳做法](https://prometheus.io/docs/instrumenting/writing_exporters/)。 通常，这些出口商在Prometheus GitHub组织之外托管。 7 | 8 | [导出器默认端口](https://github.com/prometheus/prometheus/wiki/Default-port-allocations)wiki页面已成为另一个导出器目录，可能包括由于功能重叠或仍在开发中未在此处列出的导出器。 9 | 10 | [JMX导出器](https://github.com/prometheus/jmx_exporter)可以从各种基于JVM的应用程序导出，例如[Kafka](http://kafka.apache.org/)和[Cassandra](http://cassandra.apache.org/)。 11 | 12 | ###### 1.1 数据库 13 | - [Aerospike exporter](https://github.com/alicebob/asprom) 14 | - [ClickHouse exporter](https://github.com/f1yegor/clickhouse_exporter) 15 | - [Consul exporter](https://github.com/prometheus/consul_exporter) **官方** 16 | - [Couchbase exporter](https://github.com/blakelead/couchbase_exporter) 17 | - [CouchDB exporter](https://github.com/gesellix/couchdb-exporter) 18 | - [ElasticSearch exporter](https://github.com/justwatchcom/elasticsearch_exporter) 19 | - [EventStore exporter](https://github.com/marcinbudny/eventstore_exporter) 20 | - [Memcached exporter](https://github.com/prometheus/memcached_exporter) **官方** 21 | - [MongoDB exporter](https://github.com/dcu/mongodb_exporter) 22 | - [MSSQL exporter](https://github.com/awaragi/prometheus-mssql-exporter) 23 | - [MySQL router exporter](https://github.com/rluisr/mysqlrouter_exporter) 24 | - [MySQL server exporter](https://github.com/prometheus/mysqld_exporter) **官方** 25 | - [OpenTSDB exporter](https://github.com/cloudflare/opentsdb_exporter) 26 | - [Oracle exporter](https://github.com/iamseth/oracledb_exporter) 27 | - [PgBouncer exporter](http://git.cbaines.net/prometheus-pgbouncer-exporter/about) 28 | - [PostgreSQL exporter](https://github.com/wrouesnel/postgres_exporter) 29 | - [Presto exporter](https://github.com/yahoojapan/presto_exporter) 30 | - [ProxySQL exporter](https://github.com/percona/proxysql_exporter) 31 | - [RavenDB exporter](https://github.com/marcinbudny/ravendb_exporter) 32 | - [Redis exporter](https://github.com/oliver006/redis_exporter) 33 | - [RethinkDB exporter](https://github.com/oliver006/rethinkdb_exporter) 34 | - [SQL exporter](https://github.com/free/sql_exporter) 35 | - [Tarantool metric library](https://github.com/tarantool/prometheus) 36 | - [Twemproxy](https://github.com/stuartnelson3/twemproxy_exporter) 37 | 38 | ###### 1.2 硬件相关 39 | - [apcupsd exporter](https://github.com/mdlayher/apcupsd_exporter) 40 | - [BIG-IP exporter](https://github.com/ExpressenAB/bigip_exporter) 41 | - [Collins exporter](https://github.com/soundcloud/collins_exporter) 42 | - [Dell Hardware OMSA exporter](https://github.com/galexrt/dellhw_exporter) 43 | - [IBM Z HMC exporter](https://github.com/zhmcclient/zhmc-prometheus-exporter) 44 | - [IoT Edison exporter](https://github.com/lovoo/ipmi_exporter) 45 | - [IPMI Edison exporter](https://github.com/soundcloud/ipmi_exporter) 46 | - [knxd exporter](https://github.com/RichiH/knxd_exporter) 47 | - [Netgear Cable Modem exporter](https://github.com/ickymettle/netgear_cm_exporter) 48 | - [Netgear Router exporter](https://github.com/DRuggeri/netgear_exporter) 49 | - [Node/System metrics exporter](https://github.com/prometheus/node_exporter) **官方** 50 | - [NVIDIA GPU UniFi exporter](https://github.com/mindprince/nvidia_gpu_prometheus_exporter) 51 | - [ProSAFE UniFi exporter](https://github.com/dalance/prosafe_exporter) 52 | - [Ubiquiti UniFi exporter](https://github.com/mdlayher/unifi_exporter) 53 | 54 | ###### 1.3 发布跟踪器和持续集成 55 | - [Bamboo exporter](https://github.com/AndreyVMarkelov/bamboo-prometheus-exporter) 56 | - [Bitbucket exporter](https://github.com/AndreyVMarkelov/prom-bitbucket-exporter) 57 | - [Confluence exporter](https://github.com/AndreyVMarkelov/prom-confluence-exporter) 58 | - [Jenkins exporter](https://github.com/lovoo/jenkins_exporter) 59 | - [JIRA exporter](https://github.com/AndreyVMarkelov/jira-prometheus-exporter) 60 | 61 | ###### 1.4 消息系统 62 | - [Beanstalkd exporter](https://github.com/messagebird/beanstalkd_exporter) 63 | - [EMQ exporter](https://github.com/nuvo/emq_exporter) 64 | - [Gearman exporter](https://github.com/bakins/gearman-exporter) 65 | - [kafka exporter](https://github.com/danielqsj/kafka_exporter) 66 | - [NATS exporter](https://github.com/lovoo/nats_exporter) 67 | - [NSQ exporter](https://github.com/lovoo/nsq_exporter) 68 | - [Mirth Connect exporter](https://github.com/vynca/mirth_exporter) 69 | - [MQTT blackbox exporter](https://github.com/inovex/mqtt_blackbox_exporter) 70 | - [RabbitMQ exporter](https://github.com/kbudde/rabbitmq_exporter) 71 | - [RabbitMQ Management Plugin exporter](https://github.com/deadtrickster/prometheus_rabbitmq_exporter) 72 | - [RocketMQ exporter](https://github.com/apache/rocketmq-exporter) 73 | 74 | ###### 1.5 存储 75 | - [Ceph exporter](https://github.com/digitalocean/ceph_exporter) 76 | - [Ceph RADOSGW exporter](https://github.com/blemmenes/radosgw_usage_exporter) 77 | - [Gluster exporter](https://github.com/ofesseler/gluster_exporter) 78 | - [Hadoop HDFS FSImage exporter](https://github.com/marcelmay/hadoop-hdfs-fsimage-exporter) 79 | - [Lustre exporter](https://github.com/HewlettPackard/lustre_exporter) 80 | - [ScaleIO exporter](https://github.com/syepes/sio2prom) 81 | 82 | ###### 1.6 HTTP 83 | - [Apache exporter](https://github.com/neezgee/apache_exporter) 84 | - [HAProxy exporter](https://github.com/prometheus/haproxy_exporter) **官方** 85 | - [Nginx metric library](https://github.com/knyar/nginx-lua-prometheus) 86 | - [Nginx VTS exporter](https://github.com/hnlq715/nginx-vts-exporter) 87 | - [Passenger exporter](https://github.com/stuartnelson3/passenger_exporter) 88 | - [Squid exporter](https://github.com/boynux/squid-exporter) 89 | - [Tinyproxy exporter](https://github.com/igzivkov/tinyproxy_exporter) 90 | - [Varnish exporter](https://github.com/jonnenauha/prometheus_varnish_exporter) 91 | - [WebDriver exporter](https://github.com/mattbostock/webdriver_exporter) 92 | 93 | ###### 1.7 APIs 94 | - [AWS ECS exporter](https://github.com/slok/ecs-exporter) 95 | - [AWS Health exporter](https://github.com/Jimdo/aws-health-exporter) 96 | - [AWS SQS exporter](https://github.com/jmal98/sqs-exporter) 97 | - [Cloudfare exporter](https://github.com/wehkamp/docker-prometheus-cloudflare-exporter) 98 | - [DigitalOcean exporter](https://github.com/metalmatze/digitalocean_exporter) 99 | - [Docker Cloud exporter](https://github.com/infinityworksltd/docker-cloud-exporter) 100 | - [Docker Hub exporter](https://github.com/infinityworksltd/docker-hub-exporter) 101 | - [Github exporter](https://github.com/infinityworksltd/github-exporter) 102 | - [InstaClustr exporter](https://github.com/fcgravalos/instaclustr_exporter) 103 | - [Mozilla Observatory exporter](https://github.com/Jimdo/observatory-exporter) 104 | - [OpenWeatherMap exporter](https://github.com/RichiH/openweathermap_exporter) 105 | - [Pagespeed exporter](https://github.com/foomo/pagespeed_exporter) 106 | - [Rancher exporter](https://github.com/infinityworksltd/prometheus-rancher-exporter) 107 | - [Speedtest exporter](https://github.com/RichiH/speedtest_exporter) 108 | - [Tankerkönig API Exporter](https://github.com/lukasmalkmus/tankerkoenig_exporter) 109 | 110 | ###### 1.8 Logging 111 | - [Fluentd extractor](https://github.com/V3ckt0r/fluentd_exporter) 112 | - [Google's mtail log data extractor](https://github.com/google/mtail) 113 | - [Grok exporter](https://github.com/fstab/grok_exporter) 114 | 115 | ###### 1.9 其他的监控系统 116 | - [Akamai Colud monitor exporter](https://github.com/ExpressenAB/cloudmonitor_exporter) 117 | - [Alibaba Colud monitor exporter](https://github.com/aylei/aliyun-exporter) 118 | - [AWS CloudWatch exporter](https://github.com/prometheus/cloudwatch_exporter) **官方** 119 | - [Azure Monitor exporter](https://github.com/RobustPerception/azure_metrics_exporter) 120 | - [Cloud Foundry Firehose exporter](https://github.com/cloudfoundry-community/firehose_exporter) 121 | - [Collectd exporter](https://github.com/prometheus/collectd_exporter)**官方** 122 | - [Google Stackdriver exporter](https://github.com/frodenas/stackdriver_exporter) 123 | - [Graphite exporter](https://github.com/prometheus/graphite_exporter) **官方** 124 | - [Heka dashboard exporter](https://github.com/docker-infra/heka_exporter) 125 | - [Heka exporter](https://github.com/imgix/heka_exporter) 126 | - [Huawei Cloudeye exporter](https://github.com/huaweicloud/cloudeye-exporter) 127 | - [InfluxDB exporter](https://github.com/prometheus/influxdb_exporter) **官方** 128 | - [JavaMelody exporter](https://github.com/fschlag/javamelody-prometheus-exporter) 129 | - [JMX exporter](https://github.com/prometheus/jmx_exporter) **官方** 130 | - [Munin exporter](https://github.com/pvdh/munin_exporter) 131 | - [Nagios / Naemon exporter](https://github.com/Griesbacher/Iapetos) 132 | - [New Relic exporter](https://github.com/jfindley/newrelic_exporter) 133 | - [NRPE exporter](https://github.com/robustperception/nrpe_exporter) 134 | - [Osquery exporter](https://github.com/zwopir/osquery_exporter) 135 | - [OTC CloudEye exporter](https://github.com/tiagoReichert/otc-cloudeye-prometheus-exporter) 136 | - [Pingdom exporter](https://github.com/giantswarm/prometheus-pingdom-exporter) 137 | - [scollector exporter](https://github.com/tgulacsi/prometheus_scollector) 138 | - [Sensu exporter](https://github.com/reachlin/sensu_exporter) 139 | - [SNMP exporter](https://github.com/prometheus/snmp_exporter) **官方** 140 | - [StatsD exporter](https://github.com/prometheus/statsd_exporter) **官方** 141 | - [TencentCloud monitor exporter](https://github.com/tencentyun/tencentcloud-exporter) 142 | - [ThousandEyes exporter](https://github.com/sapcc/1000eyes_exporter) 143 | 144 | ###### 1.10 其他杂项 145 | - [ACT Fibernet exporter](https://git.captnemo.in/nemo/prometheus-act-exporter) 146 | - [BIND exporter](https://github.com/digitalocean/bind_exporter) 147 | - [Bitcoind exporter](https://github.com/LePetitBloc/bitcoind-exporter) 148 | - [BlackBox exporter](https://github.com/prometheus/blackbox_exporter) **官方** 149 | - [BOSH exporter](https://github.com/cloudfoundry-community/bosh_exporter) 150 | - [cAdvisor](https://github.com/google/cadvisor) 151 | - [Cachet exporter](https://github.com/ContaAzul/cachet_exporter) 152 | - [ccache exporter](https://github.com/virtualtam/ccache_exporter) 153 | - [Dovecot exporter](https://github.com/kumina/dovecot_exporter) 154 | - [eBPF exporter](https://github.com/cloudflare/ebpf_exporter) 155 | - [Ethereum Client exporter](https://github.com/31z4/ethereum-prometheus-exporter) 156 | - [JFrog Artifactory Exporter](https://github.com/peimanja/artifactory_exporter) 157 | - [Hostapd exporter](https://stash.i2cat.net/users/miguel_catalan/repos/hostapd_prometheus_exporter/browse) 158 | - [JMeter exporter](https://github.com/johrstrom/jmeter-prometheus-plugin) 159 | - [Kannel exporter](https://github.com/apostvav/kannel_exporter) 160 | - [Kemp LoadBalancer exporter](https://github.com/giantswarm/prometheus-kemp-exporter) 161 | - [Kibana exporter](https://github.com/pjhampton/kibana-prometheus-exporter) 162 | - [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 163 | - [Locust Exporter](https://github.com/ContainerSolutions/locust_exporter) 164 | - [Meteor JS web framework exporter](https://atmospherejs.com/sevki/prometheus-exporter) 165 | - [Minecraft exporter module](https://github.com/Baughn/PrometheusIntegration) 166 | - [OpenStack exporter](https://github.com/Linaro/openstack-exporter) 167 | - [OpenStack blackbox exporter](https://github.com/infraly/openstack_client_exporter) 168 | - [oVirt exporter](https://github.com/czerwonk/ovirt_exporter) 169 | - [Pact Broker exporter](https://github.com/ContainerSolutions/pactbroker_exporter) 170 | - [PHP-FPM exporter](https://github.com/bakins/php-fpm-exporter) 171 | - [PowerDNS exporter](https://github.com/janeczku/powerdns_exporter) 172 | - [Process exporter](https://github.com/ncabatoff/process-exporter) 173 | - [rTorrent exporter](https://github.com/mdlayher/rtorrent_exporter) 174 | - [SABnzbd exporter](https://github.com/msroest/sabnzbd_exporter) 175 | - [Script exporter](https://github.com/adhocteam/script_exporter) 176 | - [Shield exporter](https://github.com/bosh-prometheus/shield_exporter) 177 | - [Smokeping exporter](https://github.com/SuperQ/smokeping_prober) 178 | - [SMTP/Maildir MDA blackbox prober](https://github.com/cherti/mailexporter) 179 | - [SoftEther exporter](https://github.com/dalance/softether_exporter) 180 | - [Transmission exporter](https://github.com/metalmatze/transmission-exporter) 181 | - [Unbound exporter](https://github.com/kumina/unbound_exporter) 182 | - [WireGuard exporter](https://github.com/MindFlavor/prometheus_wireguard_exporter) 183 | - [Xen exporter](https://github.com/lovoo/xenstats_exporter) 184 | 185 | 在实施新的Prometheus出口商时，请遵循[编写出口商的指南](https://prometheus.io/docs/instrumenting/writing_exporters/)。另请考虑咨询开[发邮件列表](https://groups.google.com/forum/#!forum/prometheus-developers)。 我们很乐意就如何使您的出口商尽可能有用和一致提供建议。 186 | 187 | ##### 二、可直接使用的软件 188 | 某些第三方软件以Prometheus格式公开指标，因此不需要单独的导出器： 189 | - [App Connect Enterprise](https://github.com/ot4i/ace-docker) 190 | - [Ballerina](https://ballerina.io/) 191 | - [BFE](https://github.com/baidu/bfe) 192 | - [Ceph](http://docs.ceph.com/docs/master/mgr/prometheus/) 193 | - [CockroachDB](https://www.cockroachlabs.com/docs/stable/monitoring-and-alerting.html#prometheus-endpoint) 194 | - [Collectd](https://collectd.org/wiki/index.php/Plugin:Write_Prometheus) 195 | - [Concourse](https://concourse-ci.org/) 196 | - [CRG Roller Derby Scoreboard ](https://github.com/rollerderby/scoreboard) 197 | - [Docker Daemon ](https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-metrics) 198 | - [Doorman](https://github.com/youtube/doorman) 199 | - [Envoy 200 | ](https://www.envoyproxy.io/docs/envoy/latest/operations/admin.html#get--stats?format=prometheus) 201 | - [Etcd](https://github.com/coreos/etcd) 202 | - [Flink](https://github.com/apache/flink) 203 | - [FreeBSD Kernel](https://www.freebsd.org/cgi/man.cgi?query=prometheus_sysctl_exporter&apropos=0&sektion=8&manpath=FreeBSD+12-current&arch=default&format=html) 204 | - [Grafana](https://grafana.com/docs/administration/metrics/) 205 | - [JavaMelody](https://github.com/javamelody/javamelody/wiki/UserGuideAdvanced#exposing-metrics-to-prometheus) 206 | - [Kong](https://github.com/Kong/kong-plugin-prometheus) 207 | - [Kubernetes](https://github.com/kubernetes/kubernetes) 208 | - [Linkerd](https://github.com/linkerd/linkerd) 209 | - [mgmt](https://github.com/purpleidea/mgmt/blob/master/docs/prometheus.md) 210 | - [MidoNet](https://github.com/midonet/midonet) 211 | - [midonet-kubernetes](https://github.com/midonet/midonet-kubernetes) 212 | - [Minio](https://github.com/minio/minio) 213 | - [Netdata](https://github.com/netdata/netdata) 214 | - [Pretix](https://pretix.eu/about/en/) 215 | - [Quobyte](https://www.quobyte.com/) 216 | - [RabbitMQ](https://www.rabbitmq.com/prometheus.html) 217 | - [RobustIRC](http://robustirc.net/) 218 | - [ScyllaDB](https://github.com/scylladb/scylla) 219 | - [Skipper](https://github.com/zalando/skipper) 220 | - [SkyDNS](https://github.com/skynetservices/skydns) 221 | - [Telegraf](https://github.com/influxdata/telegraf/tree/master/plugins/outputs/prometheus_client) 222 | - [Traefik](https://github.com/containous/traefik) 223 | - [VerneMQ](https://github.com/vernemq/vernemq) 224 | - [Weave Flux](http://weaveworks.github.io/flux/) 225 | - [Xandikos](https://www.xandikos.org/) 226 | 227 | 直接标记的软件也直接使用Prometheus客户端库进行检测。 228 | 229 | ##### 三、其他第三方实用工具 230 | 本节列出了可帮助您使用特定语言编写代码的库和其他实用程序。 它们本身不是Prometheus客户端库，而是使用一个普通的Prometheus客户端库。 对于所有独立维护的软件，我们无法审核所有这些软件以获得最佳实践。 231 | - Coljure: [prometheus-clj](https://github.com/soundcloud/prometheus-clj) 232 | - Go: [go-metrics instrumentation library](https://github.com/armon/go-metrics) 233 | - Go: [gokit](https://github.com/peterbourgon/gokit) 234 | - Go: [prombolt](https://github.com/mdlayher/prombolt) 235 | - Java/JVM: [EclipseLink metrics collector](https://github.com/VitaNuova/eclipselinkexporter) 236 | - Java/JVM: [Hystrix metrics publisher](https://github.com/soundcloud/prometheus-hystrix) 237 | - Java/JVM: [Jersey metrics collector](https://github.com/VitaNuova/jerseyexporter) 238 | - Java/JVM: [Micrometer Prometheus Registry](https://micrometer.io/docs/registry/prometheus) 239 | - Python-Django: [django-prometheus](https://github.com/korfuri/django-prometheus) 240 | - Node.js: [swagger-stats](https://github.com/slanatech/swagger-stats) 241 | -------------------------------------------------------------------------------- /instrumenting/Exposition_formats.md: -------------------------------------------------------------------------------- 1 | 可以使用简单的[基于文本](https://prometheus.io/docs/instrumenting/exposition_formats/#text-based-format)的展示格式向Memetheus公开指标。 有各种各样的客户端库可以为您实现此格式。 如果您的首选语言没有客户端库，则可以[创建自己的语言库](https://prometheus.io/docs/instrumenting/writing_clientlibs/)。 2 | 3 | #### 一、基于文本格式 4 | 从Prometheus 2.0版开始，向Prometheus公开指标的所有流程都需要使用基于文本的格式。 在本节中，您可以找到有关此格式的一些[基本信息](https://prometheus.io/docs/instrumenting/exposition_formats/#basic-info)以及格式的更详细分类。 5 | 6 | ##### 1.1 基本信息 7 | | 条目 | 描述 | 8 | |--|----------:| 9 | |成立| 2014.4月| 10 | |支持|Prometheus 版本 `>=0.4.0` 11 | |传输协议| HTTP | 12 | | 编码| utf-8, `\n`行结尾| 13 | | HTTP `Content-Type`| `text/plain; version=0.0.4`（缺少版本值将导致回退到最新的文本格式版本。） 14 | | Optional HTTP `Content-Encoding`| `gzip` | 15 | | 优点 | -可读性好 16 | | | -易于组合，特别适用于简单情况（无需嵌套） 17 | | |- 逐行阅读（处理类型提示和文本字符串外） 18 | | 限制 | - 繁琐 19 | | | - 类型和文档字符串不是语法的组成部分，意味着很少 - 不存在的度量标准合同验证 20 | | | - 解析耗时 21 | | 支持度量指标原子性 | - Counter 22 | | | - Gauge 23 | | | - Histogram 24 | | | - Summary 25 | | | - Untyped 26 | 27 | ##### 1.2 文本格式详解 28 | 29 | Prometheus基于文本的格式是面向行的。 行由换行符（`\n`）分隔。 最后一行必须以换行符结尾。 空行被忽略。 30 | 31 | ###### 1.2.1 行格式 32 | 在一行内，令牌可以由任意数量的空格和/或制表符分隔（如果它们否则将与前一个令牌合并，则必须至少分开一个）。 前导空格和尾随空格被忽略。 33 | 34 | ###### 1.2.2 注释，帮助文本和类型信息 35 | 带`#`作为第一个非空白字符的行是注释。除`#`之后的第一个标记是`HELP`或`TYPE`，否则它们将被忽略。这些行被视为如下：如果令牌是`HELP`，则预期至少还有一个令牌，即度量标准名称。所有剩余的标记都被视为该度量标准名称的文档字符串。 `HELP`行可以包含任何UTF-8字符序列（在度量标准名称之后），但反斜杠和换行符必须分别转义为`\\`和`\n`。对于任何给定的度量标准名称，只能存在一个HELP行。 36 | 37 | 如果令牌是`TYPE`，则预计还会有两个令牌。第一个是度量标准名称，第二个是`counter`, `gauge`, `histogram`, `summary`, or `untyped`,，定义该名称的度量标准的类型。给定的度量标准名称只能存在一个`TYPE`行。在为该度量标准名称报告第一个样本之前，必须显示度量标准名称的TYPE行。如果度量标准名称没有`TYPE`行，则类型将设置为`untyped`。 38 | 39 | 其余行使用以下语法（EBNF）描述样本（每行一个）： 40 | ``` 41 | metric_name [ 42 | "{" label_name "=" `"` label_value `"` { "," label_name "=" `"` label_value `"` } [ "," ] "}" 43 | ] value [ timestamp ] 44 | ``` 45 | 在示例语法中： 46 | 47 | - `metric_name`和`label_name`带有通常的Prometheus表达式语言限制。 48 | - `label_value`可以是任何UTF-8字符序列，但反斜杠（`\`，双引号(`"`)和换行符（`\n`））必须分别转义为`\\`，`\"`和`\n`。 49 | - `value`是Go的`ParseFloat()`函数所需的浮点数。 除标准数值外，`Nan`，`+Inf`和`-Inf`分别是表示数字，正无穷大和负无穷大的有效值。 50 | - `timestamp`是`int64`（自纪元以来的毫秒，即1970-01-01 00:00:00 UTC，不包括闰秒），表示为Go的`ParseInt()`函数所需。 51 | 52 | ###### 1.2.3 分组和排序 53 | 给定度量的所有行必须作为一个单独的组提供，首先是可选的`HELP`和`TYPE`行（没有特定的顺序）。 除此之外，重复展示中的可重复排序是优选的，但不是必需的，即如果计算成本过高则不进行排序。 54 | 55 | 每行必须具有度量标准名称和标签的唯一组合。 否则，摄取行为未定义。 56 | 57 | ###### 1.2.4 Histograms and summaries 58 | `histogram `and `summary`类型很难以文本格式表示。 以下约定适用： 59 | 60 | - 名为`x`的摘要或直方图的样本总和作为名为`x_sum`的单独样本给出。 61 | - 名为`x`的摘要或直方图的样本计数作为名为`x_count`的单独样本给出。 62 | - 名为`x`的摘要的每个分位数作为单独的样本行给出，其具有相同的名称x和标签`{quantile="y"}`。 63 | - 名为`x`的直方图的每个桶计数作为单独的样本行给出，名称为`x_bucket`，标签为`{le="y"}`（其中`y`为桶的上限）。 64 | - 直方图必须有一个`{l ="+Inf"}`的存储桶。 其值必须与`x_count`的值相同。 65 | - 直方图的桶和摘要的分位数必须以其标签值的递增数字顺序出现（分别对于`le`或`quantile`标签）。 66 | 67 | ##### 1.3 文本格式例子 68 | 下面是一个完整的Prometheus度量标准展示示例，包括注释，`HELP`和`TYPE`表达式，直方图，摘要，字符转义示例等。 69 | ``` 70 | # HELP http_requests_total The total number of HTTP requests. 71 | # TYPE http_requests_total counter 72 | http_requests_total{method="post",code="200"} 1027 1395066363000 73 | http_requests_total{method="post",code="400"} 3 1395066363000 74 | 75 | # Escaping in label values: 76 | msdos_file_access_time_seconds{path="C:\\DIR\\FILE.TXT",error="Cannot find file:\n\"FILE.TXT\""} 1.458255915e9 77 | 78 | # Minimalistic line: 79 | metric_without_timestamp_and_labels 12.47 80 | 81 | # A weird metric from before the epoch: 82 | something_weird{problem="division by zero"} +Inf -3982045 83 | 84 | # A histogram, which has a pretty complex representation in the text format: 85 | # HELP http_request_duration_seconds A histogram of the request duration. 86 | # TYPE http_request_duration_seconds histogram 87 | http_request_duration_seconds_bucket{le="0.05"} 24054 88 | http_request_duration_seconds_bucket{le="0.1"} 33444 89 | http_request_duration_seconds_bucket{le="0.2"} 100392 90 | http_request_duration_seconds_bucket{le="0.5"} 129389 91 | http_request_duration_seconds_bucket{le="1"} 133988 92 | http_request_duration_seconds_bucket{le="+Inf"} 144320 93 | http_request_duration_seconds_sum 53423 94 | http_request_duration_seconds_count 144320 95 | 96 | # Finally a summary, which has a complex representation, too: 97 | # HELP rpc_duration_seconds A summary of the RPC duration in seconds. 98 | # TYPE rpc_duration_seconds summary 99 | rpc_duration_seconds{quantile="0.01"} 3102 100 | rpc_duration_seconds{quantile="0.05"} 3272 101 | rpc_duration_seconds{quantile="0.5"} 4773 102 | rpc_duration_seconds{quantile="0.9"} 9001 103 | rpc_duration_seconds{quantile="0.99"} 76656 104 | rpc_duration_seconds_sum 1.7560473e+07 105 | rpc_duration_seconds_count 2693 106 | ``` 107 | #### 二、历史版本 108 | 有关历史格式版本的详细信息，请参阅旧版[客户端数据展示格式](https://docs.google.com/document/d/1ZjyKiKxZV83VI9ZKAXRGKaUKK2BIWCT7oiGBKDBpjEY/edit)文档。 109 | -------------------------------------------------------------------------------- /instrumenting/Pushing_metrics.md: -------------------------------------------------------------------------------- 1 | [Pushgateway](https://github.com/prometheus/pushgateway)允许您将时间序列从[短期服务级批处理job](https://prometheus.io/docs/practices/pushing/)推送到Prometheus可以抓取的中间job。 结合Prometheus简单的基于文本的展示格式，这使得即使没有客户端库的shell脚本也很容易。 2 | 3 | - 有关使用Pushgateway和从Unix shell使用的更多信息，请参阅项目的[README.md](https://github.com/prometheus/pushgateway/blob/master/README.md)。 4 | 5 | - 要从Java中使用，请参阅[PushGateway](https://prometheus.github.io/client_java/io/prometheus/client/exporter/PushGateway.html)类。 6 | 7 | - 要在Go中使用，请参阅[Push](https://godoc.org/github.com/prometheus/client_golang/prometheus/push#Pusher.Push)和[Add](https://godoc.org/github.com/prometheus/client_golang/prometheus/push#Pusher.Add)方法。 8 | 9 | - 要在Python中使用，请参阅导出到[Pushgateway](https://github.com/prometheus/client_python#exporting-to-a-pushgateway)。 10 | 11 | - 要从Ruby使用，请参阅[Pushgateway文档](https://github.com/prometheus/client_ruby#pushgateway)。 12 | - 要了解在Prometheus项目之外维护的[客户端库](https://prometheus.io/docs/instrumenting/clientlibs/)的Pushgateway支持，请参阅其各自的文档。 13 | 14 | -------------------------------------------------------------------------------- /instrumenting/README.md: -------------------------------------------------------------------------------- 1 | 译文：https://prometheus.io/docs/instrumenting/clientlibs/ 2 | -------------------------------------------------------------------------------- /instrumenting/Writing_client_libaries.md: -------------------------------------------------------------------------------- 1 | 本文档介绍了Prometheus客户端库应提供的功能和API，旨在实现库之间的一致性，简化易用用例，避免提供可能导致用户走错路的功能。 2 | 3 | 在撰写本文时已经支持了[10种语言](https://prometheus.io/docs/instrumenting/clientlibs/)，因此我们现在已经很好地理解了如何编写客户端。 这些指南旨在帮助新客户端库的作者生成良好的库。 4 | 5 | ##### 一、Conventions约定 6 | MUST/MUST NOT/SHOULD/SHOULD NOT/MAY具有给出的含义在[https://www.ietf.org/rfc/rfc2119.txt](https://www.ietf.org/rfc/rfc2119.txt) 7 | 8 | 此外，ENCOURAGED意味着某个功能对于库来说是理想的，但如果它不存在则可以。 换句话说，一个很好的。 9 | 10 | 记住下面的几点： 11 | - 利用每种语言的功能。 12 | - 常用用例应该很简单 13 | - 做事情正确方式是简单的方法 14 | - 更复杂的例子应该是可能的 15 | 16 | 常用用例（有序）： 17 | - 没有标签的Counters在库/应用程序之间传播 18 | - Summaries/Histograms的时序功能/代码块 19 | - Gauges跟踪事情的当前状态 20 | - 批量任务监控 21 | 22 | ##### 二、总体结构 23 | 必须将客户端编写为内部回调。客户通常应该遵循这里描述的结构。 24 | 25 | 关键类是`Collector`。有一个方法（通常称为`collect`），返回零个或多个指标及其样本。`Collector`在`CollectorRegistry`注册。通过将`CollectorRegistry`传递给`class/method/function``bridge`来公开数据，该类以Prometheus支持的格式返回指标。每次抓取`CollectorRegistry`时，它都必须回调每个`Collector`的`collect`方法。 26 | 27 | 大多数用户与之交互的界面是`Counter`，`Gauge`，`Summary`和`Histogram` Collectors。这些代表一个度量标准，应涵盖用户正在使用自己的代码的绝大多数用例。 28 | 29 | 更高级的用例（例如从另一个监视/检测系统代理）需要编写自定义`Collector`。有人可能还想编写一个`bridge`，它采用`CollectorRegistry`并以不同监控/仪表系统理解的格式生成数据，从而允许用户只需考虑一个仪器系统。 30 | 31 | `CollectorRegistry`应该提供`register()/unregister()`函数，并且应该允许收集器注册到多个`CollectorRegistrys`。 32 | 33 | 客户端库必须是线程安全的。 34 | 35 | 对于诸如C的非OO语言，客户端库应该尽可能地遵循这种结构的精神。 36 | 37 | ###### 2.1 命名 38 | 客户端库应该遵循本文档中提到的`function/method/class`，记住它们所使用的语言的命名约定。例如，`set_to_current_time()`适用于方法名称Python，但在Go中`SetToCurrentTime()`更好，`setToCurrentTime()`是Java中的约定。 如果名称因技术原因而不同（例如，不允许函数重载），文档/帮助字符串应该将用户指向其他名称。 39 | 40 | 库不得提供与此处给出的名称相同或相似的函数/方法/类，但具有不同的语义。 41 | 42 | ##### 三、Metrics 43 | `Counter`、`Gauge`、`Summary`和`Histogram`[度量指标类型](https://prometheus.io/docs/concepts/metric_types/)是最主要的接口。 44 | 45 | `Counter`和`Gauge`必须是客户库的一部分。`Summary`和`Histogram`至少被提供一个。 46 | 47 | 这些应该主要用作文件静态变量，即在与它们正在检测的代码相同的文件中定义的全局变量。客户端库应该启用它。常见的用例是整体编写一段代码，而不是在一个对象实例的上下文中编写代码。用户不必担心在他们的代码中管理他们的指标，客户端库应该为他们做这些（如果没有，用户将在库周围编写一个包装器以使其“更容易” - 这很少倾向于好吧）。 48 | 49 | 必须有一个默认的`CollectorRegistry`，默认情况下，标准指标必须隐式注册到它中，而不需要用户进行任何特殊工作。必须有一种方法可以将指标注册到默认的`CollectorRegistry`，以便在批处理作业和单元测试中使用。定制收藏家也应该遵循这一点。 50 | 51 | 究竟应该如何创建指标因语言而异。对于某些人（Java，Go），构建器方法是最好的，而对于其他人（Python），函数参数足够丰富，可以在一次调用中完成。 52 | 53 | 例如，在Java Simpleclient中，我们有： 54 | ```Java 55 | class YourClass { 56 | static final Counter requests = Counter.build() 57 | .name("requests_total") 58 | .help("Requests.").register(); 59 | } 60 | ``` 61 | 62 | 这将使用默认的`CollectorRegistry`注册请求。 通过调用`build()`而不是`register()`，度量标准将不会被注册（方便单元测试），您还可以将`CollectorRegistry`传递给`register()`（便于批处理作业）。 63 | 64 | ###### 3.1 Counter 65 | [`Counter`](https://prometheus.io/docs/concepts/metric_types/#counter)是一个单调递增的计数器。它不允许counter值下降，但是它可以被重置为0（例如：客户端服务重启）。 66 | 67 | 一个counter必须有以下方法： 68 | - `inc()`: 增量为1. 69 | - `inc(double v)`: 增加给定值v。必须检查v>=0。 70 | 71 | 一个`Counter`鼓励有： 72 | 73 | 一种计算在给定代码段中抛出/引发异常的方法，以及可选的仅某些类型的异常。 这是Python中的count_exceptions。 74 | 75 | 计数器必须从0开始。 76 | 77 | ###### 3.2 Gauge 78 | [`Gauge`](https://prometheus.io/docs/concepts/metric_types/#gauge)表示一个可以上下波动的值。 79 | 80 | gauge必须有以下的方法： 81 | - `inc()`: 每次增加1 82 | - `inc(double v)`: 每次增加给定值v 83 | - `dec()`: 每次减少1 84 | - `dec(double v)`: 每次减少给定值v 85 | - `set(double v)`: 设置gauge值成v 86 | 87 | Gauges值必须从0开始，你可以为给定的量表提供一种方法，以不同的数字开始。 88 | 89 | gauge应该有以下方法： 90 | - `set_to_current_time()`: 将gauge设置为当前的unix时间（以秒为单位）。 91 | 92 | gauge被建议有： 93 | 一种跟踪某些代码/功能中正在进行的请求的方法。 这是Python中的`track_inprogress`。 94 | 95 | 一种为一段代码计时并将仪表设置为其持续时间的方法，以秒为单位。 这对批处理作业很有用。 这是Java中的`startTimer/setDuration`和Python中的`time()`装饰器/上下文管理器。 这应该与`Summary/Histogram`中的模式匹配（尽管是`set()`而不是`observe()`）。 96 | 97 | ###### 3.3 Summary 98 | [`Summary`](https://prometheus.io/docs/concepts/metric_types/#summary)通过时间滑动窗口抽样观察（通常是要求持续时间），并提供对其分布、频率和总和的即时观察。 99 | 100 | `Summary`绝不允许用户将“quantile”设置为标签名称，因为这在内部用于指定摘要分位数。 一个`Summary`是ENCOURAGED提供分位数作为出口，虽然这些不能汇总，往往很慢。 总结必须允许没有分位数，因为`_count/_sum`非常有用，这必须是默认值。 101 | 102 | `Summary`必须具有以下方法： 103 | 104 | - `observe(double v)`：观察给定量 105 | 106 | `Summary`应该有以下方法： 107 | 108 | 一些方法可以在几秒钟内为用户计时。 在Python中，这是`time()`装饰器/上下文管理器。 在Java中，这是`startTimer/observeDuration`。 绝不能提供秒以外的单位（如果用户想要其他东西，他们可以手工完成）。 这应该遵循与`Gauge/Histogram`相同的模式。 109 | 110 | `Summary``_count/_sum`必须从0开始。 111 | 112 | ###### 3.4 Histogram 113 | [`Histogram`](https://prometheus.io/docs/concepts/metric_types/#histogram)允许可聚合的事件分布，例如请求延迟。 这是每个桶的核心。 114 | 115 | `Histogram`绝不允许`le`作为用户设置标签，因为`le`在内部用于指定存储桶。 116 | 117 | `Histogram`必须提供一种手动选择存储桶的方法。应该提供以`linear(start, width, count)`和`exponential(start, factor, count)`方式设置桶的方法。计数必须排除`+Inf`桶。 118 | 119 | `Histogram`应该与其他客户端库具有相同的默认存储桶。创建度量标准后，不得更改存储桶。 120 | 121 | `Histogram`必须有以下方法： 122 | 123 | - `observe(double v)`：观察给定量 124 | 125 | `Histogram`应该有以下方法： 126 | 127 | 一些方法可以在几秒钟内为用户计时。在Python中，这是`time()`装饰器/上下文管理器。在Java中，这是`startTimer/observeDuration`。绝不能提供秒以外的单位（如果用户想要其他东西，他们可以手工完成）。这应该遵循与`Gauge/Summary`相同的模式。 128 | 129 | `Histogram``_count/_sum`和桶必须从0开始。 130 | 131 | 进一步的指标考虑 132 | 133 | 除了上面记录的对于给定语言有意义的指标之外，还提供额外的功能，这是ENCOURAGED。 134 | 135 | 如果有一个常见的用例，你可以做得更简单然后去做，只要它不会鼓励不良行为（例如次优的度量/标签布局，或在客户端进行计算）。 136 | 137 | ###### 3.5 标签 138 | 标签是普罗米修斯[最强大的方面](https://prometheus.io/docs/practices/instrumentation/#use-labels)之一，但很容易[被滥用](https://prometheus.io/docs/practices/instrumentation/#do-not-overuse-labels)。因此，客户端库必须非常小心地向用户提供标签。 139 | 140 | 在任何情况下，客户端库都不允许用户为`Gauge/Counter/Summary/Histogram`或库提供的任何其他`Collector`的相同度量标准指定不同的标签名称。 141 | 142 | 自定义收集器中的度量标准几乎总是具有一致的标签名称。由于仍然存在罕见但有效的用例，但事实并非如此，客户端库不应对此进行验证。 143 | 144 | 虽然标签功能强大，但大多数指标都没有标签。因此，API应该允许标签但不支配它。 145 | 146 | 客户端库必须允许在`Gauge/Counter/Summary/Histogram`创建时指定标签名称列表。客户端库应该支持任意数量的标签名称。客户端库必须验证标签名称是否符合记录的要求。 147 | 148 | 提供对度量标注维度的访问的一般方法是使用`labels()`方法，该方法获取标签值列表或从标签名称到标签值的映射并返回“Child”。然后可以在Child上调用通常的`.inc()/.dec()/.observe()`等方法。 149 | 150 | `labels()`返回的子项应该由用户缓存，以避免再次查找 - 这在延迟关键代码中很重要。 151 | 152 | 带标签的度量标准应该支持一个`remove()`方法，该方法具有与`labels()`相同的签名，它将从不再导出它的度量中删除Child，以及一个从度量中删除所有Children的`clear()`方法。这些无效的缓存儿童。 153 | 154 | 应该是一种使用默认值初始化给定Child的方法，通常只是调用`labels()`。必须始终初始化没有标签的度量标准以避免缺少度量标准的问题。 155 | 156 | ###### 3.6 度量指标名称 157 | 度量标准名称必须遵循规范。 与标签名称一样，必须满足使用`Gauge/Counter/Summary/Histogram`以及随库提供的任何其他Collector。 158 | 159 | 许多客户端库提供了三个部分的名称设置：`namespace_subsystem_name`，其中只有`name`是必需的。 160 | 161 | 除非自定义收集器从其他检测/监视系统进行代理，否则不得禁止动态/生成的度量标准名称或度量标准名称的子部分。 生成/动态度量标准名称是您应该使用标签的标志。 162 | 163 | ###### 3.7 度量指标描述和帮助 164 | `Gauge/Counter/Summary/Histogram`必须要求提供度量标准描述/帮助。 165 | 166 | 随客户端库提供的任何自定义收集器必须具有其指标的描述/帮助。 167 | 168 | 建议将其作为强制性参数，但不要检查它是否具有一定的长度，好像有人真的不想写文档，否则我们不会说服它们。 图书馆提供的收藏家（实际上我们可以在生态系统中的任何地方）应该有很好的度量描述，以身作则。 169 | 170 | ##### 四、导出 171 | 172 | 客户必须实现博览会格式文档中概述的基于文本的[导出格式](https://prometheus.io/docs/instrumenting/exposition_formats/)。 173 | 174 | 如果可以在没有显着资源成本的情况下实现暴露度量的可重现顺序是ENCOURAGED（特别是对于人类可读格式）。 175 | 176 | ##### 五、标准化和运行时收集器 177 | 178 | 客户端库应该提供标准导出的功能，如下所示。 179 | 180 | 这些应该作为自定义收集器实现，并默认注册在默认的CollectorRegistry上。 应该有一种方法来禁用它们，因为有一些非常小的用例会妨碍它们。 181 | 182 | ###### 5.1 处理度量指标 183 | 这些导出应该有前缀`process_`。 如果语言或运行时没有公开其中一个变量，那么它就不会导出它。 所有内存值，以字节为单位，所有时间均为`unixtime/seconds`。 184 | 185 | | 度量指标名称 | 含义 | 单位 | 186 | | --------------------------| :-------------------------:| ---------:| 187 | | process_cpu_seconds_total | 用户和系统CPU花费的时间 | 秒 | 188 | | process_open_fds | 打开的文件描述符数量 | 文件描述符| 189 | | process_max_fds | 打开描述符最大值 | 文件描述符| 190 | | process_virtual_memory_bytes| 虚拟内存大小 | 字节| 191 | | process_virtual_memory_max_bytes| 最大可用虚拟内存量（以字节为单位） | 字节| 192 | | process_resident_memory_bytes| 驻留内存大小|字节| 193 | | process_heap_bytes | 进程head堆大小| 字节| 194 | | process_start_time_seconds| unix时间 | 秒| 195 | 196 | ###### 5.2 运行时度量指标 197 | 此外，还鼓励客户端库提供其语言运行时（例如垃圾收集统计信息）的度量标准，并提供适当的前缀，如`go_`，`hostspot_`等。 198 | ##### 六、单元测试 199 | 客户端库应该有单元测试，涵盖核心工具库和博览会。 200 | 201 | 客户端库鼓励提供方便用户对其使用仪器代码进行单元测试的方法。 例如，Python中的`CollectorRegistry.get_sample_value`。 202 | 203 | ##### 七、包和依赖 204 | 理想情况下，客户端库可以包含在任何应用程序中，以便在不破坏应用程序的情况下添加一些检测。 205 | 206 | 因此，在向客户端库添加依赖项时，建议谨慎。 例如，如果添加使用Prometheus客户端的库，该客户端需要x.y版本的库但应用程序在其他地方使用x.z，那么这会对应用程序产生负面影响吗？ 207 | 208 | 建议在可能出现这种情况时，将核心工具与给定格式的度量的桥梁/展示分开。 例如，Java simpleclient `simpleclient`模块没有依赖关系，`simpleclient_servlet`具有HTTP位。 209 | 210 | ##### 八、性能考虑 211 | 由于客户端库必须是线程安全的，因此需要某种形式的并发控制，并且必须考虑多核机器和应用程序的性能。 212 | 213 | 根据我们的经验，效果最差的是互斥体。 214 | 215 | 处理器原子指令往往位于中间，并且通常是可接受的。 216 | 217 | 避免不同CPU改变相同RAM的方法最有效，例如Java的simpleclient中的DoubleAdder。但是有记忆费用。 218 | 219 | 如上所述，`labels()`的结果应该是可缓存的。倾向于使用标签返回度量标准的并发映射往往相对较慢。没有标签的特殊套管指标可以避免`labels()`- 像查找一样可以提供很多帮助。 220 | 221 | 度量标准应当在递增/递减/设置等时避免阻塞，因为在刮擦正在进行时整个应用程序被阻止是不可取的。 222 | 223 | 主要仪器操作（包括标签）的基准测试是鼓励的。 224 | 225 | 在进行博览会时，应牢记资源消耗，特别是RAM。考虑通过流式传输结果减少内存占用量，并可能限制并发擦除次数。 226 | -------------------------------------------------------------------------------- /instrumenting/Writing_exporters.md: -------------------------------------------------------------------------------- 1 | 如果您正在检测自己的代码，则应遵循如何使用[Prometheus客户端库检测代码的一般规则](https://prometheus.io/docs/practices/instrumentation/)。 从其他监控或仪表系统中获取指标时，事情往往不是那么黑白。 2 | 3 | 本文档包含编写导出器或自定义收集器时应考虑的事项。 所涉及的理论也将对那些从事直接仪器工作的人感兴趣。 4 | 5 | 如果您正在撰写出口商并且对此处的任何内容不清楚，请通过IRC（Freenode上的#prometheus）或[邮件列表](https://prometheus.io/community/)与我们联系。 6 | 7 | ##### 一、可维护性和Purity 8 | 在编写导出器时，您需要做出的主要决定是您愿意投入多少工作来获得完美的指标。 9 | 10 | 如果有问题的系统只有少数几乎没有变化的指标，那么让一切都完美是一个简单的选择，[HAProxy exporter](https://github.com/prometheus/haproxy_exporter)就是一个很好的例子。 11 | 12 | 另一方面，如果您在系统有数百个经常随新版本更改的指标时试图让事情变得完美，那么您已经为自己签了很多正在进行的工作。 MySQL出口商正处于这一端。 13 | 14 | [node exporter](https://github.com/prometheus/node_exporter)是这些的混合，复杂性因模块而异。 例如，`mdadm`收集器手工解析文件并公开专门为该收集器创建的度量标准，因此我们也可以正确地获取指标。 对于`meminfo`收集器，结果因内核版本而异，因此我们最终只进行了足够的转换以创建有效的度量标准。 15 | 16 | ##### 二、配置 17 | 使用应用程序时，您应该瞄准一个导出器，除了告诉应用程序在哪里之外，用户不需要自定义配置。您可能还需要提供过滤掉某些指标的功能，如果它们在大型设置上过于精细和昂贵，例如[HAProxy exporter](https://github.com/prometheus/haproxy_exporter)允许过滤每服务器统计数据。同样，默认情况下可能会禁用昂贵的指标。 18 | 19 | 在使用其他监控系统，框架和协议时，您通常需要提供额外的配置或自定义，以生成适合Prometheus的指标。在最佳情况下，监控系统具有与Prometheus类似的足够数据模型，您可以自动确定如何转换指标。这是[Cloudwatch](https://github.com/prometheus/cloudwatch_exporter)，[SNMP](https://github.com/prometheus/snmp_exporter)和[collectd](https://github.com/prometheus/collectd_exporter)的情况。最多，我们需要能够让用户选择他们想要提取的指标。 20 | 21 | 在其他情况下，系统的指标完全不标准，具体取决于系统和底层应用程序的使用情况。在这种情况下，用户必须告诉我们如何转换指标。 [JMX exporter](https://github.com/prometheus/jmx_exporter)是这里最糟糕的攻击者，[Graphite](https://github.com/prometheus/graphite_exporter)和[StatsD](https://github.com/prometheus/statsd_exporter)导出器也需要配置来提取标签。 22 | 23 | 确保导出器在没有配置的情况下开箱即用，并根据需要提供一系列用于转换的示例配置。 24 | 25 | YAML是标准的Prometheus配置格式，默认情况下所有配置都应使用YAML。 26 | 27 | ##### 三、度量指标 28 | ###### 3.1 命名 29 | 遵循[度量指标最佳实践](https://prometheus.io/docs/practices/naming) 30 | 31 | 通常，度量标准名称应该允许熟悉Prometheus但不熟悉特定系统的人对度量标准的含义做出很好的猜测。名为`http_requests_total`的度量标准不是非常有用 - 这些是在它们进入时，在某些过滤器中还是在它们到达用户代码时进行测量的？而`requests_total`则更糟糕，请求的类型是什么？ 32 | 33 | 使用直接检测，给定度量应该只存在于一个文件中。因此，在出口商和收集者中，度量标准应该适用于一个子系统并相应地命名。 34 | 35 | 除非编写自定义收集器或导出器，否则不应以程序方式生成度量标准名称。 36 | 37 | 应用程序的度量标准名称通常应以导出器名称为前缀，例如： `haproxy_up`。 38 | 39 | 度量标准必须使用基本单位（例如秒，字节），并将它们转换为对图形工具更具可读性的东西。无论您最终使用哪些单位，度量标准名称中的单位必须与使用的单位相匹配。同样，暴露比率，而不是百分比。更好的是，为比率的两个组成部分中的每一个指定一个计数器。 40 | 41 | 度量标准名称不应包含与其一起导出的标签，例如`by_type`，因为如果标签聚合在一起就没有意义。 42 | 43 | 一个例外是当您通过多个指标导出具有不同标签的相同数据时，在这种情况下，这通常是区分它们的最佳方式。对于直接检测，只有在导出单个度量标准时才会出现这种情况，并且所有标记都具有过高的基数。 44 | 45 | Prometheus指标和标签名称以`snake_cas`e编写。将`camelCase`转换为`snake_case`是可取的，尽管这样做自动并不总能为`myTCPExample`或`isNaN`之类的东西产生好的结果，所以有时候最好将它们保持原样。 46 | 47 | 公开的度量标准不应包含冒号，这些是为聚合时使用的用户定义的记录规则保留的。 48 | 49 | 只有`[a-zA-Z0-9_]`在度量标准名称中有效，任何其他字符都应该清理为下划线。 50 | 51 | `_sum`，`_count`，`_bucket`和`_total`后缀由Summaries，Histograms和Counters使用。除非您正在生产其中之一，否则请避免使用这些后缀。 52 | 53 | `_total`是计数器的约定，如果您使用的是COUNTER类型，则应使用它。 54 | 55 | `process_`和`scrape_`前缀是保留的。如果它们遵循匹配的语义，可以在这些上添加自己的前缀。例如，Prometheus `scrape_duration_seconds`表示刮除了多长时间，最好还有一个以导出器为中心的指标，例如： `jmx_scrape_duration_seconds`，说明特定出口商花了多长时间做这件事。对于可以访问PID的进程统计数据，Go和Python都提供了可以为您处理此问题的收集器。一个很好的例子是HAProxy导出器。 56 | 57 | 如果您有成功的请求计数和失败的请求计数，则公开此请求的最佳方式是作为总请求的一个度量标准和针对失败请求的另一个度量标准。这使得计算故障率变得容易。不要将一个度量标准与失败或成功标签一起使用。类似地，对于缓存的命中或未命中，最好有一个指标用于总计，另一个指标用于命中。 58 | 59 | 考虑使用监控的人员对度量标准名称执行代码或Web搜索的可能性。如果这些名称非常完善且不太可能在人们习惯于这些名称的领域之外使用，例如SNMP和网络工程师，那么将它们保留为原样可能是一个好主意。此逻辑不适用于所有导出器，例如，MySQL导出器度量标准可能被各种人使用，而不仅仅是DBA。具有原始名称的HELP字符串可以提供与使用原始名称相同的大部分好处。 60 | 61 | ###### 3.2 labels 62 | 阅读关labels标签的建议,详见[advice](https://prometheus.io/docs/practices/instrumentation/#things-to-watch-out-for) 63 | 64 | 避免`type`作为标签名称，它太通用，通常没有意义。您还应该尝试尽可能避免可能与目标标签冲突的名称，例如`region`，`zone`，`cluster`，`availability_zone`，`az`，`datacenter`，`dc`，`owner`，`customer`，`stage`，`service`，`environment`和`env`。但是，如果这是应用程序调用某些资源的内容，最好不要通过重命名来引起混淆。 65 | 66 | 避免将事物放入一个指标中的诱惑，因为它们共享一个前缀。除非您确定某些指标有意义，否则多个指标更安全。 67 | 68 | 标签`le`对于直方图具有特殊含义，对于`Summaries`具有`quantile `。一般避免这些标签。 69 | 70 | 读/写和发送/接收最好作为单独的指标，而不是标签。这通常是因为您一次只关心其中一个，并且更容易以这种方式使用它们。 71 | 72 | 经验法则是，在求和或平均时，一个度量应该是有意义的。还有另一个案例出现在导出器中，而这些数据基本上是表格式的，否则将要求用户对度量标准名称的正则表达式可用。考虑一下主板上的电压传感器，而在它们之间进行数学计算是没有意义的，将它们放在一个指标中而不是每个传感器有一个指标是有意义的。度量中的所有值应该（几乎）总是具有相同的单位，例如考虑风扇速度是否与电压混合在一起，并且您无法自动分离它们。 73 | 74 | 不要做这些： 75 | ``` 76 | my_metric{label=a} 1 77 | my_metric{label=b} 6 78 | **my_metric{label=total} 7** 79 | ``` 80 | 81 | 或者 82 | ``` 83 | my_metric{label=a} 1 84 | my_metric{label=b} 6 85 | **my_metric{} 7** 86 | ``` 87 | 88 | 对于那些对你的指标进行`sum()`的人来说，前者会中断，后者会破坏总和并且很难处理。一些客户端库（例如Go）将主动尝试阻止您在自定义收集器中执行后者，并且所有客户端库都应该阻止您使用直接检测来执行后者。永远不要做其中任何一个，而是依靠Prometheus聚合。 89 | 90 | 如果您的监控公开这样的总数，则减去总数。如果由于某种原因必须保留它，例如总数包括不单独计算的内容，请使用不同的度量标准名称。 91 | 92 | 仪表标签应该是最小的，每个额外的标签是用户在编写PromQL时需要考虑的标签。因此，避免使用可以移除的仪器标签而不影响时间序列的唯一性。可以通过信息度量添加有关度量标准的其他信息，例如，请参阅下面的如何处理版本号。 93 | 94 | 但是，在某些情况下，预计几乎所有度量标准的用户都需要其他信息。如果是这样，添加非唯一标签而不是信息指标是正确的解决方案。例如，mysqld_exporter的`mysqld_perf_schema_events_statements_total`的摘要标签是完整查询模式的散列，足以实现唯一性。但是，如果没有人类可读的`digest_text`标签，它几乎没用，对于长查询，它只包含查询模式的开头，因此不是唯一的。因此，我们最终得到了人类的`digest_text`标签和唯一性的摘要标签。 95 | 96 | ###### 3.3 目标标签，非静电抓取 97 | 如果您发现自己想要将相同的标签应用于所有指标，请停止。 98 | 99 | 通常有两种情况出现。 100 | 101 | 第一个是针对某些标签，对于诸如软件的版本号之类的指标而言是有用的。相反，请使用https://www.robustperception.io/how-to-have-labels-for-machine-roles/中描述的方法。 102 | 103 | 第二种情况是标签实际上是目标标签。这些是区域，群集名称等等，它们来自您的基础结构设置而不是应用程序本身。应用程序并不是说它适合您的标签分类标准，而是运行Prometheus服务器进行配置的人员，监视同一应用程序的不同人员可能会给它指定不同的名称。 104 | 105 | 因此，通过您正在使用的任何服务发现，这些标签属于普罗米修斯的刮擦配置。也可以在这里应用机器角色的概念，因为它可能是至少有些人抓取它的有用信息。。 106 | 107 | ###### 3.4 类型 108 | 您应该尝试将指标的类型与Prometheus类型相匹配。 这通常意味着计数器和仪表。 `_coun`t和`_sum`的摘要也比较常见，有时你会看到分位数。 直方图很少见，如果您遇到直方图，请记住曝光格式会显示累积值。 109 | 110 | 通常情况下，指标的类型并不明显，特别是如果您自动处理一组指标。 一般来说，UNTYPED是一个安全的默认值。 111 | 112 | 计数器不能下降，所以如果你有一个来自另一个可以递减的仪器系统的计数器类型，例如Dropwizard指标那么它不是一个计数器，它就是一个指标。 UNTYPED可能是在那里使用的最佳类型，因为如果将GAUGE用作计数器，它将会产生误导。 113 | 114 | ###### 3.5 帮助文档 115 | 当您转换指标时，用户能够追溯到原始内容以及导致该转换的规则正在发挥作用。 将收集器或导出器的名称，应用的任何规则的ID以及原始度量的名称和详细信息放入帮助字符串中将极大地帮助用户。 116 | 117 | 普罗米修斯不喜欢一个具有不同帮助字符串的指标。 如果您正在制作其他许多指标，请选择其中一个指标放入帮助字符串。 118 | 119 | 例如，SNMP导出器使用OID，JMX导出器放入示例mBean名称。 HAProxy导出器具有手写字符串。 节点导出器还有各种各样的示例 120 | 121 | ###### 3.6 放弃无用的统计数据 122 | 一些仪器系统暴露1m，5m，15m速率，自应用程序启动以来的平均速率（例如，这些在Dropwizard度量中称为`mean`）以及最小值，最大值和标准偏差。 123 | 124 | 这些都应该被删除，因为它们不是很有用并且增加了混乱。 普罗米修斯可以自己计算费率，通常更准确，因为暴露的平均值通常呈指数衰减。 你不知道计算最小值或最大值的时间，标准偏差在统计上是无用的，如果你需要计算它，你总是可以暴露平方和，`_sum`和`_count`。 125 | 126 | 分位数有相关问题，您可以选择删除它们或将它们放在摘要中。 127 | 128 | ###### 3.7 .字符串 129 | 许多监控系统没有标签，而是执行`my.class.path.mymetric.labelvalue1.labelvalue2.labelvalue3`之类的操作。 130 | 131 | Graphite和StatsD导出器共享一种使用小型配置语言转换这些内容的方法。 其他出口商也应该这样做。 转换目前仅在Go中实现，并且可以从被分解到单独的库中获益。。 132 | 133 | ##### 四、Collectors 134 | 为导出器实现收集器时，不应使用通常的直接检测方法，然后更新每个scrape上的度量标准。 135 | 136 | 而是每次创建新的指标。在Go中，这是使用`Update()`方法中的[MustNewConstMetric](https://godoc.org/github.com/prometheus/client_golang/prometheus#MustNewConstMetric)完成的。对于Python，请参阅https://github.com/prometheus/client_python#custom-collectors，对于Java，在collect方法中生成List ，请参阅[StandardExports.java](https://github.com/prometheus/client_java/blob/master/simpleclient_hotspot/src/main/java/io/prometheus/client/hotspot/StandardExports.java)以获取示例。 137 | 138 | 原因是双重的。首先，两个擦除可能同时发生，并且直接检测使用有效的文件级全局变量，因此您将获得竞争条件。其次，如果标签值消失，它仍然会被导出。 139 | 140 | 通过直接仪器检测出口商本身很好，例如传输的总字节数或导出器在所有擦除中执行的调用。对于黑盒出口商和SMNP出口商等出口商而言，这些出口商并未绑定到单个目标，这些出口商应仅在vanilla `/metrics`调用上公开，而不是在特定目标的scrape上公开。 141 | 142 | ###### 4.1 关于获取度量指标本身 143 | 有时，您希望导出与刮擦有关的指标，例如花费的时间或处理的记录数。 144 | 145 | 这些应该作为计量器公开，因为它们是关于事件，scrape和以导出器名称为前缀的度量标准名称，例如`jmx_scrape_duration_seconds`。 通常情况下会排除`_exporter`，如果导出器也可以用作收集器，那么一定要排除它。 146 | 147 | ###### 4.2 硬件，进程度量指标 148 | 许多系统（例如Elasticsearch）都会公开机器指标，例如CPU，内存和文件系统信息。 由于节点导出器在Prometheus生态系统中提供这些，因此应删除此类指标。 149 | 150 | 在Java世界中，许多检测框架都公开了进程级和JVM级统计信息，例如CPU和GC。 Java客户端和JMX导出器已经通过DefaultExports.java以首选形式包含这些，因此也应该删除它们。 151 | 152 | 与其他语言和框架类似。 153 | 154 | ##### 五、部署 155 | 每个导出器应该只监视一个实例应用程序，最好是位于同一台机器旁边。这意味着对于您运行的每个HAProxy，您都运行`haproxy_exporter`进程。对于具有Mesos工作程序的每台计算机，如果计算机同时具有两者，则在其上运行Mesos导出程序，并为主计算机运行另一个计算机。 156 | 157 | 这背后的理论是，对于直接仪器而言，这就是你正在做的事情，而我们正努力在其他布局中尽可能地接近它。这意味着所有服务发现都在Prometheus中完成，而不是在出口商中完成。这也有一个好处，即Prometheus具有允许用户使用blackbox导出器探测您的服务所需的目标信息。 158 | 159 | 有两个例外： 160 | 161 | 第一个是在应用程序旁边运行，您的监控完全没有意义。 SNMP，blackbox和IPMI导出器就是其中的主要示例。作为设备的IPMI和SNMP导出器通常是黑盒子，因此无法运行代码（尽管如果你可以在它们上运行节点导出器而不是更好），而黑盒子导出器你正在监视类似于DNS名称，也没有什么可以运行。在这种情况下，普罗米修斯仍然应该进行服务发现，并传递要刮的目标。有关示例，请参阅blackbox和SNMP导出器。 162 | 163 | 请注意，目前只能使用Go，Python和Java客户端库编写此类导出器。 164 | 165 | 第二个例外是你从一个系统的随机实例中提取一些统计数据而不关心你正在谈论哪一个。考虑一组MySQL副本，您希望针对数据运行一些业务查询，然后导出。让一个使用您通常的负载平衡方法与一个副本通信的导出器是最安全的方法。 166 | 167 | 当您使用master-election监视系统时，这不适用，在这种情况下，您应该单独监视每个实例并处理Prometheus中的“masterness”。这是因为并不总是只有一个主人，并且改变目标在普罗米修斯的脚下会导致奇怪。 168 | 169 | ###### 5.1 调度 170 | 只有当Prometheus擦除它们时才会从应用程序中提取度量标准，出口商不应该根据自己的计时器执行刮擦。 也就是说，所有擦除应该是同步的。 171 | 172 | 因此，您不应该在您公开的指标上设置时间戳，让普罗米修斯负责。 如果您认为需要时间戳，那么您可能需要使用Pushgateway。 173 | 174 | 如果度量标准的检索特别昂贵，即花费超过一分钟，则可以对其进行缓存。 这应该在`HELP`字符串中注明。 175 | 176 | Prometheus的默认刮擦超时为10秒。 如果您的导出程序可能超出此范围，则应在用户文档中明确说明。 177 | 178 | ###### 5.2 推送 179 | 某些应用程序和监视系统仅推送指标，例如StatsD，Graphite和collectd。 180 | 181 | 这里有两个考虑因素。 182 | 183 | 首先，你何时到期指标？收集和与Graphite交谈的事情都会定期导出，当它们停止时我们想要停止公开指标。 Collectd包含一个到期时间，所以我们使用它，Graphite不是，所以它是出口商的旗帜。 184 | 185 | StatsD有点不同，因为它处理的是事件而不是指标。最好的模型是在每个应用程序旁边运行一个导出器，并在应用程序重新启动时重新启动它们，以便清除状态。 186 | 187 | 其次，这类系统倾向于允许您的用户发送增量或原始计数器。您应该尽可能地依赖原始计数器，因为这是普通的普罗米修斯模型。 188 | 189 | 对于服务级别指标，例如服务级批处理作业，您应该让您的导出器进入Pushgateway并在事件发生后退出，而不是自己处理状态。对于实例级批量指标，尚无明确的模式。选项是滥用节点导出器的文本文件收集器，依赖于内存状态（可能最好，如果您不需要持续重新启动）或实现与文本文件收集器类似的功能。 190 | 191 | ###### 5.3 抓取失败 192 | 目前有两种模式用于失败的抓取，您正在与之交谈的应用程序没有响应或有其他问题。 193 | 194 | 第一种是返回5xx错误。 195 | 196 | 第二个是有一个 `myexporter_up`，例如 `haproxy_up`，值为0或1的变量，具体取决于刮擦是否有效。 197 | 198 | 后者是更好的地方，即使是一个失败的scrape，你仍然可以获得一些有用的指标，例如提供流程统计数据的HAProxy导出器。 前者对于用户来说更容易处理，因为按照通常的方式工作，尽管您无法区分导出器关闭和应用程序关闭。 199 | 200 | ###### 5.4 登录页面 201 | 如果访问`http://yourexporter/`有一个带有导出器名称的简单HTML页面，以及指向`/metrics`页面的链接，则对用户来说更好。 202 | 203 | ###### 5.5 端口 204 | 用户可能在同一台计算机上有许多导出器和Prometheus组件，因此为了使每个组件具有唯一的端口号。 205 | 206 | https://github.com/prometheus/prometheus/wiki/Default-port-allocations是我们跟踪它们的地方，这是可公开编辑的。 207 | 208 | 在开发出口商时，请随意抓住下一个免费端口号，最好在公开宣布之前。 如果您尚未准备好发布，请将您的用户名和WIP设置为好。 209 | 210 | 这是一个注册表，使我们的用户的生活更轻松，而不是致力于开发特定的出口商。 对于内部应用程序的导出器，我们建议使用默认端口分配范围之外的端口。 211 | 212 | 213 | ##### 六、发布 214 | 一旦您准备好向全世界宣布您的`exporter `，请通过电子邮件发送邮件列表并发送PR以将其添加到可用`exporter `[列表](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exporters.md)中。 215 | -------------------------------------------------------------------------------- /introductions/Comparison_to_alternatives.md: -------------------------------------------------------------------------------- 1 | ##### 一、Prometheus vs. Graphite 2 | ###### 1.1 范围 3 | Graphite专注于查询语言和图表特征的时间序列数据库。其他都需要依赖外部组件实现。 4 | 5 | Prometheus是一个基于时间序列数据的完整监控系统和趋势系统，包括内置和主动抓取、存储、查询、图表展示和报警功能。它懂得监控系统和趋势系统应该是什么样的（哪些目标机应该存在，哪些时间序列模型存在问题等等），并积极地试着找出故障。 6 | 7 | ###### 1.2 数据模型 8 | Graphite和Prometheus一样，存储时间序列数值样本。但是Prometheus的元数据模型更加丰富：Graphite的度量指标名称是由"."分隔符，隐式地编码多维度。而Prometheus度量指标是可以自定义名称的，并以key-value键值对的标签形式，成为度量指标的标签属性列表。并在此基础上，使用Prometheus查询语言可以轻松地进行过滤，分组和匹配操作。 9 | 10 | 进一步地，当Graphite与StatsD结合使用时，Graphite就只是对一个聚合数据的存储系统了，而不是把目标实例作为一个维度，并深入分析目标实例出现的各种问题。 11 | 12 | 例如：我们用Graphite/StatsD统计HTTP请求api-server服务的数量，前置条件：返回码是`500`，请求方法是`POST`，访问URL为`/tracks` , key如下所示： 13 | ``` 14 | stats.api-server.tracks.post.500 -> 93 15 | ``` 16 | 17 | 但是在Prometheus中同样的数据存储可能像下面一样(假设有三个api-server)： 18 | ``` 19 | api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance=""} -> 34 20 | api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance=""} -> 28 21 | api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance=""} -> 31 22 | ``` 23 | 24 | ###### 1.3 存储 25 | Graphite存储以[Whisper](http://graphite.readthedocs.org/en/latest/whisper.html)方式把时间序列数据存储到本地磁盘，这种数据存储格式是RRD格式数据库，它期望样本能够定期到达。任何时间序列在一个单独的文件中存储，一段时间后新采集的样本会覆盖老数据。 26 | 27 | Prometheus也为每一个时间序列创建了一个本地文件，但是它允许时间序列以任意时间到达。新采集的样本被简单地追加到文件尾部，老数据可以任意长的时间保留。Prometheus对于短生命周期、且经常变化的时间序列集也可以表现得很好。 28 | 29 | ###### 1.4 总结 30 | 31 | Prometheus提供了一个丰富的数据模型和查询语言，而且更加容易地运行和集成到你的环境中。如果你想要一个可以长期保留历史数据的集群解决方案，Graphite可能是一个更好的选择。 32 | 33 | ##### 二、Prometheus vs. InfluxDB 34 | InfluxDB是一个开源的时间序列数据库，它的商业版本具有可扩展和集群化的特性。在Prometheus刚刚开始开发时，InfluxDB项目已经发布了近一年时间。但是这两款产品还是有很大的不同之处，这两个系统也有一些略有不同的应用小场景。 35 | 36 | ###### 2.1 范围 37 | 公平起见，我们必须把InfluxDB和Kapacitor结合起来，与Prometheus和Prometheus的报警管理工具比较。 38 | 39 | Graphite与Prometheus的范围差异，同样适用于InfluxDB本身。此外InfluxDB提供了连续查询，和Prometheus的记录规则一样。 40 | 41 | Kapacitor的作用范围相当于，Prometheus的记录规则、告警规则和警告通知功能的结合。Prometheus提供了一个更加丰富地用于图表化和警告的查询语言，Prometheus告警器还提供了分组、重复数据删除和静默功能(silencing functionality)。 42 | 43 | ###### 2.2 数据模型/存储 44 | 和Prometheus一样，InfluxDB数据模型采用的标签也是键值对形式，被称为`tags`。而且InfluxDB有第二级标签，被称为`fields`，它被更多地限制使用。InfluxDB支持高达纳秒级的时间戳，以及`float64`、`int64`、`bool`和`string`的数据类型。相反地，Prometheus仅仅支持`float64`的数据类型，`strings`和`millisecond `只能小范围地支持。 45 | 46 | InfluxDB使用变种的日志结构合并树结构来存储预写日志，并按时间分片。这比Prometheus的文件追加更适合事件记录 47 | [Logs and Metrics and Graphs, Oh My!](https://blog.raintank.io/logs-and-metrics-and-graphs-oh-my)描述了事件日志和度量指标记录的不同 48 | 49 | ###### 2.3 框架 50 | Prometheus服务器彼此独立运行，其核心功能仅依赖于本地存储：抓取、规则处理和警报。influxDB的开源版本类似。 51 | 52 | InfluxDB的商业版本具有存储和查询的分布式版本,存储和查询由集群中的节点同时处理。 53 | 54 | 这意味着商业版本的InfluxDB更加容易的水平扩展，同时也表示你必须从一开始就要管理分布式存储系统的复杂性。而Prometheus运行非常简单，而且在某些时候，你需要在可扩展性边界（如产品，服务，数据中心或者类似方面）明确分片服务器。单Prometheus服务也可以为您提供更好的可靠性和故障隔离。 55 | 56 | Kapacitor对规则、警告和通知当前还没有内置/冗余选项。相反地，通过运行Prometheus的冗余副本和使用警告管理器的高可用模式提供了冗余选项。Kapacitor通过用户手动水平切分能够被缩放，这点类似于Prometheus> 57 | 本身 58 | 59 | ###### 2.4 总结 60 | 在两个系统之间有许多相似点。都使用标签（tags/labels）有效地支持多维度量指标。都使用使用相同的压缩算法。都可扩展集成。都允许使用第三方进行监控系统的扩展，如：统计分析工具、自动化操作 61 | 62 | InfluxDB更好之处： 63 | - 使用事件日志 64 | - 商业版本提供的集群方案，对于长期的时间序列存储是非常不错的 65 | - 复制的数据最终一致性 66 | 67 | Prometheus更好之处： 68 | - 主要做度量指标监控 69 | - 更强大的查询语言，警告和通知功能 70 | - 图表和警告的高可靠性和稳定性 71 | 72 | InfluxDB是有一家商业公司按照开放核心模式运营，提供高级功能，如：集群是闭源的，托管和支持。Prometheus是一个完全开放和独立的项目，有许多公司和个人维护，其中也提供一些商业服务和支持。 73 | 74 | ##### 三、Prometheus vs. OpenTSDB 75 | [OpenTSDB](http://opentsdb.net/)是一个基于hadoop和Hbase的分布式时间序列数据库 76 | 77 | ###### 3.1 范围 78 | 和Graphite vs. Prometheus的范围一样 79 | 80 | ###### 3.2 数据模型 81 | OpenTSDB的数据模型几乎和Prometheus一样：时间序列由任意的`tags`键值对集合表示。所有的度量指标存放在一起，并限制度量指标的总数量大小。Prometheus和OpenTSDB有一些细微的差别，例如：Prometheus允许任意的标签字符，而OpenTSDB的tags命名有一定的限制.OpenTSDB缺乏灵活的查询语言支持，通过它提供的API只能简单地进行聚合和数学计算。 82 | 83 | ###### 3.3 存储 84 | OpenTSDB的存储由Hadoop和HBase实现的。这意味着水平扩展OpenTSDB是非常容易的，但是你必须接受集群的总体复杂性 85 | 86 | Prometheus初始运行非常简单，但是一旦超过单个节点的容量，就需要进行水平切分服务操作 87 | 88 | ###### 3.4 总结 89 | Prometheus提供了一个非常灵活且丰富的查询语言，能够支持更多的度量指标数量，组成整个监控系统的一部分。如果你对hadoop非常熟悉，并且对时间序列数据有长期的存储要求，OpenTSDB是一个不错的选择 90 | 91 | ##### 四、Prometheus vs. Nagios 92 | [Nagios](https://www.nagios.org/)是一款产生于90s年代的监控系统 93 | 94 | ###### 4.1 范围 95 | Nagios是基于脚本运行结果的警告系统，又称"运行结果检查"。有警告通知，但是没有分组、路由和重复数据删除功能。 96 | 97 | Nagios有大量的插件。例如：perfData插件抓取数据后写入到时间序列数据库（Graphite）或者使用NRPE在远程计算机上运行检查 98 | 99 | ###### 4.2 数据模型 100 | Nagios是基于主机的，每一台主机有一个或者多个服务。其中一个是check运行检查，但是没有标签和查询语言的概念 101 | 102 | Nagios除了检查脚本运行状态，没有任何存储功能。有第三方插件可以存储数据，并可视化数据 103 | 104 | ###### 4.3 存储 105 | 除了当前的检查状态，Nagios本身没有存储空间。有些插件可以存储数据，例如可视化。 106 | 107 | ###### 4.4 架构 108 | Nagios是单实例服务，所有的检查配置项统一由一个文件配置。 109 | 110 | ###### 4.5 总结 111 | Nagios对于小型监控或者黑盒测试时非常有效的。如果你想要做白盒监控，或者动态地，基于云环境的数据监控，Prometheus是一个不错的选择 112 | 113 | ##### 五、Prometheus vs. Sensu 114 | 广义上说，[Sensu](https://sensuapp.org/)是一个更加现代的Nagios。 115 | 116 | ###### 5.1 范围 117 | 主要不同点在于Sensu客户端注册自己，并确定从本地还是其他地方获取配置检查。Senus对perfData的数量没有限制。 还有一个客户端socket允许把任意检查结果推送到Senus 118 | 119 | ###### 5.2 数据模型 120 | 和Nagios一样 121 | 122 | ###### 5.3 存储 123 | Sensu在Redis中存储数据，存储被称作stashes。主要是静默存储，同时它也存储在Senus上注册的所有客户端 124 | 125 | ###### 5.4 架构 126 | Sensu有很多组件。它使用Rabbit消息队列进行数据传输，使用Redis存储当前状态，独立的服务处理数据 127 | 128 | RabbitMQ和Redis都可以是集群的，运行多个服务器副本可是实现副本和冗余 129 | 130 | ###### 5.5 总结 131 | 如果已经有了Nagios服务，你希望扩展它，同时希望使用Senus的注册特性，那么Senus是一个不错的选择 132 | 133 | 如果你想要使用白盒、或者有一个动态的云环境，那么Prometheus是一个很好的选择。 134 | -------------------------------------------------------------------------------- /introductions/FAQ.md: -------------------------------------------------------------------------------- 1 | ##### 一、一般问题 2 | ###### 1. Prometheus是什么？ 3 | > Prometheus是一款高活跃生态系统的开源系统监控和预警工具包。详见[概览](https://prometheus.io/docs/introduction/overview/) 4 | 5 | ###### 2. Prometheus与其他的监控系统比较 6 | > 详见[比较](https://prometheus.io/docs/introduction/comparison/) 7 | 8 | ###### 3. Prometheus有什么依赖？ 9 | > Prometheus服务独立运行，没有其他依赖 10 | 11 | ###### 4. Prometheus有高可用的保证吗？ 12 | > 是的，在多台服务器上运行相同的Prometheus服务，相同的预警会由[预警管理器](https://github.com/prometheus/alertmanager)删除 13 | > 为了[提高Alertmanager的可用性](https://github.com/prometheus/alertmanager#high-availability)，您可以在[Mesh群集](https://github.com/weaveworks/mesh)中运行多个实例，并将Prometheus服务器配置为向每个实例发送通知。 14 | 15 | ###### 5. 我被告知Prometheus"不能水平扩展" 16 | > 事实上，有许多方式可以扩展Prometheus。 阅读Robust Percetion的博客关于Prometheus的[扩展](https://www.robustperception.io/scaling-and-federating-prometheus/) 17 | 18 | ###### 6. Prometheus是什么语言写的？ 19 | > 大多数Prometheus组件是由Go语言写的。还有一些是由Java，Python和Ruby写的 20 | 21 | ###### 7. Prometheus的特性、存储格式和APIs有多稳定？ 22 | > Prometheus从v1.0.0版本开始就非常稳定了，我们现在有一些版本功能规划,详见[路线图](https://prometheus.io/docs/introduction/roadmap/)。重大更改以主要版本的增量表示。 实验组件可能会出现例外，声明中会明确标出此类例外。 23 | > 通常，即使尚未达到1.0.0版的存储库也相当稳定。 我们的目标是为每个存储库制定适当的发布流程并最终发布1.0.0。 在任何情况下，重大更改都将在发行说明中指出（由[`CHANGE`]标记），或者对于尚未正式发行的组件进行清楚地传达。 24 | 25 | ###### 8. 为什么是使用的是pull而不是push？ 26 | 基于Http方式的`pull`模型提供了一下优点： 27 | - 当开发变化时，你可以在笔记本上运行你的监控 28 | - 如果目标实例挂掉，你可以很容易地知道 29 | - 你可以手动指定一个目标，并通过浏览器检查该目标实例的监控状况 30 | 31 | 总体而言，我们认为`pull`比`push`略好，但在考虑使用监视系统时，不应将其视为重点。 32 | 33 | 如果你必须要用`Push`模式，我们提供[Pushgateway](https://prometheus.io/docs/instrumenting/pushing/) 34 | 35 | ###### 9. 怎么样把日志推送到Prometheus系统中？ 36 | > 简单地回答：千万别这样做，你可以使用[ELK栈](https://www.elastic.co/cn/products/)去实现 37 | > 比较详细的回答：Prometheus是一款收集和处理度量指标的系统，并非事件日志系统。Raintank的博客有关[日志、度量指标和图表](https://blog.raintank.io/logs-and-metrics-and-graphs-oh-my/)在日志和度量指> 38 | 标之间，进行了详尽地阐述。 39 | 40 | > 如果你想要从应用日志中提取Prometheus度量指标中。 谷歌的[mtail](https://github.com/google/mtail)可能会更有帮助 41 | 42 | ###### 10. 谁写的Prometheus？ 43 | > Prometheus项目发起人是Matt T. Proud和Julius Volz。 一开始大部分的开发是由[SoundCloud](https://soundcloud.com/)赞助的 44 | > 现在它由许多公司和个人维护和扩展 45 | 46 | ###### 11. 当前Prometheus的许可证是用的哪个？ 47 | > Prometheus是根据[Apache 2.0](https://github.com/prometheus/prometheus/blob/master/LICENSE)许可发布的 48 | 49 | ###### 12. Prometheus单词的复数是什么？ 50 | > 经过[广泛研究](https://www.youtube.com/watch?v=B_CDeYrqxjQ&feature=youtu.be)，已确定`Prometheus`的正确复数是`Prometheis`。 51 | 52 | ###### 13. 我能够动态地加载Prometheus的配置吗？ 53 | > 是的，将`SIGHUP`发送到Prometheus进程或将HTTP POST请求发送到`/-/reload`端点将重新加载并应用配置文件。 各种组件尝试妥善处理失败的更改。 54 | 55 | ###### 14. 我能发送告警吗？ 56 | > 是的，通过[预警管理器](https://github.com/prometheus/alertmanager) 57 | 当前，下面列表的外部系统都是被支持的 58 | - Email 59 | - General Webhooks 60 | - HipChat(https://www.hipchat.com/) 61 | - OpsGenie(https://www.atlassian.com/software/opsgenie) 62 | - PagerDuty(http://www.pagerduty.com/) 63 | - Pushover(https://pushover.net/) 64 | - Slack(https://slack.com/) 65 | 66 | ###### 15. 我能创建Dashboard吗？ 67 | > 是的，但是在生产使用中，我们推荐用[Grafana](https://prometheus.io/docs/visualization/grafana/)。[PromDash](https://prometheus.io/docs/visualization/promdash/)和[Console templates](https://prom 68 | etheus.io/docs/visualization/consoles/)也可以 69 | 70 | ###### 16. 我能改变timezone和UTC吗？ 71 | > 为避免任何时区混乱，特别是在涉及所谓的夏时制时，我们决定在Prometheus的所有组件中内部专门使用Unix time和UTC进行显示。 可以将精心选择的时区选择引入UI。 欢迎捐款。 有关此工作的当前状态，请参阅[issue#500](https://github.com/prometheus/prometheus/issues/500)。 72 | 73 | ##### 二、仪表 74 | 75 | ###### 1. 哪些语言有工具库？ 76 | > 这里有很多客户端库，用Prometheus的度量指标度量你的服务。详见[client库](https://prometheus.io/docs/instrumenting/clientlibs/) 77 | > 如果你对功能工具库非常感兴趣，详见[exposition formats](https://prometheus.io/docs/instrumenting/exposition_formats/) 78 | 79 | ###### 2. 我能监控机器吗？ 80 | > 是的。[Node Exporter](https://github.com/prometheus/node_exporter)暴露了很多机器度量指标，包括CPU使用率、内存使用率和磁盘利用率、文件系统的余量和网络带宽等数据。 81 | 82 | ###### 3. 我能监控网络数据吗？ 83 | > 是的。[SNMP Exporter](https://github.com/prometheus/snmp_exporter)允许监控网络设备。 84 | 85 | ###### 4. 我能监控批量任务吗？ 86 | > 是的，通过[Pushgateway](https://prometheus.io/docs/instrumenting/pushing/). 详见[最佳实践](https://prometheus.io/docs/practices/instrumentation/#batch-jobs) 87 | 88 | ###### 5. Prometheus开箱即用的监控应用程序是什么？ 89 | > 详见[exporters和integrations列表](https://prometheus.io/docs/instrumenting/exporters/) 90 | 91 | ###### 6. 我能通过JMX监控JVM应用程序吗？ 92 | > 是的。不能直接使用Java客户端进行测试的应用程序，你可以将[JMX Exporter](https://github.com/prometheus/jmx_exporter)单独使用或者Java代理使用 93 | 94 | ###### 7. 工具对性能的影响是什么？ 95 | > 客户端库和语言之间的性能可能会有所不同。 对于`Java`，[基准测试](https://github.com/prometheus/client_java/blob/master/benchmark/README.md)表明，根据争用，使用`Java`客户端增加计数器/表将花费12-17ns。 除了对延迟最关键的代码之外，所有其他代码都可以忽略不计。 96 | 97 | ##### 三、故障排除 98 | 99 | ###### 1. 我的Prometheus 1.x服务器需要很长时间才能启动并使用有关崩溃恢复的大量信息来保存日志。。 100 | > 你的服务可能遭到了不干净的关闭。Prometheus必须在SIGTERM后彻底关闭，特别地对于一些重量级服务可能需要比较长的时间去。如果服务器崩溃或者强制杀死（如：在等待Prometheus关闭时，内核的OOM杀死你的Promethe 101 | us服务），必须执行崩溃恢复，这在正常情况下需要不到一分钟。详见[崩溃恢复](https://prometheus.io/docs/operating/storage/#crash-recovery) 102 | 103 | ###### 2. 我的Prometheus 1.x服务器内存不足。 104 | > 请参阅有关[内存使用](https://prometheus.io/docs/prometheus/1.8/storage/#memory-usage)情况的部分，以配置Prometheus可用的内存量。 105 | 106 | ###### 3. 我的Prometheus 1.x服务器报告处于“匆忙模式”或“存储需要限制”。 107 | > 您的存储空间很重。阅读有关[配置本地存储](https://prometheus.io/docs/prometheus/1.8/storage/)的部分，了解如何调整设置以获得更好的性能。 108 | 109 | ##### 四、实现 110 | 111 | ###### 1. 为什么所有样品值都是float64数据类型？我想要integer数据类型。 112 | > 我们限制了float64以简化设计[,IEEE 754双精度二进制浮点格式](https://en.wikipedia.org/wiki/Double-precision_floating-point_format)支持高达253的值的整数精度。如果您需要高于253但低于263的整数精度，支持本地64位整数将有帮助。原则上，支持不同的样本值类型 （包括某种大整数 113 | ，支持甚至超过64位）可以实现，但它现在不是一个优先级。 注意，一个计数器，即使每秒增加100万次，只有在超过285年后才会出现精度问题。 114 | 115 | ###### 2. 为什么Prometheus服务器组件不支持TLS或身份验证？ 我可以添加这些吗？ 116 | > 注意：Prometheus团队在2018年8月11日的开发峰会期间已经改变了对此的立场，现在正在项目的[路线图](https://prometheus.io/docs/introduction/roadmap/#tls-and-authentication-in-http-serving-endpoints)中支持TLS和服务端点的身份验证。 代码更改后，将更新此文档。 117 | 118 | > 虽然TLS和身份验证是经常被请求的功能，但我们故意没有在Prometheus的任何服务器端组件中实现它们。 我们已经决定专注于构建最佳监控系统，而不是在每个服务器组件中支持完全通用的TLS和身份验证解决方案，因此有两个不同的选项和参数（仅TLS的10多个选项）。 119 | 120 | > 如果您需要TLS或身份验证，我们建议将反向代理放在Prometheus前面。 参见例如[使用Nginx添加对Prometheus的基本认证](https://www.robustperception.io/adding-basic-auth-to-prometheus-with-nginx)。 121 | 122 | > 这仅适用于入站连接。 Prometheus确实支持抓取[TLS-和auth启用的目标](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Cscrape_config%3E)，以及其他创建出站连接的Prometheus组件具有类似的支持。 123 | -------------------------------------------------------------------------------- /introductions/FirstSteps.md: -------------------------------------------------------------------------------- 1 | 欢迎来到Prometheus！Prometheus是一个监控平台，通过在监控目标上的HTTP端点来收集受监控目标的指标。本指南将向您展示如何安装，配置和使用Prometheus监控我们的第一个资源。 您将下载，安装并运行Prometheus。您还将下载并安装`exporter`，这些工具可在主机和服务上公开时间序列数据。我们的第一个`exporter`将是Prometheus本身，它提供了有关内存使用，垃圾回收等各种主机级指标。 2 | 3 | ##### 一、下载Prometheus 4 | 根据你的平台[下载最新发行版本](https://prometheus.io/download/)，然后解压它: 5 | ``` 6 | tar xvfz prometheus-*.tar.gz 7 | cd prometheus-* 8 | ``` 9 | Prometheus服务器是一个名为`prometheus`的二进制文件（或Microsoft Windows上的`prometheus.exe`）。 我们可以通过传递`--help`标志来运行二进制文件并查看其选项的帮助。 10 | ``` 11 | ./prometheus --help 12 | usage: prometheus [] 13 | 14 | The Prometheus monitoring server 15 | . . . 16 | ``` 17 | 在启动Prometheus之前，让我们配置它。 18 | 19 | ##### 二、配置Prometheus 20 | Prometheus配置是[YAML](https://yaml.org/start.html)。Prometheus下载附带一个名为`prometheus.yml`的文件中的示例配置，这是一个很好的入门之处。 21 | 22 | 我们删除了示例文件中的大部分注释，使其更简洁（注释是以`＃`为前缀的行）。 23 | ``` 24 | global: 25 | scrape_interval: 15s 26 | evaluation_interval: 15s 27 | 28 | rule_files: 29 | # - "first.rules" 30 | # - "second.rules" 31 | 32 | scrape_configs: 33 | - job_name: prometheus 34 | static_configs: 35 | - targets: ['localhost:9090'] 36 | ``` 37 | 示例配置文件中有三个配置块：`global`，`rule_files`和`scrape_configs`。 38 | 39 | `global`控制Prometheus服务器的全局配置。 我们有两种选择。 第一个是`scrape_interval`，它控制Prometheus抓取目标的频率。 您可以为单个目标重写此值。 在这种例子下，全局设置是每15s抓取一次。 `evaluation_interval`选项控制Prometheus评估规则的频率。 Prometheus使用规则创建新的时间序列并生成预警。 40 | 41 | `rule_files`块指定我们希望Prometheus服务器加载的任何规则的位置。 现在我们没有规则。 42 | 43 | 最后一个块`scrape_configs`控制Prometheus监视的资源。 由于Prometheus还将自己的数据公开为HTTP端点，因此它可以抓取并监控自身的健康状况。 在默认配置中，有一个名为prometheus的`job`，它会抓取Prometheus服务器公开的时间序列数据。 该`job`包含一个静态配置的目标，即端口`9090`上的`localhost`。Prometheus希望指标在`/metrics`路径上的目标上可用。 所以这个默认的工作是通过URL抓取：[http//localhost:9090/metrics](http//localhost:9090/metrics)。 44 | 45 | 返回的时间序列数据将详细说明Prometheus服务器的状态和性能。 46 | 47 | 有关配置选项的完整规范，请参阅[配置文档](https://prometheus.io/docs/prometheus/latest/configuration/configuration/)。 48 | 49 | ##### 三、启动Prometheus 50 | 要使用我们新创建的配置文件启动Prometheus，请切换到包含Prometheus二进制文件的目录并运行： 51 | ``` 52 | ./prometheus --config.file=prometheus.yml 53 | ``` 54 | prometheus应该启动。您还应该能够在[http//localhost:9090](http//localhost:9090)浏览到自己的状态页面。给它大约30秒的时间从自己的HTTP指标端点收集有关自己的数据。 55 | 56 | 您还可以通过导航到其自己的指标端点来验证Prometheus是否正在提供有关自身的指标：[http//localhost:9090/metrics](http//localhost:9090/metrics)。 57 | 58 | ##### 四、使用表达式浏览器 59 | 让我们试着看一下Prometheus收集的关于自己的一些数据。 要使用Prometheus的内置表达式浏览器，请导航到[http//localhost:9090/graph](http//localhost:9090/graph)并在`Graph`选项卡中选择`Console`视图。 60 | 61 | 正如您可以从[http//localhost：9090/metrics](http//localhost：9090/metrics)收集的那样，Prometheus导出的一个度量标准称为`promhttp_metric_handler_requests_total`（Prometheus服务器已服务的`/metrics`请求的总数）。 继续并将其输入表达式控制台： 62 | ``` 63 | promhttp_metric_handler_requests_total 64 | ``` 65 | 这应该返回许多不同的时间序列（以及为每个记录的最新值），所有时间序列都使用度量标准名称`promhttp_metric_handler_requests_total`，但具有不同的标签。 这些标签指定不同的请求状态。 66 | 67 | 如果我们只对导致HTTP代码`200`的请求感兴趣，我们可以使用此查询来检索该信息： 68 | ``` 69 | promhttp_metric_handler_requests_total{code="200"} 70 | ``` 71 | 要计算返回的时间序列总数，您可以写： 72 | ``` 73 | count(promhttp_metric_handler_requests_total) 74 | ``` 75 | 有关表达式语言的更多信息，请参阅[表达式语言文档](https://prometheus.io/docs/prometheus/latest/querying/basics/)。 76 | 77 | ##### 五、适用图表接口 78 | 要绘制表达式图表，请导航到[http//localhost:9090/graph](http//localhost:9090/mgraph) graph并使用`Graph`选项卡。 79 | 80 | 例如，输入以下表达式来绘制在自我抓取的Prometheus中发生的返回状态代码`200`的每秒HTTP请求率： 81 | ``` 82 | rate(promhttp_metric_handler_requests_total{code="200"}[1m]) 83 | ``` 84 | 您可以尝试图形范围参数和其他设置。 85 | 86 | ##### 六、监控其他目标 87 | 仅从Prometheus那里收集指标并不能很好地反映Prometheus的能力。 为了更好地了解Prometheus可以做什么，我们建议您浏览有关其他exporter的文档。 使用node exporter指南[监控Linux或macOS主机指标](https://prometheus.io/docs/guides/node-exporter/)是一个很好的起点。 88 | 89 | ##### 七、总结 90 | 在本指南中，您安装了Prometheus，配置了Prometheus实例来监控资源，并学习了在Prometheus表达式浏览器中处理时间序列数据的一些基础知识。 要继续了解Prometheus，请查看[概述](https://prometheus.io/docs/introduction/overview/)，了解接下来要探索的内容。 91 | 92 | -------------------------------------------------------------------------------- /introductions/Glossary.md: -------------------------------------------------------------------------------- 1 | ##### 一、(Alert)警告 2 | 警告是Prometheus服务正在激活警报规则的结果。警报从Prometheus服务发送到警告管理器。 3 | 4 | ##### 二、(Alertmanager)警告管理器 5 | 警告管理器接收警告，并把它们聚合成组、去重复数据、应用静默和节流，然后发送通知到邮件、Pageduty或者Slack等系统中。 6 | 7 | ##### 三、(Bridge)网桥 8 | 网桥是一个从客户端库提取样本，然后将其暴露给非Prometheus监控系统的组件。例如：Python、Go和Java客户端可以将度量指标数据导出到Graphite。 9 | 10 | ##### 四、(Client library)客户库 11 | 客户端库是使用某种语言（Go、Java、Python、Ruby等），可以轻松直接调试代码，编写样本收集器去拉取来自其他系统的数据，并将这些度量指标数据输送给Prometheus服务。 12 | 13 | ##### 五、(Collector) 收集器 14 | 收集器是表示一组度量指标导出器的一部分。它可以是单个度量指标，也可以是从另一个系统提取的多维度度量指标。 15 | 16 | ##### 六、(Direct instrumentation)直接测量 17 | 直接检测是使用[客户端库](https://prometheus.io/docs/introduction/glossary/#client-library)内联作为程序源代码的一部分内联添加的检测。 18 | 19 | ##### 七、(Endpoint)端点 20 | 可以抓取的度量标准源，通常对应于单个进程。 21 | 22 | ##### 八、(Exporter)导出器 23 | 导出器是暴露Prometheus度量指标的二进制文件，通常将非Prometheus数据格式转化为Prometheus支持的数据处理格式 24 | 25 | ##### 九、(Instance)实例 26 | 实例是唯一标识作业中目标的标签。 27 | 28 | ##### 十、(Job)作业 29 | 具有相同目的的目标集合（例如，监视为可伸缩性或可靠性而复制的一组类似进程）被称为作业。 30 | 31 | ##### 十一、(Notification)通知 32 | 通知表示一组或者多组的警告，通过警告管理器将通知发送到邮件，Pagerduty或者Slack等系统中 33 | 34 | ##### 十二、(PromDash) 面板 35 | [PromDash](https://prometheus.io/docs/visualization/promdash/)是Prometheus的Ruby-on-rails主控面板构建器。它和Grafana有高度的相似之处，但是它只能为Prometheus服务 36 | 37 | ##### 十三、Prometheus 38 | Prometheus经常称作Prometheus系统的核心二进制文件。它也可以作为一个整体，被称作Prometheus监控系统 39 | 40 | ##### 十四、(PromQL) Prometheus查询语言 41 | [PromQL](https://prometheus.io/docs/querying/basics/)是Prometheus查询语言。它支持聚合、分片、切割、预测和连接操作 42 | 43 | ##### 十五、Pushgateway 44 | [Pushgateway](https://prometheus.io/docs/instrumenting/pushing/)会保留最近从批处理作业中推送的度量指标。这允许服务中断后Prometheus能够抓取它们的度量指标数据 45 | 46 | ##### 十六、(Remote read)远程读取 47 | 远程读取是Prometheus功能，允许从其他系统（例如长期存储）透明读取时间序列作为查询的一部分。 48 | 49 | ##### 十七、(Remote Read Adapter)远程读取适配器 50 | 并非所有系统都直接支持远程读取。远程读取适配器位于Prometheus和另一个系统之间，用于转换时间序列请求和它们之间的响应。 51 | 52 | ##### 十八、(Remote Read Endpoint)远程读取端点 53 | 远程读取端点是Prometheus在进行远程读取时所说的。 54 | 55 | ##### 十九、(Remote Write)远程写入 56 | 远程写入是Prometheus功能，允许动态地将采集的样本发送到其他系统，例如长期存储。 57 | 58 | ##### 二十、(Remote Write Adapter)远程写入适配器 59 | 并非所有系统都直接支持远程写入。 远程写入适配器位于Prometheus和另一个系统之间，将远程写入中的样本转换为其他系统可以理解的格式。 60 | 61 | ##### 二十一、(Remote Write Endpoint)远程写入端点 62 | 远程写入端点是Prometheus在进行远程写入时所说的。 63 | 64 | ##### 二十二、(Sample)样本 65 | 样本是时间序列中某个时间点的单个值。 66 | 在Prometheus中，每个样本都包含一个float64值和一个毫秒精度的时间戳。 67 | 68 | ##### 二十三、(Silence)静默 69 | 在AlertManager中的静默可以阻止符合标签的警告通知 70 | 71 | ##### 二十四、(Target)目标 72 | 在Prometheus服务中，一个应用程序、服务、端点的度量指标数据 73 | -------------------------------------------------------------------------------- /introductions/Media.md: -------------------------------------------------------------------------------- 1 | 有一个[subreddit](https://www.reddit.com/r/prometheusmonitoring)收集互联网上所有与Prometheus斯相关的资源。 2 | 3 | 以下选择的资源对于Prometheus入门特别有用。 4 | 5 | ##### 一、博客 6 | - [官方博客](https://prometheus.io/blog/) 7 | - [SoundCloud的博客](https://developers.soundcloud.com/blog/prometheus-monitoring-at-soundcloud)帖子宣称-比上面的博客更加详尽地描述Prometheus 8 | - 在[Robust Perception的博客](https://www.robustperception.io/tag/prometheus)上有很多与Prometheus相关的资源 9 | 10 | ##### 二、教程 11 | - [Prometheus工作室的介绍和用例](https://github.com/juliusv/prometheus_workshop) 12 | - [在Ubuntu 14.04上使用Docker安装Prometheus](https://www.digitalocean.com/community/tutorials/how-to-install-prometheus-using-docker-on-ubuntu-14-04) 13 | 14 | ##### 三、播客与采访 15 | - [Prometheus on FLOSS Weekly 357](https://twit.tv/shows/floss-weekly/episodes/357) - Julius Volz on the FLOSS Weekly TWiT.tv show. 16 | - [Prometheus与服务监控](http://changelog.com/podcast/168)-Julius Volz on the Changelog podcast. 17 | 18 | ##### 四、录制的会谈 19 | - [Prometheus: A Next-Generation Monitoring System](https://www.usenix.org/conference/srecon15europe/program/presentation/rabenstein) – Julius Volz and Björn Rabenstein at SREcon15 Europe, Dublin. 20 | - [Prometheus: A Next-Generation Monitoring System](https://www.youtube.com/watch?v=cwRmXqXKGtk) - Brian Brazil at FOSDEM 2016 (slides). 21 | - [What is your application doing right now?](https://www.youtube.com/watch?v=Z0LlilNpX1U&feature=youtu.be) – Matthias Gruter, Transmode, at DevOps Stockholm Meetup. 22 | - [Prometheus workshop](https://vimeo.com/131581353) – Jamie Wilkinson at Monitorama PDX 2015 (slides). 23 | - [Monitoring Hadoop with Prometheus](https://www.youtube.com/watch?v=qs2sqOLNGtw) – Brian Brazil at the Hadoop User Group Ireland (slides). 24 | - In German: [Monitoring mit Prometheus](https://media.ccc.de/v/eh16-43-monitoring_mit_prometheus#video&t=2804) – Michael Stapelberg at Easterhegg 2016. 25 | - In German: [Prometheus in der Praxis](https://media.ccc.de/v/MRMCD16-7754-prometheus_in_der_praxis) – Jonas Große Sundrup at MRMCD 2016 26 | 27 | ##### 五、PPT 28 | ###### 5.1 通用 29 | - [Prometheus Overview](https://www.slideshare.net/brianbrazil/prometheus-overview) – by Brian Brazil. 30 | - [Systems Monitoring with Prometheus](https://www.slideshare.net/brianbrazil/devops-ireland-systems-monitoring-with-prometheus) – Brian Brazil at Devops Ireland Meetup, Dublin. 31 | - [OMG! Prometheus](https://www.dropbox.com/s/0l7kxhjqjbabtb0/prometheus%20site-ops%20preso.pdf?dl=0) – Benjamin Staffin, Fitbit Site Operations, explains the case for Prometheus to his team. 32 | 33 | ###### 5.2 Docker 34 | - [Prometheus and Docker](https://www.slideshare.net/brianbrazil/prometheus-and-docker-docker-galway-november-2015) – Brian Brazil at Docker Galway. 35 | 36 | ###### 5.3 Python 37 | - [Better Monitoring for Python](https://www.slideshare.net/brianbrazil/better-monitoring-for-python-inclusive-monitoring-with-prometheus-pycon-ireland-lightning-talk) – Brian Brazil at Pycon Ireland. 38 | - [Monitoring your Python with Prometheus](https://www.slideshare.net/brianbrazil/python-ireland-monitoring-your-python-with-prometheus) – Brian Brazil at Python Ireland Meetup, Dublin. 39 | -------------------------------------------------------------------------------- /introductions/Overview.md: -------------------------------------------------------------------------------- 1 | ##### 一、什么是prometheus？ 2 | [Prometheus](https://github.com/prometheus)是一个最初在[SoundCloud](https://soundcloud.com/)上构建的开源系统监视和警报工具包。自2012年成立以来，许多公司和组织都采用了Prometheus，该项目拥有非常活跃的开发者和用户[社区](https://prometheus.io/community/)。 它现在是一个独立的开源项目，可以独立于任何公司进行维护。 为了强调这一点，并阐明项目的治理结构，Prometheus于2016年加入[Cloud Native Computing Foundation](https://www.cncf.io/)，作为继[Kubernetes](https://kubernetes.io/)之后的第二个托管项目。 3 | 4 | 有关Prometheus的更详细概述，请参阅[媒体](https://prometheus.io/docs/introduction/media/)部分链接的资源。 5 | 6 | ###### 1.1 特征 7 | Prometheus的主要特征有： 8 | - 多维度数据[模型](https://prometheus.io/docs/concepts/data_model/)-由指标键值对标识的时间序列数据组成 9 | - PromQL，一种[灵活的查询语言](https://prometheus.io/docs/prometheus/latest/querying/basics/) 10 | - 不依赖分布式存储; 单个服务器节点是自治的 11 | - 以HTTP方式，通过`pull`模式拉取时间序列数据 12 | - 支持通过中间网关[推送时间序列数据](https://prometheus.io/docs/instrumenting/pushing/) 13 | - 通过服务发现或者静态配置，来发现目标服务对象 14 | - 支持多种多样的图表和界面展示 15 | 16 | ###### 1.2 组件 17 | Prometheus生态包括了很多组件，它们中的一些是可选的： 18 | - [Prometheus server](https://github.com/prometheus/prometheus)，用于抓取和存储时间序列数据 19 | - 用于检测应用程序代码的[`client libraries`](https://prometheus.io/docs/instrumenting/clientlibs/) 20 | - 用于支持短期`jobs`的[`push`网关](https://github.com/prometheus/pushgateway) 21 | - 针对`HAProxy`，`StatsD`，`Graphite`等服务的特定[`exporters`](https://prometheus.io/docs/instrumenting/exporters/) 22 | - [预警管理器](https://github.com/prometheus/alertmanager)来管理预警 23 | - 各种支持工具 24 | 25 | 多数Prometheus组件是[Go语言](https://golang.org/)写的，这使得这些组件很容易编译和部署。 26 | 27 | ###### 1.3 架构 28 | 下面这张图说明了Prometheus的整体架构，以及生态中的一些组件作用: 29 | ![Prometheus Arhitecture](https://prometheus.io/assets/architecture.svg) 30 | 31 | Prometheus可以直接通过目标拉取数据，或者间接地通过中间网关拉取数据。它在本地存储抓取的所有数据，并通过规则从现有数据中聚合记录新的时间序列或者产生预警，[`Grafana`](https://grafana.com/)和其他API可用于可视化收集的数据。 32 | 33 | ##### 二、什么时候适用？ 34 | Prometheus适用于记录任何纯数字时间序列。 它适用于以机器为中心的监控以及高度动态的面向服务架构的监控。 在微服务的世界中，Prometheus的多维度数据收集和查询非常强大。 35 | 36 | Prometheus是为服务的可靠性而设计的，当服务出现故障时，它可以使你快速定位和诊断问题。 每个Prometheus服务器都是独立的，不依赖于网络存储或其他远程服务。 当基础架构的其他部分损坏时，您可以依赖它，并且您不需要设置大量的基础架构来使用它。 37 | 38 | ##### 三、什么时候不适用？ 39 | Prometheus重视可靠性。 即使在故障情况下，您也可以随时查看有关系统的可用统计信息。 如果您需要100％的准确度，例如按请求计费，Prometheus不是一个好的选择，因为收集的数据可能不够详细和完整。 在这种情况下，您最好使用其他系统来收集和分析数据以进行计费，并使用Prometheus进行其余监控。 40 | -------------------------------------------------------------------------------- /introductions/README.md: -------------------------------------------------------------------------------- 1 | 译文:https://prometheus.io/docs/introduction/overview/ 2 | -------------------------------------------------------------------------------- /introductions/Roadmap.md: -------------------------------------------------------------------------------- 1 | 下面的一些功能使我们即将要做的事情。如果你想查看整个计划和当前工作的完整概述，请查看github上Prometheus项目的issue，如：[Prometheus server](https://github.com/prometheus/prometheus/issues) 2 | 3 | ##### 一、服务器端指标元数据支持 4 | 此时，度量标准类型和其他元数据仅在客户端库和展示中使用，但不会在Prometheus服务器中保留或使用。 我们计划将来使用这个元数据。第一步是在Prometheus中将这些数据聚合在内存中，并通过实验性API端点提供。 5 | 6 | ##### 二、采用OpenMetrics 7 | OpenMetrics工作组正在为度量标准开发新标准。我们计划在我们的客户端库和Prometheus本身支持这种格式。 8 | 9 | ##### 三、回填时间序列 10 | 回填将允许过去的大量数据。这将允许追溯规则评估，并从其他监控系统传输旧数据。 11 | 12 | ##### 四、HTTP服务端点中的TLS和身份验证 13 | Prometheus，Alertmanager和官方exporter中的HTTP服务端点尚未内置对TLS和身份验证的支持。 添加此支持将使人们更容易安全地部署Prometheus组件，而无需反向代理从外部添加这些功能。 14 | 15 | ##### 五、支持生态 16 | Prometheus拥有一系列客户端库和exporter。总是可以支持更多语言，或者从中导出指标有用的系统。 我们将支持生态系统创建和扩展这些系统。 17 | -------------------------------------------------------------------------------- /operating/Integrations.md: -------------------------------------------------------------------------------- 1 | ## 集成 2 | --- 3 | 除了客户端库和导出器以及相关库之外，Prometheus还有许多其他通用集成点。 此页面列出了与这些集成的一些集成。 4 | 5 | 由于功能重叠或仍处于开发阶段，并非所有集成都列在此处。 [导出器默认端口维基页面](https://github.com/prometheus/prometheus/wiki/Default-port-allocations)也恰好包含一些适合这些类别的非导出器集成。 6 | 7 | ### 文件服务发现 8 | 对于Prometheus本身不支持的服务发现机制，[基于文件的服务发现](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Cfile_sd_config%3E)提供了集成接口。 9 | 10 | - [Docker Swarm](https://github.com/ContainerSolutions/prometheus-swarm-discovery) 11 | - [Scaleway](https://github.com/scaleway/prometheus-scw-sd) 12 | 13 | ### 远端端点和存储 14 | Prometheus的[远程写入](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Cremote_write%3E)和[远程读取](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Cremote_read%3E)功能允许透明地发送和接收样本。 这主要用于长期存储。 建议您仔细评估此空间中的任何解决方案，以确认它可以处理您的数据量。 15 | 16 | - [AppOptics](https://github.com/solarwinds/prometheus2appoptics):写 17 | - [Chronix](https://github.com/ChronixDB/chronix.ingester):写 18 | - [Cortex](https://github.com/cortexproject/cortex):读和写 19 | - [CrateDB](https://github.com/crate/crate_adapter):读和写 20 | - [Elasticsearch](https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-module-prometheus.html):写 21 | - [Gnocchi](https://gnocchi.xyz/prometheus.html):写 22 | - [Graphite]https://github.com/prometheus/prometheus/tree/master/documentation/examples/remote_storage/remote_storage_adapter):写 23 | - [InfluxDB](https://docs.influxdata.com/influxdb/v1.7/supported_protocols/prometheus):读和写 24 | - [IRONdb](https://github.com/circonus-labs/irondb-prometheus-adapter):读和写 25 | - [Kafka](https://github.com/Telefonica/prometheus-kafka-adapter):写 26 | - [M3DB](https://m3db.github.io/m3/integrations/prometheus/):读和写 27 | - [OpenTSDB](https://github.com/prometheus/prometheus/tree/master/documentation/examples/remote_storage/remote_storage_adapter):写 28 | - [PostgreSQL/TimescaleDB](https://github.com/timescale/prometheus-postgresql-adapter):读和写 29 | - [SignalFx](https://github.com/signalfx/gateway#prometheus):写 30 | - [Splunk](https://github.com/lukemonahan/splunk_modinput_prometheus#prometheus-remote-write):写 31 | - [TiKV](https://github.com/bragfoo/TiPrometheus):读和写 32 | - [VictoriaMetrics](https://github.com/VictoriaMetrics/VictoriaMetrics):写 33 | - [Wavefront](https://github.com/wavefrontHQ/prometheus-storage-adapter):写 34 | 35 | ### Alertmanager Webhook接收器 36 | 对于Alertmanager本身不支持的通知机制，[webhook接收器](https://prometheus.io/docs/alerting/configuration/#webhook_config)允许集成。 37 | 38 | - [Alertsnitch](https://gitlab.com/yakshaving.art/alertsnitch):将报警存入MySQL数据库 39 | - [AWS SNS](https://github.com/DataReply/alertmanager-sns-forwarder) 40 | - [DingTalk](https://github.com/timonwong/prometheus-webhook-dingtalk) 41 | - [IRC Bot](https://github.com/multimfi/bot) 42 | - [JIRAlert](https://github.com/free/jiralert) 43 | - [Phabricator / Maniphest](https://github.com/knyar/phalerts) 44 | - [prom2teams](https://github.com/idealista/prom2teams):将通知转发给Microsoft Teams 45 | - [SMS](https://github.com/messagebird/sachet):支持[多个提供商](https://github.com/messagebird/sachet/blob/master/examples/config.yaml) 46 | - [SNMP traps](https://github.com/maxwo/snmp_notifier) 47 | - [Telegram bot](https://github.com/inCaller/prometheus_bot) 48 | - [XMPP Bot](https://github.com/jelmer/prometheus-xmpp-alerts) 49 | 50 | ### 管理 51 | Prometheus不包含配置管理功能，允许您将其与现有系统集成或构建在其上。 52 | 53 | - [Prometheus Operator](https://github.com/coreos/prometheus-operator):在Kubernetes上管理Prometheus 54 | - [Promgen](https://github.com/line/promgen):Prometheus和Alertmanager的Web UI和配置生成器 55 | 56 | ### 其他 57 | - [karma](https://github.com/prymitive/karma):报警看板 58 | - [PushProx](https://github.com/RobustPerception/PushProx):代理到横向NAT和类似的网络设置 59 | - [Promregator](https://github.com/promregator/promregator):发现和抓取Cloud Foundry应用程序 -------------------------------------------------------------------------------- /operating/README.md: -------------------------------------------------------------------------------- 1 | 译文：https://prometheus.io/docs/operating/integrations/ -------------------------------------------------------------------------------- /operating/Security.md: -------------------------------------------------------------------------------- 1 | ## 安全模型 2 | --- 3 | Prometheus是一个复杂的系统，具有许多组件和许多与其他系统的集成。 它可以部署在各种受信任和不受信任的环境中。 4 | 5 | 本页介绍了Prometheus的一般安全假设以及某些配置可能启用的攻击向量。 6 | 7 | 与任何复杂的系统一样，不可能保证没有错误。 如果您发现安全漏洞，请私自向相关存储库的`MAINTAINERS.md`和CC `prometheus-team@googlegroups.com`中列出的维护人员报告。 我们将解决问题并与您协调发布日期，确认您的努力，如果您愿意，请提及您的姓名 8 | 9 | ### Prometheus 10 | 假定不受信任的用户可以访问Prometheus HTTP端点和日志。他们可以访问数据库中包含的所有时间序列信息，以及各种操作/调试信息。 11 | 12 | 还假设只有受信任的用户才能更改命令行，配置文件，规则文件以及Prometheus和其他组件的运行时环境的其他方面。 13 | 14 | 其中针对Prometheus的擦除，频率以及完全通过配置文件确定的其他设置。管理员可以决定使用来自服务发现系统的信息，其与重新标记相结合可以向可以修改该服务发现系统中的数据的任何人授予一些控制权。 15 | 16 | 被扫描的目标可能由不受信任的用户运行。默认情况下，目标不应该公开冒充不同目标的数据。 `honor_labels`选项会删除此保护，某些重新标记设置也会如此。 17 | 18 | 从Prometheus 2.0开始， `--web.enable-admin-api`标志控制对管理HTTP API的访问，其中包括删除时间序列等功能。默认情况下禁用此功能。如果启用，则可以在`/api/*/admin/` paths下访问管理和变异功能。 `--web.enable-lifecycle`标志控制Prometheus的HTTP重新加载和关闭。默认情况下也会禁用此功能。如果启用，则可以在`/-/reload`和`/-/quit`路径下访问它们。 19 | 20 | 在Prometheus 1.x中，任何有权访问HTTP API的人都可以访问`/-/reload`并在`/api/v1/series上`使用`DELETE`。默认情况下禁用`/-/quit`端点，但可以使用`-web.enable-remote-shutdown`标志启用。 21 | 22 | 远程读取功能允许任何具有HTTP访问权限的人向远程读取端点发送查询。例如，如果PromQL查询最终直接针对关系数据库运行，那么任何能够向Prometheus发送查询的人（例如通过Grafana）都可以针对该数据库运行任意SQL。 23 | 24 | ### 预警管理器 25 | 任何有权访问Alertmanager HTTP端点的用户都可以访问其数据。他们可以创建和解决警报。他们可以创建，修改和删除沉默。 26 | 27 | 发送通知的位置由配置文件确定。通过某些模板设置，通知可能会在警报定义的目标位置结束。例如，如果通知使用警报标签作为目标电子邮件地址，则任何可以向Alertmanager发送警报的人都可以向任何电子邮件地址发送通知。如果警报定义的目的地是可模板的秘密字段，任何有权访问Prometheus或Alertmanager的人都可以查看秘密。 28 | 29 | 任何可模板化的秘密字段用于在上述用例中路由通知。它们不是用于使用模板文件功能将秘密从配置文件中分离出来的方法。存储在模板文件中的任何机密都可以由能够在Alertmanager配置文件中配置接收器的任何人进行泄露。例如，在大型设置中，每个团队可能都有一个他们完全控制的alertmanager配置文件片段，然后将其合并到完整的最终配置文件中。 30 | 31 | ### Pushgateway 32 | 任何有权访问Pushgateway HTTP端点的用户都可以创建，修改和删除其中包含的指标。 由于Pushgateway通常在启用`honor_labels`的情况下进行刮擦，这意味着任何有权访问Pushgateway的人都可以在Prometheus中创建任何时间序列。 33 | 34 | ### Exporters 35 | Exporters通常只与具有预设命令/请求集的一个已配置实例通信，这些命令/请求无法通过其HTTP端点进行扩展。 36 | 37 | 还有一些导出程序，例如SNMP和Blackbox导出程序，它们从URL参数中获取目标。 因此，对这些导出器具有HTTP访问权限的任何人都可以使它们向任意端点发送请求。 由于它们还支持客户端身份验证，因此可能会导致HTTP基本身份验证密码或SNMP社区字符串等机密泄露。 挑战 - 响应认证机制（如TLS）不受此影响。 38 | 39 | ### 客户端库 40 | 客户端库旨在包含在用户的应用程序中。 41 | 42 | 如果使用客户端库提供的HTTP处理程序，则到达该处理程序的恶意请求不应该导致超出由额外加载和失败的擦除导致的问题。 43 | 44 | ### 身份验证，授权和加密 45 | Prometheus及其组件不提供任何服务器端身份验证，授权或加密。如果需要，建议使用反向代理。 46 | 47 | 由于管理和变异端点旨在通过简单的工具（如cURL）进行访问，因此没有内置的CSRF保护，因为这会破坏此类用例。因此，在使用反向代理时，您可能希望阻止此类路径以防止CSRF。 48 | 49 | 对于非变异端点，您可能希望在反向代理中设置CORS标头（如`Access-Control-Allow-Origin`）以防止XSS。 50 | 51 | 如果您正在编写PromQL查询，其中包含来自不受信任的用户的输入（例如，参数控制台模板的URL参数，或者您自己构建的内容），这些查询并不意味着能够运行任意PromQL查询，请确保适当地转义任何不受信任的输入以防止注入攻击。例如，如果``是`""} or some_metric {zzz ="`，则`up{job="""}`将变为`{job=""} or some_metric {zzz =""}`。 52 | 53 | 对于那些使用Grafana注意，仪表板权限不是数据源权限，因此不要限制用户在代理模式下运行任意查询的能力。 54 | 55 | 各种Prometheus组件支持客户端身份验证和加密。如果提供TLS客户端支持，通常还会有一个名为`insecure_skip_verify`的选项，它会跳过SSL验证。 56 | 57 | ### Secrets 58 | 可以通过HTTP API和/或日志获得非机密信息或字段。 59 | 60 | 在Prometheus中，从服务发现中检索的元数据不被视为机密。 在整个普罗米修斯系统中，指标不被视为机密。 61 | 62 | 包含配置文件中的秘密的字段（在文档中明确标记）将不会在日志中或通过HTTP API公开。 不应将秘密放在其他配置字段中，因为组件通过其HTTP端点公开其配置是很常见的。 63 | 64 | 依赖项使用的其他来源的秘密（例如，EC2服务发现使用的`AWS_SECRET_KEY`环境变量）可能由于我们无法控制的代码或由于在任何存储位置发生的功能而最终暴露。 65 | 66 | ### Denial of Service 67 | 对于超额负载或昂贵的查询，存在一些缓解措施。 但是，如果提供的查询/指标太多或太昂贵，则组件将会崩溃。 更可能是受信任的用户意外取出组件而不是恶意行为。 68 | 69 | 用户有责任确保为组件提供足够的资源，包括CPU，RAM，磁盘空间，IOPS，文件描述符和带宽。 70 | 71 | 建议监视所有组件的故障，并在故障时自动重启。 72 | 73 | ### Libraries 74 | 本文档考虑了从库存源代码构建的vanilla二进制文件。 如果您修改Prometheus源代码，或在您自己的代码中使用Prometheus内部（在官方客户端库API之外），则此处提供的信息不适用。 75 | 76 | ### Build Proces 77 | Prometheus的构建管道运行在第三方提供程序上，Prometheus开发团队的许多成员和这些提供程序的工作人员都可以访问这些提供程序。 如果您担心二进制文件的确切来源，建议您自己构建它们，而不是依赖项目提供的预构建二进制文件。 78 | 79 | ### 外部审计 80 | CNCF在2018年4月至2018年6月期间通过cure53赞助了一项外部安全审计。 81 | 82 | 有关详细信息，请阅读[审计的最终报告](https://prometheus.io/assets/downloads/2018-06-11--cure53_security_audit.pdf)。 83 | -------------------------------------------------------------------------------- /prometheus/API_Stability.md: -------------------------------------------------------------------------------- 1 | Prometheus承诺在主要版本中保持API稳定性，并努力避免破坏关键功能的变化。一些功能，即化妆品，仍在开发中，或依赖于第三方服务，不在此范围内。 2 | 3 | 对于2.x而言被认为是稳定的： 4 | 5 | - 查询语言和数据模型 6 | - 警报和录制规则 7 | - 摄取博览会格式 8 | - v1 HTTP API（由仪表板和UI使用） 9 | - 配置文件格式（减去服务发现远程读/写，见下文） 10 | - 规则/警报文件格式 11 | - 控制台模板语法和语义 12 | 13 | 被认为对2.x不稳定的事情： 14 | 15 | - 任何列为实验性或可能发生变化的功能，包括： 16 | - `holt_winters PromQL`函数 17 | - 远程读取，远程写入和远程读取端点 18 | - v2 HTTP和GRPC API 19 | - 服务发现集成，`static_configs`和`file_sd_configs`除外 20 | - 转到属于服务器一部分的API 21 | - Web UI生成的HTML 22 | - Prometheus本身的/ metrics端点中的度量标准 23 | - 精确的磁盘格式。然而，潜在的变化将由Prometheus向前兼容并透明地处理 24 | 25 | 只要您没有使用标记为实验/不稳定的任何功能，通常可以在没有任何操作调整的情况下执行主要版本内的升级，并且任何事情都会破坏的风险很小。任何重大更改都将在发行说明中标记为`CHANGE`。 26 | -------------------------------------------------------------------------------- /prometheus/Federation.md: -------------------------------------------------------------------------------- 1 | 联邦允许Prometheus服务器从另一个Prometheus服务器中截取选定的时间序列。 2 | ##### 一、用例 3 | 联邦有不同的用例。 通常，它用于实现可扩展的Prometheus监控设置或将相关指标从一个服务的Prometheus拉到另一个服务。 4 | ###### 1.1 分层联合 5 | 分层联合允许Prometheus扩展到具有数十个数据中心和数百万个节点的环境。 在此用例中，联合拓扑类似于树，较高级别的Prometheus服务器从较大数量的从属服务器收集聚合时间序列数据。 6 | 7 | 例如，设置可能包含许多高度详细收集数据的每个数据中心Prometheus服务器（实例级深入分析），以及一组仅收集和存储聚合数据的全局Prometheus服务器（作业级向下钻取） ）来自那些本地服务器。 这提供了聚合全局视图和详细的本地视图。 8 | ###### 1.2 跨服务联合 9 | 在跨服务联合中，一个服务的Prometheus服务器配置为从另一个服务的Prometheus服务器中提取所选数据，以便对单个服务器中的两个数据集启用警报和查询。 10 | 11 | 例如，运行多个服务的集群调度程序可能会暴露有关在集群上运行的服务实例的资源使用情况信息（如内存和CPU使用情况）。 另一方面，在该集群上运行的服务仅公开特定于应用程序的服务指标。 通常，这两组指标都是由单独的Prometheus服务器抓取的。 使用联合，包含服务级别度量标准的Prometheus服务器可以从群集Prometheus中提取有关其特定服务的群集资源使用情况度量标准，以便可以在该服务器中使用这两组度量标准。 12 | 13 | ##### 二、联邦配置 14 | 在任何给定的Prometheus服务器上，`/federate`端点允许检索该服务器中所选时间序列集的当前值。 必须至少指定一个`match[]` URL参数才能选择要公开的系列。 每个`match[]`参数都需要指定一个即时向量选择器，如`up`或`{job="api-server"}`。 如果提供了多个`match[]`参数，则选择所有匹配系列的并集。 15 | 16 | 要将指标从一个服务器联合到另一个服务器，请将目标Prometheus服务器配置为从源服务器的`/federate`端点进行刮取，同时还启用`honor_labels` scrape选项（以不覆盖源服务器公开的任何标签）并传入所需的 `match[]`参数。 例如，以下`scrape_config`将任何带有标签`job="prometheus"`的系列或以`job`开头的度量标准名称联合起来：`source-prometheus-{1,2,3}:9090`的Prometheus服务器进入抓取普罗米修斯： 17 | ``` 18 | - job_name: 'federate' 19 | scrape_interval: 15s 20 | 21 | honor_labels: true 22 | metrics_path: '/federate' 23 | 24 | params: 25 | 'match[]': 26 | - '{job="prometheus"}' 27 | - '{__name__=~"job:.*"}' 28 | 29 | static_configs: 30 | - targets: 31 | - 'source-prometheus-1:9090' 32 | - 'source-prometheus-2:9090' 33 | - 'source-prometheus-3:9090' 34 | ``` 35 | -------------------------------------------------------------------------------- /prometheus/Getting_started.md: -------------------------------------------------------------------------------- 1 | 本教程是类似"hello,world"的教程，展示怎样在一个简单地例子中安装、配置和使用Prometheus。你将下载和本地化运行Prometheus服务，并写一个配置文件，监控Prometheus服务本身和一个简单的应用，然后配合使用`query`、`rules`和`graphs`展示收集的时间序列数据。 2 | 3 | ### 下载和运行Prometheus 4 | [下载Prometheus最新的发布版本](https://prometheus.io/download)，然后提取和运行它： 5 | ```shell 6 | tar zxvf prometheus-*.tar.gz 7 | cd prometheus-* 8 | ``` 9 | 在开始启动Prometheus之前，我们要配置它 10 | 11 | ### 配置Prometheus监控自身 12 | Prometheus从监控的目标上通过http方式收集指标数据，由于Prometheus还以相同的方式公开有关其自身的数据，因此它也可以抓取并监视其自身的健康状况。。 13 | 14 | 当然Prometheus服务收集自身服务数据，并没有多大的用处，但是它是一个好的开始例子。保存下面的基本Prometheus配置，并命名为：`prometheus.yml`: 15 | ``` 16 | global: 17 | scrape_interval: 15s # 默认情况下，每15s拉取一次目标采样点数据。 18 | 19 | # 我们可以附加一些指定标签到采样点度量标签列表中, 用于和第三方系统进行通信, 包括：federation, remote storage, Alertmanager 20 | external_labels: 21 | monitor: 'codelab-monitor' 22 | 23 | # 下面就是拉取自身服务数据配置 24 | scrape_configs: 25 | # job名称会增加到拉取到的所有采样点上，同时还有一个instance目标服务的host：port标签也会增加到采样点上 26 | - job_name: 'prometheus' 27 | 28 | # 覆盖global的采样点，拉取时间间隔5s 29 | scrape_interval: 5s 30 | 31 | static_configs: 32 | - targets: ['localhost:9090'] 33 | ``` 34 | 35 | 对于一个完整的配置选项，请见[配置文档](https://prometheus.io/docs/prometheus/latest/configuration/configuration/) 36 | 37 | ### 启动Prometheus 38 | 要使用新创建的配置文件启动Prometheus，请切换到包含Prometheus二进制文件的目录并运行： 39 | ```shell 40 | ./prometheus --config.file=prometheus.yml 41 | ``` 42 | Prometheus服务应该启动了。你可以在浏览器上输入：`http://localhost:9090`, 给它几秒钟从自己的HTTP指标端点收集有关自身的数据。 43 | 44 | 您还可以通过导航到其指标端点来验证Prometheus是否正在提供有关自身的指标：`http://localhost:9090/metrics` 45 | 46 | ### 使用expression browser 47 | 让我们试着看一下Prometheus收集的关于自己的一些数据。 使用Prometheus的内置表达式浏览器，导航到`http://localhost:9090/graph`，并选择带有"Graph"的"Console". 48 | 49 | 在`http://localhost:9090/gmetrics`中收集中，有一个metric叫`prometheus_target_interval_length_seconds`(从目标收集数据的实际时间量)，在表达式的console中输入: 50 | ```shell 51 | prometheus_target_interval_length_seconds 52 | ``` 53 | 这个应该会返回很多不同的时间序列数据(以及每个记录的最新值)，这些度量名称都是`prometheus_target_interval_length_seconds`，但是带有不同的标签列表值，这些标签列表值指定了不同的延迟百分比和目标组间隔。 54 | 55 | 如果我们仅仅对99%的延迟感兴趣，则我们可以使用下面的查询去清洗信息： 56 | ```shell 57 | prometheus_target_interval_length_seconds{quantile="0.99"} 58 | ``` 59 | 为了统计返回时间序列数据个数，你可以写： 60 | ```shell 61 | count(prometheus_target_interval_length_seconds) 62 | ``` 63 | 64 | 有关更多的表达式语言，请见[表达式语言文档](https://prometheus.io/docs/prometheus/latest/querying/basics/) 65 | 66 | ### 使用graph interface 67 | 见图表表达式，导航到`http://localhost:9090/graph`， 然后使用"Graph" tab 68 | 69 | 例如，输入以下表达式来绘制在自我抓取的Prometheus中创建的每秒块速率： 70 | ```shell 71 | rate(prometheus_tsdb_head_chunks_created_total[1m]) 72 | ``` 73 | 试验`graph`范围参数和其他设置。 74 | 75 | ### 启动其他一些采样目标 76 | 让我们让这个更有趣，并开始一些示例目标，让Prometheus抓取。 77 | 78 | `Go`客户端库包含一个示例，该示例为具有不同延迟分布的三个服务导出虚构的RPC延迟。 79 | 80 | 确保已安装`Go`编译器并设置了正常工作的`Go`构建环境（具有正确的GOPATH）。 81 | 82 | 下载Prometheus的Go客户端，运行三个服务: 83 | ```shell 84 | git clone https://github.com/prometheus/client_golang.git 85 | cd client_golang/examples/random 86 | go get -d 87 | go build 88 | 89 | ## 启动三个服务 90 | ./random -listen-address=:8080 91 | ./random -listen-address=:8081 92 | ./random -listen-address=:8082 93 | ``` 94 | 现在你在浏览器输入:`http://localhost:8080/metrics`, `http://localhost:8081/metrics`, `http://localhost:8082/metrics`, 能看到所有采集到的采样点数据。 95 | 96 | ### 配置Prometheus去监控这三个目标服务 97 | 现在我们将会配置Prometheus，拉取三个目标服务的采样点。我们把这三个目标服务组成一个`job`, 叫`example-radom`。 然而，想象成，前两个服务是生产环境服务，后者是测试环境服务。我们可以通过`group`标签分组，要在Prometheus中对此进行建模，我们可以将多组端点添加到单个作业中，为每组目标添加额外的标签。在此示例中，我们将`group ="production"`标签添加到第一组目标，同时将`group ="canary"`添加到第二组。 98 | 99 | 要实现此目的，请将以下作业定义添加到`prometheus.yml`中的`scrape_configs`部分，然后重新启动Prometheus实例： 100 | ```shell 101 | scrape_configs: 102 | - job_name: 'example-random' 103 | 104 | scrape_interval: 5s 105 | 106 | static_configs: 107 | - targets: ['localhost:8080', 'localhost:8081'] 108 | labels: 109 | group: 'production' 110 | 111 | - targets: ['localhost:8082'] 112 | labels: 113 | group: 'test' 114 | ``` 115 | 116 | 转到表达式浏览器并验证Prometheus现在是否有关于这些示例端点公开的时间序列的信息，例如`rpc_durations_seconds`指标。 117 | 118 | ### 为抓取的数据聚合配置规则 119 | 虽然在我们的示例中不是问题，但是在计算`ad-hoc`时，聚合了数千个时间序列的查询会变慢。 为了提高效率，Prometheus允许您通过配置的录制规则将表达式预先记录到全新的持久时间序列中。 假设我们感兴趣的是记录在5分钟窗口内测量的所有实例（但保留作业和服务维度）的平均示例RPC（`rpc_durations_seconds_count`）的每秒速率。 我们可以这样写： 120 | ```shell 121 | avg(rate(rpc_durations_seconds_count[5m])) by (job, service) 122 | ``` 123 | 要将此表达式生成的时间序列记录到名为`job_service：rpc_durations_seconds_count：avg_rate5m`的新度量标准中，请使用以下记录规则创建一个文件并将其另存为`prometheus.rules.yml`： 124 | ```shell 125 | groups: 126 | - name: example 127 | rules: 128 | - record: job_service:rpc_durations_seconds_count:avg_rate5m 129 | expr: avg(rate(rpc_durations_seconds_count[5m])) by (job, service) 130 | ``` 131 | 132 | 要使Prometheus选择此新规则，请在`prometheus.yml`中添加`rule_files`语句。 配置现在应该如下所示： 133 | ```shell 134 | global: 135 | scrape_interval: 15s # By default, scrape targets every 15 seconds. 136 | evaluation_interval: 15s # Evaluate rules every 15 seconds. 137 | 138 | # Attach these extra labels to all timeseries collected by this Prometheus instance. 139 | external_labels: 140 | monitor: 'codelab-monitor' 141 | 142 | rule_files: 143 | - 'prometheus.rules.yml' 144 | 145 | scrape_configs: 146 | - job_name: 'prometheus' 147 | 148 | # Override the global default and scrape targets from this job every 5 seconds. 149 | scrape_interval: 5s 150 | 151 | static_configs: 152 | - targets: ['localhost:9090'] 153 | 154 | - job_name: 'example-random' 155 | 156 | # Override the global default and scrape targets from this job every 5 seconds. 157 | scrape_interval: 5s 158 | 159 | static_configs: 160 | - targets: ['localhost:8080', 'localhost:8081'] 161 | labels: 162 | group: 'production' 163 | 164 | - targets: ['localhost:8082'] 165 | labels: 166 | group: 'canary' 167 | ``` 168 | 使用新配置重新启动Prometheus，并通过表达式浏览器查询或绘制图表，验证带有度量标准名称`job_service：rpc_durations_seconds_count：avg_rate5m`的新时间序列现在可用。 169 | 170 | -------------------------------------------------------------------------------- /prometheus/Installation.md: -------------------------------------------------------------------------------- 1 | ##### 一、使用预编译二进制文件 2 | 我们为Prometheus大多数的官方组件，提供了预编译二进制文件。可用版本[下载](https://prometheus.io/download)列表 3 | 4 | ##### 二、源码安装 5 | 如果要从源码安装Prometheus的官方组件，可以查看各个项目源码目录下的`Makefile` 6 | 7 | ##### 三、Docker安装 8 | 所有Prometheus服务的Docker镜像在官方组织[Quay.io](https://quay.io/repository/prometheus/prometheus)或者[Docker Hub](https://hub.docker.com/u/prom/)下，都是可用的。 9 | 10 | 在`Docker`上运行Prometheus服务，只需要简单地执行`docker run -p 9090:9090 prom/prometheus`命令行即可。这条命令会启动Prometheus服务，使用的是默认配置文件，并对外界暴露`9090`端口。 11 | 12 | Prometheus镜像使用`docker`中的`volumn`卷存储实际度量指标。在生产环境上使用[容器卷](https://docs.docker.com/engine/userguide/containers/dockervolumes/#creating-and-mounting-a-data-volume-container)模式,可以在Prometheus更新和升级时轻松管理Prometheus数据，这种使用`docker volumn`卷方式存储数据，是被`docker`官方强烈推荐的。 13 | 14 | 通过几个选项，可以达到使用自己的配置的目的。下面有两个例子。 15 | 16 | ###### 3.1 卷&绑定挂载 17 | 通过运行以下命令从主机绑定您的prometheus.yml： 18 | > docker run -p 9090:9090 -v /tmp/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus 19 | 20 | 或者为这个配置文件使用一个独立的volumn 21 | > docker run -p 9090:9090 -v /prometheus-data \ 22 | prom/prometheus -config.file=/prometheus-data/prometheus.yml 23 | 24 | ###### 3.2 自定义镜像 25 | 为避免管理主机上的文件并对其进行绑定安装，可以将配置烘焙到映像中。 如果配置本身相当静态并且在所有环境中都相同，则此方法很有效。 26 | 27 | 为此，使用Prometheus配置和`Dockerfile`创建一个新目录，如下所示： 28 | ``` 29 | FROM prom/prometheus 30 | ADD prometheus.yml /etc/prometheus/ 31 | ``` 32 | 33 | 然后编译和运行它： 34 | ``` 35 | docker build -t my-prometheus . 36 | docker run -p 9090:9090 my-prometheus 37 | ``` 38 | 39 | 一个更高级的选项是可以通过一些工具动态地渲染配置，甚至后台定期地更新配置。 40 | 41 | ##### 四、使用配置管理系统 42 | 如果你喜欢使用配置管理系统，你可能对下面地第三方库感兴趣： 43 | 44 | Ansible： 45 | - [Cloud Alchemy/ansible-prometheus](https://github.com/cloudalchemy/ansible-prometheus) 46 | 47 | Chef: 48 | - [rayrod2030/chef-prometheus](https://github.com/rayrod2030/chef-prometheus) 49 | 50 | Puppet： 51 | - [puppet/prometheus](https://forge.puppet.com/puppet/prometheus) 52 | 53 | SaltStack: 54 | - [bechtoldt/saltstack-prometheus-formula](https://github.com/bechtoldt/saltstack-prometheus-formula) 55 | -------------------------------------------------------------------------------- /prometheus/Management_API.md: -------------------------------------------------------------------------------- 1 | Prometheus提供了一组管理API，以简化自动化和集成。 2 | 3 | ##### 一、健康检查 4 | ``` 5 | GET /-/healthy 6 | ``` 7 | 这个端点始终返回200，应用于检查Prometheus的健康状况。 8 | 9 | ##### 二、准备检查 10 | ``` 11 | GET /-/ready 12 | ``` 13 | 当Prometheus准备服务流量（即响应查询）时，此端点返回200。 14 | 15 | ##### 三、重新加载 16 | ``` 17 | PUT /-/reload 18 | POST /-/reload 19 | ``` 20 | 该端点触发Prometheus配置和规则文件的重新加载。 默认情况下它是禁用的，可以通过`--web.enable-lifecycle`标志启用。 21 | 22 | 或者，可以通过将`SIGHUP`发送到Prometheus进程来触发配置重载。 23 | 24 | ##### 四、退出 25 | ``` 26 | PUT /-/quit 27 | POST /-/quit 28 | ``` 29 | 该端点触发Prometheus的正常关闭。 默认情况下它是禁用的，可以通过`--web.enable-lifecycle`标志启用。 30 | 31 | 或者，可以通过将`SIGTERM`发送到Prometheus进程来触发正常关闭。 -------------------------------------------------------------------------------- /prometheus/Migration.md: -------------------------------------------------------------------------------- 1 | 根据我们的[稳定承诺](https://prometheus.io/blog/2016/07/18/prometheus-1-0-released/#fine-print)，Prometheus 2.0版本包含许多向后不兼容的更改。 本文档提供了从Prometheus 1.8迁移到Prometheus 2.0的指导。 2 | 3 | ##### 一、标志 4 | Prometheus命令行标志的格式已更改。现在所有标志都使用双破折号而不是单个破折号。公共标志（`--config.file`， `--web.listen-address`和`--web.external-url`）仍然相同，但除此之外，几乎所有与存储相关的标志都已被删除。 5 | 6 | 一些值得注意的标志已删除： 7 | 8 | - `-alertmanager.url`在Prometheus 2.0中，已删除用于配置静态Alertmanager URL的命令行标志。现在必须通过服务发现来发现Alertmanager，请参阅Alertmanager服务发现。 9 | 10 | - `-log.format`在Prometheus 2.0中，日志只能流式传输到标准错误。 11 | 12 | - `-query.staleness-delta`已重命名为`--query.lookback-delta`; Prometheus 2.0引入了一种处理陈旧性的新机制，请参见陈旧性。 13 | 14 | - `-storage.local.*` Prometheus 2.0引入了一个新的存储引擎，因此删除了与旧引擎相关的所有标志。有关新引擎的信息，请参阅存储。 15 | 16 | - `-storage.remote.*` Prometheus 2.0删除了已经弃用的远程存储标志，如果提供它们将无法启动。要写入InfluxDB，Graphite或OpenTSDB，请使用相关的存储适配器。 17 | 18 | ##### 二、Alertmanager服务发现 19 | 在Prometheus 1.4中引入了Alertmanager服务发现，允许Prometheus使用与刮擦目标相同的机制动态发现Alertmanager复制品。 在Prometheus 2.0中，已删除静态Alertmanager配置的命令行标志，因此以下命令行标志： 20 | > ./prometheus -alertmanager.url=http://alertmanager:9093/ 21 | 22 | 将在`prometheus.yml`配置文件中替换为以下内容： 23 | ``` 24 | alerting: 25 | alertmanagers: 26 | - static_configs: 27 | - targets: 28 | - alertmanager:9093 29 | ``` 30 | 您还可以在Alertmanager配置中使用所有常用的Prometheus服务发现集成和重新标记。 此代码段指示Prometheus使用`name: alertmanger`：alertmanager和非空端口在`default`命名空间中搜索Kubernetes pod。 31 | ``` 32 | alerting: 33 | alertmanagers: 34 | - kubernetes_sd_configs: 35 | - role: pod 36 | tls_config: 37 | ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt 38 | bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token 39 | relabel_configs: 40 | - source_labels: [__meta_kubernetes_pod_label_name] 41 | regex: alertmanager 42 | action: keep 43 | - source_labels: [__meta_kubernetes_namespace] 44 | regex: default 45 | action: keep 46 | - source_labels: [__meta_kubernetes_pod_container_port_number] 47 | regex: 48 | action: drop 49 | ``` 50 | ##### 三、记录规则和报警 51 | 配置警报和录制规则的格式已更改为YAML。 旧格式的录制规则和警报示例： 52 | ``` 53 | job:request_duration_seconds:histogram_quantile99 = 54 | histogram_quantile(0.99, sum(rate(request_duration_seconds_bucket[1m])) by (le, job)) 55 | 56 | ALERT FrontendRequestLatency 57 | IF job:request_duration_seconds:histogram_quantile99{job="frontend"} > 0.1 58 | FOR 5m 59 | ANNOTATIONS { 60 | summary = "High frontend request latency", 61 | } 62 | ``` 63 | 看起来像这样： 64 | ``` 65 | groups: 66 | - name: example.rules 67 | rules: 68 | - record: job:request_duration_seconds:histogram_quantile99 69 | expr: histogram_quantile(0.99, sum(rate(request_duration_seconds_bucket[1m])) 70 | BY (le, job)) 71 | - alert: FrontendRequestLatency 72 | expr: job:request_duration_seconds:histogram_quantile99{job="frontend"} > 0.1 73 | for: 5m 74 | annotations: 75 | summary: High frontend request latency 76 | ``` 77 | 为了帮助进行更改，`promtool`工具具有自动执行规则转换的模式。 给定`.rules`文件，它将以新格式输出`.rules.yml`文件。 例如： 78 | ``` 79 | $ promtool update rules example.rules 80 | ``` 81 | 请注意，您需要使用2.0中的promtool，而不是1.8。 82 | ##### 四、存储 83 | Prometheus 2.0中的数据格式已完全改变，并且不向后兼容1.8。 为了保持对历史监控数据的访问，我们建议您运行至少与Prometheus 2.0实例并行运行至少版本1.8.1的非刮擦Prometheus实例，并让新服务器通过远程读取协议从旧服务器读取现有数据。 84 | 85 | 您的Prometheus 1.8实例应该使用以下标志和仅包含`external_labels`设置（如果有）的配置文件启动： 86 | > $ ./prometheus-1.8.1.linux-amd64/prometheus -web.listen-address ":9094" -config.file old.yml 87 | 88 | 然后可以使用以下标志启动Prometheus 2.0（在同一台机器上）： 89 | > $ ./prometheus-2.0.0.linux-amd64/prometheus --config.file prometheus.yml 90 | 91 | 除了完整的现有配置之外，prometheus.yml还包含哪些节： 92 | ``` 93 | remote_read: 94 | - url: "http://localhost:9094/api/v1/read" 95 | ``` 96 | ##### 五、PromQL 97 | 从PromQL中删除了以下功能： 98 | 99 | - `drop_common_labels`函数 - 应该使用不使用聚合修饰符。 100 | - `keep_common`聚合修饰符 - 应该使用修饰符。 101 | - `count_scalar`函数 - `absent()`或在操作中正确传播标签可以更好地处理用例。 102 | - 103 | 有关详细信息，请参阅[issue＃3060](https://github.com/prometheus/prometheus/issues/3060)。 104 | 105 | ##### 六、杂项 106 | ###### 6.1 普罗米修斯非root用户 107 | Prometheus Docker镜像现在可以作为[非root用户运行Prometheus](https://github.com/prometheus/prometheus/pull/2859)。 如果您希望Prometheus UI / API侦听低端口号（例如，端口80），则需要覆盖它。 对于Kubernetes，您将使用以下YAML： 108 | ``` 109 | apiVersion: v1 110 | kind: Pod 111 | metadata: 112 | name: security-context-demo-2 113 | spec: 114 | securityContext: 115 | runAsUser: 0 116 | ... 117 | ``` 118 | 有关更多详细信息，请参阅[为Pod或容器配置安全上下文](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)。 119 | 120 | 如果您使用的是Docker，则会使用以下代码段： 121 | ``` 122 | docker run -u root -p 80:80 prom/prometheus:v2.0.0-rc.2 --web.listen-address :80 123 | ``` 124 | ###### 6.2 普罗米修斯生命周期 125 | 如果您使用Prometheus `/-/reload`加载HTTP端点在更改时[自动重新加载Prometheus配置](https://prometheus.io/docs/prometheus/latest/configuration/configuration/)，则出于安全原因，默认情况下会禁用这些端点，这是Prometheus 2.0中的。 要启用它们，请设置`--web.enable-lifecycle`标志。 126 | -------------------------------------------------------------------------------- /prometheus/README.md: -------------------------------------------------------------------------------- 1 | 译文：https://prometheus.io/docs/prometheus/latest/getting_started/ 2 | -------------------------------------------------------------------------------- /prometheus/Storage.md: -------------------------------------------------------------------------------- 1 | Prometheus包括一个本地磁盘时间序列数据库，但也可选择与远程存储系统集成。 2 | ##### 一、本地存储 3 | Prometheus的本地时间序列数据库以自定义格式在磁盘上存储时间序列数据。 4 | ###### 1.1 磁盘布局 5 | 摄入的样品分为两个小时。 每个两个小时的时间段包含一个目录，该目录包含一个或多个块文件，该文件包含该时间窗口的所有时间序列样本，以及元数据文件和索引文件（用于将度量名称和标签索引到块文件中的时间序列） ）。 通过API删除系列时，删除记录存储在单独的逻辑删除文件中（而不是立即从块文件中删除数据）。 6 | 7 | 当前传入样本的块保留在内存中，尚未完全保留。 Prometheus服务器在崩溃后重新启动时，可以通过预写日志（WAL）防止崩溃，从而防止崩溃。 预写日志文件以128MB的段存储在wal目录中。 这些文件包含尚未压缩的原始数据，因此它们比常规的块文件大得多。 Prometheus将至少保留3个预写日志文件，但是高流量服务器可能会看到三个以上的WAL文件，因为它需要保留至少两个小时的原始数据。 8 | 9 | Prometheus服务器的数据目录的目录结构如下所示： 10 | ``` 11 | ./data 12 | ├── 01BKGV7JBM69T2G1BGBGM6KB12 13 | │ └── meta.json 14 | ├── 01BKGTZQ1SYQJTR4PB43C8PD98 15 | │ ├── chunks 16 | │ │ └── 000001 17 | │ ├── tombstones 18 | │ ├── index 19 | │ └── meta.json 20 | ├── 01BKGTZQ1HHWHV8FBJXW1Y3W0K 21 | │ └── meta.json 22 | ├── 01BKGV7JC0RY8A6MACW02A2PJD 23 | │ ├── chunks 24 | │ │ └── 000001 25 | │ ├── tombstones 26 | │ ├── index 27 | │ └── meta.json 28 | └── wal 29 | ├── 00000002 30 | └── checkpoint.000001 31 | ``` 32 | 请注意，本地存储的局限性在于它不是集群或复制的。 因此，面对磁盘或节点中断，它不是任意可伸缩的或持久的，应该像对待任何其他类型的单节点数据库一样对待它。 建议将RAID用于磁盘可用性，[快照](https://prometheus.io/docs/prometheus/latest/querying/api/#snapshot)用于备份，容量规划等，以提高耐用性。 通过适当的存储耐久性和计划，可以在本地存储中存储多年的数据。 33 | 34 | 或者，可以通过[远程读/写API](https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage)使用外部存储。 这些系统在耐用性，性能和效率上差异很大，因此需要仔细评估。 35 | 36 | 有关文件格式的更多详细信息，请参阅[TSDB格式](https://github.com/prometheus/tsdb/blob/master/docs/format/README.md)。 37 | 38 | ##### 二、压实 39 | 最初的两个小时的块最终会在后台压缩为更长的块。 40 | 41 | 压缩将创建较大的块，最多保留时间的10％，即31天，以较小者为准。 42 | 43 | ##### 三、运营方面 44 | Prometheus有几个标志，允许配置本地存储。 最重要的是： 45 | 46 | - `--storage.tsdb.path`：这决定了Prometheus写入数据库的位置。 默认为`data/`。 47 | - `--storage.tsdb.retention.time`：这决定了何时删除旧数据。 默认为`15d`。 如果此标志设置为默认值以外的任何值，则覆盖`storage.tsdb.retention`。 48 | - `--storage.tsdb.retention.size`：[EXPERIMENTAL]这确定了存储块可以使用的最大字节数（请注意，这不包括WAL大小，这可能很大）。 最早的数据将被删除。 默认为`0`或禁用。 此标志是实验性的，可以在将来的版本中进行更改。 支持的单位：KB，MB，GB，PB。 例如：“512MB” 49 | - `--storage.tsdb.retention`：不推荐使用此标志，而使用`storage.tsdb.retention.time`。 50 | - `--storage.tsdb.wal-compression`：此标志启用预写日志（WAL）的压缩。 根据您的数据，您可以预期WAL大小将减少一半，而额外的CPU负载却很少。 请注意，如果启用此标志，然后将Prometheus降级到2.11.0以下的版本，则您将需要删除WAL，因为它将不可读。 51 | 52 | 平均而言，Prometheus每个样本仅使用大约1-2个字节。 因此，要规划Prometheus服务器的容量，您可以使用粗略的公式： 53 | > needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample 54 | 55 | 要调整每秒摄取样本的速率，您可以减少抓取的时间序列数（每个目标的目标更少或更少的系列），或者可以增加刮擦间隔。然而，由于一系列样品的压缩，减少系列数可能更有效。 56 | 57 | 如果您的本地存储因任何原因而损坏，最好的办法是关闭Prometheus并删除整个存储目录。 Prometheus的本地存储不支持非POSIX兼容的文件系统，可能会发生损坏，无法恢复。 NFS只是潜在的POSIX，大多数实现都不是。您可以尝试删除单个块目录以解决问题，这意味着每个块目录丢失大约两个小时的数据时间窗口。同样，普罗米修斯的本地存储并不意味着持久的长期存储。 58 | 59 | 如果同时指定了时间和大小保留策略，则在该时刻将使用先触发的策略。 60 | 61 | ##### 三、远程存储集成 62 | Prometheus的本地存储在可扩展性和耐用性方面受到单个节点的限制。 Prometheus没有尝试解决Prometheus本身的集群存储问题，而是提供了一组允许与远程存储系统集成的接口。 63 | ###### 3.1 概述 64 | rometheus以两种方式与远程存储系统集成： 65 | 66 | - Prometheus可以以标准格式将其提取的样本写入远程URL。 67 | - Prometheus可以以标准格式从远程URL读取（返回）样本数据。 68 | 69 | ![url](https://prometheus.io/docs/prometheus/latest/images/remote_integrations.png) 70 | 71 | 读写协议都使用基于HTTP的snappy压缩协议缓冲区编码。这些协议尚未被视为稳定的API，并且可能会在将来更改为使用gRPC over HTTP/2，此时可以安全地假设Prometheus和远程存储之间的所有跃点都支持HTTP/2。 72 | 73 | 有关在Prometheus中配置远程存储集成的详细信息，请参阅Prometheus配置文档的[远程写入](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write)和[远程读取](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_read)部分。 74 | 75 | 有关请求和响应消息的详细信息，请参阅[远程存储协议缓冲区](https://github.com/prometheus/prometheus/blob/master/prompb/remote.proto)定义。 76 | 77 | 请注意，在读取路径上，Prometheus仅从远程端获取一组标签选择器和时间范围的原始系列数据。对原始数据的所有PromQL评估仍然发生在Prometheus本身。这意味着远程读取查询具有一定的可伸缩性限制，因为需要首先将所有必需的数据加载到查询Prometheus服务器中，然后在那里进行处理。但是，支持PromQL的完全分布式评估暂时被认为是不可行的。 78 | ###### 3.2 现有的集成 79 | 要了解有关与远程存储系统的现有集成的更多信息，请参阅[Integrations文档](https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage)。 80 | -------------------------------------------------------------------------------- /prometheus/configuration/Altering_rules.md: -------------------------------------------------------------------------------- 1 | 警报规则允许您基于Prometheus表达式语言表达式定义警报条件，并将有关触发警报的通知发送到外部服务。 每当警报表达式在给定时间点生成一个或多个向量元素时，警报将计为这些元素的标签集的活动状态。 2 | 3 | ##### 一、定义报警规则 4 | 警报规则在Prometheus中以与记录规则相同的方式配置。 5 | 6 | 带警报的示例规则文件将是： 7 | ``` 8 | groups: 9 | - name: example 10 | rules: 11 | - alert: HighErrorRate 12 | expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5 13 | for: 10m 14 | labels: 15 | severity: page 16 | annotations: 17 | summary: High request latency 18 | ``` 19 | 可选的`for`子句使Prometheus在第一次遇到新的表达式输出向量元素和将此警告作为此元素的触发计数之间等待一段时间。 在这种情况下，Prometheus将在每次评估期间检查警报是否继续处于活动状态10分钟，然后再触发警报。 处于活动状态但尚未触发的元素处于暂挂状态。 20 | 21 | `labels`子句允许指定要附加到警报的一组附加标签。 任何现有的冲突标签都将被覆盖。 标签值可以是模板化的。 22 | 23 | `annotations`子句指定一组信息标签，可用于存储更长的附加信息，例如警报描述或Runbook链接。 注释值可以是模板化的。 24 | 25 | ##### 二、模板 26 | 可以使用控制台模板模板化标签和注释值。 `$labels`变量保存警报实例的标签键/值对，`$value`保存警报实例的评估值。 27 | ``` 28 | # 要插入触发元素的标签值： 29 | {{ $labels. }} 30 | # 要插入触发元素的数值表达式值： 31 | {{ $value }} 32 | ``` 33 | 例子： 34 | ``` 35 | groups: 36 | - name: example 37 | rules: 38 | 39 | # 对于任何无法访问> 5分钟的实例的警报。 40 | - alert: InstanceDown 41 | expr: up == 0 42 | for: 5m 43 | labels: 44 | severity: page 45 | annotations: 46 | summary: "Instance {{ $labels.instance }} down" 47 | description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes." 48 | 49 | # 对中值请求延迟> 1s的任何实例发出警报。 50 | - alert: APIHighRequestLatency 51 | expr: api_http_request_latencies_second{quantile="0.5"} > 1 52 | for: 10m 53 | annotations: 54 | summary: "High request latency on {{ $labels.instance }}" 55 | description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)" 56 | ``` 57 | 58 | ##### 三、在运行时检查警报 59 | 要手动检查哪些警报处于活动状态（待处理或触发），请导航至Prometheus实例的"警报"选项卡。 这将显示每个定义的警报当前处于活动状态的确切标签集。 60 | 61 | 对于待处理和触发警报，Prometheus还存储`ALERTS{alertname="",alertstate ="pending|firing",}`形式的合成时间序列。 只要警报处于指示的活动（挂起或触发）状态，样本值就会设置为`1`，并且当不再是这种情况时，系列会标记为过时。 62 | 63 | ##### 四、发送提醒通知 64 | 普罗米修斯的警报规则很好地解决了现在的问题，但它们并不是一个完全成熟的通知解决方案。 需要另一层来在简单警报定义之上添加摘要，通知速率限制，静默和警报依赖性。 在普罗米修斯的生态系统中，Alertmanager承担了这一角色。 因此，Prometheus可以被配置为周期性地向Alertmanager实例发送关于警报状态的信息，然后该实例负责调度正确的通知。 65 | Prometheus可以配置为通过其服务发现集成自动发现可用的Alertmanager实例。 66 | -------------------------------------------------------------------------------- /prometheus/configuration/README.md: -------------------------------------------------------------------------------- 1 | 译文：https://prometheus.io/docs/prometheus/latest/configuration/configuration/ 2 | -------------------------------------------------------------------------------- /prometheus/configuration/Recording_rules.md: -------------------------------------------------------------------------------- 1 | ##### 一、配置规则 2 | Prometheus支持两种类型的规则，这些规则可以定期配置，然后定期评估：记录规则和[警报规则](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)。 要在Prometheus中包含规则，请创建包含必要规则语句的文件，并让Prometheus通过Prometheus配置中的`rule_files`字段加载文件。 规则文件使用YAML。 3 | 4 | 通过将`SIGHUP`发送到Prometheus进程，可以在运行时重新加载规则文件。 仅当所有规则文件格式正确时才会应用更改。 5 | ##### 二、语法检查规则 6 | 要在不启动Prometheus服务器的情况下快速检查规则文件在语法上是否正确，请安装并运行Prometheus的`promtool`命令行实用工具： 7 | ``` 8 | go get github.com/prometheus/prometheus/cmd/promtool 9 | promtool check rules /path/to/example.rules.yml 10 | ``` 11 | 当文件在语法上有效时，检查器将已解析规则的文本表示打印到标准输出，然后以`0`返回状态退出。 12 | 13 | 如果存在任何语法错误或无效的输入参数，则会向标准错误输出错误消息，并以`1`返回状态退出。 14 | 15 | ##### 三、录制规则 16 | 录制规则允许您预先计算经常需要或计算上昂贵的表达式，并将其结果保存为一组新的时间序列。 因此，查询预先计算的结果通常比每次需要时执行原始表达式快得多。 这对于仪表板尤其有用，仪表板需要在每次刷新时重复查询相同的表达式。 17 | 18 | 记录和警报规则存在于规则组中。 组内的规则以固定间隔顺序运行。 19 | 20 | 规则文件的语法是： 21 | ``` 22 | groups: 23 | [ - ] 24 | ``` 25 | 一个简单的示例规则文件将是： 26 | ``` 27 | groups: 28 | - name: example 29 | rules: 30 | - record: job:http_inprogress_requests:sum 31 | expr: sum(http_inprogress_requests) by (job) 32 | ``` 33 | ###### 3.1 `` 34 | ``` 35 | # 组的名称。 在文件中必须是唯一的。 36 | name: 37 | 38 | # 评估组中的规则的频率。 39 | [ interval: | default = global.evaluation_interval ] 40 | 41 | rules: 42 | [ - ... ] 43 | ``` 44 | ###### 3.2 `` 45 | 记录规则的语法是： 46 | ``` 47 | # 要输出的时间序列的名称。 必须是有效的度量标准名称。 48 | record: 49 | 50 | # 要评估的PromQL表达式。 每个评估周期都会在当前时间进行评估，并将结果记录为一组新的时间序列，其中度量标准名称由“记录”给出。 51 | expr: 52 | 53 | # 在存储结果之前添加或覆盖的标签。 54 | labels: 55 | [ : ] 56 | ``` 57 | 警报规则的语法是： 58 | ``` 59 | # 警报的名称。 必须是有效的度量标准名称。 60 | alert: 61 | 62 | # 要评估的PromQL表达式。 每个评估周期都会在当前时间进行评估，并且所有结果时间序列都会成为待处理/触发警报。 63 | expr: 64 | 65 | # 警报一旦被退回这段时间就会被视为开启。 66 | # 尚未解雇的警报被认为是未决的。 67 | [ for: | default = 0s ] 68 | 69 | # 为每个警报添加或覆盖的标签。 70 | labels: 71 | [ : ] 72 | 73 | # 要添加到每个警报的注释。 74 | annotations: 75 | [ : ] 76 | ``` 77 | -------------------------------------------------------------------------------- /prometheus/configuration/Template_examples.md: -------------------------------------------------------------------------------- 1 | Prometheus支持在警报的注释和标签以及服务的控制台页面中进行模板化。 模板能够针对本地数据库运行查询，迭代数据，使用条件，格式化数据等.Prometheus模板语言基于[Go模板系统](https://golang.org/pkg/text/template/)。 2 | ##### 一、简单的警报字段模板 3 | ``` 4 | alert: InstanceDown 5 | expr: up == 0 6 | for: 5m 7 | labels: 8 | severity: page 9 | annotations: 10 | summary: "Instance {{$labels.instance}} down" 11 | description: "{{$labels.instance}} of job {{$labels.job}} has been down for more than 5 minutes." 12 | ``` 13 | 对于每个触发的警报，将在每次规则迭代期间执行警报字段模板，因此请保持所有查询和模板的轻量级。 如果您需要更复杂的警报模板，建议您改为链接到控制台。 14 | ##### 二、简单的迭代 15 | 这将显示实例列表以及它们是否已启动： 16 | ``` 17 | {{ range query "up" }} 18 | {{ .Labels.instance }} {{ .Value }} 19 | {{ end }} 20 | ``` 21 | 特别的`.`变量包含每个循环迭代的当前样本的值。 22 | ##### 三、展示一个值 23 | ``` 24 | {{ with query "some_metric{instance='someinstance'}" }} 25 | {{ . | first | value | humanize }} 26 | {{ end }} 27 | ``` 28 | Go和Go的模板语言都是强类型的，因此必须检查是否返回了样本以避免执行错误。 例如，如果抓取或规则评估尚未运行，或者主机已关闭，则可能会发生这种情况。 29 | 30 | 包含的`prom_query_drilldown`模板处理此问题，允许格式化结果，并链接到表达式浏览器。 31 | ##### 四、使用命令行URL参数 32 | ``` 33 | {{ with printf "node_memory_MemTotal{job='node',instance='%s'}" .Params.instance | query }} 34 | {{ . | first | value | humanize1024}}B 35 | {{ end }} 36 | ``` 37 | 如果以`console.html?instance = hostname`的身份访问，`.Params.instance`将评估为`hostname`。 38 | ##### 五、高级迭代 39 | ``` 40 | 41 | {{ range printf "node_network_receive_bytes{job='node',instance='%s',device!='lo'}" .Params.instance | query | sortByLabel "device"}} 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | {{ end }} 51 |
{{ .Labels.device }}
Received{{ with printf "rate(node_network_receive_bytes{job='node',instance='%s',device='%s'}[5m])" .Labels.instance .Labels.device | query }}{{ . | first | value | humanize }}B/s{{end}}
Transmitted{{ with printf "rate(node_network_transmit_bytes{job='node',instance='%s',device='%s'}[5m])" .Labels.instance .Labels.device | query }}{{ . | first | value | humanize }}B/s{{end}}
52 | ``` 53 | 在这里，我们遍历所有网络设备并显示每个网络设备的网络流量。 54 | 55 | 由于`range`操作未指定变量，因此。循环内部`.Params.instance`不可用。 现在是循环变量。 56 | ##### 六、定义可重用模板 57 | Prometheus支持定义可重用的模板。 当与控制台库支持结合使用时，这一功能特别强大，允许跨控制台共享模板。 58 | ``` 59 | {{/* Define the template */}} 60 | {{define "myTemplate"}} 61 | do something 62 | {{end}} 63 | 64 | {{/* Use the template */}} 65 | {{template "myTemplate"}} 66 | ``` 67 | 模板仅限于一个参数。 `args`函数可用于包装多个参数。 68 | ``` 69 | {{define "myMultiArgTemplate"}} 70 | First argument: {{.arg0}} 71 | Second argument: {{.arg1}} 72 | {{end}} 73 | {{template "myMultiArgTemplate" (args 1 2)}} 74 | ``` 75 | -------------------------------------------------------------------------------- /prometheus/configuration/Template_reference.md: -------------------------------------------------------------------------------- 1 | Prometheus支持在警报的注释和标签以及服务的控制台页面中进行模板化。 模板能够针对本地数据库运行查询，迭代数据，使用条件，格式化数据等.Prometheus模板语言基于Go模板系统。 2 | ##### 一、数据结构题 3 | 处理时间序列数据的主要数据结构是样本，定义如下： 4 | ``` 5 | type sample struct { 6 | Labels map[string]string 7 | Value float64 8 | } 9 | ``` 10 | 样本的度量标准名称在`Labels`映射中的特殊`__name__`标签中进行编码。 11 | 12 | `[]sample`表示样本列表。 13 | 14 | Go中的`interface{}`类似于C中的void指针。 15 | ##### 二、函数 16 | 除了Go模板提供的[默认功能](https://golang.org/pkg/text/template/#hdr-Functions)外，Prometheus还提供了更轻松处理模板中查询结果的功能。 17 | 18 | 如果在管道中使用函数，则管道值将作为最后一个参数传递。 19 | ###### 2.1 查询 20 | 名字 | 参数 | 返回值 |解析 21 | ---|---|---|--- 22 | query| query string |[]sample |查询数据库，不支持返回范围向量。 23 | first| []sample| sample |索引等于0 24 | label| label, sample |string |相当于`index sample.Labels标签` 25 | value| sample |float64| 相当于 `sample.Value` 26 | sortByLabel| label, []samples| []sample| 按给定标签对样品进行排序。 是稳定排序。 27 | `first`，`label`和`value`旨在使查询结果易于在管道中使用。 28 | ###### 2.2 数字 29 | 名字| 参数| 返回| 解析 30 | ---|---|---|--- 31 | humanize |number| string |使用度量标准前缀将数字转换为更易读的格式。 32 | humanize1024| number |string |像`humanize`一样，但使用1024作为基础而不是1000。 33 | humanizeDuration| number |string| 将持续时间（以秒为单位）转换为更易读的格式。 34 | humanizeTimestamp| number |string |将Unix时间戳以秒为单位转换为更易读的格式。 35 | `Humanizing `功能旨在为人类消费产生合理的输出，并且不保证在Prometheus版本之间返回相同的结果。 36 | ###### 2.3 字符串 37 | 名字| 参数| 返回| 解析 38 | ---|---|---|--- 39 | title| string |string |`strings.Title`, 大写每个单词的第一个字符。 40 | toUpper| string |string |`strings.ToUpper`, 将所有字符转换为大写。 41 | toLower |string |string |`strings.ToLower`, 将所有字符转换为小写。 42 | match| pattern, text |boolean |`regexp.MatchString` 测试未锚定的正则表达式匹配。 43 | reReplaceAll| pattern, replacement, text| string |`Regexp.ReplaceAllString` Regexp替换，未经修复。 44 | graphLink| expr |string |返回表达式的表达式浏览器中图表视图的路径。 45 | tableLink| expr |string| 返回表达式的表达式浏览器中表格（“Console”）视图的路径。 46 | ###### 2.4 其他 47 | 名字| 参数| 返回| 解析 48 | ---|---|---|--- 49 | args| []interface{}| map[string]interface{}| 这会将对象列表转换为具有键`arg0`，`arg1`等的映射。这旨在允许将多个参数传递给模板。 50 | tmpl| string, []interface{} |nothing |与内置模板一样，但允许非文字作为模板名称。 请注意，结果被认为是安全的，不会自动转义。 仅适用于游戏机。 51 | safeHtml| string |string| 将字符串标记为不需要自动转义的HTML。 52 | 53 | ##### 三、模板类型的区别 54 | 每种类型的模板都提供可用于参数化模板的不同信息，并具有一些其他差异。 55 | ###### 3.1 报警字段模板 56 | `.Value`和`.Labels`包含警报值和标签。 为方便起见，它们也作为`$value`和`$labels`变量公开。 57 | ###### 3.2 控制台模板 58 | 控制台暴露在`/consoles/`上，并且来自`-web.console.templates`标志指向的目录。 59 | 60 | 控制台模板使用[html/template](https://golang.org/pkg/html/template/)呈现，提供自动转义功能。 要绕过自动转义，请使用`safe*`功能。， 61 | 62 | URL参数在`.Params`中以地图形式提供。 要使用相同的名称访问多个URL参数，`.RawParams`是每个参数的列表值的映射。 URL路径在`.Path`中可用，不包括`/consoles/`前缀。 63 | 64 | 控制台还可以访问在`-web.console.libraries`标志指向的目录中的* `.lib`文件中找到的`{{define"templateName"}}...{{end}}`定义的所有模板。 由于这是一个共享命名空间，请注意避免与其他用户发生冲突。 以`prom`，`_prom`和`__`开头的模板名称保留供Prometheus使用，上面列出的函数也是如此。 65 | -------------------------------------------------------------------------------- /prometheus/configuration/Unit_Testing_for_Rules.md: -------------------------------------------------------------------------------- 1 | 您可以使用`promtool`来测试您的规则。 2 | ``` 3 | # 单个测试文件 4 | ./promtool test rules test.yml 5 | 6 | # 多个测试文件 7 | ./promtool test rules test1.yml test2.yml test3.yml 8 | ``` 9 | ##### 一、测试文件格式 10 | ``` 11 | # 这是要考虑进行测试的规则文件列表。 12 | rule_files: 13 | [ - ] 14 | 15 | # 可选的, 默认 = 1m 16 | evaluation_interval: 17 | 18 | # 下面列出组名称的顺序将是规则组的评估顺序（在给定的评估时间）。 订单仅适用于下面提到的组。 19 | # 下面不需要提到所有组。 20 | group_eval_order: 21 | [ - ] 22 | 23 | # 所有测试都列在这里。 24 | tests: 25 | [ - ] 26 | ``` 27 | ###### 1.1 `` 28 | ``` 29 | # 系列数据 30 | interval: 31 | input_series: 32 | [ - ] 33 | 34 | # 上述数据的单元测试 35 | 36 | # 警报规则的单元测试。 我们从输入文件中考虑警报规则。 37 | alert_rule_test: 38 | [ - ] 39 | 40 | # 单元测试PromQL表达式。 41 | promql_expr_test: 42 | [ - ] 43 | ``` 44 | ###### 1.2 `` 45 | ``` 46 | # 这遵循通常的系列符号 '{ 31 | 32 | 35 | 36 | 37 | 38 | 42 | 43 | 44 | 45 | 49 | 50 | {{template "prom_right_table_tail"}} 51 | 52 | 53 | {{template "prom_content_head" .}} 54 |

MyJob

55 | 56 |

Queries

57 |
58 | 69 | 70 | {{template "prom_content_tail" .}} 71 | 72 | {{template "tail"}} 73 | ``` 74 | `prom_right_table_head`和`prom_right_table_tail`模板包含右侧表。这是可选的。 75 | 76 | `prom_query_drilldown`是一个模板，它将评估传递给它的表达式，格式化它，并链接到表达式浏览器中的表达式。第一个参数是表达式。第二个参数是要使用的单位。第三个参数是如何格式化输出。只需要第一个参数。 77 | 78 | `prom_query_drilldown`的第三个参数的有效输出格式： 79 | 80 | - 未指定：默认转到显示输出。 81 | - `humanize`：使用指标[前缀显示](https://en.wikipedia.org/wiki/Metric_prefix)结果。 82 | - `humanizeNoSmallPrefix`：对于大于1的绝对值，使用度量标准[前缀显示](https://en.wikipedia.org/wiki/Metric_prefix)结果。对于小于1的绝对值，显示3位有效数字。这对于避免可以通过人性化生成的诸如每秒毫微秒的单位是有用的。 83 | - `humanize1024`：使用1024而不是1000的基数显示人性化结果。这通常与`B`一起用作生成`KiB`和`MiB`等单位的第二个参数。 84 | - `printf.3g`：显示3位有效数字。 85 | 86 | 可以定义自定义格式。有关示例，请参阅[prom.lib](https://github.com/prometheus/prometheus/blob/master/console_libraries/prom.lib)。 87 | 88 | ##### 三、图库 89 | 图库被调用为： 90 | ``` 91 |
92 | 98 | ``` 99 | `head`模板加载所需的Javascript和CSS。 100 | 101 | 图库的参数： 102 | 103 | | 名字 | 描述 | 104 | | ---|--- | 105 | | expr| 必选. 表达式到图表。 可以是一个清单。| 106 | | node| 必选. 要渲染的DOM节点。 | 107 | | duration| 可选. 图表的持续时间。 默认为1小时。 | 108 | | endTime |可选. 图表结束时的Unixtime。 默认为现在。 | 109 | | width |可选. 图表的宽度，不包括标题。 默认为自动检测。| 110 | | height |可选. 图表的高度，不包括标题和图例。 默认为200像素。| 111 | | min | 可选. 最小x轴值。 默认为最低数据值。| 112 | | max | 可选. 最小y轴值。 默认为最高数据值。 | 113 | | renderer| 可选. 图表类型。 选项`line`和`area`（堆叠图）。 默认为行。| 114 | | name | 可选. 图例和悬停细节中的图表标题。 如果传递了一个字符串，`[[label]]`将被替换为标签值。 如果传递了一个函数，它将传递一个标签映射，并应该将该名称作为字符串返回。 可以是一个清单。 | 115 | | xTitle | 可选. x轴的标题。 默认为`Time`。| 116 | | yUnits | 可选. y轴的单位。 默认为空。 | 117 | | yTitle | 可选. y轴的标题。 默认为空。| 118 | | yAxisFormatter | 可选. y轴的数字格式化程序。 默认为`PromConsole.NumberFormatter.humanize`。| 119 | | yHoverFormatter| 可选. 悬停细节的数字格式化程序。 默认为`PromConsole.NumberFormatter.humanizeExact`。| 120 | | colorScheme| 可选. 图表使用的配色方案。 可以是十六进制[颜色代码列表](https://github.com/shutterstock/rickshaw/blob/master/src/js/Rickshaw.Fixtures.Color.js)，也可以是人力车支持的颜色方案名称之一。 默认为`colorwheel`。 | 121 | 122 | 如果`expr`和`name`都是列表，则它们的长度必须相同。 该名称将应用于相应表达式的图。 123 | 124 | `yAxisFormatter`和`yHoverFormatter`的有效选项： 125 | 126 | - `PromConsole.NumberFormatter.humanize`：使用度[量标准前缀](https://en.wikipedia.org/wiki/Metric_prefix)的格式。 127 | - `PromConsole.NumberFormatter.humanizeNoSmallPrefix`：对于大于1的绝对值，使用度量标准前缀进行格式化。 对于小于1的绝对值，请使用3位有效数字格式。 这对于避免`PromConsole.NumberFormatter.humanize`可以生成的每秒毫秒数等单位很有用。 128 | - `PromConsole.NumberFormatter.humanize1024`：使用1024而不是1000的基数格式化人性化结果。 129 | -------------------------------------------------------------------------------- /visualization/Expression_browser.md: -------------------------------------------------------------------------------- 1 | 表达式浏览器在Prometheus服务器上的`/graph`处可用，允许您输入任何表达式并在表格中查看其结果或随时间变化。 2 | 3 | 这主要用于临时查询和调试。 对于图形，请使用[Grafana](https://prometheus.io/docs/visualization/grafana/)或[控制台模板](https://prometheus.io/docs/visualization/consoles/)。 4 | -------------------------------------------------------------------------------- /visualization/Grafana.md: -------------------------------------------------------------------------------- 1 | [Grafana](http://grafana.org/)支持查询Prometheus。从Grafana 2.5.0 (2015-10-28)开始Prometheus可以作为它的数据源。 2 | 3 | 以下显示了一个示例Grafana仪表板，它向Prometheus查询数据： 4 | ![Deme Dashboard](https://prometheus.io/assets/grafana_prometheus.png) 5 | 6 | ##### 一、安装 7 | Grafana的完整安装教程，详见[Grafana官方文档](http://docs.grafana.org/installation/) 8 | 9 | ##### 二、使用 10 | 默认情况下，Grafana将监听[http://localhost:3000](http://localhost:3000)。默认登录用户名和密码"admin/admin"。 11 | 12 | ###### 2.1 创建一个Prometheus数据源 13 | 14 | 创建一个Prometheus数据源： 15 | 1. 点击Grafana的logo，打开工具栏。 16 | 2. 在工具栏中，点击"Data Source"菜单。 17 | 3. 点击"Add New"。 18 | 4. 数据源Type选择"Prometheus"。 19 | 5. 设置Prometheus服务访问地址（例如：`http://localhost:9090`）。 20 | 6. 调整其他想要的设置（例如：关闭代理访问）。 21 | 7. 点击"Add"按钮，保存这个新数据源。 22 | 23 | 下面显示了一个Prometheus数据源配置例子： 24 | ![Prometheus configuration in Grafana](https://prometheus.io/assets/grafana_configuring_datasource.png) 25 | 26 | ###### 2.2 创建一个Prometheus图表 27 | 按照添加新Grafana图的标准方式。 然后： 28 | 1. 点击图表Graph的title，它在图表上方中间。然后点击"Edit"。 29 | 2. 在"Metrics"tab下面，选择你的Prometheus数据源（下面右边）。 30 | 3. 在"Query"字段中输入你想查询的Prometheus表达式，同时使用"Metrics"字段通过自动补全查找度量指标。 31 | 4. 为了格式化时间序列的图例名称，使用“Legend format”图例格式输入。例如，为了仅仅显示这个标签为`method`和`status`的查询结果，你可以使用图例格式`{{method{} - {{status}}`。 32 | 5. 调节其他的Graph设置，知道你有一个工作图表。 33 | 34 | 以下显示了Prometheus图配置示例： 35 | ![Prometheus图表](https://prometheus.io/assets/grafana_qps_graph.png) 36 | 37 | ###### 2.3 从Grafana.com导入预构建的dashboard 38 | Grafana.com维护着一组[共享仪表板](https://grafana.com/dashboards)，可以下载并与Grafana的独立实例一起使用。 使用Grafana.com"Filter"选项仅浏览"Prometheus"数据源的仪表板。 39 | 40 | 您当前必须手动编辑下载的JSON文件并更正`datasource`：条目以反映您为Prometheus服务器选择的Grafana数据源名称。 使用“仪表板”→“主页”→“导入”选项将已编辑的仪表板文件导入Grafana安装。 41 | -------------------------------------------------------------------------------- /visualization/README.md: -------------------------------------------------------------------------------- 1 | 译文：https://prometheus.io/docs/visualization/browser/ 2 | --------------------------------------------------------------------------------
MyJob{{ template "prom_query_drilldown" (args "sum(up{job='myjob'})") }} 33 | / {{ template "prom_query_drilldown" (args "count(up{job='myjob'})") }} 34 |
CPU{{ template "prom_query_drilldown" (args 39 | "avg by(job)(rate(process_cpu_seconds_total{job='myjob'}[5m]))" 40 | "s/s" "humanizeNoSmallPrefix") }} 41 |
Memory{{ template "prom_query_drilldown" (args 46 | "avg by(job)(process_resident_memory_bytes{job='myjob'})" 47 | "B" "humanize1024") }} 48 |