已知问题

编辑

APM 存在以下已知问题:

组件模板中需要 prefer_ilm 来创建自定义生命周期策略
编辑

Elastic Stack 版本:8.15.1+

此问题发生在使用 8.15.1+ 版本创建集群时。 对于在 8.15.1+ 中创建的任何 APM 数据流,都会出现此问题。如果自定义组件模板是在 8.15.0 或之前版本创建的,则不会出现此问题。

在 8.15.0 中,APM 服务器开始使用 apm-data 插件 来管理数据流、摄取管道、生命周期策略等等。在 8.15.1 中,引入了一个修复程序来解决使用默认 ILM 策略的旧集群中的未管理索引。此修复程序添加了对默认 ILM 策略(如果存在)的回退,并将 prefer_ilm 配置设置为 false。此设置会影响同时生效 ILM 和数据流生命周期 (DSL) 的集群,例如在上述情况下使用 @custom 组件模板配置自定义 ILM 策略时。

要使用组件模板覆盖这些新集群的 ILM 策略,请按照 更新的自定义 ILM 指南prefer_ilm 配置设置为 true

升级到 v8.15.x 版本可能会导致数据摄取失败
编辑

Elastic Stack 版本:8.15.0、8.15.1、8.15.2、8.15.3
在 Elastic Stack 版本 8.15.4 中修复

此问题仅在将 Elastic Stack 从 8.12.2 或更低版本直接升级到 8.15.4 之前的任何 8.15.x 版本时才会发生。使用任何 8.15.x 版本创建集群时,或从 8.12.2 升级到 8.13.x 或 8.14.x,然后再升级到 8.15.x 时,不会出现此问题。

在 8.13.0 之前的 APM 服务器版本中,存在一个摄取管道来执行版本检查。版本检查将使与已安装 APM 的摄取管道的版本不同的 APM 服务器生成的任何 APM 文档失败。在 8.13.0 中,去除了摄取管道中的版本检查。由于从 8.15 开始设置 apm 数据管理资源的内部更改以及 Elasticsearch 中与 数据流的延迟滚动 相关的错误,升级时不会删除进行版本检查的摄取管道,并阻止数据摄取。

如果部署运行的是 8.15.0,请将部署升级到 8.15.1 或更高版本。需要手动滚动所有 APM 数据流才能获取新的索引模板并删除有故障的摄取管道版本检查。执行以下 Elasticsearch 请求(假设使用了 default 命名空间,如有必要请调整):

POST /traces-apm-default/_rollover
POST /traces-apm.rum-default/_rollover
POST /logs-apm.error-default/_rollover
POST /logs-apm.app-default/_rollover
POST /metrics-apm.app-default/_rollover
POST /metrics-apm.internal-default/_rollover
POST /metrics-apm.service_destination.1m-default/_rollover
POST /metrics-apm.service_destination.10m-default/_rollover
POST /metrics-apm.service_destination.60m-default/_rollover
POST /metrics-apm.service_summary.1m-default/_rollover
POST /metrics-apm.service_summary.10m-default/_rollover
POST /metrics-apm.service_summary.60m-default/_rollover
POST /metrics-apm.service_transaction.1m-default/_rollover
POST /metrics-apm.service_transaction.10m-default/_rollover
POST /metrics-apm.service_transaction.60m-default/_rollover
POST /metrics-apm.transaction.1m-default/_rollover
POST /metrics-apm.transaction.10m-default/_rollover
POST /metrics-apm.transaction.60m-default/_rollover
升级到 v8.15.0 可能会导致 APM 索引丢失其生命周期策略
编辑

Elastic Stack 版本:8.15.0
在 Elastic Stack 版本 8.15.1 中修复

此问题仅在将 Elastic Stack 升级到 8.15.0 时才会发生。使用 8.15.0 创建集群时,不会出现此问题。如果使用自定义组件模板配置了自定义 ILM 策略,也不会出现此问题。

在 8.15.0 中,APM 服务器切换到使用数据流生命周期来管理新部署以及具有默认生命周期配置的升级部署的 APM 索引的数据保留。不幸的是,由于在 8.15.0 之前创建的任何数据流都没有数据流生命周期配置,因此此类现有数据流对于默认生命周期配置而言将变得未管理。

升级到 8.15.1 可以解决为 APM 数据流创建的任何新索引的生命周期问题。但是,如果默认 ILM 策略已启用,则在 8.15.0 版本中创建的索引将保持未管理状态。要修复这些未管理的索引,请考虑以下方法之一:

  1. 不再需要时手动删除未管理的索引。
  2. 显式配置 APM 数据流以使用默认数据流生命周期配置。此方法会将所有受影响的数据流迁移到使用数据流生命周期,从而保持与默认 ILM 策略等效的行为。仅对由于缺少默认 ILM 策略而具有未管理索引的数据流应用此修复程序。

    PUT _data_stream/{{data_stream_name}}-{{data_stream_namespace}}/_lifecycle
    {
      "data_retention": <data_retention_period>
    }

