20 - Traces - 观察应用程序的效能瓶颈 (4/6) - 使用 APM Server 来收集 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 Server
• 如何安装以及设定 APM Server
• APM Server 的校能调校技巧

APM Server 概观

APM Server 的定位，是用来专门收集 APM Agents 所发送的资料，身为同样是收集资料的服务之一，APM Server 被 Elastic 归类在 Beats 的生态圈之中，因此 APM Server 就是使用 libbeat 所开发出来的产品，如此一来 APM Server 就拥有 Beats framework 所开发出来针对资料收集处理的各种能力与机制。

APM Server 的任务

• 负责收集 APM Agents 所传送出来的 APM 资料。
• 将收集到的资料，进行基本的验证。
• 将收集到的资料，进行加工处理，转换成後续易於分析使用的格式。
• 负责将资料传送到 Elasticsearch 储存。
• 负责在 Elasticsearch 安装 Ingest Pipeline 设定，让资料汇入至 Elasticsearch 时，能经由 Ingest Pipeline 进行处理。
• 负责向 Elasticsearch 设定 APM 的 Index Template、ILM (Index Lifecycle Management) Policy。
• 如果 Elasticsearch 在某段时间无法承受大量的资料写入时，APM 拥有的 Beats framework 当中的 queue 机制，会扮演 APM Agents 与 Elasticsearch 之间资料缓存的角色。

为何要有 APM Server 这个独立存在的元件？

• 让 APM Agents 轻量化，因为 Agents 是要安装在『服务』或『应用程序』之中，有些功能可以不用存在於 Agents 身上。
• 由於 APM Server 的设计是 stateless (无状态) 的，所以可以轻易的 scale out (向外扩展)，提升接收及处理大量 APM 资讯的能力。
• Elasticsearch 是架构中的元件，就像是资料库一样，不适合直接让外部存取，APM Server 的存在，避免让 APM Agents 直接存取到 Elasticsearch，因为有些 APM Agents 例如：RUM (Real User Monitoring) 是以 Javascript 的方式在 Browser 端执行，也就是在一般用户端执行，若是直接存取 Elasticsearch 会有安全性上的疑虑。
• APM Server 可以掌控资料传送进 Elasticsearch 的流量，避免 Elasticsearch 被过量的资料在短时间写入，造成效能影响。
• 如果 Elasticsearch 发生问题，APM Server 可以缓存 APM Agents 送来的资料，避免增加 Agents 端的负担，因为 Agents 有可能是安装在我们的『服务』或『应用程序』之中，这样会影响到『服务』或『应用程序』正常的运作。
• 在使用 RUM (Real User Monitoring) 时，Javascript 在前端有被 minify (缩小)，要在 APM 端能有效的解读，会需要使用 Source Mapping 的定义，这样在 APM UI 端时，所看到的资讯才能和原始档对应起来，这个 Source Mapping 的对应的动作，就会在 APM Server 端处理。
• 经由定义专门接受 APM Data 的 JSON API，并且在 APM Agents 与 Elasticsearch 之中当作缓冲的角色，可以提升不同 Agents 版本与 Elasticsearch 之间的相容性，也就是某些版本有更动时，这些相容性的格式转换，会在 APM Server 端处理掉。

如何安装及使用 APM Server

安装 APM Server

以下安装的步骤，以自行安装於 MacOS 环境为例：

1. 下载 APM Server 压缩档，并进行解压缩

curl -L -O https://artifacts.elastic.co/downloads/apm-server/apm-server-7.15.0-darwin-x86_64.tar.gz
tar xzvf apm-server-7.15.0-darwin-x86_64.tar.gz

2. 进入目录後，透过 APM Server 向 Elasticsearch 设定 Index Template、ILM (Index Lifecycle Management) Policy、Alias。

./apm-server setup --index-management

apm-server setup --pipelines 这个指令可以省略，预设 APM Server 启动时就会执行，当然也可以手动先设定好。

3. 在 apm-server.yml 中调整合适的配置设定。

4. 启动 APM Server

./apm-server -e

5. 当 APM Server 启动後，再来就是要安装 APM Agents，让 Agents 传送收集的资料到 APM Server，APM Agents 的部份我们在下一个章节进行介绍。

APM Server 常用设定

在使用 APM Server 时，在 apm-server.yml 有一些设定值可能会需要调整：

