Web应用程序监视最佳实践

我们正在完成Web应用程序并计划部署。部署到生产中非常重要的方面是监视系统的运行状况。拥有一小组开发人员/支持人员使我们非常重要，要及早收到潜在问题的通知，并在它们对用户造成影响之前加以解决。

使用Nagios接缝是一个不错的选择，但是想获得更多关于Web应用程序，尤其是Django应用程序的最佳监视工具/做法的意见。也欢迎就明显的CPU，内存，磁盘空间，数据库连接性之外应该监视的内容提出建议。

我们的网络应用程序是用Django编写的，我们在Linux（Ubuntu）上以Apache + Fast CGI和PostgreSQL数据库运行。

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

编辑 我们正在使用django-logging，因此我们有一种将信息，错误，关键问题等分开的方法。

Nagios很好，也许定期运行系统测试（Selenium）很好。

编辑：Hyperic和Groundwork也看起来很有趣。

可能会有一个测试套件系统，可以对您的所有内容进行压力测试。我不记得这个名字了，也许有人可以在下面提一个名字。

我喜欢做的其他事情：

基础架构的最佳座右铭始终是修复，检测和修复。启动它，找到它的根源，并尽可能治愈/预防它。

由于系统存在于多个级别，因此我们应该在多个级别进行测试：

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

1）连接：从服务器和外部监视您的Internet连接。将此记录在某处

2）服务器：监视所需的所有进程，以确保它们正在运行并且不固定服务器。使用HP Server或具有硬件故障通知功能的等效产品（可以从BIOS级别执行此操作）。通知并记录是否存在。

3）软件：确定始终需要运行的关键软件。设置性能水平（如有），然后对其进行监控。Nagios应该能够提供帮助。在Windows上可能更多。发生异常时，您应该能够从中运行脚本以自动重启进程。我的梦想系统是允许我通过SMS与服务器交互，如果服务器将其视为我必须允许的例外，或者除非我通过短信取消，否则它将自动发生。一天..

4）远程电源：确保您拥有远程电源重置功能。如果您曾经使用Windows执行任何操作，则可能希望安排每周重新启动。

5）业务逻辑测试：定期运行脚本来测试系统的工作流程。Selenium可能可以实现某些目标，但是我也喜欢记录结果，以说这次运行了，并且这些文件有错误。如果可能的话，请让系统通过脚本监控自身。

6）备份：进行备份，您可以设置并忘记该备份。如果您可以将内容放入虚拟机，则可以在任何地方扩展，移动或部署基础架构的任何部分，这将是理想的选择。我遇到了将死服务器移到笔记本电脑上的情况，在解决问题时让它在vmware中运行。

监视与Web服务器和数据库的连接数是另一件事。如果有人通过屋顶射击，则可能会出现资源短缺的情况，而该场地将要倒塌。

另外，请确保您有对URL的常规请求，这是对系统的合理的端到端测试。如果您的站点支持搜索，则让nagios执行搜索-应确保搜索索引运行正常，即Web服务器和数据库服务器。

另外，请确保您的应用程序在用户看到错误或有未处理的异常时随时向您发送电子邮件。这样，您就知道应用程序如何在现场失败。

如果必须选择一种测试类型，那就是测试系统的最终用户功能。要考虑的重要事项是用户。尽管测试数据库可用性，服务器正常运行时间等都很重要，但是通过远程UI测试系统测试通过系统的工作流程涵盖了所有这些基础。如果您知道系统的关键部分可供最终用户使用，则说明您的系统完全可以。

