Compartilhar via

监视Azure Analysis Services

本文介绍：

  • 可以为此服务收集的监视数据的类型。
  • 如何分析这些数据。

注释

如果已熟悉此服务和/或Azure Monitor并只想了解如何分析监视数据，请参阅本文末尾附近的 Analyze 部分。

如果关键应用程序和业务流程依赖于Azure资源，则需要监视并获取系统的警报。 Azure Monitor服务从系统的每个组件收集并聚合指标和日志。 Azure Monitor提供可用性、性能和复原能力视图，并通知你问题。 可以使用 Azure 门户、PowerShell、Azure CLI、REST API 或客户端库来设置和查看监视数据。

Analysis Services 还提供多种非Azure Monitor监视机制：

资源类型

Azure使用资源类型和 ID 的概念来标识订阅中的所有内容。 Azure Monitor同样将核心监视数据组织成基于资源类型的指标和日志，也称为namespaces。 不同的指标和日志可用于不同的资源类型。 服务可能与多种资源类型关联。

资源类型也是Azure中运行的每个资源的资源 ID 的一部分。 例如，虚拟机的一种资源类型是 Microsoft.Compute/virtualMachines。 有关服务及其关联资源类型的列表，请参阅 资源提供程序。

有关 Analysis Services 的资源类型的详细信息，请参阅 Analysis Services 监视数据参考。

数据存储

对于Azure Monitor：

  • 指标数据存储在Azure Monitor指标数据库中。
  • 日志数据存储在Azure Monitor日志存储中。 Log Analytics 是 Azure 门户中用于查询此存储的工具。
  • Azure活动日志是一个单独的存储区，其自己的接口位于Azure门户中。
  • 可以选择性地将指标和活动日志数据路由到Azure Monitor日志数据库存储，以便可以使用Log Analytics查询数据并将其与其他日志数据相关联。

有关如何Azure Monitor存储数据的详细信息，请参阅 Azure Monitor 数据平台。

Azure Monitor平台指标

Azure Monitor为大多数服务提供平台指标。 这些指标是：

  • 针对每个命名空间单独定义。
  • 存储在Azure Monitor时序指标数据库中。
  • 轻量级且具备支持准实时警报的能力。
  • 用于跟踪资源随时间推移的性能变化。

Collection： Azure Monitor自动收集平台指标。 不需要任何配置。

Routing：通常还可以将平台指标路由到Azure Monitor日志/Log Analytics，以便可以使用其他日志数据查询它们。 有关详细信息，请参阅指标诊断设置。 有关如何配置服务的诊断设置，请参阅 在 Azure Monitor 中创建诊断设置。

有关可以为 Azure Monitor 中所有资源收集的全部指标，请参阅 Azure Monitor 支持的指标。

有关 Analysis Services 的可用度量列表，请参阅 Analysis Services 监视数据参考。

Azure Monitor资源日志

资源日志提供有关由Azure资源执行的作的见解。 日志是自动生成的，但必须将日志路由到Azure Monitor日志以保存或查询日志。 日志按类别组织。 给定的命名空间可能具有多个资源日志类别。

收集：在创建诊断设置并将日志路由到一个或多个位置之前，不会收集和存储资源日志。 创建诊断设置时，指定要收集的日志类别。 可通过多种方式创建和维护诊断设置，包括Azure门户、编程方式以及Azure Policy。

Routing：建议的默认值是将资源日志路由到Azure Monitor日志，以便可以使用其他日志数据对其进行查询。 还提供了其他资源位置，例如 Azure Storage、Azure Event Hubs 和某些 Azure 监视合作伙伴。 有关详细信息，请参阅 Azure 资源日志和 resource 日志目标。

有关收集、存储和路由资源日志的详细信息，请参阅 Azure Monitor 中的 Diagnostic 设置。

有关 Azure Monitor 中所有可用资源日志类别的列表，请参阅 Azure Monitor 支持的资源日志。

Azure Monitor中的所有资源日志具有相同的标头字段，随后是服务特定字段。 通用架构在 Azure Monitor 资源日志架构中概述。

Analysis Services 资源日志

若要了解如何设置诊断日志记录，请参阅 设置诊断日志记录。

在为 Analysis Services 设置日志记录时，可以选择记录引擎事件或服务事件，或者选择AllMetrics来记录指标数据。 有关详细信息，请参阅 Microsoft.AnalysisServices/servers 支持的资源日志。

Azure活动日志

活动日志包含订阅级别的事件，用于跟踪从资源外部查看的每个 Azure 资源的操作；例如，创建新资源或启动虚拟机。

Collection：活动日志事件会自动生成，并在独立的存储中收集，以便在 Azure 门户中查看。

