“Infrastructure”（基础架构）和“Logs”（日志）UI：操作人员与 Elasticsearch 交互的新途径

By
Dan Roscigno

在 Elastic Stack 6.5 版本中，我们发布了两种与数据交互的新途径：“Infrastructure”（基础架构）UI 和“Logs”（日志）UI。在 6.5 版本中，这两个工具尚处于公测版阶段，但稍后我会询问您更多的反馈信息。对于这两个新工具，我想略微谈一下设计初衷、用户体验和 UI 配置。下面我们先从“Logs”（日志）UI 开始。

“Logs”（日志）UI

设计初衷

下面这些话我已经耳熟能详：“就把日志给我，我不需要什么花哨的东西，我需要知道的都写在日志里了，我只要看日志”。我们听从您的心声，竭力改进，现提供三种方案供您选择：

一是使用功能更为强大的 tail -f 命令，在页面底部查看最近的记录；二是使用表格、图表、标签云等，获得良好的视觉体验；三是使用表格视图。您应该能够选用最适合自己的方式展开工作，Elastic Stack 的开放式设计也支持这一点。

Logs-small.jpg visuals-small.jpg discover-small.jpg

用户体验

使用“Logs”（日志）UI 与对日志文件执行 tail 命令类似，但可在一个控制台中查看来自所有系统的所有日志。日志源源不断地进入，视图底部是最近的记录，就像 tail -f 命令结果一样。默认情况下，“Logs”（日志）UI 会显示满足配置条件的所有日志的所有记录（下一节将做详细介绍）。当您在处理一个问题时，如果决定不需要将所有服务的所有日志都收集在一起（日志流入速度超过任何人的阅读速度），则只需在顶部搜索栏键入内容即可更改交互方式。例如，如果我只想看到 Apache httpd pod 中 Kubernetes 标签层为“frontend”的 404 错误，我只需在搜索栏中开始键入内容，并让自动完成功能帮我找到合适的日志即可：

而在以前，要想实现上述目的，我们需要打开终端，向您的 k8s 提供商提供身份验证，再找出您需要的 Pod，然后运行 kubectl logs -f … | grep 404（若在非容器架构中，我们则需要查找主机名、使用 SSH 登录，再对日志执行 tail 命令等），操作起来十分繁琐。我们希望您的生活更轻松，并以您想要的查看方式提供数据。

配置

“Logs”（日志 UI）文档还在原来的位置，这里我将重点介绍一些配置选项。以下是您可以粘贴到 config/kibana.yml 中的默认配置，然后根据这些默认配置进行修改：

xpack.infra.sources.default.logAlias: "filebeat-*"
xpack.infra.sources.default.fields.timestamp: "@timestamp"
xpack.infra.sources.default.fields.message: ['message', '@message']

配置非常简单，在“Logs”（日志）UI 中显示的这些现成行都是与 filebeat-* 别名匹配的每个索引的 message 字段。那么，如果您想添加所有的 Logstash 索引该怎么办呢？只需像这样修改 config/kibana.yml 条目中的 xpack.infra.sources.default.logAlias，然后重启 Kibana 即可：

#xpack.infra.sources.default.logAlias: "filebeat-*"
xpack.infra.sources.default.logAlias: "filebeat-*,logstash-*"

不要忘了重启 Kibana。重新打开“Logs”（日志）UI 并单击“Stream Live”（实时流式传输），您应会看到所有的 Logstash 和 Filebeat 日志都流入到“Logs”（日志）UI。

注意：如果您更习惯使用 Elasticsearch 别名，则只需将 xpack.infra.sources.default.logAlias 设置为别名的名称，然后根据需要更新别名即可。以下是使用 logs 别名的等效方法

创建别名：

curl -X POST "localhost:9200/_aliases" -H 'Content-Type: application/json' -d'
{
    "actions" : [
        { "add" : { "indices" : ["logstash-*", "filebeat-*"], "alias" : "logs" } }
    ]
}
'

更新 config/kibana.yml：

#xpack.infra.sources.default.logAlias: "filebeat-*"
xpack.infra.sources.default.logAlias: "logs"

“Infrastructure”（基础架构）UI

设计初衷

我看到了管理基础架构的三个基本成熟度级别：

  1. 发现故障，然后打开监测系统进行探查。
  2. 将所有系统的关键指标绘制在一个大仪表板上并仔细观察这些指标，然后深入研究问题所在。
  3. 借助机器学习实现操作自动化，进而发现正常行为，检测新出现的问题，并向操作人员发出警告。

“Infrastructure”（基础架构）UI 旨在让操作人员进入“在大型仪表板上绘制关键指标”的阶段。可以肯定地说，我们都需要进入“机器学习自动化阶段”；更多相关内容，请参阅 Elastic Machine Learning。如果您观看本博文末尾的视频，将会看到一个工作流：从一个机器学习作业的警告开始，然后依次是 APM、分布式跟踪、“Infrastructure”（基础架构）和“Logs”（日志）UI。在 Elasticsearch 中，将所有日志、指标、APM 和分布式跟踪结合在一起，让您能够使用各种分析和可视化工具呈现数据。

