随着应用架构往容器化、微服务化方向发展，传统监控技术已经不能满足云原生时代运维的需求，因此，可观察性的理念被各个团队重视起来。
站酷的监控告警，经历了蛮荒发展的过程，先后推出了blackbox、Grafana、Prometheus、Skywalking、sentry等等工具、平台。大家在使用过程中，或多或少出现了疑问：我们真的需要这这么多监控么？为什么这么多监控监控不到我的痛点？未来我们是否只需要部分监控告警？
一、可观测性
可观察性的三大支柱及其之间的关系，Peter Bourgon 在2017年2月撰写了一篇简明扼要的文章， 叫 "Metrics, tracing, and logging" [3]
详细阐明了可观测性三大支柱：
维恩图的方式展现三者关系时，会正巧展现出一个附加效应。在这三个功能域中，metric倾向于更节省资源，因为他会“天然的”压缩数据。相反，日志倾向于无限增加的，会频繁的超出预期的容量。容量的需求趋势：metrics低到logging高， 而trace可能处于他们两的中间位置
1. 指标数据（Metrics Data）
特点是可累加的：他们具有原子性，每个都是一个逻辑计量单元，或者一个时间段内的柱状图。例如：队列的当前深度可以被定义为一个计量单元，在写入或读取时被更新统计；
输入HTTP请求的数量可以被定义为一个计数器，用于简单累加； 请求的执行时间可以被定义为一个柱状图，在指定时间片上更新和统计汇总。
描述具体某个对象某个时间点的值。在 Prometheus 中，指标有四种类型，分别 Counter（计数器）、Gauge（瞬时值）、Histogram（直方图）和 Summary （概要）， 通过这四种类型，可以实现指标的高效传输和存储。
2. 日志数据 ( Logging Data）
它描述一些离散的（不连续的）事件。 例如：应用通过一个滚动的文件输出debug或error信息，并通过日志收集系统，存储到Elasticsearch中； 审批明细信息通过Kafka，存储到数据库（BigTable）中；又或者，特定请求的元数据信息，从服务请求中剥离出来，发送给一个异常收集服务。
描述某个对象的是离散的事情，例如有个应用出错，抛出了NullPointerExcepction，或者是完成了一笔转账，个人认为 Logging Data 大约等同于 Event Data，所以告警信息在我认为，也是一种 Logging Data。但是也有技术团队认为，告警应该算是可观察性的其中一个支柱。
3. 跟踪数据（Tracing Data）
它在单次请求的范围内，处理信息。 任何的数据、元数据信息都被绑定到系统中的单个事务上。例如：一次调用远程服务的RPC执行过程；一次实际的SQL查询语句；一次HTTP请求的业务性ID。
Tracing Data 这词貌似现在还没有一个权威的翻译范式，有人翻译成跟踪数据，有人翻译成调用数据，我尽量用 Tracing 这个词。Tracing 的特点就是在单次请求的范围内处理信息，任何的数据、元数据信息都被绑定到系统中的单个事务上。
一个 Trace 有一个唯一的 Trace ID ，并由多个 Span 组成。下图详细说明了Tracing的发展史：
聊了这么多可观测性，那么我们站酷的这些监控，分别是做什么用的呢？
二、站酷监控梳理
上图说明：图中可以看到，我们的各个监控所处的位置，其中冗余项，我们倾向于优先发展绿色的这几个项目。即
Metrics：
ASM监控：无需业务开发，只要接入容器即可享受完善的监控图表（本质上是SLS来画图）。
Logging：
Sentry：排查详细问题，少不了详细的错误日志。
Alerting：上文说到，告警信息大多是logging 或metrics。
Tracing
同 ASM监控，使用 ASM的链路追踪（本质是Ali Trace）。
三、监控所处在容器化的位置
如图可以看到：
ASM监控+SLS、AliTrace，是在服务网格的istio后面做的，业务无感知。
其他的是在容器里做的，需要业务添加sdk。
所以各个业务同学根据上面两张图，即可选购你心爱的监控了。
四、监控告警截图+手册
1.ASM日志+ASM链路+网格的SLS日志（metrics纬度+Logging）
在企业空间（cmdb首页）即可看到监控页面。
2.Sentry（Logging这个纬度）
Sentry 是一个开源的实时错误追踪系统，可以帮助开发者实时监控并修复异常问题。 提供了对多种主流语言和框架的支持，包括 React、Angular、Node、Django、RoR、PHP、Laravel、Android、.NET、JAVA 等。
