市面上最流行的商用和开源的指标监控和告警服务有
DATADOG、influxdb、New Relic、Nagios、Prometheus、Grafana 等。
可以获知后端系统的健康程度，还可以帮助发现趋势和问题。
收集操作系统的运行指标，可以是低级别的数据如 CPU负载、内存使用率、磁盘空间， 也可以是高级别数据 聚合或汇总数据 如每秒请求数或Web服务器池里的服务器数量。
支持告警渠道 邮件、电话、PagerDuty、Webhook。
可以监控仪系列指标，不限于 CPU 使用率、请求数量、内存使用率、异常数量、消息队列里的消息数量。
系统应该是可扩展的，以便容纳更多的指标、告警等。系统应高度可靠避免错失关键告警。
值班开发者应该可以快速接收到告警，从而及时开展调查。
指标监控和告警系统通常包含5个组成部分：
指标数据通常以时间序列的格式记录，数据随着时间的变化
指标名、时间戳、值、标签
数据存在关系型数据库中，会遇到各种挑战如写性能、可扩展性方面问题，它们并没有针对典型的时间序列工作负载（随时间变化的数据）做优化。
有几个非关系型数据库可以高效处理时间序列数据，OpenTSDB
是一个分布式时间序列数据库，但它是基于 Hadoop 和 HBase 的，运行
Hadoop/HBase 集群会增加复杂性 。 Bigtable 也可以用于处理
时间序列数据。Twitter 使用MetricsDB，而亚马逊提供了 Timestream
作为时间序列数据库。
两个最流行的时间序列数据库是 InfluxDB 和 Prometheus。
展示了高层级的设计示意图
指标来源，可以是应用服务器、SQL 数据库、消息队列 等。
有两种收集指标的数据，拉或推。
推模型缺点，可能会给指标收集器带来巨大流量成为瓶颈，解决方案之一是在应用服务器 如 Web 服务器、数据库服务器 等上安装代理，代理是运行在应用服务器上的软件。它从应用服务器上收集各种指标数据并进行处理，然后把它们推送给指标收集器。如果推送的流量大，代理就会进行调整以避免指标收集器被压垮。
所以在 指标收集器 与 时间序列数据库 之间加 Kafka和消费者。指标收集器将指标数据发送给队列系统，比如Kafka，然后消费者或者流处理服务如 Apache Storm、Flink、Spark 处理数据并将其推送给时间序列数据库。
Kafka可以用作高可靠和可扩展的分布式消息平台，它解耦了数据收集和数据处理服务，当数据库不可用时，将数据保留在Kafka中，能容易地避免数据丢失，不会给指标收集器施压。
利用 Kafka 内置的分区机制，基于吞吐量的需求配置分区数量，按指标名字分区以便消费者按名字来聚合，可以进一步按标签来分区。
查询服务由查询服务器集群提供，它们访问时间序列数据库，并处理来自可视化系统或告警系统的请求。
查询服务器把时间序列数据库与客户端（可视化和告警系统）解耦。以便可以容易更换时间序列数据库和告警系统。
大部分流行的指标监控系统如 Prometheus 和 InfluxDB 不使用SQL，而是创建了自有的查询语言。
在对运营数据存储的查询中，很多都是差最近一天内的数据，如果 缓存最近的时间序列数据，可以显著提升插入和查询速度。
为了确保查询服务提供低延时的查询且减少要存储的数据量，允许工程师或数据科学家按特定的粒度（1秒、10秒、1分钟、1小时等）来灵活聚合和存储时间序列数据。
空间优化：
告警系统如下图所示
告警管理器 负责规则过滤、合并、删除重复告警，访问控制，重试保证检查告警状态并确保至少发送了一次通知
告警存储是键值数据库，保存所有告警的状态机，确保至少发送一次通知，合格的告警被插入Kafka，告警消费者从Kafka中拉取告警时间，告警消费者处理Kafka中的告警事件，并将通知发送到不同的接收端 如 邮件、短信 等。
可视化系统建立在数据层之上，可以基于不同的时间范围将指标展示在指标仪表板上，而将告警展示在告警仪表板上。
仪表板上列出 服务器请求、内存、CPU使用率、页面加载时间、网络流量、登录信息等指标。