让我们来谈谈 Amazon CloudWatch。

对于那些足够幸运，不必深陷 Amazon Web Services (AWS) 泥潭的人来说，CloudWatch 正如官方 AWS 描述 所说，“是为开发人员、系统运维人员 (SRE)、站点可靠性工程师和 IT 经理构建的监控和管理服务”。 这听起来都很好，除了没有任何一个被提及的群体喜欢使用这款产品。 请允许我发表一些监控方面的异端邪说。

更好的是，让我结合亚马逊 14 条 领导力准则 来描述这一点，据说这些准则指导着亚马逊的每一个决策。 当你认真审视 CloudWatch 在所有 14 条领导力准则上的彻底失败时，你会想知道这款产品是如何以目前的状态问世的。

我将从计费开始说起。 通常这类文章都会把计费放在最后，但 CloudWatch 的计费模式非常糟糕，所以我先来说这个。 您需要按指标、按月付费。 您需要按每千个通过 API 请求查看的指标付费。 您需要按每个仪表板、按月付费。 您需要按每个告警、按月付费。 您需要为日志付费，费用取决于摄取的数据量、存储的数据量以及由 AWS 服务代表客户原生发布的“供应商日志”。 而且，您还需要为每个自定义事件付费。 所有这些都可以最好地概括为“地球上没有人理解你的 CloudWatch 指标和日志是如何计费的”，这导致了这样一种情况：监控供应商可能因过于频繁地轮询 CloudWatch 而意外地让您花费数千美元。 当 AWS 的费用比您支付给监控供应商的费用还要高时，感觉就非常糟糕了。

CloudWatch Logs、CloudWatch Events、自定义指标、供应商日志和自定义仪表板，所有这些对 CloudWatch 内部来说都意味着不同的东西，这与您期望的相比，那些实际有一定程度意义的指标解决方案是不同的。 因此，有多种服务在“CloudWatch”这个名号下运行，但它们的功能却大相径庭。 例如，对于大多数人来说，安排 Lambda 函数每小时调用一次需要自定义 CloudWatch Event，这不是很直观。 它让人感觉过于复杂、令人困惑，而且很快，您就会发现自己不得不构建复杂的关系来监控那些本身简单得多的事物。

所有商业人士在被问及他们希望从监控平台获得什么时，都会回答类似于“仪表板”或“单一管理平台视图”的东西。 CloudWatch 提供了大量的细节，但它绝对没有提供全局视图，没有绿色/黄色/红色状态指示器，甚至无法让您瞥见网站的整体运行状况。 想要查看过去 30 秒内实例 CPU 中每个核心的图表？ 简单！ 想知道您的整个公司是否应该扑灭正在燃烧的大火，即您网站当前的生产状态？ 继续寻找吧——CloudWatch 什么都提供不了。

就其本质而言，CloudWatch 给人的感觉是格局小。 从头到尾的整个体验都让人觉得“我们能做的最少的事情是什么，并且还能蒙混过关？” 他们构建了他们的 MVP，然后就停滞不前了……就像琥珀中的化石一样。 他们创建了一组构建模块，但他们没有解决“我如何监控我的 AWS 资源？”这个问题。 相反，感觉整个团队都在敷衍了事，从而催生了一个庞大的监控供应商市场。 这些供应商都没有 CloudWatch 那样访问原始数据的权限； 但他们都构建了更好的产品。 你会认为 CloudWatch 团队会从这个领域正在快速发生的创新中吸取教训，但这需要有人去学习和保持好奇心。

最近的数据是“最终一致性”的，所以你总是会得到如图 1 所示的图表。

图 1. CloudWatch 图表示例

在现实中，在一个准确的仪表板上看到这样的情况将是非常可怕的——你的网站显然出了大问题！ 不管好坏，“准确”的描述并不适用于 CloudWatch，而这正是你的图表始终呈现的样子。 “你的指标将是最终一致性的”几乎是您最不想听到的关于监控平台的事情，仅次于“什么指标？” 这直接关系到……

让我在这里非常清楚地说明一点——真正的问题不是数据摄取问题。 地球上绝对所有的供应商都面临同样的问题——你无法显示你没有的数据。 CloudWatch 的失败之处在于，它在没有解释正在发生什么的情况下，将这种行为暴露给最终用户。 因此，在您习惯它之前，每当您瞥一眼仪表板时，您都会心跳加速，心想“网站到底发生了什么”。 这种状况会使您在查看合理的仪表板时过于冷静，即使灾难刚刚发生。 如果您信任 CloudWatch 仪表板显示给您的内容，那您就犯了一个可怕的错误。

