如何选择适合您需求的网站监控工具

您被警报声唤醒，不确定时间，但外面很黑，当您开始恢复意识时，您会看到大量通知。

你的应用程序崩溃了，欧洲的用户非常不安。 一个小时过去了，没有备份，当您希望恢复正常时，您的客户服务经理会每 15 分钟尽职地询问一次。 你们两个看着团队的其他成员醒来，收到消息，并开始互相指责。

您认为，随着停机时间的第四个小时达到顶峰，整个情况都是可以避免的。 如果有什么东西警告我们即将到来的厄运就好了。

欢迎来到网站监控的世界，其中应用程序正常运行时间是主要指令。 也许这并不是你凌晨 3 点的火力下降的原因，但如果你在 DevOps 中幸存了这么久，你就有了——我们敢打赌，这并不令人愉快。

如果您的目标是最大程度地减少这种独特的痛苦，那么我们将通过易于浏览的指南帮助您减少待命工作，该指南列出了您在网络监控提供商中的需求。

选择网站监控工具的一站式指南

让我们从基础开始：监控和报告。 就像 1984 年的全能电幕一样，这里的监控是指对您的操作的“外部”监督。 外部探测服务器通常用于监控应用程序的状态。

问责制始于监督，或者更确切地说是可观察性。 根据您的基础设施告诉您的信息，您可以学到什么？

报告量化了你的责任，但好的报告是主观的。 有些人可能喜欢他们可以打包成任何格式的原始数据。 其他人希望交付自动化报告，有些人希望提供更直观的方法。 报告是监控的另一面，正确处理这两个元素将确保您的应用程序保持可访问性，并满足您的服务水平协议。

您对基础架构了解得越多，您从监控中获得的价值就越大。 提供商经常解析支票类型以保持低成本。 了解基础架构的 Web 监控需求是节省成本的一个很好的来源。

网络监控和报告问责制

监控不仅仅是让你的服务器侏儒在工作中睡着了，它应该告诉你更多，而不是服务是启动还是关闭。 通过性能指标，您可以清楚地了解基础架构的运行方式。 尤其是更高级的检查，例如真实用户监控 (RUM)——但稍后会详细介绍。

检查供应商的状态页面，并筛选他们之前 6 到 12 个月的中断数据。 供应商经常宕机吗？ 他们的整体正常运行时间和事件管理应该为他们的可靠性提供线索。

哪些网站监控检查类型最有用？

在选择供应商之前，您要评估您的需求。 回答这个问题，半夜什么会吵醒你？ 该基础设施应该是您在测试提供者时配置的第一批组件之一。

制定用于监控的攻击计划，并列出您必须拥有的服务。 提供固定计划的服务提供商在这里可以帮助或伤害。 好的计划会考虑使用它们的企业的规模。 询问您的升级和附加选项以自定义您的计划永远不会有坏处。

也许促使您搜索网络监视器的原因是 404 或 SSL 错误，但请给自己留出试验和成长的空间。 在您进行测试时，您无疑会找到其他方法来监控您的系统并使用您的支票分配。

基本检查及其网络监控功能

基本检查通常只做一件事，例如监控单个 URL 或检查 DNS 记录。 这些检查类型通常会提示某人搜索监控，通常是在发生中断之后。 做到这一点很重要。

HTTP(S)、SSL、DNS 和域到期是一些需要牢记的很好的基本检查，因为这些是最终用户倾向于感受到的中断类型。 这些检查也构成了大多数企业用户的监控支柱。 仅包含这些支票类型的计划是针对初创企业和小型企业的强大“入门”计划。

HTTP(S) 检查，有时称为“网络监控”，用于监控正常运行时间。 SSL、DNS 和域到期倾向于确保关键基础设施不会因可预防的原因而失败。 如果您的提供商还包括性能指标，那显然是一个好处。

确保您的提供商支持在您需要的地方发送警报。 如果您的 SSL 即将到期，最好摆脱官僚机构并将该通知直接放在可以支付续订费用的人面前，并有足够的时间让他们续订。 如果需要更多专业知识，问题可以自动升级给其他人，那就更好了。

每个 DevOps 团队都应考虑的高级检查

高级检查是一种使用真实用户数据或基于用户操作的操作。 这些复杂的检查类型通常需要一些设置工作。 对于使用它们的组织来说，回报可能是巨大的。

高级检查类型监督关键目标或导航渠道，例如登录或购买商品。 因为他们表现得像真实用户（或有时从真实用户那里获取数据），所以这些检查可以清楚地了解您的网站在各种条件下的性能。

为什么要花精力设置这些支票类型？

• 测试：在生成大量历史数据的同时了解新功能和升级的性能
• 第一反应：结帐页面出现故障可能意味着不止一个 HTTP(S) 检查失败。 什么失败以及何时失败是从何处开始诊断的良好指标。

让我们见见 James，看看多种支票类型是如何有用的：

