Elastic 采用开源和开放标准。了解如何引入 Prometheus 指标并使用 ELK Stack 将指标与所有其他数据一起可视化。

<p>本篇博文将介绍以下内容：
</p><ul>
	<li>为什么开放标准很重要</li>
	<li>Prometheus 公开格式</li>
	<li>Elastic 如何看待可观察性</li>
	<li>Elasticsearch 可以使用 Prometheus 指标的三种方式</li>
	<li>举例说明如何收集和可视化由 
Prometheus Redis 导出器公开的指标
	</li>
</ul><h2>开放标准</h2><p>在  
	<a href="http://opensource.com">opensource.com</a> 上，有一篇名为“<a href="https://opensource.com/resources/what-are-open-standards">什么是开放标准？</a>”的参考性资源文档。 在该文档中
阐述了很多重要观点，但基于多年的
操作经验来看，我对下面几点比较认同：
</p><ol start="1">
	<li>可用性：开放标注可供所有人读取和
实施。
	</li>
	<li>使最终用户的选择最大化</li>
	<li>无歧视（供应商中立）：开放标准以及
管理开放标准的组织不会偏爱
其中的某个实施者。
	</li>
	<li>没有刻意的秘密：标准不得隐瞒
针对可互操作实施所必需的任何详细信息。
	</li>
</ol><p>这些无可争议的理由足以说明为什么开放标准是优秀的了。
接下来，我们先来谈谈为什么  
	<a href="https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md">
	Prometheus 公开格式</a>是 <a href="https://openmetrics.io/">
	OpenMetrics</a> 的基础。在 <a href="https://promcon.io/2018-munich/slides/openmetrics-transforming-the-prometheus-exposition-format-into-a-global-standard.pdf">
	PromCon 2018</a> 和 KubeCon + <a href="https://www.youtube.com/watch?v=DARVop91kBQ">
	CloudNativeCon</a> North America 2018 的会谈中，Richard Hartmann 总结了
受 
Prometheus 公开格式影响而创建开放标准的几点原因：
</p><ul>
	<li>大部分数据格式是专有的，或者很难实施，
亦或是两种情况都有
	</li>
	<li>Prometheus 已成为云原生
指标监测的实际标准
	</li>
	<li>公开数据的易用性使得<a href="https://prometheus.io/docs/instrumenting/exporters/">
	兼容指标端点</a>出现激增</li>
	<li>Prometheus 的公开格式虽然是基于大量操作
经验，但一直是在少数人之中设计的
	</li>
	<li>其他一些项目和供应商在采用
“竞争性”产品中的某些功能时极为受挫
	</li>
</ul><h2>Prometheus 公开格式</h2><p>您可以在 <a href="https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md">
	Prometheus Github 存储库</a>中阅读有关公开格式的信息。现在，我们来看一个示例。
 我有一个导出器，
	<a href="https://github.com/oliver006/redis_exporter">
	Oliver006 Redis 导出器</a>，其在 
/metrics 端点的端口 9121 上发布指标。 我在这里只介绍有关 
Redis 的“每秒即时操作数”指标的信息。 有三行
需要阅读：
</p><ol start="1">
	<li>帮助文本</li>
	<li>指标类型（在此用例中为仪表）</li>
	<li>当前测量的 Redis 服务器（localhost 端口 6379），及其
当前读数（每秒操作数为 9 个）
	</li>
</ol><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltdc2597dd9d329537/5cd475e29033f96a5b031b8b/roscigno-prometheus-exposition-format.png" data-sys-asset-uid="bltdc2597dd9d329537" alt="roscigno-prometheus-exposition-format.png">
</p><h2>Elastic 可观察性</h2><p>我建议您阅读有关 <a href="/cn/blog/observability-with-the-elastic-stack">
	Elastic 如何看待可观察性</a>的文章，但其中
我最喜欢的部分是：
</p><blockquote>设计和构建“可观察”系统的目标在于，
确保当它在生产中运行时，
负责操作它的人员能够检测到不良行为（例如，服务停机、
错误、响应缓慢），并拥有可操作的信息，
以有效地确定根本原因（例如，详细的事件日志、
细粒度的资源使用信息，以及应用程序跟踪）。
</blockquote><p>我完全同意这种说法，它表明
我们需要所有日志、指标和跟踪信息，以运行、
修复和管理我们提供的服务。 Prometheus 是
可观察性中极其重要的一部分，因为它已被广泛采用
且拥有活跃的社区。 只有为“操作中产生”的符合常理的指标格式
扫除了采用障碍（无论这些障碍是真实的还是感知的），
OpenMetrics 标准才会实现增值。
</p><p>我交谈过的大部分人对使用 Elastic
Stack (ELK) 进行日志分析都十分熟悉。 如果您不了解 Elastic
Stack 还非常适合指标和 APM，请查看 
	<a href="/cn/blog/elasticsearch-as-a-time-series-database-for-telemetry-data-at-ns1">
	指标</a>和 <a href="/cn/solutions/apm">
	APM/分布式跟踪</a>。
