一位从监控专家转行为顾问的人士对你的服务器监控仍然糟糕的五个观察。

在我的职业生涯早期，我负责管理一个大型校园内的庞大打印机群。我们讨论的是数百台联网打印机。走到其中一些打印机旁经常需要步行 10 或 15 分钟，而且许多打印机只是偶尔使用。在我到达之前，我并不总是知道发生了什么，所以问题是什么只能靠猜测。简单的卡纸？驱动程序问题？打印机着火了？我只有在长途跋涉后才知道。更让每个人感到沮丧的是，由于其中一些打印机不常使用，出现问题的打印机可能会数周无人注意，只有当有人尝试使用它时才会被发现。

最后，我突然想到：如果我在有人打电话给我之前就知道问题和原因，那不是很好吗？那天我找到了我的第一个监控工具，我完全被迷住了。

从那时起，我帮助许多人彻底改造了他们的监控系统。在这样做的过程中，我注意到相同的挑战经常重复出现。如果您负责管理您组织中的系统，请继续阅读；我有很多建议要提供。

那么，事不宜迟，以下是我认为你的监控很糟糕的五个主要原因以及你可以做些什么。

1. 你正在使用过时的工具

到目前为止，监控搞砸的最常见原因是依赖过时的工具。当您花费太多时间来解决监控工具的缺陷，或者当您编写了一堆自定义代码来绕过一些主要的缺失功能时，您就知道这是您的问题。但底线是，您花费更多的时间来修复几乎可用的工具，而不是继续完成您的工作。

使用过时的工具和方法的问题在于，您只是让自己更困难。我想用一把生锈的勺子挖洞当然是可能的，但您难道不想用铲子吗？

好的工具是无形的。它们使您更有效率，并且工作更容易完成。当您拥有好的工具时，您甚至不会注意到它们。

也许您不会将您的监控工具描述为“易于使用”或“无形的”。您可能会选择使用的词语会让我的编辑拿出红笔。

此清单可以帮助您确定您是否在自找麻烦。

• 您是否正在使用 Nagios 或 Nagios 衍生工具来监控弹性/短暂基础设施？
• 您的部署过程中是否有一个手动步骤，需要人工“将 $thing 添加到监控”？
• 有多少次事后分析包含诸如“我们没有监控 $thing”之类的行动项？
• 您是否有一个 cron 作业来 tail 日志文件并通过 sendmail 发送电子邮件？
• 您是否有一个 syslog 服务器，您的所有系统都将日志转发到该服务器...然后就再也看不到了？
• 您是否仅每五分钟（甚至更少）收集系统指标？

如果您对上述任何一项回答“是”，则说明您依赖的是糟糕的、老式的工具。我向您表示慰问。

好消息是您的情况不是永久性的。稍加努力，您就可以解决它。

如果您准备好改变，那就是。

我们在运维领域如此轻易地更换整个堆栈、在一周内重新设计部署、更换配置管理工具并引入现代技术（例如 Docker 和 serverless）——所有这些都没有经过任何重要的审查期，这有点可笑（或令人沮丧？）。

然而，更换监控平台是绝对禁止的。这是为什么呢？

我认为答案在于许多公司监控现状的现实。情况非常糟糕。它们很混乱，配置不一致，缺乏连贯的策略，自动化不足......但这一切都建立在我们熟悉的工具之上。我们知道它们的故障模式；我们知道它们的缺陷。

例如，行业花费了数年时间和惊人的开发时间将各种东西添加到 Nagios 上，使其更易于接受（例如 nagios-herald、NagiosQL、OMD），而不是问，“我们是否在雪上加霜？”

答案是肯定的。是的，我们是。

不是要挑 Nagios 的毛病——好吧，是的，我要挑 Nagios 的毛病。每次更改 Nagios 配置，例如添加或删除主机，都需要重新加载配置。在依赖短暂系统（例如容器）的基础设施中，整个基础设施可能每隔几分钟就轮换一次。如果您有两个 dozen 容器每 15 分钟轮换一次，则 Nagios 可能每分钟重新加载其配置不止一次。这太疯狂了。

那么您的指标呢？判断某物是否损坏的旧方法是将检查输出的当前值与阈值进行比较。这显然会导致一些误报，因此我们添加了仅当 N 个连续检查违反阈值时才触发警报的功能。这也存在一个非常明显的问题。如果您每分钟获取一次数据，您可能在问题发生后 3-5 分钟才知道。如果您每五分钟获取一次数据，情况会更糟。

当我在我的肥皂箱上时，让我们谈谈自动化。我记得当我负责 dozen 台服务器时。当我启动第 13 台服务器时，这是一个重要的日子。这些事情每隔几个月才会发生一次。当然，将我的新服务器添加到我的监控工具中在我的清单上，而且肯定需要不止几分钟才能完成。

但现在的科技世界已经不是那样了。就在今天早上，一个客户的基础设施启动了 dozen 个新实例，并在一个小时后关闭了其中的一半。我事后才知道发生了什么。监控系统在几秒钟内就知道了这些事件，并且它们也做出了相应的调整。

