开发人员、SRE 和安全分析人员现在可以使用 Google Dataflow 直接从 Google Cloud Storage 采集数据到 Elastic 中，缩短故障排除和分析所需的时间。

elastic-blog-googlecloudstorage.png

elastic-blog-googlecloudstorage-2.png

elastic-blog-googlecloudstorage-3.png

elastic-blog-googlecloudstorage-4.png

elastic-blog-googlecloudstorage-5.png

elastic-blog-googlecloudstorage-6.png

elastic-blog-googlecloudstorage-7.png

blog-thumb-cloud-gcp.png

Ingest data directly from Google Cloud Storage into Elastic using Google Dataflow

使用 Google Dataflow 直接将数据从 Google Cloud Storage 采集到 Elastic 中

数据分析人员和开发人员现在就可以将 BigQuery 数据直接采集到 Elastic 中，消除运行开销和减少数据采集花费的时间，从而专注于构建仪表板以发掘见解或在 Elastic 中运行全文搜索

elastic-blog-bigquery.png

elastic-blog-bigquery-2.png

elastic-blog-bigquery-3.png

elastic-blog-bigquery-4.png

elastic-blog-bigquery-5.png

elastic-blog-bigquery-6.png

elastic-blog-bigquery-7.png

elastic-blog-bigquery-8.png

Ingest data directly from Google BigQuery into Elastic using Google Dataflow

使用 Google Dataflow 直接将数据从 Google BigQuery 采集到 Elastic 中

开发人员、SRE 和安全分析人员现在可以使用 Google Dataflow 直接从 Google Pub/Sub 采集数据到 Elastic 中，从而消除运行开销并减少故障排除所需的时间。