</p><p>我们认为，在 Elastic Stack 和 Prometheus 指标导出方式之间
进行深度集成很有意义，主要原因如下：
</p><ul>
	<li>在 Elasticsearch 中将指标与日志和 APM 合并，
并在 Kibana 中将它们关联起来。请查看来自 NS1 的 
	一个
	<a href="/cn/blog/elasticsearch-as-a-time-series-database-for-telemetry-data-at-ns1">
	用户案例</a>，了解有关在 Elastic
Stack 中合并日志与指标的信息。
	</li>
	<li>使用 Elasticsearch 作为长期存储，用于通过 Prometheus 服务器收集的指标，
Prometheus 服务器目前
不支持原生集群。
	</li>
	<li>对分散在不同地理位置
的 Prometheus 实例的指标实现全球查看。
	</li>
</ul><p>本博文的其余部分将详细描述我们如何实现这些
集成。
</p><h3>示例导出器</h3><p>我的演示环境运行于 Google 
Kubernetes 引擎 (GKE) 中，所以我的应用程序、
Metricbeat 和 Prometheus 导出器都是在 Kubernetes 中运行。 下面
是一段 Oliver006 的清单，用于将 Redis 导出器部署
为 Redis 映像旁边的挎斗。 如您所见，导出器
在端口 9121 上发布指标，这是 Prometheus Redis 导出器的 
	<a href="https://github.com/prometheus/prometheus/wiki/Default-port-allocations">
	默认分配的端口号</a>
	。
</p><pre class="prettyprint">...
  - name: redis-exporter
    image: oliver006/redis_exporter:latest
    resources:
      requests:
        cpu:100m
        memory:100Mi
    ports:
    - containerPort:9121
...
</pre><p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/guestbook.yaml">GitHub 中的完整源代码</a>
</p><h3>使用 Metricbeat Prometheus 模块收集指标
</h3><p><a href="/cn/beats/metricbeat">Metricbeat</a> 是 Elastic 的轻量型指标采集器。 Metricbeat 随附的 
	<a href="/guide/en/beats/metricbeat/7.0/metricbeat-module-prometheus.html">
	Prometheus 模块</a>可以采用三种方式
收集指标：
</p><ol start="1">
	<li>通过端口 9090 连接到 Prometheus 服务器，
并使用 Prometheus 联合 API 拉取已收集的指标
（以获得 Prometheus 收集的指标）
	</li>
	<li>使用 /metrics 端点
通过端口 9090 连接到 Prometheus 服务器（Prometheus 自我监测）
	</li>
	<li>连接到各个 Prometheus 导出器并解析
公开格式
	</li>
</ol><p>至于您选择哪种方法收集指标，要取决于
您对 Prometheus 服务器的熟悉程度。
</p><ul>
	<li>如果您已经设置了 Prometheus 服务器来收集指标，
并希望直接查询这些指标以进行集成，
则可以从选项 (1) 和 (2) 入手。
	</li>
	<li>另一方面，如果您还没有 Prometheus 服务器，
或者不介意通过多个工具并行收集导出器，
则可以使用选项 (3)。
	</li>
</ul><p>注意：上述某些 Metricbeat 功能在
Metricbeat 版本 7.0 中为公测版。 我们建议您 
	<a href="/cn/downloads ">下载 7.0 公测版</a>，
	或从 
	<a href="https://www.docker.elastic.co/">
	https://www.docker.elastic.co/</a> 复制容器链接，并在非生产环境中运行公测版。
</p><h3>Prometheus 联合 API</h3><p>一般来说，联合用于支持扩展、将数据集合并在一起，或在不同位置提供数据副本（用于灾难恢复）。 Prometheus 服务器提供一个 <a href="https://prometheus.io/docs/prometheus/latest/federation/"><code>/federation</code> 端点</a>，Elastic 可以连接到此端点，以复制 Prometheus 出于上述原因而收集的指标。
</p><pre class="prettyprint">...
  - module: prometheus
    period:10s
    hosts: ["prometheus-service.monitoring.svc.cluster.local:9090"]
    metrics_path: '/federate'
    query:
      'match[]': '{__name__!=""}'