James 正在为他的公司 Edgeco 推出一款新产品。 这项新服务将需要自己的安全证书以及新的基础设施。 James 将使用真实用户监控部署此服务，以便他了解更多有关早期用户体验的信息。 SSL 监控将确保当 James 转移到其他项目时，他的证书将有适当的保护措施，以确保不会忘记更新。

通过监控此 URL 的 HTTP(S) 检查，James 和他的团队在检测到停机时具有第一响应能力。 使用事务检查，James 可以测试关键的用户流程，例如登录新服务和使用其核心组件。

由于 James 部署了 Real User Monitoring，因此他的服务收集了他和他的团队在服务生命周期内所做的每一次更改的使用统计信息。 在六个月内，詹姆斯将有足够的数据来识别特定地区的绩效问题，并指导他的团队做出相应的改进。 多层检查有助于保护和简化复杂基础设施的管理。

网络监控软件必备

您已经确定了所需的支票类型，是时候开始比较这些不错的功能了，让您的生活更轻松一些。 这里有很大的区别，因为一些提供商提供状态页面或集成作为“高级”产品。

公开和私人报告

可见性很重要。 谁能看到？ 高管们会理解吗？ 公众可以访问吗？ 在中断期间，DevOps 可能会在内部和通过用户承受压力，因此可见报告是有价值的。

支持不是免费的。 每张支持票，即使是宏/快速响应，也需要时间。 有人必须提交工单，停止处理另一项任务并做出响应。 将您的用户群增加数十万或数百万用户，并且支持可能会失去一整天的生产力，发送相同的样板响应关于它是向上还是向下的问题。 可见报告创建了一个平台来回答问题并减少支持响应的压力。

第二个好处是消息传递，因为错误的新闻故事会破坏您的声誉。 当您在灾难面前，专注于透明度时，您就会成为新闻来源。 这比受点击引发争议的行业摆布要好得多。

易用性和价值

监控和报告的一切看起来都很棒。 安装成本如何？ 就像您的支持团队一样，您的工程师也不是免费工作的。 甚至测试提供商也需要设置成本，因此请花时间评估您的所有要求。

易用性是指从帐户设置到新用户入职的任何内容。 在试用期间，您可能会专注于基础知识并尽快启动和运行； 长期项目并考虑用户将如何与系统交互。

如果您要更换提供商，那么拥有导入/导出功能也很有帮助，您可以轻松地转移数百张支票。

单点登录软件 (SSO) 就是一个很好的例子，它为您的公司提供了一定程度的安全性，并使您的用户更容易采用。 支持文档和一般用途可以帮助您了解软件的可访问性。 您可能会考虑邀请其他用户尝试设置一些检查或检索报告，以从各个角度测试系统的工作方式。

定制和可观察性

让我们考虑一下普通的企业用例，其中 100 多个监视器并非不可能。 这种设置的报告是什么样的？ 海量，就是一个字。 令人费解，也许是另一个。 超过 100 件事情都将难以追踪，因此从 Web 监控中构建可观察性还应该考虑到您在完成工作时需要看到的内容。 您的提供商如何处理可见性可以告诉您很多关于他们的主要业务的信息。

一些需要注意的有用功能包括标签，您可以在其中使用颜色代码或使用团队或内部命名约定来组织检查。 您可能还喜欢在命令行中工作，在这种情况下，API 是一个需要寻找的重要功能。 请务必询问您在考虑选择时需要注意的任何潜在限制。

仪表板提供内部可见性

解决这个问题的一种方法是为支票管理提供一个集中的空间。 如果您是喜欢概览和即时访问关键指标的类型，那么仪表板可为您提供所需的可见性。 这里的好处包括可分享性。 您或您的团队能否设计可以即时切换到的仪表板？ 您能否控制访问或为特定用户分配特定仪表板？

品牌状态页面提供信任

大多数公司都重视透明度，因此状态页面是另一个不错的选择。 信任不会表现出来。 结合您的监控和状态页面提供了简单性。 如果您为这些服务中的每一项都使用供应商，则需要在两者之间设置一些层来帮助促进两者之间的沟通。 通常这意味着有人必须精心创建组件或编写脚本。 即使这样，您也可能会将数据提取到自托管服务中，该服务可能会遇到与您的网站相同的中断风险。

您的状态页面和您的网站之间的无缝体验看起来很专业。 但是，您需要将事件管理纳入您的响应例程，包括在中断或维护窗口期间定期更新您的状态页面。

还有一些内部状态页面旨在根据需要了解信息。 IT 团队以外的人员可以了解关键停机时间。 当确实发生中断时，内部状态页面将成为更新整个公司的枢纽。

警报和可观察性

当需要对问题做出反应时，服务水平协议往往会内置该信号的阈值。 这些“错误预算”，让您的团队在晚上睡觉。 警报及其包含的内容会在 5 到 60 分钟之间做出响应。

