隨著分布式架構(gòu)逐漸成為了架構(gòu)設(shè)計(jì)的主流，可觀測(cè)性（Observability）一詞也日益被人頻繁地提起。

2017 年的分布式追蹤峰會(huì)（2017 Distributed Tracing Summit）結(jié)束后，Peter Bourgon 撰寫(xiě)了總結(jié)文章《Metrics, Tracing, and Logging》系統(tǒng)地闡述了這三者的定義、特征，以及它們之間的關(guān)系與差異。文中將可觀測(cè)性問(wèn)題映射到了如何處理指標(biāo)（metrics）、追蹤（tracing）、日志（logging）三類(lèi)數(shù)據(jù)上。

其后，Cindy Sridharan 在其著作《Distributed Systems Observability》中，進(jìn)一步講到指標(biāo)、追蹤、日志是可觀測(cè)性的三大支柱（three pillars）。

到了 2018 年， CNCF Landscape 率先出現(xiàn)了 Observability 的概念，將可觀測(cè)性（ Observability ）從控制論（ Cybernetics ）中引入到 IT 領(lǐng)域。在控制論中，可觀測(cè)性是指系統(tǒng)可以由其外部輸出，來(lái)推斷其內(nèi)部狀態(tài)的程度，系統(tǒng)的可觀察性越強(qiáng)，我們對(duì)系統(tǒng)的可控制性就越強(qiáng)。

可觀測(cè)性可以解決什么問(wèn)題？Google SRE Book 第十二章給出了簡(jiǎn)潔明快的答案：快速排障。

There are many ways to simplify and speed troubleshooting. Perhaps the most fundamental are:

• Building observability—with both white-box metrics and structured logs—into each component from the ground up
• Designing systems with well-understood and observable interfaces between components.

Google SRE Book, Chapter 12

而在云原生時(shí)代，分布式系統(tǒng)越來(lái)越復(fù)雜，分布式系統(tǒng)的變更是非常頻繁的，每次變更都可能導(dǎo)致新類(lèi)型的故障。應(yīng)用上線(xiàn)之后，如果缺少有效的監(jiān)控，很可能導(dǎo)致遇到問(wèn)題我們自己都不知道，需要依靠用戶(hù)反饋才知道應(yīng)用出了問(wèn)題。

本文主要講述如何建立應(yīng)用業(yè)務(wù)指標(biāo)Metrics監(jiān)控和如何實(shí)現(xiàn)精準(zhǔn)告警。Metrics 可以翻譯為度量或者指標(biāo)，指的是對(duì)于一些關(guān)鍵信息以可聚合的、數(shù)值的形式做定期統(tǒng)計(jì)，并繪制出各種趨勢(shì)圖表。透過(guò)它，我們可以觀察系統(tǒng)的狀態(tài)與趨勢(shì)。

技術(shù)棧選擇

我們的應(yīng)用都是 Spring Boot 應(yīng)用，并且使用 Spring Boot Actuator 實(shí)現(xiàn)應(yīng)用的健康檢查。從 Spring Boot 2.0 開(kāi)始，Actuator 將底層改為 Micrometer，提供了更強(qiáng)、更靈活的監(jiān)測(cè)能力。Micrometer 支持對(duì)接各種監(jiān)控系統(tǒng)，包括 Prometheus。

所以我們選擇 Micrometer 收集業(yè)務(wù)指標(biāo)，Prometheus 進(jìn)行指標(biāo)的存儲(chǔ)和查詢(xún)，通過(guò) Grafana 進(jìn)行展示，通過(guò)阿里云的告警中心實(shí)現(xiàn)精準(zhǔn)告警。

指標(biāo)收集

對(duì)于整個(gè)研發(fā)部門(mén)來(lái)說(shuō)，應(yīng)該聚焦在能夠?qū)崟r(shí)體現(xiàn)公司業(yè)務(wù)狀態(tài)的最核心的指標(biāo)上。例如 Amazon 和 eBay 會(huì)跟蹤銷(xiāo)售量， Google 和 Facebook 會(huì)跟蹤廣告曝光次數(shù)等與收入直接相關(guān)的實(shí)時(shí)指標(biāo)。