...
</pre><p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-kube-state-and-prometheus-server.yaml">GitHub 中的完整源代码</a><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-kube-state-and-prometheus-server.yaml"></a>
</p><p>在上例中，查询设置为“具有非空名称的任何内容”。 您不需要获取所有内容，Prometheus 文档中包含了有关如何编写更具限制性的匹配条件的信息。 此外，该示例中将期间设置为每 10 秒连接到 Pometheus 服务器一次，我的演示服务器仅从少数 Pod 和 kube-state-metrics 收集指标，但您可能需要更改该时间间隔。
</p><h3>Prometheus 自我监测</h3><p>Prometheus 提供一个 <code>/metrics</code> 端点，像导出器一样。 这样您就可以收集有关 Prometheus 服务器的指标。 该端点的配置如下：
</p><pre class="prettyprint">...
  - module: prometheus
    period:10s
    hosts: ["prometheus-service.monitoring.svc.cluster.local:9090"]
    metrics_path: /metrics
...
</pre><p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-kube-state-and-prometheus-server.yaml">GitHub 中的完整源代码</a>
</p><h3>Prometheus 导出器收集</h3><p>某一清单中的这段 YAML 用于部署一个 Metricbeat
DaemonSet，告知 Metricbeat 自动发现
其中  
	<code>kubernetes.labels.app</code> == <code>redis</code> 的内容，并从该 Pod 
的端口 9121 读取指标。 请记住，为 Redis 导出器容器设置的 containerPort 
为 9121。
</p><pre class="prettyprint">...
- condition.equals:
    kubernetes.annotations.prometheus.io/scrape: "true"
  config:
    - module: prometheus
      period:10s
      # Redis pods
      hosts: ["${data.host}:9121"]
      metrics_path: /metrics
...
</pre><p>部署 Metricbeat 后，任何满足条件 
kubernetes.labels.app == redis 的 Pod 都会应用 Prometheus 模块，
并从
端口 9121 的导出器挎斗中收集指标。
</p><p>但是，在 k8s 环境中怎能缺了元数据呢，对吗？ 让我们用
元数据和 Beats 自动发现功能来一展身手。 请看下面这段代替
上述 YAML 的内容：
</p><pre class="prettyprint">...
- condition.equals:
    kubernetes.annotations.prometheus.io/scrape: "true"
  config:
    - module: prometheus
      period:10s
      hosts: ["${data.host}:${data.kubernetes.annotations.prometheus.io/port}"]
      metrics_path: /metrics
...
</pre><p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-prometheus-auto-discover.yaml">GitHub 中的完整源代码</a>
</p><p>现在，我们寻找的不是 Redis pod 的导出器，
而是任何注释 
	<code>kubernetes.annotations.prometheus.io/scrape</code> 设置为 true 的 Pod 导出器。 这也是 
Prometheus 自动发现的设置方式。 通常情况下，Metricbeat 
自动发现由 elastic.co 
命名空间中的注释驱动，但既然我们在讨论从 Prometheus 
导出器读取，我们就应遵守与 
Prometheus 关联的标准 k8s 注释。 如果您查看上述内容中的主机列表：
</p><p><code>hosts: ["${data.host}:${data.kubernetes.annotations.prometheus.io/port}"]</code>
</p><p>您可以看到，我们不再硬编码端口 9121，因为
它是 Redis 导出器的端口。 注释  
	<code>prometheus.io/port</code> 设置为导出器的端口号。 为了完整起见，
下面提供一段 guestbook.yaml，
其中设置了这些注释：
</p><pre class="prettyprint">...
kind:Deployment
metadata:
  name: redis-master
spec:
  replicas:1
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port:"9121"
      labels:
        app: redis
...
</pre><p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/guestbook.yaml">GitHub 中的完整源代码</a>
</p><p>我提到过元数据在 k8s 环境中不可或缺吗？
那不是七十年代后期的一首歌吗？
</p><h3>通过可视化获得洞察力</h3><p>虽然将数据引入 Elastic Stack 非常好，但您必须能够与数据进行交互。 在以下视频中，我们将看到如何使用由 Prometheus 收集（然后导入 Elastic Stack）的 Redis 指标，以及使用 Metricbeat 直接从 kube-state-metrics 收集的 Kubernetes 事件来构建有用的可视化。
</p><p>如果您希望按照视频操作并获得更详细的说明，请
参阅 
	<a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/README.md">
	示例存储库</a>。
</p><div class="video embed-container" style="height: 319.725px;">
	<img style="width: 100%; margin: auto; display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/kt1jkhu1sptWzV3Y1wrfwE.jpg" data-uuid="kt1jkhu1sptWzV3Y1wrfwE" data-v="4" data-type="inline">
