« APM 版本 8.0 综合监控 »
Elastic 文档 ›Elastic Observability [8.17] ›应用程序和服务监控 ›应用程序性能监控 (APM)

已知问题

编辑

已知问题

编辑

APM 存在以下已知问题

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

Elastic Stack 版本：8.15.1+

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

在 8.15.0 中，APM Server 开始使用 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 Server 版本中，存在一个摄取管道来执行版本检查。 版本检查将使使用与安装的 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 Server 切换为使用数据流生命周期来管理新部署以及具有默认生命周期配置的升级部署的 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. 向规则添加一个或多个检测器类型。

    检测器类型确定何时触发异常规则。例如，当被监控服务的延迟异常时，会触发延迟异常规则。支持的检测器类型为 latency、throughput 和 failed 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 文档

    对于找到的每个损坏的规则，使用上一步中从 API 返回的内容创建一个 JSON 规则文档。 您需要对每个文档进行两处更改

    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 Server 升级到 8.11+ 可能会破坏来自较旧 APM Java 代理的事件接收
编辑

APM Server 版本：>=8.11.0
Elastic APM Java 代理版本：< 1.43.0

如果您正在使用 APM Server (> v8.11.0) 和 Elastic APM Java 代理 (< v1.43.0)，则代理可能正在发送空的直方图指标集。

在以前的 APM Server 版本中，某些数据验证没有正确应用，导致 APM Server 接受不应接受的空直方图指标集。此错误已在 8.11.0 中的 APM Server 中修复。

APM Java 代理 (< v1.43.0) 在某些情况下会发送这种无效数据。 如果您将 APM Server 升级到 v8.11.0+，而没有升级 APM Java 代理版本，则 APM Server 可能会拒绝指标集，并且可能会在 Java 代理中生成其他错误日志。

修复方法是将 Elastic APM Java 代理升级到 >= 1.43.0 的版本。 在elastic/apm-data#157 中查找详细信息。

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

APM Server 版本：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 Server 版本：8.11.0、8.11.1
Elastic APM Java 代理版本：1.39.0+

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

升级后，您将看到以下错误

  • APM Server 错误日志

    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 Server 版本：<= 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 Server 版本：>=8.13.0，<= 8.14.2

如果您使用的是 APM 服务器版本 >=8.13.0，<= 8.14.2，并且使用 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 Server 二进制文件

    • 在 apm-server.yml 中，设置 output.elasticsearch.flush_bytes: 1mib

  • 对于 Fleet 管理的 APM (非 Elastic Cloud)

    • 在 Fleet 中，打开 Settings 选项卡。
    • 在 Outputs 下，找到接收 APM 数据的 Elasticsearch 输出，选择编辑图标。
    • 在 Edit output 弹出框中，在“Advanced YAML configuration”字段中，添加行 flush_bytes: 1mib。

  • 对于 Elastic Cloud

    • 无法编辑 Fleet “Elastic Cloud internal output”。

8.14.3 版本将发布一个修复补丁：elastic/apm-server#13576。

« APM 版本 8.0 综合监控 »