在过去的五年里，科技世界发生了巨大的变化。我们心爱的首选工具并没有完全跟上步伐。监控必须是 100% 自动化的，无论是在注册新实例和服务，还是在它们消失时注销它们。在知道某事出错方面，您可以容忍 5 分钟（或 15 分钟！）延迟的日子已经一去不复返了；许多顶级公司在几秒钟内就知道某些事情不对劲。

继续依赖旧时代的方法和工具，无论您多么喜欢它们并了解它们的困境，都会阻碍您在监控方面取得巨大飞跃。

试图在三种同样糟糕的监控工具之间做出选择的糟糕旧时代早已结束。您至少应该为了自己和您的公司考虑现代工具——无论是 SaaS 还是自托管解决方案。

2. 你正在追逐“新的热门事物”

在频谱的另一端是对新兴和令人兴奋的工具的喜爱。像 Netflix 和 Facebook 这样的公司确实发布了一些非常酷的东西。但这并不一定意味着您应该使用它。

问题是：您（可能）不是 Facebook、Netflix、Google 或其他任何每个人都仰望的巨型科技公司。货物崇拜永远不会让任何事情变得更好。

仅仅因为其他人使用某些工具或策略取得了成功就采用它们，这忽略了为什么它们对他们有效的原因。

工具并不能使组织成功。组织之所以成功，是因为其成员的思维方式。它的方法、信念、人员和战略引导组织创建了这些工具。它的成功源于比“我们编写了自己的监控平台”更深层次的东西。

为了达到与行业巨头相同的成功水平，您必须深入挖掘。他们知道哪些您不知道的事情？他们正在做、思考、说、相信哪些您没有做的事情？

曾在许多此类公司内部工作过，我将向您透露这个秘密：他们非常擅长基本功。非常好。令人震惊地好。

乍一看，这似乎不相关，但请允许我引用著名系统理论家约翰·加尔的话

一个正常运行的复杂系统总是被发现是从一个正常运行的简单系统演变而来的。从头开始设计的复杂系统永远无法正常运行，也无法修补使其正常运行。您必须从一个正常运行的简单系统重新开始。

加尔博士非常敏锐地指出了全盘采用他人工具的徒劳。这些工具是从简单系统演变而来的，以适应该组织和文化的需求。将如此复杂的系统放入另一个组织或文化中可能不会产生良好的结果，仅仅是因为您试图绕过演变简单系统的艰苦工作。

所以，您想要与名副其实的行业巨头相同的成功吗？答案很简单：从简单开始。随着时间的推移不断改进。要有耐心。

3. 你不必要地害怕“供应商锁定”

如果有一个论点我希望消失，那就是人们对想要“避免供应商锁定”的看法。这种论点完全是胡说八道。

“供应商锁定”到底是什么？它指的是如果您完全采用特定供应商的产品，那么更换产品将变得非常困难或昂贵。Keurig 的 K-cups 是供应商锁定的一个著名例子。它们只能与 Keurig 咖啡机一起使用，而 Keurig 咖啡机只接受专有的 Keurig K-cups。通过购买 Keurig，您就被锁定在 Keurig 生态系统中。

因此，如果我担心被锁定在 Keurig 生态系统中，我只需避免购买 Keurig 咖啡机。很简单。

如果我担心供应商锁定，例如我的服务器基础设施，我该怎么办？同时推出 Dell 和 HP 服务器？这似乎是一个非常愚蠢的想法。这让我的工作更加困难。我必须基于每种产品的最低公分母来构建，并忽略任何特定于产品的功能，包括使产品具有吸引力的创新。表面上，这可以让我避免被锁定在一个供应商中并保持较低的切换成本，但也意味着我得到的解决方案只完成了一半的工作，并且在任何规模下管理起来都是一场噩梦。（您是否尝试过构建工具来同时管理和自动化 iDRAC 和 IPMI？您真的不想这样做。）

特别是，您无法利用产品的独特功能。通过试图避免供应商锁定，您最终得到的“解决方案”会忽略任何高级功能。

在监控产品方面，情况甚至更糟。可组合性和互操作性是您可以使用的大多数产品的核心原则。当今监控解决方案的状态有利于高度的互操作性和开放的 API。是的，单个供应商可能拥有您的所有数据，但通常可以轻松地将相同的数据转移到另一个供应商，而不会造成重大的功能损失。

关于整个供应商锁定论点的一个特殊问题是，它经常被用作不购买 SaaS 或商业专有应用程序的借口。人们认为，仅使用自托管开源产品，您会获得更多自由。

这种假设是错误的。您根本没有获得更多自由或避免供应商锁定。您只是用一个供应商换了另一个供应商。

通过选择自己完成所有事情（通常很糟糕），您实际上变成了您自己的供应商——一个经验不足、过度劳累的供应商。您在正常工作之外，设计、构建、维护和改进监控平台的能力比监控供应商更好？这种可能性接近于零。构建工具真的是您想从事的业务吗？

此外，由于商业供应商现在具有互操作性，因此从内部解决方案切换到商业解决方案的切换成本远高于从一个商业解决方案切换到另一个商业解决方案。您的内部解决方案也能做到这一点吗？

4. 你正在监控错误的东西