</div><h2>返回可观察性</h2><p>在最后这部分，我们为 Oliver006 Redis 导出器公开的
关键 Redis 指标（每秒即时操作数）
创建了一个 Kibana 可视化。 我们的下一步是收集日志，
然后创建一个仪表板，并在
我们的应用程序中将日志和指标合并在一起。
</p><p>如需了解如何在 Kubernetes 环境中收集日志，
我建议您按照  
	<a href="https://github.com/elastic/examples/blob/master/MonitoringKubernetes/README.md">
	elastic/examples</a> GitHub 存储库中的说明进行操作。 只需几分钟，即可
让 Filebeat、Metricbeat 和 Packetbeat 收集数据，并
发布到 Elasticsearch。 使用随附的各种 Beats 的示例仪表板，
您可以随意
为 Prometheus 数据创建自己的可视化，并混合使用这些可视化，
以创建适合您工作方式的仪表板。如果您遇到任何问题或希望讨论可观察性，请访问 
	<a href="https://discuss.elastic.co">讨论</a>论坛。
</p>

blog-roscigno-wide.jpg

blog-roscigno-thumb.png

Elasticsearch Observability: Embracing Prometheus and OpenMetrics Standards for Metrics

Elasticsearch 可观察性：采用 Prometheus 和 OpenMetrics 标准收集指标

介绍新的“Logs”（日志）UI 和“Infrastructure”（基础架构）UI。使用 Elastic Stack 管理您的环境从未像现在这样简单。

<p>在 Elastic Stack 6.5 版本中，我们发布了两种与数据交互的新途径：“Infrastructure”（基础架构）UI 和“Logs”（日志）UI。在 6.5 版本中，这两个工具尚处于公测版阶段，但稍后我会询问您更多的反馈信息。对于这两个新工具，我想略微谈一下设计初衷、用户体验和 UI 配置。下面我们先从“Logs”（日志）UI 开始。
</p>
<h2>“Logs”（日志）UI
</h2>
<h3>设计初衷
</h3>
<p>下面这些话我已经耳熟能详：“就把日志给我，我不需要什么花哨的东西，我需要知道的都写在日志里了，我只要看日志”。我们听从您的心声，竭力改进，现提供三种方案供您选择：
</p>
<p>一是使用功能更为强大的 <code>tail -f</code> 命令，在页面底部查看最近的记录；二是使用表格、图表、标签云等，获得良好的视觉体验；三是使用表格视图。您应该能够选用最适合自己的方式展开工作，Elastic Stack 的开放式设计也支持这一点。
</p>
<table border="0" style="width:100%">
<tbody>
<tr>
	<td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf9bdf54b4eeab8bc/5c57d6fb85820dce0bcc2bf5/Logs-small.jpg" data-sys-asset-uid="bltf9bdf54b4eeab8bc" alt="Logs-small.jpg" style="background-color: initial;">
	</td>
	<td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1af8714b20964974/5c57d6ef16a7de000c2b32a0/visuals-small.jpg" data-sys-asset-uid="blt1af8714b20964974" alt="visuals-small.jpg">
	</td>
	<td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7193fa48ab952fe4/5c57d6e94c9f4feb0b4c5843/discover-small.jpg" data-sys-asset-uid="blt7193fa48ab952fe4" alt="discover-small.jpg">
	</td>