今天，我们很高兴地宣布与 Google Cloud 持续发展的合作关系的最新进展。现在，开发人员、站点可靠性工程师 (SRE) 和安全分析人员只需在 Google Cloud 控制台中点击几下，就可以从 Google Pub/Sub 采集数据到 Elastic Stack。通过使用 Google Dataflow 模板，Elastic 可以轻松地将 Google Cloud 服务（如 Google Cloud 审计、VPC 流或防火墙）中的事件和日志流式传输到 Elastic Stack 中。这有助于客户简化他们的数据管道体系结构，消除运行开销，并减少故障排除所需的时间。
许多使用 Google Cloud 开发应用程序和建立其基础架构的开发人员、SRE 和安全分析人员也利用 Elastic Stack 排除、监测和识别安全异常。Google 和 Elastic 合作提供了一种易于使用、无障碍的方式，从 Google Cloud 服务中的应用程序和基础架构中采集日志和事件至 Elastic。所有这些都是可行的，只需要在 Google Cloud 控制台中点击几下，而不需要安装任何数据采集器。&nbsp; &nbsp;
在这篇博文中，我们将介绍如何使用 Google Dataflow 实现从 Google Pub/Sub 到 Elastic Stack 的无代理数据采集。
<h2>省略运行开销</h2>Pub/Sub 是一种常用的无服务器异步消息传递服务，用于来自于 Google Operations（前身为 Stackdriver）的流数据，使用 Google Cloud 服务构建的应用程序或涉及流数据集成管道的其他用例。要将 Google Cloud 审计、VPC 流或防火墙日志采集到第三方分析解决方案（如 Elastic Stack），需要首先将这些日志发送到 Google Operations，然后发送至 Pub/Sub。&nbsp; 一旦日志在 Pub/Sub 中， Google Cloud 用户必须确定采集方法，以将存储在 Google Pub/Sub 中的消息发送给第三方分析解决方案。
Google 和 Elastic 用户共同使用的一个常用选项是在 Google Compute Engine VM（虚拟机）上安装 Filebeat、Elastic Agent 或 Fluentd，然后使用其中一个数据采集器将数据从 Pub/Sub 发送到 Elastic Stack。配置 VM 和安装数据采集器会产生流程和管理开销。所以省略这一步，直接从 Pub/Sub 采集数据到 Elastic 的功能对许多用户来说就很有价值，特别是当这一操作在 Google Cloud 控制台中点击几下就可以完成时，更加显得意义非凡。现在，通过 Google Dataflow 中的下拉菜单就可以实现这一操作。
<h2>简化数据采集</h2>Google Dataflow 是一种基于 Apache Beam 的无服务器异步消息传递服务。Dataflow 可以代替 Filebeat 直接从 Google Cloud 控制台发送日志。Google 和 Elastic 团队合作开发了一个开箱即用型 Dataflow 模板，可将日志和事件从 Pub/Sub 推送到 Elastic。这个模板取代了轻量型处理，比如以前由 Filebeat 以无服务器的方式完成的数据格式转换，以前使用 Elasticsearch 采集管道的用户无需做其他更改。&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
下面简要介绍了数据采集流程。这种集成适用于所有用户，无论他们使用的是 Elastic Cloud 上的 Elastic Stack、Google Cloud Marketplace 中的 Elastic Cloud，还是自管型环境。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt4a0252dfb0591d2f/6143c63764c8007a9bdea6f5/blog-gcp-integration-pubsub-1.png" data-sys-asset-uid="blt4a0252dfb0591d2f" alt="blog-gcp-integration-pubsub-1.png" style="display: block; margin: auto;">
<h2>开始使用</h2>在本节中，我们将逐步学习如何使用 Dataflow 模板来分析 Elastic Stack 中的 <a href="https://cloud.google.com/logging/docs/audit">GCP 审计日志</a>。
审计日志包含的信息可以帮助您回答 Google Cloud 账户中发生的运行变更的“地点、方式和时间”问题。通过我们的 Pub/Sub 模板，您可以将审计日志从 GCP 流式传输到 Elasticsearch，并在几秒钟内收集到见解。&nbsp;
我们将从直接在 Kibana 网页 UI（用户界面）安装 Elastic GCP 集成开始，该 UI 包含预构建的仪表板、采集节点配置和其他资产，这些资产可以帮助您获取所采集的大部分审计日志。&nbsp;
在配置 Dataflow 模板之前，您必须从 Google Cloud 控制台创建一个 <a href="https://cloud.google.com/pubsub/docs/quickstart-console">Pub/Sub 主题和订阅</a>，在这个控制台中您可以从 Google Operations Suite 发送日志。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt729ea82c62f6cf41/6143c6569d27cf7da4ba0a18/blog-gcp-integration-pubsub-2.png" data-sys-asset-uid="blt729ea82c62f6cf41" alt="blog-gcp-integration-pubsub-2.png">
接下来，导航到 Google Cloud 控制台来配置我们的<a href="https://cloud.google.com/dataflow/"> Dataflow</a> 作业。&nbsp;
在 Dataflow 产品中，单击“Create job from template”（从模板创建作业），并从 Dataflow 模板下拉菜单中选择“Pub/Sub to Elasticsearch”（从 Pub/Sub 到 Elasticsearch）。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltbd14459da3fb91c0/6143c6648440e97ef58272c3/blog-gcp-integration-pubsub-3.png" data-sys-asset-uid="bltbd14459da3fb91c0" alt="blog-gcp-integration-pubsub-3.png">
填写所需的参数，包括您的 Cloud ID 和用于 Elasticsearch 的 Base64 编码的 API 密钥。因为我们是流式传输审计日志，所以添加“audit”（审计）作为日志类型参数。Cloud ID 可以从 Elastic Cloud UI 中找到，如下所示。可以用 <a href="/guide/en/elasticsearch/reference/current/security-api-create-api-key.html">Create API key API</a> 创建 API 密钥。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltaa76aed1b8faf542/6143c677947b692d209b5352/blog-gcp-integration-pubsub-4.png" data-sys-asset-uid="bltaa76aed1b8faf542" alt="blog-gcp-integration-pubsub-4.png">
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt56be59a0016ed28c/6143c686f725af79f53fc4ea/blog-gcp-integration-pubsub-5.png" data-sys-asset-uid="blt56be59a0016ed28c" alt="blog-gcp-integration-pubsub-5.png">
单击“Run Job”（运行作业），等待 Dataflow 执行模板，大约需要几分钟。正如您所见，您无需离开 Google Cloud 控制台或管理代理！
现在，导航至 Kibana 在 [logs GCP] （日志 GCP）仪表板中查看已解析和可视化的日志。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt879b955d1a95e437/6143c69364c8007a9bdea6fd/blog-gcp-integration-pubsub-6.png" data-sys-asset-uid="blt879b955d1a95e437" alt="blog-gcp-integration-pubsub-6.png">
<h2>总结</h2>Elastic 不断努力，使客户更容易、更顺畅地根据需要选择部署位置并使用所需功能，与 Google Cloud 的这种简化集成就是该理念的最新实例。Elastic Cloud 延伸了 Elastic Stack 的价值, 让客户的可用操作更多、更快，使它成为体验我们平台的最佳方式。欲知更多关于集成的信息，<a href="https://cloud.google.com/dataflow/docs/guides/templates/provided-streaming#cloudpubsubtoelasticsearch">请访问 Google 的文档资料</a>。要即刻体验 Google Cloud 上的 Elastic，请访问<a href="https://console.cloud.google.com/marketplace/product/elastic-prod/elastic-cloud?utm_source=blog&utm_medium=ingest_data_directly_from_google_pub_sub_into_elastic_using_google_dataflow"> Google Cloud Marketplace</a> 或 <a href="/cn/">elastic.co</a>。

blog-banner-cloud-gcp.png

Ingest data directly from Google Pub/Sub into Elastic using Google Dataflow

使用 Google Dataflow 直接将数据从 Google Pub/Sub 采集到 Elastic 中

ECK 基于 Operator 模式构建而成，能够扩展 Kubernetes 以支持对 Elasticsearch 和 Kibana 进行设置和管理，还能简化很多关键操作。

