运维工程师如何做好告警分析与汇报？

于 2020-05-22 17:41:12 发布
阅读量916 收藏 4
点赞数
分类专栏： 运维 文章标签： 运维
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_45385576/article/details/106287791
版权
本文介绍了智能告警平台Cloud Alert (CA) 如何帮助运维团队进行告警管理，包括告警降噪、流程化管理、多维度报表分析，以提升告警响应和恢复效率。CA提供事件量、压缩比、MTTA、MTTR等关键指标分析，以及应用分析、关闭分析、告警级别和状态分析、成员分析和告警智能分类等深度洞察，助力运维团队优化告警处理策略。
摘要由CSDN通过智能技术生成

智能告警平台（Cloud Alert） CA，能快速接入各类告警信息，通过自动去重、规则压缩、算法降噪，实现告警降噪，帮助IT运维团队减少告警，避免告警风暴；同时通过分派、排班、通知等功能，快速实现告警流程化管理，帮助运维团队更快响应告警，恢复告警，提升告警管理能力。
CA提供多维度报表帮助您快速分析告警、成员工作效率，概览系统运行状况。支持自定义时间段，回溯分析历史系统状况。
在这里插入图片描述
在这里插入图片描述
关键指标分析
事件量: 原始告警量
· 主告警量: 自动去重、规则压缩后告警量
· 压缩比: 压缩比计算公式：(1 - 主告警量/事件量) * 100%
· MTTA: 告警平均响应or认领时长
· MTTR: 告警平均恢复or关闭时长
事件压缩分析
· 按天统计事件量、所有告警、主告警量随时间变化趋势
· 点击右上角 more 按钮，可下钻查看更多分析，若回溯分析时间跨度过长，还可以按月维度统计事件量、主告警量、所有告警量

