×

微信扫一扫,快捷登录!

如何做好分布式系统的监控

标签: 暂无标签
Google的SRE团队在构建监控系统和报警系统方面遵循一些核心思想和最佳实践。本章在决定何时需要人工干预(发出紧急警报)的问题上提供了一些指导意见,同时也讨论了如何应对那些不那么严重的警报。


在讨论监控系统时,目前几乎没有通用的术语。即使在 Google内部,不同的团队也在使用不同的术语,以下是绝大部分通用的术语。


监控(monitoring)
收集、处理、汇总,并且显示关于某个系统的实时量化数据,例如请求的数量和类型,错误的数量和类型,以及处理用时,应用服务器的存活时间等。


白盒监控(white-box monitoring)
依靠系统内部 的一些性能指标进行监控。包括日志分析、Java 虚拟机提供的监控接口,或者一个列出内部统计数据的 HTTP接口进行监控。


黑盒监控(black-box monitoring)
通过测试某种外部用户可见的系统行为进行监控。


监控台页面(dashboard)
提供某个服务核心指标一览服务的应用程序(一般是基于Web的)。该应用程序可能会提供过滤功能(fiter)、选择功能(selector)等,但是最主要的功能是用来显示系统最重要的指标。该程序同时可以显示相应团队的一些信息,包括目前工单的数量、高优先级的 Bug列表、目前的on-call工程师和最近进行的生产发布等。


警报(alert)
目标对象是某个人发向某个系统地址的一个通知。目的地可以包括工单系统、E-mail地址,或者某个传呼机。相应的,这些警报被分类为∶工单、E-mail警报"',以及紧急警报(page)。


根源问题(root cause)
指系统(软件或流程)中的某种缺陷。这个缺陷如果被修复,就可以保证这种问题不会再以同样的方式发生。某一个故障情况可能同时具有多个根源问题∶例如,有可能自动化程度不够,软件在异常输入下崩溃,以及对生成配置文件的脚本测试不足等。这里每一个因素都是一个根源问题,并且每一个都需要被修复。


节点或者机器(node/machine)
这里的两个术语是可以互换的∶指在物理机、虚拟机,或者容器内运行的某个实例。某个单独的物理机器上可能有多个服务需要监控,这些服务可能具有如下特点。

● 相互关联的服务∶例如 Web 服务器与对应的缓存服务器。
● 不相关的服务,它们仅仅共享硬件∶例如代码仓库和把文件存放在代码仓库中的配置管理系统的主进程。例如Puppet( /puppet/puppet-open-source)和 Chef( /chef/)。


推送(push)
关于某个服务正在运行的软件或者其配置文件的任何改动。





上一篇:琐事繁多是不是一定不好呢?
下一篇:为什么要对分布式系统进行监控
姚明

写了 298 篇文章,拥有财富 1569,被 5 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

Powered by IT 运维管理
返回顶部