芯片复制监控作为底层基础设施的一环，是保障生产环境服务稳定性不可或缺的一部分，线上问题从发现到定位再到解决，通过监控和告警手段可以有效地覆盖了「发现」和「定位」，甚至可以通过故障自愈等手段实现解决，服务开发和运维人员能及时有效地发现服务运行的异常，从而更有效率地排查和解决问题。一个典型的监控（如白盒监控），通常会关注于目标服务的内部状态，例如：

• 单位时间接收到的请求数量
• 单位时间内请求的成功率/失败率
• 请求的平均处理耗时

芯片复制白盒监控很好地描述了系统的内部状态，但缺少从外部角度看到的现象，比如：白盒监控只能看到已经接收的请求，并不能看到由于 DNS 故障导致没有发送成功的请求，而黑盒监控此时便可以作为补充手段，由探针（probe）程序来探测目标服务是否成功返回，更好地反馈系统的当前状态。某日需要为服务搭建一个监控系统来采集应用埋点上报的指标，经过一番对比，最终选择了 Prometheus 来作为我们的业务监控，因为它具有以下优点：

• 支持 PromQL（一种查询语言），可以灵活地聚合指标数据

  
  

• 部署简单，只需要一个二进制文件就能跑起来，不需要依赖分布式存储

  
  

• Go 语言编写，组件更方便集成在同样是Go编写项目代码中

  
  

• 原生自带 WebUI，通过 PromQL 渲染时间序列到面板上

  
  

• 生态组件众多，Alertmanager，Pushgateway，Exporter……

  
  

Prometheus 的架构图如下：

在上面流程中，芯片复制Prometheus 通过配置文件中指定的服务发现方式来确定要拉取监控指标的目标（Target），接着从要拉取的目标（应用容器和Pushgateway）发起HTTP请求到特定的端点（Metric Path），将指标持久化至本身的TSDB中，TSDB最终会把内存中的时间序列压缩落到硬盘，除此之外，Prometheus 会定期通过 PromQL 计算设置好的告警规则，决定是否生成告警到 Alertmanager，后者接收到告警后会负责把通知发送到邮件或企业内部群聊中。Prometheus 的指标名称只能由 ASCII 字符、数字、下划线以及冒号组成，而且有一套命名规范：

• 使用基础 Unit（如 seconds 而非 milliseconds）

  
  

• 指标名以 application namespace 作为前缀，如：

  
  

• process_cpu_seconds_total

  
  

• http_request_duration_seconds

  
  

• 用后缀来描述 Unit，如：

  
  

• http_request_duration_seconds

  
  

• node_memory_usage_bytes

  
  

• http_requests_total

  
  

• process_cpu_seconds_total

  
  

• foobar_build_info

  
  

Prometheus 提供了以下基本的指标类型：

• Counter：代表一种样本数据单调递增的指标，即只增不减，通常用来统计如服务的请求数，错误数等。

  
  

• Gauge：代表一种样本数据可以任意变化的指标，即可增可减，通常用来统计如服务的CPU使用值，内存占用值等。

  
  

• Histogram 和 Summary：用于表示一段时间内的数据采样和点分位图统计结果，通常用来统计请求耗时或响应大小等。