</tr>
</tbody>
</table>
<h3>用户体验</h3>
<p>使用“Logs”（日志）UI 与对日志文件执行 tail 命令类似，但可在一个控制台中查看来自所有系统的所有日志。日志源源不断地进入，视图底部是最近的记录，就像 <code>tail -f</code> 命令结果一样。默认情况下，“Logs”（日志）UI 会显示满足配置条件的所有日志的所有记录（下一节将做详细介绍）。当您在处理一个问题时，如果决定不需要将所有服务的所有日志都收集在一起（日志流入速度超过任何人的阅读速度），则只需在顶部搜索栏键入内容即可更改交互方式。例如，如果我只想看到 Apache httpd pod 中 Kubernetes 标签层为“frontend”的 404 错误，我只需在搜索栏中开始键入内容，并让自动完成功能帮我找到合适的日志即可：
</p>
<p><img src="https://www.elastic.co/assets/bltf003bd0045b7cf86/animated-gif-logs-ui-optimized.gif">
</p>
<p>而在以前，要想实现上述目的，我们需要打开终端，向您的 k8s 提供商提供身份验证，再找出您需要的 Pod，然后运行 <code>kubectl logs -f … | grep 404</code>（若在非容器架构中，我们则需要查找主机名、使用 SSH 登录，再对日志执行 tail 命令等），操作起来十分繁琐。我们希望您的生活更轻松，并以您想要的查看方式提供数据。
</p>
<h3>配置</h3>
<p><a href="/guide/en/kibana/6.x/xpack-logs.html">“Logs”（日志 UI）文档</a>还在原来的位置，这里我将重点介绍一些配置选项。以下是您可以粘贴到 <code>config/kibana.yml</code> 中的默认配置，然后根据这些默认配置进行修改：
</p>
<pre class="prettyprint">xpack.infra.sources.default.logAlias: "filebeat-*"
xpack.infra.sources.default.fields.timestamp: "@timestamp"
xpack.infra.sources.default.fields.message: ['message', '@message']
</pre>
<p>配置非常简单，在“Logs”（日志）UI 中显示的这些现成行都是与 <code>filebeat-*</code> 别名匹配的每个索引的 <code>message</code> 字段。那么，如果您想添加所有的 Logstash 索引该怎么办呢？只需像这样修改 <code>config/kibana.yml</code> 条目中的 <code>xpack.infra.sources.default.logAlias</code>，然后重启 Kibana 即可：
</p>
<pre class="prettyprint">#xpack.infra.sources.default.logAlias: "filebeat-*"
xpack.infra.sources.default.logAlias: "filebeat-*,logstash-*"
</pre>
<p>不要忘了重启 Kibana。重新打开“Logs”（日志）UI 并单击“Stream Live”（实时流式传输），您应会看到所有的 Logstash 和 Filebeat 日志都流入到“Logs”（日志）UI。
</p>
<p><strong>注意</strong>：如果您更习惯使用 <a href="/guide/en/elasticsearch/reference/6.5/indices-aliases.html">Elasticsearch 别名</a>，则只需将 <code>xpack.infra.sources.default.logAlias</code> 设置为别名的名称，然后根据需要更新别名即可。以下是使用 <code>logs</code> 别名的等效方法
</p>
<p>创建别名：
</p>
<pre class="prettyprint">curl -X POST "localhost:9200/_aliases" -H 'Content-Type: application/json' -d'
{
    "actions" : [
        { "add" : { "indices" : ["logstash-*", "filebeat-*"], "alias" : "logs" } }
    ]
}
'
</pre>
<p>更新 config/kibana.yml：
</p>
<pre class="prettyprint">#xpack.infra.sources.default.logAlias: "filebeat-*"
xpack.infra.sources.default.logAlias: "logs"
</pre>
<h2>“Infrastructure”（基础架构）UI</h2>
<h3>设计初衷</h3>
<p>我看到了管理基础架构的三个基本成熟度级别：
</p>
<ol>
	<li>发现故障，然后打开监测系统进行探查。</li>
	<li><span></span>将所有系统的关键指标绘制在一个大仪表板上并仔细观察这些指标，然后深入研究问题所在。</li>
	<li>借助机器学习实现操作自动化，进而发现正常行为，检测新出现的问题，并向操作人员发出警告。</li>
</ol>
<p>“Infrastructure”（基础架构）UI 旨在让操作人员进入“在大型仪表板上绘制关键指标”的阶段。可以肯定地说，我们都需要进入“机器学习自动化阶段”；更多相关内容，请参阅 <a href="/cn/products/stack/machine-learning">Elastic Machine Learning</a>。如果您观看本博文末尾的视频，将会看到一个工作流：从一个机器学习作业的警告开始，然后依次是 APM、分布式跟踪、“Infrastructure”（基础架构）和“Logs”（日志）UI。在 Elasticsearch 中，将所有日志、指标、APM 和分布式跟踪结合在一起，让您能够使用各种分析和可视化工具呈现数据。
</p>
<p>接下来，让我们来看看“Infrastructure”（基础架构）UI，然后再做深入学习。在这个视图中，我们看到的是 Kubernetes Pod，我已经将它们按命名空间进行了分组。我当前正在查看入站网络流量。通过右键单击其中一个 Pod，即可跳转到这个 Pod 的日志，或者跳转到为其精心组织的指标仪表板。
</p>
<p><img src="https://www.elastic.co/assets/bltf64d638716ce8cd4/screenshot-infra-ops-ui-kubernetes.jpg">
</p>
<h3>用户体验</h3>
<p>目前支持三种类型的设备：主机、Kubernetes (k8s) Pod 和 Docker 容器。“Infrastructure”（基础架构）UI 的强大之处在于，您可以看到大量设备中关键指标的状态。指标数量较多时，在您使用搜索栏或单击某个组深入到一个感兴趣的子集前，看到的都将是没有文本的彩色方块。此外，您还可以启动一个设备的日志，或者显示一个指标仪表板。
</p>
<p>我提到过“关键指标”；目前就是这个列表，它们都来自 Metricbeat：
</p>
<p style="margin-left: 20px;">主机：CPU、内存、负载、入站流量、出站流量及日志速率 <br>
	Kubernetes：CPU、内存、入站流量、出站流量 <br>
	Docker： CPU、内存、入站流量、出站流量