最低0.47元/天 解锁文章
睿象云
关注
专栏目录
博客
可观测性（二）
04-27 587
上一期可观测性文章《可观测性（一）》里面聊了可观测性的定义、价值和三大支柱。其中值得再次提及的是，可观测性的核心目的是以量化的方式管理企业的基础设施（包括中间件等）、平台和应用程序。正所谓 “如果你无法量化它，你就无法管理它” -- 彼得·德鲁克。同时还有一个要点，就是可观测性要完成闭环，终究需要告警管理平台来做连接--将问题指标即时反映给相关维护人员，以解决系统无法自修复的问题，同时提高系统自修复能力。接着这个话题，这期我整理了构建一个优秀的可观测系统需要哪些核心能力。
博客
On-call机制——一种有效运维的方法
03-09 3238
对于On-cal这一词，国内并没有特别明确的说法，因为这是个欧美流传过来的叫法。国内与之相接近的意思大致就是值班，再详细一些的说法便是指企业为了快速相应生产故障或者重大事件，在某段时间内指定某个人或者某组人随时待命（类似值班）。在故障发生的一瞬间，会以邮件、短信、电话等形式通知到负责人，以保障第一时间的处理。正所谓，没有零bug的程序，没有零问题的系统，因此互联网技术的发展也是时刻离不开运维的支撑，与此同时，On-call机制的理念也逐渐流行开来，但依旧会存在没能有序但处理：海量的事件淹没了重要事件，
博客
多变的智能降噪
11-17 669
告警、作为监控的平台的最直观的体现形式，可以体现出被“监控者”的当前状态，你可以看到它是健康十足的平稳状态，亦或是偶尔发出告警的异常状态，甚至是告警癫狂的崩溃状态，这都是最直观的告诉你他是否需要你的方式。但如果没有好的梳理方式，反而会让人没办法正确的发现它此时的情况，今天我们就来说下如何通过智能告警平台Cloud Aler中的智能降噪的功能，实现告警的灵活处理。睿象云智能降噪Cloud Alert中，有三种降噪的类别，分别为：自定义规则降噪、时间窗口智能降噪、实施智能降噪；分为两种降噪方式，一种是单点降噪
博客
创业公司的监控告警需要几个人？一个就够了
10-29 320
一家年轻的互联网初创公司，通过一个好的idea获得了一批用户，当他们的用户增长的时候，就面临一个问题：为了防止服务崩溃，该如何做好监控告警？有统计显示，初创公司服务崩溃带来的用户流失率几乎达到了70%，而对于大公司来说，有80%的用户希望有更好的体验。一家用户至上的创业公司，要在客户发现之前知道服务出了什么问题，就要建立一套强大的监控告警系统！这样就可以避免故障发生，或者把故障影响降到最低了！那么创业公司的监控告警要怎么做呢？监控系统对于公司来说，监控告警系统有两种选择：现成产品或者自研，现成产品
博客
为什么国内很多公司都自主开发监控告警系统？
10-19 990
在互联网企业大行其道的今天，以开源软件为代表的开源文化成为一股不断壮大的潮流，各种开源监控告警系统如zabbix、nagios等也是层出不穷。但奇怪的是，在国内却仍有很多公司选择自主开发监控告警系统，究其原因是什么呢？国外有一个网站叫StackShare，可以查看各公司用了什么产品！比如我们可以看什么公司用了zabbix！在这个网站上可以看到，从亚马逊、谷歌这种顶级公司，到中小型公司都会使用各种开源软件或者SaaS，所以这在国外是非常普遍的情况。但为什么国内就喜欢自主开发监控告警系统呢？关于这个问
博客
为什么都劝运维转开发，却仍看到大批年轻人运维做的风生水起？
10-18 5745
当谈到运维职业发展情况时，很多人都会说运维做不长久，然后劝人做两年就赶快转研发吧！总之是全面唱衰运维！但作为一个老运维，我想说的是：运维转开发确实是一个不错的选择，但运维做不长久则完全是对运维的偏见了!很多人有运维做不长久的偏见的原因其实和运维职业的特性有关，运维有三个老生常谈的特点：打杂，背锅，睡的少！说运维打杂，是说运维工作比较宽泛，运维职业门槛不高，什么都得会一点。公司里但凡跟计算机有关的事，可能都会找到运维，这就导致了运维工作比较杂！至于背黑锅，是说运维工作做的好了没人找你，但一旦出问题，所
博客
为什么国内互联网公司喜欢用Centos而不是Ubuntu？
10-09 1680
几乎所有新手接触Linux时，都会被它的几百个发行版本搞得一头雾水，在众多Linux 版本中，CentOS 和 Ubuntu 可以说是最有名的两个了，而关于这两者的选择也是大家在网络上经常讨论的问题。比如各大网站都有热门问题：为什么国内互联网公司喜欢用Centos而不是Ubuntu/Debian？作为一个十多年经验，见证了linux的一路发展的老运维，我总结了三点分享给大家：企业选择系统的决定性因素是稳定性，但稳定性的本质是钱，谁的钱多，谁就更稳定！Centos就是Rhel的克隆版，背后是Redha
博客
运维为什么这么难招？
09-28 9909
最近群里的hr朋友总说运维太难招，基本招不到人，作为一个在运维界摸爬滚打10多年的老炮儿，我说：你招不到人是有原因的！因为不只是运维的招聘难，而是两边都难，一边公司招不到人，一边是运维不好找工作！公司招不到人最根本的原因，文明点说就是招聘职位定位不清晰，说不好听的就是心里没点x数！为什么这么说，看看他们的招聘要求就知道了：学历本科及以上！本科以上的干点啥不好，运维能力经验比学历重要多了好嘛！要求具备基本自动化运维开发能力！就这么简单的一句话要学的东西多了去了，有开发能力直接去干开发他不香吗？
博客
从被吐槽的Amazon看，如何建设好的on call机制？
09-06 718
对于每个程序员来说，进入市值万亿的Amazon工作，似乎都是一件值得骄傲的事，但只要在网络上一提起Amazon，关于它的on call 机制的吐槽就会此起彼伏！要知道在互联网公司，on call应该是非常普遍的现象。但大家为什么对Amazon的on call文化如此反感呢？Amazon的on call真的不一般首先是范围广，基本上90%的组都要on call，甚至可以说只要在Amazon做技术基本都有过on call的经历。其次是时间长，基本是每隔x周就要接受一周的on call，x等于团队人数。而
博客
关于告警管理的软件，您还只知道Pagerduty吗？
08-23 449
全面数字化时代，组织业务系统建设复杂，各个服务之间的调用关系多重依赖。一个指标的变化，可能引发一系列的告警连锁反应。不同监控平台的红色标识、不断涌入的告警邮件和短信，紧牵着运维人员的神经，告警管理挑战重重。传统的监控告警工具和故障处理方式已成为数字化业务系统高效稳定运行的“老大难”。监控告警 就是故障发现的重要一环。当有异常发生时，运维人员常常可以从一些告警中找到蛛丝马迹，但是每天动辄上万条的告警经常都让运维人员无的放矢。从IT运营管理的基本面上来讲，告警事件每天都会发生。那么，与告警相关的各项服务的健康
博客
关于飞书的告警通知，这里有个更好的办法
08-23 892
飞书，是字节跳动于2016年自研的新一代一站式协作平台，是保障字节跳动全球五万人高效协作的办公工具。飞书将即时沟通、日历、云文档、云盘和工作台深度整合，通过开放兼容的平台，让成员在一处即可实现高效的沟通和流畅的协作，全方位提升企业效率。2020年2月24日，字节跳动旗下办公套件飞书宣布，向全国所有企业和组织免费开放，不限规模，不限使用时长，所有用户均可使用飞书全部套件功能。越来越多的公司开始使用飞书处理工作事宜，运维团队实现将告警发送到飞书，并通过飞书来进行处理告警，就成为了迫切的需求。睿象云智能告警平C
博客
行业洞察系列之《事件管理的 5 个阶段及其改进建议》
07-15 519
高效的事件管理应该是所有企业业务系统的重要组成部分。为什么这么说？因为随着IT技术、工具和工作流程的日益复杂，以及彼此关联性的日益增加，业务系统越来越容易受到计划外停机的影响。停机可能在任何时候发生在任何系统上，对内部和外部业务运营都会造成潜在影响。停机事故的成本通常以每分钟数万（甚至数十万）美元计算。由于会面临这样的潜在影响，企业正在加速优化事件响应流程，以确保事件能够得到最快最有效的管理。这意味着企业需要采取一种全面的事件应对方法，了解事件如何发展，如何不断提高系统弹性。从学术角度来看，一个典型的事.
博客
睿象云入围 | 腾讯云原生加速器首期成员名单
07-06 303
睿象云入围 | 腾讯云原生加速器首期成员名单6月30日，“开源向善·应云而生”腾讯云原生加速器公布了首期入选企业名单，睿象云等 38 家优秀云原生企业从全球500多家参与企业中脱颖而出，携手腾讯共建云原生生态，面向云原生未来加速启航。产业数字化浪潮中，云原生已成大势。企业发展中的开发、运维、管理等环节日趋复杂，云原生技术为企业提供了面向未来的信息化平台构建方式，并已逐渐开始融入各行各业。腾讯积极构建云原生生态，联手生态伙伴，共同为企业提供便捷、安全的云原生服务。由此，“腾讯云原生加速器”应运而生，输出腾
博客
车行易携手睿象云：告警管理体系全升级
04-16 351
据权威数据显示，目前国内汽车后服务市场的规模已达万亿级别。而在车主日常用车的多种生活场景中，与车辆违章相关的细分业务使用频度仅次于导航、停车、洗车等三项车后服务，这也是极具发展潜力的一个细分市场。「车行天下，快易人生」的车行易，已经成为众多服务厂商中的佼佼者。创立于 2011 年，全国最大的违章数据处理平台的车行易违章大数据平台（以下简称：车行易），已经在线服务覆盖全国 330 多个城市，在全球拥有超过超一亿车主用户。车行易以庞大的车务数据平台为基础，集违章代办办理、行车周边、车务处理、一键挪车、实时提
博客
当 ITOA 遇上 Cloud Alert，企业可以至少每年节省 3600 小时！
04-01 240
每个工作日，一家大型企业都可能存在一两件优先级为 1 级的事件，五六件优先级为 2 级的事件和百来件优先级为 3 级的事件。试想一下，如果公司所有支持人员都要收到每个事件的通知……不想了，我好方！还能不能愉快的工作了？然而，这样的事情每天都在各个企业里上演。然而支持团队并无权处理所有事件！他们却需要反复地处理各个事件，如果全球各地的支持团队都如此，想想这总共得浪费多少时间和多少叠 money 呀！2012 年全球第一家 ITOA 企业 Splunk 的上市，人们才有了更为有效的方法解决上述问题。首先我.
博客
睿象云智能告警平台cloudalert排班可以帮你做什么
04-01 318
排班功能详解· 轮班机制· 工作时间· 多视图展示· 排班临时调整如何通过排班助力运维团队· 通过排班让告警精准分派相关人员· PDCA 戴明环优化排班策略轮班机制Cloudalert（以下简称CA)的分派功能已经可以实现告警第一时间分派到相关人员，但告警一定要第一时间所有相关人员同时处理么？答案是否定的，大部分公司会选择以值班的方式，让不同的人在指定的时间内，处理当时发生的告警。CA的排班功能中，可以实现如下轮循值班需求：· 按天轮循· 按周轮循· 按指定小时轮循CA支.
博客
Datadog 能成为最大的云监控厂商吗
03-29 937
Datadog 原本是一家名不见经传的云监控公司，于 2019年9月19日 登陆纳斯达克，上市首日即突破 80亿 美金。上市前还搞了个小插曲，思科在 IPO 前夕提出 70亿美元 全面收购要约，被 Datadog 董事会断然拒绝。时至今日，经过了一年半左右的持续上涨，截至 2020年3月2日，Datadog 市值达到了令人咋舌的 298亿美金。一个做云监控的厂商为什么能比风头正劲的 Splunk 还值钱，是不是被资本市场高估了？未来还能走多远？我带着这一席勒疑问开始进行了相关的研究。我们先来看看 D.
博客
AIOps 让「事件管理」变得更加智能
03-15 384
AIOps 日益增长的趋势，代表着未来市场积极的发展信号。最终，AIOps 将有能力帮助 IT 团队完成各类最重要任务与最紧迫的事务，例如与业务效能密切相关的应用程序与数字服务可靠性、稳定性以及正常运行时间。日益分散、异构且高度动态化的现代 IT 环境不仅没有降低监控与管理的难度，反而随着云计算、容器与微服务技术的普及给各类组织带来更严苛的运营挑战。面对这一现实难题，IT 领导者正转向 AIOps，将人工智能应用于 IT 运营，希望借此破解 IT 复杂度提升与传统监控工具不足的窘境。人工智能技术和 IT
博客
想要完成系统性能评估？ 试试【云压力测试 + APM】的端到端压测解决方案
01-28 892
随着移动互联网、云计算、物联网等技术的不断发展，企业数字化转型的渗透率也越来越高，应用架构变得更加离散和复杂，一个系统是否具备高稳定性，不但要看其架构是否合理，还要关注其性能是否强大。​对于小型的产品来说，每秒的在线人数超过百人就可能会导致产品无法响应，而对于一些几经考验的产品，每秒上万，上百万的并发才能满足他们的业务需求。当产品的承载能力遇到瓶颈的时候，发包不断超时，页面不断加载，然后页面无法响应，直到最后服务器崩溃…企业要想从容应对业务访问流量，准确发现系统性能瓶颈，就需要找到更加科学解决方案，而性能
博客
干货分享｜仅需六步，加速提高DevOps效率
01-08 385
随着企业业务对软件系统日益依赖，IT运营管理与产品研发交付对“敏态”模式产生了愈发强烈的需求。将产品的设计、开发与运营等元素进行高效整合，综合管理，就是今天时常提起的DevOps。可以说DevOps的到来才真正让开发者与管理员携起手来，并为传统开发及运营流程间存在鸿沟及割裂架起了桥梁。为了提升产品的上线发布速度，实现更好的开发敏捷性，让开发人员拥有更多的时间去创新，越来越多的技术团队都在寻求实施DevOps。但是，采用DevOps并不是万能药，这种方式需要开发团队和运维团队密切交流、高效协作并且相互理解.
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值