1. 确定系统中的重要工作流程。 例如，如果您编写了一个电子商务网站，则可能会确定“搜索产品，将产品放入购物车并购买产品”的工作流程。
2. 确定工作流程的优先级，并首先构建更高优先级的测试。 投入生产后，您始终可以添加其他测试。
3. 使用可用的UI测试框架之一构建UI测试。有许多可以以自动化方式运行的免费和商业UI测试框架。首先建立一组核心测试，以解决关键的工作流程。
4. 设置至少一个远程位置，从该位置运行测试。您想测试系统的各个方面，这意味着要对其进行远程测试。互联网连接正常了吗？Web服务器是否正在运行？与数据库服务器的连接是否正常工作？等等，如果您进行远程测试，请确保您的系统对外界可用，这意味着它很可能端对端运行。您也可以在内部运行这些测试，但是我认为在外部运行它们至关重要。
5. 确保您的解决方案包括报告和通知。如果您的关键工作流程测试之一失败了，您希望有人知道它，以尽快解决问题。如果非关键任务失败，则可能只希望报告，以便可以解决带外问题。

最终用户测试不应消除对数据中心系统的监视，但是我想重申一下，最终用户测试是您可以对Web应用程序执行的最重要的测试类型。

啊，监视。凌晨3点，我多么爱你和你的振动。

本质上，您需要一种方法来检查应用程序的内部状态，包括在特定时刻以及整个时间范围内（后者对于在问题发生之前进行检测非常重要）。另一种思考方式是美化的单元测试。

我们有自己的（非常好）监控系统，因此我无法对Nagios或其他应用程序发表评论。但是，我们的用例与您的用例相似（apache上的cgi应用）。

1. 添加logging.monitor（）类型的方法，该方法会将信息记录到磁盘。这至少应该支持记录简单数字和数字字典（key => value关联非常方便）。
2. 有一个过程可以抓取监视日志并将其存储到数据库中。
3. 有一个获取数据库信息，根据规则检查它们并发出警报的过程。请记住，某些东西可能会剥落。仅仅因为一次获得404并不意味着该应用程序就关闭了。
4. 有一种使警报静音的方法（对于维护或阅读电子邮件非常有用）。

那都相当高水平。重要的是您具有一段时间内应用程序状态的历史记录。由此，您可以创建规则（也许只是将原始sql查询放入某个配置中），例如：“如果每秒查询增加一倍，则发送SlashDotted警报”，或“如果50％的响应为404，则发送一条警报”。它也使管理感到震惊，因为您可以量化有关其上升，下降，快速还是缓慢的任何评论。

监视的内容包括（其他人可能也提到了这些内容）：http状态，可访问端口，http负载，数据库负载，开放连接，查询延迟，服务器可访问性（ssh，ping），每秒查询，工作进程数，错误百分比，错误率。

简单的端到端测试也很方便，尽管它们可能很脆弱。最好使它们保持简单，但您应该尝试使它们涉及应用程序的核心部分（缓存，数据库，身份验证）。

我使用Munin和Monit，并且对它们都很满意。

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

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

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

监视任何在线站点的最重要的一种方法是从外部进行监视。目标应该是以最能反映用户使用该网站的方式来监视您的网站。在99％的情况下，只要您知道您的网站外部出现故障，就很容易找到根本原因。最重要的是尽快了解您的客户无法加载您的网站。

这通常意味着使用外部性能监视服务。它们从非常低端（mon.itor.us，pingdom）到高端（Webmetrics，Gomez，Keynote）。和往常一样，您得到的是所支付的。到处购买监控服务时需要寻找的东西包括：

• 监控网络的规模和分布
• 监视解决方案是否能够使用真实的浏览器监视您的站点（否则，您将不会像真实用户那样对站点进行测试）
• 脚本语言（以脚本编写针对您网站的交易）
• 支持部门，一路为您提供帮助，并提供有关如何正确监控的专业知识

祝好运！

IP Patrol或SiteSentry的Web监视对我们很有用。第二个有点像网站的信心，但稍微漂亮一点。

您是否也考虑过监视功能？与您的应用程序对话并执行一些重要步骤（例如登录，购买等）的脚本（使用Perl或Pyton这样的脚本语言，或者使用WebTest这样的工具）是非常不错的。

