# README
* [全书组织](/prometheus-handbook/introduction)
## Part I - Prometheus基础
* [第1章 天降奇兵](/prometheus-handbook/parti-prometheus-ji-chu/quickstart)
* [Prometheus简介](/prometheus-handbook/parti-prometheus-ji-chu/quickstart/why-monitor)
* [初识Prometheus](/prometheus-handbook/parti-prometheus-ji-chu/quickstart/prometheus-quick-start)
* [安装Prometheus Server](/prometheus-handbook/parti-prometheus-ji-chu/quickstart/prometheus-quick-start/install-prometheus-server)
* [使用Node Exporter采集主机数据](/prometheus-handbook/parti-prometheus-ji-chu/quickstart/prometheus-quick-start/use-node-exporter)
* [使用PromQL查询监控数据](/prometheus-handbook/parti-prometheus-ji-chu/quickstart/prometheus-quick-start/promql_quickstart)
* [监控数据可视化](/prometheus-handbook/parti-prometheus-ji-chu/quickstart/prometheus-quick-start/use-grafana-create-dashboard)
* [任务和实例](/prometheus-handbook/parti-prometheus-ji-chu/quickstart/prometheus-job-and-instance)
* [Prometheus核心组件](/prometheus-handbook/parti-prometheus-ji-chu/quickstart/prometheus-arch)
* [小结](/prometheus-handbook/parti-prometheus-ji-chu/quickstart/summary)
* [第2章 探索PromQL](/prometheus-handbook/parti-prometheus-ji-chu/promql)
* [理解时间序列](/prometheus-handbook/parti-prometheus-ji-chu/promql/what-is-prometheus-metrics-and-labels)
* [Metrics类型](/prometheus-handbook/parti-prometheus-ji-chu/promql/prometheus-metrics-types)
* [初识PromQL](/prometheus-handbook/parti-prometheus-ji-chu/promql/prometheus-query-language)
* [PromQL操作符](/prometheus-handbook/parti-prometheus-ji-chu/promql/prometheus-promql-operators-v2)
* [PromQL聚合操作](/prometheus-handbook/parti-prometheus-ji-chu/promql/prometheus-aggr-ops)
* [PromQL内置函数](/prometheus-handbook/parti-prometheus-ji-chu/promql/prometheus-promql-functions)
* [在HTTP API中使用PromQL](/prometheus-handbook/parti-prometheus-ji-chu/promql/prometheus-promql-with-http-api)
* [最佳实践：4个黄金指标和USE方法](/prometheus-handbook/parti-prometheus-ji-chu/promql/prometheus-promql-best-praticase)
* [小结](/prometheus-handbook/parti-prometheus-ji-chu/promql/summary)
* [第3章 Prometheus告警处理](/prometheus-handbook/parti-prometheus-ji-chu/alert)
* [Prometheus告警简介](/prometheus-handbook/parti-prometheus-ji-chu/alert/prometheus-alert-manager-overview)
* [自定义Prometheus告警规则](/prometheus-handbook/parti-prometheus-ji-chu/alert/prometheus-alert-rule)
* [部署AlertManager](/prometheus-handbook/parti-prometheus-ji-chu/alert/install-alert-manager)
* [Alertmanager配置概述](/prometheus-handbook/parti-prometheus-ji-chu/alert/alert-manager-config)
* [基于标签的告警处理路由](/prometheus-handbook/parti-prometheus-ji-chu/alert/alert-manager-route)
* [使用Receiver接收告警信息](/prometheus-handbook/parti-prometheus-ji-chu/alert/alert-manager-use-receiver)
* [集成邮件系统](/prometheus-handbook/parti-prometheus-ji-chu/alert/alert-manager-use-receiver/alert-with-smtp)
* [集成Slack](/prometheus-handbook/parti-prometheus-ji-chu/alert/alert-manager-use-receiver/alert-with-slack)
* [集成企业微信](/prometheus-handbook/parti-prometheus-ji-chu/alert/alert-manager-use-receiver/alert-with-wechat)
* [集成钉钉：基于Webhook的扩展](/prometheus-handbook/parti-prometheus-ji-chu/alert/alert-manager-use-receiver/alert-manager-extension-with-webhook)
* [告警模板详解](/prometheus-handbook/parti-prometheus-ji-chu/alert/alert-template)
* [屏蔽告警通知](/prometheus-handbook/parti-prometheus-ji-chu/alert/alert-manager-inhibit)
* [使用Recoding Rules优化性能](/prometheus-handbook/parti-prometheus-ji-chu/alert/prometheus-recoding-rules)
* [小结](/prometheus-handbook/parti-prometheus-ji-chu/alert/summary)
## Part II - Prometheus进阶
* [第4章 Exporter详解](/prometheus-handbook/part-ii-prometheus-jin-jie/exporter)
* [Exporter是什么](/prometheus-handbook/part-ii-prometheus-jin-jie/exporter/what-is-prometheus-exporter)
* [常用Exporter](/prometheus-handbook/part-ii-prometheus-jin-jie/exporter/commonly-eporter-usage)
* [容器监控：cAdvisor](/prometheus-handbook/part-ii-prometheus-jin-jie/exporter/commonly-eporter-usage/use-prometheus-monitor-container)
* [监控MySQL运行状态：MySQLD Exporter](/prometheus-handbook/part-ii-prometheus-jin-jie/exporter/commonly-eporter-usage/use-promethues-monitor-mysql)
* [网络探测：Blackbox Exporter](/prometheus-handbook/part-ii-prometheus-jin-jie/exporter/commonly-eporter-usage/install_blackbox_exporter)
* [使用Java自定义Exporter](/prometheus-handbook/part-ii-prometheus-jin-jie/exporter/custom_exporter_with_java)
* [使用Client Java构建Exporter程序](/prometheus-handbook/part-ii-prometheus-jin-jie/exporter/custom_exporter_with_java/client_library_java)
* [在应用中内置Prometheus支持](/prometheus-handbook/part-ii-prometheus-jin-jie/exporter/custom_exporter_with_java/custom_app_support_prometheus)
* [小结](/prometheus-handbook/part-ii-prometheus-jin-jie/exporter/summary)
* [第5章 数据与可视化](/prometheus-handbook/part-ii-prometheus-jin-jie/grafana)
* [使用Console Template](/prometheus-handbook/part-ii-prometheus-jin-jie/grafana/use-console-template)
* [Grafana的基本概念](/prometheus-handbook/part-ii-prometheus-jin-jie/grafana/grafana-intro)
* [Grafana与数据可视化](/prometheus-handbook/part-ii-prometheus-jin-jie/grafana/grafana-panels)
* [变化趋势：Graph面板](/prometheus-handbook/part-ii-prometheus-jin-jie/grafana/grafana-panels/use_graph_panel)
* [分布统计：Heatmap面板](/prometheus-handbook/part-ii-prometheus-jin-jie/grafana/grafana-panels/use_heatmap_panel)
* [当前状态：SingleStat面板](/prometheus-handbook/part-ii-prometheus-jin-jie/grafana/grafana-panels/use_singlestat_panel)
* [模板化Dashboard](/prometheus-handbook/part-ii-prometheus-jin-jie/grafana/templating)
* [小结](/prometheus-handbook/part-ii-prometheus-jin-jie/grafana/summary)
* [第6章 集群与高可用](/prometheus-handbook/part-ii-prometheus-jin-jie/readmd)
* [本地存储](/prometheus-handbook/part-ii-prometheus-jin-jie/readmd/prometheus-local-storage)
* [远程存储](/prometheus-handbook/part-ii-prometheus-jin-jie/readmd/prometheus-remote-storage)
* [联邦集群](/prometheus-handbook/part-ii-prometheus-jin-jie/readmd/scale-prometheus-with-federation)
* [Prometheus高可用](/prometheus-handbook/part-ii-prometheus-jin-jie/readmd/prometheus-and-high-availability)
* [Alertmanager高可用](/prometheus-handbook/part-ii-prometheus-jin-jie/readmd/alertmanager-high-availability)
* [小结](/prometheus-handbook/part-ii-prometheus-jin-jie/readmd/summary)
* [第7章 Prometheus服务发现](/prometheus-handbook/part-ii-prometheus-jin-jie/sd)
* [Prometheus与服务发现](/prometheus-handbook/part-ii-prometheus-jin-jie/sd/why-need-service-discovery)
* [基于文件的服务发现](/prometheus-handbook/part-ii-prometheus-jin-jie/sd/service-discovery-with-file)
* [基于Consul的服务发现](/prometheus-handbook/part-ii-prometheus-jin-jie/sd/service-discovery-with-consul)
* [服务发现与Relabel](/prometheus-handbook/part-ii-prometheus-jin-jie/sd/service-discovery-with-relabel)
* [小结](/prometheus-handbook/part-ii-prometheus-jin-jie/sd/summary)
## Part III - Prometheus实战
* [第8章 监控Kubernetes](/prometheus-handbook/part-iii-prometheus-shi-zhan/readmd)
* [初识Kubernetes](/prometheus-handbook/part-iii-prometheus-shi-zhan/readmd/kubernetes-with-minikube)
* [部署Prometheus](/prometheus-handbook/part-iii-prometheus-shi-zhan/readmd/deploy-prometheus-in-kubernetes)
* [Kubernetes下的服务发现](/prometheus-handbook/part-iii-prometheus-shi-zhan/readmd/service-discovery-with-kubernetes)
* [监控Kubernetes集群](/prometheus-handbook/part-iii-prometheus-shi-zhan/readmd/use-prometheus-monitor-kubernetes)
* [基于Prometheus的弹性伸缩](/prometheus-handbook/part-iii-prometheus-shi-zhan/readmd/hap-with-prometheus)
* [小结](/prometheus-handbook/part-iii-prometheus-shi-zhan/readmd/summary)
* [第9章 Prometheus Operator](/prometheus-handbook/part-iii-prometheus-shi-zhan/operator)
* [什么是Prometheus Operator](/prometheus-handbook/part-iii-prometheus-shi-zhan/operator/what-is-prometheus-operator)
* [使用Operator管理Prometheus](/prometheus-handbook/part-iii-prometheus-shi-zhan/operator/use-operator-manage-prometheus)
* [使用Operator管理监控配置](/prometheus-handbook/part-iii-prometheus-shi-zhan/operator/use-operator-manage-monitor)
* [在Prometheus Operator中使用自定义配置](/prometheus-handbook/part-iii-prometheus-shi-zhan/operator/use-custom-configuration-in-operator)
* [小结](/prometheus-handbook/part-iii-prometheus-shi-zhan/operator/summary)
* [参考资料](/prometheus-handbook/part-iii-prometheus-shi-zhan/references)
# 全书组织
这里假定你已经对Linux系统以及Docker技术有一定的基本认识，也可能使用过像Java，Golang这样的编程语言，在本书中我们不会事无巨细的讲述所有事。
第1章，是Prometheus基础的综述，通过一个简单案例（使用Prometheus采集主机的监控数据）来了解Prometheus是什么，能做什么，以及它的架构组成。通过阅读本章希望读者能对Prometheus有一个基本的理解和认识。
第2章，读者将会了解到Prometheus的数据模型，以及时间序列模型。同时会学习到如何利用Prometheus的数据查询语言PrmQL(Prometheus Query Language)对监控数据进行查询、聚合、计算等。
第3章，我们的重点将放在监控告警部分，作为监控系统的重要能力之一，我们希望能够及时的了解系统的变化。这一章中读者将学习如何在Prometheus中自定义告警规则，同时了解如何使用AlertManager对告警进行处理。
第4章，介绍Prometheus中一些常用的Exporter的使用场景以及使用方法。之后还会带领读者通过Java和Golang实现自定义的Exporter，同时了解如何在现有应用系统上添加对Prometheus支持，从而实现应用层面的监控对接。
从第1章到第4章的部分都是本书的基础性章节，对大部分的研发或者运维人员来说可以快速掌握，并且能够使用Prometheus来完成一些基本的日常任务。余下的章节我们会关注到Prometheus的高级用法部分。
第5章，"You can't fix what you can't see"。可视化是监控的核心目标之一，这部分将会基于Grafana这一可视化工具实现监控数据可视化，并且了解Grafana作为一个通用的可视化工具是如何与Prometheus进行配合的。
第6章，读者将会了解到如何通过Prometheus的服务发现能力，自动的发现那些需要监控的资源和服务。特别是在云平台或者容器平台中，资源的创建和销毁成本变得更加频繁，通过服务发现自动地去发现监控目标，能够充分简化Prometheus的运维和管理难度。
第7章，在单个节点的情况下Prometheus能够轻松完成对数以百万的监控指标的处理，但是当监控的目标资源以及数据量变得更大的时候，我们如何实现对Prometheus的扩展？这一章节中重点讨论Prometheus高可用方面的能力。
第8章，这一章节中我们的另外一位重要成员Kubernetes将会登场，这里我们会带领读者对Kubernetes有一个基本的认识，并且通过Prometheus构建我们的容器云监控系统。并且介绍如何通过Prometheus与Kubernetes结合实现应用程序的弹性伸缩。
# 第1章 天降奇兵
本章作为全书的开篇，我们会带读者了解Prometheus的前世今生，Prometheus是如何从众多的监控平台中脱颖而出成为下一代监控系统的首选。同时通过一个简单的例子带领读者快速了解Prometheus是如何工作的，从而了解Prometheus中的一些概念以及架构模式。
本章内容：
* Prometheus的前世今生
* 使用Prometheus监控主机
* Prometheus的核心组件和概念
# Prometheus简介
Prometheus受启发于Google的Borgmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。
Prometheus作为新一代的云原生监控系统，目前已经有超过650+位贡献者参与到Prometheus的研发工作上，并且超过120+项的第三方集成。
## 监控的目标
在《SRE: Google运维解密》一书中指出，监控系统需要能够有效的支持白盒监控和黑盒监控。通过白盒能够了解其内部的实际运行状态，通过对监控指标的观察能够预判可能出现的问题，从而对潜在的不确定因素进行优化。而黑盒监控，常见的如HTTP探针，TCP探针等，可以在系统或者服务在发生故障时能够快速通知相关的人员进行处理。通过建立完善的监控体系，从而达到以下目的：
* 长期趋势分析：通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间增长率的判断，我们可以提前预测在未来什么时间节点上需要对资源进行扩容。
* 对照分析：两个版本的系统运行资源使用情况的差异如何？在不同容量情况下系统的并发和负载变化如何？通过监控能够方便的对系统进行跟踪和比较。
* 告警：当系统出现或者即将出现故障时，监控系统需要迅速反应并通知管理员，从而能够对问题进行快速的处理或者提前预防问题的发生，避免出现对业务的影响。
* 故障分析与定位：当问题发生后，需要对问题进行调查和处理。通过对不同监控以及历史数据的分析，能够找到并解决根源问题。
* 数据可视化：通过可视化仪表盘能够直接获取系统的运行状态、资源使用情况、以及服务运行状态等直观的信息。
## 与常见监控系统比较
对于常用的监控系统，如Nagios、Zabbix的用户而言，往往并不能很好的解决上述问题。这里以Nagios为例，如下图所示是Nagios监控系统的基本架构：
Nagios的主要功能是监控服务和主机。Nagios软件需要安装在一台独立的服务器上运行，该服务器称为监控中心。每一台被监控的硬件主机或者服务都需要运行一个与监控中心服务器进行通信的Nagios软件后台程序，可以理解为Agent或者插件。
首先对于Nagios而言，大部分的监控能力都是围绕系统的一些边缘性的问题，主要针对系统服务和资源的状态以及应用程序的可用性。 例如：Nagios通过check\_disk插件可以用于检查磁盘空间，check\_load用于检查CPU负载等。这些插件会返回4种Nagios可识别的状态，0(OK)表示正常，1(WARNING)表示警告，2(CRITTCAL)表示错误，3(UNKNOWN)表示未知错误，并通过Web UI显示出来。
对于Nagios这类系统而言，其核心是采用了测试和告警(check\&alert)的监控系统模型。 对于基于这类模型的监控系统而言往往存在以下问题：
* 与业务脱离的监控：监控系统获取到的监控指标与业务本身也是一种分离的关系。好比客户可能关注的是服务的可用性、服务的SLA等级，而监控系统却只能根据系统负载去产生告警；
* 运维管理难度大：Nagios这一类监控系统本身运维管理难度就比较大，需要有专业的人员进行安装，配置和管理，而且过程并不简单；
* 可扩展性低： 监控系统自身难以扩展，以适应监控规模的变化；
* 问题定位难度大：当问题产生之后（比如主机负载异常增加）对于用户而言，他们看到的依然是一个黑盒，他们无法了解主机上服务真正的运行情况，因此当故障发生后，这些告警信息并不能有效的支持用户对于故障根源问题的分析和定位。
## Prometheus的优势
Prometheus是一个开源的完整监控解决方案，其对传统监控系统的测试和告警模型进行了彻底的颠覆，形成了基于中央化的规则计算、统一分析和告警的新模型。 相比于传统监控系统Prometheus具有以下优点：
### 易于管理
Prometheus核心部分只有一个单独的二进制文件，不存在任何的第三方依赖(数据库，缓存等等)。唯一需要的就是本地磁盘，因此不会有潜在级联故障的风险。
Prometheus基于Pull模型的架构方式，可以在任何地方（本地电脑，开发环境，测试环境）搭建我们的监控系统。对于一些复杂的情况，还可以使用Prometheus服务发现(Service Discovery)的能力动态管理监控目标。
### 监控服务的内部运行状态
Prometheus鼓励用户监控服务的内部状态，基于Prometheus丰富的Client库，用户可以轻松的在应用程序中添加对Prometheus的支持，从而让用户可以获取服务和应用内部真正的运行状态。
### 强大的数据模型
所有采集的监控数据均以指标(metric)的形式保存在内置的时间序列数据库当中(TSDB)。所有的样本除了基本的指标名称以外，还包含一组用于描述该样本特征的标签。
如下所示：
```
http_request_status{code='200',content_path='/api/path', environment='produment'} => [value1@timestamp1,value2@timestamp2...]
http_request_status{code='200',content_path='/api/path2', environment='produment'} => [value1@timestamp1,value2@timestamp2...]
```
每一条时间序列由指标名称(Metrics Name)以及一组标签(Labels)唯一标识。每条时间序列按照时间的先后顺序存储一系列的样本值。
表示维度的标签可能来源于你的监控对象的状态，比如code=404或者content\_path=/api/path。也可能来源于的你的环境定义，比如environment=produment。基于这些Labels我们可以方便地对监控数据进行聚合，过滤，裁剪。
### 强大的查询语言PromQL
Prometheus内置了一个强大的数据查询语言PromQL。 通过PromQL可以实现对监控数据的查询、聚合。同时PromQL也被应用于数据可视化(如Grafana)以及告警当中。
通过PromQL可以轻松回答类似于以下问题：
* 在过去一段时间中95%应用延迟时间的分布范围？
* 预测在4小时后，磁盘空间占用大致会是什么情况？
* CPU占用率前5位的服务有哪些？(过滤)
### 高效
对于监控系统而言，大量的监控任务必然导致有大量的数据产生。而Prometheus可以高效地处理这些数据，对于单一Prometheus Server实例而言它可以处理：
* 数以百万的监控指标
* 每秒处理数十万的数据点。
### 可扩展
Prometheus是如此简单，因此你可以在每个数据中心、每个团队运行独立的Prometheus Sevrer。Prometheus对于联邦集群的支持，可以让多个Prometheus实例产生一个逻辑集群，当单实例Prometheus Server处理的任务量过大时，通过使用功能分区(sharding)+联邦集群(federation)可以对其进行扩展。
### 易于集成
使用Prometheus可以快速搭建监控服务，并且可以非常方便地在应用程序中进行集成。目前支持： Java， JMX， Python， Go，Ruby， .Net， Node.js等等语言的客户端SDK，基于这些SDK可以快速让应用程序纳入到Prometheus的监控当中，或者开发自己的监控数据收集程序。同时这些客户端收集的监控数据，不仅仅支持Prometheus，还能支持Graphite这些其他的监控工具。
同时Prometheus还支持与其他的监控系统进行集成：Graphite， Statsd， Collected， Scollector， muini， Nagios等。
Prometheus社区还提供了大量第三方实现的监控数据采集支持：JMX， CloudWatch， EC2， MySQL， PostgresSQL， Haskell， Bash， SNMP， Consul， Haproxy， Mesos， Bind， CouchDB， Django， Memcached， RabbitMQ， Redis， RethinkDB， Rsyslog等等。
### 可视化
Prometheus Server中自带了一个Prometheus UI，通过这个UI可以方便地直接对数据进行查询，并且支持直接以图形化的形式展示数据。同时Prometheus还提供了一个独立的基于Ruby On Rails的Dashboard解决方案Promdash。最新的Grafana可视化工具也已经提供了完整的Prometheus支持，基于Grafana可以创建更加精美的监控图标。基于Prometheus提供的API还可以实现自己的监控可视化UI。
### 开放性
通常来说当我们需要监控一个应用程序时，一般需要该应用程序提供对相应监控系统协议的支持。因此应用程序会与所选择的监控系统进行绑定。为了减少这种绑定所带来的限制。对于决策者而言要么你就直接在应用中集成该监控系统的支持，要么就在外部创建单独的服务来适配不同的监控系统。
而对于Prometheus来说，使用Prometheus的client library的输出格式不止支持Prometheus的格式化数据，也可以输出支持其它监控系统的格式化数据，比如Graphite。
因此你甚至可以在不使用Prometheus的情况下，采用Prometheus的client library来让你的应用程序支持监控数据采集。
接下来，在本书当中，将带领读者感受Prometheus是如何对监控系统的重新定义。
# 初识Prometheus
Prometheus是一个开放性的监控解决方案，用户可以非常方便的安装和使用Prometheus并且能够非常方便的对其进行扩展。为了能够更加直观的了解Prometheus Server，接下来我们将在本地部署并运行一个Prometheus Server实例，通过Node Exporter采集当前主机的系统资源使用情况。 并通过Grafana创建一个简单的可视化仪表盘。
# 安装Prometheus Server
Prometheus基于Golang编写，编译后的软件包，不依赖于任何的第三方依赖。用户只需要下载对应平台的二进制包，解压并且添加基本的配置即可正常启动Prometheus Server。
## 从二进制包安装
对于非Docker用户，可以从找到最新版本的Prometheus Sevrer软件包：
```
export VERSION=2.4.3
curl -LO https://github.com/prometheus/prometheus/releases/download/v$VERSION/prometheus-$VERSION.darwin-amd64.tar.gz
```
解压，并将Prometheus相关的命令，添加到系统环境变量路径即可：
```
tar -xzf prometheus-${VERSION}.darwin-amd64.tar.gz
cd prometheus-${VERSION}.darwin-amd64
```
解压后当前目录会包含默认的Prometheus配置文件prometheus.yml:
```
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=` to any timeseries scraped from this config.
- job_name: 'prometheus'
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9090']
```
Prometheus作为一个时间序列数据库，其采集的数据会以文件的形式存储在本地中，默认的存储路径为`data/`，因此我们需要先手动创建该目录：
```
mkdir -p data
```
用户也可以通过参数`--storage.tsdb.path="data/"`修改本地数据存储的路径。
启动prometheus服务，其会默认加载当前路径下的prometheus.yaml文件：
```
./prometheus
```
正常的情况下，你可以看到以下输出内容：
```
level=info ts=2018-10-23T14:55:14.499484Z caller=main.go:554 msg="Starting TSDB ..."
level=info ts=2018-10-23T14:55:14.499531Z caller=web.go:397 component=web msg="Start listening for connections" address=0.0.0.0:9090
level=info ts=2018-10-23T14:55:14.507999Z caller=main.go:564 msg="TSDB started"
level=info ts=2018-10-23T14:55:14.508068Z caller=main.go:624 msg="Loading configuration file" filename=prometheus.yml
level=info ts=2018-10-23T14:55:14.509509Z caller=main.go:650 msg="Completed loading of configuration file" filename=prometheus.yml
level=info ts=2018-10-23T14:55:14.509537Z caller=main.go:523 msg="Server is ready to receive web requests."
```
## 使用容器安装
对于Docker用户，直接使用Prometheus的镜像即可启动Prometheus Server：
```
docker run -p 9090:9090 -v /etc/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus
```
启动完成后，可以通过访问Prometheus的UI界面：
# 使用Node Exporter采集主机数据
## 安装Node Exporter
在Prometheus的架构设计中，Prometheus Server并不直接服务监控特定的目标，其主要任务负责数据的收集，存储并且对外提供数据查询支持。因此为了能够监控到某些东西，如主机的CPU使用率，我们需要使用到Exporter。Prometheus周期性的从Exporter暴露的HTTP服务地址（通常是/metrics）拉取监控样本数据。
从上面的描述中可以看出Exporter可以是一个相对开放的概念，其可以是一个独立运行的程序独立于监控目标以外，也可以是直接内置在监控目标中。只要能够向Prometheus提供标准格式的监控样本数据即可。
这里为了能够采集到主机的运行指标如CPU, 内存，磁盘等信息。我们可以使用[Node Exporter](https://github.com/prometheus/node_exporter)。
Node Exporter同样采用Golang编写，并且不存在任何的第三方依赖，只需要下载，解压即可运行。可以从获取最新的node exporter版本的二进制包。
```
curl -OL https://github.com/prometheus/node_exporter/releases/download/v0.15.2/node_exporter-0.15.2.darwin-amd64.tar.gz
tar -xzf node_exporter-0.15.2.darwin-amd64.tar.gz
```
运行node exporter:
```
cd node_exporter-0.15.2.darwin-amd64
cp node_exporter-0.15.2.darwin-amd64/node_exporter /usr/local/bin/
node_exporter
```
启动成功后，可以看到以下输出：
```
INFO[0000] Listening on :9100 source="node_exporter.go:76"
```
访问可以看到以下页面：
### 初始Node Exporter监控指标
访问，可以看到当前node exporter获取到的当前主机的所有监控数据，如下所示：
每一个监控指标之前都会有一段类似于如下形式的信息：
```
# HELP node_cpu Seconds the cpus spent in each mode.
# TYPE node_cpu counter
node_cpu{cpu="cpu0",mode="idle"} 362812.7890625
# HELP node_load1 1m load average.
# TYPE node_load1 gauge
node_load1 3.0703125
```
其中HELP用于解释当前指标的含义，TYPE则说明当前指标的数据类型。在上面的例子中node\_cpu的注释表明当前指标是cpu0上idle进程占用CPU的总时间，CPU占用时间是一个只增不减的度量指标，从类型中也可以看出node\_cpu的数据类型是计数器(counter)，与该指标的实际含义一致。又例如node\_load1该指标反映了当前主机在最近一分钟以内的负载情况，系统的负载情况会随系统资源的使用而变化，因此node\_load1反映的是当前状态，数据可能增加也可能减少，从注释中可以看出当前指标类型为仪表盘(gauge)，与指标反映的实际含义一致。
除了这些以外，在当前页面中根据物理主机系统的不同，你还可能看到如下监控指标：
* node\_boot\_time：系统启动时间
* node\_cpu：系统CPU使用量
* node\_disk\_\*：磁盘IO
* node\_filesystem\_\*：文件系统用量
* node\_load1：系统负载
* node\_memeory\_\*：内存使用量
* node\_network\_\*：网络带宽
* node\_time：当前系统时间
* go\_\*：node exporter中go相关指标
* process\_\*：node exporter自身进程相关运行指标
## 从Node Exporter收集监控数据
为了能够让Prometheus Server能够从当前node exporter获取到监控数据，这里需要修改Prometheus配置文件。编辑prometheus.yml并在scrape\_configs节点下添加以下内容:
```
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
# 采集node exporter监控数据
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']
```
重新启动Prometheus Server
访问，进入到Prometheus Server。如果输入“up”并且点击执行按钮以后，可以看到如下结果：
如果Prometheus能够正常从node exporter获取数据，则会看到以下结果：
```
up{instance="localhost:9090",job="prometheus"} 1
up{instance="localhost:9100",job="node"} 1
```
其中“1”表示正常，反之“0”则为异常。
# 使用PromQL查询监控数据
Prometheus UI是Prometheus内置的一个可视化管理界面，通过Prometheus UI用户能够轻松的了解Prometheus当前的配置，监控任务运行状态等。 通过`Graph`面板，用户还能直接使用`PromQL`实时查询监控数据：
切换到`Graph`面板，用户可以使用PromQL表达式查询特定监控指标的监控数据。如下所示，查询主机负载变化情况，可以使用关键字`node_load1`可以查询出Prometheus采集到的主机负载的样本数据，这些样本数据按照时间先后顺序展示，形成了主机负载随时间变化的趋势图表：
PromQL是Prometheus自定义的一套强大的数据查询语言，除了使用监控指标作为查询关键字以为，还内置了大量的函数，帮助用户进一步对时序数据进行处理。例如使用`rate()`函数，可以计算在单位时间内样本数据的变化情况即增长率，因此通过该函数我们可以近似的通过CPU使用时间计算CPU的利用率：
```
rate(node_cpu[2m])
```
这时如果要忽略是哪一个CPU的，只需要使用without表达式，将标签CPU去除后聚合数据即可：
```
avg without(cpu) (rate(node_cpu[2m]))
```
那如果需要计算系统CPU的总体使用率，通过排除系统闲置的CPU使用率即可获得:
```
1 - avg without(cpu) (rate(node_cpu{mode="idle"}[2m]))
```
通过PromQL我们可以非常方便的对数据进行查询，过滤，以及聚合，计算等操作。通过这些丰富的表达书语句，监控指标不再是一个单独存在的个体，而是一个个能够表达出正式业务含义的语言。
# 监控数据可视化
Prometheus UI提供了快速验证PromQL以及临时可视化支持的能力，而在大多数场景下引入监控系统通常还需要构建可以长期使用的监控数据可视化面板（Dashboard）。这时用户可以考虑使用第三方的可视化工具如Grafana，Grafana是一个开源的可视化平台，并且提供了对Prometheus的完整支持。
```
docker run -d -p 3000:3000 grafana/grafana
```
访问就可以进入到Grafana的界面中，默认情况下使用账户admin/admin进行登录。在Grafana首页中显示默认的使用向导，包括：安装、添加数据源、创建Dashboard、邀请成员、以及安装应用和插件等主要流程:
这里将添加Prometheus作为默认的数据源，如下图所示，指定数据源类型为Prometheus并且设置Prometheus的访问地址即可，在配置正确的情况下点击“Add”按钮，会提示连接成功的信息：
在完成数据源的添加之后就可以在Grafana中创建我们可视化Dashboard了。Grafana提供了对PromQL的完整支持，如下所示，通过Grafana添加Dashboard并且为该Dashboard添加一个类型为“Graph”的面板。 并在该面板的“Metrics”选项下通过PromQL查询需要可视化的数据：
点击界面中的保存选项，就创建了我们的第一个可视化Dashboard了。 当然作为开源软件，Grafana社区鼓励用户分享Dashboard通过网站，可以找到大量可直接使用的Dashboard：
Grafana中所有的Dashboard通过JSON进行共享，下载并且导入这些JSON文件，就可以直接使用这些已经定义好的Dashboard：
# 任务和实例
在上一小节中，通过在prometheus.yml配置文件中，添加如下配置。我们让Prometheus可以从node exporter暴露的服务中获取监控指标数据。
```yaml
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']
```
当我们需要采集不同的监控指标(例如：主机、MySQL、Nginx)时，我们只需要运行相应的监控采集程序，并且让Prometheus Server知道这些Exporter实例的访问地址。在Prometheus中，每一个暴露监控样本数据的HTTP服务称为一个实例。例如在当前主机上运行的node exporter可以被称为一个实例(Instance)。
而一组用于相同采集目的的实例，或者同一个采集进程的多个副本则通过一个一个任务(Job)进行管理。
```
* job: node
* instance 2: 1.2.3.4:9100
* instance 4: 5.6.7.8:9100
```
当前在每一个Job中主要使用了静态配置(static\_configs)的方式定义监控目标。除了静态配置每一个Job的采集Instance地址以外，Prometheus还支持与DNS、Consul、E2C、Kubernetes等进行集成实现自动发现Instance实例，并从这些Instance上获取监控数据。
除了通过使用“up”表达式查询当前所有Instance的状态以外，还可以通过Prometheus UI中的Targets页面查看当前所有的监控采集任务，以及各个任务下所有实例的状态:
我们也可以访问直接从Prometheus的UI中查看当前所有的任务以及每个任务对应的实例信息。
# Prometheus核心组件
上一小节，通过部署Node Exporter我们成功的获取到了当前主机的资源使用情况。接下来我们将从Prometheus的架构角度详细介绍Prometheus生态中的各个组件。
下图展示Prometheus的基本架构：
## Prometheus Server
Prometheus Server是Prometheus组件中的核心部分，负责实现对监控数据的获取，存储以及查询。 Prometheus Server可以通过静态配置管理监控目标，也可以配合使用Service Discovery的方式动态管理监控目标，并从这些监控目标中获取数据。其次Prometheus Server需要对采集到的监控数据进行存储，Prometheus Server本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。最后Prometheus Server对外提供了自定义的PromQL语言，实现对数据的查询以及分析。
Prometheus Server内置的Express Browser UI，通过这个UI可以直接通过PromQL实现数据的查询以及可视化。
Prometheus Server的联邦集群能力可以使其从其他的Prometheus Server实例中获取数据，因此在大规模监控的情况下，可以通过联邦集群以及功能分区的方式对Prometheus Server进行扩展。
## Exporters
Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。
一般来说可以将Exporter分为2类：
* 直接采集：这一类Exporter直接内置了对Prometheus监控的支持，比如cAdvisor，Kubernetes，Etcd，Gokit等，都直接内置了用于向Prometheus暴露监控数据的端点。
* 间接采集：间接采集，原有监控目标并不直接支持Prometheus，因此我们需要通过Prometheus提供的Client Library编写该监控目标的监控采集程序。例如： Mysql Exporter，JMX Exporter，Consul Exporter等。
## AlertManager
在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由AlertManager进行管理。在AlertManager中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式。AlertManager即Prometheus体系中的告警处理中心。
## PushGateway
由于Prometheus数据采集基于Pull模型进行设计，因此在网络环境的配置上必须要让Prometheus Server能够直接与Exporter进行通信。 当这种网络需求无法直接满足时，就可以利用PushGateway来进行中转。可以通过PushGateway将内部网络的监控数据主动Push到Gateway当中。而Prometheus Server则可以采用同样Pull的方式从PushGateway中获取到监控数据。
# 小结
在这一章中，我们初步了解了Prometheus以及相比于其他相似方案的优缺点，可以为读者在选择监控解决方案时，提供一定的参考。同时我们介绍了Prometheus的生态以及核心能力，在本地使用Prometheus和NodeExporter搭建了一个主机监控的环境，并且对数据进行了聚合以及可视化，相信读者通过本章能够对Prometheus有一个直观的认识。
# 第2章 探索PromQL
本章将带领读者探秘Prometheus的自定义查询语言PromQL。通过PromQL用户可以非常方便地对监控样本数据进行统计分析，PromQL支持常见的运算操作符，同时PromQL中还提供了大量的内置函数可以实现对数据的高级处理。当然在学习PromQL之前，用户还需要了解Prometheus的样本数据模型。PromQL作为Prometheus的核心能力除了实现数据的对外查询和展现，同时告警监控也是依赖PromQL实现的。
本章的主要内容：
* Prometheus的数据模型
* Prometheus中监控指标的类型
* 深入PromQL
* 4个黄金指标和USE方法
# 理解时间序列
在1.2节当中，通过Node Exporter暴露的HTTP服务，Prometheus可以采集到当前主机所有监控指标的样本数据。例如：
```
# HELP node_cpu Seconds the cpus spent in each mode.
# TYPE node_cpu counter
node_cpu{cpu="cpu0",mode="idle"} 362812.7890625
# HELP node_load1 1m load average.
# TYPE node_load1 gauge
node_load1 3.0703125
```
其中非#开头的每一行表示当前Node Exporter采集到的一个监控样本：node\_cpu和node\_load1表明了当前指标的名称、大括号中的标签则反映了当前样本的一些特征和维度、浮点数则是该监控样本的具体值。
## 样本
Prometheus会将所有采集到的样本数据以时间序列（time-series）的方式保存在内存数据库中，并且定时保存到硬盘上。time-series是按照时间戳和值的序列顺序存放的，我们称之为向量(vector). 每条time-series通过指标名称(metrics name)和一组标签集(labelset)命名。如下所示，可以将time-series理解为一个以时间为Y轴的数字矩阵：
```
^
│ . . . . . . . . . . . . . . . . . . . node_cpu{cpu="cpu0",mode="idle"}
│ . . . . . . . . . . . . . . . . . . . node_cpu{cpu="cpu0",mode="system"}
│ . . . . . . . . . . . . . . . . . . node_load1{}
│ . . . . . . . . . . . . . . . . . .
v
<------------------ 时间 ---------------->
```
在time-series中的每一个点称为一个样本（sample），样本由以下三部分组成：
* 指标(metric)：metric name和描述当前样本特征的labelsets;
* 时间戳(timestamp)：一个精确到毫秒的时间戳;
* 样本值(value)： 一个float64的浮点型数据表示当前样本的值。
```
<--------------- metric ---------------------><-timestamp -><-value->
http_request_total{status="200", method="GET"}@1434417560938 => 94355
http_request_total{status="200", method="GET"}@1434417561287 => 94334
http_request_total{status="404", method="GET"}@1434417560938 => 38473
http_request_total{status="404", method="GET"}@1434417561287 => 38544
http_request_total{status="200", method="POST"}@1434417560938 => 4748
http_request_total{status="200", method="POST"}@1434417561287 => 4785
```
## 指标(Metric)
在形式上，所有的指标(Metric)都通过如下格式标示：
```
{