elasticsearch APM功能全解 一
elastic stack在6.3版本开始推出了APM功能，但当时只支持nodejs，python和ruby，尚不支持java和go，而公司里面大部分系统还是java，因此只是关注，还没有去解读。但在6.4.0版本，终于推出了java和go的beta版本，而在6.5.0版本，终于变为GA版本。这使得在生产环境上部署APM服务变为可能，下面让我们一起来看看elastic stack的这个APM服务吧
文章目录
- elastic APM的前世今生
- 基本组件
- APM
- 事件（event）
- 组件通信
- 真实用户监控（RUM）
- 分布式跟踪（Distributed trace）
elastic APM的前世今生
首先，不要以为这个APM功能是一个不务正业、心血来潮的新功能。其实今天elastic的APM来源于之前的opbeat。而Opbeat是由一个丹麦初创团队于2013年成立的老公司了，专门运维软件的开发，而其主打产品即是APM运维软件。
被elastic收购之后，opbeat已经于2018年5月份，正式关闭网站和社区，转到了elastic APM上：
基本组件
Elastic APM 由四个基本组件构成：
- APM agents
- APM Server
- Elasticsearch
- Kibana APM UI
基本架构如下图：
APM agent是一系列开源库，使用与服务器端相同的语言编写，目前支持node、python、ruby、js，java和golang。您可以像安装任何其他库一样将它们安装到服务器端中。apm agent会检测代码并在运行时收集性能数据和错误。此数据可 缓冲一小段时间并发送到APM服务器。
APM Server是一个用Go编写的开源应用程序，通常在专用服务器上运行。它默认侦听端口8200，并通过JSON HTTP API从代理接收数据。然后，它根据该数据创建文档并将其存储在Elasticsearch中。
Elasticsearch是一个高度可扩展的开源全文搜索和分析引擎。它允许你快速，近实时地存储，搜索和分析大量数据。Elasticsearch用于存储APM性能指标并利用其聚合。
Kibana是一个开源分析和可视化平台，旨在与Elasticsearch协同工作。你可使用Kibana搜索，查看Elasticsearch中存储的数据并与之进行交互。你还可以使用Kibana中的专用APM UI或可以通过 APM Kibana UI直接加载的预构建的开源Kibana dashboard来可视化APM数据。（basic license就授权了APM功能）
APM
事件（event）
APM agent从其已监测的应用程序中捕获不同类型的信息，称为事件。事件可以是Errors，Spans或Transactions。然后将这些事件流式传输到APM server，由server验证并处理事件。
- Errors 包含捕获的错误或异常的相关信息。
- Spans包含已执行的特定代码路径的相关信息。它们从活动的开始到结束进行测量，并且可以与其他跨度建立父/子关系。
- Transactions是一种特殊的跨度，具有与之关联的额外元数据。您可以将Transactions视为您在服务中衡量的最高级别的工作。例如，提供HTTP请求或运行特定的后台作业。
组件通信
APM server是一个单独的组件 - 它有助于保持agent的轻量化，防止某些安全风险，并提高整个elastic stack和APM stack的兼容性。
Intake API是的APM agent和APM server进行通信的内部协议。在APM server验证并处理来自APM agent的事件（通过Intake API）后，server将数据转换为Elasticsearch文档并将其存储在相应的Elasticsearch索引中。只需几秒钟，您就可以开始在Kibana中查看应用程序性能数据。
真实用户监控（RUM）
Real User Monitoring捕获用户与Web浏览器等客户端的交互。javascript agent是Elastic的RUM agent。要使用它，您需要在APM server中启用RUM支持。
与监视请求和响应的Elastic APM后端agent不同，RUM JavaScript agent监视客户端应用程序中的真实用户体验和交互。RUM JavaScript agent也与框架无关，这意味着它可以与任何前端JavaScript应用程序一起使用。
您将能够测量诸如time to first byte之类的指标。而domInteractive，domComplete这类指标可以帮助你发现客户端应用程序中的性能问题以及与服务器端应用程序通信延迟的相关问题。
分布式跟踪（Distributed trace）
我们所有的APM agent都支持开箱即用的分布式跟踪。通过分布式跟踪，你可以在一个视图中分析整个微服务架构的性能。
现代应用程序性能监视的一个关键特性是分布式跟踪。随着软件应用程序架构从单一架构转变为更加分散的，基于服务的架构，能够跟踪请求如何流经系统至关重要。
通过分布式跟踪，request和transactions将链接在一起形成trace，即transactions和spans共同构成了一个Trace。trace不是事件，而是将具有公共根的事件组合在一起。从中，我们可以端到端的检测request的性能，以及哪些service是该request服务的一部分。
分布式追踪可以监控整个调用链，使开发人员和运营人员能够将各个事务的性能进行上下文分析，从而快速查明最终影响用户体验的瓶颈。
需要注意的是，目前Distributed trace还只是一个Beta版本
我们可以从下图学习分布式跟踪。
其中，Rack是一个request。因为是一个微服务系统，整个request是由多个service共同完成的。示例中，参与服务的bean由ruby, python, java, node。可见，整个Distributed trace与技术无关，只要由一个公共的根（trace id），则在服务下所有的transactions均可在UI上显示。
