故障排除和限制

编辑

故障排除和限制编辑

警报功能提供了许多选项,用于诊断规则和连接器的问题。

检查 Kibana 日志编辑

规则和连接器分别使用 [alerting] 和 [actions] 标签记录到 Kibana 日志记录器。通常,消息是警告和错误。在某些情况下,错误可能是误报,例如,当连接器被删除并且规则正在运行时。

server    log   [11:39:40.389] [error][alerting][alerting][plugins][plugins] Executing Rule "5b6237b0-c6f6-11eb-b0ff-a1a0cbcf29b6" has resulted in Error: Saved object [action/fdbc8610-c6f5-11eb-b0ff-a1a0cbcf29b6] not found

某些资源(例如已保存的对象和 API 密钥)可能不再可用或有效,从而产生有关这些丢失资源的错误消息。

使用调试工具编辑

可以使用以下调试工具

  • Kibana 7.10 及更高版本提供了一个 测试连接器 UI。
  • Kibana 7.11 及更高版本包括改进的 Webhook 错误消息、针对操作和连接器的更好的整体调试日志记录,以及任务管理器 诊断端点

使用规则和连接器列表了解当前状态并查找问题编辑

堆栈管理 中的 规则 列出了您当前所在空间中可用的规则。单击规则名称时,您将导航到该规则的 详细信息页面,您可以在其中查看当前活动的警报。此页面上的开始日期指示规则何时触发,以及针对哪些警报触发。此外,条件的持续时间表示实例的活动时间。

Alerting management details

预览索引阈值规则图表编辑

创建或编辑索引阈值规则时,您会看到规则将对其进行操作的数据图表,从过去某个日期到现在,每 5 秒更新一次。

Index Threshold chart

结束日期与规则的检查间隔有关。您可以使用此视图查看规则是否获取了您预期的数据,并在视觉上与阈值(图表中的水平线)进行比较。如果图表中除阈值线外不包含任何线,则表示规则存在问题,例如,在指定的索引和字段下没有可用数据,或者存在权限错误。诊断这些问题可能很困难,但错误情况可能会有日志消息。

使用 REST API编辑

有一组丰富的 HTTP 端点可用于内省和管理规则和连接器。操作可用的 HTTP 端点之一是 运行连接器 API。您可以使用它来“测试”操作。例如,如果您创建了一个服务器日志操作,则可以通过对端点执行 curl 操作来运行它

curl -X POST -k \
 -H 'kbn-xsrf: foo' \
 -H 'content-type: application/json' \
 api/actions/connector/a692dc89-15b9-4a3c-9e47-9fb6872e49ce/_execute \
 -d '{"params":{"subject":"hallo","message":"hallo!","to":["[email protected]"]}}'

[预览] 此功能处于技术预览阶段,可能会在未来版本中更改或删除。Elastic 将努力解决任何问题,但技术预览版中的功能不受官方 GA 功能支持 SLA 的约束。 此外,还有一个使用旧规则 API 的命令行客户端,它可能更容易使用,但必须针对新的 API 进行更新。用于列出、创建、编辑和删除警报(规则)和操作(连接器)的 CLI 工具在 kbn-action 中提供,您可以按如下方式安装它

npm install -g pmuellr/kbn-action

相同的 REST POST _execute API 命令将是

kbn-action execute a692dc89-15b9-4a3c-9e47-9fb6872e49ce ‘{"params":{"subject":"hallo","message":"hallo!","to":["[email protected]"]}}’

此 HTTP 请求的结果(并由 kbn-action 打印到 stdout)将是由操作返回的数据,以及如果遇到错误,还会返回错误消息。

查找错误横幅编辑

堆栈管理 > 规则 页面包含一个错误横幅,可帮助识别规则的错误

Rule management page with the errors banner

任务管理器诊断编辑

在后台,警报功能使用名为任务管理器的插件,该插件处理任务的调度、运行和错误处理。这意味着警报功能中的故障情况有时会由任务管理器机制而不是规则机制来揭示。

任务管理器提供了一个可见的状态,可用于诊断问题,并且有很好的文档记录 运行状况监控故障排除。任务管理器使用 .kibana_task_manager 索引,这是一个内部索引,包含表示系统中任务的所有已保存对象。

从规则到其任务编辑

创建规则时,将创建一个任务,并安排在指定的时间间隔运行。例如,当创建一个规则并将其配置为每 5 分钟检查一次时,则预计底层任务将每 5 分钟运行一次。实际上,每次规则运行后,任务都会被安排在 5 分钟后再次运行,而不是无限期地每 5 分钟运行一次。

