站酷监控告警,终于有一篇文章说清楚了?

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 随着应用架构往容器化、微服务化方向发展,传统监控技术已经不能满足云原生时代运维的需求,因此,可观察性的理念被各个团队重视起来。     站酷的监控告警,经历了蛮荒发展的过程,先后推出了blackbox、Grafana、Prometheus、Skywalking、sentry等等工具、平台。大家在使用过程中,或多或少出现了疑问:    我们真的需要这这么多监控么?为什么这么多监控监控不到我的痛点?未来我们是否只需要部分监控告警?于是就有了这个比较诱人(唬人)的标题。那就让我们慢慢道来。
 随着应用架构往容器化、微服务化方向发展,传统监控技术已经不能满足云原生时代运维的需求,因此,可观察性的理念被各个团队重视起来。

     站酷的监控告警,经历了蛮荒发展的过程,先后推出了blackbox、Grafana、Prometheus、Skywalking、sentry等等工具、平台。大家在使用过程中,或多或少出现了疑问:

    我们真的需要这这么多监控么?为什么这么多监控监控不到我的痛点?未来我们是否只需要部分监控告警?于是就有了这个比较诱人(唬人)的标题。那就让我们慢慢道来。

一、这些年我们追过的可观测性

     可观察性的三大支柱及其之间的关系,Peter Bourgon 在2017年2月撰写了一篇简明扼要的文章, 叫 《Metrics, tracing, and logging》

     详细阐明了可观测性三大支柱:

     维恩图的方式展现三者关系时,会正巧展现出一个附加效应。在这三个功能域中,metric倾向于更节省资源,因为他会“天然的”压缩数据。相反,日志倾向于无限增加的,会频繁的超出预期的容量。容量的需求趋势:metrics低到logging高, 而trace可能处于他们两的中间位置

  1. 指标数据(Metrics Data)

特点是可累加的:他们具有原子性,每个都是一个逻辑计量单元,或者一个时间段内的柱状图。例如:队列的当前深度可以被定义为一个计量单元,在写入或读取时被更新统计; 输入HTTP请求的数量可以被定义为一个计数器,用于简单累加; 请求的执行时间可以被定义为一个柱状图,在指定时间片上更新和统计汇总。

描述具体某个对象某个时间点的值。在 Prometheus 中,指标有四种类型,分别 Counter(计数器)、Gauge(瞬时值)、Histogram(直方图)和 Summary (概要), 通过这四种类型,可以实现指标的高效传输和存储。

  1. 日志数据 ( Logging Data)

它描述一些离散的(不连续的)事件。 例如:应用通过一个滚动的文件输出debug或error信息,并通过日志收集系统,存储到Elasticsearch中; 审批明细信息通过Kafka,存储到数据库(BigTable)中;又或者,特定请求的元数据信息,从服务请求中剥离出来,发送给一个异常收集服务。

描述某个对象的是离散的事情,例如有个应用出错,抛出了NullPointerExcepction,或者是完成了一笔转账,个人认为 Logging Data 大约等同于 Event Data,所以告警信息在我认为,也是一种 Logging Data。但是也有技术团队认为,告警应该算是可观察性的其中一个支柱。

  1. 跟踪数据(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,业务无感知。

     容器中:其他的是在容器里做的,需要业务添加sdk。

所以各个业务同学根据上面两张图,即可选购你心爱的监控了。

四、监控告警截图+手册

1.ASM日志+ASM链路+网格的SLS日志(metrics纬度+Logging)

接入手册《ASM可观测性》《流水线添加ASM虚拟服务》

     2.Sentry(Logging这个纬度)

Sentry 是一个开源的实时错误追踪系统,可以帮助开发者实时监控并修复异常问题。 提供了对多种主流语言和框架的支持,包括 React、Angular、Node、Django、RoR、PHP、Laravel、Android、.NET、JAVA 等。

详见《sentry手册》《Sentry接入及使用引导 》

     3.KubeSphere Log(Logging这个纬度)

详见《kubesphere日志》

     4.告警手册

详见《告警手册》

相关文章
|
3月前
|
SQL 运维 监控
ARMS全链路监控
【8月更文挑战第22天】
82 3
|
3月前
|
运维 监控
GTS的监控与报警
【8月更文挑战第23天】
46 2
|
Web App开发 存储 监控
日志服务之告警接入与管理
本教程介绍如何使用日志服务接入NGINX模拟数据,并配置告警规则来对NGINX访问错误进行监控。
406 0
|
6月前
|
运维 Prometheus 监控
StarRocks 监控报警配置指南
StarRocks 监控报警配置指南
|
存储 SQL 监控
SLS新版告警自助排查系列之告警监控
在SLS告警中,告警监控通过对数据源的查询监控,然后产生告警,并将告警发送到告警管理,告警管理会对告警进行降噪处理包括合并抑制静默后,在将告警发送给行动管理,最终发送通知到用户配置的接收渠道。在整个过程中,告警监控作为告警的源头,决定着告警是否能准确的发出。在配置告警监控规则时,配置不当或者配置错误都会导致告警不能触发或者不是希望的触发。本文主要介绍在告警监控中如何进行自助排查问题。
596 0
|
监控 机器人
夜莺系列 2 告警管理
夜莺的告警管理
648 0
|
存储 运维 Prometheus
站酷监控告警实践
随着应用架构往容器化、微服务化方向发展,传统监控技术已经不能满足云原生时代运维的需求,因此,可观察性的理念被各个团队重视起来。 站酷的监控告警,经历了蛮荒发展的过程,先后推出了blackbox、Grafana、Prometheus、Skywalking、sentry等等工具、平台。大家在使用过程中,或多或少出现了疑问:我们真的需要这这么多监控么?为什么这么多监控监控不到我的痛点?未来我们是否只需要部分监控告警?
|
监控 Kubernetes 容器
云监控报警最佳实践之无数据策略
本文介绍了云监控报警中的无数据策略,通过该策略用户可以实现被监控对象无数据时的响应、处理。 ## 背景 云监控报警通常情况下是通过监控数据的阈值的判断来进行报警,比如cpu超过80%报警等。但有时候被监控对象的监控数据出现不连续或断掉的情况。如果要对这种情况进行报警,就需要配置无数据策略。 ## 配置无数据策略 首先进入[云监控控制台](https://cloudmonitor.console.
601 2
云监控报警最佳实践之无数据策略
|
存储 监控 Cloud Native
用户指南—监控与告警—配置告警
您可以在控制台上配置计算资源监控指标和存储资源监控指标的告警规则。本文将介绍如何配置实例的告警规则。
181 0
用户指南—监控与告警—配置告警
|
存储 JSON 弹性计算
使用云监控实现本地日志监控
本地日志监控是什么?本地日志监控是指使用云监控的Agent在本地对日志进行格式化处理,然后将处理后的格式化数据上报到云监控的指标仓库。而不用上报原始日志。在本地处理日志(而非上报原日志)有几个重要的理由:1,上报原始日志需要消耗大量的云端存储和网络IO,甚至为了查询还需要创建索引,费用不低;2,部分场景下的原始日志涉及到商业数据,不便上报,如订单信息,客户信息等。本地日志被处理成指标数据上报到指标
742 0
使用云监控实现本地日志监控