Routing： 可以将活动日志数据发送到Azure Monitor日志，以便可以与其他日志数据一起分析。 还提供了其他资源位置，例如 Azure Storage、Azure Event Hubs 和某些 Azure 监视合作伙伴。 有关如何路由活动日志的详细信息，请参阅Azure活动日志的 Overview。

分析监视数据

有许多工具可用于分析监视数据。

Azure Monitor工具

Azure Monitor支持以下基本工具：

支持更复杂可视化效果的工具包括：

  • Dashboards，使你能够将不同类型的数据合并到Azure门户中的单个窗格中。
  • Workbooks，可以在Azure门户中创建的可自定义报表。 工作簿可以包括文本、指标和日志查询。
  • Power BI，这是一项业务分析服务，用于跨各种数据源提供交互式可视化效果。 可以将Power BI配置为从Azure Monitor自动导入日志数据，以利用这些可视化效果。

Azure Monitor导出工具

可以使用以下方法将数据从Azure Monitor中获取到其他工具：

若要开始使用适用于Azure Monitor的 REST API，请参阅Azure监视 REST API 演练。

分析 Analysis Services 指标

可以使用 Azure Monitor 指标资源管理器中的 Analysis Services 指标来帮助监视服务器的性能和运行状况。 例如，可以监视内存和 CPU 使用率、客户端连接数和查询资源消耗量。

若要确定是否需要横向扩展服务器，请监视服务器 QPU 和 查询池作业队列长度 指标。 一个值得监测的指标是按 ServerResourceType 的平均 QPU，它比较主服务器的平均 QPU与查询池的平均 QPU。 有关如何根据指标数据横向扩展服务器的详细说明，请参阅Azure Analysis Services横向扩展。

查询横向扩展指标

有关为 Analysis Services 收集的指标的完整列表，请参阅 Analysis Services 监控数据参考。

分析“Log Analytics”工作区中的日志

指标和服务器事件与Log Analytics工作区资源中的 xEvents 集成，以便并行分析。 还可以将Log Analytics工作区配置为接收来自其他Azure服务的事件，从而提供整个体系结构诊断日志记录数据的整体视图。

若要查看诊断数据，请在Log Analytics工作区中，从左侧菜单中打开 Logs。

Screenshot 显示 Azure portal 中的日志搜索选项。

在查询生成器中，展开 LogManagement>AzureDiagnostics。 AzureDiagnostics 包括引擎和服务事件。 注意，查询是即时创建的。 EventClass_s 字段包含 xEvent 名称，如果使用 Xevent 进行本地日志记录，你可能觉得该名称很眼熟。 选择EventClass_s或其中一个事件名称，Log Analytics工作区继续构造查询。 请务必保存查询以便稍后重复使用。

Kusto 查询

可以使用 Kusto 查询语言（KQL）分析 Azure Monitor 日志 / Log Analytics 存储中的监控数据。

重要

从门户中的服务菜单中选择Logs时，Log Analytics打开，并将查询范围设置为当前服务。 此范围意味着日志查询将仅包含来自该资源类型的数据。 如果要运行包含来自其他Azure服务的数据的查询，请从 Azure Monitor 菜单中选择 Logs。 有关详细信息，请参阅 在 Azure Monitor 日志分析中日志查询范围和时间范围。

有关任何服务的常见查询列表，请参阅 Log Analytics 查询接口。

以下查询对监视 Analysis Services 服务器很有用。

示例 1

以下查询返回模型数据库和服务器的每个查询结束/刷新结束事件的持续时间。 如果进行横向扩展，则结果将按副本细分，因为副本编号包含在 ServerName_s 中。 按 RootActivityId_g 分组可以减少从 Azure Diagnostics REST API 检索到的行数，并有助于保持在 Log Analytics 速率限制中所述的限制范围内。

let window = AzureDiagnostics
   | where ResourceProvider == "MICROSOFT.ANALYSISSERVICES" and Resource =~ "MyServerName" and DatabaseName_s =~ "MyDatabaseName" ;
window
| where OperationName has "QueryEnd" or (OperationName has "CommandEnd" and EventSubclass_s == 38)
| where extract(@"([^,]*)", 1,Duration_s, typeof(long)) > 0
| extend DurationMs=extract(@"([^,]*)", 1,Duration_s, typeof(long))
| project  StartTime_t,EndTime_t,ServerName_s,OperationName,RootActivityId_g,TextData_s,DatabaseName_s,ApplicationName_s,Duration_s,EffectiveUsername_s,User_s,EventSubclass_s,DurationMs
| order by StartTime_t asc

示例 2

