故障排除和限制

编辑

故障排除和限制编辑

警报提供了许多选项来诊断规则和连接器的问题。

检查 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 -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 进行更新。在 kbn-action 中提供了用于列出、创建、编辑和删除警报(规则)和操作(连接器)的 CLI 工具,您可以按如下方式安装

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 中获得,或者如果启用了调试日志记录,则可在详细日志中获得。在诊断任务的健康状态时,您很可能对以下字段感兴趣

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

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

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

暂时限制所有任务编辑

如果集群性能因过度或昂贵的规则而下降,并且 Kibana 变得迟缓或无响应,您可以通过更新其 设置 来暂时减少对任务管理器的负载

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

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

限制编辑

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

警报可见性编辑

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