尽管仍在 α 测试阶段，近期<a href="/cn/blog/introducing-elastic-cloud-on-kubernetes-the-elasticsearch-operator-and-beyond">有关 Elastic Cloud on Kubernetes (ECK) 的公告</a>还是在 Elasticsearch 社区和 Kubernetes 社区引发了人们浓厚的兴趣。ECK 由 Elastic Stack 的开发人员开发和提供支持，是在 Kubernetes 上部署 Elastic 的首选方式。本系列博文共有两篇，旨在带您逐步完成下面的过程：
<ol>
	<li>在 Kubernetes 集群（Minikube 或 GKE）中部署 ECK</li>
	<li>在 ECK 中部署 Elastic Stack</li>
	<li>在 ECK 中对 Elasticsearch 和 Kibana 进行缩放和升级</li>
	<li>部署一个由 Elastic APM 检测的范例应用程序，并将 APM 数据发送至由 ECK 托管的 Elasticsearch 集群</li>
	<li>将 Metricbeat 作为 DaemonSet 部署到 Kubernetes 中，并将 Metribeat 安全地连接至由 ECK 托管的 Elasticsearch 集群</li>
</ol>按照博文进行操作后，您将会拥有一套如下图所示的系统。在第一篇博文中，我们专注于部署 ECK 和 Elastic Stack。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt581c3354e0ff2a19/5d669db03c79d92e49236cd1/eck-deployment-diagram-blog.png" data-sys-asset-uid="blt581c3354e0ff2a19" alt="ECK 部署关系图" style="display: block; margin: auto;">
您还可以参考<a href="/guide/en/cloud-on-k8s/0.9/k8s-quickstart.html">快速入门</a>页面或<a href="/cn/elasticsearch-kubernetes">产品页面</a>，以了解有关 ECK 的最新信息。
 <h2>创建您的 k8s 集群</h2>您必须准备好一个 Kubernetes 集群，然后才能部署 ECK 和 Elastic Stack。在本篇博文中，Minikube 或 Google Kubernetes Engine (GKE) 都可以。我们还支持其他 Kubernetes 分发包，例如 <a href="/guide/en/cloud-on-k8s/0.9/k8s-openshift.html">OpenShift</a>、Amazon EKS 和 Microsoft AKS。由于我们要部署 ECK、Elasticsearch、Kibana、APM Server 和一个范例应用程序，我建议您将集群配置为 16 GB 内存和 4 核处理器。您也可以将 Kubernetes 集群配置为 12 GB 内存，但 16 GB 肯定能为您带来流畅的使用体验。
 <h3>Minikube</h3>如果您准备使用 Minikube，请按照<a href="https://kubernetes.io/docs/tasks/tools/install-minikube/#install-minikube">安装说明</a>进行安装。安装完毕后，使用所需的资源对 Minikube 进行配置并将其启动：
<pre class="prettyprint">minikube config set memory 16384 
minikube config set cpus 4 
minikube start
</pre>借助 Kubernetes 仪表板，您能够十分便捷地对 Kubernetes 集群进行监测和管理。您通过一条命令便可为 Minikube 启用仪表板：
<pre class="prettyprint">minikube dashboard
</pre>会自动打开一个浏览器窗口，并显示 Kubernetes 仪表板。就这么简单——您可以进行下一步了。
 <h3>Google Kubernetes Engine (GKE)</h3>如想使用 GKE，请按照 Google <a href="https://cloud.google.com/kubernetes-engine/">文档</a>来配置您的集群。我的 GKE 集群包括一个节点，该节点的配置为 15 GB 内存，4 个 vCPU。您可以选择小一些的集群，但是内存不得小于 12 GB。而且，如要使用 GKE，您需要 <a href="https://cloud.google.com/sdk/gcloud/">gcloud 命令行工具</a>。
您的 GKE 集群设置完毕并运行后，使用下方命令来连接至您的集群并设置所需的权限。对于 GKE，您必须拥有集群管理员权限。确保将 project name（项目名称）、zone name（区域名称）、cluster name（集群名称）和 user ID（用户 ID）替换为您的信息：
<pre class="prettyprint">gcloud config set project elastic-sa 
gcloud config set compute/zone us-central1-a 
gcloud config set container/cluster aquan 
gcloud auth login 
gcloud container clusters get-credentials aquan --zone us-central1-a --project elastic-sa 
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=adam.quan@elastic.co 
kubectl create clusterrolebinding adam.quan-cluster-admin-binding --clusterrole=cluster-admin --user=adam.quan@elastic.co
</pre>最后，我们将要使用 Kubernetes 命令行工具与 Minikube 或 GKE 进行交互。按照<a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/">指南</a>安装 kubectl。确保您所安装的 kubectl 为 1.11 或更新版本。
至于本篇博文所使用的项目，您可从这个 <a href="https://github.com/adamquan/ECK">GitHub 存储库</a>下载。
 <h2>部署 Elasticsearch Operator</h2>只需一条命令便可部署 ECK，您相信吗？就是这样——只需运行下方命令便可部署最新的 ECK 0.9.0（截至撰写本文时）。无比简单快捷。
