监控宝沙龙@熊昌伟正式版.ppt

* 几块核心业务 * 还有一个虚拟运营商。 * * 我们先回想一下，我们日常工作的中苦恼是什么。 1、是不是每天都感觉自己在救火 2、每天被一群围着，可一点上帝的感觉都没有 3、干的每一块工作感觉都是一个个的孤岛无法系统性，连贯性的窜起来 4、每天都干着一次性的工作，干不完的重复的工作 5、为什么都是运维的错，黑锅都是运维来背 * 你太沉迷于当下的忙碌工作状态了 缺少系统性的分工 对工作内容要抽象出来 模块化的管理运维各项 * 大家可能会说，我只有一个小兵，有些东西我没有办法控制。那我只说两点。 一你自己有没有努力的去改变现状，二你的领导是否积极的配合你去改变现状。 如果是第一点，那你就好好静下心来干踏踏实实干。如果是你们领导不配合，那趁早和他说拜拜吧。 * 下面我就简单介绍一下，我们现有的运维体系架构。给大家一个思路和借鉴吧。 看着是不是很高大上。其实也就是画着好看。 运维的东西越简单越好 * 这是我们现有的几大模块，红色的为还未完成了。但那都是一个流程规范类的东西。这些东西，在一个优秀的团队中没有什么用处。主要就是团队大了，就需要有一些规则、流程来约束一下。 * 这是我们一个日常的设备上架流程图。 我们现在上架，做到了，设备上架通电，配好管理卡IP,剩下的就是电脑玩电脑了。 先通过自动化装机系统，获取服务器的管理卡IP，灌入所需要的系统。然后通过puppet进行整型，先打入、配置好通用的模块后，再按用途进行分类安装 后面我会具体提到这块 * 这里要多说一句的就是，我们在准备上线任何一个运维系统前必须考虑好，他的多点部署、单点失效等问题。因为如果运维系统都不可靠，那后面架在上面的应用哪能有好日子过是吧？ 比如Puppet你就要想到当它出服务器损坏，脚本推送失败等故障时，生产业务是否正常，如何补救。 这里面比较有讲究，都是一些细节的东西，有兴趣的我们可以线下交流 * * * 通过LDAP统一管理起来后，其实就有很多事可以做了 进行统一用户展现，控制 进行单一用户的具体受权，可以按puppet组的模式来，也可以给某一台设备进行独立受权 这张图可以看出来，我们做的运维系统，还是比较有互联网思维的，都极简的模式，新建一个账号没有什么要填，只需要输入一个账号，我们就会按排规则所相关的ID\密码发送你的邮箱中 通过配置方便的设置密码策略与提醒时间 还可以通过LDAP的标准协议把各运维系统、监控系统、等等都加入进来。统一分配。 每天都会把前一天用户登录成功与失败的信息推送到相关运维人员的邮箱中，供大家查看。 这里面有一个真实的案例。。。。。。。。。。。。。。。。。。。。。 整体的想法呢，就是千万不要闭门造车，能拿来就是尽量拿来，有那个精力不如研究透现在的东西 这就是我们基于LDAP扩展出来的一些东西，自我感觉良好。可能大家有更好的，希望大家能分享出来，多交流 * * 监控是什么，就是：发现问题、提示问题、定位问题 * * 什么是价值，就是把我们从救火队转变为医护队 主动监控比如服务器当前运行的状态，各项资源情况如果。这是我们通过SNMP或agency获取的 预警式监控，比如硬盘空间快满了，实时报警是有，但为什么要把一个平常的东西，提升为紧急问题来处理呢。为什么不能把他做为一个日常任务呢。 这里面就比较智能了，比如通过分析月环比、周环比、日环比得出一个可用天数，然后进行每天推送式的预警。 * 如何发现问题呢，一堆报警袭来，如何甄别。 报警准确与合理设置监控项阈值设置，以及报警通道的速度有关，对一级服务进行短信报警，二级服务采用邮件方式报警，三级服务属于不需要报警仅需要数据采集趋势图绘制。 这里个性化的东西太多了，就不多讲了。 我这里就说一个关键核心，就是要有一个全局观、分类汇总的能力，用图的模式最能表现了 * * 大家可能会说，监控都做的这么强大了，还用监控宝做什么呀？ 事实上大家忽略一个最最重要的东西，就是客户的真实体验是怎样的。我们不能掩耳盗铃。 能过监控宝就可以非常有效的解决这个核心问题。他不用管我里面怎么样，死了多少台服务器，有几条链路断了。只用给我看着我的应用给客户展现的是否可用。 比如：我们现在的系统内部都非常庞大与复杂的，但都做了冗余与高可用的，当我们收到一堆自己的报警时，没有收到监控宝的报警，那就证明，现在状态可控，是重要非紧急的。 还有一个妙用，就是做故障演练时，你可以在里面乱搞。只要监控宝不报警，就证明这个系统高可用是没有问题的。 另一个就考核了，如何证明我们做到了99.9% SLA 那就看这个。 * 比如我们现在的服务托管在机房，要确认当前的全国各地方到机房网络状态如果。 如果应用出现问题，也可能通过监控宝先定位出是否机房方面出现问题。 最核心的，就是节点多，并且这些数据都是十分有需