Prometheus 默認(rèn)采用一種名為 OpenMetrics 的指標(biāo)協(xié)議。OpenMetrics 是一種基于文本的格式。下面是一個(gè)基于 OpenMetrics 格式的指標(biāo)表示格式樣例。

# HELP http_requests_total The total number of HTTP requests.
# TYPE http_requests_total counter
http_requests_total{method="post",code="200"} 1027
http_requests_total{method="post",code="400"}    3

# Escaping in label values:
msdos_file_access_time_seconds{path="C:\\DIR\\FILE.TXT",error="Cannot find file:\n\"FILE.TXT\""} 1.458255915e9

# Minimalistic line:
metric_without_timestamp_and_labels 12.47

# A weird metric from before the epoch:
something_weird{problem="division by zero"} +Inf -3982045

# A histogram, which has a pretty complex representation in the text format:
# HELP http_request_duration_seconds A histogram of the request duration.
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.05"} 24054
http_request_duration_seconds_bucket{le="0.1"} 33444
http_request_duration_seconds_bucket{le="0.2"} 100392
http_request_duration_seconds_bucket{le="0.5"} 129389
http_request_duration_seconds_bucket{le="1"} 133988
http_request_duration_seconds_bucket{le="+Inf"} 144320
http_request_duration_seconds_sum 53423
http_request_duration_seconds_count 144320

# Finally a summary, which has a complex representation, too:
# HELP rpc_duration_seconds A summary of the RPC duration in seconds.
# TYPE rpc_duration_seconds summary
rpc_duration_seconds{quantile="0.01"} 3102
rpc_duration_seconds{quantile="0.05"} 3272
rpc_duration_seconds{quantile="0.5"} 4773
rpc_duration_seconds{quantile="0.9"} 9001
rpc_duration_seconds{quantile="0.99"} 76656
rpc_duration_seconds_sum 1.7560473e+07
rpc_duration_seconds_count 2693

指標(biāo)的數(shù)據(jù)由指標(biāo)名(metric_name)，一組 key/value 標(biāo)簽（label_name=label_value)，數(shù)字類(lèi)型的指標(biāo)值(value)，時(shí)間戳組成。

metric_name [
  "{" label_name "=" `"` label_value `"` { "," label_name "=" `"` label_value `"` } [ "," ] "}"
] value [ timestamp ]

Meter

Micrometer 提供了多種度量類(lèi)庫(kù)(Meter)，Meter 是指一組用于收集應(yīng)用中的度量數(shù)據(jù)的接口。Micrometer 中，Meter 的具體類(lèi)型包括：Timer, Counter, Gauge, DistributionSummary, LongTaskTimer, FunctionCounter, FunctionTimer, and TimeGauge

• Counter 用來(lái)描述一個(gè)單調(diào)遞增的變量，如某個(gè)方法的調(diào)用次數(shù)，緩存命中/訪(fǎng)問(wèn)總次數(shù)等。支持配置 recordFailuresOnly，即只記錄方法調(diào)用失敗的次數(shù)。Counter 的指標(biāo)數(shù)據(jù)，默認(rèn)有四個(gè) label：class, method, exception, result。
• Timer 會(huì)同時(shí)記錄 totalcount, sumtime, maxtime 三種數(shù)據(jù)，有一個(gè)默認(rèn)的 label: exception。
• Gauge 用來(lái)描述在一個(gè)范圍內(nèi)持續(xù)波動(dòng)的變量。Gauge 通常用于變動(dòng)的測(cè)量值，比如隊(duì)列中的消息數(shù)量，線(xiàn)程池任務(wù)隊(duì)列數(shù)等。
• DistributionSummary 用于統(tǒng)計(jì)數(shù)據(jù)分布。

應(yīng)用接入流程

為了方便微服務(wù)應(yīng)用接入，我們封裝了
micrometer-spring-boot-starter。micrometer-spring-boot-starter 的具體實(shí)現(xiàn)如下。

1.入 Spring Boot Actuator 依賴(lài)

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