<pre class="prettyprint">kubectl apply -f https://download.elastic.co/downloads/eck/0.9.0/all-in-one.yaml
</pre>部署完成后，您可以使用下方命令监测来自 Operator 的日志并确保一切顺利。片刻之间，便能部署完并运行 ECK 。
<pre class="prettyprint">kubectl -n elastic-system logs -f statefulset.apps/elastic-operator
</pre> <h2>部署 Elastic Stack</h2>既然现在 ECK 已在运行，我们可以开始部署 Elastic Stack 了，也是仅需一条命令。查看 <a href="https://github.com/adamquan/ECK/blob/master/apm_es_kibana.yaml">apm_es_kibana.yaml</a> 并了解配置 Kibana 和 APM Server 有多么简单；配置完后，Kibana 和 APM Server 便可使用 elasticsearchRef 彼此进行通信。
您可以通过很多方法<a href="/guide/en/cloud-on-k8s/0.9/k8s-elasticsearch-specification.html">对部署进行自定义</a>，例如：
<ul>
	<li>Pod 模板</li>
	<li>节点配置</li>
	<li>虚拟内存</li>
	<li>自定义 HTTP 证书</li>
	<li>安全设置</li>
</ul>使用下方命令部署堆栈：
<pre class="prettyprint">kubectl apply -f apm_es_kibana.yaml
</pre>通过 kubectl 或者 Kubernetes 仪表板了解 Elasticsearch、Kibana 和 APM Server 的状态，并确保所有均为绿色和可用状态：
<pre class="prettyprint">kubectl get elasticsearch,kibana,apmserver
</pre>所有三个组件均变为绿色即表示您的 Elasticsearch 集群已部署完毕并正常运行，可以向其中采集数据了。ECK 可帮助我们完成很多任务。稍停一下，我们看一下 ECK 到底对我们的集群进行了哪些操作：
<ul>
	<li>为 ECK 开启了安全功能。通过 ECK 部署的所有 Elastic Stack 资源均默认受到安全保护。内置的基本身份验证用户 elastic 已通过 TLS 进行配置，而且往返于 Elasticsearch 集群的以及 Elasticsearch 集群内的网络流量均通过 TLS 受到安全保护。</li>
	<li>证书：默认情况下，会针对每个集群使用一个自签名 CA 证书。还可以配置自定义 HTTPS 证书。</li>
	<li>默认服务暴露：会自动为您的集群和 Kibana 创建一项 ClusterIP 服务。如有需要，您当然可以将其配置为 LoadBalancer 类型。</li>
</ul>现在 Elasticsearch、Kibana 和 APM Server 都已正常运行，我们从 Kibana 中看一下。
 <h2>访问 Kibana</h2>默认情况下，Kibana 会暴露为一项可从集群内部访问集群 IP 的服务，但 Kibana 不会暴露至互联网。然而，您可以使用下方的端口转发命令让您的笔记本电脑可以访问 Kibana：
<pre class="prettyprint">kubectl port-forward service/kibana-sample-kb-http 5601
</pre>登录 Kibana 之前，我们需要获得默认 elastic 用户的凭据。您可以运行 kubectl get secret，然后检查密钥以找出密钥的 JSON 路径。下面是我们案例的正确密钥和路径：
<pre class="prettyprint">echo `kubectl get secret elasticsearch-sample-es-elastic-user -o=jsonpath='{.data.elastic}' | base64 --decode`
</pre>Elastic 用户的密码已显示出来。将其复制并保存至记事本中。
现在，打开浏览器并连接至 https://localhost:5601。由于我们使用的是自签名证书，您将需要接受浏览器的安全警告。使用 Elastic 用户和您刚检索到的密码登录 Kibana。您将会来到 Kibana 主页。我们的集群已完全部署完毕啦！
 <h2>缩放和升级</h2>在 ECK 中缩放和升级 Elasticsearch 集群的过程十分简单，只需编辑部署配置并通过 kubectl 加以应用即可。
 <h3>缩放</h3>编辑您的部署清单 apm_es_kibana.yaml，在下面部分中将 elasticsearch 容器的内存大小从 3 GB 调整为 2 GB 即可：
<pre class="prettyprint"> containers:
 - name: elasticsearch 
 resources:
 limits:
 memory: &lt;strong&gt;3Gi&lt;/strong&gt;
</pre>保存文件并通过这条命令对节点进行缩放：
<pre class="prettyprint">kubectl apply -f apm_es_kibana.yaml
</pre>立即切换至 Kubernetes 控制台，您在这里会看到创建了几个 Elasticsearch Pod。ECK 正在缩放 Elasticsearch 节点，而且实现了零中断。很快您就会发现新的 Pod 开始运行，而原始 Pod 也会消失。原始 Pod 的数据也畅通无阻地转移了过来。
您当然还可以通过其他方式对集群规模进行缩放，例如向其中添加更多节点。无论采用什么方式，通过简单的一条 kubectl apply 命令就能搞定。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt9ce4b89f5a75638c/5d669de848f9131ee05db04e/eck-deployment-pod-creation-blog.png" data-sys-asset-uid="blt9ce4b89f5a75638c" alt="正在创建 Elasticsearch 集群" style="display: block; margin: auto;">
<h3>升级</h3>现在，我们将集群升级至 7.2.0，只需简单地在部署清单文件 apm_es_kibana.yaml 中将 Elasticsearch、Kibana 和 APM Server 的版本从 7.1.0 更改为 7.2.0 即可。保存并通过下面的命令应用升级：
<pre class="prettyprint">kubectl apply -f apm_es_kibana.yaml
</pre>相似地，从 Kubernetes 控制台中您可以看到 ECK 正在流畅地对 Elasticsearch、Kibana 和 APM Server 进行升级，而且实现了零中断。
升级过程完成后，验证并确认您所运行 Elastic Stack 的版本是 7.2.0。您现在完全相信 ECK 的强大能力了吧？希望如此。
 <h2>总结</h2>希望您喜欢 Elastic Cloud on Kubernetes 的快速入门过程，并且认识到这一过程有多么简单。在本篇博文的<a href="/cn/blog/getting-started-with-elastic-cloud-on-kubernetes-data-ingestion">第 2 部分</a>，我们将会部署一个由 APM 检测的简单应用程序，并让其将 APM 数据发送至我们由 ECK 托管的集群。我们还会在 Kubernetes 中部署 Metricbeat，以将指标数据发送至集群。