以下查询返回服务器的内存和 QPU 消耗。 如果进行横向扩展，则结果将按副本细分，因为副本编号包含在 ServerName_s 中。

let window = AzureDiagnostics
   | where ResourceProvider == "MICROSOFT.ANALYSISSERVICES" and Resource =~ "MyServerName";
window
| where OperationName == "LogMetric" 
| where name_s == "memory_metric" or name_s == "qpu_metric"
| project ServerName_s, TimeGenerated, name_s, value_s
| summarize avg(todecimal(value_s)) by ServerName_s, name_s, bin(TimeGenerated, 1m)
| order by TimeGenerated asc

示例 3

以下查询返回服务器的 Analysis Services 引擎性能计数器每秒读取的行数。

let window =  AzureDiagnostics
   | where ResourceProvider == "MICROSOFT.ANALYSISSERVICES" and Resource =~ "MyServerName";
window
| where OperationName == "LogMetric" 
| where parse_json(tostring(parse_json(perfobject_s).counters))[0].name == "Rows read/sec" 
| extend Value = tostring(parse_json(tostring(parse_json(perfobject_s).counters))[0].value) 
| project ServerName_s, TimeGenerated, Value
| summarize avg(todecimal(Value)) by ServerName_s, bin(TimeGenerated, 1m)
| order by TimeGenerated asc

警报

Azure Monitor警报会在监视数据中找到特定条件时主动通知你。 有了警报，你就可以在客户注意到你的系统中的问题之前找出和解决问题。 有关详细信息，请参阅 Azure Monitor 警报。

Azure资源有许多常见警报来源。 有关Azure资源的常见警报示例，请参阅 Sample 日志警报查询。 Azure Monitor 基线警报（AMBA） 站点针对 Azure 着陆区（ALZ）方案，提供关键的警报指标、仪表板和指南。

常见的警报架构标准化Azure Monitor警报通知的使用。 有关详细信息，请参阅 常见警报架构。

警报类型

可以在Azure Monitor数据平台中针对任何指标或日志数据源发出警报。 警报具有许多不同类型，具体取决于要监视的服务以及要收集的监视数据。 不同类型的警报各有优缺点。 有关详细信息，请参阅 “选择正确的监视警报类型”。

以下列表描述了可以创建的Azure Monitor警报的类型：

  • 指标警报会定期评估资源指标。 指标可以是平台指标、自定义指标、Azure Monitor转换为指标或 Application Insights 指标的日志。 指标警报还可以应用多个条件和动态阈值。
  • Log 警报允许用户使用Log Analytics查询以预定义的频率评估资源日志。
  • 当发生与定义的条件匹配的新活动日志事件时，活动日志警报会触发。 资源运行状况警报和服务运行状况警报是用于报告服务和资源运行状况的活动日志警报。

还可以为某些Azure服务创建以下类型的警报：

  • Application Insights 资源上的智能检测警报会就 Web 应用程序中的潜在性能问题和故障异常自动向你发出警报。 可以在 Application Insights 资源上迁移智能检测，以便为不同的智能检测模块创建警报规则。
  • Prometheus 警报对存储在 Azure Monitor 托管的 Prometheus 服务中的 Prometheus 指标进行警报。 该警报规则基于 PromQL，它是一种开源查询语言。 你的服务可能不支持此类型警报。 目前，Prometheus 用于具有来宾操作系统的有限数量的服务，例如 Azure 虚拟机和 Azure 容器实例。
  • 推荐的警报规则开箱即用于某些 Azure 资源，包括虚拟机、Azure Kubernetes Service (AKS) 资源和 Log Analytics 工作区。

监视多个资源

可以通过将同一指标警报规则应用于同一Azure区域中存在的同一类型的多个资源来大规模监视。 将为每个受监视的资源发送单独通知。 有关支持的Azure服务和云，请参阅使用一条警报规则监控多个资源。

Analysis Services 警报规则

下表列出了 Analysis Services 的一些常见和常用的警报规则。

警报类型 条件 DESCRIPTION
指标 每当最大 qpu_metric 参数大于动态阈值时。 如果 QPU 经常超过上限，则表示针对模型的查询数量超出了计划的 QPU 限制。
指标 每当最大值 QueryPoolJobQueueLength 超过动态阈值时。 查询线程池队列中的查询数超过了可用的 QPU。

顾问建议

如果在资源操作期间出现严重情况或即将发生变化，则门户中的“概述”页面上会显示一个警报。

可以在监控下的顾问建议中找到警报的详细信息和建议的修复措施。 在正常操作期间，不会显示任何顾问建议。

有关Azure Advisor的详细信息，请参阅 Azure Advisor 概述。

相关内容

  • Last updated on