<dependency>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-registry-prometheus</artifactId>
  <version>${micrometer.version}</version>
</dependency>

進(jìn)行初始配置

Actuator 默認(rèn)開(kāi)啟了一些指標(biāo)的收集，比如 system, jvm, http，可以通過(guò)配置關(guān)閉它們。其實(shí)僅僅是我們需要關(guān)閉，因?yàn)槲覀円呀?jīng)接了 jmx exporter 了。

management.metrics.enable.jvm=false
management.metrics.enable.process=false
management.metrics.enable.system=false

如果不希望 Web 應(yīng)用的 Actuator 管理端口和應(yīng)用端口重合的話(huà)，可以使用 management.server.port 設(shè)置獨(dú)立的端口。這是好的實(shí)踐，可以看到針對(duì) actuator 的破壞，但是換了端口號(hào)，不暴露公網(wǎng)問(wèn)題會(huì)少很多。

1management.server.port=xxxx

配置 spring bean

TimedAspect 的 Tags.empty() 是故意的，防止產(chǎn)生太長(zhǎng)的 class 名稱(chēng)對(duì) prometheus 造成壓力。

@PropertySource(value = {"classpath:/micrometer.properties"})
@Configuration
public class MetricsConfig {

    @Bean
    public TimedAspect timedAspect(MeterRegistry registry){
        return new TimedAspect(registry, (pjp) -> Tags.empty());
    }

    @Bean
    public CountedAspect countedAspect(MeterRegistry registry){
        return new CountedAspect(registry);
    }

    @Bean
    public PrometheusMetricScrapeEndpoint prometheusMetricScrapeEndpoint(CollectorRegistry collectorRegistry){
        return new PrometheusMetricScrapeEndpoint(collectorRegistry);
    }

    @Bean
    public PrometheusMetricScrapeMvcEndpoint prometheusMvcEndpoint(PrometheusMetricScrapeEndpoint delegate){
        return new PrometheusMetricScrapeMvcEndpoint(delegate);
    }

}

應(yīng)用接入時(shí)，引入
micrometer-spring-boot-starter 依賴(lài)

<dependency>
  <groupId>xxx</groupId>
  <artifactId>micrometer-spring-boot-starter</artifactId>
</dependency>

現(xiàn)在，就可以通過(guò)訪(fǎng)問(wèn)
http://ip:port/actuator/prometheus，來(lái)查看 Micrometer 記錄的數(shù)據(jù)。

自定義業(yè)務(wù)指標(biāo)

Micrometer 內(nèi)置了 Counted 和 Timed 兩個(gè) annotation?？梢酝ㄟ^(guò)在對(duì)應(yīng)的方法上加上 @Timed 和 @Counted 注解，來(lái)收集方法的調(diào)用次數(shù)，時(shí)間和是否發(fā)生異常等信息。

@Timed

如果想要記錄打印方法的調(diào)用次數(shù)和時(shí)間，需要給 print 方法加上 @Timed 注解，并給指標(biāo)定義一個(gè)名稱(chēng)。

@Timed(value = "biz.print", percentiles = {0.95, 0.99}, description = "metrics of print")
public String print(PrintData printData) {

}

在 print 方法上加上 @Timed 注解之后，Micrometer 會(huì)記錄 print 方法的調(diào)用次數(shù)(count)，方法調(diào)用最大耗時(shí)(max)，方法調(diào)用總耗時(shí)(sum)三個(gè)指標(biāo)。percentiles = {0.95, 0.99} 表示計(jì)算 p95，p99 的請(qǐng)求時(shí)間。記錄的指標(biāo)數(shù)據(jù)如下。

biz_print_seconds_count{exception="none"} 4.0
biz_print_seconds_sum{exception="none"} 7.783213927
biz_print_seconds_max{exception="none"} 6.14639717
biz_print_seconds{exception="NullPointerException"} 0.318767104
biz_print_seconds{exception="none",quantile="0.95",} 0.58720256
biz_print_seconds{exception="none",quantile="0.99",} 6.157238272

