OneAlert

如何把关联性的告警智能添加到 Nagios 上?(2)

时间秒杀一切 提交于 2019-11-27 13:40:36
######上节回顾 对于许多 IT 和运维团队来说,Nagios 既是一个福音也是一个诅咒。一方面,Naigos 在 IT 应用的工作领域中,给予了你可以实时查看告警数据的可能性;但是另一方面, Nagios 也能够生成超级多的告警,对于任何一个运维人员或是运维团队来说都是 hold 不住的。 由于告警浪潮的原因,我们收件箱时常会爆满,移动电话也会被逼调成静音状态。更令人沮丧的是,这些告警只不过仅仅是噪音而已。 Nagios 所欠缺的就是一个智能的管理系统,可以在噪音背景中,帮助运维人员挑选出真正的有意义的告警。 当然,说起来容易做起来难。 在上一篇文章中,我们讨论了为什么 Naigos 起初会生成如此之多的告警,并且很少是需要实际执行的。 那么现在,让我们来讨论下该如何把告警智能化。 ######告警关联 唯一使监控和报警都步入正轨的好办法,就是通过告警关联。如果成百上千个告警都潜在的指向着同一个根本问题「当然情况也常常如此」,我们需要的就是一种能够瞬间查找到关联这些告警的方法,这才是真正的问题所在。 以下这个例子,可以很好的理解告警关联,并告诉你如何提升应用监控。 例如一个 MySOL 集群,这里面一些主机的页面上有着很高的错误率,而其余一些只是发出低内存的警告。此时你的 Nagios 图表盘在30分钟里,会接受到不止20个独特的告警,这其实看起来没有太大的意义

OneAlert 入门(一)——事件流

跟風遠走 提交于 2019-11-27 13:30:37
### OneAlert 入门(一)——事件流 OneAlert 是国内首个 SaaS 模式的云告警平台,集成国内外主流监控/支撑系统,实现一个平台上集中处理所有 IT 事件,提升 IT 可靠性。它能以史上第二快的速度,对事件进行智能的组织、排序和分类,从而极大地提高团队在处理运维告警与事件时的协作能力。本文是 OneAlert 入门系列文章的第一篇,主要介绍事件流。 #### 事件流 OneAlert 界面最重要的部分便是事件流。只需点击菜单中部的告警图标,就能追踪并管理所有的告警,不论它们来自什么监控工具 —— Zabbix , Nagios ,Solarwinds, AWS CloudWatch,Open-Falcon, 阿里云 ,监控宝,腾讯云等十几种都能支持,而且新的应用正在快速集成。 #### 自动智能归类告警 现有的多数软件缺陷追踪系统、工单管理系统以及问题追踪工具都不是针对 IT、NOC 以及 DevOps 设计的,基本上每个工单都必须由用户手动创建。但是,这并不适用于当今的 DevOps 。传统的告警往往是由于超出监控栈中阈值而自动生成的,这些告警数量庞大,少则上百条,多则上千条。OneAlert 能自动分析这些告警,将它们按照主机、集群或者应用智能地进行组合,形成事件。 #### 实时监控 OneAlert 支持实时更新数据,确保 OneAlert

告警信息大爆炸,运维解放秘籍!

给你一囗甜甜゛ 提交于 2019-11-27 09:01:17
信息大爆炸的时代,互联网企业的运维人员每天都要处理成千上万的信息。如何处理这种纷繁复杂的情况?面对各种运维事件,想获得足够的告警信息,单一的监控系统往往是不够的。而告警的问题若得不到及时的发现与处理,就很容易受到用户投诉。 告警风暴来临,信息无法聚合 日新月异的专业监控软件陆续问世,越来越多的工具在监测告警方面变得越发的专注、极致。91%的运维团队同时用着多种监控工具,这些工具每天都会发出成百上千个告警。不幸的是,在这些告警触发之前,只有27%的团队会做一些有关聚合与过滤的事情。那么由此会产生什么后果呢?运维团队面对冗杂且繁复的告警信息,会加重每位成员的负担,经常处于精疲力尽的状态中。 这样下去,团队会被大量无休止的告警所湮没。运维工程师们很难了解,哪些告警信息才是最关键的?哪些告警信息是重复可替代的?哪些告警信息又是可以忽略且清除掉的?于是处理告警就成了最头疼的事情,而且把时间都耽误在了处理错综复杂的无效告警上,错失掉真正需要关注的信息。后果就是,把用户的怒火点燃了,难以被补救。 如上所述,大部分的运维团队购买了若干个监控系统用以监测应用性能,然而却会导致网络故障,服务器不堪重负,人员配置跟不上等。除了监控系统的安装数量过多,传统的监控方式也是一直以来很大的问题。由于手动效率过于低下,尽管 Email 在高风险的事件报警传达中传播的速度很慢

当 ITOA 遇上 OneAlert,企业可以至少每年节省 3600 小时!

寵の児 提交于 2019-11-27 00:30:08
每个工作日,一家大型企业都可能存在一两件优先级为 1 级的事件,五六件优先级为 2 级的事件和百来件优先级为 3 级的事件。试想一下,如果公司所有支持人员都要收到每个事件的通知……不想了,我好方!还能不能愉快的工作了?然而,这样的事情每天都在各个企业里上演。然而支持团队并无权处理所有事件!他们却需要反复地处理各个事件,如果全球各地的支持团队都如此,想想这总共得浪费多少时间和多少叠 money 呀! 2012 年全球第一家 ITOA 企业 Splunk 的上市,人们才有了更为有效的方法解决上述问题。 首先我们先科普下 ITOA 究竟是为何物, Wikipedia 如是说 : Definition: IT Operations Analytics (ITOA) (also known as Advanced Operational Analytics, or IT Data Analytics) technologies are primarily used to discover complex patterns in high volumes of often "noisy" IT system availability and performance data. Forrester Research defines IT analytics as "The use of

