如今，DevOps和SRE团队拥有许多工具来访问和分析日志数据。但是，有两个挑战阻止这些团队及时解决问题：他们没有配备所需的所有数据 检测和解决问题是被动的和手动的
在本文中，我将分解为什么这些挑战会持续存在，并提出一种新的可观察性方法来帮助您克服这些挑战。
DevOps和SRE团队需要了解他们的应用程序和服务的行为，以便在异常发生时发现它们并保持它们正常运行。然而，传统日志平台的成本使这些团队无法分析100%的可观察性数据。
相反，他们采用了减少摄入量的机制。在某些情况下，这意味着截断或过滤掉数据集。在其他情况下，这意味着将数据移动到不应用分析的不太活跃的存储层/目标。此外，工程师必须预先预测哪些数据集很重要并符合索引标准。团队能够实时分析的正是这些数据集。其余的最终都被忽略了。
净影响是团队对其环境的了解不完整，因此很难理解应用程序和服务的行为方式。因此，他们无法在每个问题发生时查明它。
挑战：传统平台创建反应式和手动流程
在使用传统的可观察性平台时，团队必须不断定义逻辑以检测其环境中的问题。通常，他们只能检测到他们意识到并有时间构建逻辑的问题。为了保持警报正确触发，您必须掌握不同的数据结构、不断变化的数据形状、新的模式和库以及波动的基线。
然而，并不是每个团队都有能力检测他们以前从未见过的问题。当团队面临未知行为时，他们将进行事后调试，这本质上是一个反应过程。此外，越来越难以快速解决问题，因为日志数据通常是非结构化的并且难以搜索。团队必须手动搜索日志线以查明活动和受影响的系统或组件。这种方法可以增加数小时甚至数天的调查时间。
为了捕捉每个问题并加快事件调查，团队可以在数据源上应用机器学习来检测潜在威胁，并为团队提供保持应用程序和服务运行所需的信息。这种方法允许工程师分析100%的日志数据，并将其编译成一个可使用且可操作的视图，以便他们能够比传统方法更快地发现行为变化并解决异常。
创建日志时，可以自动对其进行分析并将其转换为有洞察力的指标，从而为应用程序和服务行为提供信息。从那里，联合机器学习可用于自动检测问题并在问题发生时发出警报。它通过为关键指标设定基线、了解它们何时超出典型范围以及确定异常行为的可能性来实现——所有这些都通过机器学习来完成。
无需不断构建和完善逻辑，有效地消除了过度手动的工程实践。
发生问题时，开发人员和DevOps工程师将收到有关其系统内活动的具体变化的详细报告。在此报告中，他们将看到事件的确切时间窗口以及受影响的系统或元数据。该报告还包括精确捕获导致异常的相关原始数据，以及涉及的系统、组件或服务。
最后，相关的全保真日志可以在异常之前、期间和之后动态地流式传输到中央可观察性平台(Splunk、Datadog等)。这为团队提供了及时解决问题所需的准确数据。
总而言之，这种边缘可观察性允许系统管理员始终分析他们的所有日志，而不仅仅是那些与集中设置中的预定义查询匹配的日志，从而在事件响应方面节省大量时间。