良好的警报具有指导意义。 警报可能包含状态代码、建议的修复或将您引导至有用的资源，例如警报分析。 最好的警报表明真正的问题正在发生，并告诉您该问题可能是什么。 “它已关闭”与“它正在报告 500 错误”指向非常不同的问题。

警报和详细信息

太模糊和 devops 可能会在寻找问题时掉头发，但太具体很少有问题。 彻底测试警报系统。 如果您打算更换供应商，请使用警报系统进行比赛日练习。 向您的团队提供了哪些信息？ 警报对您的诊断有帮助吗？

如果您计划多次中断，无论是作为比赛日练习还是扩展测试，您都可以了解很多关于您的监控系统如何工作的信息。 警报会升级吗？ 维护窗口而不是中断呢？ 你的系统能区分吗？

警报传递

让我们回到我们的 Edgecom 用例。 当詹姆斯在他的 Slack 频道中收到一个 ping 时，他正在监控他的服务。 HTTP(S) 中断表明他的博客已关闭。 詹姆斯能够标记博客的负责人，后者迅速调查了这一事件。 事实证明，异常数量的页面加载是原因。

该团队想知道最近的一篇帖子是否像病毒一样传播开来。 James 感知到即将发生的攻击并扩展服务器以提高容量。 果然，他的行为是一系列事件的一部分，这些事件有助于击退旨在摧毁他的主要网站的 DDoS 攻击。

这里的寓意是，发送给您的团队的警报可能会导致诊断和意外的意外发现。 没有警报意味着痛苦。 可怕的痛苦。

网络监控真的是关于分析

不要忽视警报历史的价值。 经验丰富的 devops 用户可能对灾难有超自然的感觉。 他们如何磨练这种感觉？ 通过观察灾难的原因并仔细记录它们。

升级和灵活性

假设 James 不再是 DevOps 蜘蛛侠，而且他超自然的感觉还不能完全满足。 DDoS 攻击确实会导致一些服务中断。 监控提供商可以做些什么来提供帮助？

升级和维护是一个好的开始。 如果您的提供商允许，维护窗口可以灵活地响应中断，同时提醒用户。 无论维护是否考虑到您的 SLA，当您可以安排例行维护窗口并将更新推送给您的高级用户时，它都会很有帮助。

如果您事先规划好自己的限制，您还可以减少在改组责任和内部升级上浪费的时间。 多长时间才算停电？ 在五分钟或十分钟后升级是一个不错的起点，因为更长的中断意味着确实有问题。 自动升级的警报系统消除了这种猜测，让您的团队可以工作而不必担心何时通知更高层。

合成和真实的用户 Web 监控以捕捉用户体验

停止依赖付费 Beta 测试人员（您的客户）提供的用户报告，并直接获取用户体验。 真实用户监控通常需要一些代码，例如跟踪像素，但回报是来自真实会话的实际用户数据。 如果您想知道您的用户看到了什么，RUM 监控是您工具包的有用补充。

综合监控

综合监控有两种形式，通常是：API 和事务。 事务检查正是它们听起来的样子。 他们测试目标漏斗并为关键交易提供第一响应能力。 成为第一个了解您的购物车、注册表单、登录等问题的人。

API 检查对于检查驱动服务自动化方面的端点很有用。 您可以对大多数提供商进行 GET、PUSH、PULL、PATCH 或 DELETE，从而为端点监控提供一系列可能性。 如果您可以设置和检索变量，则可以加分。

支持是网络监控中的一个看不见的因素

现在是凌晨 2 点，您的网络监控正在左右发出警报。 你需要帮助！ 你需要分析和解释。 当您遇到看不到或无法复制的错误时，来自您的提供商的响应式支持证明了它的价值。

当您需要帮助时，有一个愿意与您合作的团队很重要。 早期的支持交互是服务质量的一个很好的指标。 代理需要多长时间才能响应工单？ 他们的回复质量如何？他们可以提供哪些文件？ 有哪些支持类型可用，例如电话或聊天支持？ 当提供商隐藏联系按钮时，这可能是一个危险信号。

文档

文档应该是详尽的，包括示例，并提供分步说明。 如果您的提供商在他们的文档中使用代码，这是一个很好的迹象，他们知道他们在说什么并认真对待它。 为开发外部工具集、浏览器扩展等以帮助创建您的监控系统的提供商提供奖励积分。

致力于网络监控提供商

监控和报告是决定您的供应商的最重要组成部分，但不错的功能列表可以简化您的工作并改善监督。 请记住，警报的重点是第一反应。 如果您的警报在以太中丢失并且没有人可以声称它，那么火灾真的发生了吗？

Web 监控软件是您对客户群做出的重要承诺的一部分。 它表示您关心提供服务，并且您的用户可以相信您会为他们服务。 认真对待该承诺意味着要考虑这些要求中的哪些要求与您的组织最相关。