此体系结构描述了一种可针对系统和最终用户设备遥测数据提供实时监视和可观测性的解决方案。 它侧重于媒体行业的用例。
Grafana 是其相关公司的商标。 使用此标志并不意味着认可。
体系结构
下载此体系结构的 Visio 文件。
数据流
在图中显示的可观测系统中，原始遥测数据通过 HTTP 和连接器流式传输到 Azure Blob 存储。 原始遥测数据经过处理、转换、规范化，并保存在 Azure 数据资源管理器中以供分析。 Grafana 和 Azure 指标顾问等系统从数据资源管理器读取数据并为最终用户提供见解。
更具体地说，图中系统的功能组件如下：
- 检测。 通过系统中安装的用于监视数据的探测器或代理进行检测。 这些代理采用多种形式。 例如，在点播视频流式处理平台中，公司可能会使用开放标准 dash.js 从客户那里收集体验质量指标。
- 数据引入。 这些原始遥测数据可以通过 HTTP 调用直接从终端客户端传送。 或者，可以通过第三方系统将其上传到永久性存储和数据湖，例如 Blob 存储。 Blob 存储支持在上传新文件时调用 Azure 函数。 可以使用此触发机制将原始遥测数据移到结构化数据仓库。
- 转换和持久保存。 可能需要通过一个转换系统来规范化数据。 Azure Functions 应用按需转换数据，然后将其写入数据资源管理器。 数据资源管理器是大数据分析的理想选择，因为它可以满足大型数据集的高性能和高吞吐量需求。
- 监视。 Azure 托管 Grafana 支持与数据资源管理器集成。 可以使用 Grafana 的拖放功能快速生成仪表板和图表。 Grafana 非常适合用于媒体监视，因为它可以在不到一分钟内刷新仪表板磁贴，并且可用于发出警报。
- 异常情况检测。 Grafana 仪表板支持在 NOC 中进行手动监视。 但是，如果数据集很大，并且用户群分散在不同的地理位置并使用不同的设备，则通过图表和具有硬编码阈值的警报规则手动识别问题将变得效率低下。 可以使用 AI 来解决此问题。 指标顾问等服务使用机器学习算法根据时序数据自动理解和检测异常情况。 此外，Kusto 数据平台具有内置的异常情况检测功能，这些功能会考虑数据中的季节性和基线趋势。
组件
- 数据资源管理器是一个托管的数据分析服务，可对大量数据进行实时分析。 数据资源管理器是用于处理需要很高数据检索速度和吞吐量的大型数据集的极好工具。 此体系结构使用数据资源管理器来存储和查询用于分析的数据集。
- Blob 存储用于保存原始遥测数据。 这些遥测数据可能来自你的应用程序和服务，也可能来自第三方供应商。 如果你以后不需要执行更多分析，可将这些数据视为暂时性数据。 来自 Blob 存储的数据将引入数据资源管理器群集。
- Azure 事件网格是一个事件传送系统。 它用于侦听 Blob 存储发布的事件。 Azure 存储事件允许应用程序对事件（例如创建和删除 Blob）做出反应。 Azure 函数订阅事件网格发布的事件。
- Azure 事件中心是一个实时数据引入服务，使用它每秒可从任何源引入数百万个事件。 事件中心代表事件管道的前门，通常称为事件引入器。 事件引入器是位于事件发布者和事件使用者之间的组件或服务。 它将事件流的生成与事件的使用相分离。
- Azure Functions 是一个无服务器解决方案，用于分析和转换通过 HTTP 与 Blob 终结点引入的数据，并将数据写入数据资源管理器群集。
- Azure 托管 Grafana 可以轻松连接到数据资源管理器。 在此体系结构中，它生成用于可视化遥测数据的图表和仪表板。 Azure 托管 Grafana 提供与 Microsoft Entra ID 的深度集成，以便你可以实现对仪表板和视图的基于角色的访问。
- 指标顾问是 Azure 应用 AI 服务的一部分。 它使用 AI 在时序数据中执行数据监视和异常情况检测。 指标顾问可自动完成将模型应用于数据的过程，并提供一组 API 和一个基于 Web 的工作区用于数据引入、异常情况检测和诊断。 即使你不熟悉机器学习，也可以使用它。
备选方法
Azure 数据工厂和 Azure Synapse Analytics 提供用于生成 ETL 工作流的工具和工作区，以及从图形界面跟踪和重试作业的功能。 请注意，数据工厂和 Azure Synapse 从引入数据到持久保存数据都至少有大约 5 分钟的滞后时间。 你的监视系统可能会接受这段滞后时间。 如果是这样，我们建议考虑这些替代方案。
方案详细信息
组织通常会部署各种大规模技术来解决业务问题。 这些系统和最终用户设备生成大量遥测数据。
此体系结构基于媒体行业的某种用例。 用于实时视频和点播视频播放的媒体流需要准实时识别和响应应用程序问题。 为了支持这种实时方案，组织需要收集一个庞大的遥测数据集，这需要构建可缩放的体系结构。 收集数据后，还需要进行其他类型的分析，例如 AI 和异常情况检测，以便有效识别如此庞大的数据集中的问题。
部署大规模技术时，系统以及与其交互的最终用户设备会生成庞大的遥测数据集。 在传统方案中，会通过数据仓库系统分析这些数据，以生成可用于支持管理决策的见解。 此方法在某些方案中可能适用，但它对流式处理媒体用例的响应能力不够。 为了解决此问题，需要为从监视服务器、网络以及与其交互的最终用户设备生成的遥测数据提供实时见解。 捕获故障和错误的监视系统很常见，但准实时捕获故障和错误却很困难。 这就是此体系结构的重点所在。
在实时传送视频流或点播视频设置中，遥测数据是从系统和异构客户端（移动设备、桌面设备和电视）生成的。 该解决方案涉及到获取原始数据并将上下文与数据点（例如地理位置、最终用户操作系统、内容 ID 和 CDN 提供商等维度）相关联。 将收集、转换原始遥测数据，并将其保存在数据资源管理器中以供分析。 然后，可以使用 AI 来理解数据并自动完成观测和发出警报的手动过程。 可以使用 Grafana 和指标顾问等系统从数据资源管理器读取数据，以显示交互式仪表板并触发警报。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
可靠性
可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性支柱概述。
即使在发生 Azure 区域服务中断或 CDN 服务中断等干扰性事件期间，业务关键型应用程序也需要保持正常运行。 有两种主要策略和一种混合策略可用于在系统中内置冗余：
- 主动/主动。 重复的代码和函数正在运行。 在故障期间任一系统都可以接管工作。
- 主动/待机。 只有一个节点是主动/主要节点。 另一个节点已准备好在主要节点出现故障时接管工作。
- 混合。 有些组件/服务采用主动/主动配置，有些则采用主动/待机配置。
请记住，并非所有 Azure 服务都具有内置冗余。 例如，Azure Functions 仅在特定的区域运行函数应用。 Azure Functions 异地灾难恢复介绍了可以根据函数的触发方式（HTTP 与发布/订阅）实现的各种策略。
引入和转换函数应用可以在主动/主动模式下运行。 可以使用主动/主动和主动/待机配置运行数据资源管理器。
Azure 托管 Grafana 支持可用性区域冗余。 建立跨区域冗余的一种策略是在部署了数据资源管理器群集的每个区域中设置 Grafana。
成本优化
成本优化就是减少不必要的费用和提高运营效率。 有关详细信息，请参阅成本优化支柱概述。
此体系结构的成本取决于入口遥测事件的数量、原始遥测数据在 Blob 存储和数据资源管理器中占用的存储量、Azure 托管 Grafana 的每小时成本，以及指标顾问中时序图表数量的静态成本。
可以使用 Azure 定价计算器来估算每小时或每月成本。
性能效率
性能效率是指工作负荷能够以高效的方式扩展以满足用户对它的需求。 有关详细信息，请参阅性能效率要素概述。
根据传入请求的规模和频率，函数应用可能会成为瓶颈，主要原因有两个：
- 冷启动。 冷启动是无服务器执行的结果。 它是指在函数首次开始运行之前启动环境所需的计划和设置时间。 所需时间最多为几秒钟。
- 请求的频率。 假设你有 1,000 个 HTTP 请求，但只有一个单线程服务器处理这些请求。 那么，你将无法同时为所有 1,000 个 HTTP 请求提供服务。 要及时为这些请求提供服务，需要部署更多服务器。 也就是说，需要水平扩展。
我们建议使用高级或专用 SKU 来：
- 消除冷启动。
- 通过增加或减少服务虚拟机的数量来处理并发请求的要求。
有关详细信息，请参阅为 Azure 数据资源管理器群集选择 SKU。
部署此方案
有关部署此方案的信息，请参阅 GitHub 上的 real-time-monitoring-and-observability-for-media。 此代码示例包括所需的基础结构即代码 (IaC)，以启动开发和 Azure 函数来从 HTTP 和 Blob 终结点引入数据并转换数据。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- John Hauppa | 高级技术项目经理
- Uffaz Nathaniel | 首席软件工程师
其他参与者：
- Mick Alberts | 技术文档撰写人
- Dilmurod Makhamadaliev | 软件工程师
- Omeed Musavi | 首席软件工程师主管
- Ayo Mustapha | 首席技术项目经理
要查看非公开领英个人资料，请登录领英。