</p>
<p>通过分组可使您放大设备列表。如果您支持使用 Kubernetes 部署的特定应用程序，则适合用命名空间组。如果您认为某个问题与某个特定节点过载有关，则需要通过按命名空间和节点进行分组来进一步细分。以下是目前的分组列表（每种设备类型最多可以使用两个分组）：
</p>
<p style="margin-left: 20px;">主机：可用区域、机器类型、项目 ID、云服务提供商 <br>
	Kubernetes：命名空间、节点 <br>
	Docker：主机、可用区域、机器类型、项目 ID、提供商
</p>
<p>如果上面的分组都不支持您希望的数据交互方式，则可以使用搜索栏。只需开始键入内容，<a href="/guide/en/kibana/6.5/kuery-query.html">Kibana 查询语言</a> (KQL) 自动完成功能就会提供引导。我在前述“Logs”（日志）UI 的 GIF 图中提供了一个示例，当我开始键入 <code>kubernetes</code> 时，Kibana 便会依次提供 <code>labels</code> 和 <code>tier</code>，并随后根据 Elasticsearch 中索引的内容提供可能的选择。
</p>
<p>在您对资源进行分组后，即可通过单击它进行深入查看，让您看到该组的更多细节。 如果您对某个特定的主机、Pod 或容器感兴趣，则可以深入研究它的日志或指标。 以下是主机指标视图的一部分：
</p>
<p><img src="https://www.elastic.co/assets/bltca514c310b636e2d/screenshot-metrics-infrastructure-monitoring.png">
</p>
<h3>配置</h3>
<p>对于“Infrastructure”（基础架构）UI 几乎不需要进行任何配置。只需部署 Metricbeat 并启用<a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-system.html">系统模块</a>即可。如果您运行的是容器，则还需要启用 <a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-kubernetes.html">Kubernetes</a> 和 <a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-docker.html">Docker 模块</a>。
</p>
<p>除非您修改了默认索引模式 (<code>metricbeat-*</code>)，否则配置既告完成。如果您需要定制某些选项，请参考<a href="/guide/en/kibana/6.x/xpack-infra.html">“Infrastructure”（基础架构）UI 文档</a>，其中有详细介绍。我在这里只列出一些关键选项：
</p>
<pre class="prettyprint">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"
</pre>
<h2>说说您的看法</h2>
<p>这两个 UI 均处于公测版阶段，我们非常期待您的反馈，即使在正式发布后也欢迎您持续提出宝贵意见。请告诉我们您更喜欢的数据交互方式。在此公测版的“Infrastructure”（基础架构）UI 中，分组是否足以支持贵团队的组织方式？怎样会更好？我们有合适的指标来驱动颜色吗？您是否需要其他途径来筛选“Logs”（日志）UI 中的日志？当您从“Infrastructure”（基础架构）UI 中启动指标视图时，是否看到了您所关心的指标？
</p>
<p>前往 <a href="https://discuss.elastic.co/c/kibana">Kibana 论坛</a>，告诉我们您喜欢什么、不喜欢什么，以及需求等等。开发人员会阅读并回应这些讨论，并希望收到您的反馈。此外，您还可以在 <a href="https://github.com/elastic/kibana">GitHub</a> 上开立问题，提交 PR，或密切跟踪它们的状态。
</p>
<h2>快来试试吧</h2>
<p>我们的实时<a href="https://demo.elastic.co/">演示系统</a>提供了您可以进行搜索、可视化和交互的日志和指标。
转到“Infrastructure”（基础架构）磁贴并单击，启动“Infrastructure”（基础架构）UI：
</p>
<p><a href="https://demo.elastic.co"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc85a8861b14f7f05/5c57d682a669c2e50b763c45/JumpIn.jpg" data-sys-asset-uid="bltc85a8861b14f7f05" alt="JumpIn.jpg" width="200" height="187"></a>
</p>
<p>您可以切换到 Kubernetes 或 Docker 视图，使用 UI 分组对象，或者 
使用搜索栏缩小视图。 左键单击主机、Pod 或容器并启动该对象的“Logs”（日志）UI。当您位于 demo.elastic.co 时，不妨看看部分 
仪表板和可视化效果。 您可以从 
	<a href="https://demo.elastic.co/">登录页</a>导航到不同区域。