eck-announcement-banner.png

eck-deployment-blog-thumb.jpg

Getting started with Elastic Cloud on Kubernetes: Deployment

Elastic Cloud on Kubernetes 入门：部署

RUM（Real User Monitoring，真实用户监测）可捕获用户与浏览器的交互。我们将使用 RUM 和 Java 代理来为一个具有 React 前端和 Spring Boot 后端的应用程序装载测量工具。

elastic-apm-distributed-tracing-large.jpg

elastic-apm-distributed-tracing-small.png

A Sip of Elastic RUM (Real User Monitoring)

Elastic RUM 浅谈

开放式跟踪为分布式跟踪定义了一个独立于供应商的 API。Elastic APM 兼容开放式跟踪，并为仪器复用提供了一个桥梁。

<h2>微服务的世界</h2>企业越来越多地采用微服务架构。他们每天都在开发和部署更多的微服务。通常，这些服务是用不同的编程语言开发的，部署到不同的运行时容器中，并由不同的团队和组织管理。像推特这样的大企业可以拥有成千上万的微服务，所有这些都在一起工作以实现他们的商业目标。正如他们在这篇推特博客文章中讨论的<a href="https://blog.twitter.com/engineering/en_us/a/2013/observability-at-twitter.html">，了解不同服务拓扑的运行状况和性能对于他们能够快速确定问题的根本原因以及提高推特的整体可靠性和效率是极其重要的。
</a><a href="https://blog.twitter.com/engineering/en_us/a/2013/observability-at-twitter.html"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf0ee6529c2de5c59/5c98d620026179ca592ee24d/blog-opentracing-elastic-apm-1.png" data-sys-asset-uid="bltf0ee6529c2de5c59" alt="" style="display: block; margin: auto;">
</a><a href="https://blog.twitter.com/engineering/en_us/a/2013/observability-at-twitter.html">这是分布式跟踪真正能提供帮助的地方。分布式跟踪有助于解决微服务面临的两个基本挑战：
</a><ol><a href="https://blog.twitter.com/engineering/en_us/a/2013/observability-at-twitter.html">
	<li>跟踪延迟 一个用户请求或事务可以在不同的运行时环境中通过许多不同的服务。理解每个服务对于特定请求的延迟对于理解整个系统的整体性能特征至关重要，并为可能的改进提供有价值的见解。</li>
	<li>根本原因分析 对于建立在大型微服务生态系统之上的应用程序来说，根本原因分析甚至更具挑战性。任何服务在任何时候都可能出错。分布式跟踪在调试这样一个系统中的问题时至关重要。</li>