如果您正在使用 Lambda 或 Fargate，您别无选择，只能使用 CloudWatch Logs，在其中搜索所有内容都非常糟糕。 如果您正在使用 CloudWatch Logs 来诊断任何问题，那么恭喜您：您正在深入挖掘，您可能会在回到水面之前溺水身亡。 例如，如果我有一个 Lambda 函数抛出一个错误，为了诊断问题，我必须

• 首先通过查看调用错误 CloudWatch 仪表板来找到它遇到错误的事实。 我也可以设置一个过滤器来对日志运行连续查询，并在出现问题时发出警报，但这并不是原生支持的——我需要一个第三方工具来实现这一点（例如 PagerDuty）。
• 深入到各种 CloudWatch 日志组中，找到以特定错误函数命名的那个。
• 手动滚动浏览许多、许多、许多页日志组，以找到抛出错误的特定调用。
• 意识到保留的 JSON 对象不足以进行故障排除，绝望地哭泣，然后写一篇像这样的文章。
• 快速计算一下，意识到我为一项最多只有些许用处的服务支付了 AWS 账单中令人不安的百分比。

您的所有指标、所有日志——它们都被锁定在 CloudWatch 的各种组件中。 您不会在 CloudWatch 中找到“当超过此阈值时通知我”的选项； 您的选择仅限于“用铁丝和 SNS 设计一个告警传递管道”或为另一个监控产品支付非 AWS 供应商的费用。

CloudWatch 保留您的所有指标。 它保留您的日志。 它允许您构建自定义仪表板，在一个地方查看您的所有指标。 一个伟大服务的基础构建模块已经存在——但实用性的表达却有所欠缺，有时甚至非常严重。 如果 CloudWatch 能够振作起来，那么大型监控供应商成为 AWS 活动的主要赞助商将是一件可笑的事情。 您将不需要第三方来理解纯 AWS 环境，而且他们中的许多人会饿死，因为他们变得太虚弱，无法打断您的谈话，询问是否可以扫描您的胸牌。 选择使用 CloudWatch 而不是其他任何东西，就像买车一样。 “是的，我想买一辆优果而不是本田。 毕竟，它在技术上符合汽车的所有标准，所以没问题，对吧？”

CloudWatch 许多失败的根本原因很可能来自构建它的产品工程师误解了这条（公认的难以捉摸的！）领导力准则。 它的设想是热情地表达您对某个决定的保留意见，但一旦达成一致，您就要承诺执行做出的决定。 不幸的是，负责 CloudWatch 的工程团队似乎决定“在提交中表达分歧”，并将他们的争论以产品的形式强加于世。

如果我在互联网上发帖说几乎任何其他 AWS 服务有多糟糕，人们都会站出来为该服务辩护。 这就是互联网； 人们会这样做。 但是，当这些以及更多类似的关于 CloudWatch 的评论出现时，却没有 AWS 的人出来说“哇，我很抱歉，您为什么会有这种感觉？”，这清楚地表明，如果 CloudWatch 团队中有人真的关心这款产品，那么他们已经被锁在故障的浴室隔间里将近十年了。 这些 评论 至少可以追溯到那么久以前，但 亚马逊 完全 没有 在意 这些，完全无视公司的 “行动偏好” 原则。

构建 CloudWatch 的人并非工作能力差； 我真诚地相信他们不太了解他们的产品是如何被看待的。 考虑到像这样写一篇长篇大论而不提供积极改进的建议是不好的形式，以下是我希望看到的一些产品增强功能：

• 给我选择以任意级别限制 API 调用的选项，而不是在月底被大约相当于桑给巴尔 GDP 的账单吓到。
• “这是您的 Lambda 函数抛出的错误，这是来自该特定函数的日志输出”最多应该是两次点击就可以完成的事情——而不是 30 次。
• 如果你的狗生了 14 只小狗，也许你不需要把它们都命名为“CloudWatch”这个词的细微变体。 所有以“Cloud”这个词开头的服务和公司的激增是另一个完全独立的长篇大论的主题。

请不要误解我。 我使用、享受和推广 AWS 服务，并且我被认为是“一个真实的声音”，主要是因为除了赞扬美好的事物之外，我也会指出不好的事物，就像我刚刚做的那样。 我在 AWS 生态系统中工作的基础上建立了自己的职业和事业。 我发现 AWS 员工聪明且善意，他们的大部分服务都非常好。 CloudWatch 经过一些努力可以达到那个水平，但它存在许多非常痛苦的可用性问题，使其无法变得优秀，更不用说伟大了。