如果您使用 警报 API(例如获取规则 API 或查找规则 API),您将获得一个包含规则详细信息的对象

{
  "id":"ed30d1b0-7c9e-11ed-ba24-0b137d501cb7",
  "name":"cluster_health_rule",
  "consumer":"alerts",
  "enabled":true,
  ...
  "scheduled_task_id":"ed30d1b0-7c9e-11ed-ba24-0b137d501cb7",
  ...
  "next_run":"2022-12-15T17:56:55.713Z"
}

您要查找的字段是名为 scheduled_task_id 的字段,其中包含任务管理器任务的标识符。然后,您可以转到控制台并在系统索引中找到有关该任务的更多信息

GET .kibana_task_manager/_doc/task:ed30d1b0-7c9e-11ed-ba24-0b137d501cb7

例如

{
  "_index": ".kibana_task_manager_8.7.0_001",
  "_id": "task:ed30d1b0-7c9e-11ed-ba24-0b137d501cb7",
  "_version": 85,
  "_seq_no": 13009,
  "_primary_term": 3,
  "found": true,
  "_source": {
    "migrationVersion": {
      "task": "8.5.0"
    },
    "task": {
      "retryAt": null,
      "runAt": "2022-12-15T18:05:19.804Z",
      "startedAt": null,
      "params": """{"alertId":"ed30d1b0-7c9e-11ed-ba24-0b137d501cb7","spaceId":"default","consumer":"alerts"}""",
      "ownerId": null,
      "enabled": true,
      "schedule": {
        "interval": "1m"
      },
      "taskType": "alerting:monitoring_alert_cluster_health",
      "scope": [
        "alerting"
      ],
      "traceparent": "",
      "state": """{"alertTypeState":{"lastChecked":1671127459923},"alertInstances":{},"alertRecoveredInstances":{},"previousStartedAt":"2022-12-15T18:04:19.804Z"}""",
      "scheduledAt": "2022-12-15T18:04:16.824Z",
      "attempts": 0,
      "status": "idle"
    },
    "references": [],
    "updated_at": "2022-12-15T18:04:19.998Z",
    "coreMigrationVersion": "8.7.0",
    "created_at": "2022-12-15T17:35:55.204Z",
    "type": "task"
  }
}

为了使规则正常工作,此任务必须处于正常状态。其运行状况信息可在 任务管理器运行状况 API 中或启用调试日志记录时的详细日志中找到。诊断任务的运行状况状态时,您最有可能对以下字段感兴趣

status
这是任务的当前状态。任务管理器当前是否正在运行?任务管理器是否处于空闲状态,而您正在等待它运行?或者任务管理器是否已尝试运行但失败了?
runAt
这是任务计划下次运行的时间。如果这在过去,并且状态为空闲,则表示任务管理器已落后或未运行。如果它在过去,但状态正在运行,则表示任务管理器已将其拾取并正在处理它,这被认为是健康的。
retryAt
另一个时间字段,如 runAt。如果填充了此字段,则表示任务管理器当前正在运行该任务。如果任务未完成(并且未标记为失败),则任务管理器将在 retryAt 下指定的时间再次尝试该任务。

调查底层任务可以帮助您判断您所看到的问题是根本没有运行规则,还是运行规则但失败了,或者运行规则但表现出的行为与预期不同(此时您应该关注规则本身,而不是任务)。

除了上述方法之外,请参阅以下方法和常见问题

暂时限制所有任务编辑

如果由于过多或过于昂贵的规则导致集群性能下降,并且 Kibana 变得缓慢或无响应,您可以通过更新其 设置 来临时减少任务管理器的负载

xpack.task_manager.max_workers: 1
xpack.task_manager.poll_interval: 1h

此方法应仅作为最后的手段临时使用,以便在 Kibana 无响应且尝试识别和 暂停或禁用 运行缓慢的规则未能解决问题时恢复 Kibana 的功能。它会严重限制所有后台任务,而不仅仅是与警报功能相关的任务。任务管理器一次只运行一个任务,并且每小时查找一次更多工作。

限制编辑

以下限制和已知问题适用于 Kibana 警报功能的 8.14.3 版本

警报可见性编辑

如果您在 Observability 或 Elastic Security 应用程序中创建规则,则其警报在 堆栈管理 > 规则 中不可见。您只能在创建规则的 Kibana 应用程序中查看它们。如果您使用 创建规则 API,则警报的可见性与 consumer 属性相关。