也许你去过那里。 您是工程副总裁或产品负责人。 您的一个应用程序发生了严重停机，您的团队花了整整一周的时间来查找和解决问题。 客户和收入损失了。 现在，您正在与一位顾问一起参加的审核会议上，以了解发生了什么事情以及原因。
您有点紧张，因为您知道自己没有监视所有事情。 毕竟，监视系统既昂贵又费时。 但是您已经完成了标记关键和不关键的过程。 您的运维团队很好，您的应用程序正在运行，并且即使在上个月发生故障的情况下，您的业绩也很稳定。 这个问题正好被标2级，或“并不重要”，但它属于你，因为碰到它到1级。
“那么，告诉我，”顾问说，“为什么要监视应用程序？”
你放松。 这将比您想象的要容易。
您说：“即使在最佳系统中，也会有问题，而问题会花费金钱。 因此，我们需要尽可能多地了解问题发生的时间。 如果没有监控，我们就会知道什么是错的 ，但我们不知道任何细节。 而且，当操作人员正在寻找答案时，我们将失去销售。 监视可以准确地告诉我们出了什么问题以及在哪里寻找。”
“我明白了。”顾问说。 “那么，您正在监视所有关键业务应用程序吗？”
是的。 我们只是碰巧错过了这个。”
“为什么不监视每个应用程序—甚至是非关键应用程序也只是为了安全起见？”
你说：“太贵了。” “而且会有太多的数据-所有这些日志和指标。 我们将永远无法解析所有内容。”
“那么，您如何选择哪些应用程序至关重要？”
您说：“这很重要。” “ ERP，财务，CRM，工资单，呼叫中心，电子商务平台……”
“好的，”顾问说。 “但是这些是系统，而不是应用程序。 系统由应用程序组成：验证服务，Web应用程序，数据库。 您是否正在监视所有这些组件？”
您会感到不舒服。 “好吧，”你说，“是的。 有点。 我们正在监视其中的大多数。 但这有很多应用。”
“您的微服务呢？ 还有您的云API？”
“我们不能监视一切 ，”你说。 “我们有预算和时间限制。”
“在您正在监视的应用程序上，您正在监视哪些指标？”
“大部分只是性能。 每秒事务数，数据库响应时间之类的东西。”
“而已？” 他问。
您已经知道了为什么要花这么长时间跟踪故障，顾问也是如此。 这是因为您没有监视应有的一切。 您已经牺牲了预算和时间的保障。 一直都是这样。
但这不必是这种方式。
让我们退后一步，看看出了什么问题。 我们将研究如何识别关键业务系统，为什么这些系统如此复杂且难以监控，以及如何使用应用程序性能监控（APM）来帮助您以简单，轻松和最小的成本监控所有系统。
什么是关键业务应用程序？
首先，让我们看一下使应用程序业务变得至关重要的原因。 一个很好的起点是定义关键流程 ，这是企业生存所需的流程 。 例如，一家货运公司向超市运送货物可能会认为其供应链管理流程至关重要。 一家在线酒店预订公司可能会确定其预订工作流程至关重要。 关键业务流程决定了您的业务成败。
确定关键业务流程后，下一步就是定义哪些关键应用程序为这些关键流程提供动力。 对于旅行公司，它可能是前端应用程序，购物车应用程序，付款处理应用程序以及调用批发商API的应用程序。
然后，一旦确定了关键业务应用程序，便知道需要监视什么。 如果这些部件中的任何一个停止工作，则您的流程将中断，并且客户将丢失。 但是，要确定所有这些组件非常困难，特别是在现代建筑复杂的情况下。
现代关键业务应用程序很复杂
几年前，监视更加容易。 系统是运行在用户工作站上并直接调用数据库的整体。 但是，随着时间的流逝，系统变得越来越复杂，实现了三层体系结构：数据库，应用程序和表示层。 最近，随着微服务，混合云和多云以及容器和编排系统的引入，复杂性成倍增加。
在现代应用程序中，您现在可能需要监视旅行预订应用程序的数百种微服务，监视本地和公共云上的混合云应用程序，或者监视两个供应商之间的多云通信。 对于现代DevOps，您可能需要监视容器和复杂的编排系统（如Kubernetes），以确保您的部署能够正常工作。
这些现代体系结构可能会增加可靠性和可伸缩性，但它们还会增加抽象性，复杂性，更多的故障点并显着增加监视需求。 即使您可以监视所有这些组件，您现在仍然面临一个主要问题：信息过载。 来自关键业务应用程序的大量指标和日志可能不堪重负。 持续观察这些指标和日志是不可能的。
不要损害您的监控
所有这些应用程序创建所有这些信息的结果是，团队损害了他们标记为业务关键的内容。 他们可能决定监视数据库的慢查询日志，CPU，内存和磁盘空间，但不监视读/写吞吐量。 他们可能决定监视调用银行API的微服务，但不监视通过电子邮件发送给客户的微服务。
这种妥协的结果？ 本文开头的场景。 有一天，您的应用程序停止了。 您检查了应用程序的日志，消息队列，警报，但找不到答案。 您的查询经过精心调整和测试。 您的DBA宣誓索引是最新的。 但是您的整个团队都花了几天的时间来寻找问题所在。
但是，如果您监视了所有真正重要的应用程序，并且观看了所有可用指标，则将很快找到答案。 您的读/写吞吐量高于正常水平，这会导致表锁定并降低查询速度，从而使CPU达到极限。 通过彻底的监视，您可以Swift将问题归结为罪魁祸首：最近的应用程序更改导致大量写请求。
缺少单个指标或监视器可能会导致几天甚至几周的时间和收入损失。
应用程序性能监控（APM）
这就是APM存在的原因。 APM与您的应用程序集成在一起，以收集，处理，分析和关联来自所有组件的信息。 简而言之，APM为您提供了所有应用程序的整体视图，从问题的“鸟瞰图”到根本原因。
如果你使用的SolarWinds®AppOptics ™作为你的APM工具 ，成本不再是一个问题。 您无需选择要监视的应用程序或指标。 随着AppOptics，你能负担得起的监控你所有的关键业务应用，业务流程工具和云平台的所有指标，都在一个简单，优雅，易于使用的视图。
SolarWinds AppOptics
AppOptics是一个全面的监视解决方案，使您可以并排为所有应用程序，数据库，服务器，网络和基础结构创建仪表板。 首先，快速浏览可以告诉您哪个层遇到了问题。
SolarWinds AppOptics应用程序概述仪表板。 ©2020 SolarWinds，Inc.保留所有权利。
然后，您可以深入了解细节。 AppOptics为您提供了清晰的应用程序依赖关系图，使您可以轻松地了解微服务的连接方式，数据库返回给用户的内容，API网关正在调用的功能等等。 此外，通过AppOptics相结合SolarWinds的Loggly ®，你将不会被记录的群众不堪重负。 只需单击一下，您便可以从基础结构主机或事务跟踪移到与构成事务跟踪的主机或服务关联的相关日志事件。
您还可以查看服务器的容量和性能，并通过比较一段时间内的使用情况，容量和性能来进行趋势分析。
重要的是，借助AppOptics，您可以监控所有应用程序而无需付出任何代价。
结束语 SolarWinds AppOptics是一种新型的APM，它简单，可扩展且最经济实惠。 要试用，今天就注册免费试用 。
翻译自: https://www.javacodegeeks.com/2020/04/the-high-cost-of-not-monitoring-every-business-critical-application.html