接下来，让我们来看看“Infrastructure”（基础架构）UI，然后再做深入学习。在这个视图中，我们看到的是 Kubernetes Pod，我已经将它们按命名空间进行了分组。我当前正在查看入站网络流量。通过右键单击其中一个 Pod，即可跳转到这个 Pod 的日志，或者跳转到为其精心组织的指标仪表板。

用户体验

目前支持三种类型的设备：主机、Kubernetes (k8s) Pod 和 Docker 容器。“Infrastructure”（基础架构）UI 的强大之处在于，您可以看到大量设备中关键指标的状态。指标数量较多时，在您使用搜索栏或单击某个组深入到一个感兴趣的子集前，看到的都将是没有文本的彩色方块。此外，您还可以启动一个设备的日志，或者显示一个指标仪表板。

我提到过“关键指标”；目前就是这个列表，它们都来自 Metricbeat：

主机：CPU、内存、负载、入站流量、出站流量及日志速率
Kubernetes：CPU、内存、入站流量、出站流量
Docker： CPU、内存、入站流量、出站流量

通过分组可使您放大设备列表。如果您支持使用 Kubernetes 部署的特定应用程序，则适合用命名空间组。如果您认为某个问题与某个特定节点过载有关，则需要通过按命名空间和节点进行分组来进一步细分。以下是目前的分组列表（每种设备类型最多可以使用两个分组）：

主机：可用区域、机器类型、项目 ID、云服务提供商
Kubernetes：命名空间、节点
Docker：主机、可用区域、机器类型、项目 ID、提供商

如果上面的分组都不支持您希望的数据交互方式，则可以使用搜索栏。只需开始键入内容，Kibana 查询语言 (KQL) 自动完成功能就会提供引导。我在前述“Logs”（日志）UI 的 GIF 图中提供了一个示例，当我开始键入 kubernetes 时，Kibana 便会依次提供 labels 和 tier，并随后根据 Elasticsearch 中索引的内容提供可能的选择。

在您对资源进行分组后，即可通过单击它进行深入查看，让您看到该组的更多细节。 如果您对某个特定的主机、Pod 或容器感兴趣，则可以深入研究它的日志或指标。 以下是主机指标视图的一部分：

配置

对于“Infrastructure”（基础架构）UI 几乎不需要进行任何配置。只需部署 Metricbeat 并启用系统模块即可。如果您运行的是容器，则还需要启用 Kubernetes 和 Docker 模块。

除非您修改了默认索引模式 (metricbeat-*)，否则配置既告完成。如果您需要定制某些选项，请参考“Infrastructure”（基础架构）UI 文档，其中有详细介绍。我在这里只列出一些关键选项：

xpack.infra.sources.default.metricAlias: "metricbeat-*"
xpack.infra.sources.default.fields.host: "beat.hostname"
xpack.infra.sources.default.fields.container: "docker.container.name"
xpack.infra.sources.default.fields.pod: "kubernetes.pod.name"

说说您的看法

这两个 UI 均处于公测版阶段，我们非常期待您的反馈，即使在正式发布后也欢迎您持续提出宝贵意见。请告诉我们您更喜欢的数据交互方式。在此公测版的“Infrastructure”（基础架构）UI 中，分组是否足以支持贵团队的组织方式？怎样会更好？我们有合适的指标来驱动颜色吗？您是否需要其他途径来筛选“Logs”（日志）UI 中的日志？当您从“Infrastructure”（基础架构）UI 中启动指标视图时，是否看到了您所关心的指标？

前往 Kibana 论坛，告诉我们您喜欢什么、不喜欢什么，以及需求等等。开发人员会阅读并回应这些讨论，并希望收到您的反馈。此外，您还可以在 GitHub 上开立问题，提交 PR，或密切跟踪它们的状态。

快来试试吧

我们的实时演示系统提供了您可以进行搜索、可视化和交互的日志和指标。 转到“Infrastructure”（基础架构）磁贴并单击，启动“Infrastructure”（基础架构）UI：

JumpIn.jpg

您可以切换到 Kubernetes 或 Docker 视图，使用 UI 分组对象，或者 使用搜索栏缩小视图。 左键单击主机、Pod 或容器并启动该对象的“Logs”（日志）UI。当您位于 demo.elastic.co 时，不妨看看部分 仪表板和可视化效果。 您可以从 登录页导航到不同区域。

观看演示

下面是一段视频，展示了这些 UI 的工作流，以及机器学习和具有分布式跟踪的 APM！再次感谢您的阅读和反馈！