多年前，在我的第一份工作中，我检查了一台数据库服务器，注意到它的 CPU 利用率很高。我想我会告诉我的老板。

“谁抱怨过它？”，我的老板问道。

“嗯，没有人”，我回答道。

我老板的回答一直铭记于心。它教会了我一个宝贵的教训：“如果它没有影响任何人，那真的有问题吗？”

我的教训是：没有上下文的数据是没有用的。在监控中，指标只有在用户的上下文中才有意义。如果低可用内存是您注意到的情况，但它没有影响用户，则不值得触发警报。

在我多年的运营和系统管理工作中，我从未见过 OS 指标直接表明活跃用户的影响。指标有时可能是间接指标，但我从未见过它直接表明问题。

这引出了我的下一个观点。有了来自基础设施的所有这些指标和日志，为什么您的监控没有变得更好？原因是运维只能解决一半的问题。虽然监控 nginx 工作进程、Tomcat 垃圾回收或 Redis 密钥驱逐对于了解基础设施性能都很重要，但它们都无法帮助您了解您的业务运行的软件。监控的最大价值来自对用户依赖的应用程序进行检测。（当然，除非您的业务是提供基础设施即服务——那么，请务必继续。）

在 SaaS 公司中，这一点最为明显，因此让我们以 SaaS 公司为例进行说明。

假设您有一个应用程序，它是一个标准的三层 Web 应用程序：前端是 nginx，应用服务器是 Rails，后端是 PostgreSQL。网站上的每个操作都会访问 PostgreSQL 数据库。

您拥有所有标准数据：访问和错误日志、nginx 指标、Rails 日志、Postgres 指标。所有这些都很棒。

您知道什么更棒吗？了解用户登录需要多长时间。或者每分钟发生多少次登录。或者更好的是：每分钟发生多少次登录失败。

此信息如此有价值的原因在于，它直接告诉您用户体验。如果过去五分钟内登录失败次数增加，您就知道您遇到了问题。

但是，您无法仅从基础设施的角度看到此类信息。如果我只关注 nginx/Rails/Postgres 性能，我将完全错过此事件。我会错过一些事情，例如最近的代码部署更改了一些与登录相关的代码，这导致登录失败。

为了解决这个问题，与您的工程团队成为更亲密的朋友。帮助他们识别代码中有用的检测点，并实施更多的指标和日志记录。我非常喜欢 statsd 协议来做这类事情；大多数监控供应商都支持它（或他们自己对它的实现）。

5. 只有你在乎

如果您是唯一关心监控的人，系统性能和有用的指标永远不会得到有意义的改进。您无法独自完成这项工作。即使只有您的团队关心，您也无法做到这一点。我不禁要数我见过多少次运维团队努力做出改进，却发现团队外没有人注意到或认为这很重要。

改进监控需要全公司的支持。从接待员到 CEO，每个人都必须相信您所做工作的价值。公司中的每个人都知道企业需要盈利。同样，这需要全公司理解，改进监控可以提高底线并保护公司的利润。

问问自己：你为什么关心监控？

是因为它可以帮助您更快地发现和解决事件吗？这对你为什么重要？

为什么这对您的经理很重要？对您经理的经理呢？为什么 CEO 应该关心？

您需要回答这些问题。当您这样做时，您就可以开始为所需的投资（包括在最好的新工具上的投资）提出有说服力的商业理由。

需要一个起点吗？以下是一些企业可能关心改进监控的想法

• 企业可以管理和减轻事件和故障的风险。
• 企业可以发现性能改进的领域，从而改善客户体验并增加收入。
• 企业可以更快地解决事件（通常在事件变得危急之前），从而获得更多的用户好感和提升声誉。
• 企业可以避免事件从糟糕变得更糟，从而防止收入损失和潜在的 SLA 罚款支付。
• 企业可以通过容量规划和预测更好地控制基础设施成本，从而提高利润和降低费用。

我建议与您的团队就他们为什么关心监控进行坦诚的对话。务必让管理层也参与进来。一旦您进行了这些对话，请再次与您的工程团队重复这些对话。以及您的产品管理团队。以及市场营销部门。以及销售部门。以及客户支持部门。

监控会影响整个公司，并且通常以不同的方式影响。当您发现自己与高管进行对话以请求对监控进行投资时，您将能够用他们的语言说话。前进并修复您的监控。我希望您至少找到了一些改进监控的想法。成为世界一流的监控是一个漫长、艰苦且昂贵的道路，但好消息是，您实际上不需要成为最好的就能看到巨大的好处。随着时间的推移添加一些简单的更改可以从根本上改善您公司的监控。

总结一下

1. 使用更好的工具。在更好的工具出现时更换它们。
2. 但是，不要只关注工具。工具是用来帮助您解决问题的——它们不是最终目标。
3. 不要担心供应商锁定。选择您喜欢的产品并全力以赴。
4. 注意您收集的内容以及您发出警报的内容。最好的数据会告诉您有关对用户有直接影响的事情。
5. 了解您的公司为什么关心监控，并用业务成果来表达它。只有这样，您才能真正获得您想要的投资。

祝您好运，监控愉快。