17 - Traces - 观察应用程序的效能瓶颈 (1/6) - Elastic APM 基本介绍

Traces - 观察应用程序的效能瓶颈 系列文章

• (1/6) - Elastic APM 基本介绍
• (2/6) - 使用 APM-Integratoin-Testing 建立 APM 的模拟环境
• (3/6) - 如何在 Kibana 使用 APM UI
• (4/6) - 使用 APM Server 来收集 APM 数据
• (5/6) - 透过 APM Agents 收集并传送後端服务运作的记录
• (6/6) - 透过真实使用者监控 (RUM, Real User Monitoring) 来改善使用者体验

本篇学习重点

• APM 的基本介绍与架构
• APM 所收集的资料模型
• APM 的应用场影

什麽是 Elastic APM (Application Performance Monitoring) ?

Elastic APM 是一个能让你『即时』监控、观察、分析应用程序及服务的工具，透过收集应用程序内元件之间沟通时的记录，收集包含各种详细与效能相关的资讯，例如以下的资讯：

• 前端使用者的即时行为资讯
• 前端对应用程序 API 的请求与回应
• 应用程序对内部服务 API 的请求与回应
• 内部服务对 Cache 的存取
• 内部服务对 Database 的存取
• 服务存取外部的第三方服务的请求与回应

除了效能相关的资讯之外，如果处理中有发生例外状况的错误，甚至是程序错误发生时的 stacktrace 也都会被 APM 收集，另外也会顺便收集某些有支援的系统或运作环境相关的 metrics，例如：JVM metrics, Go runtime metrics。

Elastic APM 的基本架构

Elastic APM 的基本架构如上图共包含四个主要的元件：

• APM Agents： 提供各种语言实作的 Library，能协助开发人员加在应用程序之中，在应用程序执行的过程中负责收集各种效能相关的资讯或是错误的资讯，内含许多常用的 framework 或是 library 的整合，像是 cache 或 db 的存取 library，使用这些 library 时就不用额外自己开发要收集的资讯。
• APM Server： 以 libbeat 实作的 HTTP server，负责接收各个 APM Agents 所收集到的 APM 资讯，将这些资讯进行验证及加工处理後，汇整并传送给 Elasticsearch 进行 Indexing 及储存。
• Elasticsearch： 负责 APM 资料的储存，提供分析运算、资料生命周期的管理、资料备份等处理核心。
• Kibana APM UI： 让存在 Elasticsearch 里的 APM 资料能被快速的查阅、追纵、分析的 UI 工具。

Elastic APM 的资料模型

Elastic APM 的资料，每一笔都会是一个事件 (event)，而这些事件总共有四种的类型：

• Transactions
• Spans
• Errors
• Metrics

除此之外，events 当中都可以在 APM Agent 端自行加上我们自己想收集的额外资讯，并定义在扩充的栏位当中。

以下分别对四种资料类型进行说明。

Spans

Spans (跨度，可理解成片刻的一小段时间)，表示一个活动的开始到结束的记录，也就是代表一段程序执行时发生的资讯，并且因为一连串执行与处理的过程中，一个 Span 可能也会与其他的 Span 有上、下层的关系，在 Span 里面会记录：

• transaction.id：属於哪一个 Transaction。
• parent.id：如果是另个 Transaction 或是 Span 有上、下层关系时，会记录他的上层。
• Span 的开始及结束时间。
• Span 的 name。
• type、subtype、action。
• 过程中有错误发生时会包含 stacktrace 的资讯。

Transactions

Transactions (交易)，针对一个相对於 Span 更高层级的事件 (event) 的请求与回应，例如：发送一个外部的 Request、批次的作业处理、背景执行的工作、或是在程序执行中自行定义的一个处理行为…等，都可以是一个 Transaction，在一个 Transaction 之中，可以包含 0 到多个 Spans，Transaction 里面会记录：

• 事件发生的 timestamp。
• unique id、type、name。
• 事件发生的环境 (Environment) 相关的资讯，例如：
  • Service 的 environment、framework、language。
  • Host 的 hostname、IP。
  • Process 的 pid。
  • URL 的 domain、port、query string。
• 其他特定 APM Agent 所收集到的特定资讯。
• 使用者自行定义的 labels 或 custom 栏位的资讯。

Errors

Errors (错误)，当 APM Agent 收到 Errors 的资讯时，会产生 Errors 这样的 event，并且在里面会记录发生当时的 exception 资讯，或是 Error 发生当下的 logs，Error 里面会记录：

• 错误发生当时 exception 或 error log 所收集到的 stacktrace 资讯。
• culprit 记录错误发生的地方。
• 与错误发生时相关的 Transaction 的 transaction.id。
• 事件发生的环境 (Environment) 相关的资讯，例如：
  • Service 的 environment、framework、language。
  • Host 的 hostname、IP。
  • Process 的 pid。
  • URL 的 domain、port、query string。
• 使用者自行定义的 labels 或 custom 栏位的资讯。

Metrics

Metrics (指标)，APM Agent 会收集一些最基本的主机层级 (host-level) 的 metrics，例如：

• System metrics。
• Process 层级的 CPU 和 Memory metrics。
• JVM metrics。
• Go runtime metrics。

APM 的运用场景

• 分散式追纵 (Distributed Tracing)：分散式追纵是维运微服务架构时不可缺少的重要工具，APM 透过定义 Trace，并在里面包含了一组的 Transactions 及 Spans，用来代表一个特定的服务请求从到头尾的过程，并且在跨服务之间透过在 Header 中加入 trasc-id、span-id、parent-id，来实现分散式追纵的功能，让我们能透过 Kibana 能轻易的观察一个横跨多个服务的请求，过程中哪个环节的执行效能较慢、或是在发生错误时能快速的查看历程中发生什麽样的事。
• 真实使用者监控 (Real User Monitoring)：让我们透过 Elastic's RUM Agent 收集前端使用者在 web 上的操作，帮助我们从真实的使用者情境，并且关注在使用者体验来分析效能状况、进行效能最佳化、或是更即时的发现系统存在的问题。
• 与 Elastic Observability 的整合，像是透过与先前介绍的 Logs 整合，在 Logs 写入时也加入 APM event 的识别 ID，让我们使用 APM 进行分析时，在追到某个需要深入探索的地方时，能轻易的接续到 Logs 的部份查阅事件发生上、下文的 Logs。

参考资料

1. 官方文件 - APM Overview

查看最新 Elasticsearch 或是 Elastic Stack 教育训练资讯: https://training.onedoggo.com
欢迎追踪我的 FB 粉丝页: 乔叔 - Elastic Stack 技术交流
不论是技术分享的文章、公开线上分享、或是实体课程资讯，都会在粉丝页通知大家哦！