@Timed 注解支持配置一些屬性：

• value：必填，指標(biāo)名
• extraTags：給指標(biāo)定義標(biāo)簽，支持多個(gè)，格式 {"key", "value", "key", "value"}
• percentiles：小于等于 1 的數(shù)，計(jì)算時(shí)間的百分比分布，比如 p95，p99
• histogram：記錄方法耗時(shí)的 histogram 直方圖類(lèi)型指標(biāo)

@Timed 會(huì)記錄方法拋出的異常。不同的異常會(huì)被記錄為獨(dú)立的數(shù)據(jù)。代碼邏輯是先 catch 方法拋出的異常，記錄下異常名稱(chēng)，然后再拋出方法本身的異常：

try {
    return pjp.proceed();
} catch (Exception ex) {
    exceptionClass = ex.getClass().getSimpleName();
    throw ex;
} finally {
    try {
        sample.stop(Timer.builder(metricName)
                    .description(timed.description().isEmpty() ? null : timed.description())
                    .tags(timed.extraTags())
                    .tags(EXCEPTION_TAG, exceptionClass)
                    .tags(tagsBasedOnJoinPoint.apply(pjp))
                    .publishPercentileHistogram(timed.histogram())
                    .publishPercentiles(timed.percentiles().length == 0 ? null : timed.percentiles())
                    .register(registry));
    } catch (Exception e) {
        // ignoring on purpose
    }
}

@Counted

如果不關(guān)心方法執(zhí)行的時(shí)間，只關(guān)心方法調(diào)用的次數(shù)，甚至只關(guān)心方法調(diào)用發(fā)生異常的次數(shù)，使用 @Counted 注解是更好的選擇。recordFailuresOnly = true 表示只記錄異常的方法調(diào)用次數(shù)。

@Timed(value = "biz.print", recordFailuresOnly = true, description = "metrics of print")
public String print(PrintData printData) {

}

記錄的指標(biāo)數(shù)據(jù)如下。

biz_print_failure_total{class="com.xxx.print.service.impl.PrintServiceImpl",exception="NullPointerException",method="print",result="failure",} 4.0

counter 是一個(gè)遞增的數(shù)值，每次方法調(diào)用后，會(huì)自增 1。

private void record(ProceedingJoinPoint pjp, Counted counted, String exception, String result){
    counter(pjp, counted)
            .tag(EXCEPTION_TAG, exception)
            .tag(RESULT_TAG, result)
            .register(meterRegistry)
            .increment();
}

private Counter.Builder counter(ProceedingJoinPoint pjp, Counted counted){
    Counter.Builder builder = Counter.builder(counted.value()).tags(tagsBasedOnJoinPoint.apply(pjp));
    String description = counted.description();
    if (!description.isEmpty()) {
        builder.description(description);
    }
    return builder;
}

Gauge

Gauge 用來(lái)描述在一個(gè)范圍內(nèi)持續(xù)波動(dòng)的變量。Gauge 通常用于變動(dòng)的測(cè)量值，例如雪花算法的 workId，打印的模板 id，線(xiàn)程池任務(wù)隊(duì)列數(shù)等。

1. 注入 PrometheusMeterRegistry
2. 構(gòu)造 Gauge。給指標(biāo)命名并賦值。

@Autowired
private PrometheusMeterRegistry meterRegistry;

public void buildGauge(Long workId) {
    Gauge.builder("biz.alphard.snowFlakeIdGenerator.workId", workId, Long::longValue)
            .description("alphard snowFlakeIdGenerator workId")
            .tag("workId", workId.toString())
            .register(meterRegistry).measure();
}

記錄的指標(biāo)數(shù)據(jù)如下。

biz_alphard_snowFlakeIdGenerator_workId{workId="2"} 2

配置 SLA 指標(biāo)

如果想要記錄指標(biāo)時(shí)間數(shù)據(jù)的 sla 分布，Micrometer 提供了對(duì)應(yīng)的配置：

management.metrics.distribution.sla[biz.print]=300ms,400ms,500ms,1s,10s

記錄的指標(biāo)數(shù)據(jù)如下。

