58集团监控业务实践：将网站运行信息透明化
|
为了更好的发现一些重要的异常,我们还通过IDC出口的VIP对页面进行监控,当IDC的出口链路故障或者后端集群出现故障时能够及时发现.该监控发现的故障是重要性较高的故障,当监控发现异常时,外部用户已经能够发现访问异常.通过这些监控数据也能够综合评估页面的可用性和响应时间. ?? ?4. ? ?网络监控在网络监控上还需要对VIP的可用性、流量等进行监控,确保及时发现链路的异常.还要对各IDC之间的专线和IDC内部的网络进行监控,及时发现问题、进行优化. ?? ?5. ? ?数据可视化经过前面几步,监控的覆盖率已经比较高了,系统的异常已经基本都可以发现.那么为了更方便的查看监控数据、排查异常,需要将监控和告警的数据进行可视化. 监控数据可视化：可以方便的通过服务器的IP、集群名等方式快速查看相关服务器的监控指标变化趋势,从而发现故障原因.另外,为了方便查看常用的监控视图,还可以定制监控视图和监控墙,方便日常进行巡检. 告警数据的可视化：为了方便用户查看自己负责服务的异常,提供了多种角色视图及搜索功能便于查看.为了方便排查相关服务的异常,还提供了按照时间轴组织的监控异常事件展示功能,在某个服务的故障时间点附近可能有依赖服务的异常告警,从而方便用户快速定位故障的根源原因. ?? ?6. ? ?用户端监控由于用户处于各个地域、各个运营商中,用户的访问速度和用户体验受公网的影响,与local DNS的解析、CDN的流量调度、CDN节点状态、链路劫持等都有很大的关系.为了评估用户真正的用户体验、及用户网络的异常,需要通过第三方的APM或页面中的js收集数据在用户端进行监控. ?? ?7. ? ?运营分析有了前面的监控数据,能够从多层次、多维度进行运营质量分析,例如：
?? ?8. ? ?容量管理容量管理也是与监控业务相关联的,可以先从服务器负载开始做容量管理. 通过监控数据和服务器负载计算模型可以计算各事业群、业务线、集群的负载情况.从而简单、有效的评估负载情况,据此做服务器采购预算和分配,节约成本. 在此基础上,可以对服务集群的极限容量进行测试和评估,做性能瓶颈分析、容量预警、弹性伸缩等. 最后我们总结一下,如果面对一个不是很稳定的站点,那么从何入手呢? 首先可以先将监控搭建、完善起来,保证将重要的告警发送出来、且控制告警的数量.对关键服务的监控包括通过nginx的日志对后端集群进行监控,在IDC的出口对页面进行监控. 然后通过人工或自动化的方式逐渐提高监控的覆盖率,辅助以监控数据可视化、监控异常排查工具等方式缩短排查故障的时间.在保证了服务端比较稳定的基础上,再对用户端的访问情况进行监控.有了这么多的监控数据,就可以做一些运营分析,及时发现相关的问题、进行优化. 最后可以基于监控数据深入的做容量的管理,提升资源使用率、降低成本等. QA环节Q1：银行业务系统如何监控,用哪些技术个软件? A1：银行业务系统的监控思路和互联网系统的思路是一致的.关键还是看：希望发现哪些异常?这些异常有哪些特征?如何采集这些特征?如何判断异常?在具体的技术和实现上都是类似的.可以自己开发、也可以选择开源软件,还可以购买一些厂商的产品. Q2：你们的精细化监控是如何实现?需要把监控嵌入到业务上吗,比如：监控业务异常(进程还在,程序报致命异常)是如何实现? A2：我们希望采用的是尽可能通用、尽可能对业务代码侵入少的方式进行监控,这样会减少业务添加监控的代价.有如下几种方式： 1、在Nginx上对后端集群的错误率和响应时间进行监控.这样可以在整体上发现后端集群的异常. 2、在监控agent上部署插件,对服务型程序的接口进行探测,判断返回数据的格式和内容是否正常. 3、更精细的监控是开发一个公共库,所有代码在编译打包的时候都要包含该库.该公共库会自动采集程序内部的信息发给监控系统.具体对监控指标精细化到什么程度,就可以根据需求对公共库进行开发. Q3：pc端有什么好办法防缓存和劫持吗? A3：网站使用https防止劫持还是有一定效果的.为了更好的解决劫持,还是要通过多种方式采集用户端的数据,及时发现劫持,才能更好的给出解决劫持的对策.防止缓存需要根据需要调整好HTTP头中的缓存策略. Q4：龚老师 您好 请问你们的监控平台是监控日志吗??有没有使用ELK? A4：我们的监控系统不只是监控日志,也在服务器上部署了agent采集相关的信息.在“流量接入端(Nginx)”的监控里,我们使用了ELK,实时采集Nginx的日志,分析后端集群的运行状态. Q5: 告警收敛怎么做比较好呢?貌似不太好在精准与效率之间取得平衡 A5：告警收敛最重要的是保证告警的准确性.如果有告警一定是出了问题,而且需要人去处理.告警数量太多和没有告警几乎是一致的,因为都没法及时的追踪和处理.告警收敛也有很多方法,例如：连续多次异常才告警,过滤掉短暂的异常；告警最多发送3次,恢复正常后再报1条正常,减少告警数量；连续2条告警之间间隔5分钟,确保不会频繁的打扰在处理问题的人员；设置合理的告警阈值；设置合理的告警接收人和告警方式等. Q6: 有什么开源的监控软件推荐吗?请问你龚老师,你们的监控系统是自己开发的还是开源的,使用到哪里技术和工具? A6：强烈推荐Open-Falcon,尤其适合有大规模服务器的互联网公司,它的功能、性能、可扩展能力都是很强的,也非常适合做二次开发.对于服务器数量较少的公司,由于Open-Falcon的模块较多,部署起来略微复杂,可以简单的使用Zabbix. 我们的监控系统是在Open-Falcon的基础上做的二次开发,在功能上对很多前端和后端模块都进行了大量的优化.基本的架构和Open-Falcon类似,只是根据我们的需求增加了一些模块. Q7: 监控界面,常见的告警指标可以展示下吗? （编辑：宁德站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