</a></ol><a href="https://blog.twitter.com/engineering/en_us/a/2013/observability-at-twitter.html">退一步说，跟踪只是</a><a href="/cn/blog/observability-with-the-elastic-stack">可观察性</a>的三大支柱-记录、指标和跟踪中的一部分。正如我们将简要讨论的，Elastic Stack 是所有三个可观察性支柱的统一平台。当日志、指标和 APM 数据存储在同一个存储库中，一起进行分析和关联时，您将获得对业务应用程序和系统最丰富的上下文洞察。在本篇博客中，我们将只关注跟踪方面。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltd249957e822769f9/5c98d61beb3c40e859703c1a/blog-opentracing-elastic-apm-2.png" data-sys-asset-uid="bltd249957e822769f9" alt="" style="display: block; margin: auto;">
<h2>Elastic APM 的分布式跟踪</h2><a href="/guide/en/apm/get-started/current/index.html">Elastic APM</a> 是建立在 Elastic Stack 上的应用性能监控系统。它允许您实时监控软件服务和应用程序，收集有关传入请求、数据库查询、缓存调用、外部 HTTP 请求等响应时间的详细性能信息。Elastic APM 代理提供丰富的开箱即用的自动检测（例如定时数据库查询等）。获得支持的框架和技术。您也可以出于自定义目的使用自定义仪器。这使得快速查明和修复性能问题变得更加容易。
Elastic APM 支持<a href="/guide/en/apm/get-started/6.6/distributed-tracing.html">分布式跟踪</a>，并且兼容开放式跟踪。它使您能够在一个视图中分析整个微服务体系结构的性能。Elastic APM 通过跟踪所有请求来实现这一点，从最初的网络请求到前端服务，再到对后端服务的查询。这使得在整个应用程序中查找可能的瓶颈变得更加容易和快速。APM 用户界面中的时间线可视化显示了跟踪中连接的单个服务的所有事务的瀑布视图：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blta65f095d22517ce4/5c98d59849a201165fca1042/blog-opentracing-elastic-apm-3.png" data-sys-asset-uid="blta65f095d22517ce4" alt="" style="display: block; margin: auto;">
Elastic Stack 也是日志聚合和指标分析的绝佳平台。将日志、指标和 APM 跟踪都存储在 Elasticsearch 中并有编制索引，这是一种超级强大的功能。能够快速关联基础架构指标、日志和跟踪等数据源使您能够更快地调试根本原因。在 APM 用户界面中，查看跟踪时，如果还收集了主机或容器指标和日志，您可以通过单击操作菜单快速跳转到这些指标和日志。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc037c8e3109bfba5/5c98d60b6d10d1145a98468c/blog-opentracing-elastic-apm-4.png" data-sys-asset-uid="bltc037c8e3109bfba5" alt="" style="display: block; margin: auto;">
如果每个人都使用 Elastic APM 来测量他们的应用和服务，那就太好了。然而，Elastic APM 并不是当今唯一可用的分布式跟踪解决方案。还有其他流行的开源跟踪器，比如 Zipkin 和 Jaeger。像多语种编程和多语种持久性这样的概念在微服务领域是众所周知和被广泛接受的。类似地，“多语种跟踪”将会更加普遍。由于微服务的独立性和解耦性，负责不同服务的人可能会使用不同的跟踪系统。<h2>开发者面临的挑战</h2>有了许多不同的跟踪系统，开发人员面临着真正的挑战。一天结束的时候，跟踪者生活在应用程序代码中。一些常见的挑战是：
<ol>
	<li>使用哪个跟踪系统？</li>
	<li>如果我想改变我的跟踪器呢？我不想改变我的全部源代码。</li>
	<li>我如何处理可能使用不同跟踪程序的共享库？</li>
	<li>如果我的第三方服务使用不同的跟踪程序呢？</li>
</ol>毫不奇怪，我们需要标准化来解决这些问题。在讨论标准化的现状之前，让我们退一步，从整体的角度从架构的角度来看分布式跟踪，并理解实现分布式跟踪“涅槃”需要什么。
<h2>分布式跟踪的架构组件</h2>现代软件系统可以分解成几个高级组件，通常由不同的组织设计和开发，并在不同的运行环境中运行。
<ul>
	<li>您自己的应用程序代码和服务</li>
	<li>共享图书馆和服务</li>
	<li>外部服务</li>
</ul>为了通过分布式跟踪以整体和集成的方式监控这样一个系统，我们需要四个架构组件:
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1a2bddd007f963ac/5c98d60367b8321d593d7fb4/blog-opentracing-elastic-apm-5.png" data-sys-asset-uid="blt1a2bddd007f963ac" alt="" style="display: block; margin: auto;">
<ol>
	<li>标准化分布式跟踪 API。标准化独立于供应商的跟踪 API 允许开发人员以标准化的方式测量他们的代码，而不管他们在运行时后期可能选择使用什么样的跟踪程序。这是迈向任何目标的第一步。</li>
	<li>标准化跟踪上下文定义和传播。要让跟踪从一个运行时跨越到另一个运行时，跟踪上下文必须被双方理解，并且必须有一种传播该上下文的标准方式。至少，上下文携带一个跟踪 ID。</li>
	<li>标准化跟踪数据定义。为了让一个跟踪器的跟踪数据被另一个跟踪器理解和使用，必须有一个标准化的和可扩展的格式。</li>
	<li>互操作跟踪程序。最后，为了实现 100% 的运行时兼容性，不同的跟踪程序必须为它们提供以开放方式从其他跟踪程序导出和导入跟踪数据的机制。理想情况下，由 Jaeger 这样的跟踪程序检测的共享库或服务应该能够通过 Jaeger代 理通过配置更改将它的跟踪数据直接发送到 Elastic APM 或另一个跟踪程序。</li>
</ol>现在，关于开放式跟踪。
<h2>开放式跟踪规范</h2>开放式跟踪<a href="https://opentracing.io/specification/">规范</a>为分布式跟踪定义了一个开放的、独立于供应商的 API。它允许用户随时切换开放式跟踪实现者，从而避免供应商锁定。它还使框架和共享库的开发人员能够以标准的方式提供开箱即用的跟踪功能，从而能够更好地洞察框架和库。优步和 Yelp 等网络规模的公司正在使用开放式跟踪来更深入地了解他们高度分布式和动态的应用程序。
<h3>开放式跟踪数据模型</h3>开放式跟踪的基本概念和基本的<a href="https://opentracing.io/docs/overview/">数据模型</a>来自谷歌的 Dapper 论文。关键概念包括跟踪和跨度。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf922d3d931f16598/5c98d5fcd3c73ef55e9ea9c2/blog-opentracing-elastic-apm-6.png" data-sys-asset-uid="bltf922d3d931f16598" alt="" style="display: block; margin: auto;">
<ol>
	<li>跟踪表示事务在分布式系统中移动。它可以被认为是跨度的有向无环图。</li>
	<li>跨度是表示具有名称、开始时间和持续时间的逻辑工作单位。跨度可以嵌套和排序以建立关系模型。跨度接受键：值标签以及附加到特定跨度实例的细粒度、时间戳、结构化日志。</li>
	<li>跟踪上下文是分布式事务附带的跟踪信息，包括它何时通过网络或消息总线将服务传递给服务。上下文包含跟踪标识符、跨度标识符以及跟踪系统需要传播到下游服务的任何其他数据。</li>