biz_print_seconds_bucket{exception="none",le="0.3",} 1.0
biz_print_seconds_bucket{exception="none",le="0.4",} 3.0
biz_print_seconds_bucket{exception="none",le="0.5",} 10.0
biz_print_seconds_bucket{exception="none",le="0.6",} 11.0
biz_print_seconds_bucket{exception="none",le="1.0",} 11.0
biz_print_seconds_bucket{exception="none",le="10.0",} 12.0
biz_print_seconds_bucket{exception="none",le="+Inf",} 12.0

存儲(chǔ)查詢(xún)

我們使用 Prometheus 進(jìn)行指標(biāo)數(shù)據(jù)的存儲(chǔ)和查詢(xún)。Prometheus 采用拉取式采集（Pull-Based Metrics Collection）。Pull 就是 Prometheus 主動(dòng)從目標(biāo)系統(tǒng)中拉取指標(biāo)，相對(duì)地，Push 就是由目標(biāo)系統(tǒng)主動(dòng)推送指標(biāo)。Prometheus 官方解釋選擇 Pull 的原因。

Pulling over HTTP offers a number of advantages:

• You can run your monitoring on your laptop when developing changes.
• You can more easily tell if a target is down.
• You can manually go to a target and inspect its health with a web browser.
  Overall, we believe that pulling is slightly better than pushing, but it should not be considered a major point when considering a monitoring system.

Prometheus 也支持 Push 的采集方式，就是 Pushgateway。

For cases where you must push, we offer the Pushgateway.

為了讓 Prometheus 采集應(yīng)用的指標(biāo)數(shù)據(jù)，我們需要做兩件事：

應(yīng)用通過(guò) service 暴露出 actuator 端口，并添加 label: monitor/metrics

apiVersion: v1
kind: Service
metadata:
  name: print-svc
  labels:
    monitor/metrics: ""
spec:
  ports:
  - name: custom-metrics
    port: xxxx
    targetPort: xxxx
    protocol: TCP
  type: ClusterIP
  selector:
    app: print-test

添加 ServiceMonitor

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: metrics
  labels:
    app: metric-monitor
spec:
  namespaceSelector:
    any: true
  endpoints:
  - interval: 15s
    port: custom-metrics
    path: "/manage/prometheusMetric"
  selector:
    matchLabels:
      monitor/metrics: ""

