Prometheus是一个开源监控系统，它既适用于面向服务器等硬件指标的监控，也适用于高动态的面向服务架构的监控。对于现在流行的微服务，Prometheus的多维度数据收集和数据筛选查询语言也是非常的强大。

Prometheus的主要特性包括：

1. 多维度数据模型
2. 灵活的查询语言
3. 不依赖分布式存储，单个服务器节点是自治的
4. 通过服务（sd，准确的说是监控目标）发现或者静态配置，来发现目标服务对象
5. 支持多种多样的图表和界面展示，可以和Grafana集成
6. 数据采集方式：
   1. Pull：通过HTTP协议定期去采集指标，只要被监控系统提供HTTP接口即可接入
   2. Push：被监控系统主动推送指标到网关，Prometheus定期从网关Pull

Prometheus包括以下组件：

1. Prometheus Server：负责抓取和存储时间序列数据
2. Push Gateway：推送网关，第三方可以推送数据到此网关，Prometheus Server再从此网关拉取数据
3. 多种导出工具，支持导出Graphite、StatsD等所需的格式
4. 命令行查询工具
5. Alert Manager：告警管理器
6. PromQL查询语言

Prometheus中所有数据都存放为时间序列——具有时间戳的数据流，这些数据属于同一指标、以及由一系列标签定义的维度集。每个时间序列由指标名+标签集唯一的识别，标签由键、值组成。时间序列通常使用如下记号表示：

<metric name>{<label name>=<label value>, ...}
# 示例：
api_http_requests_total{method="POST", handler="/messages"}

指标名是需要监控系统特性的一般性名称，例如http_requests_total可以表示HTTP请求计数。

标签为一个具体的指标“实例”提供维度信息。使用PromQL你可以基于标签进行过滤、分组。增加、修改、删除某个标签，则新的时间序列会被创建。标签名只能ASCII字符，但是标签值可以是任何Unicode字符。

样本（Sample）构成了实际的时间序列的数据点。样本由float64类型的数值+毫秒精度的时间戳组成。

Prometheus的客户端库区分了4种指标类型，目前服务器端不理解这些类型的不同，但是未来可能改变。

# prometheus_tsdb_compaction_chunk_range_count{instance="localhost:9090"}
# 样本总数
tsdb_compaction_chunk_range_count{}                   64388371

# prometheus_tsdb_compaction_chunk_range_sum{instance="localhost:9090"}
# 所有样本的值的总和
tsdb_compaction_chunk_range_sum{}                     456743796630059

