Web应用程序监视最佳实践

我们正在完成我们的Web应用程序并计划部署.部署到生产的非常重要的方面是监视系统的健康状况.拥有一个小型的开发人员/支持团队,对于我们来说,获取潜在问题的早期通知并在对用户产生影响之前解决这些问题非常关键.

使用Nagios接口是一个很好的选择,但是想要获得更多关于Web应用程序的最佳监控工具/实践的意见,特别是对于Django应用程序？除了显而易见的CPU,内存,磁盘空间,数据库连接之外,还欢迎有关应该监控的内容的建议.

我们的Web应用程序是用Django编写的,我们使用PostgreSQL数据库在Apache + Fast CGI下运行Linux(Ubuntu).

编辑 我们在Linode下有一个完全虚拟化的环境.

编辑 我们正在使用django-logging,所以我们有一个单独的信息,错误,关键问题等方式.

Nagios很好,可能正常运行系统测试(Selenium).

编辑:Hyperic和Groundwork也很有趣.

可能有一个测试套件系统可以为您保持压力测试.我不记得我头顶的名字,也许有人可以在下面提一个.

我喜欢做的其他事情:

基础设施的最佳座右铭始终是修复,检测和修复.得到它,找到它的根源,并在可能的情况下治愈/预防它.

由于系统存在于多个层面,我们应该在多个层面进行测试:

编辑:通过电子邮件将所有错误或警告直接发布到您的案例管理员.这样您就可以在一个地方跟踪事件.

1)连接:监控来自服务器和外部的互联网连接.记录这个地方

2)服务器:监控所需的所有进程,以确保它们正在运行而不是固定服务器.使用HP服务器或类似的硬件故障通知,它可以从BIOS级别执行.通知并记录它们是否存在.

3)软件:识别始终需要运行的关键软件.设置性能级别(如果有),然后监视它们.Nagios应该能够帮助解决这个问题.在Windows上它可以多一点.发生异常时,您应该能够从中运行脚本以自动重新启动进程.我的梦想系统允许我通过短信与服务器进行交互,如果服务器将其视为我必须允许的例外,或者除非我通过短信取消,否则将自动发生.一天..

4)远程电源:确保您手中有远程电源复位功能.如果你曾经使用过任何窗户,你可能想要安排每周重新启动.

5)业务逻辑测试:定期运行脚本测试系统的工作流程.Selenium可能会实现其中一些,但我喜欢记录结果,并说这次运行并且这些文件有错误.如果可能的话,让系统通过脚本监控自己.

6)备份:进行备份,您可以设置并忘记.如果您可以将其置于虚拟机中,那么它将非常理想,因为您可以在任何地方扩展,移动或部署基础架构的任何部分.我有一些实例,我将死了的服务器移到我的笔记本电脑上,让我在修复问题的同时在vmware中运行.

监视Web服务器和数据库的连接数是另一个需要跟踪的好事.如果一个人从屋顶射击,有些东西正在寻找资源而且该网站即将倒塌.

还要确保您定期请求URL,这是对系统进行合理的端到端测试.如果您的站点支持搜索,那么让nagios执行搜索 - 这应该确保搜索索引是健康的,Web服务器和数据库服务器.

此外,请确保您的应用程序在用户看到错误或任何未处理的异常时随时向您发送电子邮件.这样你就知道应用程序在现场失败了.

如果我必须选择一种类型的测试,那就是测试系统的最终用户功能.需要考虑的重要事情是用户.虽然测试数据库可用性,服务器正常运行时间等等都非常重要,但通过远程UI测试系统测试工作流程涵盖所有这些基础.如果您知道最终用户可以使用系统的关键部分,那么您就知道您的系统非常好.

确定系统中的重要工作流程. 例如,如果您编写了电子商务网站,则可能会确定"搜索产品,将产品放入购物车以及购买产品"的工作流程.

优先考虑工作流程,并首先构建更高优先级的测试. 在推广到生产之后,您始终可以添加其他测试.

使用一个可用的UI测试框架构建UI测试.有许多免费和商业UI测试框架可以以自动方式运行.首先构建一组核心测试,以解决关键工作流程.

设置至少一个运行测试的远程位置.您想要测试系统的每个方面,这意味着要远程测试它.互联网连接？Web服务器是否正在运行？与数据库服务器的连接是否有效？等等.如果您进行远程测试,请确保您的系统可供外界使用,这意味着它最有可能端到端地工作.您也可以在内部运行这些测试,但我认为在外部运行它们至关重要.

确保您的解决方案包括报告和通知.如果您的某个关键工作流测试失败,您希望有人知道它以尽快解决问题.如果非关键任务失败,您可能只需要报告,以便可以在带外修复问题.

这种最终用户测试不应该取消对数据中心系统的监控,但我想重申最终用户测试是您可以为Web应用程序执行的最重要的测试类型.

啊,监控.凌晨3点我爱你和你的振动.

从本质上讲,您需要一种方法来检查应用程序的内部状态,包括在特定时刻以及跨越时间跨度(后者对于在问题发生之前检测问题非常重要).另一种思考方式是美化单元测试.

我们有自己的(非常好的)监控系统,因此我无法评论Nagios或其他应用程序.我们的用例与你的用例类似(cache app on apache).

添加logging.monitor()类型方法,该方法将信息记录到磁盘.这至少应该支持记录简单的数字和数字序列(key => value association可以非常方便).

有一个进程可以擦除监视日志并将其存储到数据库中.

拥有一个获取数据库信息,根据规则检查它们并发出警报的进程.请记住,有些东西可能是片状的.只是因为你有404 次并不意味着应用程序下来.

有办法静音警报(非常有用于维护或阅读您的电子邮件).

这都是相当高的水平.重要的是,您随时间了解应用程序状态的历史记录.从这里,您可以创建规则(可能只是您在某处配置的原始SQL查询),说"如果每秒查询加倍,发送SlashDotted警报",或"如果50%的响应是404,请发送一个警报".它还可以管理因素,因为您可以量化关于其上,下,快或慢的任何评论.

要监视的内容包括(其他人可能也提到了这些):http状态,端口可访问,http加载,数据库加载,打开连接,查询延迟,服务器可访问性(ssh,ping),每秒查询数,工作进程数,错误百分比,错误率.

简单的端到端测试也非常方便,但它们可能很脆弱.最好保持简单,但你应该有一个尝试触摸应用程序的核心部分(缓存,数据库,身份验证).

我使用Munin和Monit,对他们两个都非常满意.

内部日志记录很好，但当您的整个应用程序崩溃或盒子/环境崩溃时，您也需要进行外部检查。 http://www.pingdom.com/对我来说非常可靠。

我唯一的其他建议是我不会在此上花费太多时间。我最好的例子是推特，他们投入了多少能量来半死，而不是仅仅花费时间和精力投入更多的硬件/进行扩展。

最终可能使您失望的是，无论如何您的伐木和卫生系统都将丢失。