58集团监控业务实践：将网站运行信息透明化

《58集团监控业务实践：将网站运行信息透明化》要点：
本文介绍了58集团监控业务实践：将网站运行信息透明化，希望对您有用。如果有疑问，可以联系我们。

作者介绍
龚诚,58集团技术工程平台部高级经理,硕士毕业于哈尔滨工业大学计算机应用专业.曾任职于百度、新浪微博等公司负责运维及自动化团队的技术和管理工作,在网站的稳定性建设、网站优化等方面有丰富的经验.监控系统是服务稳定性的重要保障,本文将分享58集团监控业务实践.总体工作思路是将网站运行信息透明化,按照各项工作的重要性分步骤构建起立体化的监控体系.首先解决稳定性问题,再解决网站优化和节约成本的问题,有利于在短期内快速取得收益.

主要内容如下：

• 监控系统的业务定位
• 监控系统的核心需求
• 监控系统的应用规模
• 如何在监控方面快速取得收益

业务定位??

监控业务的定位可以概括为：线上服务的守护神,是服务稳定性的重要保障.

1、监控系统是运维和研发人员的眼睛,可以快速发现和排查故障.

2、监控系统将运维数据进行量化和可视化,便于对网站优化.

核心需求??

监控业务的核心需求可以概括为：通知异常、发现故障、追查故障、预防故障、优化网站.

?? ?1 .有效的告警(通知异常)

在监控系统发现异常后,通过告警信息通知相关负责人.这就要求告警的有效性,有效性体现为：发生故障时要发出告警；确定是需要处理的异常才发送告警；告警数量要控制在合理范围内,可以深入跟踪和处理,每天大量的告警和没有告警是一样的,不会引起重视；告警信息中明确说明异常的相关信息,通过告警可以明确知道出现了什么异常,情况有多严重；告警要根据重要性分级,使用不同方式通知异常,重要的告警使用语音送达,确保告警信息引起重视.

?? ?2. 数据可视化(发现故障)

监控数据可视化有助于快速发现问题.在用户收到告警后可以快速查看到相关的监控数据变化趋势,从数据上分析、定位问题.可以在告警信息中加入链接,点击后直接跳转到相关的监控数据视图,这样能够减少查询监控数据的时间.另外,对于用户的个性化数据可视化需求,可以添加自定义的监控视图,将自己关注的指标添加进去.对于网站的重点服务和核心监控指标,将监控视图配置为“监控墙”进行展示,便于日常进行巡检和发现问题.

?? ?3. ? ?辅助排查故障(追查故障)

为了方便排查故障,除了基本的监控数据可视化外,还需要提供一系列功能对异常告警进行展示.监控系统中可以展示所有当前存在的异常,用户访问系统直接看到与自己负责服务相关的异常.用户还可以按照时间序列查看最近处于异常状态的事件,便于对关联的异常进行分析,推断故障根源原因.

为了方便了解网站在全局的运行状态,用户可以在全局视图中看到各模块的运行状态和模块之间的调用状态,当某部分出现问题时能够用突出的颜色标识出来.也可以定义服务之间的依赖关系,根据各服务之间的依赖关系自动分析故障的根源原因.

?? ?4. ? ?对告警做运营分析(预防故障)

为了预防故障,需要提供一系列功能对监控运营状况做数据分析.

运营分析有的服务于监控系统的运营人员,以便了解监控系统的运行和使用情况,发现问题及时进行内部调整和推动相关部门进行优化.例如：每天发送的告警电话、告警短信、告警邮件等的发送次数,及近期变化趋势.每天出现次数为TOP 10的异常类型、异常服务、异常集群、告警接收人、异常服务器等.

运营分析也服务于研发和运维部门的负责人.例如：相关负责人可以在web查看自己负责范围的异常事件信息,也可以通过邮件报表查看自己负责服务的告警次数和告警持续时间等.

?? ?5. ? ?网站系统透明化(优化网站)

通过所有服务必须包含的基础框架采集服务之间的调用链,构建全局系统架构视图.通过全局视图,用户可以看到各模块的运行状态和模块之间的调用状态,根据各服务之间的依赖关系自动分析故障的根源原因.另外,还能够及时发现系统内部的不合理依赖,对架构不合理情况进行改造.

应用规模

?? ?1. ? ?覆盖围范

覆盖58集团下网站：58同城、赶集网、中华英才网、安居客,转转.

覆盖网络、主机、系统、应用、业务等多个层级.

覆盖用户端、IDC出口、流量接入端、IDC内部服务端.

?? ?2. ? ?数据规模

我们的监控系统中通过自动和人工添加的方式配置了超过万台服务器和网络设备,3000余个集群,近3000个监控模板,300余万个监控指标,每天实时处理的数据量超过2T.

工作思路??

如果要提升网站的稳定性、对网站进行优化,那么监控是一个很好的切入点.我们的总体思路是按照各项工作的重要性分步骤构建起立体化的监控体系.首先解决稳定性问题,短期内快速取得收益.下面是一些具体步骤.

?? ?1. ? ?服务端基础监控

为了保证监控的覆盖度,首先要覆盖所有服务器的基础监控,例如：服务器是否宕机、系统资源的使用率是否过高等.由于监控的添加也是需要较大的工作量,很多运维和开发人员在此方面投入的精力有限,出现问题不能及时发现.

为了解决该问题,我们从CMDB系统同步了集群中包含的服务器、集群负责人等信息,在监控系统中配置默认模板、自动添加了基础的系统监控.这样,当出现服务器宕机、假死、硬件故障、系统资源使用过高、端口不通、JVM状态异常等情况,监控系统会发送告警给对应集群的负责人.通过这种方式,既不需要大量的人工配置,也能够快速提升服务器层面的监控覆盖率.

另外我们也积极推进应用层监控和业务层监控的添加,在监控系统上提供了快速添加监控的功能,保证用户能够以较小的代价方便添加监控.

?? ?2. ? ?流量接入端监控

在完成服务器的基础监控后,需要对服务是否正常进行监控.由于后端业务集群的数量非常多,逐个去添加服务的监控需要了解更多的业务信息,一般来说需要投入更多的时间和精力.

为了在短时间内解决应用服务的监控问题,我们首先保证所有流量都经过nginx集群进行分发,通过elk实时收集nginx的日志,然后按照域名和后端集群维度分别获取错误率和响应时间.域名维度的监控更关注返回给用户的错误率和响应时间；后端集群维度更关注后端集群出现的错误率和响应时间.

通过这种方式,我们可以对各业务集群的状况进行监控,故障时能快速缩小排查的范围.

?? ?3. ? ?页面监控

通过前面的工作,已经能够对服务器级别和重要的后端集群进行监控了,一般较大的故障已经能够及时发现了.

（编辑：ASP站长网）