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

本文涉及的产品
日志服务 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.告警手册

详见《告警手册》

相关文章
|
26天前
|
运维 监控
GTS的监控与报警
【8月更文挑战第23天】
32 2
|
26天前
|
SQL 运维 监控
ARMS全链路监控
【8月更文挑战第22天】
37 3
|
Web App开发 存储 监控
日志服务之告警接入与管理
本教程介绍如何使用日志服务接入NGINX模拟数据,并配置告警规则来对NGINX访问错误进行监控。
397 0
|
4月前
|
运维 Prometheus 监控
StarRocks 监控报警配置指南
StarRocks 监控报警配置指南
|
4月前
|
DataWorks 监控
DataWorks报警延迟是什么?
DataWorks报警延迟是什么?
55 3
|
存储 数据采集 监控
无数据告警最佳实践
在对SLS的Logstore和Metricstore进行监控的过程中,有时候会出现一些无数据的情况,监控SLS的存储库中无数据的情况,是保证数据成功上传到SLS的一个重要手段,本文将介绍无数据告警的常见配置方法。
434 0
无数据告警最佳实践
|
监控 机器人
夜莺系列 2 告警管理
夜莺的告警管理
625 0
|
存储 SQL 监控
SLS新版告警自助排查系列之告警监控
在SLS告警中,告警监控通过对数据源的查询监控,然后产生告警,并将告警发送到告警管理,告警管理会对告警进行降噪处理包括合并抑制静默后,在将告警发送给行动管理,最终发送通知到用户配置的接收渠道。在整个过程中,告警监控作为告警的源头,决定着告警是否能准确的发出。在配置告警监控规则时,配置不当或者配置错误都会导致告警不能触发或者不是希望的触发。本文主要介绍在告警监控中如何进行自助排查问题。
574 0
|
存储 运维 Prometheus
站酷监控告警实践
随着应用架构往容器化、微服务化方向发展,传统监控技术已经不能满足云原生时代运维的需求,因此,可观察性的理念被各个团队重视起来。 站酷的监控告警,经历了蛮荒发展的过程,先后推出了blackbox、Grafana、Prometheus、Skywalking、sentry等等工具、平台。大家在使用过程中,或多或少出现了疑问:我们真的需要这这么多监控么?为什么这么多监控监控不到我的痛点?未来我们是否只需要部分监控告警?
|
监控 Kubernetes 容器
云监控报警最佳实践之无数据策略
本文介绍了云监控报警中的无数据策略,通过该策略用户可以实现被监控对象无数据时的响应、处理。 ## 背景 云监控报警通常情况下是通过监控数据的阈值的判断来进行报警,比如cpu超过80%报警等。但有时候被监控对象的监控数据出现不连续或断掉的情况。如果要对这种情况进行报警,就需要配置无数据策略。 ## 配置无数据策略 首先进入[云监控控制台](https://cloudmonitor.console.
577 2
云监控报警最佳实践之无数据策略