故障排除和限制
Elastic Stack Serverless
警报功能提供了许多用于诊断规则和连接器问题的方法。
规则和连接器会将消息记录到带有 [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 密钥）可能不再可用或有效，从而产生有关这些缺失资源的错误消息。
以下调试工具可用
堆栈管理中的规则列出了您当前所在空间中可用的规则。 当您单击规则名称时，您将被导航到规则的详细信息页面，您可以在其中查看当前活动的警报。 此页面上的开始日期指示何时触发规则，以及针对哪些警报。 此外，条件的持续时间指示实例处于活动状态的时间。
创建或编辑索引阈值规则时，您会看到一个图表，其中显示了规则将针对其运行的数据，从过去的某个日期到现在，每 5 秒更新一次。
结束日期与规则的检查间隔有关。 您可以使用此视图来查看规则是否正在获取您期望的数据，并在视觉上与阈值（图表中的水平线）进行比较。 如果该图表除了阈值线之外不包含任何线，则该规则存在问题，例如，给定指定的索引和字段，没有数据可用，或者存在权限错误。 诊断这些问题可能很困难 - 但可能存在错误情况的日志消息。
有一组丰富的 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":["me@example.com"]}}'
[预览] 此外，还有一个命令行客户端，它使用旧的规则 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":["me@example.com"]}}’
此 HTTP 请求的结果（并由 kbn-action 打印到 stdout）将是由操作返回的数据，以及遇到的任何错误消息。
堆栈管理 > 规则页面包含一个错误横幅，可帮助识别规则的错误
在底层，警报功能使用一个名为任务管理器的插件，该插件处理任务的计划、运行和错误处理。 这意味着警报功能中的故障情况有时会通过任务管理器机制而不是规则机制来显示。
任务管理器提供了一个可见状态，可用于诊断问题，并且有据可查健康监控和故障排除。 任务管理器使用 .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- 另一个时间字段，如
runAt。 这是计划任务下次运行的时间。 如果这是在过去，并且状态为空闲，则任务管理器已经落后或未运行。 如果它在过去，但状态为正在运行，则任务管理器已将其拾取并正在处理它，这被认为是健康的。 retryAt- 另一个时间字段，如
runAt。 如果填充了此字段，则任务管理器当前正在运行该任务。 如果任务未完成（并且未标记为失败），则任务管理器将在retryAt下指定的时间再次尝试运行它。
调查底层任务可以帮助您评估您所看到的问题是根本原因在于规则根本没有运行，是正在运行但失败，还是正在运行但表现出与预期不同的行为（此时您应该关注规则本身，而不是任务）。
除了上述方法外，请参考以下方法和常见问题
如果集群性能因过多或昂贵的规则而降低，并且 Kibana 运行缓慢或无响应，您可以通过更新其 设置 来暂时降低任务管理器的负载
xpack.task_manager.capacity: 5
xpack.task_manager.poll_interval: 1h
此方法应仅作为最后的手段暂时使用，以在 Kibana 无响应时恢复其功能，并且尝试识别和暂停或禁用运行缓慢的规则未能解决问题。 它严重限制了所有后台任务，而不仅仅是与警报功能相关的任务。 任务管理器一次只运行一个任务，并且每小时都会寻找更多工作。
以下限制和已知问题适用于 Kibana 警报功能的 9.0.0 版本
如果您在 Observability 或 Elastic Security 应用程序中创建一个规则，则其警报在 堆栈管理 > 规则 中不可见。 您只能在创建规则的 Kibana 应用程序中查看它们。 如果您使用创建规则 API，则警报的可见性与 consumer 属性相关。