</ol><h3>这一切是如何组织的？</h3>理想情况下，通过标准化，跟踪来自不同组织开发和运行的自定义应用程序代码、共享库和共享服务的信息是可交换的和运行时兼容的，不管这些组件选择使用哪种跟踪器。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc509fc1ff327a7bd/5c98d5f7228f2c42594171f4/blog-opentracing-elastic-apm-7.png" data-sys-asset-uid="bltc509fc1ff327a7bd" alt="" style="display: block; margin: auto;">
然而，开放式跟踪只解决了我们之前讨论的四个架构组件中的第一个。那么，我们现在与其他组件的关系如何，我们的未来会怎样？
<h3>我们现在发展到什么程度了？</h3>正如我们所讨论的，开放式跟踪为不同的跟踪者定义了一组标准的跟踪 API 来实现，这是一个很好的开始，也非常令人鼓舞。然而，我们仍然需要跟踪上下文标准化和跟踪数据标准化，以便它们能够相互兼容和交换。
<ol>
	<li>开放式跟踪 API 提供了一组标准的 API。这几乎是我们目前唯一的标准化。规范也有局限性。例如，它没有涵盖所有的编程语言。然而，这是一个了不起的努力，并获得了巨大的牵引力。</li>
	<li>还没有标准化的跟踪上下文定义。<a href="https://www.w3.org/2018/distributed-tracing/">W3C 分布式跟踪工作组</a>正在标准化跟踪上下文定义 W3C<a href="https://www.w3.org/TR/trace-context/">跟踪上下文规范</a>。该规范定义了分布式系统中上下文和事件关联的统一方法，并将支持跨不同监控工具的分布式应用程序中的端到端事务跟踪。Elastic APM 支持 W3C 跟踪上下文工作组标准化分布式跟踪的 HTTP 头格式的努力。我们的代理实现严格遵循跟踪上下文草案规范，我们打算完全支持最终规范。 
	作为当今跟踪上下文不兼容的一个例子，这里有一个 Elastic APM 和 Jaeger 用于跟踪标识的 HTTP 头的例子。如您所见，ID 的名称和编码都是不同的。当使用不同的跟踪头时，当它们跨越各自跟踪工具的边界时，跟踪将中断。 Jaeger： uber-trace-id:118c6c15301b9b3b3:56e66177e6e55a91:18c6c15301b9b3b3:1 Elastic APM: elastic-apm-traceparent:00-f109f092a7d869fb4615784bacefcfd7-5bf936f4fcde3af0-01 除了定义本身，还有其他挑战。例如，并不是所有的超文本传输协议报头都是由服务基础设施和路由器等自动转发的。每当头被丢弃时，跟踪就会中断。
	</li>
	<li>还没有标准化的跟踪数据定义。正如 W3C 分布式跟踪工作组所指出的，跟踪互操作性的第二个难题是“一种标准化的和可扩展的格式，用于跨工具共享跟踪数据——完整的跟踪或跟踪片段，以供进一步解释”。可以想象，有许多开源和商业参与者参与，就标准格式达成一致不是一件容易的事情。希望我们能很快到达那里。</li>
	<li>跟踪程序与运行时不兼容。由于我们上面讨论的所有内容，加上让他们的系统开放并与世界其他地方兼容的混合动机，在现在的运行时，跟踪程序是完全不兼容的。我可以自信地说，在可预见的将来，这可能会是这样。</li>
</ol><h2>如今 Elastic APM 如何与其他跟踪器配合使用</h2>即使我们现在还没有接近跟踪程序之间的 100% 兼容性，也没有必要气馁。 Elastic Stack 仍然可以用几种不同的方式与其他跟踪器一起工作。
<ol>
	<li>Elasticsearch作为可扩展后端数据存储用于其他跟踪程序。 不出所料，Elasticsearch 由于其巨大的可扩展性和丰富的分析能力，已经被用作其他跟踪者（如 Zipkin 和 Jaeger）的后端数据存储。将 Zipkin 或 Jaeger 跟踪数据传送到 Elasticsearch 对他们来说都是一个简单的配置。一旦跟踪数据进入 Elasticsearch，您就可以使用 Kibana 强大的分析和可视化功能来分析您的跟踪信息，并创建引人注目的可视化效果，从而深入了解您的应用程序性能。</li>
	<li>Elastic 开放式跟踪桥 
	Elastic APM 开放式跟踪桥允许您使用开放式跟踪 API 创建 Elastic APM 事务和跨度。换句话说，它将对开放式跟踪 API 的调用转换成 Elastic APM，从而允许重用现有的工具。例如，Jaeger 完成的现有仪器可以简单地用 Elastic APM 替换，只需修改几行代码。 
	Jaeger 的原始仪器： 
	<pre class="prettyprint">import io.opentracing.Scope;