# sort(prometheus_tsdb_compaction_chunk_range_bucket{instance="localhost:9090"})
# 值小于25600的样本数量
tsdb_compaction_chunk_range_bucket{le="25600"         1301
tsdb_compaction_chunk_range_bucket{le="400"}          1301
tsdb_compaction_chunk_range_bucket{le="100"}          1301
tsdb_compaction_chunk_range_bucket{le="1600"}         1301
tsdb_compaction_chunk_range_bucket{le="6400"}         1301
tsdb_compaction_chunk_range_bucket{le="102400"}       20000
tsdb_compaction_chunk_range_bucket{le="409600"}       108533
tsdb_compaction_chunk_range_bucket{le="1.6384e+06"}   254369
tsdb_compaction_chunk_range_bucket{le="6.5536e+06"}   655322
tsdb_compaction_chunk_range_bucket{le="2.62144e+07"}  64272199
# 所有样本数量
tsdb_compaction_chunk_range_bucket{le="+Inf"}         64272199

// 估算99分位数
histogram_quantile(0.99, 
  // 以le分组求和
  sum(
    // 以interval为区间获得平均值
    irate(
      istio_request_duration_seconds_bucket{
        reporter="destination",
        destination_workload=~"$workload",
        destination_workload_namespace=~"$namespace"
      }[$interval]
    )
  ) by (le)
)

# 样本总数
tsdb_wal_fsync_duration_seconds_count{job="prometheus"}                  369717
# 样本值总和
tsdb_wal_fsync_duration_seconds_sum{job="prometheus"}                   24423.798953890488
# 中位数耗时0.05秒，也就是说，有一半的磁盘同步操作在0.05秒内完成
tsdb_wal_fsync_duration_seconds{job="prometheus",quantile="0.5"}	0.053841949
# 九分位数耗时0.12秒，也就是说，90%的磁盘同步操作都在0.12秒内完成
tsdb_wal_fsync_duration_seconds{job="prometheus",quantile="0.9"}	0.116763012
tsdb_wal_fsync_duration_seconds{job="prometheus",quantile="0.99"}	0.263791273

一个你可以从中抓取监控数据的endpoint称为实例（Instance），实例通常对应一个进程，例如NodeExporter、RedisExporter……

一系列相同目的的实例，称为Job。多实例的原因可能是为了可靠性、扩容。

当Prometheus服务器抓取数据时，它会自动为时间序列添加标签：

1. job，抓取目标所属的Job的名称
2. instance，目标从什么host:port抓取得到

如果上述两个标签已经存在于抓取的数据上，则配置项honor_labels影响服务器的行为。

除了添加标签之外，还会为以下时间序列添加样本：

1. up{job="<job-name>", instance="<instance-id>"}:1/0。如果实例可达则取值1，否则0
2. scrape_duration_seconds{job="<job-name>", instance="<instance-id>"}:抓取目标消耗的时间
3. scrape_samples_post_metric_relabeling{job="<job-name>", instance="<instance-id>"}:指标重打标签后，剩余的样本数量
4. scrape_samples_scraped{job="<job-name>", instance="<instance-id>"}: 目标暴露的样本数量

Graphite专注于作为一个被动的时间序列数据库，同时提供查询语言、图形化特性。Prometheus则是一个全功能的监控和趋势分析系统，内置主动拉取、存储、图形化、报警功能。

Graphite存储数字采样，但是其元数据模型不如Prometheus丰富。Graphite的指标名称使用点号分隔的单词，暗含维度信息。Prometheus则将维度信息作为明确的标签存储。Prometheus更容易支持过滤、分组操作。

Graphite在本地磁盘上，以Whisper格式存储时间序列数据。每个时间序列存储一个文件，一段时间后，新采样会覆盖旧采样，此外采样频率是固定的。Prometheus也是每个时间序列对应一个文件，但是采样频率是动态的，新数据简单的Append到文件尾部。

InfluxDB的持续查询类似于Prometheus的Recording规则。Kapacitor类似于Recording规则、Alerting规则和Alertmanager的通知功能的组合。Alertmanager具有额外的分组、去重、静默功能。

InfluxDB的Tag和Prometheus的Label一样，都是键值对形式的维度信息。InfluxDB还提供第二级的“标签”——字段（Field）

helm install gmem/prometheus --name prometheus --namespace=kube-system

此Chart的定义位于：https://github.com/gmemcc/charts/tree/master/prometheus

安装完毕，到https://prometheus.k8s.gmem.cc/targets可以查看各监控目标的状态。

wget https://github.com/prometheus/prometheus/releases/download/v2.2.1/prometheus-2.2.1.linux-amd64.tar.gz
tar xzf prometheus-2.2.1.linux-amd64.tar.gz
rm prometheus-2.2.1.linux-amd64.tar.gz
mv prometheus-2.2.1.linux-amd64 prometheus
cd prometheus
./prometheus --config.file="prometheus.yml"       # 指定配置文件
             --web.listen-address="0.0.0.0:9090"  # UI/API/Telemetry监听地址
             --storage.tsdb.path="data/"          # 时间序列数据库存储路径
             --storage.tsdb.retention=15d         # 时间序列数据存储时长
             # 等待处理的的告警管理器通知队列长度
             --alertmanager.notification-queue-capacity=10000
             --alertmanager.timeout=10s           # 发送告警给告警管理器的超时

Prometheus通过命令行、配置文件进行配置。命令行参数可以配置一些不变的系统参数，例如存储位置、存留在内存和磁盘中的数据量。配置文件则用于指定Job、Instance、Rule的配置。

配置文件的格式是YAML，使用--config.file指定配置文件的位置。本节列出重要的配置项。

global:
  # 默认抓取周期，可用单位ms、smhdwy
  [ scrape_interval: <duration> | default = 1m ]
  # 默认抓取超时
  [ scrape_timeout: <duration> | default = 10s ]
  # 估算规则的默认周期
  [ evaluation_interval: <duration> | default = 1m ]
  # 和外部系统（例如AlertManager）通信时为时间序列或者警情（Alert）强制添加的标签列表
  external_labels:
    [ <labelname>: <labelvalue> ... ]

# 规则文件列表
rule_files:
  [ - <filepath_glob> ... ]

# 抓取配置列表
scrape_configs:
  [ - <scrape_config> ... ]

# 和Alertmanager相关的配置
alerting:
  alert_relabel_configs:
    [ - <relabel_config> ... ]
  alertmanagers:
    [ - <alertmanager_config> ... ]

# 和远程读写特性相关的配置
remote_write:
  [ - <remote_write> ... ]
remote_read:
  [ - <remote_read> ... ]

配置一系列的目标，以及如何抓取它们的参数。一般情况下，每个scrape_config对应单个Job。

目标可以在scrape_config中静态的配置，也可以使用某种服务发现机制动态发现。

# 任务名称，自动作为抓取到的指标的一个标签
job_name: <job_name>

# 抓取周期
[ scrape_interval: <duration> | default = <global_config.scrape_interval> ]
# 每次抓取的超时
[ scrape_timeout: <duration> | default = <global_config.scrape_timeout> ]
# 从目标抓取指标的URL路径
[ metrics_path: <path> | default = /metrics ]
# 当添加标签发现指标已经有同名标签时，是否保留原有标签不覆盖
[ honor_labels: <boolean> | default = false ]
# 抓取协议
[ scheme: <scheme> | default = http ]
# 可选的请求参数
params:
  [ <string>: [<string>, ...] ]

# 身份验证信息
basic_auth:
  [ username: <string> ]
  [ password: <secret> ]
  [ password_file: <string> ]
# Authorization请求头取值
[ bearer_token: <secret> ]
# 从文件读取Authorization请求头
[ bearer_token_file: /path/to/bearer/token/file ]

# TLS配置
tls_config:
  [ <tls_config> ]

# 代理配置
[ proxy_url: <string> ]

# DNS服务发现配置
dns_sd_configs:
  [ - <dns_sd_config> ... ]
# 文件服务发现配置
file_sd_configs:
  [ - <file_sd_config> ... ]
# K8S服务发现配置
kubernetes_sd_configs:
  [ - <kubernetes_sd_config> ... ]

# 此Job的静态配置的目标列表
static_configs:
  [ - <static_config> ... ]

# 目标重打标签配置
relabel_configs:
  [ - <relabel_config> ... ]
# 指标重打标签配置
metric_relabel_configs:
  [ - <relabel_config> ... ]

# 每次抓取允许的最大样本数量，如果在指标重打标签后，样本数量仍然超过限制，则整个抓取认为失败
# 0表示不限制
[ sample_limit: <int> | default = 0 ]

使用该配置，可以从K8S API Server暴露的REST API中发现抓取目标，并且和K8S集群保持同步。你可以配置以下role，以发现目标：

通常，你会给相关K8S资源添加以下注解：

annotations:                                                                                                                                                                           
  prometheus.io/path: /metrics                                                                                                                                                         
  prometheus.io/port: "8080"                                                                                                                                                           
  prometheus.io/scrape: "true"

并配合以下Relabel配置，提示这些资源需要作为Prometheus的抓取目标：

relabel_configs:
  - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
    action: keep
    regex: true
  - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
    action: replace
    target_label: __metrics_path__
    regex: (.+)
  - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
    action: replace
    regex: ([^:]+)(?::\d+)?;(\d+)
    replacement: $1:$2
    target_label: __address__ 

重打标签是动态修改目标的标签集的强大工具。每个抓取配置可以定义多个重打标签步骤，这些步骤按照声明顺序依次执行、在实际抓取指标数据之前执行。

在一开始，除了为每个目标配置的标签之外，目标的：

1. job标签被设置为抓取配置的job_name字段
2. __address__标签被设置为目标的<host>:<port>

在重打标签之后，目标的：

1. instance标签默认被设置为__address__，如果没有此标签的话
2. __scheme__标签被设置为http或https
3. __metrics_path__标签被设置为目标的指标路径，即URL路径
4. __param_<name>标签为请求时使用的每个参数

在重打标签期间，额外的 __meta_ 开头的元标签可用，这些标签由服务发现机制自动添加。

在重打标签结束后，以__开头的标签会被移除。

如果某个步骤需要临时的设置一些标签，仅仅作为后续步骤的输入，应当以__tmp作为前缀。

每个重打标签步骤（relabel_configs的元素）具有以下子配置项：

# 从已有的标签中选取值
[ source_labels: '[' <labelname> [, ...] ']' ]
# 并且使用下面的分隔符连接那些值
[ separator: <string> | default = ; ]
# 然后基于下面的正则式进行匹配，或者保留，或者替换，或者删除

# 对于替换操作来说，替换为的目标标签的名字，可以使用正则式捕获组
[ target_label: <labelname> ]

# 用于匹配源标签值的正则式
[ regex: <regex> | default = (.*) ]

# 用于获取源标签值的哈希的模数
[ modulus: <uint64> ]

# 如果正则式匹配，使用什么替换值，可以使用正则式捕获组
[ replacement: <string> | default = $1 ]

# 如果正则式匹配，执行何种操作
# replace 如果正则式匹配source_labels的值，则设置target_label为指定的内容
# keep 如果正则式匹配，维持目标不变
# drop 如果正则式匹配，丢弃目标
# hashmod 设置target_label标签名为source_labels的值的哈希的取模
# labelmap 针对所有标签名来匹配regex，然后将匹配的标签的值拷贝到replacement所指定的新标签中
# labeldrop 针对所有标签来匹配regex，不匹配的标签都丢弃
# labelkeep 针对所有标签来匹配regex，匹配的标签都丢弃
[ action: <relabel_action> | default = replace ]

重打标签配置示例：

# 将元标签__meta_kubernetes_pod_node_name替换为nodename
- source_labels: [__meta_kubernetes_pod_node_name]
  action: replace
  target_label: nodename 

在存储（ingestion）样本数据之前，作为最后一个步骤，配置同上。可以用于屏蔽存储成本过高的时间序列。

Prometheus使用YAML格式的配置文件，默认的配置文件内容如下：

# Prometheus服务器的全局配置
global:
  # 拉取Target的间隔，默认1分钟
  scrape_interval:     15s 
  # 执行Rule的间隔，默认1分钟
  evaluation_interval: 15s 
  # 拉取Target的超时时间
  scrape_timeout: 10s      

# 报警管理器配置
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - alertmanager:9093

# 加载规则文件，并每evaluation_interval执行规则一次
rule_files:
  - "first_rules.yml"
  - "second_rules.yml"

# 拉取配置，说明Prometheus需要监控什么
scrape_configs:
  # 这个默认抓取任务，监控Prometheus服务器自己（Prometheus通过HTTP暴露了自己的Metrics）
  - job_name: 'prometheus'
    metrics_path: /metrics
    scheme: http
    static_configs:
      # 此Job仅具有一个目标
      - targets: ['localhost:9090']

Prometheus提供了一种查询语言，用来实时的查询、聚合时间序列数据。查询结果可以在Prometheus的WebUI中展示，或者通过HTTP API暴露给第三方系统。

# 返回一个指标的所有时间序列
http_requests_total
# 返回一个指标具有特定Label的时间序列
http_requests_total{job="apiserver", handler="/api/comments"}
# 在满足上一条的前提下，返回5分钟内所有时间序列，并形成范围矢量（range vector）
http_requests_total{job="apiserver", handler="/api/comments"}[5m]
# 支持使用正则式来匹配Label
http_requests_total{job=~".*server"}
# 反向匹配
http_requests_total{status!~"4.."}

# 以最近5分钟的范围矢量为基础，统计每秒的数据增量
rate(http_requests_total[5m])

# 按Label job进行分组统计
sum(rate(http_requests_total[5m])) by (job)
# 如果两个指标具有相同的Label（维度信息），则可以对指标值进行运算
sum(
  instance_memory_limit_bytes - instance_memory_usage_bytes
) by (app, proc) / 1024 / 1024

# 取前三
topk(3, sum(rate(instance_cpu_time_ns[5m])) by (app, proc))

匹配单个时间点的一个或多个时间序列的采样：

# 选择指标的所有时间序列
http_requests_total
# 根据标签匹配
http_requests_total{job="prometheus",group="canary"}

匹配标签时可以使用四种操作符：=、!=、=~、!~，前两者用于精确匹配，后两者用于正则式匹配：

http_requests_total{environment=~"staging|testing|development",method!="GET"}

只需要在瞬时矢量选择器后面添加

[timePeriod]

http_requests_total{job="prometheus"}[5m]

# 获取相对当前查询时间，之前5分钟的数据
http_requests_total offset 5m

# 一周前的每秒请求数
rate(http_requests_total[5m] offset 1w)

算术：加减乘除、取模、乘方（^）。可以在两个标量、标量vs瞬时矢量、 两个瞬时矢量之间进行。

比较：== != > >= < <=。可以在两个标量、标量vs瞬时矢量、 两个瞬时矢量之间进行。

逻辑：and or unless。仅仅用于两个瞬时矢量之间：

1. and，取v1 v2中具有完全一致Label的那些时间序列，构成v3返回
2. or，取v1所有时间序列，外加v2中那些Label在v1中不存在的时间序列，构成v3返回
3. unless，取v1中那些没有在v2中具有相同Label的时间序列

对两个瞬时矢量应用操作符时，牵涉到如何找到左侧矢量元素在右侧矢量中的匹配元素的问题。匹配都是基于Label的。

矢量匹配的行为有两种：1对1匹配，1对多匹配：

vector1 <operator> vector2

# 匹配时忽略一些标签
<vector expr> <bin-op> ignoring(<label list>) <vector expr>
# 仅仅针对某些标签进行匹配
<vector expr> <bin-op> on(<label list>) <vector expr>

# 500错误占比分析
method_code:http_errors:rate5m{code="500"} / ignoring(code) method:http_requests:rate5m

操作符列表：

操作符	说明	操作符	说明
min	最小值	max	最大值
sum	求和	avg	求平均
count	统计数量	count_values	统计同值元素量
bottomk	最小N元素	topk	最大N元素
quantile	分位数（例如求中位数）

语法：

<aggr-op>([parameter,] <vector expression>) [without|by (<label list>)]
# parameter：仅count_values, quantile, topk, bottomk需要
# without：从结果矢量中移除指定的标签
# by：仅仅保留指定的标签

# 示例：
sum(http_requests_total) without (instance)
sum(http_requests_total) by (application, group)
count_values("version", build_version)
topk(5, http_requests_total)

不能对已经聚合过的数据再进行rate，只能对原始counter进行rate。正确的示例：

# 对平均值，按service进行分组
    # 对每个指标求每分钟平均值
sum(rate(dubbo_consumer_elapsed_ms{kubernetes_namespace="$namespace"}[2m]) * 60) by (service)    /
# 分组之后的数据仍然可以进行算术运算，按service值分别进行运算
sum(rate(dubbo_consumer_success_count{kubernetes_namespace="$namespace"}[2m]) * 60) by (service)

这里使用Helm Chart方式安装，Chart的源码位于：

https://git.gmem.cc/alex/helm-charts/src/branch/master/prometheus。

安装脚本如下：

rm -rf prometheus
helm fetch gmem/prometheus --untar
helm install prometheus --name=prometheus --namespace=kube-system  -f prometheus/overrides/gmem.yaml

上面的Chart默认配置了以下Job：

启动Prometheus后，访问http://localhost:9090/metrics可以查看Prometheus本身的指标信息：

# curl http://localhost:9090/metrics
# 输出示意片断
# HELP http_requests_total Total number of HTTP requests made.
# TYPE http_requests_total counter
# 指标名             {标签=值,标签=值...}                       指标值
http_requests_total{code="200",handler="graph",method="get"} 3
http_requests_total{code="200",handler="label_values",method="get"} 5
http_requests_total{code="200",handler="prometheus",method="get"} 4105
http_requests_total{code="200",handler="query",method="get"} 13
http_requests_total{code="200",handler="query_range",method="get"} 3
http_requests_total{code="200",handler="static",method="get"} 26
http_requests_total{code="304",handler="static",method="get"} 20
# 在http://localhost:9090/graph的控制台中输入http_requests_total进行查询，也可以得到上面的输出

http_requests_total是Prometheus暴露（Export）的关于自身的指标 —— 接受的HTTP请求总数，包括了多个时间序列数据。这些时间序列数据的指标名都一样，但是具有不同的标签，这些标签用于区分不同类型的HTTP请求。

我们可以在控制台输入

http_requests_total{code="200"}

类似的，还可以使用表达式

count(http_requests_total)

在http://localhost:9090/graph页面，点击Graph选项卡，可以生成图表。例如表达式

rate(http_requests_total[1m])

Node Exporter是Prometheus提供的，用于监控Linux系统的组件。对于Windows，则有功能类似的WMIExporter。

下载NodeExporter后运行，它默认会在9100端口上暴露本机的各项指标。你可以访问http://localhost:9100/metrics来查看。修改Prometheus默认配置文件尾部的9090端口为9100即可采集这些指标。

这个项目是Google开源的，专门采集容器资源用量、性能指标。cAdvisor嵌入在kubelet中运行。

此项目可以暴露JMX管理Beans给Prometheus采集。它作为Java Agent运行，开启一个HTTP端口，对外提供本地JVM的各项指标。

为JVM添加参数：

-javaagent:jmx_prometheus_javaagent-0.3.1.jar=9100:config.yaml

格式为YAML：

# 延迟于JVM启动HTTP端口的时间
startDelaySeconds: 0
# 如果连接到远程JVM，采集JMX信息，则要么指定hostPort，要么指定jmxUrl
hostPort: 127.0.0.1:1234
jmxUrl: service:jmx:rmi:///jndi/rmi://127.0.0.1:1234/jmxrmi
# 远程JMX身份验证信息
username: 
password: 
# 远程JMX是否通过SSL连接
ssl: false
# 是否小写化指标名、标签名
lowercaseOutputName: false
lowercaseOutputLabelNames: false
# 是否采集的ObjectNames的白、黑名单。默认采集所有mBeans
whitelistObjectNames: ["org.apache.cassandra.metrics:*"]
blacklistObjectNames: ["org.apache.cassandra.metrics:type=ColumnFamily,*"]
# 规则列表，从上往下执行，遇到匹配的规则则终止
# 不匹配的Attributes不被采集，默认情况下，以默认格式采集所有
rules:
    # 匹配mBean Attributes的正则式
  - pattern: 'org.apache.cassandra.metrics<type=(\w+), name=(\w+)><>Value: (\d+)'
    # 指标名
    name: cassandra_$1_$2
    # 指标值
    value: $3
    # 指标值需要乘以的系数
    valueFactor: 0.001
    # 标签，可以使用捕获组
    labels: {}
    # 指标帮助信息
    help: "Cassandra metric $1 $2"
    # 指标类型
    type: GAUGE
    # 转换为下划线 + 小写风格
    attrNameSnakeCase: false

如果没有任何配置内容，则以默认格式采集本地JVM的所有指标。

官方提供了若干中间件的示例配置文件。 

传递给配置文件rules.pattern的格式为：

# domain mBean的名称，JMX ObjectNames的冒号前的部分
# beanProperyName/Value mBean属性列表，JMX ObjectNames的冒号后的部分
# keyN 如果是组合或表格数据，则包含键列表
# attrName 属性的名称，如果是表格数据，则为列名称。如果设置了attrNameSnakeCase则转换为下划线小写
# value 属性值
domain<beanpropertyName1=beanPropertyValue1, beanpropertyName2=beanPropertyValue2, ...><key1, key2, ...>attrName: value 

不经配置，输出的默认指标格式为：

domain_beanPropertyValue1_key1_key2_...keyN_attrName{beanpropertyName2="beanPropertyValue2", ...}: value 

Prometheus提供了主流语言的客户端库。要使用Prometheus的Go客户端库，导入：

import "github.com/prometheus/client_golang/prometheus"

该结构是任何Prometheus指标都需要使用的描述符，它本质上是指标（Metrics）的不可变元数据：

struct {
	// 全限定名称，由命名空间 - 子系统 - 名称组成
	fqName string
	// 指标的帮助信息
	help string
	// 常量标签键值
	constLabelPairs []*dto.LabelPair
	// 可变标签的名字
	variableLabels []string
	// 基于ConstLabels和fqName生成的哈希，所有注册的Desc都必须具有独特的值
        // 以作为Desc的唯一标识
	id uint64
	// 维度哈希，所有常量/可变标签的哈希，所有具有相同fqName的Desc必须具有相同的dimHash
	// 这意味着每个fqName对应的标签集是固定的
	dimHash uint64
	// 构造时出现的错误，注册时报告
	err error
}

所有指标的通用接口，表示需要导出到Prometheus的单个采样值+关联的元数据集 。此接口的实现包括Gauge、Counter、Histogram、Summary、Untyped。

type Metric interface {
	// 幂等的返回该指标的、不可变的描述符
	// 不能描述子集的指标，必须返回一个无效的描述符。无效描述符通过NewInvalidDesc创建
	Desc() *Desc
	// 将指标对象编码为ProtoBuffer数据传输对象
	// 指标实现必须考虑并发安全性，因为对指标的读可能随时发生，任何阻塞操作都会影响
	// 所有已经注册的指标的整体渲染性能
	// 理想的实现应该支持并发读
	//
	// 除了产生dto.Metric，实现还负责确保Metric的ProtoBuf合法性验证
	// 建议使用字典序排序标签，LabelPairSorter可能对指标实现者有帮助
	Write(*dto.Metric) error
}

此结构表示用于bundle全限定名称、标签值有所不同的指标。通常不会直接使用此结构，而是将它作为具体指标向量GaugeVec, CounterVec, SummaryVec,  UntypedVec的一部分：

type MetricVec struct {
	mtx      sync.RWMutex // 保护元素的锁
	children map[uint64][]metricWithLabelValues // 所有指标实例（值+标签集）
	desc     *Desc // 描述符

	newMetric   func(labelValues ...string) Metric  // 以指定的标签值创建新指标
	hashAdd     func(h uint64, s string) uint64
	hashAddByte func(h uint64, b byte) uint64
} 

创建大部分的指标类型时，可以通过该接口提供选项：

type Opts struct {
	// Namespace, Subsystem, Name是指标的全限定名称的组成部分，这些部分使用下划线连接
	// 仅仅Name是必须的
	Namespace string
	Subsystem string
	Name      string

	// 帮助信息，单个全限定名称，其帮助信息必须一样
	Help string

	// 常量标签用于为指标提供固定的标签，单个全限定名称，其常量标签集的所包含的标签名必须一致
	// 注意在大部分情况下，标签的值会变化，这些标签通常由指标矢量收集器（metric vector collector）来
	// 处理，例如CounterVec、GaugeVec、UntypedVec，而ConstLabels则仅用于特殊情况，例如：
	// vector collector (like CounterVec, GaugeVec, UntypedVec). ConstLabels
	// 1、在整个处理过程中，标签的值绝不会改变。这种标签例如运行中的二进制程序的修订版号
	// 2、在具有多个收集器（collector）来收集相同全限定名称的指标的情况下，那么每个收集器收集的
	//    指标的常量标签的值必须有所不同
	// 如果任何情况下，标签的值都不会改变，它可能更适合编码到全限定名称中
	ConstLabels Labels
}

任何Prometheus用来收集指标的对象，都需要实现此接口：

type Collector interface {
	// 将此收集器收集的指标的所有可能的描述符发送到参数提供的通道。并且在最后一个描述符
	// 发送成功后返回。发送的描述符必须满足Desc文档声明的一致性、唯一性要求
	// 
	// 同一收集器发送重复的描述符是允许的，重复自动忽视
	// 但是两个收集器不得发送重复的描述符
	//
	// 如果不发送任何描述符，则收集器标记为unchecked状态，也就是说在注册时，不会进行任何检查
	// 收集器以后可能产生任何匹配它的Collect方法签名的指标
	//
	// 该方法在收集器的生命周期里，幂等的发送相同的描述符
	// 
	// 该方法可能被并发的调用，实现时需要注意线程安全问题
	//
	// 如果在执行该方法的过程中收集器遇到错误，务必发送一个无效的描述符（NewInvalidDesc）来提示注册表
	Describe(chan<- *Desc)
	// 在收集指标时，该方法被Prometheus注册表（Registry）调用。方法的实现必须将所有它收集到的指标
	// 经由参数提供的通道发送，并且在最后一个指标发送后返回
	// 
	// 每个发送的指标的描述符，必须是Describe方法提供的之一（除非收集器是Unchecked）
	// 发送的共享相同描述符的指标，其标签集必须有所不同
	// 
	//
	// 该方法可能被并发的调用，实现时需要注意线程安全问题
	// 
	// 阻塞会导致影响所有已注册的指标的渲染性能，理想情况下，实现应该支持并发读
	Collect(chan<- Metric)
} 

收集器必须被注册（Registerer.Register）才能收集指标值。

内置的指标类型实现了此接口，包括GaugeVec、CounterVec、HistogramVec、SummaryVec。

注册表，此结构实现了Registerer、Gatherer接口。

Registerer接口为注册表提供注册/反注册功能：

type Registerer interface {
	// 注册一个需要包含在指标集中的收集器。如果收集器提供的描述符非法、
	// 或者不满足metric.Desc的一致性/唯一性需求，则返回错误
	//
	// 如果相等的收集器已经注册过，返回AlreadyRegisteredError，其中包含先前注册的收集器的实例
	//
	// 其Describe方法不产生任何Desc的收集器，视为Unchecked，对这种收集器的注册总是成功
	// 重现注册它时也不会有检查。因此，调用者必须负责确保不会重复注册
	Register(Collector) error
	// 注册多个收集器，并且在遇到第一个失败时就Panic
	MustRegister(...Collector)
	// 反注册
	Unregister(Collector) bool
}

Gatherer为注册表提供汇集（gathering）功能 —— 将已经收集的指标汇集到若干指标族（MetricFamily）中：

type Gatherer interface {
	// 该方法调用所有已经注册的收集器的Collect方法，然后将获得的指标存放到一个字典序排列
	// 的MetricFamily的切片中。该方法保证返回的切片是有效的、自我一致的，可以用于对外
	// 暴露（给Prometheus服务器）该方法容忍相同指标族中具有不同标签集的指标
	//
	// 即时发生错误，该方法也会尝试尽可能收集更多的指标。因此，当该方法返回非空error时
	// 同时返回的dto.MetricFamily切片可能是nil（意味着致命错误）或者包含一定数量的
	// MetricFamily —— 切片可能是不完整的
	Gather() ([]*dto.MetricFamily, error)
} 

表示gauge类型的指标： 

type Gauge interface {
	// 实现的接口
	Metric
	Collector

	// 设值
	Set(float64)
	// 增1
	Inc()
	// 减1
	Dec()
	// 加上一个值
	Add(float64)
	// 减去一个值
	Sub(float64)
}

要创建一个Gauge，可以调用：

func NewGauge(opts GaugeOpts) Gauge {
	// func newValue(desc *Desc, valueType ValueType, val float64, labelValues ...string) *value
	return newValue(NewDesc(
		BuildFQName(opts.Namespace, opts.Subsystem, opts.Name),
		opts.Help,
		nil,
		opts.ConstLabels,
	), GaugeValue, 0)
}

GaugeVec表示Gauge的向量：

type GaugeVec struct {
	*MetricVec
}

表示histogram类型的指标。

Histogram对可配置的Bucket（观察值的区间）中的事件或样本流，基于Bucket进行独立计数观察。它支持对观察值（observations）进行计数，或者求和。

在Prometheus中，分位数可以基于Histogram，通过函数histogram_quantile计算得到。Histogram依赖于用户定义的、适当的buckets，一般来说精确度相对较低，但是和Summary比起来，Histogram的性能成本较低。

type Histogram interface {
	Metric
	Collector

	// 添加一个观察值
	Observe(float64)
}

默认的Buckets如下，主要用于测量网络响应延迟的场景：

DefBuckets = []float64{.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10}

对于其它场景，你应当自己定义Buckets。 

我们不会直接操控指标，而是使用它们的向量 —— GaugeVec、CounterVec、HistogramVec、SummaryVec。这些向量都是Collector接口的实现。

要创建向量，需要调用prometheus.New***Vec方法，例如：

func NewGaugeVec(opts GaugeOpts, labelNames []string) *GaugeVec {
// 描述符，关键信息是全限定名 + 标签集
	desc := NewDesc(
		BuildFQName(opts.Namespace, opts.Subsystem, opts.Name),
		opts.Help,
		labelNames,
		opts.ConstLabels,
	)
	return &GaugeVec{
		metricVec: newMetricVec(desc, func(lvs ...string) Metric {
// 第二个参数是回调，标签集创建一个Metric —— 指标，准确的说是时间序列
			if len(lvs) != len(desc.variableLabels) {
				panic(makeInconsistentCardinalityError(desc.fqName, desc.variableLabels, lvs))
			}
			result := &gauge{desc: desc, labelPairs: makeLabelPairs(desc, lvs)}
			result.init(result) // Init self-collection.
			return result
		}),
	}
} 

下面的例子创建一个Gauge向量：

weight := prometheus.NewGaugeVec(prometheus.GaugeOpts{
	Subsystem: "flagger",
	Name:      "canary_weight",
	Help:      "The virtual service destination weight current value",
}, []string{"workload", "namespace"})  // 注意标签顺序

获取具有指定标签值的Gauge（时间序列）： 

// 注意标签值的顺序，和上面对应
gauge := cr.weight.WithLabelValues(cd.Spec.TargetRef.Name, cd.Namespace)

产生一个指标值：

gauge.Set(float64(canary))

下面的例子使用默认Bucket创建Histogram向量：

duration := prometheus.NewHistogramVec(prometheus.HistogramOpts{
	Subsystem: controllerAgentName,
	Name:      "canary_duration_seconds",
	Help:      "Seconds spent performing canary analysis.",
	Buckets:   prometheus.DefBuckets,
}, []string{"name", "namespace"})

产生一个指标值：

cr.duration.WithLabelValues(cd.Spec.TargetRef.Name, cd.Namespace).Observe(duration.Seconds())

Prometheus客户端提供了开箱即用的默认注册表：

prometheus.DefaultRegisterer

你可以调用以下函数来创建注册表：

// 不预先注册任何收集器的注册表
func NewRegistry() *Registry {
	return &Registry{
		collectorsByID:  map[uint64]Collector{},
		descIDs:         map[uint64]struct{}{},
		dimHashesByName: map[string]uint64{},
	}
}

// 创建一个严格的注册表。该注册表在收集期间，检查
// 1、每个指标是否和它的Desc一致
// 2、指标的Desc是否已经注册到注册表
// Unchecked的收集器不被检查
func NewPedanticRegistry() *Registry {
	r := NewRegistry()
	r.pedanticChecksEnabled = true
	return r
}

示例：

registry = prometheus.NewPedanticRegistry()

// 进行注册
if err := registry.Register(gauge); err != nil {
// 如果已经注册
	if are, ok := err.(prometheus.AlreadyRegisteredError); ok {
// 返回先前注册的收集器
		return are.ExistingCollector, nil
	}
	return nil, err
} 

Prometheus客户端不能直接将指标发送给Prometheus服务器。只能通过网络端口暴露一个Exporter。

如果要基于HTTP协议暴露，将promhttp包提供的Handler传递给你的HTTP服务器，每个Handler读取单个注册表，从中收集指标信息，生成HTTP响应：

// 使用默认注册表创建Handler
func Handler() http.Handler {
	return InstrumentMetricHandler(
		prometheus.DefaultRegisterer, HandlerFor(prometheus.DefaultGatherer, HandlerOpts{}),
	)
}

如果你需要使用非默认注册表，直接调用：

func HandlerFor(reg prometheus.Gatherer, opts HandlerOpts) http.Handler {}

 然后将Handler传递给你的ServeMux即可：

mux := http.NewServeMux()
import "github.com/prometheus/client_golang/prometheus/promhttp"
mux.Handle("/metrics", promhttp.Handler())

The post Prometheus学习笔记 appeared first on 绿色记忆.

InfluxDB是一个用于存储和分析时间序列数据的开源数据库。它的特性包括：

1. 支持HTTP接口
2. 支持类SQL的查询 —— InfluxQL
3. 高效的数据读写

InfluxDB默认使用两个端口：8086用于HTTP接口，8088用于备份/恢复数据的RPC服务。

curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/lsb-release
echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

sudo apt-get update
sudo apt-get install influxdb
sudo service influxdb start

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: influxdb-pvc
  namespace: dev
spec:
  storageClassName: rook-block
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

---

apiVersion: v1
kind: Pod
metadata:
  namespace: dev
  name: influxdb
  labels:
    app: influxdb
  annotations:
    "cni.projectcalico.org/ipAddrs": "[\"172.27.0.20\"]"
spec:
  terminationGracePeriodSeconds: 10
  containers:
  - name: influxdb
    image: docker.gmem.cc/influxdb
    ports:
    - containerPort: 8086
      name: http
    - containerPort: 8082
      name: ifql
    volumeMounts:
      - name: influxdb-pv
        mountPath: /var/lib/influxdb
  volumes:
    - name: influxdb-pv
      persistentVolumeClaim:
        claimName: influxdb-pvc

--- 

apiVersion: v1
kind: Service
metadata:
  name: influxdb
  namespace: dev
spec:
  ports:
  - name: http
    port: 8086
    protocol: TCP
    targetPort: 8086
  selector:
    app: influxdb
  sessionAffinity: None
  type: ClusterIP

执行下面命令进入CLI：

kubectl -n dev exec -it influxdb  influx -- -precision rfc3339

命令格式类似于MySQL：

CREATE DATABASE metrics
SHOW DATABASES
# name: databases
# name
# ----
# _internal
# metrics
USE metrics

InfluxDB中存放的是时间序列数据，包括0-N个数据点。数据点由以下部分组成：

1. time，时间戳
2. measurement，此指标的名字。例如CPU_LOAD
3. field，至少一个，KV对，V为数值例如value=6.12
4. tag，0-N个，指标的元数据。 host=zircon

指标的模式（Schema）是自由的，你可以任意添加字段、Tag。但是字段类型不可以改变，如果你第一次写入host的值类型是字符串，就不能在以后写入数字。

写入数据点时，你需要遵守如下格式的行协议：

<measurement>[,<tag-key>=<tag-value>...] <f1-key>=<f1-val>[,<f2-key>=<f2-val>...] [unix-nano-timestamp]
# 示例：
load,host=xenial-100,group=k8s value=3.1

通过CLI差入数据的InfluxQL语法为：

INSERT load,host=xenial-100,group=k8s value=3.1

类似的，可以用SELECT查询指标数据：

SELECT * FROM load
# name: load
# time                group host       value
# ----                ----- ----       -----
# 1522746924735704773 k8s   xenial-100 3.1

# 每个Tag、字段都可以作为列名
SELECT "group", host,value FROM "load"

FROM子句中，支持使用正则式来匹配指标名：

SELECT * FROM /.*/ LIMIT 1

WHERE子句也是支持的。

export URL=http://influxdb.dev.svc.k8s.gmem.cc:8086

# 执行InfluxQL             格式化响应JSON                   查询语句
curl -i -XPOST $URL/query?pretty=true --data-urlencode "q=SHOW DATABASES"
curl -i -XPOST $URL/query?pretty=true --data-urlencode "q=CREATE DATABASE metrics" 

# 写入操作，响应码204，数据正常写入
# 时间戳（纳秒）可以不传，这样自动使用InfluxDB本地时间
curl -i -XPOST $URL/write?db=metrics --data-binary 'host=xenial-100,group=k8s value=3.1 1434055562000000000'

# 可以同时写入多个数据点，使用换行符分隔

# 导入文件中的数据点、
curl -i -XPOST $URL/write?db=metrics --data-binary @load.txt 

curl -G $URL/query?pretty=true --data-urlencode "db=metrics" --data-urlencode "q=SELECT * FROM load"

结果同样以JSON形式返回。要同时执行多个查询，只需要用分号分开InfluxQL语句。

使用请求参数chunked/chunk_size可以发起分块（Chunked）请求，数据流式返回：

--data-urlencode "chunked=true" --data-urlencode "chunk_size=20000 

Influx提供了持续查询（Continuous Queries，CQ）来处理数据采样。CQ是按照时间进行聚合的InfluxQL语句，周期性的在Influx数据库内部运行。示例：

-- 查询数据库metrics的指标network的inbound、outbuound字段，对两者取平均值
-- 每30分钟分组聚合一次
-- 聚合结果存放到RP为one_year的指标sampled_load中，该指标具有字段mean_inbound、mean_outbound
CREATE CONTINUOUS QUERY "cq_30m" ON "metrics" BEGIN
    SELECT mean("inbound") AS "mean_inbound",mean("outbound") AS "mean_outbound"
    INTO "one_year"."sampled_load"
    FROM "network"
    GROUP BY time(30m)
END

配合使用CQ和RP，可以实现近期数据高精度保留，远期数据低精度保留甚至删除。 

Retention Policy（RP）定义了InfluxDB保留历史数据的时长。示例：

# 为指标load定义一个驻留策略，时长2小时
# REPLICATION为数据复制的份数，对于单节点InfluxDB，必须设置为1
CREATE RETENTION POLICY "two_hours" ON "load" DURATION 2h REPLICATION 1 DEFAULT 

 配置文件默认位于/etc/influxdb/influxdb.conf。

# 禁止向usage.influxdata.com发送使用情况信息
reporting-disabled = false

# 数据备份/恢复服务绑定地址
bind-address = "127.0.0.1:8088"


[meta]
# metadata/raft数据库的存放位置
dir = "/var/lib/influxdb/meta"
# 创建数据库时，自动创建默认的驻留策略
retention-autocreate = true
# 为meta service打印日志
logging-enabled = true


[data]
# TSM存储引擎在何处存储TSM文件
dir = "/var/lib/influxdb/data"
# TSM存储引擎在何处存储TWAL文件
wal-dir = "/var/lib/influxdb/wal"
# 写操作fsync到磁盘的延迟，大于0的值可以用于慢速磁盘，以及WML写出现竞态的情况
# 对于非SSD磁盘，推荐取值范围0-100ms
wal-fsync-delay = "0s"
# 新分片使用的分片索引（Shard index）类型，默认是内存索引，重启后会重新创建
# 取值tsi1使用基于磁盘的索引，支持大cardinality数据集
index-version = "inmem"
# 是否启用tsm引擎的冗长日志 
trace-logging-enabled = false
# 是否启用查询日志
query-log-enabled = true
### TSM引擎配置 ###
# 在拒绝写入操作之前，分片缓存占用的内存最大量
cache-max-memory-size = "1g"
# 当缓存达到多大时，引擎产生其快照，并写入到TSM文件，以释放内存空间
cache-snapshot-memory-size = "25m"
# 如果分片持续多久没有接收到新的写入/删除操作，则引擎产生缓存的快照，并写入到新的TSM文件
cache-snapshot-write-cold-duration = "10m"
# 如果引擎持续多久没有接收到分片的新的写入/删除操作，它将压缩分片的所有TSM文件
compact-full-write-cold-duration = "4h"
# 压缩并行度
max-concurrent-compactions = 0
# 在丢弃写操作之前，每个数据库允许的最大序列（Series）数量
# 可以在数据库级别解决高Cardinality问题，设置为0则禁用
max-series-per-database = 1000000
# 在丢弃写操作之前，每个Tag的最大值数量
# 可以解决Tag值的高Cardinality问题，设置为0则禁用
max-values-per-tag = 100000


# 集群服务配置
[coordinator]
# 写操作超时时间
write-timeout = "10s"
# 同时执行的查询的最大数量
max-concurrent-queries = 0
# 查询超时：在查询被系统杀掉之前，经过的最大时间
query-timeout = "0s"
# 缓慢查询阈值，超过此阈值的被记录到缓慢日志
log-queries-after = "0s"
# 一个SELECT最多能处理的数据点数量
max-select-point = 0
# 一个SELECT可以处理的Series的最大数量
max-select-series = 0
# 一个SELECT最多创建的Group by 时间桶（Time Bucket）数量
max-select-buckets = 0


# 驻留策略配置，驻留策略决定了如何清除老旧数据
[retention]
# 是否启用驻留策略，也就是说是否清除老旧数据
enabled = true
# 每隔多久进行运行驻留策略
check-interval = "30m"


# 控制分配的预创建，这样在数据到达前分片即可用
[shard-precreation]
# 是否启用分片预创建服务
enabled = true
# 预创建服务运行间隔
check-interval = "10m"

advance-period = "30m"


# 系统自我监控、统计和诊断
[monitor]
# 是否在内部进行统计信息
store-enabled = true
# 存储统计信息的目标数据库
store-database = "_internal"
# 每隔多久记录一次统计信息
store-interval = "10s"


[http]
# 是否启用HTTP端点
enabled = true
# HTTP服务的绑定地址
bind-address = ":8086"
# 是否启用用户身份验证
auth-enabled = false
# 基于HTTP基本认证时，发送给客户端的Realm信息
realm = "InfluxDB"
# 是否记录HTTP请求日志
log-enabled = true
# 访问日志路径
access-log-path = ""
# 是否启用详细的写日志
write-tracing = false
# 是否启用pprof端点，用于调试和诊断
pprof-enabled = true
# 是否启用HTTPS
https-enabled = false
# SSL整数路径
https-certificate = "/etc/ssl/influxdb.pem"
# 可以指定单独的私钥路径
https-private-key = ""
# SON web token共享密钥
shared-secret = ""
# 结果集大小限制，防止查询耗尽InfluxDB内存
# 仅仅限制非分块的HTTP API请求，分块请求不受限制
max-row-limit = 0
# 最大连接数
max-connection-limit = 0
# 是否使用UNIX域套接字
unix-socket-enabled = false
# UNIX域套接字路径
bind-socket = "/var/run/influxdb.sock"
# 客户端请求体大小
max-body-size = 25000000


[ifql]
# 是否启用RPC服务
enabled = true
# 是否进行额外的日志记录
log-enabled = true
# 绑定地址
bind-address = ":8082"


[logging]
# 日志格式
format = "auto"
# 日志级别
level = "info"
# 是否禁止显示LOGO
suppress-logo = false


# 控制订阅，订阅可以用于获取整个数据集的拷贝
[subscriber]
# 是否启用订阅者服务
enabled = true
# 写到订阅者的HTTP请求的超时
http-timeout = "30s"
# 是否允许到订阅者的不安全连接
insecure-skip-verify = false
# 数字证书位置
ca-certs = ""
# Goroutine数量
write-concurrency = 40
# 写缓冲区大小
write-buffer-size = 1000


[continuous_queries]
# 是否启用持续查询服务
enabled = true
# 是否记录CQ日志
log-enabled = true
# 是否记录统计信息
query-stats-enabled = false
# 多久检查CQ服务是否需要运行
run-interval = "1s"

The post InfluxDB学习笔记 appeared first on 绿色记忆.

OpenTSDB是一个开源的、被广泛使用的时间序列数据库。它提供了一整套和监控有关的功能，可以用来构建分布式、可扩容的监控系统。使用OpenTSDB可以不损失统计精度的永久保存监控数据，统计精度可以达到毫秒级。OpenTSDB的底层是Hadoop/HBase，可以扩容到每秒百万级的监控数据写操作。OpenTSDB自带了前端组件，并且支持通过HTTP Pull API拉取数据，这样你可以选择自己喜爱的前端组件。

The post OpenTSDB学习笔记 appeared first on 绿色记忆.

Grafana是一个独立运行的系统，内置了Web服务器。它可以基于仪表盘的方式来展示、分析时间序列数据。

Grafana支持多种数据源，例如：Graphite、OpenTSDB、InfluxDB、Elasticsearch。你可以混合使用多种数据源。它对Graphite有以下增强的支持：

1. 点击修改Metrics路径的每一个片断
2. 快速的添加函数，支持点击函数参数以修改之
3. 修改函数顺序
4. 丰富的模板支持

在UI方面，Grafana具有以下特性：

1. 丰富的、基于客户端的图表组件：Bar图、区域图、线图。支持多Y轴
2. 支持点击/选择以缩放（Zoom）时间区间
3. 支持混合多种图表组件，一起展示或者堆叠展示
4. 支持定制图表的配色，支持黑白两种主题
5. 支持拖放仪表盘面板（Panel），支持多种面板类型
6. 支持脚本化仪表盘、仪表盘模板
7. 通过来自数据源的事件（例如Graphite的Events），可以对仪表进行标注

依次执行下面的命令完成安装：

# CentOS
yum install initscripts fontconfig
wget https://grafanarel.s3.amazonaws.com/builds/grafana-3.1.1-1470047149.x86_64.rpm
rpm -Uvh grafana-3.1.1-1470047149.x86_64.rpm

设置为开机启动：

/bin/systemctl daemon-reload
/bin/systemctl enable grafana-server.service

启动服务：

systemctl start grafana-server.service

helm repo update gmem
helm del --purge grafana
helm install gmem/grafana --name grafana --namespace kube-system

# 执行下面的命令获得初始密码
kubectl get secret --namespace kube-system grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

值覆盖情况参考：https://github.com/gmemcc/charts/tree/master/grafana

grafana-cli plugins install grafana-kubernetes-app
grafana-cli plugins install natel-plotly-panel
grafana-cli plugins install kentik-app
grafana-cli plugins install alexanderzobnin-zabbix-app
grafana-cli plugins install grafana-worldmap-panel
grafana-cli plugins install grafana-clock-panel
grafana-cli plugins install grafana-piechart-panel
grafana-cli plugins install percona-percona-app
grafana-cli plugins install digrich-bubblechart-panel
grafana-cli plugins install digiapulssi-breadcrumb-panel
grafana-cli plugins install petrslavotinek-carpetplot-panel
grafana-cli plugins install neocat-cal-heatmap-panel
grafana-cli plugins install briangann-gauge-panel
grafana-cli plugins install jdbranham-diagram-panel

安装插件后，需要重新启动Grafana服务：

service grafana-server restart

当Grafana服务启动时，会读取

/etc/sysconfig/grafana-server

默认的，日志文件存储目录为/var/log/grafana，数据存储目录为/var/lib/grafana。默认使用SQLite数据库/var/lib/grafana/grafana.db。

如果基于deb/rpm包进行安装，则主配置文件的位置为：

/etc/grafana/grafana.ini

127.0.0.1:3306

使用Grafana的日常工作包括：用户管理、系统管理、仪表盘设计、数据源管理，等等。所有这些工作都在Web界面

http://GRAFANA_HOST:3000

点击Web界面左上角的图标，下拉列表中选择Data Sources，即可管理数据源。

点击Add data source按钮，添加新的数据源，参考下图：

注意Access设置成proxy，则数据通过Grafana间接获取，否则，数据直接通过客户端获取。添加Graphite数据源后，可以点击Dashboards选项卡，获得其预置的仪表盘Graphite Carbon Metrics并导入到Grafana中。

点击Web界面左上角的图标，下拉列表中选择Dashboards  ⇨ New，可以新建仪表盘。在新仪表盘中，点击左侧的绿条，可以添加新的面板；点击右下侧ADD ROW按钮则可以新建一行。

The post 使用Grafana展示时间序列数据 appeared first on 绿色记忆.

Graphite是一个开源项目，可以作为时间序列数据库（TSDB）使用，当你需要存储随着时间变化的数值时，应当考虑使用时间序列数据库。

除了数据的存储、查询外，Graphite还提供数据可视化（UI层）功能，它可以很好的在廉价的硬件上运行。你可以使用Graphite来监控网站、应用程序、网络服务器等的性能数据（Metrics），轻松实现基于时间维的分析。

Graphite本身不负责性能数据的采集，但是它提供了简单易用的接口，公共这些接口你可以把基于数字的性能数据存储到Graphite中。

Graphite由三个组件构成：

1. Carbon：一个基于Twisted（Python事件驱动网络框架）的守护程序，负责监听外部的时间序列数据
2. Whisper：一个简单的存储时间序列数据的数据库，设计上和RRDtool类似 
3. Graphite-Web：一个基于Django（Python Web框架）的Web应用，使用Cairo（一个2D图形库）来渲染性能数据的图表，使用ExtJS作为基础UI框架

下面是Graphite的架构图：

一旦你把数据送给Carbon，它就立刻可以在Webapp的图表中显示，因为数据在被写入文件系统之前，会驻留在缓存中。

除了使用Graphite Webapp，你也可以通过URL API，将图表嵌入到自己的应用程序中去。如何使用Graphite

使用Graphite来监控你的性能数据，你需要完成以下工作：

1. 理解Graphite组件的职责和相互关系
2. 安装Graphite及其依赖
3. 基础的配置，让Graphite能运行起来
4. 设计Metrics路径
5. 配置Metrics的驻留规则、聚合规则等
6. 向Graphite发送Metrics
7. 从Graphite获取Metrics并展示

Metrics路径由点号分隔的字符串构成，类似于Python的包名称。路径是Metrics的标识。

你应当仔细的设计此路径的命名空间，以反映出所有Metrics之间的层次关系。例如servers.zircon.cpu，这个三级路径设计中，第一级表示设备类别，第二级表示设备名称，第三级表示监测点类型。

Carbon由一系列的守护进程组成，这些守护进程共同组成Graphite的存储后端。在最小化的安装下，只有一个守护进程carbon-cache.py。根据需要你可以启用carbon-relay.py、carbon-aggregator.py以便实现Metrics分发、定制聚合规则。各Carbon守护进程简介如下：

Whisper是一个固定大小（fixed-size）的数据库，其设计和用途与RRD（round-robin-database）类似。它能提供快速、可靠的数值数据的存储。

Whisper能够对最近的数据进行高分辨率的存储，而对久远的历史数据，自动降低其存储精度（减少样本数量）。

在大多数场景下，Whisper有足够好的性能。它比RRDtool慢，主要原因是Whisper基于Python编写，这个性能差异很小，通常不需要考虑。

Whisper数据库以文件方式存放在磁盘上，扩展名.wsp。Carbon会为每个Metrics创建一个.wsp文件，路径的最后一节作为文件的basename，路径的其它部分形成目录层次。

在Whisper中存储的每一个数值，称为数据点（Data Points）。

在磁盘上，数据点以大端、双精度浮点数存储。每个数据还附带一个时间戳信息，时间戳为1970-01-01到数据采集时间的秒数。

一个Whisper数据库文件可以包含一个或者多个“归档”，归档是数据文件中的逻辑段。

每个归档具有不同的数据分辨率（一定时间段内，数据点数量越多，则分辨率越高）。归档以最高分辨率（最小驻留时间） —— 最低分辨率（最长驻留时间）的顺序，在数据库文件中顺序排列。

为了精确的从高分辨率向低分辨率的归档聚合，高分辨率归档和它之后的低分辨率归档，其分辨率应当具有整除关系。例如，第一个归档分辨率为60秒/数据点，那么第二个归档可以是300秒/数据点，第三个归档可以是3600秒/数据点。

一个数据库的总计驻留时间（存放的数据点跨越的时间），由最长驻留时间的（最后一个）归档确定。因为之前的那些归档，时间区间都是它的子区间。

把数据点转移到低分辨率归档时，面临着如何把多个数据点转变为单个数据点的问题。Whisper支持average、sum、last、max、min等聚合函数。

注意，这里的聚合和Carbon提供的前置聚合不是一回事。

当Whisper向一个多归档数据写入Metrics时，数据点将被同时写入到所有的归档中。这意味着聚合动作随时可能发生。

当从Whisper中获取数据时，第一个能完整覆盖所需区间的归档被使用。

Whisper的磁盘利用效率不高，因为：

1. 每个数据点要附加一个时间戳信息
2. 由于归档的时间区间有重叠，因此数据存在冗余
3. 归档中的时间槽位（time-slots）总是占据着磁盘空间，不管有没有值存储在其中

这些特征是故意的，主要出于性能方面的考虑。

1. RRD不能去填充以前的时间槽位。这意味着每一条数据都必须是更新的，不会“补录”
2. RRD不能很好的支持不规则的数据更新。如果RRD接收到一条数据，但是后续数据没有到来，则前一条数据可能丢失

git clone https://github.com/graphite-project/graphite-web.git
graphite-web/check-dependencies.py
# 根据输出的提示来判断缺少哪些依赖，然后安装

yum -y install python-devel     # Carbon 依赖于 Python Development Headers

yum install pycairo             # Cairo库的Python绑定

pip install django              # Web框架
pip install django-tagging

pip install pytz

yum install fontconfig

yum install -y memcached        # 可选，缓存支持
pip install python-memcached    
                                # 可选，RDDTool
yum install cairo-devel libxml2-devel pango-devel pango libpng-devel freetype freetype-devel libart_lgpl-devel rrdtool-devel

pip install python-rrdtool      # 可选，RRD支持

pip install whitenoise          # 用于Web静态文件处理

yum install pyOpenSSL           # OpenSSL的Python绑定
pip install service_identity    # SSL相关

pip install https://github.com/graphite-project/ceres/tarball/master
pip install whisper
pip install carbon
pip install graphite-web

sudo groupadd graphite
sudo usermod -a -G graphite root
sudo usermod -a -G graphite apache
sudo chgrp -R graphite /opt/graphite/storage
sudo chmod -R 770 /opt/graphite/storage

Whisper被安装到Python全局site-packages目录，另外两个Graphite组件安装到

/opt/graphite

$GRAPHITE_ROOT

$STORAGE_DIR

你需要让Graphite-web的底层框架Django执行数据库的初始化。此数据库被用来存放用户设置、仪表盘，以及支持事件功能。

默认情况下，Graphite-web使用位于$STORAGE_DIR/graphite.db的SQLite数据库。如果要运行多个Graphite-web实例，则必须使用MySQL等数据库以便多个实例可以共享数据。 

执行下面的命令初始化SQLite数据库：

PYTHONPATH=/opt/graphite/webapp django-admin.py migrate --settings=graphite.settings --run-syncdb
# 完毕后 $STORAGE_DIR/graphite.db自动创建

Django应用需要在Web服务器中运行，Web服务器需要对SQLite数据文件有读写权限。假设你使用Apache2，运行Apache2的用户为apache，则需要执行：

sudo chgrp graphite /opt/graphite/storage/graphite.db

Graphite不建议修改settings.py，所有定制化的配置，都应该在此文件中进行。常用的设置项如下表：

rrdtool flushcached

DEFAULT_CACHE_POLICY = [
    (0, 60), # 默认缓存60秒
    (7200, 120) # >= 2小时以上时间范围的查询，缓存2分钟
] 

# 如果报Unknown command: 'collectstatic' 说明INSTALLED_APPS中缺少
# django.contrib.staticfiles	
PYTHONPATH=/opt/graphite/webapp django-admin.py collectstatic 
    --noinput --settings=graphite.settings

Alias /static/ "/opt/graphite/static"

我们的配置如下：

# 如果不设置，会导致报错：AttributeError: 'Settings' object has no attribute 'URL_PREFIX
URL_PREFIX = '/'

多种Web服务器可以用于运行基于Django的Web应用，这里我们选择Apache2。在CentOS下安装Apache2：

yum install httpd

要让Apache2能够运行Python Web应用，需要安装模块mod_wsgi。参考Django学习笔记完成mod_wsgi的构建与安装。

在/opt/graphite/examples/目录下，example-graphite-vhost.conf可以作为Apache虚拟主机的模板，复制该文件到/etc/httpd/conf.d/目录下，然后修改：

<IfModule !wsgi_module.c>
    LoadModule wsgi_module modules/mod_wsgi.so
</IfModule>
WSGISocketPrefix run/wsgi
<VirtualHost *:7767>
        ServerName xcentos7.local
        DocumentRoot "/opt/graphite/webapp"
        ErrorLog /opt/graphite/storage/log/webapp/error.log
        CustomLog /opt/graphite/storage/log/webapp/access.log common
        WSGIDaemonProcess graphite processes=5 threads=5 display-name='%{GROUP}' inactivity-timeout=120
        WSGIProcessGroup graphite
        WSGIApplicationGroup %{GLOBAL}
        WSGIImportScript /opt/graphite/conf/graphite.wsgi process-group=graphite application-group=%{GLOBAL}
        WSGIScriptAlias / /opt/graphite/conf/graphite.wsgi
        Alias /content/ /opt/graphite/webapp/content/
        <Directory /opt/graphite/webapp/content/>
            Require all granted
        </Directory>
        <Directory /opt/graphite/conf/>
            Require all granted
        </Directory>
</VirtualHost>

如果配置没有问题，启动Web服务器后访问：

http://GRAPHITE_HOST:GRAPHITE_PORT/render

所有Carbon守护进程可以基于多种通信协议，监听时间序列数据，并且对数据进行不同的处理。

Carbon的配置文件位于/opt/graphite/conf/目录，默认情况下没有预置的配置文件，但是Graphite提供了若干配置文件样例。你可以复制这些配置文件并定制：

pushd /opt/graphite/conf
cp carbon.conf.example carbon.conf
cp storage-schemas.conf.example storage-schemas.conf

这是主配置文件，为每个Carbon守护进程定义配置项。该配置文件按段区分不同守护进程的配置：

这个配置文件用于定义Metrics的驻留率（ retention rates）——即Metrics的数据点（datapoints）以什么频率保存，保存多长时间。关于该配置文件，需要注意：

1. 该配置文件可以由多个段（Section）组成。每个段定义一个存储规则
2. 这些规则按照从上到下的顺序对Metrics进行匹配，第一个匹配的规则对Metrics生效
3. 匹配Metrics时，采用的是正则表达式
4. 对于一个Metrics，其存储规则在接收到第一个数据时固化。因而修改此配置文件不会影响到既有的.wsp文件。要应用到既有的.wsp可以调用whisper-resize.py

每个规则由三个部分组成：

# 段名称（规则名称），主要是文档用途。在匹配段的Metrics被创建时，日志creates.log中会显示此名称
[rulename]
# 匹配Metrics路径（Metrics的全限定名称，点号分隔）的正则式
# 举例：^servers\.www.*\.workers\.busyWorkers$
pattern=regex
# 驻留率表达式，数据点间隔:存留天数，时间后缀s,m,h,d,y分别表示秒、分、小时、天、年
# 举例：10s:14d 表示每个数据点表示10秒（相当于每10秒采集数据一次），并且存储14天的数据
retentions=retention rate

注意，你可以指定多重驻留率表达式（retention rate），逗号分隔每个表达式。一般从最高精度:最短存留时间开始指定，直到最低精度:最长存留时间。例如：

15s:7d,1m:21d,15m:5y

设置多重驻留率表达式，可以在保存足够长时间的历史数据的前提下，尽量减少磁盘I/O和消耗的存储空间。当跨越驻留表达式的时间区间（上例中7天，21天）后，whisper会自动降低采样率（downsamples），默认算法是取平均值，可以通过storage-aggregation.conf定制聚合方式

这个配置文件定义如何在降低采样率（转换为低精度存储时） 如何对数据进行聚合。该文件的格式与storage-schemas.conf类似：

[rulename]
pattern = rexexp
# 0-1之间的浮点数，默认0.5。聚合区间内的值，至少多少比例为非空，聚合后的值才是非空
xFilesFactor = 0.5
# 数据聚合方式，默认average
aggregationMethod = average | sum | min | max | last

同样的，修改此文件不会影响已经生成的.wsp文件， 要应用到既有的.wsp文件，可以调用whisper-set-aggregation-method.py。

这个配置文件指定中继规则——即需要把何种Metrics转发给何种后端。中继由Carbon的中继进程负责执行。该文件格式如下：

[rulename]
pattern = regex
servers = ip:port,ip:port,...

该配置文件定义聚合出来的Metrics——由几个Metrics聚合而成的新的Metrics。聚合由Carbon的聚合进程负责执行。

注意：这里的聚合storage-aggregation.conf提及的聚合不同。后者用于单一Metrics的降低采样，而前者用于生成新的Metrics。

与其它配置文件不同，该文件一旦更改，立即生效。

该文件的格式如下：

# 捕获任何匹配input_pattern的Metrics，使用method聚合成新的Metrics：output_template
# frequency：每隔多久执行一次聚合
# method：可选sum/avg
output_template (frequency) = method input_pattern

举例，假设你的Metrics的命名规则是：

<env>.applications.<app>.<server>.<metric>

这是你可以配置如下聚合规则，来计算所有应用程序的请求的总数：

<env>.applications.<app>.all.requests (60) = sum <env>.applications.<app>.*.requests

在此规则下，下面的Metrics：

test.applications.pems.221.request
test.applications.pems.6.request
test.applications.pems.5.request
test.applications.pems.201.request

会每个60秒求和并生成 

test.applications.pems.all.request

该配置文件定义Metrics名称的改写规则。 与其它配置文件不同，该文件一旦更改，立即生效。该文件的格式如下：

[pre]
# pre段的规则，在接收到数据后立即执行改写
[post]
# post段的规则，在聚合完毕后执行改写
regex-pattern = replacement-text

 举例：

# \1表示第一个捕获，即[a-z0-9]+
^collectd\.([a-z0-9]+)\. = \1.system.
# collectd.prod.cpu-0.idle-time 会被改写为 prod.system.cpu-0.idle-item

Carbon提供黑白名单功能。白名单：仅仅接受其中列出的Metrics；黑名单：拒绝其中列出Metrics。

要启用黑白名单功能，需要修改carbon.conf，设置

USE_WHITELIST = True

如何启动Graphite Webapp依赖于其运行的Web服务软件，以Apache为例：

# CentOS 7
systemctl restart httpd

Carbon组件需要执行下面的命令来启动：

/opt/graphite/bin/carbon-cache.py start

SQLite是一个“文件数据库”，不需要启动。如果Graphite Webapp使用其它数据库，例如MySQL，则需要启动之。 

你可以通过多种方式向Graphite（的Carbon组件）发送Metrics数据点。主要的三种数据格式是：Plaintext、Pickle、AMQP 

这种方式非常简单，你可以用如下格式来发送一条Metrics数据点：

<metric path> <metric value> <metric timestamp>
# 举例：
servers.zircon.cpu 85 1470303923

出于测试目的，你可以直接通过命令向Carbon发送Metrics数据：

PORT=2003
SERVER=127.0.0.1
echo "servers.zircon.cpu 85 `date +%s`" | nc ${SERVER} ${PORT}

Pickle是Python下的对象串行化框架，Pickle协议即它的串行化格式协议。使用该协议，你可以一次发送多个Metrics，并且串行化后的数据比较紧凑，因此Pickle协议性能更好。

下面是构建Pickle报文的示例代码：

listOfMetricTuples = [
    (path, (timestamp, value)),
    ...
]
payload = pickle.dumps(listOfMetricTuples, protocol=2)
header = struct.pack("!L", len(payload))
message = header + payload
# 然后通过Socket把message发送出去即可

import pickle
import socket
import struct
import sys
import time
from time import sleep

import psutil


def get_cpu_load():
    load = psutil.cpu_percent()
    print load
    return load


if __name__ == '__main__':
    CARBON_HOST = '172.16.87.132'
    CARBON_PORT = 2004
    s = socket.socket()
    try:
        s.connect((CARBON_HOST, CARBON_PORT))
        while True:
            data = [
                ('servers.zircon.cpu', (time.time(), get_cpu_load()))
            ]
            pkg = pickle.dumps(data, 1)
            s.sendall(struct.pack('!L', len(pkg)))
            s.sendall(pkg)
            sleep(5)
    except socket.error:
        raise SystemExit("Failed to connect to %(host)s:%(port)" % {'host': CARBON_HOST, 'port': CARBON_PORT})
    except KeyboardInterrupt:
        sys.stderr.write("\nExiting on CTRL-C\n")
        sys.exit(0) 

要从Graphite获取数据用于展示，可以使用Graphite Webapp暴露的Render URL API（RUA）。你可以通过

http://GRAPHITE_HOST:GRAPHITE_PORT/render

访问此API。要向RUA传递参数，可以使用URL请求参数方式：

&name=value

下面列出几个RUA的URL示例：

# Zircon的CPU负载图，获取800x600的图片
http://graphite/render?target=servers.zircon.cpu&height=800&width=600
# 最近12小时，所有服务器的CPU负载平均值
http://graphite/render?target=averageSeries(servers.*.load)&from=-12hours
# 获取原始数据而不是图片，JSON格式
http://graphite/render?target=servers.zircon.cpu&format=json

该参数用来指定从何处获取数据，你可以指定：

1. 单个Metrics路径
2. 带有通配符的的Metrics路径，匹配多个Metrics
3. 函数调用，针对作为入参的Metrics进行各种转换、合并操作

你可以在路径中使用三种风格的通配符：

1. *

    可以匹配0-N个字符，例如

   servers.dev-*.cpu

    ，可以匹配所有开发服务器的CPU负载Metrics。

2. [...]

    可以匹配列表中枚举的单个字符，例如

   servers.dev-[a-z0-9].cpu

    ，可以匹配dev-0、dev-1等服务器的CPU负载Metrics。

3. {...}

    可以匹配列表中枚举的单个字符串，例如

   servers.{dev-0,dev-1}.cpu

    ，匹配dev-0、dev-2的CPU负载Metrics。

注意：所有通配符都不能跨越点号。 

你可以指定target为template函数调用，从而在Metrics路径中使用变量，例如：

# $varname 用来声明变量占位符
# template[varname]参数用来传递变量值
&target=template(servers.$servername.cpu)&template[servername]=zircon

# 可以使用数字代替变量名
&target=template(servers.$1.cpu)&template[1]=zircon

# template可以内嵌其它函数
&target=template(constantLine($number))&template[number]=123

可用的函数较多，这里不一一列举说明，参见官方文档。

这两个可选参数用来指定相对或者绝对的时间区间（time period）。from表示区间起点，如果忽略，默认值是24小时之前；until表示区间终点，如果或略，默认值是当前时间点。

如果要使用相对时间，需要加上

-

你可以指定

HH:MM_YYYYMMDD

YYYYMMDD

 MM/DD/YY

该参数用来指定要获取的数据的格式。 支持以下取值：

<target name>,<start timestamp>,<end timestamp>,<series step>|[data]*

entries,1311836008,1311836013,1|1.0,2.0,3.0,5.0,6.0

entries,2011-07-28 01:53:28,1.0
entries,2011-07-28 01:53:29,2.0
entries,2011-07-28 01:53:30,3.0
entries,2011-07-28 01:53:31,5.0
entries,2011-07-28 01:53:32,6.0

[{
  "target": "entries",
  "datapoints": [
    [1.0, 1311836008],
    [2.0, 1311836009],
    [3.0, 1311836010],
    [5.0, 1311836011],
    [6.0, 1311836012]
  ]
}]

{
  "labels" : [
    "Time",
    "entries"
  ],
  "data" : [
    [1468791890000, 0.0],
    [1468791900000, 0.0]
  ]
}

[{
  "target": "entries",
  "datapoints": [{
    "y": 0.0,
    "x": 1468791890
  }, {
    "y": 0.0,
    "x": 1468791900
  }]
}]

[
  {
    'name' : 'summarize(test.data, "30min", "sum")',
    'start': 1335398400,
    'end'  : 1335425400,
    'step' : 1800,
    'values' : [None, None, 1.0, None],
  }
]

你可以指定多个参数，来控制生成的图形的样式：

# 颜色名称
&bgcolor=blue
# HEX代码
&bgcolor=2222FF
# HEX代码，包含透明度
&bgcolor=5522FF60

上一章内容我们讨论了如何获取Graphite数据。通过Render URL API，我们不但可以获得文本数据，还可以直接获得渲染好的图片。这意味着通过Render URL API本身就可以实现Metrics的渲染，你只需要把生成的图片嵌入到自己的应用程序中即可。

Graphite Webapp本身提供了基于ExtJS的一个管理界面，你可以通过

http://GRAPHITE_HOST:GRAPHITE_PORT/admin

Graphite生成的Metrics曲线的图片，不是非常美观，而静态图片也缺乏交互性。因此，实际项目中常常结合使用第三方基于JavaScript的Charts库来做展示，例如：

1. Grafana：UI比较绚丽，支持设计仪表盘、时间区间联动。参见：使用Grafana展示时间序列数据
2. Graphene：一个较为简单的，基于D3.js和Backbone.js的Graphite仪表盘工具

除了简单的，基于Key/Value的Metrics数据，Graphite还可以存储、展示随机出现的数据——事件。

事件不适合存储在Whisper中，因此它被存储在Graphite的Webapp的数据库中（默认使用SQLite）。

通过向

http://GRAPHITE_HOST:GRAPHITE_PORT/events/

{ 
    "what": "事件类型", 
    "tags": "标签",
    "data": "事件相关的数据" 
}

指定target为

event(*tags)

/render

[
   {
      "target" : "events(mytag)",
      "datapoints" : [
         [
            1,
            1388966651
         ],
         [
            3,
            1388966652
         ]
      ]
   }
]

你也可以通过

/render/events/get_data

[
   {
      "when" : 1392046352,
      "tags" : "mytag",
      "data" : "...",
      "id" : 2,
      "what" : "Event - deploy"
   }
] 

Django的request对象曾经有一个属性REQUEST，用来获得通过GET或者POST请求传递的请求参数，在1.9版本中此属性已经移除。

Graphite代码没有即时更新，存在不兼容的问题，修改一下即可：

def parseOptions(request):
   queryParams = request.GET # request.REQUEST已经被移除

还有很多其它views.py存在同样的问题，最好搜索一下一并修改。如果觉得麻烦可以安装兼容版本的Django：

pip install django==1.8.14

The post Graphite学习笔记 appeared first on 绿色记忆.