77

我们正在完成我们的 Web 应用程序并计划部署。部署到生产的非常重要的方面是监控系统的健康状况。拥有一个由开发人员/支持组成的小型团队对于我们来说非常重要的是，尽早收到潜在问题的通知并在它们对用户产生影响之前解决它们。

使用 Nagios 接缝是一个不错的选择，但想获得更多关于一般 Web 应用程序特别是 Django 应用程序的最佳监控工具/实践的意见？除了明显的 CPU、内存、磁盘空间、数据库连接之外，还欢迎就应该监控的内容提出建议。

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

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

编辑 我们正在使用 django-logging，所以我们有一种方法可以分离信息、错误、关键问题等。

4

17 回答 17

38

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

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

可能有一个测试套件系统可以为您保持对所有内容的压力测试。我不记得我头顶上的名字了，也许有人可以在下面提到一个。

我喜欢做的其他事情：

基础设施的最佳座右铭始终是修复、检测、修复。抓住它，找到它的根源，如果可以的话，治愈/预防它。

由于一个系统存在于多个层次，我们应该在多个层次上进行测试：

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

1)连接：从服务器和外部监控您的互联网连接。在某处记录这个

2)服务器：监控所有需要确保它们正在运行而不是固定服务器的进程。使用 HP 服务器或具有硬件故障通知功能的等效设备，它可以从 bios 级别执行。如果是，请通知并记录。

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

4）远程电源：确保远程电源重置功能在您手中。如果您曾经使用 Windows 进行任何操作，您可能需要安排每周重新启动。

5）业务逻辑测试：定期运行脚本测试系统的工作流程。Selenium 可能可以实现其中的一些，但我也喜欢记录结果以说明此时运行并且这些文件有错误。如果可能，请让系统通过脚本自行监控。

6)备份：做一个你可以设置和忘记的备份。如果您可以将东西放入虚拟机中，那将是理想的选择，因为您可以在任何地方扩展、移动或部署基础架构的任何部分。我曾经有过这样的例子，我将一个死机的服务器移到我的笔记本电脑上，让它在我修复问题的同时在 vmware 中运行。

于 2009-01-30T16:39:10.067 回答
13

监视与您的 Web 服务器和数据库的连接数是另一件值得跟踪的好事情。很有可能，如果有人从屋顶射出，那么某些东西正在缺乏资源，并且该站点即将倒塌。

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

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

于 2009-01-30T16:55:13.637 回答
12

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

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

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

于 2009-02-01T20:44:56.637 回答
8

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

本质上，您需要一种方法来检查应用程序的内部状态，无论是在特定时刻还是在一段时间内（后者对于在问题发生之前检测到问题非常重要）。另一种思考方式是美化单元测试。

我们有自己的（非常好的）监控系统，所以我不能评论 Nagios 或其他应用程序。不过，我们的用例与您的类似（apache 上的 cgi 应用程序）。

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

这都是相当高的水平。重要的是您拥有应用程序状态随时间变化的历史记录。从此，您可以创建规则（也许只是您放入某个配置的原始 sql 查询），例如“如果每秒查询数翻倍，则发送 SlashDotted 警报”或“如果 50% 的响应是 404，则发送警报”。它还使管理人员眼花缭乱，因为您可以量化任何关于它是向上、向下、快速还是缓慢的评论。

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

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

于 2009-02-01T21:17:01.423 回答
6

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

于 2009-01-31T14:58:25.743 回答
5

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

我唯一的其他建议是我不会在这上面花太多时间。我最好的例子是推特，他们在系统中投入了多少精力才能半死，而不是仅仅将时间和精力投入到投入更多硬件/扩大规模。

机会是最终让你失望的东西，你的日志记录和健康系统无论如何都会错过。

于 2009-02-04T18:59:46.457 回答
4

监控任何在线站点的最重要的方法是外部监控。目标应该是以最能反映您的用户如何使用该网站的方式来监控您的网站。在 99% 的情况下，一旦您知道您的网站在外部出现故障，就相对容易找到根本原因。最重要的是尽快知道您的客户无法加载您的网站。

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

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

