aiCache:自动监测和报警机制
虽然通过CLI,SNMP和Web端口,aiCache都可以监测和解决问题,并提供一系列丰富的统计数据和测试报告,但我们认使用SNMP作为制表,报告和历史记录的分析(如果您的软件支持的话)最为理想。
aiCache提供的自动报警机制可以充分简化问题,使你为一天的工作做好准备。通过进行设置,我们可以监测许多重要的参数。当aiCache发现与配置不符的参数时,则自动生成警报邮件发送到您的邮箱。
邮箱里警报泛滥的情形并不少见。显然,过多非“重点”的警报往往使技术人员要么失去耐心,不以为然,要么在警报的海洋里消耗大量不必要的时间。幸好,aiCache会非常慎重地生成每一份警报警,以防止这种情况发生。
事实上,aiCache每分钟至多生成一份警报。当大量错误发生时,它们会被收集到一起发送。一切恢复正常后不会再有邮件发送给您,没有邮件就表示一切顺利。
警报一共有两种——全局警报,或是针对某网站具体情况的警报,每种都可以单独设置邮箱地址。全局警报的内容包括一份整体出错情况报告及此时所有各个错误站点的情况报告。
我们可以举一个例子来说明这点。假设我们用aiCache加速三个站点——news.acme.com,video.acme.com和boards.acme.com,那么无论何时,只要检测到其中某一站点出现问题,都会发出全局警报,同时还会生成一份具体出错站点的警报发给对应的网站管理团队。当任何一个站点出现状况时,你都可以向deskhelp寻求帮助。警报会被分别送到自己的组,如boards.acme.com的问题会汇报给boards团队解决,以此类推。
这样可以保证你不会将问题提交给错误的团队,即使在共享的托管状态时也不会将隐秘的信息泄露给其他用户。
下面是一组发出全局警报的情况以及假设的数值:
alert_bad_req_sec 20
alert_max_cache_entries 10000
alert_client_conn_max 30000
alert_client_conn_min 5
alert_os_conn_max 20
alert_os_fails_sec 2
alert_req_sec_max 2500
alert_req_sec_min 10
alert_os_rt 200
下面是一组发出某个具体网站警报的情况及假设的数值:
alert_max_cache_entries 10000
alert_os_fails_sec 2
alert_req_sec_max 2500
alert_req_sec_min 10
alert_os_rt 200
此外,当检测到任何一个无法工作的原始服务器时,全局警报和具体某个网站的警报都会生成。当你尝试恢复系统时,aiCache会把一个没有通过健康检查(health check)的原始服务器关掉。但如果您对网站没有设置健康检查的话,就发现不了无法通过检查的服务器。因此,如果您希望得到原始服务器无法工作情况的警报,请务必设置健康检查。
状况设置的名称是自定义的,但下面有一些速成建议：
一,务必要通过配置警报参数“alert_os_rt”以检测原始服务器的响应时间,这样一旦原始服务器速度慢下来,你就会收到警报。
二,建议通过配置警报参数“alert_max_cache_entries”对缓存响应的数量进行检测。当缓存响应的数量大大地超过设定值,提醒您注意,可能是进行参数丢弃或忽视一些URL的查询字符串的时候了。
三,建议配置警报参数“alert_os_fails_sec”,以发现原始服务器停机或瘫痪的状况。一般而言,高得反常的数值暗示原始服务器,应用程序或DB服务器及其它后台基础设施存在严重问题。你还需要设置“alert_os_conn_max”,以反映原始服务器连接数。如果连接数量持续显著上涨往往也暗示着前面类似的问题。
四,建议配置警报“alert_req_sec_max”和“alert_req_sec_min”,以检测每秒的用户请求数,过高或过低都可能暗藏问题或一个值得注意的情况。(比如用户大量减少,uplink连接,含病毒内容等)
五,建议配置“alert_bad_req_sec”以监测每秒的恶意请求。如果数值过高,可能说明你受到了DoS攻击,收到了很多不完整的或虚假的连接。要为所要的站点定一个合适的默认值非常困难,所以我们建议你针对自己的情况来一步步具体设定每一个值。
最后,通过对全局警报和和单个具体网站警报设置alert_humane指令,aiCache会在午夜自动关掉警报,早上七点自动打开,保证您的技术员工们忙碌一天后能睡一个好觉!这对他们来说很可能是努力工作后特别嘉奖呢!
一般在每天凌晨到早上七点,网络中对服务器的请求会大幅下降。所以这项功能还有一项重要意义——避免因这段时间内每秒请求数和客户连接数过低而生成警报。