import io.opentracing.Tracer;
import io.jaegertracing.Configuration;
import io.jaegertracing.internal.JaegerTracer;
...
private void sayHello(String helloTo) {
 Configuration config = ...
 Tracer tracer = config.getTracer();
 try (Scope scope = tracer.buildSpan("say-hello").startActive(true)) {
 scope.span().setTag("hello-to", helloTo);
 }
 ...
}
 </pre>
	用 Elastic 开放式跟踪桥替换 Jaeger： 
	<pre class="prettyprint">import io.opentracing.Scope;
import io.opentracing.Tracer;
import co.elastic.apm.opentracing.ElasticApmTracer;
...
private void sayHello(String helloTo) {
 Tracer tracer = new ElasticApmTracer();
 try (Scope scope = tracer.buildSpan("say-hello").startActive(true)) {
 scope.span().setTag("hello-to", helloTo);
 }
 ...
}
 </pre> 通过这个简单的更改，跟踪数据将轻松地流入 Elastic APM，而无需修改其他跟踪代码。这就是开放式跟踪的力量！
	</li>
</ol><h2>Elastic APM 真实用户监控</h2>而在讨论跟踪和上下文传播等时，我们主要关注后端服务。，在浏览器的客户端启动跟踪非常有价值。这样做时，当用户点击浏览器中的某个东西时，您会得到跟踪信息。该跟踪信息从性能方面代表了应用程序的“真实用户体验”。不幸的是，现在没有标准的方式来转发这些信息。W3C 小组确实打算将来把跟踪上下文一直扩展到浏览器。
<a href="/guide/en/apm/server/current/rum.html">Elastic APM 实际用户监控</a>（RUM）现在正好提供了这一功能。RUM JS 代理监控客户端应用程序中的真实用户体验。您将能够测量“首字节时间”、“优势活动”和“完成时间”等指标，帮助您发现客户端应用程序中的性能问题以及与服务器端应用程序延迟相关的问题。我们的 RUM JS 代理与框架无关，这意味着它可以与任何基于 JavaScript 的前端应用程序一起使用。
&lt;p?<img src="https://images.contentstack.io/v3/assets/bltf7afce26b89a5b33/blte4644a6aaae06c70/5c645a55e2c86a6c4191bfe1/download" data-sys-asset-uid="blte4644a6aaae06c70">&lt;/p?<img><h2>结论</h2>希望本篇能帮助你更好地理解分布式跟踪的前景，并澄清一些关于我们现在使用开放式跟踪的困惑。让我们简单总结一下：
<ol>
	<li>分布式跟踪为微服务提供了无价的性能洞察。</li>
	<li>开放式跟踪是行业走向分布式跟踪标准化的第一步。要完全兼容，我们还有很长的路要走。</li>
	<li>Elastic APM 符合开放式跟踪标准。</li>
	<li>Elastic 开放式跟踪桥允许仪器复用。</li>
	<li>Elastic Stack 是一个很好的可扩展的长期存储，适用于其他跟踪程序，如 Zipkin 和 Jaeger，即使现在没有完全的运行时兼容性。</li>
	<li>Elastic 为跟踪数据提供了丰富的分析。将 Zipkin 或 Jaeger 跟踪数据传送到 Elasticsearch 是一个简单的配置。</li>
	<li>Elastic APM 真实用户监控（RUM）监控客户端应用程序中的真实用户体验。</li>
	<li>总而言之，Elastic 是一个可大规模扩展、功能丰富且统一的分析平台，适用于可观察性的三大支柱 - 日志记录、指标和跟踪。</li>
</ol>如往常一样，如果您想展开讨论或有任何问题，请在 <a href="https://discuss.elastic.co/c/apm">Elastic APM 论坛</a>上留言。跟踪愉快！

AUTHOR

Articles By Adam Quan

使用 Google Dataflow 直接将数据从 Google Cloud Storage 采集到 Elastic 中

使用 Google Dataflow 直接将数据从 Google BigQuery 采集到 Elastic 中

使用 Google Dataflow 直接将数据从 Google Pub/Sub 采集到 Elastic 中

Elastic Cloud on Kubernetes 入门：部署

Elastic RUM 浅谈

分布式跟踪、开放式跟踪和 Elastic APM

注册 Elastic Cloud 免费试用版

产品和解决方案

公司

资源

解决方案

Elastic (ELK) Stack

新增功能

AUTHOR

Articles By Adam Quan

使用 Google Dataflow 直接将数据从 Google Cloud Storage 采集到 Elastic 中

使用 Google Dataflow 直接将数据从 Google BigQuery 采集到 Elastic 中

使用 Google Dataflow 直接将数据从 Google Pub/Sub 采集到 Elastic 中

Elastic Cloud on Kubernetes 入门：部署

Elastic RUM 浅谈

分布式跟踪、开放式跟踪和 Elastic APM

注册 Elastic Cloud 免费试用版

公司

资源