随着分布式架构、容器云在生产系统的广泛应用，传统监控工具如nagios、zbbix等监控工具在k8s、pod环境等复杂多变的服务环境下并不理想，prometheus的出现成为了云原生架构下的主流监控工具。
Prometheus是一个由SoundClould于2012年开始编写，2015年在Github上开源的基于时间序列的监控组件。2016年prometheus成为继Kubernetes之后，第二个CNCF（云原生计算基金会）的成员。Prometheus以其数据模型多维、查询语句灵活、无依赖存储、支持local/remote不同模型、告警收敛好等特点广受欢迎。以下是一个Prometheus监控体系架构图：
引用自Prometheus官网https://prometheus.io/docs/introduction/overview/
通常情况下，监控系统的搭建会根据业务场景与生产环境的需要而选择性的使用或拓展上述组件。一个基于prometheus的相关组件的监控系统的核心组成部分可分为监控目标、数据采集、数据存储/查询、监控告警。
监 / 控 / 目 / 标
Monitoring Target
监控目标是监控系统要监控的目标对象，一般可分为基础设施、基础服务、应用系统，针对不同监控对象采集不同监控指标。
-
基础设施：基础设施的监控指标包括cpu、网络、磁盘等目标对象的相关性能，例如cpu使用率、网络出入包、磁盘速率、内存占用率、文件描述符使用率等；
-
基础服务：基础服务的监控指标包括针对redis、mysql等服务的连接、回滚等数据，例如redis命中率、redis连接客户端数量、mysql当前活跃连接数、mysql事务回滚次数等；
-
应用系统：监控指标可根据应用系统需要监控的特性开发。
prometheus可以通过静态配置或服务发现来配置target。由于在容器云场景下的监控对象都在动态的变化之中，所以部署注册中心（例如：consul）来掌握所有服务的注册信息，prometheus通过访问注册中心即通过服务发现的模式获取监控目标信息。
数 / 据 / 采 / 集
Data Collection
数据采集的方式通常分为pull和push两种。Exporter作为数据采集器通过HTTP的方式收集监控目标的监控数据，并且使之可以被prometheus拉取到，其每个监控指标对应数据格式如下：
有一些监控指标prometheus无法直接通过pull的方式获取，Pushgateway就用来解决这个问题。值得注意的是，此时数据采集方式是由脚本push到pushgateway，但prometheus依旧使用pull的方式从pushgateway获取指标数据。
数 / 据 / 存储 / 查询
Data Store&Query
Prometheus将监控指标数据以时序数据（时序数据是由指标名称以及一组标签键值对唯一标识），以时间维度存储的连续数据）格式存在TSDB数据库，然后提供API接口以便通过promql语言进行聚合、查询。用户可以搭配grafana对查询结果进行可视化处理。
在这一部分prometheus有一个痛点，它只支持单机部署且不支持高可用及水平扩容，由于单机下性能和存储能力有限，容易发生单点故障。thanos可以统一查询聚合分布式部署的prometheus，所以一般通过部署thanos来解决这个问题，同时thanos也支持将数据长期存储到存储对象。
告 / 警 / 处 / 理
Alarm Process
Prometheus负责告警规则计算，到达阈值时触发告警，将告警信息推送到alertmanage，由alertmanage进行告警通知。
告警规则通过配置如下rule.yml文件进行告警名、告警表达式、告警级别和告警描述等参数的设置。
prometheus相对于例如zabbix等传统监控工具在容器与云原生环境下有其天然优势，被称为“下一代监控系统”。与此同时，在全球智能化的浪潮中，未来监控工具的发展也许也会更加简洁、智能。