Prometheus 會(huì)定時(shí)訪(fǎng)問(wèn) service 的 endpoints (
http://podip:port/manage/prometheusMetric)，拉取應(yīng)用的 metrics，保存到自己的時(shí)序數(shù)據(jù)庫(kù)。

Prometheus 存儲(chǔ)的數(shù)據(jù)是文本格式，雖然 Prometheus 也有 Graph，但是不夠炫酷，而且功能有限。還需要有一些可視化工具去展示數(shù)據(jù)，通過(guò)標(biāo)準(zhǔn)易用的可視化大盤(pán)去獲知當(dāng)前系統(tǒng)的運(yùn)行狀態(tài)。比較常見(jiàn)的解決方案就是 Grafana。Prometheus 內(nèi)置了強(qiáng)大的時(shí)序數(shù)據(jù)庫(kù)，并提供了 PromQL 的數(shù)據(jù)查詢(xún)語(yǔ)言，能對(duì)時(shí)序數(shù)據(jù)進(jìn)行豐富的查詢(xún)、聚合以及邏輯運(yùn)算。通過(guò)在 Grafana 配置 Prometheus 數(shù)據(jù)源和 PromQL，讓 Grafana 去查詢(xún) Prometheus 的指標(biāo)數(shù)據(jù)，以圖表的形式展示出來(lái)。

1. grafana 配置 Prometheus 數(shù)據(jù)源

2. 添加看板，配置數(shù)據(jù)源，query 語(yǔ)句，圖表樣式

3. 可以在一個(gè) dasborad 添加多個(gè)看板，構(gòu)成監(jiān)控大盤(pán)。

精準(zhǔn)告警

任何系統(tǒng)都不是完美的，當(dāng)出現(xiàn)異常和故障時(shí)，能在第一時(shí)間發(fā)現(xiàn)問(wèn)題且快速定位問(wèn)題原因就尤為重要。但要想做到以上這兩點(diǎn)，只有數(shù)據(jù)收集是不夠的，需要依賴(lài)完善的監(jiān)控和告警體系，迅速反應(yīng)并發(fā)出告警。

我們最初的方案是，基于 Prometheus operator 的 PrometheusRule 創(chuàng)建告警規(guī)則， Prometheus servers 把告警發(fā)送給 Alertmanager，Alertmanager 負(fù)責(zé)把告警發(fā)到釘釘群機(jī)器人。但是這樣運(yùn)行一段時(shí)間之后，我們發(fā)現(xiàn)這種方式存在一些問(wèn)題。SRE 團(tuán)隊(duì)和研發(fā)團(tuán)隊(duì)負(fù)責(zé)人收到的告警太多，所有的告警都發(fā)到一個(gè)群里，打開(kāi)群消息，滿(mǎn)屏的告警標(biāo)題，告警級(jí)別，告警值。其中有需要運(yùn)維處理的系統(tǒng)告警，有需要研發(fā)處理的應(yīng)用告警，信息太多，很難快速篩選出高優(yōu)先級(jí)的告警，很難快速轉(zhuǎn)派告警到對(duì)應(yīng)的處理人。所以我們希望應(yīng)用告警可以精準(zhǔn)發(fā)送到應(yīng)用歸屬的研發(fā)團(tuán)隊(duì)。

經(jīng)過(guò)一段時(shí)間的調(diào)研，我們最終選擇阿里云的《ARMS 告警運(yùn)維中心》來(lái)負(fù)責(zé)告警的管理。ARMS 告警運(yùn)維中心支持接入 Prometheus 數(shù)據(jù)源，支持添加釘釘群機(jī)器人作為聯(lián)系人。

1. 收集研發(fā)團(tuán)隊(duì)的釘釘群機(jī)器人的 webhook 地址，創(chuàng)建機(jī)器人作為聯(lián)系人。

2. 給每個(gè)研發(fā)團(tuán)隊(duì)分別配置通知策略，通知策略篩選告警信息里的 team 字段，并綁定對(duì)應(yīng)的釘釘群機(jī)器人聯(lián)系人。

通過(guò)這個(gè)方式，實(shí)現(xiàn)了應(yīng)用的告警直接發(fā)送到對(duì)應(yīng)的研發(fā)團(tuán)隊(duì)，節(jié)省了信息篩選和二次轉(zhuǎn)派的時(shí)間，提高了告警處理效率。

效果如下：

ARMS 告警運(yùn)維中心支持接入 grafana，zabbix，arms 等多種數(shù)據(jù)源，具有告警分派和認(rèn)領(lǐng)，告警匯總?cè)ブ?，通過(guò)升級(jí)通知方式對(duì)長(zhǎng)時(shí)間沒(méi)有處理的告警進(jìn)行多次提醒，或升級(jí)通知到領(lǐng)導(dǎo)，保證告警及時(shí)解決。

作者簡(jiǎn)介：

趙君｜南京愛(ài)福路汽車(chē)科技有限公司基礎(chǔ)設(shè)施部云原生工程師，過(guò)去一直從事 java 相關(guān)的架構(gòu)和研發(fā)工作。目前主要負(fù)責(zé)公司的云原生落地相關(guān)工作，負(fù)責(zé) F6 基礎(chǔ)設(shè)施和業(yè)務(wù)核心應(yīng)用全面上云和云原生化改造。

徐航｜南京愛(ài)福路汽車(chē)科技有限公司基礎(chǔ)設(shè)施部云原生工程師，過(guò)去一直負(fù)責(zé)數(shù)據(jù)庫(kù)高可用以及相關(guān)運(yùn)維和調(diào)優(yōu)工作。目前主要負(fù)責(zé)研發(fā)效能 DevOps 的落地以及業(yè)務(wù)系統(tǒng)云原生可觀測(cè)性的改造。