O365 活动管理 API - 大型审计日志流的性能答案

【问题标题】：O365 Activity Management API - Performance for huge audit log streamsO365 活动管理 API - 大型审计日志流的性能
【发布时间】：2018-10-23 12:02:54
【问题描述】：

这个问题是关于O365 Activity Management API

我们正在使用 API 从多个渠道（AzureAD、Outlook、SharePoint 等）为超大型租户检索审核日志通知，这意味着我们需要在相对较短的时间跨度内检索数百万条通知。

O365 将审核通知收集到一系列“blob”中，然后其中包含许多单独的通知（JSON 消息）。据我了解，这部分来自与 API 开发人员的通信。来自reading the docs 的团队和来自reading the docs 的这些blob 应该包含一个“相当多”数量的通知，以便在执行实际Web 请求时充当一种批处理方法。

在我们的方法中，我们每隔一小时请求 blob URL，然后对单个 blob 进行请求。

但是，我们已经对许多不同的租户和不同的 PublisherIdentifiers 进行了测试，但无论“等待”获取的通知总数如何，平均每个 blob 似乎只能收到大约 2.5 条消息。

这对于较大的租户来说是一个主要问题，因为需要的请求数量很多，这会给运行 fetcher 逻辑（Python 服务）的 SIEM 解决方案带来压力，而且它还给我们带来了 API 本身的限制问题.

实际上，我们根本无法以足够快的速度获取审核通知以跟上 - 在保留期内。如果 blob 每个 blob 包含更多通知，我们会很好 - 因为数据总量（以 MB 为单位）并没有那么大。

“有趣”的是，如果我们使用租户管理中心内的可视化查询工具，它会非常快速地搜索和检索通知。

我的问题

有没有人遇到过这个问题，或者可能有更好的“批处理性能”？
有没有人知道我们可以尝试什么来获得更好的性能？

如前所述，我们一直与雷德蒙德的开发团队和项目经理保持直接联系。他们对我们遇到的其他问题非常有帮助，但他们向我们推荐了对这个特定问题的支持——他们又将我们推荐给了论坛/社区。我们目前无法获得高级支持...

一个小时的内容 blob 请求示例 https://manage.office.com/api/v1.0/{tenantid}/activity/feed/subscriptions/content?contentType=Audit.Exchange&PublisherIdentifier={pub.id}&startTime=2017-12-03T10:31:24&endTime=2017-12-03T11:31:24

在检索单个 blob 时，我们只使用上述请求提供给我们的 URL。

【问题讨论】：

标签： office365api

【解决方案1】：

您可以通过在检索内容获取请求中将“?PublisherIdentifier={Tenant ID}”附加到 contentUri 来避免限制。

How can I add a PublisherId to a GetBlob call to the Office365 Rest API to avoid throttling?

【讨论】：

嗨阿赫特沙姆。感谢您的回答，但我们已经提供了 PublisherId

【解决方案2】：

在过去 6 个月里，我一直在使用 Office 365 管理活动 API。我以前也遇到过这种问题。如果您尝试以特定时间间隔从 Office 365 租户获取所有审核日志内容，则会出现此问题，这将导致限制问题。供您参考，无法避免大型活动租户的限制问题（资源过度使用）。

要克服这些问题，您可以在云中创建和部署一个 Web 应用程序并注册 Office 365 Management Activity API webhook。

只要 Office 365 租户将活动日志包装到 Azure Blob 中，它就会立即将 Blob 详细信息提供给您注册的 Web 应用程序。您可以参考this link 了解如何为 Web 应用程序启用 webhook。从 Office 365 租户收到 blob 详细信息后，从 Azure Blob 中提取日志并将其保存在您自己的 blob 存储中/存储在 SQL/NOSQL 数据库中。

【讨论】：

感谢您的回答。 Webhook 对我们来说不是一个选项，因为我们只是一个更大的 SIEM 解决方案中的一个“插件”，生活在一个（防火墙）隔离的环境中。然而，我们已经对较大的客户端进行了一些额外的测试，我们实际上看到了更好的“items/blob”性能。所以我们从这里开始的方法就是让我们的代码知道限制。
您提到的“问题”并不是我们试图获取“所有”内容，因为我们非常小心只请求同一时间段一次。问题出现了，如果租户产生的审计事件的数量超过了我们能够通过 (items/blob * allowed_requests/time_unit) 获取的数量。然而，如上所述，我们现在看到了更高的项目/blob 数量，所以这可能是一个理论上的讨论。我们正在对其进行测试。

【解决方案3】：

我遇到了类似的问题。提取日志所需的时间会比分配给 Python 脚本的时间间隔长，并且脚本会开始重叠，或者在尝试为 SIEM 实施提取日志时会落后。

https://github.com/IntegralDefense/o365_log_fetch

我写这篇文章有点晚了，但是通过在 Python 3.5+ 中使用 Asyncio 以及 aiohttp，您可以并发调用 O365 管理 API 并更快地拉下日志。我执行了一些测试并检索了 13 小时窗口的日志（Audit.Exchange、Audit.AzureActiveDirectory 和 Audit.Sharepoint）。使用“请求”并按顺序进行 API 调用大约需要 20 分钟。实施 Asyncio/aiohttp 后，相同的时间框架只用了不到 2 分钟（从位于数千个内容 blob/位置的数据中提取了 500,000 多个单独的事件）。

我每隔 10 分钟运行一次脚本，通常脚本会在

我上面粘贴的脚本也支持分页。因此，如果您在 Microsoft 的响应中得到一个被截断的内容列表，该脚本将继续访问并拉下更多内容位置。

目前，文档还没有跟上进度，但希望很快就会赶上。

【讨论】：