简介： 本文介绍什么是云原生可观测性需求以及告警限度，介绍一站式云原生智能告警运维平台——SLS 新版告警。

前言

本篇是 SLS 新版告警系列宣传与培训的第一篇，后续咱们会推出 20+ 系列直播与实战培训视频，敬请关注。

系列目录（继续更新）

• 一站式云原生智能告警运维平台——SLS 新版告警公布！（本篇）
• 这才是可观测告警运维平台——20 个 SLS 告警运维场景
• 可观测告警运维零碎调研——SLS 告警与多款计划比照

1. 云原生观测告警

1.1. 业务倒退对开发运维的挑战

古代业务倒退对开发运维提出了新的挑战，具体如下：

1.1.1. 业务：稳定性要求越来越高

参考 AIOps 的指标与挑战，随着越来越多的业务云化数字化，例如往年开始大热的在线教育，任何一个稳定性、可靠性等异样都将给业务带来微小的损失。要求 SLA（服务可靠性）越高越好、MTTR（问题均匀修复工夫）和 Cost（老本）越低越好。

在各大云厂商，也指定了十分多的稳定性制度和要求，例如 1 -5-10（1 分钟发现问题，5 分钟定位问题，10 分钟解决问题）准则。

1.1.2. 零碎：复杂性越来越高

随着开发模式（麻利开发、DevOps）、零碎架构（分层、微服务）、部署模式（容器化、云原生）、和基础设施（多云、混合云）的疾速演变，零碎变得原来越简单。当零碎呈现问题时，如何发现问题、排查定位起因、解决问题就越来越艰难。从监控运维的角度，零碎的 可观测性 也逐渐成为是一个根本要求。

1.1.3. 工程师：职责越来越大

因为前述起因，零碎从研发集成到上线前后的各个阶段，有大量的工作须要做，不同人员参加的协同会大大降低响应速度，越来越多的公司要求 一专多能。开发、测试、运维交融逐渐成为趋势，开发人员逐渐开始承当测试的工作、局部的运维甚至经营的工作。

随着业务数字化时代的到来，可预见到经营角色更深刻的与开发、运维角色交融也是一个趋势，也就是说开发工程师将来投入到经营（Ops）的工夫也会逐渐减少。

1.2. 什么是可观测性

传统监控 个别以一个白盒形式监控零碎，专一发现外围指标异样，例如 500 谬误，客户订单成功率等。个别这种问题产生时，准取性极高（例如大量 500 谬误，大量订单失败，肯定示意 SLA 有问题），个别也都比较严重。因为是 黑盒，进一步排错和修复工夫和老本极大，往往给开发运维人员带来极大压力。

依据海恩法令(Heinrich’s Law)，每一起严重事故背地，必然有 29 次轻微事变和 300 起得逞前兆以及 1000 起事故隐患。如果提前解决那些不那么重大的问题、前兆或者隐患，其实是能够防止后续的严重事故的，也就防止了其带来的微小压力和损失。

可观测性 是对 传统监控 的降级，其要求进行 白盒化 监控，对各种可能的隐患、前兆、不重大问题进行监测、跟踪解决。且不再只是在公布后，而是在开发、测试阶段就进行。

因而比照两者，能够发现，传统监控 次要由 SRE 人员 从零碎内部 进行监控，关注 指标 ，发现问题（Know What）；而 可观测性 由DevOps 人员 从零碎外部 进行监控，关注 指标、日志和跟踪 等数据各种数据，发现问题并开掘起因（Know Why）。

1.3. 可观测性的挑战

依据 AIOps 平台计划抉择，可知各种监控数据（指标、日志、跟踪 等）的中台都有各种计划，同样的监控零碎也有十分多的抉择。

次要挑战就是：

1. 数据笼罩不残缺、存在数据孤岛（无奈关联协同）
2. 应用门槛高，不人性化

1.4 告警运维零碎的痛点

可观测性对于告警监控运维零碎是有很高的要求的，但现状却不容乐观，咱们能够看到惯例监控运维零碎存在如下 6 大痛点：

具体开展细化如下：

1. 什么是 SLS 告警运维零碎

2.1. SLS（日志服务）是什么

SLS 是阿里云上云原生观测剖析平台，为 Log/Metric/Trace 等数据提供大规模、低成本、实时平台化服务。目前 对内 曾经是“阿里巴巴 + 蚂蚁金服”零碎的数据总线，数年稳固撑持双十一、双十二、新春红包流动。对外 则曾经服务阿里云几十万企业客户。

2.2. SLS 新版告警——一站式智能告警运维零碎

SLS 新版告警在中国站等公布公测（国内站预计 4 月公布），新版在 SLS 云原生可观测性平台上提供了一站式智能运维告警零碎。新版告警提供对日志、时序等各类数据的告警监控，亦可承受三方告警，对告警进行降噪、事件治理、告诉治理等，新增 40+ 性能场景，充分考虑研发、运维、平安以及经营人员的告警监控运维需要。

能够看到新版告警由 4 个模块组成：告警监控、告警治理、告诉 (口头) 治理以及行将公布的凋谢告警组成。上面逐渐介绍各个模块的作用。

2.3. 劣势

应用 SLS 新版告警，能够无效缓解后面提到的告警运维零碎的痛点，和其余自建、商业化或云厂商提供的计划比，具备如下 5 大劣势：

2.4. 告警监控概述

通过 告警监控规定 配置，定期检查评估，查问统计源日志、时序存储，依照监控编排逻辑，评估后果，并触发告警或复原告诉，最终发送给 告警策略。

告警监控 提供的性能能够分为如下 3 类：

根底能力

其中值得强调的是 SLS 告警监控的 根底能力 反对大规模日志 / 时序 / 跟踪等实时监控，而查问统计语法也是应用通用对立的 SQL（并扩大）的形式提供。也就是SQL = Search + PromQL + SQL92。

例如对特定机器是否在线监控，能够应用 SQL、PromQL、或者两者子查问协同、甚至多层嵌套应用机器学习的算法来找出异样。

其中机器学习算法是间接在 SQL 扩大形式提供，笼罩了以下 4 个场景：

2.5. 告警治理

每一个告警监控规定会将触发的告警 (含复原告诉) 发送给一个事后配置的 告警策略 ，通过 告警策略 配置，对所有承受到的告警进行 路由分派、克制、去重、静默、合并 操作，后再分派给特定 口头策略。

通过告警核心控制台能够治理告警的状态（包含设置解决人），和查看告警链路与规定态势。

告警治理 提供的性能也能够分为 3 类，如下：

2.6. 口头 (告诉) 治理

每一个 告警策略 依据配置分派合并后将每个告警合并汇合发送给特定的 口头策略。由口头策略依据配置动静分派给特定告诉渠道告诉到特定的人 / 组 / 值班组，也反对告警未及时处理下的告诉降级。

口头 (告诉) 治理 提供的性能也能够分为 3 类，如下：

原文链接
本文为阿里云原创内容，未经容许不得转载。