我们在组建产品团队的阶段就考虑建立一个监控系统。 很明显，我们的业务——剥削——不属于这些团队。 这是为什么？
事实上，我们所有的团队都是围绕单个信息系统、微服务和前端构建的，因此团队看不到整个系统的整体健康状况。 例如，他们可能不知道深层后端中的某些小部分如何影响前端。 他们的兴趣范围仅限于与其系统集成的系统。 如果一个团队及其服务A与服务B几乎没有联系，那么这样的服务对于团队来说几乎是不可见的。
反过来，我们的团队与彼此集成非常紧密的系统合作：它们之间有很多连接，这是一个非常庞大的基础设施。 在线商店的运营取决于所有这些系统（顺便说一句，我们拥有大量系统）。
原来我们部门不属于任何一个团队，只是位置稍微靠边一点。 在整个故事中，我们的任务是全面了解信息系统如何工作、其功能、集成、软件、网络、硬件以及所有这些如何相互连接。
我们的在线商店运营的平台如下所示：
- 前
- 中台
- 后台
无论我们多么希望，所有系统都不会顺利、完美地运行。 同样，重点是系统和集成的数量——对于像我们这样的系统，尽管测试质量很高，但一些事件是不可避免的。 此外，无论是在单独的系统内还是在集成方面。 您需要全面监控整个平台的状态，而不仅仅是平台的任何单个部分。
理想情况下，整个平台的健康监控应该是自动化的。 我们将监控作为这个过程中不可避免的一部分。 最初，它只是为一线人员构建的，而网络专家、软硬件管理员已经并且仍然拥有自己的层层监控系统。 这些人都只是在自己的层面上进行监控，没有人有全面的了解。
例如，如果虚拟机崩溃，大多数情况下只有负责硬件和虚拟机的管理员知道。 在这种情况下，一线团队看到了应用程序崩溃的事实，但没有有关虚拟机崩溃的数据。 并且管理员可以知道客户是谁，并大致了解当前在该虚拟机上运行的内容，前提是它是某种大型项目。 他很可能不知道小孩子们的事。 无论如何，管理员需要去找所有者询问这台机器上有什么，需要恢复什么以及需要更改什么。 如果出现了非常严重的问题，他们就会开始原地踏步——因为没有人看到整个系统。
最终，这些不同的故事会影响整个前端、用户和我们的核心业务功能——在线销售。 由于我们不是团队的一员，而是作为在线商店的一部分从事所有电子商务应用程序的运营，因此我们承担了为电子商务平台创建全面监控系统的任务。
系统结构及堆栈
我们首先为我们的系统确定几个监控层，在这些监控层中我们需要收集指标。 所有这些都需要结合起来，这就是我们在第一阶段所做的。 现在，在这个阶段，我们正在最终确定所有层中最高质量的指标集合，以便建立相关性并了解系统如何相互影响。
在应用程序启动的初始阶段缺乏全面的监控（因为我们在大多数系统投入生产时开始构建它）导致我们在建立整个平台的监控方面背负着巨大的技术债务。 我们无法集中精力对一个IS进行监控并制定详细的监控方案，因为其余系统将在一段时间内处于无人监控的状态。 为了解决这个问题，我们确定了逐层评估信息系统状态最必要的指标列表，并开始实施。
因此，他们决定把大象分成几部分吃掉。
我们的系统包括：
- 硬件;
- 操作系统;
- 软件;
- 监控应用中的UI部分；
- 业务指标；
- 集成应用程序；
- 信息安全;
- 网络；
- 流量平衡器。
该系统的核心是自我监控。 为了大致了解整个系统的状态，您需要了解所有这些层上以及整个应用程序集上的应用程序发生了什么。
那么，关于堆栈。
我们使用开源软件。 我们的中心有 Zabbix，我们主要将其用作警报系统。 大家都知道它是基础设施监控的理想选择。 这是什么意思？ 正是每个维护自己的数据中心的公司（Sportmaster 也有自己的数据中心）所拥有的低级指标 - 服务器温度、内存状态、raid、网络设备指标。
我们已将 Zabbix 与 Telegram Messenger 和 Microsoft Teams 集成，这些在团队中积极使用。 Zabbix覆盖了实际网络层、硬件层和部分软件层，但它并不是万能的。 我们从其他一些服务中丰富了这些数据。 例如，在硬件层面，我们通过API直接连接到我们的虚拟化系统并收集数据。
还有什么。 除了 Zabbix 之外，我们还使用 Prometheus，它允许我们监控动态环境应用程序中的指标。 也就是说，我们可以通过 HTTP 端点接收应用程序指标，而不必担心哪些指标要加载到其中，哪些不加载。 基于这些数据，可以开发分析查询。
其他层的数据源（例如业务指标）分为三个部分。
首先，这些是外部业务系统，Google Analytics，我们从日志中收集指标。 我们从他们那里获得有关活跃用户、转化以及与业务相关的所有其他数据。 其次，这是一个UI监控系统。 应该更详细地描述它。
曾几何时，我们从手动测试开始，逐渐发展为功能和集成的自动测试。 由此我们进行了监控，只留下主要功能，并依赖于尽可能稳定且不会随时间经常变化的标记。
新的团队结构意味着所有应用活动都仅限于产品团队，因此我们不再做纯粹的测试。 相反，我们从测试中进行 UI 监控，用 Java、Selenium 和 Jenkins 编写（用作启动和生成报告的系统）。
我们进行了很多测试，但最终我们决定走主路，即顶级指标。 而且如果我们有很多具体的测试，就很难保持数据的最新性。 每个后续版本都会严重破坏整个系统，我们要做的就是修复它。 因此，我们专注于很少改变的非常基本的事情，我们只监控它们。
最后，第三，数据源是集中式日志系统。 我们使用 Elastic Stack 来记录日志，然后可以将这些数据提取到我们的业务指标监控系统中。 除此之外，我们还有自己的监控 API 服务，用 Python 编写，它通过 API 查询任何服务并将数据收集到 Zabbix 中。
监控的另一个不可或缺的属性是可视化。 我们的基于 Grafana。 它在其他可视化系统中脱颖而出，因为它允许您在仪表板上可视化来自不同数据源的指标。 我们可以收集在线商店的顶级指标，例如，过去一小时内从 DBMS 下的订单数量、Zabbix 运行该在线商店的操作系统的性能指标以及该应用程序实例的指标来自普罗米修斯。 所有这一切都将在一个仪表板上进行。 清晰易懂。
让我注意一下安全性 - 我们目前正在完成该系统，稍后我们将与全球监控系统集成。 在我看来，电子商务在信息安全领域面临的主要问题与机器人、解析器和暴力破解有关。 我们需要密切关注这一点，因为从业务角度来看，所有这些都会严重影响我们应用程序的运行和声誉。 通过所选的堆栈，我们成功地完成了这些任务。
还有一点很重要，应用层是由Prometheus组装的。 他本人也与Zabbix集成。 而且我们还有sitespeed，一个可以让我们查看页面加载速度、瓶颈、页面渲染、加载脚本等参数的服务，它也是API集成的。 因此，我们的指标是在 Zabbix 中收集的，相应地，我们也从那里发出警报。 目前所有警报均发送至主要发送方式（目前为电子邮件和电报，MS Teams 最近也已连接）。 有计划将警报升级到智能机器人作为服务工作并向所有感兴趣的产品团队提供监控信息的状态。
对我们来说，指标不仅对于单个信息系统很重要，而且对于应用程序使用的整个基础设施的一般指标也很重要：运行虚拟机的物理服务器集群、流量平衡器、网络负载平衡器、网络本身、通信通道的利用率。 加上我们自己的数据中心的指标（我们有几个数据中心，而且基础设施相当大）。
我们的监控系统的优势在于，借助它，我们可以了解所有系统的健康状况，并可以评估它们对彼此以及对共享资源的影响。 最终，它使我们能够参与资源规划，这也是我们的责任。 我们管理服务器资源 - 电子商务内的池、调试和退役新设备、购买额外的新设备、对资源利用率进行审核等。 每年，团队都会规划新项目、开发他们的系统，我们为他们提供资源非常重要。
在指标的帮助下，我们可以看到信息系统资源消耗的趋势。 基于它们我们可以计划一些事情。 在虚拟化级别，我们收集数据并查看有关数据中心可用资源量的信息。 在数据中心内部，您可以看到资源的回收、实际分配和消耗。 此外，无论是独立服务器还是虚拟机，以及所有这些虚拟机都在其上高速运转的物理服务器集群。
前途
现在整个系统的核心我们已经准备好了，但是还有很多事情需要去做。 至少，这是一个信息安全层，但到达网络、开发警报并解决相关问题也很重要。 我们有很多层和系统，每一层都有更多的指标。 原来是套娃程度的套娃。
我们的任务是最终发出正确的警报。 例如，如果硬件出现问题，或者虚拟机出现问题，并且有一个重要的应用程序，并且服务没有以任何方式备份。 我们发现虚拟机已经死了。 那么业务指标就会提醒你：用户已经消失在某处，没有转化，界面中的UI不可用，软件和服务也死掉了。
在这种情况下，我们将收到来自警报的垃圾邮件，这不再适合适当的监控系统的格式。 相关性的问题就出现了。 因此，理想情况下，我们的监控系统应该在一个警报的帮助下说：“伙计们，你们的物理机器已经死了，随之而来的是这个应用程序和这些指标”，而不是用一百个警报疯狂地轰炸我们。 它应该报告主要内容 - 原因，这有助于快速消除由于其本地化而导致的问题。
我们的通知系统和警报处理是围绕 XNUMX 小时热线服务构建的。 所有被视为必备且包含在清单中的警报都会发送到此处。 每个警报必须有一个描述：发生了什么、它实际意味着什么、它影响什么。 还有仪表板的链接以及有关在这种情况下该怎么做的说明。
这就是构建警报的要求。 那么情况可能会向两个方向发展——要么出现问题需要解决，要么监控系统出现故障。 但无论如何，你都需要去弄清楚。
考虑到警报的关联性尚未正确配置，我们现在平均每天收到大约一百个警报。 如果我们需要进行技术工作，并且我们强行关闭某些东西，那么它们的数量就会显着增加。
除了监控我们运营的系统并收集我们认为重要的指标之外，监控系统还允许我们为产品团队收集数据。 它们可以影响我们监控的信息系统内指标的组成。
我们的同事可能会要求添加一些对我们和团队都有用的指标。 或者，例如，团队可能没有我们拥有的足够的基本指标；他们需要跟踪一些特定的指标。 在 Grafana 中，我们为每个团队创建一个空间并授予管理员权限。 此外，如果一个团队需要仪表板，但他们自己不能/不知道如何去做，我们会帮助他们。
由于我们处于团队价值创造、发布和规划的流程之外，因此我们逐渐得出这样的结论：所有系统的发布都是无缝的，并且可以在不与我们协调的情况下每天推出。 对我们来说监控这些版本很重要，因为它们可能会影响应用程序的运行并破坏某些内容，这一点至关重要。 为了管理版本，我们使用 Bamboo，通过 API 接收数据，并可以查看哪些版本已在哪些信息系统中发布及其状态。 最重要的是在什么时间。 我们将发布标记叠加在主要关键指标上，这在出现问题时在视觉上非常具有指示性。
这样我们就可以看到新版本和新出现的问题之间的相关性。 主要思想是了解系统各层的工作原理，快速定位问题并尽快修复。 毕竟，很多时候花最多时间的不是解决问题，而是寻找原因。
未来在这个领域我们希望注重主动性。 理想情况下，我希望提前而不是事后了解即将出现的问题，以便我可以预防而不是解决它。 有时，由于人为错误和应用程序的更改，监控系统会发生误报。我们致力于此，对其进行调试，并尝试在对监控系统进行任何操作之前警告与我们一起使用它的用户。 ，或在技术窗口中执行这些活动。
因此，该系统已经启动，并且自春季开始以来一直在成功运行......并且正在显示出非常实际的利润。 当然，这不是它的最终版本；我们将引入更多有用的功能。 但现在，随着如此多的集成和应用程序，监控自动化确实是不可避免的。
如果您还监控具有大量集成的大型项目，请在评论中写下您为此找到的灵丹妙药。
来源： habr.com