你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
选择目标 Azure 平台来托管导出的历史数据
在迁移过程中做出的重要决策之一是存储历史数据的位置。 若要做出此决定，需要了解并能够比较各种目标平台。
本文比较了目标平台的性能、成本、可用性和管理开销。
注意
此表中的注意事项仅适用于历史日志迁移，不适用于其他方案，例如长期保留。
| 基本日志/存档 | Azure 数据资源管理器 (ADX) | Azure Blob 存储 | ADX + Azure Blob 存储 | |
|---|---|---|---|---|
| 功能： | • 以较低的成本使用大多数现有 Azure Monitor 日志体验。 • 基本日志保留 8 天，然后（根据原始保留期）自动传输到存档。 • 使用搜索作业跨 PB 的数据搜索并查找特定事件。 • 若要对特定时间范围进行深入调查，请从存档还原数据。 然后，数据在热缓存中可用，以便进一步分析。 |
• ADX 和 Microsoft Sentinel 都使用 Kusto 查询语言 (KQL)，使你能够查询、聚合或关联两个平台中的数据。 例如，可以从 Microsoft Sentinel 运行 KQL 查询，将 ADX 中存储的数据与 Log Analytics 中存储的数据联接在一起。 • 使用 ADX，可以大幅控制群集大小和配置。 例如，可以创建更大的群集以实现更高的引入吞吐量，或创建较小的群集来控制成本。 |
• Blob 存储最适合存储巨量的非结构化数据。 • 提供竞争性成本。 • 适用于组织不优先考虑辅助功能或性能的方案，例如，当组织必须符合合规性或审核要求时。 |
• 数据存储在 Blob 存储中，成本较低。 • 使用 ADX 查询 KQL 中的数据，使你能够轻松访问数据。 了解如何使用 ADX 查询 Azure Monitor 数据 |
| 可用性： | 非常好 存档和搜索选项易于使用，可从 Microsoft Sentinel 门户访问。 但是，数据不能立即用于查询。 你需要执行搜索来检索数据，这可能需要一些时间，具体取决于要扫描和返回的数据量。 |
好 在 Microsoft Sentinel 的上下文中相当容易使用。 例如，可以使用 Azure 工作簿可视化跨 Microsoft Sentinel 和 ADX 分布的数据。 还可以使用 ADX 代理从 Microsoft Sentinel 门户查询 ADX 数据。 |
差 使用历史数据迁移，可能需要处理数百万个文件，探索数据会成为挑战。 |
一般 虽然使用 externaldata 运算符需要应用大量 blob，但是使用外部 ADX 表可以消除此问题。 外部表定义了解 Blob 存储文件夹结构，并允许以透明方式查询许多不同 Blob 和文件夹中包含的数据。 |
| 管理开销： | 完全托管 搜索和存档选项完全托管，不会增加管理开销。 |
高 ADX 是 Microsoft Sentinel 的外部，需要监视和维护。 |
低 虽然此平台需要很少的维护，但选择此平台会添加监视和配置任务，例如设置生命周期管理。 |
中等 使用此选项，可以维护和监视 ADX 和 Azure Blob 存储，这两个组件都是 Microsoft Sentinel 的外部组件。 虽然 ADX 有时可以关闭，但请考虑使用此选项的额外管理开销。 |
| 性能： | 中等 通常，使用搜索作业与存档中的基本日志进行交互，这些日志适合在维护对数据的访问权限时使用，但不需要立即访问数据。 |
高到低 • ADX 群集的查询性能取决于群集中的节点数、群集虚拟机 SKU、数据分区等。 • 将节点添加到群集时，性能会提高，并增加成本。 • 如果使用 ADX，建议配置群集大小来平衡性能和成本。 此配置取决于组织的需求，包括完成迁移需要多快、访问数据的频率以及预期的响应时间。 |
低 提供两个性能层：高级版或标准层。 尽管这两个层都是长期存储的选项，但标准层更具成本效益。 了解性能和可伸缩性限制。 |
低 由于数据驻留在 Blob 存储中，因此性能受该平台的限制。 |
| 成本： | 高 成本由两个组件组成： • 引入成本。 引入到基本日志中的每个 GB 数据都受 Microsoft Sentinel 和 Azure Monitor 日志引入成本的约束，成本高达大约 1 美元/GB。 查看定价详细信息。 • 存档成本。 存档层中数据的成本高达每月大约 0.02 美元/GB。 查看定价详细信息。 除了这两个成本组件之外，如果需要频繁访问数据，则通过搜索作业访问数据时会产生额外的成本。 |
高到低 • 由于 ADX 是虚拟机群集，因此根据计算、存储和网络使用情况以及 ADX 标记收费，查看定价详细信息。 因此，添加到群集的节点越多，存储的数据越多，成本就越高。 • ADX 还提供自动缩放功能，以适应按需工作负荷。 ADX 还可以受益于预留实例定价。 可以在 Azure 定价计算器中运行自己的成本计算。 |
低 采用最佳设置后，Azure Blob 存储成本最低。 为了提高效率和成本节省，Microsoft Azure 存储生命周期管理可用于将旧 Blob 自动放入更便宜的存储层。 |
低 在这种情况下，ADX 仅充当代理，因此群集可能很小。 此外，当不需要访问数据时，群集可以关闭，并且仅在需要数据访问时启动它。 |
| 如何访问数据： | 搜索作业 | 直接 KQL 查询 | externaldata | 修改后的 KQL 查询 |
| 应用场景： | 偶尔访问 在不需要运行大量分析或触发分析规则的情况下相关，并且只需偶尔访问数据。 |
频繁访问 在需要频繁访问数据且需要控制群集大小和配置方式的情况下相关。 |
合规性/审核 • 最适合存储大量非结构化数据。 • 在不需要快速访问数据或高性能（例如出于合规性或审核目的）的情况下相关。 |
偶尔访问 在想要从低成本 Azure Blob 存储中受益并保持对数据的相对快速访问的情况相关。 |
| 复杂性： | 极低 | 中等 | 低 | 高 |
| 就绪情况： | GA | GA | GA | GA |
一般注意事项
现在，你已了解有关可用目标平台的详细信息，请查看以下主要因素以最终确定决定。
- 组织将如何使用引入的日志？
- 迁移需要运行多快？
- 要引入的数据量是多少？
- 迁移期间和迁移后估计的迁移成本是多少？ 请参阅平台比较来比较成本。
使用引入的日志
定义组织如何使用引入的日志来指导你选择引入平台。
请考虑以下三种常规方案：
- 组织需要仅出于合规性或审核目的保留日志。 在这种情况下，组织很少访问数据。 即使组织访问数据，高性能或易用性也不是优先考虑的问题。
- 组织需要保留日志，以便团队能够轻松且快速地访问日志。
- 组织需要保留日志，以便团队能够偶尔访问日志。 性能和易用性是次要的。
请参阅平台比较，了解哪些平台适合其中每个方案。
迁移速度
在某些情况下，可能需要满足严格的截止时间，例如，由于许可证过期事件，组织可能需要紧急地从以前的 SIEM 转移。
查看确定迁移速度的组件和因素。
数据源
数据源通常是本地文件系统或云存储，例如 S3。 服务器的存储性能取决于多种因素，例如磁盘技术 (SSD 与 HDD)、IO 请求的性质以及每个请求的大小。
例如，Azure 虚拟机性能从较小的 VM SKU 上的 30 MB/s，到使用 NVW Express (NVMe) 磁盘的一些存储优化 SKU 的 20 GB/s。 了解如何设计 Azure VM 以提高存储性能。 还可以将大多数概念应用于本地服务器。
计算能力
在某些情况下，即使磁盘能够快速复制数据，计算能力也是复制过程中的瓶颈。 在这些情况下，可以选择以下缩放选项之一：
- 垂直缩放。 可以通过添加更多 CPU 或提高 CPU 速度来增加单个服务器的电源。
- 横向缩放。 添加更多服务器，这会增加复制进程的并行度。
目标平台
本部分讨论的每个目标平台都有不同的性能配置文件。
- Azure Monitor 基本日志。 默认情况下，基本日志可以按大约每分钟 1 GB 的速度推送到 Azure Monitor。 此速率允许每天引入大约 1.5 TB 或每月 43 TB。
- Azure 数据资源管理器。 引入性能因预配的群集大小和应用的批处理设置而异。 了解引入最佳做法，包括性能和监视。
- Azure Blob 存储。 Azure Blob 存储帐户的性能可能会因文件数量和大小、作业大小、并发数等而异。 了解如何优化 AzCopy 和 Microsoft Azure 存储的性能。
数据量
数据量是影响迁移过程持续时间的主要因素。 因此，应考虑如何根据数据集设置环境。
若要确定迁移的最小持续时间以及瓶颈的位置，请考虑目标平台的数据量和引入速度。 例如，选择可以每秒引入 1 GB 的目标平台，并且必须迁移 100 TB。 在这种情况下，迁移至少需要 100,000 GB，乘以每秒 1 GB 的速度。 将结果除以 3600，计算结果为 27 小时。 如果管道中的其余组件（例如本地磁盘、网络和虚拟机）每秒可以执行 1 GB，则此计算是正确的。
后续步骤
在本文中，你已了解如何将迁移规则从 QRadar 映射到 Microsoft Sentinel。