监控
大型系统的运行离不开监控。网站监测是测试和验证终端用户使用网站或Web应用程序,以确保网站是运行和响应的。EBay等大型系统的设计经验中很重要的一条是容错设计(Design For Failure), 容错设计要求对出错的自动监测和报警。很多网络公司都安装了开源监测程序,比较常用的有Nagios ,Cacti, Ntop, Zabbix。在监测程序收集网络流量,服务器CPU和内存占有率等系统工作状况指标的基础上, 绝大多数公司同时安装了自动报警系统。报警系统可以根据系统出现的非正常状况对客户的影响范围和程度来设定报警的等级。Amazon内部结合开源程序开发了功能强大的监控报警系统,技术人员可以在问题发生的第一时间发现并解决问题,避免了对正常商业事务的影响。同时比较全面的监测数据也为技术人员在诊断系统故障时提供了重要的线索。
如上图所示,在监测数据的基础上定义不同的度量标准,在度量的基础上设定报警器。 以Amazon的AWS为例,报警器具有三个状态(正常,报警,无足够数据)。 当监控值在用户定义的许可范围内时,报警器处于OK状态;当监控值超出预设阈值,报警器进入ALARM状态并作出用户预先设定的反应(比如发出Page ,Email).。如果监测数据不全面或者没法获取,报警器的状态“无足够数据“。
监测对确保网站可用性,最大程度减少停机时间至关重要。如果网站经常停止工作会严重影响用户体验, 最终失去用户。 监测可以覆盖很多事情,常用度量指标是响应时间和可用性(正常工作时间),但一致性和可靠性指标越来越受欢迎。负载测试用来在各种流量下测试一个网站的可用性和可靠性。
下表是系统可用性和每年停机时间的换算。 对一些关键业务服务,每年的停机时间不能超过几分钟,可用性要求高达5个9(99.999%)。(Wikipedia)
可用性 |
俗称 |
每年的停机时间 |
90% |
n/a |
876 hours |
95% |
n/a |
438 hours |
99% |
two 9s |
87 hours, 36 minutes |
99.9% |
three 9s |
8 hours, 45 minutes, 36 seconds |
99.99% |
four 9s |
52 minutes, 33.6 seconds |
99.999% |
five 9s |
5 minutes, 15.36 seconds |
99.9999% |
six 9s |
31.68 seconds |
监测可以分为内部或外部监测,外部性能监控也被称为 终端用户监控 或者终端到终端的性能监控。对于网站监控,主要有综合监控(也称为主动监测)和被动监测(也称为实时监控)。综合监控使用模拟Web浏览器或脚本编程的Web浏览器, 模拟终端用户在网站上的浏览路径和行为, 然后在指定的时间间隔连续监测系统的可用性和响应时间等。综合监测使网站管理员迅速确定网站或Web应用程序是运行迟缓或停止工作,在问题影响到大范围实际用户之前得到解决。被动监测对解决性能问题是非常有帮助的。 现在大多数网络专业人士认识到,被动监测和综合监控是相辅相成的。
对程序开发人员而言,监测也可以分为系统水平的监测(System Logs, Firewall Logs,IDS/IPS Logs)和对应用程序运行状态的监测(Application Logs,Application Server Logs)两个层次。其中 Application Logs是程序开发人员控制的日志。
一。系统水平的监测 (System Monitoring, SM)
系统监测(SM)是在一个分布式的系统状态数据的收集和存储的过程。因为SNMP (简单网络管理协议)的低带宽要求和在业界的广泛支持度, 许多SM 工具使用SNMP从系统主机和设备为收集数据。 其他适合监控应用的协议 包CORBA (语言/ OS-独立),JMX(Java的管理和监控协议),或专用TCP / IP或UDP协议(语言/ OS独立的部分)。
SM中数据采集模式包括监视程序的轮询 (SM系统中的进程,周期性的查询被监测系统的状态),代理推送(被监测主机把数据从自身推送到监测管理程序),以及混合方案。选择不同的数据采集模式直接影响到SM的复杂度和对监控对象的负载。
网络设备的日志包括防火墙日志和IDS(入侵检测系统, Intrusion Detection System) 日志等。防火墙日志主要记录数据包的信息,IDS日志提供了可疑数据包信息。
常用的计算机系统监测指标包括OS资源监控中CPU占用率(CPU utilization ),内存页交换速率(Paging rate),磁盘交换率(Disk rate)等。 如果CPU占用率持续超过95%,或者SQL Server的值超过80-85% ,表明CPU是系统性能瓶颈;如果内存页交换速率值偶尔走高, 表明当时有线程竞争内存,如果持续很高,则内存可能是瓶颈,可能导致CPU占用率和 磁盘交换率增高,最终发生内存不够出错(out of memory errors) ;
Nagios是一个很受系统管理员欢迎的开源软件,监控计算机系统,网络和系统的基础结构。 Nagios为服务器,交换机,应用程序和服务同时提供了监控和警报功能(Wikipedia)。
监控网络服(SMTP,POP3,HTTP,NNTP,ICMP,SNMP,FTP,SSH)
监控大多数网络操作系统上的主机资源(处理器负载,磁盘使用情况,系统日志)。
通过插件接口监测第三方探测器(温度,报警等)
通过脚本远程监控, 支持SSH或SSL加密通道。
可扩展的设计,使用户通过简单的插件开发自己的服务
提供数据的图形化插件
提供监测的并行化服务
能够定义网络主机的层次结构,能够检测和区分那些无法访问的主机
警报系统。当服务或主机出现问题或者问题得到解决时,多途径(电子邮件,寻呼机,手机短信,或通过插件支持任何用户定义的方法)通知用户。
定义事件处理程序来自动解决问题
日志文件的自动轮换。
支持监控主机的冗余复制。
可选的Web界面查看当前的网络状态,通知,问题历史记录,日志文件等。
数据存储在文本文件中,而不是数据库。
Cacti 是另一种开源代码的网络监测软件,是非常受欢迎的RRDTool(附录有详细介绍)的前台应用程序。Cacti的一个常见应用是通过SNMP协议从网络交换机或路由器的接口读取数据来监控网络流量。主要功能包括 (Wikipedia):
强大的图形支持功能和图形模板
灵活的数据来源和数据模板
自定义的数据收集脚本
内置的SNMP支持
图形数据的树,列表和预览
基于用户的管理和安全性
二。应用程序运行状态的监测 (Application Performance Management, APM)
应用性能管理(APM)监控和管理软件的性能和可用性。和SM不同,APM的对象是应用程序本身, 直接反映IT在商业上的价值和对业务的影响。 APM运用工作流程和相关IT工具检测,诊断和报告应用程序的性能问题,以确保应用程序符合或超过终端用户和业务的预期(Wikipedia)。
应用程序的性能反应了程序通过一个特定的网络,应用程序和/或Web服务 完成交易,或者或信息传递到最终用户的速度。应用程序的性能评估方法主要有两种:应用程序所使用的资源和终端用户体验(用户在不同系统负载下的响应时间), 最终建立事务处理性能/响应时间(EUE),交易量 - (指标趋势),资源消耗(基础设施)三方面的性能基准线。
APM 的设置包括系统基本构架层,服务器和应用程序本身。下面介绍工作中
使用的几个模式。
(一)负载平衡器的应用程序健康测试。
负载平衡器通过Ping或者TCP connection来监测服务器是否正常工作,对不工作的服务员重新分配负载。Ping最简单也最不可靠,只能判断服务器是否正常工作,没法发现服务器正常运行而应用程序不工作的情况; 而且防火墙往往阻断ICMP Ping。 TCP connection 比Ping 更进了一步, 通过Telnet 和 服务器的 80 端口连接,而直接判断网站程序是否运行。
无论Ping还是TCP connection 都无法判断 应用程序涉及到真正业务的代码是否正常工作。 很多负载平衡器支持网络协议第7层负载平衡(Layer-7 Load Balancing)的应用程序健康测试: HTTP GET HEADER 和 HTTP GET CONTENTS. HTTP GET HEADER发出 HTTP GET 请求并检查HTTP返回的状态代码(是否为200)。 HTTP GET CONTENTS进一步检查HTTP返回的内容, 适合动态网页的监测。
在实际工作中, 为了获得更好的监测效果, 可以在系统构架水平上要求所有被监测的网络服务程序实现给定的API,并要求程序实现API时做一些实质性的内部功能检查。
BOOL CHECK_APP_STATUS()
CHECK_APP_STATUS 内部可以运行一个简单的数据库查询以检测数据层是否正常工作,如果查询成功,返回TRUE,否则返回FALSE。负载平衡器如果获得FALSE的查询结果,将视同于该服务器不能正常工作而将负载转移。
本文出自 “静水流深” 博客,转载请与作者联系!