怎样创建合适的告警处理流程?

帅比萌擦擦* 提交于 2019-11-27 00:29:25
我们都知道监控对确保网站和应用的平稳运行是多么重要,但这只是一个方面。一旦发现错误,监控软件发出了告警消息你该怎么做?如何决定下一步采取什么措施? 一个合理的告警流程可以帮助你优先处理最重要的问题,并且避免让问题打扰到不在职责范围内的无关人员。更广泛地说,它使得每个人都清楚地知道自己应该解决什么问题。 ##怎样创建合适的告警处理流程? 创建一个合适的告警处理流程可能会比较棘手,这个过程需要自己去摸索。适合你的规则可能不适合另一个团队——即使是相同规模的团队或者处于同一行业的团队。 如何创建合适的处理流程,取决于你的团队,项目类别、项目的基础架构,团队的组织架构和使用的工具。那么你应该从哪里开始呢? 根据经验,创建升级过程需要考虑以下3件事情: 严重程度等级结构 团队的组织结构 阈值及其相应的通知渠道 显然,具有较高严重性的错误自然需要更可靠的通知渠道。例如,你可能会选择使用 OneAlert 为高严重性错误发送短信或者打电话,而被认为低严重性的错误则不会触发告警,以减少噪声。作为替代,你可以为其选择邮件、微信通知。 ####1. 严重性等级结构 设置严重性等级结构的最简单方法是根据商业价值来确定网站或应用的最关键部分。 例如,一家网店的的最关键部分就是它的产品目录和结账功能。这些功能如果停止工作将会导致网店业务受到严重影响。因此,这些问题应排在其他问题之前优先考虑。

程序猿必备的高逼格午饭玩具

会有一股神秘感。 提交于 2019-11-27 00:29:16
午饭选择综合症?天天呆在写字楼,方圆百米内的餐馆都吃吐了?天天喊着「改变世界」的程序猿,连午饭吃啥都搞不定,还搞个毛线世界? 这是一篇有逼格追求的程序猿们,有效解决中午吃啥的「世界性难题」的故事,正在申请2016年诺贝尔和平奖。 原始需求: 解决攻城狮、程序猿、运维狗们的午饭吃啥问题。不在以上系列的小盆友请出门右拐煎饼摊,夹菜5块,加肠7块。 解决思路: (设计)提前解决,12点吃饭,11点开始准备。 (功能)负责到人,落不到人头上的都不算事。团队里每个小伙伴轮值一天,负责确定吃啥,如果是外卖下单;或者饭馆订位,或者确定快餐店吃饭地点。 (可靠性)候补机制,如果第一责任人没有及时处理,有候补人员,第一责任人惩罚买零食。 实现: 使用 OneAlert 排班计划,团队每人轮值1天。 使用定时调度脚本,11点准时提醒。发送吃饭事件到 OneAlert 的一个应用里。 使用 OneAlert 的通知必达,短信、微信、电话、邮件通知第一负责人,如果不处理,默认升级候补人。 不知道 OneAlert 的,请自行度娘。 微信通知 分享 OneAlert 的小伙伴排班表 分享我们的分派策略: 如果排班同学不及时订饭,升级到老大!兄弟等着买零食吧。 接下来是定时调度脚本代码实现部分: 1.安装json处理工具jq yum install jq -y 2.vim chifan.sh ,写入以下命令

论互联网合并趋势之不一样的「合并」

99封情书 提交于 2019-11-27 00:29:06
这一年,合并的咣当声不绝于耳。从情人节的滴滴与快的合并,到年中的58与赶集合并,再到国庆节的美团和大众点评,以及10月底的携程与去哪儿……合并声,有的人觉得悦耳,有的人觉得刺耳,总之是声声入耳。不仅入耳,甚至还震掉了下巴。那么,2015年还剩一个月,合并声或许会于你的耳边再次响起…… 接踵而至的这四起合并案,掀起了中国互联网行业的合并狂潮。可以说,2015年就是中国互联网行业的合并元年。这四起合并案,件件震动了业界。这,就是趋势,合并的力量。 合并很恐怖吗? Peter Thiel 的《从0到1》一书中阐述了这样的观点:互联网企业竞争的最高形态就是合并,合并的行业比充分竞争的行业更有前途,对消费者更有利。 再往前推推,在互联网的江湖中,优酷土豆之前,为何一个合并案例也没有呢?今年为什么合并案会井喷呢?因为现在到了移动互联网时代,用户主要通过手机 APP 上网,每一个分类,用户装一个 APP 就够了,连第二个都不会装,更不用说六七八个了。所以,人人都想争当第一。当大家的模式、技术、人才等都发展到上限时,怎么才能抢到第一呢?最后只好放大招,比谁钱多。两个土豪碰一起,钱都多怎么办,合并! 就像早年间配个电脑,CPU 是谁家的、硬盘是谁家的、主板是谁家的、内存条是谁家的,一清二楚,现在你买台电脑,这些东西是谁家的,没人关心了。那么当下用户最关心的是什么,当然是好不好用,方不方便了