Keep 的规格说明和压力测试
TIP
如果您正在使用 Keep 并遇到性能问题，我们非常乐意为您提供帮助。请加入我们的 slack 并在 #help 频道发送消息。
概述
规格和压力测试对于确保 Keep 的稳健性能和可扩展性至关重要。 本文档概述了在不同负载条件下测试 Keep 的关键重点领域，同时考虑了较小环境的设置简单性和较大部署的可扩展性机制。
Keep 最初被设计为用户友好的方式，用于处理少于 10,000 条告警的设置。然而，随着告警量增加，用户可以利用高级功能，例如使用 Elasticsearch 进行文档存储和使用 Redis + ARQ 进行基于队列的告警摄取。虽然这些高级配置在此未完整记录，但它们是支持的，可以在我们的 Slack 社区进一步讨论。
如何重现
要重现上述压力测试场景，请参阅 Keep 仓库中的 STRESS.md 文件。本文档提供了关于如何设置、运行和测量 Keep 在不同负载条件下的性能的分步说明。
性能测试
影响规格的主要因素
影响 Keep 规格要求的主要参数是：
- 告警量：告警被摄取到系统的速率。
- 告警总数：系统中存储的告警累计数量。
- 工作流数量：作为告警结果运行多少自动化。
主要组件：
- Keep 后端 - API 和业务逻辑。在 gunicorn 上提供 FastAPI 的容器。
- Keep 前端 - Web 应用。提供 react 应用的容器。
- 数据库 - 存储告警和任何其他操作数据。
- Elasticsearch（默认退出）- 将告警存储为文档以获得更好的搜索性能。
- Redis（默认退出）- 与 ARQ 一起使用，作为告警队列。
测试场景：
低量（< 10,000 条告警总数，每天数百条告警）：
- 设置：使用标准关系数据库（如 MySQL、PostgreSQL）和默认配置。
- 预期：Keep 应以最小的资源使用处理查询和告警摄取。
中量（10,000 - 100,000 条告警总数，每天数千条告警）：
- 设置：扩展数据库到更大的实例或集群。根据 DB 调整最佳实践（例如增加 innodb_buffer_pool_size）
- 预期：CPU 和 RAM 使用应成比例增加，但保持在可接受的范围内。
- 高量（100,000 - 1,000,000 条告警总数，每天超过五千条告警）：
- 设置：使用 Elasticsearch 部署 Keep 以将告警存储为文档。
- 预期：尽管告警量很大，系统应保持性能水平，增加的资源使用通过扩展策略进行管理。
- 非常高量（> 1,000,000 条告警总数，每天数万条告警）：
- 设置：使用 Elasticsearch 部署 Keep 以将告警存储为文档。
- 设置 #2：使用 Redis 和 ARQ 部署 Keep 以使用 Redis 作为队列。
按告警量的推荐规格
| 告警数量 | Keep 后端 | Keep 数据库 | Redis | Elasticsearch |
|---|---|---|---|---|
| < 10,000 | 1 vCPUs, 2GB RAM | 2 vCPUs, 8GB RAM | 不需要 | 不需要 |
| 10,000 - 100,000 | 4 vCPUs, 8GB RAM | 8 vCPUs, 32GB RAM, 优化的索引 | 不需要 | 不需要 |
| 100,000 - 500,000 | 8 vCPUs, 16GB RAM | 8 vCPUs, 32GB RAM, 高级索引 | 4 vCPUs, 8GB RAM | 8 vCPUs, 32GB RAM, 2-3 个节点 |
| > 500,000 | 8 vCPUs, 16GB RAM | 8 vCPUs, 32GB RAM, 高级索引、分片 | 4 vCPUs, 8GB RAM | 8 vCPUs, 32GB RAM, 2-3 个节点 |
按操作类型、负载和规格的性能
| 操作类型 | 负载 | 规格 | 执行时间 |
|---|---|---|---|
| 摘要告警 | 每分钟 100 条告警 | 4 vCPUs, 8GB RAM | 约 0.5 秒 |
| 摘要告警 | 每分钟 500 条告警 | 8 vCPUs, 16GB RAM | 约 1 秒 |
| 摘要告警 | 每分钟 1,000 条告警 | 16 vCPUs, 32GB RAM | 约 1.5 秒 |
| 运行工作流 | 每分钟 10 个工作流 | 4 vCPUs, 8GB RAM | 约 1 秒 |
| 运行工作流 | 每分钟 50 个工作流 | 8 vCPUs, 16GB RAM | 约 2 秒 |
| 运行工作流 | 每分钟 100 个工作流 | 16 vCPUs, 32GB RAM | 约 3 秒 |
| 通过队列摄取 | 每分钟 100 条告警 | 4 vCPUs, 8GB RAM, Redis | 约 0.3 秒 |
| 通过队列摄取 | 每分钟 500 条告警 | 8 vCPUs, 16GB RAM, Redis | 约 0.8 秒 |
| 通过队列摄取 | 每分钟 1,000 条告警 | 16 vCPUs, 32GB RAM, Redis | 约 1.2 秒 |
表格说明：
- 操作类型：正在测试的特定操作（例如摘要告警、运行工作流）。
- 负载：每分钟处理的操作数量（例如每分钟告警数量）。
- 规格：用于该操作的 CPU、RAM 和附加服务。
- 执行时间：在给定负载和规格下完成操作的大致时间。
微调
由于任何部署都有其自己的特性，例如告警量与告警总数之间的平衡或告警量与工作流数量之间的平衡，Keep 可以使用以下参数进行微调：
- Worker 数量：调整 Gunicorn worker 数量以更有效地处理 API 请求。您还可以启动额外的 API 服务器来分配负载。
- 区分 API 服务器 Worker 和摘要告警 Worker：将处理 API 请求的 worker 与负责摘要告警的 worker 分开，确保每组任务根据其特定需求进行优化。
- 为数据库添加更多 RAM：增加分配给数据库的 RAM 可以帮助管理更大的数据集和提高查询性能，特别是在处理大量告警时。
- 优化数据库配置：Keep 主要在 MySQL 和 PostgreSQL 上进行了测试。不同的数据库可能有不同的微调机制。
- 水平扩展：考虑部署 API 和数据库服务的额外实例以更有效地分配负载。
常见问题
1. 如何估计我需要 Keep 的什么规格？
要估计 Keep 所需的规格，请考虑每分钟告警数量和您希望处理的告警总数。请参阅上面的 按告警量的推荐规格 表，将您预期的负载与适当的资源进行匹配。
2. 我如何知道我是否需要 Elasticsearch？
当您处理超过 50,000 条告警总数或需要传统关系数据库无法有效处理的高级搜索和查询功能时，通常需要 Elasticsearch。如果您的系统性能随着告警量增加而显著下降，可能是时候考虑使用 Elasticsearch 了。
3. 我如何知道我是否需要 Redis？
当您的告警摄取速率超过每分钟 1,000 条告警，或者您注意到由于高摄取速率 API 已成为瓶颈时，推荐使用 Redis。Redis 与 ARQ（异步 Redis 队列）结合使用可以帮助更有效地管理和分配负载。
4. 如果 Keep 的性能仍然不足，我该怎么办？
如果您已根据建议进行了扩展，但仍然面临性能问题，请考虑：
- 优化您的数据库配置：索引、分片和查询优化可以产生显著差异。
- 水平扩展：跨多个 API 和数据库服务实例分配负载。
- 联系我们的 Slack 社区：要获得个性化支持，请在 Slack 上联系我们，我们将帮助您排除故障并优化您的 Keep 部署。
如有任何其他问题或定制建议，请随时加入我们的 Slack 社区，我们的团队和其他用户可以为您提供帮助。