openshift4下的Logging5.5新特性介绍

原文出自： https://cloud.redhat.com/blog/whats-new-in-red-hat-openshift-logging-5.5

（译者注： OpenShift 自带的日志组件，发展到 Logging5.5 的版本，技术上有了一个非常大的变化，本文论述了这些变化，以及我们如何在这些变化中受益）

正文开始：

长期以来，日志系统一直是所有可观测性解决方案的基石。

Vector 是我们日志堆栈的一个重要部分（译者注： Vector 是本文中 Logging5.5 版本采用的新的开源技术，如果对照EFK日志堆栈，Vector可以代替FluentD， https://vector.dev/ ）。 Vector 是 DevOps 团队的日志收集器和分析器，可将分布式日志从任何源处理到单个流，并可实时进行切片、切块、聚合和分析。

例如，使用 Vector 作为日志收集器，客户可以将日志发送到 Amazon CloudWatch 目的地进行进一步分析。此外，客户现在可以使用 JSON 格式将日志消息在单个日志实体封装为一个堆栈跟踪（译者注：简单地说，堆栈跟踪 /stacktrace 是抛出异常时应用程序正在进行的方法调用的列表，就是常见的 Java 的程序调用报错的时候抛出的那玩意）。

随着 Logging 5.5 的发布，用户现在可以使用全新的 Logging 视图插件。 OpenShift Console 中的日志视图（专用于日志浏览）允许用户深入研究系统问题的根本原因。这个新的日志视图显示原始日志条目，并允许用户按严重性过滤它们，以及放大以进行进一步调查。

这些更新提供了更好的产品支持和 OpenShift Console 内更好的开箱即用体验，涵盖 Red Hat Private 、 Hybrid 和 Managed 部署。

现在可以解决哪些问题？

与其他工具不同， Vector 诞生于 statsd 和 collected 等监控工具。它是用他们的仪器技术建造的。它将直接处理 JSON+StatsD 协议格式的数据，而不需要任何额外的配置或插件。

Vector-收集器

由于其内置的 Rust Vector 是一个高性能的可观察性数据路由器，它使得收集、转换和发送日志、度量和事件变得非常容易。

性能

最后，当您为您的环境选择一个开源收集器时，性能将是您日常操作的关键指标。那么，当谈到 CPU 、内存、 LPS （每秒日志数）和可伸缩性的资源消耗时， Vector 如何与其他人进行比较？在这篇博客文章中（ https://medium.com/ibm-cloud/log-collectors-performance-benchmarking-8c5218a08fea ），不同的日志收集器之间进行了有趣的性能比较。正如您所料， Vector 在 LPS 和每 CPU LPS 方面非常出色。可扩展性更好，内存消耗更少。但在 CPU 消耗方面，它有一个轻微的缺点，消耗略高一些。

简单

由于 Vector 是这个高性能收集器，它也是构建可观察性管道的一个很好的工具。当您收集所有日志时，您有时可能还希望将该数据传输给其他供应商。 Vector 与供应商无关，允许您从多个来源收集数据、转换数据并将其路由到任何其他供应商。

LOKI-日志聚合

（译者注： Loki 是 Logging5.5 版本采用的另一个新的开源技术， 如果对照EFK日志堆栈，Loki可以代替ElasticSearch， ， https://grafana.com/oss/loki/ ）

使用 Loki 的主要好处是它不索引所有日志行，只索引与日志行关联的标签。与传统的日志收集方式相比，此功能使 Loki 更快。 Loki 是一个为有效保存日志数据而优化的数据存储。日志数据的有效索引这一特性，将它与其他日志系统区分开来。与其他日志系统不同， Loki 索引基于标签，原始日志消息不被索引。

特征

索引日志的高效内存使用

通过在一组标签上建立索引，该索引可以显著小于其他日志聚合。更少的内存可以降低操作成本。 Loki 的体系结构具有出色的性能、低存储成本，将扩展需求和更容易调试的需求进行分离。与大多数日志服务器相比， Loki 对日志存储和索引采取了不同的方法。

与其把所有可能的东西都纳入索引， Loki 更喜欢有一个小索引。然后，该索引用于查找存储完整日志条目的数据块。当执行查询时，块被发送给处理客户端请求的分布式 grep 类服务进行处理。这允许保持良好的性能，而小索引和简单的碎片存储意味着只需要低成本的存储就可以保存数据。（译者注：有得必有失，由于没有进行全文索引，所以 Loki 的查询性能是低于 ES 的，但是对于给后台人员使用的低频场景，这个小缺点似乎可以忽略）

它还具有非常简单的存储要求。从 Loki 2.0 开始，拥有 S3 兼容存储就足够了。不需要额外的文档数据库。由于索引小，并且能够与 S3 这样的非常经济高效的存储一起工作， Loki 可以非常经济高效。

多租户

Loki 允许多个租户使用单个 Loki 实例。不同租户的数据与其他租户完全隔离。用户可以通过在代理中分配租户 ID 来配置多个租户。

LogQL、 LOKI查询语言

LogQL 是一种用于日志分析和可视化的新语言。它基于与 PromQL 相同的一些构造，但经过重新设计以满足那些不使用 Prometheus 的用户的需求。 LogQL 用户会发现， LogQL 是熟悉的、灵活的，可以用于生成日志查询。该语言还有助于从日志数据生成指标（译者注：没错，这一条模糊了监控和日志的边界，把 Prometheus+Grafana 和 EFK 的能力进行了融合），这是一个远远超过日志聚合的强大功能。

可扩展性

LOKI 在小范围内表现良好。在单进程模式下，所有必需的微服务都在一个进程中运行。单进程模式是测试 LOKI 、运行或小规模运行的理想模式。

LOKI 还可以进行水平扩展，以便大规模安装。 LOKI 的每个微服务组件都可以分解为一个单独的进程，并且该配置允许单独扩展这些组件。

灵活性

许多代理（客户端）都有插件支持。这允许当前可观察结构将 Loki 添加到其日志聚合工具中，而无需切换可观察堆栈的现有部分。

日志记录视图

使用 Logging 5.5 ，现在可以通过管理控制台访问日志视图（插件）。通过浏览 OpenShift 控制台的“观察” > “日志”页面，用户现在可以轻松搜索应用程序 / 基础设施 / 审核日志并按严重性进行筛选。因此， Logs 页面为 OpenShift Observability UI 的整体体验增加了巨大的价值。（译者注：由于 Grafana 社区组件的安全隐患频出， Redhat 在新的 OCP 版本中，把 Grafana 组件踢出了官方产品的包含范围，但是 Logi 的视图功能是无法像传统的 EFK 一样使用 Kibana 进行展示，所以现在Redhat重新实现了这部分展示功能）

我们下一步打算做什么？

如果您想在 Openshift 群集中使用 Elastic 或 Loki 日志组件，或转发到某个受支持的端点，我们建议您使用 OpenShift 产品自带的日志组件。随着我们进入下一个版本，我们计划在操作环境中添加数据保留 API 、基于日志的警报和警报。未来的开发将包括自动缩放、基于日志的指标和一些 OCP 仪表板。除此之外，日志视图插件将很快在开发人员控制台中提供，同时还将进行一系列用户体验改进，以更好地导航。敬请期待！