关于为什么您的服务器监视仍然由监视专家转为顾问的问题有五点看法。
在我职业生涯的早期,我负责管理整个大型园区中的大量打印机。我们正在谈论数百台联网打印机。通常需要步行10或15分钟才能到达其中的某些打印机,而且许多打印机只是偶尔使用。直到我到达时,我并不总是知道发生了什么,所以这是任何人对问题的猜测。卡纸简单吗?驱动程序问题?打印机目前着火了?经过漫长的步行,我才发现。让每个人都感到沮丧的是,由于其中一些打印机的不经常使用,有问题的打印机可能会在数周内被忽略,只有在有人尝试使用它进行打印时,它才会被人们知道。
最后,这发生在我身上:如果在有人打电话给我之前知道问题的原因和原因,那不是很好吗?那天我找到了我的第一个监视工具,这让我非常着迷。
从那时起,我帮助许多人检修了他们的监控系统。在这样做时,我注意到同样的挑战会定期重复出现。如果您负责组织中的系统管理,请继续阅读;我有很多建议可以分配。
因此,事不宜迟,以下是我的五个主要原因,说明您的监视工作很糟糕,您可以采取哪些措施。
到目前为止,监视被搞砸的最常见原因是对陈旧工具的依赖。当您花太多时间在监视工具的缺陷上工作时,或者当您有大量自定义代码来解决一些主要的缺少功能时,您就会知道这是您的问题。但最重要的是,您花费更多的时间尝试修复几乎可以使用的工具,而不是仅仅着手工作。
使用过时的工具和方法的问题在于,这只会使您自己更难。我想当然可以用生锈的勺子挖一个洞,但是您不是更喜欢用铁锹吗?
伟大的工具是看不见的。它们使您更有效,工作也更容易完成。当您拥有出色的工具时,您甚至都不会注意到它们。
也许您不会将监视工具描述为“易于使用”或“不可见”。您可能会选择使用的单词会使我的编辑器变红。
该清单可以帮助您确定自己是否在搞砸。
您是否正在使用Nagios或Nagios衍生产品来监视弹性/短暂基础设施?
在您的部署过程中,是否有人工操作人员可以“为监视添加新内容”?
多少验尸中包含一个操作项,例如“我们没有监视$ thing”?
您是否有一个cron作业,它尾随日志文件并通过sendmail发送电子邮件?
您是否有一个syslog服务器,您的所有系统都将其日志转发到该服务器...再也看不到?
您是否仅每五分钟(甚至更少一次)收集一次系统指标?
如果您对其中任何一个回答为“是”,则说明您使用的是不良的老式工具。节哀顺变。
好消息是您的情况不是永久的。只需一点工作,就可以修复它。
如果您准备好进行更改,那就是。
在Ops中,我们如此轻松地替换整个堆栈,在一周内重新设计部署,替换配置管理工具并引入现代技术(例如Docker和无服务器),这都没有任何明显的审查期,这在某种程度上令人感到沮丧(或沮丧)。
但是,更改监视平台是很严格的。是什么赋予了?
我认为答案在于许多公司的监控状态。事情很糟糕。它们杂乱无章,配置不一致,缺乏连贯的策略,自动化程度不高……但这全都是基于我们所知道的工具构建的。我们知道他们的失败模式;我们知道他们的疣。
例如,该行业花费了数年时间和惊人的开发时间,将事情花在了Nagios上,使它变得更美味(例如nagios-herald,NagiosQL,OMD),而不是问“我们是在坏事之后投入好钱吗?”
答案是肯定的。是的,我们是的。
不选择Nagios,是的,我要选择Nagios。Nagios配置的每项更改(例如添加或删除主机)都需要重新加载配置。在依赖临时系统(例如容器)的基础结构中,整个基础结构可能每隔几分钟就会翻转一次。如果每15分钟有两个容器在搅动,则Nagios可能每分钟重新加载一次其配置。太疯狂了
那您的指标呢?判断是否损坏的旧方法是对照阈值检查检查输出的当前值。显然,这会导致一些错误警报,因此我们添加了仅在N个连续检查违反阈值时才发出警报的功能。这也有一个非常明显的问题。如果您每分钟获取一次数据,则可能要等到问题发生3到5分钟后才能知道问题。如果每五分钟获取一次数据,那就更糟了。
当我在肥皂盒上时,让我们谈谈自动化。我记得我当时负责十几台服务器。这是重要的一天,我启动了13号服务器。这些事情仅每几个月发生一次。当然,将我的新服务器添加到我的监视工具中是在我的清单上,并且肯定花了几分钟的时间。
但是技术世界已经不再那样了。就在今天早上,一个客户的基础架构启动了十二个新实例,并在一小时后缩减了一半。我知道这是事实之后才发生的。监视系统在几秒钟内就知道了这些事件,并对其进行了相应的调整。
在过去的五年中,科技界发生了翻天覆地的变化。我们钟爱的选择工具并没有跟上步伐。在注册新实例和服务时以及在它们消失时都将其注销,监视必须100%自动化。能够将5分钟(或15分钟)的延迟告知某事出问题的日子已经一去不复返了。许多顶级公司在几秒钟内就知道有些不对劲。
不管您多么喜欢它们并知道它们的麻烦,继续依赖旧时的方法和工具都会使您从监视的巨大飞跃中退缩。
试图在三种同样可怕的监视工具之间进行选择的糟糕时光已经过去了。无论是SaaS还是自托管解决方案,您都应该自己和您的公司来考虑使用现代工具。
在另一端是对新颖工具的兴趣。当然,像Netflix和Facebook这样的公司发布了一些非常酷的东西。但这并不一定意味着您应该使用它。
问题出在这里:您(可能)不是Facebook,Netflix,Google或其他所有人都仰望的其他大型科技公司。货运培训 从未使任何事情变得更好。
采用别人的工具或策略,因为他们是成功的,他们错过的关键原因为什么它为他们工作。
这些工具不能使组织成功。该组织之所以成功,是因为其成员的想法。它的方法,信念,人员和策略促使组织创建了这些工具。它的成功源于比“我们编写了自己的监视平台”更深刻的东西。
为了获得行业巨头的相同成功,您必须更进一步。他们知道您不知道什么?他们在做什么,想着想说,相信自己不是吗?
在其中许多公司的内部工作之后,我将为您提供一个秘密:他们擅长基础知识。真的很好 令人难以置信的好。
乍一看,这似乎无关紧要,但请允许我引用著名系统理论家John Gall的话:
总是可以找到一个有效的复杂系统,它是从一个有效的简单系统演变而来的。从头开始设计的复杂系统永远无法运行,也无法进行修补以使其正常运行。您必须重新开始,首先要使用一个简单的系统。
盖尔博士非常机敏地指出了采用其他人的工具批发是徒劳的。这些工具从简单的系统演变而来,以适应该组织和文化的需求。将这样一个复杂的系统放入另一个组织或文化中可能不会产生令人满意的结果,这仅仅是因为您试图简化开发一个简单系统的艰巨工作。
那么,您想要与真正的行业巨头一样的成功吗?答案很简单:从简单开始。随着时间的推移而改善。耐心一点。
如果有一个我希望死掉的论点,那就是人们认为要“避免供应商锁定”的论点。这种说法完全是白痴。
无论如何,什么是“供应商锁定”?这是一种观念,即如果您全心投入特定供应商的产品,那么更改将变得异常困难或昂贵。Keurig的K杯是供应商锁定的著名示例。它们只能与Keurig咖啡机一起使用,而Keurig咖啡机仅接受专有的Keurig K杯。购买Keurig,您就可以进入Keurig生态系统。
因此,如果我担心被困在Keurig生态系统中,那我就避免购买Keurig机器。简单。
如果我担心供应商会锁定我的服务器基础结构,该怎么办?同时推出戴尔和惠普服务器?这似乎是一个愚蠢的想法。这使我的工作更加困难。我必须将每个产品的公分母都设为最低,而忽略任何产品特定的功能,包括使产品具有吸引力的创新。表面上,这将使我避免被某个供应商所束缚,并保持较低的转换成本,但这也意味着我有一个解决方案,只能解决一半的工作,并且是在任何规模进行管理的噩梦。(您是否曾经尝试过构建用于管理和自动化iDRAC和IPMI的工具?您真的不想这么做。)
特别是,您不会利用产品的独特功能。通过避免供应商锁定,您最终得到了一个忽略任何高级功能的“解决方案”。
在监视产品时,情况更糟。可组合性和互操作性是您可以使用的大多数产品的核心原则。如今,监视解决方案的状态要求高度的互操作性和开放的API。是的,单个供应商可能拥有您的所有数据,但是将同一数据移动到另一供应商而又不会造成重大功能损失通常是微不足道的。
整个供应商锁定论的一个特殊问题是,它经常被用作不购买SaaS或商业专有应用程序的借口。人们的看法是,仅使用自托管的开源产品,您将获得更多的自由。
这个假设是错误的。您没有获得更多自由,也没有完全避免供应商锁定。您已将一个供应商换成另一个。
通过选择自己做(通常做得不好),您可以有效地成为自己的供应商-经验不足,工作过度的供应商。您是否有机会在日常工作之外比监视供应商更好地设计,构建,维护和改善监视平台?他们舍入为零。工具构建真的是您想从事的业务吗?
此外,由于商业供应商如今具有互操作性,从内部解决方案转换成本比从一种商业解决方案转换为另一种成本高得多。您内部的解决方案可以这么说吗?
许多年前,在我的第一份工作中,我检出了一个数据库服务器,发现它具有很高的CPU利用率。我想让老板知道。
“谁抱怨呢?”老板问。
我回答:“嗯,没人。”
老板的反应一直困扰着我。它教会了我一个宝贵的教训:“如果不影响任何人,真的有问题吗?”
我的教训是:没有上下文的数据没有用。在监视中,度量标准仅在用户的上下文中才重要。如果您注意到低可用内存是一种情况,但它不会影响用户,则不值得发出警报。
在我多年的运营和系统管理工作中,我从未见过OS指标直接表明积极的用户影响。指标有时可以是间接指标,但我从未见过它可以直接表明问题。
这把我带到了下一点。有了来自基础架构的所有这些指标和日志,为什么您的监视效果不佳?原因是因为Ops只能解决一半的问题。监视nginx工人时,Tomcat垃圾回收或Redis密钥驱逐都是了解基础架构性能的重要指标,但它们都无法帮助您了解业务运行的软件。监视的最大价值在于对用户所依赖的应用程序进行检测。(当然,除非您的企业提供基础设施即服务,然后再继续进行下去。)
在SaaS公司中,没有哪个地方比这更清楚了,所以让我们以它为例。
假设您有一个应用程序,它是标准的三层Web应用程序:前端为nginx,后端为Rails应用程序服务器和PostgreSQL。该站点上的每个操作都会访问PostgreSQL数据库。
您拥有所有标准数据:访问和错误日志,nginx指标,Rails日志,Postgres指标。所有这些都很棒。
你知道有什么更好的吗?知道用户登录需要多长时间。或者每分钟发生多少次登录。甚至更好:每分钟发生多少次登录失败。
该信息之所以如此有价值,是因为它直接告诉您有关用户体验的信息。如果在过去五分钟内登录失败率上升,则说明您遇到了麻烦。
但是,您不能仅从基础结构的角度看到此类信息。如果我只关注nginx / Rails / Postgres的性能,我将完全错过这一事件。我会想念类似最近的代码部署之类的东西,该东西更改了一些与登录相关的代码,从而导致登录失败。
为了解决这个问题,请与您的工程团队成为更亲密的朋友。帮助他们识别代码中有用的检测点,并实施更多指标和日志记录。对于这种事情,我非常喜欢statsd协议;大多数监视供应商都支持它(或它们自己的实现)。
如果您是唯一关心监视的人,那么系统性能和有用的指标将永远不会有意义地提高。你不能一个人做。如果只有您的团队在乎,您甚至无法做到这一点。我无法开始计算Ops团队进行改进的努力次数,只是发现团队之外没有人关注或认为这很重要。
改善监控要求整个公司范围内的支持。从接待员到首席执行官,每个人都必须相信您所做工作的价值。公司中的每个人都知道业务需要盈利。同样,它需要整个公司范围的理解,即改进监控可以改善底线并保护公司的利润。
问自己:您为什么关心监视?
是因为它可以帮助您更快地捕获和解决事件吗?为什么这对您很重要?
为什么这对您的经理很重要?给你经理的经理?CEO为什么要关心?
您需要回答这些问题。当您这样做时,就可以开始为所需的投资(包括最佳的新工具)进行有说服力的业务论据。
需要一个起点?这里有一些想法,为什么企业可能会关心改善监控:
企业可以管理和减轻事件和故障的风险。
该业务可以发现需要改进的地方,从而改善客户体验并增加收入。
企业可以更快地解决事件(通常在事件变得严重之前),从而提高用户信誉并提高声誉。
该业务避免了事件的恶化,从而避免了收入损失和潜在的SLA罚款。
该业务可以通过容量规划和预测更好地控制基础架构成本,从而提高利润和降低支出。
我建议您与您的团队进行坦诚的交谈,以了解他们为何关心监控。确保也包括管理。进行完这些对话后,请与您的工程团队再次重复。和您的产品管理团队。和营销。和销售。和客户支持。
监视通常以不同的方式影响整个公司。当您发现自己正在与高管进行对话以请求对监控进行投资时,您将能够说出他们的语言。继续并修复您的监视。希望您至少找到了一些改善监控的想法。要在这条道路上跻身世界一流,是一条漫长,艰辛,昂贵的道路,但是好消息是,您并不需要真正地成为获得巨大收益的最佳人选。随着时间的推移,添加了一些直接的更改,可以从根本上改善公司的监视。
回顾一下:
使用更好的工具。当有更好的工具可用时,请更换它们。
但是,不要专注于工具。那里的工具可以帮助您解决问题,但这不是最终目标。
不必担心供应商锁定。选择您喜欢的产品并全力以赴。
请注意收集的内容和发出的警报。最好的数据可以告诉您有关直接影响用户的事情。
了解您的公司为何关心监控并在业务成果中表达出来。只有这样,您才能真正获得所需的投资。
祝你好运,祝您监督愉快。
评论专区