</p>
<h2>观看演示</h2>
<p>下面是一段视频，展示了这些 UI 的工作流，以及机器学习和具有分布式跟踪的 APM！再次感谢您的阅读和反馈！
</p>
<div class="video embed-container" style="height: 478px;">
	<img style="width: 100%; margin: auto; display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/78EpMXQeU57jR7HrKsMXqK.jpg" data-uuid="78EpMXQeU57jR7HrKsMXqK" data-v="4" data-type="inline">
</div>

infrastructure-and-logs-background.jpg

infrastructure-and-logs-thumbnail.jpg

Infrastructure and Logs UI: New ways for Ops to interact with Elasticsearch

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

使用 Elastic Stack 监测 Docker 和 Kubernetes 日志和指标。通过 Beats 传输容器数据，使用 Elasticsearch 对这些数据进行分析，并在 Kibana 中实现可视化。

<p>本篇博文讲的是如何监测容器环境，容器环境包括 <a href="https://cloud.google.com/kubernetes-engine/">Google Kubernetes Engine</a> (GKE)、<a href="https://www.ibm.com/cloud/container-service">IBM Cloud Kubernetes Service</a> 以及任何其他 Kubernetes (k8s) 和&nbsp;Docker 环境。但是在本篇博文中，我使用的是 IBM Cloud Kubernetes Service。
</p>
<p>您可能会纳闷，我为什么要写关于监测 Kubernetes 和&nbsp;Docker 容器的内容。毫无疑问，基础架构现在由云服务提供商管理，我只需要担心自己的应用程序，对吧？您可能没有错，但我却是一个十分较真的人，即使有人私下向我推荐某家餐厅，我也会到 Yelp 上查看这家餐厅的评价，我觉得拥有的信息越多越好。对于我的应用程序及其所在环境，我希望获得所有相关日志和指标，同时能够对所有这些内容进行搜索、可视化并收到相关通知。常用的容器监测功能固然很好，但是我在这里还要向您展示一种很棒的方法，即使用 Kubernetes 事件和元数据对应用程序的性能图表进行注解，同时还能提供有关规模调整或滚动更新的通知。
</p>
<p>在开始之前，我们首先对几个词汇进行定义。
</p>
<ul>
	<li><strong>日志：</strong>时间戳和消息。日志既包括典型的日志条目，例如 “NGINX started at 13:42”（“NGINX 于 13:42 启动”），也包括 k8s 事件，例如 “There was an NGINX container with a Back-off restarting failed container at 16:20.”（”有一个 NGINX 容器在 16:20 放弃重启失败容器。”）。</li>
	<li><strong>指标：</strong>在固定时段内收集的数字型测量数据。指标既可以是 “Sales through the eCommerce site were $50,000 over the past ten minutes”（”在过去十分钟内电商网站的销售额为 $50,000”），也可以是 “CPU utilization was 17% from 14:00:00&nbsp;to 14:00:10.”（“14:00:00&nbsp;到 14:00:10 期间 CPU 的利用率为 17%。”）。</li>
</ul>
<h2>向 Kubernetes 集群内添加部署</h2>
<p>在我的示例中，我要基于 Apache HTTP 服务器、PHP 和 Redis 来使用此应用程序。
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb6c40127948a43cc/5c305565760e7f7a666d690f/k8s-module-1.png" data-sys-asset-uid="bltb6c40127948a43cc" alt="k8s-module-1.png">
</p>
<p>此外，如要监测应用程序和容器基础架构，我们需要拥有下面两项：&nbsp;
</p>
<ul>
	<li>Elastic Cloud 中的托管式 Elasticsearch Service 部署。</li>
	<li><span></span>Beats，即在同一 Kubernetes 集群中作为 DaemonSet 来部署的轻量型日志和指标采集器。请注意 Beats 可以代替 Kubernetes 集群内通常部署的 fluentd。</li>
</ul>
<h2>日志和指标</h2>
<p>上述应用只是持续产生有用信息的生态系统的一部分，我们要采集的便是该系统产生的这些信息。下面是我们所收集日志和指标的来源的级别：
</p>
<ol>
	<li>编排 (Kubernetes)</li>
	<li><span></span>主机</li>
	<li>应用</li>
	<li>容器 (Docker)</li>
