免费监控解决方案:洞察力有限

在之前的博客中,我们讨论了基本实施中存在的一些免费监视解决方案所面临的挑战。 缺少CMDB和ITOM集成可能会阻止您轻松提取预先存在的权威基础架构配置数据,从而使您的速度降低。 缺乏自动化和未知的插件质量可能会增加进一步的摩擦-需要更多的编码,更多的专业知识,对解决方案验证的更多关注以及更仔细的手动步骤,然后您才能确信基本监控效果良好。

假设您具有强大的技术实力,可以帮助您的组织克服这些障碍,那么您现在就可以了解各个主机,VM和应用程序实例的运行状况。 但是,现代企业IT系统和应用程序(尤其是任务关键型系统)通常不驻留在单个主机上。 相反,它们通过群集来实现弹性:将主机分布在多个故障域中,并使用智能的联网软件来启用故障转移。 它们通过负载平衡和并行化来实现性能:在可用基础架构中扩展单片应用服务器或单个微服务,有时甚至动态地扩展。 它们共享依赖关系:例如,许多企业应用程序可能共享一个身份验证机制,访问集中式企业数据库集群,或者在单个云或容器编排框架(如OpenStack或Kubernetes)上运行。

免费监控解决方案通常无法对具有许多相互依赖元素的弹性集群和复杂业务服务进行建模。 分布式应用程序体系结构的部分目的是避免单点故障。 当多服务器,负载均衡层中的一台Web服务器向南移动或数据库集群中的一台服务器死机时,您的企业CRM解决方案不会崩溃。

免费的监视软件往往专注于单个组件,并且可能不容易配置为模型化系统级的弹性,服务相互依赖性或估计部分集群故障的性能影响。 这意味着您需要在两个不令人满意的选项之间进行选择。 您可以将监视平台配置为在任何单个群集组件发生故障时发出警报; 因此,存在过度警报,操作员精疲力竭以及相关成本和风险的风险。 或者,您可以抑制有关集群元素的警报,并相信集群技术将使关键服务100%地保持可用状态。 你感到幸运吗?

通常无法将免费的监视平台配置为估计基础结构级故障对业务服务可用性的性能影响 。 尽管分布式应用程序旨在最大程度地减少单点故障,但是任何基础结构级别的问题通常都会对性能产生影响。 有时这些足以以有意义的方式影响服务水平。 但是,很少有免费的监视平台可配置为测量这些影响,确定SLA或SLO是否处于危险之中,或提供明确的记录,说明在特定时间段内是否满足服务级别义务。 这使得断言合规性或限制可用性问题的声誉或财务影响变得更加困难,尤其是在这些问题不会导致应用程序完全崩溃的情况下。

要阅读本系列的其他博客,请访问:https://www.opsview.com/resources/free-alternative