你的企业是否需要集成监控策略？首先应考虑你的IT部门如何跟踪数据中心和公共云环境中的网络、系统、应用程序和其他基础架构元素的可靠性和性能。

他们很可能在使用很多不同的未整合的监控工具。

他们的“武器库”可能包括多个监控工具，以提醒正常运行时间、性能和事故。每个工具都提供底层问题的视图，并在既定操作范围内提供事件、指标、日志和诊断。每个公共云提供商也都有自己的原生工具。他们还可能有工具来监视应用程序运行状况、诊断数据库瓶颈、显示数据集成的状态或提供有关API吞吐量的见解。

这些工具仍在不断增加。几年前，一项关于应用程序性能监控工具的调查发现，65%的企业拥有10多种不同的商业监控产品，企业仅在使用其中50%或更少的工具。随着企业迁移到云端以及DevOps推动应用程序开发加速，这个数字仍在增加。实际上，其他供应商报告说，典型的客户使用30到50个独特的监控工具，每个监控工具的多个实例部署在庞大的基础架构中。

集成监控战略

对于很多IT企业而言，多年来，他们购买的这些孤立、未使用和未集成的监控工具不仅耗尽了有限的资源，而且还会导致性能问题：

• 从复杂事件中恢复很困难，并且，由于涉及的人员和使用的工具，诊断根本原因需要很长时间。IT企业要么无法测量平均恢复时间（MTTR），要么做得不是很好。企业需要太多时间和太多专业技能来诊断问题。
• 对于业务应用程序系统和网络的运行状况，企业需要满足关键性能指标，但他们很难获得全面数据以展示最终用户体验以及基础服务和系统的状况。
• 对于使用和数据量不断增长的应用程序，企业必须跟踪其性能以帮助预测何时需要扩展基础设施，或者何时应升级应用程序以解决可扩展性限制问题。
• 鉴于现在有很多IT工作流工具以及很多系统会发出警报，警报路由到正确的人员变得更加复杂。没有人希望看到单个事件导致多个监控工具触发数百或数千个警报。

4个集成监控战略

对于拥有太多监控工具而需要制定集成监控策略的企业而言，可考虑下面的方法：

1. 方法之一是减少监测工具的数量。据笔者所知，有家企业在单个公共云上标准化，使用该公共云的原生监控工具来覆盖基础架构，并且该公司大量使用Splunk来报告数据库和应用程序日志文件中的问题。

此方法适用于具有标准化架构、强大的应用程序开发标准和服务水平要求不高的企业。换句话说，并不适用于很多企业。对于具有更多异构环境、传统平台和复杂应用程序架构的大型企业而言，这种方法不太可行。

2. 第二种方法是开发直接绑定并集成到应用程序架构的监控方法。这种方法的示例是针对物联网数据的监控仪表板—通过使用AWS无服务器和托管服务。

这种方法适用于新开发的架构，可从头开始考虑监控和服务级别要求。它不适用于传统架构或者具有多种计算架构的企业。

3. 第三种方法是针对大型企业，这些企业具有更复杂环境，并试图开发自己的集成监控系统。这种方法是将所有监视工具的日志和数据聚合到一个中央数据仓库中。当数据集中后，便可以开发一组通用的报告仪表板、预测分析，以预测容量，以及实现更智能的警报–基于多个监控工具。如果你的企业已经拥有云数据库（例如AWS Relational Database Service，类似Talen的数据集成工具）方面的专业技能、对Databricks的建模专业技能以及Tableau等数据可视化工具，那么这可能是很有吸引力的选择。

对于这种方法，其开发和支持非常耗时且昂贵。

4. 最后一种方法是考虑自主运营平台。BigPanda等平台提供与监控工具、数据仓库和警报整合的开箱即用集成。通过结合人工智能和机器学习，这些平台创建了一个虚拟的统一监控架构，可实现智能事件管理。

通过集成监控创造业务价值

对于企业来说，提高业务价值的关键不是选择更多的监控工具，而是利用集成监控架构或自主运营平台带来的速度、见解和协作。

DevOps团队的目标应该是使用机器学习来推动事件响应改进。当集中数据后，可利用机器学习算法来关联警报、简化诊断并改善对关键事件的平均恢复时间。

集成监测策略可帮助企业提高效率。当数据聚合以及警报智能地分组到事件中，并路由到适当的人员时，这有助于释放其他不需要参与诊断或解决事件的人员。如果单个事件触发多个监视器，系统将能够识别数据库发出的第一个警报，而数据操作团队可能是第一个，也可能是唯一收到此警告的团队。当集成监控架构与Jira、ServiceNow、Slack等工作流工具整合时，这种方法很有效。当与客户服务团队共享事件通信时，此方法还可以改善客户体验。