« APM 版本 8.0 日志监控 »
Elastic 文档 ›Elastic 可观测性 [8.14] ›应用程序性能监控 (APM)

已知问题

编辑

已知问题编辑

APM 存在以下已知问题

升级到 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 文档

    对于找到的每个损坏规则，创建一个 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 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 接受了不应该接受的空直方图指标集。此错误在 APM Server 8.11.0 中修复。

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+ 将新的 JVM 指标发送到 APM Server v8.9.x 和 v8.10.x，则升级到 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 版本 8.0 日志监控 »