• output.elasticsearch：指定 Elasticsearch 的主机位置，或是 Security 相关的设定。
• queue.mem.*：Queue 的大小，如果 APM 收集的资料量较大、并且 APM Server 也配置较好的硬体规格时，这部份应该要有对应的调整。
• max_procs：如果对於 APM Server 能使用的 CPU 数量有要进行限制或调整的话，在此设定。
• app-server.rum.enable：如果要开启 RUM (Real User Monitoring) 的功能，要特别设定启用。(预设是关闭)
• apm-server.kibana.*：如果要透过 Kibana 来控制 APM Agents 的话，会需要设定这些配置。
• logging.*：要收集 APM 产生的 Logs 档的话，要设定启用写入档案，一般建议会启用并配合 Filebeat 来收集 APM Server 的 Logs。
• http.*：如果我们要透过 Metricbeat 收集 APM Server 的 Metrics 时，会需要启用 HTTP Endpoint，提供 Metricbeat 取得内部 Metrics 的 API。
• apm-server.auth.anonymous.*：当 RUM 设定启用时，这个设定值也会自动被启用，有些 rate_limit 的设定在量级较大的环境可能会需要被重新检视设定。

多了解一点 APM Server

APM Server 如何接收 APM Agents 的资料

APM Server 定义了一个 Events Intake 的 API，而 APM Agents 主要也就是使用这个 API，将我们先前介绍到的以下四种资料传送给 APM Server：

• Transactions
• Spans
• Errors
• Metrics

Intake API 的 Endpoint 如下：

http(s)://{hostname}:{port}/intake/v2/events

RUM 有另外独立的 Endpoints：

http(s)://{hostname}:{port}/intake/v2/rum/events

存取这个 API 使用的是 HTTP POST，并且如同 Elasticsearch _bulk API 的设计一样，使用 newline delimited JSON (NDJSON) 的 Content-Type 来接收一次多笔 Events 的传送，同时在回传结果若有错误时，也会回传每一个 Events 及独立的错误资讯。

官方文件 - APM Events API 里面有详细的介绍四种资料各自的 Schema，有兴趣的读者可以参考。

APM Server 效能调校技巧

针对 APM Server 的效能调校，这边参考官方文件的介绍，有包含以下几点：

1. 调整 output.elasticsearch 的参数

包含以下三种调整方式：

• 适度的增加 output.elasticsearch.worker 的数量。
• 调大 output.elasticsearch.bulk_max_size 的数量，预设值 50 是蛮小的一个数字，如果硬体规格还不错，甚至可以调高到 5120 来试试。
• 确认 queue.mem.events 的数量有被正确的设定是 output.elasticsearch.worker * output.elasticsearch.bulk_max_size 的大小。

2. 调整 Queue Size

透过调整 queue.mem.events 的大小，在 APM Server 使用更多的记忆体来缓存 APM Agents 所传送进来的资料，如果为了能承受 Elasticsearch 发生一段时间无法正常运作，又要保持 APM Server 能接受 APM Agents 不断传送进来的资料时，可以从这边下手。

3. 增加 APM Server 的数量

如果发生 request timeouts 的错误时，通常是因为 APM Server 处理不了当下的资料量了，这时最简单且有效的方式，就是增加 APM Server 的数量。

4. 减少传进 APM Server 资料的 Payload 大小

这部份要从 APM Agents 端下手，如果一次传送到 APM Server 的资料量太大，有可能会发生 Request timeout，这时可以调小 flush interval 的设定，或甚至是降低 sample rate (取样率)。

5. 调整 Anonymous Auth 的 Rate Limit

当 APM Server 处理的量已经消化不完的时候，透过从 Intake API 进行节流，设定 rate_limit.event_limit 来限制一次能进来的资料量，能帮助 APM Server 有效的处理他能处理的资料量，整体的效能使用率会更佳。

6. 记得删除旧资料

预设 APM Server 建立的 ILM (Index Lifecycle Management) Policy 没有包含删除资料、或移到 Cold phase 等操作，这部份记得在使用 APM 时，也一样要做好资料管理的规划，避免 Elasticsearch 的资料随时间不断增长，最终导致资料量过多而影响服务的正常使用。

参考资料

1. 官方文件 - APM Server
2. 官方文件 - APM Events API

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