</ol>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltd3029c1072fc382e/5c57e478bc5d07ed0b48c928/k8s-module-2.png" data-sys-asset-uid="bltd3029c1072fc382e" alt="k8s-module-2.png">
</p>
<p>为了收集数据，我们使用&nbsp;<a href="/cn/products/beats">Beats</a>（Filebeat、Metricbeat 和 Packetbeat）和System、Kubernetes、Docker 模块，以及针对应用（Apache 和 Redis）的模块。我们针对每个 Beat 部署了 <a href="https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/">DaemonSet</a>，并通过 Kubernetes&nbsp;对其进行管理。尽管这个列表较为冗长，但是不要担心，因为 Beats autodiscover 会让这一切变得很简单。如欲详细了解如何部署 Beats 来监测应用，请参阅<a href="/cn/blog/monitoring-an-application-running-in-docker-containers-and-kubernetes-with-the-elastic-stack">此篇博文</a>及其中的视频。实际上，如果您想从头开始，请查看 Elastic 网站上的<a href="/cn/docker-kubernetes-container-monitoring">容器监测页面</a>。<span></span>
</p>
<p><a href="/cn/cloud/elasticsearch-service/signup">托管式 Elasticsearch</a> Service 来对数据进行索引、储存、搜索、分析和可视化。<a href="/cn/start">我们的入门页面详细介绍</a>了如何在 Elastic Cloud 中部署 Elasticsearch Service，这和您在自管型系统中部署 Elasticsearch 和 Kibana 一样。
</p>
<p>我提到了 Beats 和模块，我们应该对这些内容进行更详细的介绍。Beat 是一款轻量型代理，其会向 Elasticsearch 或 Logstash 发送数据。Beats 有时候部署在数据来源处（譬如在实体或者虚拟系统上），有时会和源内容一起部署，例如作为 DaemonSet（就如我在此处所做的一样）。模块能够简化常见日志格式的收集、解析、索引和可视化过程。
</p>
<p>这听起来有点枯燥，我换一种方式来解释吧：Elastic 模块是预配置体验。让我们假设您知道有关管理 Apache HTTPD 服务器的所有知识，但是 NGINX 对您而言是新内容。您可能会找到熟悉 NGINX 的人士并问他们“您在日志中寻找什么内容呢？您关注哪些指标？可以从您的历史文件中给我一些 greps 吗？”这些问题的答案能够让我对 Beat 模块进行定义；预配置仪表板、保存的搜索、解析，以及收集大量内容（例如 Kubernetes、Docker、NGINX、Apache、操作系统和数据库等）的行为。以我的经验来看，这是一个非常强大的能力集合。
</p>
<p><a href="https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-module-kubernetes.html">k8s 模块</a>会收集与 pod、节点、容量、ReplicaSets 和部署相关的指标。每个指标都附有丰富的元数据集，所以您能将数据关联到应用程序。举例说明，您可能不在乎 pod <em>xyz</em> 的内存使用已经接近限度，但是如果此指标的出现与您应用程序的前端有关，那么您就知道这一指标的业务价值了。它还会收集事件（回想一下，我在上面的日志定义中已经将 Kubernetes 事件包括在内），在下面的视频中，我们便要使用这些事件来丰富性能图表。
</p>
<p><a href="https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-module-docker.html">Docker 模块</a>收集与容器、主机、内存、网络和健康检查相关的指标。和 Kubernetes 模块一样，在理解您应用程序的性能和环境时，元数据是十分宝贵的信息。
</p>
<p>还有很多其他的 <a href="https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-modules.html">Filebeat 模块</a> 和 <a href="https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-modules.html">Metricbeat 模块</a>。而且，<a href="https://www.elastic.co/guide/en/beats/packetbeat/current/visualizing-data-packetbeat.html">Packetbeat</a> 针对多项服务（譬如 Cassandra、Flows、HTTP、MySQL 和 MongoDB 等）提供了很多仪表板。
</p>
<p>观看视频并了解将数据转化为可付诸行动的信息有多么简单。视频主要包括下列内容：
</p>
<ul>
	<li>通过应用程序性能指标对&nbsp;Kubernetes 事件进行可视化
	</li>
	<li>深入了解 Metricbeat Kubernetes 模块的事件指标集
	</li>
	<li>在 Kubernetes 事件中进行导览并创建自定义可视化内容</li>
</ul>
<div class="video embed-container" style="height: 319.725px;">
	<img style="width: 100%; margin: auto; display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/FMHRF7JA2JhmPqpTNm4edp.jpg" data-uuid="FMHRF7JA2JhmPqpTNm4edp" data-v="4" data-type="inline">
</div>

AUTHOR

Articles By Dan Roscigno

Elasticsearch 可观察性：采用 Prometheus 和 OpenMetrics 标准收集指标

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

使用 Beats 监测 Kubernetes 和 Docker 容器：日志、指标和元数据

注册 Elastic Cloud 免费试用版

产品和解决方案

公司

资源

解决方案

Elastic (ELK) Stack

新增功能

AUTHOR

Articles By Dan Roscigno

Elasticsearch 可观察性：采用 Prometheus 和 OpenMetrics 标准收集指标

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

使用 Beats 监测 Kubernetes 和 Docker 容器：日志、指标和元数据

注册 Elastic Cloud 免费试用版

公司

资源