祝你好运！

于 2009-02-08T00:38:01.153 回答
3

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

于 2011-08-14T13:16:06.907 回答
2

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

于 2009-01-30T16:39:46.663 回答
2

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

在支持/开发团队之间分配待命轮班，这样就不必每天晚上都值班。那会让人们失望。监控是一件好事，但每个人都需要偶尔获得一次生活的机会。你的手机在凌晨 2 点嗡嗡响了几个晚上很快就会变老，相信我。并不是每个开发人员都习惯于 24/7 支持，因此您需要在使用监控和滥用监控之间找到平衡。

基本上，有不同的升级级别，如果天空没有塌陷，请在夜间定义一个“现在宁静”窗口，较小的升级级别不会消失。

于 2009-02-01T20:31:14.027 回答
2

我一直在使用Nagios + CruiseControl + Selenium在关键任务 Web 应用程序上运行高级测试。一个简单的 jquery 错误阻止了用户通过在线注册表单进行操作，这让我感到非常难过。

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

于 2009-07-25T21:06:43.430 回答
2

你可以看看AlertGrid。此 Web 应用程序允许您过滤警报并将警报转发给您的团队（全球）。如果某事没有发生，它也有很好的监控能力。

于 2010-10-04T21:08:16.400 回答
1

套用 Richard Levasseur 的话说：啊，监控工具，你的不完美让我很沮丧。那里似乎没有完美的工具。Nagios 很容易设置，但 UI 有点过时，你必须在每台被监控的服务器上运行一个守护进程。 Zenoss有一个更好的 UI，包括资源使用趋势图，但它使用 SNMP，所以你必须熟悉它才能使其正常工作，而且文档不是最好的 - 有数百页，但真的很难只需找到您开始所需的信息。

我的朋友也推荐过Cacti和Hyperic，但我没有个人经验。

最后一件事 - 其他答案之一建议运行一个对您的网站施加压力的工具。我不建议在您的实时站点上这样做，除非您有一个可靠的安静期，没有人打它；即使那样，您也可能会意外地将其降低。拥有一个登台服务器要好得多，您可以在其中运行负载测试，然后再将更改投入生产。

于 2009-02-04T18:54:49.757 回答
0

我们的一位客户使用 Techout (www.techout.com) 并对服务非常满意。

警报是免费的，无论种类或数量，它们提供电子邮件、语音邮件和短信警报——如果发生重大事件，现场人员会打来电话帮助您。

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

于 2009-04-07T16:47:14.910 回答
0

我只想补充一点，您可以根据过去错误的历史并修复它们来预测错误的可能性。通过小规模的内部测试，如果您要绘制已纠正到这一点的问题的频率和严重性，您将对可预测的新问题有一个概览。如果一段时间以来一切都运行无错误，那么问题的两个来源将是最近的更改或可伸缩性问题。

从上面看来，可扩展性是你唯一担心的问题，但我只提到过去错误频率测试，因为我所在的团队总是认为他们已经修复了最后一个错误，并且没有更多错误。直到有。

于 2009-06-09T17:10:08.813 回答
0

稍微改变一下这条线，我真的认为这是有用的，并且改变了我监控我的应用程序的方式是在某处记录 javascript 异常。有一个非常好的实现，可以直接从用户浏览器记录到 Google Analytics。这对于以 Javascript 为中心的 Web 应用程序来说是必须的，并且可以直接根据用户浏览器为您提供结果，这可能会导致非常意外的错误（iE 和移动浏览器很痛苦）

免责声明：我的帖子如下

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

于 2011-04-14T12:01:16.210 回答
-1

对于互联网存在监控，我建议我正在开发的服务：Sucuri NBIM（基于网络的完整性监控）。

它进行可用性和完整性检查，查找您的 Internet 存在（站点、DNS、WHOIS、标头等）的变化和连接丢失。它是免费的，您可以在这里试用。

于 2009-05-13T15:10:23.607 回答