每个数据流的默认 <data_retention_period> 可在此 指南 中找到。

此问题已在 8.15.1 中修复 (elastic/elasticsearch#112432)。

升级到 v8.13.0 到 v8.13.2 会破坏 APM 异常规则
编辑

Elastic Stack 版本:8.13.0、8.13.1、8.13.2
在 Elastic Stack 版本 8.13.3 中修复

将 Elastic Stack 升级到 8.13.0、8.13.1 或 8.13.2 时会发生此问题。除非您主动监控 Kibana 日志,否则此问题可能会被忽略。以下日志表示存在此问题:

"params invalid: [anomalyDetectorTypes]: expected value of type [array] but got [undefined]"

出现此问题是因为在 8.13.0 中添加了一个非可选参数 anomalyDetectorTypes,但没有自动化迁移脚本。这会破坏预先存在的规则,因为它们没有此参数,并且会验证失败。此问题已在 v8.13.3 中修复。

有三种方法可以修复此错误:

  • 升级到 8.13.3 版本
  • 在 APM UI 中修复损坏的异常规则(无需升级)
  • 使用 Kibana API 修复损坏的异常规则(无需升级)

在 APM UI 中修复损坏的异常规则

  1. 在 Kibana 的任何 APM 页面中,选择 警报和规则管理规则
  2. 通过将 类型 设置为 APM 异常 来过滤规则。
  3. 对于列表中的每个异常规则,选择铅笔图标以编辑规则。
  4. 向规则添加一个或多个 检测器类型

    检测器类型确定异常规则何时触发。例如,延迟异常规则将在监控的服务延迟异常时触发。支持的检测器类型包括 latencythroughputfailed transaction rate

  5. 单击 保存

使用 Kibana API 修复损坏的异常规则

  1. 查找损坏的规则

    要识别处于此确切状态的规则,您可以使用 查找规则端点 并搜索 APM 异常规则类型以及指示规则处于损坏状态的确切错误消息。我们还将使用 fields 参数来指定稍后发出更新请求时仅需要的字段。

    • search_fields=alertTypeId
    • search=apm.anomaly
    • filter=alert.attributes.executionStatus.error.message:"params invalid: [anomalyDetectorTypes]: expected value of type [array] but got [undefined]"
    • fields=[id, name, actions, tags, schedule, notify_when, throttle, params]

    编码后的请求可能如下所示:

    curl -u "$KIBANA_USER":"$KIBANA_PASSWORD" "$KIBANA_URL/api/alerting/rules/_find?search_fields=alertTypeId&search=apm.anomaly&filter=alert.attributes.executionStatus.error.message%3A%22params%20invalid%3A%20%5BanomalyDetectorTypes%5D%3A%20expected%20value%20of%20type%20%5Barray%5D%20but%20got%20%5Bundefined%5D%22&fields=id&fields=name&fields=actions&fields=tags&fields=schedule&fields=notify_when&fields=throttle&fields=params"
    示例结果:
    {
      "page": 1,
      "total": 1,
      "per_page": 10,
      "data": [
        {
          "id": "d85e54de-f96a-49b5-99d4-63956f90a6eb",
          "name": "APM Anomaly Jason Test FAILING [2]",
          "tags": [
            "test",
            "jasonrhodes"
          ],
          "throttle": null,
          "schedule": {
            "interval": "1m"
          },
          "params": {
            "windowSize": 30,
            "windowUnit": "m",
            "anomalySeverityType": "warning",
            "environment": "ENVIRONMENT_ALL"
          },
          "notify_when": null,
          "actions": []
        }
      ]
    }
  2. 准备更新 JSON 文档

    对于找到的每个损坏规则,创建一个 JSON 规则文档,其中包含上一步中 API 返回的内容。您需要对每个文档进行两处更改:

    1. 删除 id 密钥,但保留与该文档关联的值(例如,将文件重命名为 {id}.json)。id 不能作为 PUT 请求的请求正文的一部分发送,但您需要它用于 URL 路径。
    2. "anomalyDetectorTypes" 添加到 "params" 块中,使用如下所示的默认值来模拟 8.13 之前的行为:

      {
        "params": {
          // ... other existing params should stay here,
          // with the required one added to this object
          "anomalyDetectorTypes": [
            "txLatency",
            "txThroughput",
            "txFailureRate"
          ]
        }
      }
  3. 使用 PUT /api/alerting/rule/{id} API 更新每个规则

    对于每个规则,使用该规则的 ID 及其上一步中存储的更新文档,向 更新规则端点 提交 PUT 请求。例如,假设第一个损坏规则的 ID 是 046c0d4f

    curl -u "$KIBANA_USER":"$KIBANA_PASSWORD" -XPUT "$KIBANA_URL/api/alerting/rule/046c0d4f" -H 'Content-Type: application/json' -H 'kbn-xsrf: rule-update' -d @046c0d4f.json

    PUT 请求成功执行后,规则将不再损坏。

将 APM 服务器升级到 8.11+ 可能会破坏来自较旧 APM Java 代理的事件摄取
编辑

APM 服务器版本:>=8.11.0
Elastic APM Java 代理版本:< 1.43.0

如果您使用的是 APM 服务器(> v8.11.0)和 Elastic APM Java 代理(< v1.43.0),则代理可能会发送空的直方图指标集。

在以前的 APM 服务器版本中,一些数据验证未正确应用,导致 APM 服务器接受了它不应该接受的空直方图指标集。此错误已在 8.11.0 的 APM 服务器中修复。

APM Java 代理(< v1.43.0)在某些情况下会发送这种无效数据。如果您在升级 APM Java 代理版本的情况下将 APM 服务器升级到 v8.11.0+,则 APM 服务器可能会拒绝指标集,并可能导致 Java 代理中出现其他错误日志。

解决方法是将 Elastic APM Java 代理升级到 >= 1.43.0 版本。详细信息请参见 elastic/apm-data#157

traces-apm@custom 摄取管道意外应用于某些数据流
编辑

APM 服务器版本:8.12.0

如果您使用的是 Elastic APM Server v8.12.0,则 traces-apm@custom 摄取管道现在还会应用于数据流 traces-apm.sampled-*traces-apm.rum-*,并且对 traces-apm-* 应用了两次。此错误会影响具有非空 traces-apm@custom 摄取管道的用户。

如果您依赖于 8.12.0 中的此意外行为,请将您的管道重命名为 traces-apm.integration@custom 以在更高版本中保留此行为。

在 8.12.1 中发布了修复程序:elastic/kibana#175448

在 8.9 和 8.10 中摄取新的 JVM 指标会破坏升级到 8.11 并停止摄取
编辑

APM 服务器版本:8.11.0、8.11.1
Elastic APM Java 代理版本:1.39.0+

如果您使用 Elastic APM Java 代理 v1.39.0+ 将新的 JVM 指标发送到 APM Server v8.9.x 和 v8.10.x,则升级到 8.11.0 或 8.11.1 将会静默失败并停止摄取 APM 指标。

升级后,您将看到以下错误:

  • APM 服务器错误日志:

    failed to index document in 'metrics-apm.internal-default' (fail_processor_exception): Document produced by APM Server v8.11.1, which is newer than the installed APM integration (v8.10.3-preview-1695284222). The APM integration must be upgraded.
  • 集成包升级的 Fleet 错误:

    Failed installing package [apm] due to error: [ResponseError: mapper_parsing_exception
    	Root causes:
    		mapper_parsing_exception: Field [jvm.memory.non_heap.pool.committed] attempted to shadow a time_series_metric]

在 8.11.2 中发布了修复程序:elastic/kibana#171712

通过 Fleet 升级 APM 集成包会导致过度的数据流滚动
编辑

APM 服务器版本:<= 8.12.1 +

如果您正在将APM集成包升级到8.12.1及以下的任何版本,在某些极少数情况下,升级可能会因映射冲突错误而失败。升级过程会不断地重试数据流,试图绕过该错误,但最终失败。结果,会创建许多用于APM数据流的空后端索引。

升级期间,您将看到类似于以下的错误

  • 集成包升级的 Fleet 错误:

    Mappings update for metrics-apm.service_destination.10m-default failed due to ResponseError: illegal_argument_exception
    	Root causes:
    		illegal_argument_exception: Mapper for [metricset.interval] conflicts with existing mapper:
    	Cannot update parameter [value] from [10m] to [null]

8.12.2版本中已发布修复程序:elastic/apm-server#12219

性能下降:APM向Elasticsearch输出发出过多的小批量请求
编辑

APM服务器版本:>=8.13.0,<= 8.14.2

如果您使用的是>=8.13.0,<= 8.14.2版本的APM服务器,并使用Elasticsearch输出,请不要指定任何output.elasticsearch.flush_bytes,也不要通过将output.elasticsearch.compression_level设置为0来显式禁用压缩,否则APM服务器将发出24KB大小的小批量请求,并且需要发出更多批量请求来维持原始吞吐量。这会导致Elasticsearch承受更高的负载,并且APM服务器可能会出现Elasticsearch反压症状。

出现这种情况是因为引入了性能下降,导致批量索引器刷新字节的默认值从1MB降低到24KB。

受影响的APM服务器将发出以下日志

flush_bytes config value is too small (0) and might be ignored by the indexer, increasing value to 24576

要解决此问题,请修改APM中的Elasticsearch输出配置。

  • 对于APM服务器二进制文件

    • apm-server.yml中,设置output.elasticsearch.flush_bytes: 1mib
  • 对于Fleet管理的APM(非Elastic Cloud)

    • 在Fleet中,打开“设置”选项卡。
    • 在“输出”下,找到接收来自APM的Elasticsearch输出,选择编辑图标。
    • 在“编辑输出”弹出窗口中,“高级YAML配置”字段中,添加一行flush_bytes: 1mib
  • 对于Elastic Cloud

    • 无法编辑Fleet的“Elastic Cloud内部输出”。

8.14.3版本中将发布修复程序:elastic/apm-server#13576