除了要监视的内容（已回答问题）之外，您还需要确保-无论使用什么系统，都只能得到一个每次请求关于发生多次错误的通知。否则您的收件箱会用完内存:)另外，这很烦人...

将备用班次分配给支持/开发团队，这样一来，不必每个晚上都有一个人待命。那会让人们感到沮丧。监视是一件好事，但是每个人都需要有机会不时地生活。相信我，您的手机在凌晨2点嗡嗡作响的夜晚会很快变得很旧。并不是每个开发人员都习惯24/7全天候支持，因此您需要在使用监视和滥用监视之间找到平衡。

基本上，升级级别会有所不同，如果天没有落下，请定义“在晚上宁静”窗口，较小的升级级别不会消失。

我一直在使用Nagios + CruiseControl + Selenium在关键任务Web应用程序上运行高级测试。一个简单的jquery错误使我非常沮丧，该错误使用户无法通过在线注册表单进行操作。

http://www.agileatwork.com/the-holy-trinity-of-web-2-0-application-monitoring/

您可以看一下AlertGrid。此Web应用程序使您可以筛选警报并将警报转发给您的团队（全球）。它还具有很好的监视是否未发生事件的能力。

用理查德·莱瓦瑟（Richard Levasseur）来解释一下：啊，监控工具，您的缺陷如何使我感到沮丧。似乎没有一个完美的工具。Nagios的设置非常简单，但是UI有点过时，并且必须在每个要监视的服务器上运行一个守护程序。 Zenoss的UI更好，包括资源使用趋势图，但是它使用SNMP，因此您必须熟悉SNMP才能正常工作，而且文档也不是最好的-有数百页，但是要做到这一点确实很难仅找到您需要入门的信息。

我的朋友还推荐了Cacti和Hyperic，但我对这些没有亲身经验。

最后一件事-其他答案之一是建议运行一个使您的网站受压力的工具。我不建议在您的实时站点上执行此操作，除非您有一个可靠的安静时段，没有人打扰它。即使这样，您也可能会意外降低它。拥有一个登台服务器更好，您可以在其中将负载投入生产之前运行负载测试。

我们的一位客户使用Techout（www.techout.com），对该服务感到非常满意。

无论是哪种警报，警报都是免费的，并且它们会提供电子邮件，语音邮件和SMS警报-如果发生重大问题，请与真人打个电话为您提供帮助。

所有这些都是基于服务的-您无需安装软件，而是拥有一名顾问与您一起确定最佳业务方法。这是最方便的Web应用程序监视服务之一，因为它们可以处理所有事情。

我只想补充一点，您可以根据过去错误的历史记录并修复它们，从而在某种程度上预测错误可能性。使用较小规模的内部测试，如果要绘制到现在已纠正的问题的频率和严重性图表，则可以大致了解可预测的新问题。如果现在一切正常运行了一段时间，那么麻烦的两个根源可能是最近的更改或可伸缩性问题。

从上面看来，可伸缩性是您唯一需要担心的问题，但是我只提到过去错误频率测试，因为我一直在研究的团队始终认为他们已解决了最后一个错误，并且没有其他错误了。直到有。

稍微更改一下行，我认为确实有用，并且更改了我监视应用程序的方式，很多地方是将javascript异常记录到某处。有一个非常好的实现，可以直接从用户浏览器记录到Google Analytics（分析）。这对于以Javascript为中心的Web应用程序是必须的，并且可以直接基于用户浏览器为您提供结果，这可能导致非常意外的错误（iE和移动浏览器很痛苦）

免责声明：我的帖子如下

http://www.directperformance.com.br/zh-CN/javascript-debug-simples-com-google-analytics

对于Internet状态监视，我建议使用我正在从事的服务：Sucuri NBIM（基于网络的完整性监视器）。

它会进行可用性和完整性检查，以查找您的Internet状态（站点，DNS，WHOIS，标头等）是否发生变化以及是否失去连接。它是免费的，您可以在这里尝试。