通过 Azure Monitor 日志管理使用情况和成本Manage usage and costs with Azure Monitor Logs

备注

本文介绍如何了解和控制 Azure Monitor 日志的成本。This article describes how to understand and control your costs for Azure Monitor Logs. 相关文章监视使用情况和估算成本介绍了如何针对不同的定价模型查看多个 Azure 监视功能的使用情况及估算成本。A related article, Monitoring usage and estimated costs describes how to view usage and estimated costs across multiple Azure monitoring features for different pricing models. 本文中显示的所有价格和成本仅用于举例。All prices and costs shown in this article are for example purposes only.

Azure Monitor 日志用于调整和支持来自任何源的巨量数据的每日收集、索引和存储,这些源部署在企业或 Azure 中。Azure Monitor Logs is designed to scale and support collecting, indexing, and storing massive amounts of data per day from any source in your enterprise or deployed in Azure. 尽管这可能是组织的主要驱动力,但成本效益最终是基本驱动力。While this may be a primary driver for your organization, cost-efficiency is ultimately the underlying driver. 为此,必须了解 Log Analytics 工作区的成本不仅仅是基于收集的数据量,而且也取决于所选的计划,以及连接源生成的数据的存储时间长短。To that end, it's important to understand that the cost of a Log Analytics workspace isn't based only on the volume of data collected, it is also dependent on the plan selected, and how long you chose to store data generated from your connected sources.

本文介绍如何主动监视引入的数据量和存储增长,以及定义限制来控制这些关联的成本。In this article we review how you can proactively monitor ingested data volume and storage growth, and define limits to control those associated costs.

定价模型Pricing model

Log Analytics 的默认定价采用即用即付模型,该模型基于数据引入量,有时还基于长期数据保留策略。The default pricing for Log Analytics is a Pay-As-You-Go model based on data volume ingested and optionally for longer data retention. 数据量是指将要存储的数据的大小。Data volume is measured as the size of the data that will be stored. 每个 Log Analytics 工作区作为独立服务计费,并在 Azure 订阅的帐单中产生相应费用。Each Log Analytics workspace is charged as a separate service and contributes to the bill for your Azure subscription. 数据引入量可能相当大,具体取决于以下因素:The amount of data ingestion can be considerable depending on the following factors:

  • 已启用的管理解决方案的数量及其配置Number of management solutions enabled and their configuration
  • 受监视的 VM 数量Number of VMs monitored
  • 从每个受监视 VM 收集的数据类型Type of data collected from each monitored VM

除了即用即付模型以外,Log Analytics 还提供了产能预留层,与即用即付价格相比,该模型最多可将成本节省 25%。In addition to the Pay-As-You-Go model, Log Analytics has Capacity Reservation tiers which enable you to save as much as 25% compared to the Pay-As-You-Go price. 容量预留定价模型允许每天购买 100 GB 的初始预留容量。The capacity reservation pricing enables you to buy a reservation starting at 100 GB/day. 超过预留级别的任何用量将按即用即付费率计费。Any usage above the reservation level will be billed at the Pay-As-You-Go rate. 产能预留层具有 31 天的套餐周期。The Capacity Reservation tiers have a 31-day commitment period. 在套餐周期内,你可以更改为更高级别的产能预留层(这将重启 31 天的套餐周期),但在套餐周期结束之前,你不能返回到即用即付或更低级别的产能预留层。During the commitment period, you can change to a higher level Capacity Reservation tier (which will restart the 31-day commitment period), but you cannot move back to Pay-As-You-Go or to a lower Capacity Reservation tier until after the commitment period is finished. 产能预留层将每天进行计费。Billing for the Capacity Reservation tiers is done on a daily basis. 详细了解 Log Analytics 即用即付和产能预留定价。Learn more about Log Analytics Pay-As-You-Go and Capacity Reservation pricing.

在所有定价层中,由准备存储数据时从数据的字符串表示形式来计算数据量。In all pricing tiers, the data volume is calculated from a string representation of the data as it is prepared to be stored. 一些对于所有数据类型都通用的属性未包含在事件大小计算中,包括 _ResourceId_ItemId_IsBillable_BilledSizeSeveral properties common to all data types are not included in the calculation of the event size, including _ResourceId, _ItemId, _IsBillable and _BilledSize.

另请注意,某些解决方案(例如 Azure 安全中心配置管理)具有其自己的定价模型。Also, note that some solutions, such as Azure Security Center and Configuration management have their own pricing models.

Log Analytics 专用群集Log Analytics Dedicated Clusters

Log Analytics 专用群集将工作区集合收集到单一托管的 Azure 数据资源管理器群集中,以支持高级方案。Log Analytics Dedicated Clusters are collections of workspaces into a single managed Azure Data Explorer cluster to support advanced scenarios. 与即用即付定价相比,Log Analytics 专用群集仅支持 1000 GB/天起、25% 折扣的产能预留定价模型。Log Analytics Dedicated Clusters support only a Capacity Reservation pricing model starting at 1000 GB/day with a 25% discount compared to Pay-As-You-Go pricing. 超过预留级别的任何用量将按即用即付费率计费。Any usage above the reservation level will be billed at the Pay-As-You-Go rate. 增加预留级别后,群集产能预留具有 31 天的套餐周期。The cluster Capacity Reservation has a 31-day commitment period after the reservation level is increased. 套餐周期期间,不能减少产能预留级别,但可以随时增加。During the commitment period the capacity reservation level cannot be reduced, but it can be increased at any time.

群集产能预留级别将使用 Sku 下的 Capacity 参数以编程方式通过 Azure 资源管理器进行配置。The cluster capacity reservation level is configured via programatically with Azure Resource Manager using the Capacity parameter under Sku. Capacity 指定 GB 为单位,并且值可以为 1000 GB/天或更大,增量为 100 GB/天。The Capacity is specified in units of GB and can have values of 1000 GB/day or more in increments of 100 GB/day. 如果群集需要的预留超过 2000 GB/天,请通过 LAIngestionRate@microsoft.com 联系我们。If your cluster needs a reservation above 2000 GB/day contact us at LAIngestionRate@microsoft.com.

由于引入数据的计费在群集级别上完成,因此与群集关联的工作区不再具有定价层。Because the billing for ingested data is done at the cluster level, workspaces associated to a cluster no longer have a pricing tier. 每个与群集关联的工作区中的引入数据数量将进行聚合,以计算该群集的每日帐单。The ingested data quantities from each workspace associated to a cluster is aggregated to calculate the daily bill for the cluster. 请注意,在跨群集中的所有工作区对此聚合数据进行聚合之前,将在工作区级别应用来自 Azure 安全中心 的按节点分配。Note that per-node allocations from Azure Security Center are applied at the workspace level prior to this aggregation of aggregated data across all workspaces in the cluster. 数据保留期仍按工作区级别计费。Data retention is still billed at the workspace level. 请注意,在创建群集时开始群集计费,无论工作区是否已关联到群集。Note that cluster billing starts when the cluster is created, regardless of whether workspaces have been associated to the cluster.

估算环境的管理成本Estimating the costs to manage your environment

如果尚未使用 Azure Monitor 日志,则可以使用 Azure Monitor 定价计算器来估算使用 Log Analytics 的成本。If you're not yet using Azure Monitor Logs, you can use the Azure Monitor pricing calculator to estimate the cost of using Log Analytics. 首先在搜索框中输入“Azure Monitor”,然后单击生成的“Azure Monitor”磁贴。Start by entering "Azure Monitor" in the Search box, and clicking on the resulting Azure Monitor tile. 向下滚动页面到 Azure Monitor,然后从“类型”下拉列表中选择 Log Analytics。Scroll down the page to Azure Monitor, and select Log Analytics from the Type dropdown. 可在此输入 VM 数目,以及要从每个 VM 收集的数据量 (GB)。Here you can enter the number of VMs and the GB of data you expect to collect from each VM. 通常每月会从一个典型的 Azure VM 中引入 1 到 3 GB 的数据。Typically 1 to 3 GB of data month is ingested from a typical Azure VM. 如果已经评估了 Azure Monitor 日志,则可以使用自己环境中的数据统计信息。If you're already evaluating Azure Monitor Logs already, you can use your data statistics from your own environment. 请参阅下文来了解如何确定受监视 VM 数工作区引入的数据量See below for how to determine the number of monitored VMs and the volume of data your workspace is ingesting.

查看自己的使用情况和估算成本Understand your usage and estimate costs

如果现在正在使用 Azure Monitor 日志,就很容易了解根据最近的使用模式可能会产生什么样的成本。If you're using Azure Monitor Logs now, it's easy to understand what the costs are likely be based on recent usage patterns. 若要执行此操作,请使用“Log Analytics 使用情况和预估成本”查看和分析数据使用情况。To do this, use Log Analytics Usage and Estimated Costs to review and analyze data usage. 此项显示每个解决方案收集的数据量、保留的数据量,并根据引入的数据量和已包含量之外的其他保留量来估算成本。This shows how much data is collected by each solution, how much data is being retained and an estimate of your costs based on the amount of data ingested and any additional retention beyond the included amount.

使用情况和预估成本

若要更详细地探索数据,请单击“使用情况和预估成本”页上任一图表右上侧的图标。To explore your data in more detail, click on the icon at the top right of either of the charts on the Usage and Estimated Costs page. 现在可以使用此查询来探索有关使用情况的更多详细信息。Now you can work with this query to explore more details of your usage.

日志视图

从“使用情况和估计成本”页面,可以查看当月的数据量。From the Usage and Estimated Costs page you can review your data volume for the month. 这包括 Log Analytics 工作区中收到和保留的所有数据。This includes all the data received and retained in your Log Analytics workspace. 单击页面顶部的“使用情况详细信息”查看使用情况仪表板,其中按源、计算机和产品/服务显示了有关数据量趋势的信息。Click Usage details from the top of the page, to view the usage dashboard with information on data volume trends by source, computers, and offering. 若要查看和设置每日上限或修改保留期,请单击“数据量管理”。To view and set a daily cap or to modify the retention period, click Data volume management.

Log Analytics 费用将添加到 Azure 帐单。Log Analytics charges are added to your Azure bill. 可以在 Azure 门户的“计费”部分或在 Azure 计费门户中查看 Azure 账单详细信息。You can see details of your Azure bill under the Billing section of the Azure portal or in the Azure Billing Portal.

在 Azure 帐单上查看 Log Analytics 使用情况Viewing Log Analytics usage on your Azure bill

在 Azure 成本管理和计费中心,Azure 提供了大量有用的功能。Azure provides a great deal of useful functionality in the Azure Cost Management + Billing hub. 例如,使用“成本分析”功能可以查看 Azure 资源的开支。For instance, the "Cost analysis" functionality enables you to view your spends for Azure resources. 首先,添加按"资源类型"筛选的筛选器(到 microsoft.operationalinsights/workspace for Log Analytics 和microsoft.operationalinsights/workspace for Log Analytics Clusters),以便跟踪 Log Analytics 支出。First, add a filter by "Resource type" (to microsoft.operationalinsights/workspace for Log Analytics and microsoft.operationalinsights/workspace for Log Analytics Clusters) will allow you to track your Log Analytics spend. 然后,为“分组依据”选择“计量类别”或“计量”。Then for "Group by" select "Meter category" or "Meter". 请注意,其他服务(例如 Azure 安全中心和 Azure Sentinel)也会根据 Log Analytics 工作区资源来计费其使用情况。Note that other services such as Azure Security Center and Azure Sentinel also bill their usage against Log Analytics workspace resources. 若要查看到服务名称的映射,可以选择表视图而不是图表。To see the mapping to Service name, you can select the Table view instead of a chart.

更改定价层Changing pricing tier

若要更改工作区的 Log Analytics 定价层,请执行以下操作:To change the Log Analytics pricing tier of your workspace,

  1. 在 Azure 门户中,从你的工作区中打开“使用情况和预估成本”,你会在其中看到此工作区可用的每个定价层的列表。In the Azure portal, open Usage and estimated costs from your workspace where you'll see a list of each of the pricing tiers available to this workspace.

  2. 查看每个定价层的预估成本。Review the estimated costs for each of the pricing tiers. 此预估基于过去 31 天的使用情况,因此,此成本估计依赖于过去的 31 天,能代表你的典型使用情况。This estimate is based on the last 31 days of usage, so this cost estimate relies on the last 31 days being representative of your typical usage. 在下面的示例中,你可以看到,基于过去 31 天的数据模式,与 100 GB/天产能预留层 (#2) 相比,此工作区采用即用即付层 (#1) 时的成本更低。In the example below you can see how, based on the data patterns from the last 31 days, this workspace would cost less in the Pay-As-You-Go tier (#1) compared to the 100 GB/day Capacity Reservation tier (#2).

    定价层

  3. 查看基于过去 31 天使用情况的估计成本后,如果决定更改定价层,请单击“选择”。After reviewing the estimated costs based on the last 31 days of usage, if you decide to change the pricing tier, click Select.

还可以使用 sku 参数(在 Azure 资源管理器模板中为 pricingTier通过 Azure 资源管理器设置定价层You can also set the pricing tier via Azure Resource Manager using the sku parameter (pricingTier in the Azure Resource Manager template).

旧版定价层Legacy pricing tiers

如果订阅在 2018 年 4 月 2 日前已有 Log Analytics 工作区或 Application Insights 资源,或者链接到了 2019 年 2 月 1 日前启动的企业协议,则这些订阅将继续可以使用以下旧定价层:“免费”、“独立(按 GB)”和“按节点(OMS)”。Subscriptions who had a Log Analytics workspace or Application Insights resource in it before April 2, 2018, or are linked to an Enterprise Agreement that started prior to February 1, 2019, will continue to have access to use the legacy pricing tiers: Free, Standalone (Per GB) and Per Node (OMS). 对于“免费”定价层中的工作区,其每日数据引入量限制为 500 MB(由 Azure 安全中心收集的安全数据类型除外),并且其数据保留期限制为 7 天。Workspaces in the Free pricing tier will have daily data ingestion limited to 500 MB (except for security data types collected by Azure Security Center) and the data retention is limited to 7 days. “免费”定价层仅用于评估目的。The Free pricing tier is intended only for evaluation purposes. 对于“独立”或“按节点”定价层中的工作区,用户可配置的保留期为 30-730 天。Workspaces in the Standalone or Per Node pricing tiers have user-configurable retention from 30 to 730 days.

按节点定价层对每个受监视的 VM(节点)进行计费,时间粒度为一小时。The Per Node pricing tier charges per monitored VM (node) on an hour granularity. 对于每个受监视的节点,每日向工作区分配 500 MB 未计费的数据。For each monitored node, the workspace is allocated 500 MB of data per day that is not billed. 此分配在工作区级别上进行聚合。This allocation is aggregated at the workspace level. 引入的数据如果超过每日聚合数据分配,将按 GB 计算数据超额费用。Data ingested above the aggregate daily data allocation is billed per GB as data overage. 请注意,如果工作区位于按节点定价层,则该服务在账单上为“Insight and Analytics”,用于 Log Analytics 使用情况。Note that on your bill, the service will be Insight and Analytics for Log Analytics usage if the workspace is in the Per Node pricing tier.

提示

如果工作区可访问“按节点”定价层,但你想知道在即用即付层中是否成本更低,则可以使用以下查询来轻松获取建议。If your workspace has access to the Per Node pricing tier, but you're wondering whether it would be cost less in a Pay-As-You-Go tier, you can use the query below to easily get a recommendation.

在 2016 年 4 月之前创建的工作区还可以访问标准高级定价层,这些层的数据保留期是固定的,分别为 30 天和 365 天。Workspaces created prior to April 2016 can also access the original Standard and Premium pricing tiers which have fixed data retention of 30 and 365 days respectively. 无法在标准高级定价层中创建新的工作区,并且如果将工作区移出这些层,则无法将其移回。New workspaces cannot be created in the Standard or Premium pricing tiers, and if a workspace is moved out of these tiers, it cannot be moved back.

此处提供了定价层限制的更多详细信息。More details of pricing tier limitations are available here.

备注

若要使用通过购买用于 System Center 的 OMS E1 套件、OMS E2 套件或 OMS 附加产品所获得的权利,请选择 Log Analytics 的“按节点”定价层。To use the entitlements that come from purchasing OMS E1 Suite, OMS E2 Suite or OMS Add-On for System Center, choose the Log Analytics Per Node pricing tier.

更改数据保留期Change the data retention period

以下步骤说明如何配置日志数据在工作区中的保留期限。The following steps describe how to configure how long log data is kept by in your workspace. 对于所有工作区,数据保留期可配置为 30 到 730 天(2 年),除非他们使用的是旧版免费定价层。详细了解有关更长数据保留期定价的信息。Data retention can be configured from 30 to 730 days (2 years) for all workspaces unless they are using the legacy Free pricing tier.Learn more about pricing for longer data retention.

默认保留期Default retention

若要设置工作区的默认保留期,请执行以下操作:To set the default retention for your workspace,

  1. 在 Azure 门户中,从你的工作区的左窗格中,选择“使用情况和预估成本”。In the Azure portal, from your workspace, select Usage and estimated costs from the left pane.

  2. 在“使用情况和预估成本”页面顶部,单击“数据量管理”。 On the Usage and estimated costs page, click Data volume management from the top of the page.

  3. 在窗格中,移动滑块以增加或减少天数,然后单击“确定”。On the pane, move the slider to increase or decrease the number of days and then click OK. 如果位于“免费”层,则不能修改数据保留期,需要升级到付费层才能控制这一项设置。If you are on the free tier, you will not be able to modify the data retention period and you need to upgrade to the paid tier in order to control this setting.

    更改工作区数据保留设置

如果保留期缩短,则会在最旧的数据删除之前有几天宽限期。When the retention is lowered, there is a several day grace period before the oldest data is removed.

保留期也可使用 retentionInDays 参数通过 Azure 资源管理器进行设置The retention can also be set via Azure Resource Manager using the retentionInDays parameter. 此外,如果将数据保留期设置为 30 天,则可以使用 immediatePurgeDataOn30Days 参数对旧数据触发立即清除,这对于合规性相关的方案可能很有用。Additionally, if you set the data retention to 30 days, you can trigger an immediate purge of older data using the immediatePurgeDataOn30Days parameter, which may be useful for compliance-related scenarios. 此功能仅通过 Azure 资源管理器公开。This functionality is only exposed via Azure Resource Manager.

两种数据类型(UsageAzureActivity)默认保留 90 天,在这 90 天的保留期内不收费。Two data types -- Usage and AzureActivity -- are retained for 90 days by default, and there is no charge for for this 90 day retention. 这些数据类型也没有数据引入费用。These data types are also free from data ingestion charges.

默认情况下,基于工作区的 Application Insights 资源(AppAvailabilityResultsAppBrowserTimingsAppDependenciesAppExceptionsAppEventsAppMetricsAppPageViewsAppPerformanceCountersAppRequestsAppSystemEventsAppTraces)中的数据类型也将保留 90 天,并且此 90 天的保留期将不收取任何费用。Data types from workspace-based Application Insights resources (AppAvailabilityResults, AppBrowserTimings, AppDependencies, AppExceptions, AppEvents, AppMetrics, AppPageViews, AppPerformanceCounters, AppRequests, AppSystemEvents and AppTraces) are also retained for 90 days by default, and there is no charge for for this 90 day retention. 可以使用按数据类型分类的保留期功能调整上述保留期。Their retention can be adjust using the retention by data type functionality.

按数据类型分类的保留期Retention by data type

还可以为单个数据类型指定不同的保留期设置,从 30 天到 730 天(旧版免费定价层中的工作区除外)。It is also possible to specify different retention settings for individual data types from 30 to 730 days (except for workspaces in the legacy Free pricing tier). 每个数据类型都是工作区的子资源。Each data type is a sub-resource of the workspace. 例如,SecurityEvent 表可以在 Azure 资源管理器中寻址,如下所示:For instance the SecurityEvent table can be addressed in Azure Resource Manager as:

/subscriptions/00000000-0000-0000-0000-00000000000/resourceGroups/MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/MyWorkspaceName/Tables/SecurityEvent

请注意,数据类型(表)区分大小写。Note that the data type (table) is case sensitive. 若要获取特定数据类型(在此示例中为 SecurityEvent)的当前每数据类型保留期设置,请使用:To get the current per data type retention settings of a particular data type (in this example SecurityEvent), use:

    GET /subscriptions/00000000-0000-0000-0000-00000000000/resourceGroups/MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/MyWorkspaceName/Tables/SecurityEvent?api-version=2017-04-26-preview

若要获取工作区中所有数据类型的当前每数据类型保留期设置,请直接省略特定的数据类型,例如:To get the current per data type retention settings for all data types in your workspace, just omit the specific data type, for example:

    GET /subscriptions/00000000-0000-0000-0000-00000000000/resourceGroups/MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/MyWorkspaceName/Tables?api-version=2017-04-26-preview

若要将特定数据类型(在此示例中为 SecurityEvent)的保留期设置为 730 天,请执行以下代码To set the retention of a particular data type (in this example SecurityEvent) to 730 days, do

    PUT /subscriptions/00000000-0000-0000-0000-00000000000/resourceGroups/MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/MyWorkspaceName/Tables/SecurityEvent?api-version=2017-04-26-preview
    {
        "properties": 
        {
            "retentionInDays": 730
        }
    }

retentionInDays 的有效值为 30 到 730。Valid values for retentionInDays are from 30 through 730.

UsageAzureActivity 数据类型不能使用自定义保留期进行设置。The Usage and AzureActivity data types cannot be set with custom retention. 它们会使用最大的默认工作区保留期(或 90 天)。They will take on the maximum of the default workspace retention or 90 days.

OSS 工具 ARMclient 是一个很好的工具,可以直接连接到 Azure 资源管理器,以便按数据类型设置保留期。A great tool to connect directly to Azure Resource Manager to set retention by data type is the OSS tool ARMclient. 请在 David EbboDaniel Bowbyes 的文章中了解有关 ARMclient 的详细信息。Learn more about ARMclient from articles by David Ebbo and Daniel Bowbyes. 下面是一个示例,演示了如何使用 ARMClient 将 SecurityEvent 数据的保留期设置为 730 天:Here's an example using ARMClient, setting SecurityEvent data to a 730 day retention:

armclient PUT /subscriptions/00000000-0000-0000-0000-00000000000/resourceGroups/MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/MyWorkspaceName/Tables/SecurityEvent?api-version=2017-04-26-preview "{properties: {retentionInDays: 730}}"

提示

可以根据单个数据类型设置保留期,这样可以降低数据保留成本。Setting retention on individual data types can be used to reduce your costs for data retention. 如果数据是从 2019 年 10 月(此时发布了该功能)开始收集的,则缩短某些数据类型的保留期可以降低一段时间的保留成本。For data collected starting in October 2019 (when this feature was released), reducing the retention for some data types can reduce your retention cost over time. 如果数据是更早之前收集的,则为单个类型设置较短的保留期不会影响保留成本。For data collected earlier, setting a lower retention for an individual type will not affect your retention costs.

管理每日最大数据量Manage your maximum daily data volume

可以配置工作区的每日上限并限制每日引入量,但请谨慎设置,因为目标是避免达到每日限制。You can configure a daily cap and limit the daily ingestion for your workspace, but use care as your goal should not be to hit the daily limit. 否则,会丢失该天剩余时间的数据,这可能会影响其功能依赖于工作区中提供的最新数据的其他 Azure 服务和解决方案。Otherwise, you lose data for the remainder of the day, which can impact other Azure services and solutions whose functionality may depend on up-to-date data being available in the workspace. 因此,需要具有在支持 IT 服务的资源的运行状况受到影响时监视和接收警报的能力。As a result, your ability to observe and receive alerts when the health conditions of resources supporting IT services are impacted. 每日上限旨在用作一种调控受管理资源数据量意外增长并使其保留在限制范围内,或者限制工作区产生计划外费用的方式。The daily cap is intended to be used as a way to manage the unexpected increase in data volume from your managed resources and stay within your limit, or when you want to limit unplanned charges for your workspace.

达到每日限制后不久,应计费数据类型的收集会在当天的剩余时间停止。Soon after the daily limit is reached, the collection of billable data types stops for the rest of the day. (应用每日上限时的固有延迟可能意味着应用上限不会精确到指定的每日上限级别。)选定 Log Analytics 工作区的页面顶部会显示警告横幅,同时会将一个操作事件发送到“LogManagement”类别下的“操作”表。(Latency inherent in applying the daily cap can mean that the cap is not applied as precisely the specified daily cap level.) A warning banner appears across the top of the page for the selected Log Analytics workspace and an operation event is sent to the Operation table under LogManagement category. 在“每日限制设置时间”定义的重置时间过后,数据收集将会恢复。Data collection resumes after the reset time defined under Daily limit will be set at. 我们建议基于此操作事件定义一个警报规则,并将其配置为在达到每日数据限制时发出通知。We recommend defining an alert rule based on this operation event, configured to notify when the daily data limit has been reached.

警告

每日上限不会停止从 Azure 安全中心收集数据,2017 年 6 月 19 日之前安装 Azure 安全中心的工作区除外。The daily cap does not stop the collection of data from Azure Security Center, except for workspaces in which Azure Security Center was installed before June 19, 2017.

确定要定义的每日数据限制Identify what daily data limit to define

查看 Log Analytics 使用情况和预估成本,了解数据引入趋势,以及要定义的每日数据量上限。Review Log Analytics Usage and estimated costs to understand the data ingestion trend and what is the daily volume cap to define. 应该慎重考虑上限,因为在达到限制后,将无法监视资源。It should be considered with care, since you won’t be able to monitor your resources after the limit is reached.

设置每日上限Set the Daily Cap

以下步骤说明如何配置一个限制来管理 Log Analytics 工作区每日引入的数据量。The following steps describe how to configure a limit to manage the volume of data that Log Analytics workspace will ingest per day.

  1. 在工作区的左窗格中,选择“使用情况和预估成本”。From your workspace, select Usage and estimated costs from the left pane.

  2. 在所选工作区的“使用情况和预估成本”页面顶部,单击“数据量管理”。 On the Usage and estimated costs page for the selected workspace, click Data volume management from the top of the page.

  3. 每日上限默认为“关闭”– 单击“打开”将其启用,然后设置数据量限制(以 GB/天为单位)。 Daily cap is OFF by default – click ON to enable it, and then set the data volume limit in GB/day.

    Log Analytics 配置数据限制

达到每日上限时发出警报Alert when Daily Cap reached

尽管在达到数据限制阈值时,Azure 门户中会显示视觉提示,但此行为不一定符合需要立即关注的操作问题的处理方式。While we present a visual cue in the Azure portal when your data limit threshold is met, this behavior doesn't necessarily align to how you manage operational issues requiring immediate attention. 若要接收警报通知,可以在 Azure Monitor 中创建一个新的警报规则。To receive an alert notification, you can create a new alert rule in Azure Monitor. 有关详细信息,请参阅如何创建、查看和管理警报To learn more, see how to create, view, and manage alerts.

若要开始操作,请参考下面提供的建议警报设置:To get you started, here are the recommended settings for the alert:

  • 目标:选择 Log Analytics 资源Target: Select your Log Analytics resource
  • 条件:Criteria:
    • 信号名称:自定义日志搜索Signal name: Custom log search
    • 搜索查询:Operation | where Detail has 'OverQuota'Search query: Operation | where Detail has 'OverQuota'
    • 依据:结果数Based on: Number of results
    • 条件:大于Condition: Greater than
    • 阈值:0Threshold: 0
    • 时间段:5(分钟)Period: 5 (minutes)
    • 频率:5(分钟)Frequency: 5 (minutes)
  • 警报规则名称:达到每日数据限制Alert rule name: Daily data limit reached
  • 严重性:警告(严重性 1)Severity: Warning (Sev 1)

定义警报并达到限制后,警报将会触发,并执行操作组中定义的响应。Once alert is defined and the limit is reached, an alert is triggered and performs the response defined in the Action Group. 该警报可通过电子邮件和短信通知团队,或者使用 Webhook、自动化 Runbook 或与外部 ITSM 解决方案集成来自动执行操作。It can notify your team via email and text messages, or automate actions using webhooks, Automation runbooks or integrating with an external ITSM solution.

排查使用量超出预期的原因Troubleshooting why usage is higher than expected

使用量较高是由下面的一个或两个原因引起的:Higher usage is caused by one, or both of:

  • 将数据发送到 Log Analytics 工作区的节点数超出预期More nodes than expected sending data to Log Analytics workspace
  • 发送到 Log Analytics 工作区的数据量超出预期(可能是由于开始使用新解决方案或对现有解决方案进行配置更改)More data than expected being sent to Log Analytics workspace (perhaps due to starting to use a new solution or a configuration change to an existing solution)

了解发送数据的节点Understanding nodes sending data

若要了解上个月每天通过代理报告检测信号的节点数,请使用To understand the number of nodes reporting heartbeats from the agent each day in the last month, use

Heartbeat 
| where TimeGenerated > startofday(ago(31d))
| summarize nodes = dcount(Computer) by bin(TimeGenerated, 1d)    
| render timechart

要获取最近 24 小时内发送数据的节点计数,请使用查询:The get a count of nodes sending data in the last 24 hours use the query:

union withsource = tt * 
| where TimeGenerated > ago(24h)
| extend computerName = tolower(tostring(split(Computer, '.')[0]))
| where computerName != ""
| summarize nodes = dcount(computerName)

若要获取发送任何数据的节点列表(以及每个节点发送的数据量),可以使用以下查询:To get a list of nodes sending any data (and the amount of data sent by each) the follow query can be used:

union withsource = tt * 
| where TimeGenerated > ago(24h)
| extend computerName = tolower(tostring(split(Computer, '.')[0]))
| where computerName != ""
| summarize TotalVolumeBytes=sum(_BilledSize) by computerName

提示

请谨慎使用这些 union * 查询,因为跨数据类型执行扫描很耗费资源Use these union * queries sparingly as scans across data types are resource intensive to execute. 如果不需要每台计算机都获得结果,则请按使用情况数据类型查询(见下文)。If you do not need results per computer then query on the Usage data type (see below).

了解引入的数据量Understanding ingested data volume

在“使用情况和预估成本”页上,“单个解决方案的数据引入”图表显示发送的总数据量以及每个解决方案发送的量。On the Usage and Estimated Costs page, the Data ingestion per solution chart shows the total volume of data sent and how much is being sent by each solution. 这样就可以确定趋势,例如总数据使用量(或特定解决方案的使用量)是正在增长、保持平稳还是正在下降。This allows you to determine trends such as whether the overall data usage (or usage by a particular solution) is growing, remaining steady or decreasing.

特定事件的数据量Data volume for specific events

若要查看一组特定事件的引入数据大小,可以查询特定的表(在此示例中为 Event),然后将查询限制为相关事件(在此示例中事件 ID 为 5145 或 5156):To look at the size of ingested data for a particular set of events, you can query the specific table (in this example Event) and then restrict the query to the events of interest (in this example event ID 5145 or 5156):

Event
| where TimeGenerated > startofday(ago(31d)) and TimeGenerated < startofday(now()) 
| where EventID == 5145 or EventID == 5156
| where _IsBillable == true
| summarize count(), Bytes=sum(_BilledSize) by EventID, bin(TimeGenerated, 1d)

请注意,子句 where IsBillable = true 从某些解决方案中筛选掉没有引入费用的数据类型。Note that the clause where IsBillable = true filters out data types from certain solutions for which there is no ingestion charge.

按解决方案统计的数据量Data volume by solution

若要查看上个月(最后一部分日期除外)的按解决方案统计的应计费数据量,使用的查询如下:The query used to view the billable data volume by solution over the last month (excluding the last partial day) is:

Usage 
| where TimeGenerated > ago(32d)
| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())
| where IsBillable == true
| summarize BillableDataGB = sum(Quantity) / 1000. by bin(StartTime, 1d), Solution | render barchart

带有 TimeGenerated 的子句仅用于确保 Azure 门户中的查询体验在超出默认的 24 小时后会回看。The clause with TimeGenerated is only to ensure that the query experience in the Azure portal will look back beyond the default 24 hours. 使用使用情况数据类型时,StartTimeEndTime 表示用于显示结果的时间存储桶。When using the Usage data type, StartTime and EndTime represent the time buckets for which results are presented.

按类型统计的数据量Data volume by type

你可以进一步钻取,以查看数据类型统计的数据趋势:You can drill in further to see data trends for by data type:

Usage 
| where TimeGenerated > ago(32d)
| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())
| where IsBillable == true
| summarize BillableDataGB = sum(Quantity) / 1000. by bin(StartTime, 1d), DataType | render barchart

或按解决方案和类型查看上个月的表,Or to see a table by solution and type for the last month,

Usage 
| where TimeGenerated > ago(32d)
| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())
| where IsBillable == true
| summarize BillableDataGB = sum(Quantity) by Solution, DataType
| sort by Solution asc, DataType asc

按计算机的数据量Data volume by computer

Usage 数据类型不包括计算机级别的信息。The Usage data type does not include information at the computer level. 若要按计算机查看引入的数据的大小,请使用 _BilledSize 属性(以字节为单位提供大小):To see the size of ingested data per computer, use the _BilledSize property, which provides the size in bytes:

union withsource = tt * 
| where TimeGenerated > ago(24h)
| where _IsBillable == true 
| extend computerName = tolower(tostring(split(Computer, '.')[0]))
| summarize BillableDataBytes = sum(_BilledSize) by  computerName | sort by Bytes nulls last

_IsBillable 属性指定引入的数据是否会导致收费。The _IsBillable property specifies whether the ingested data will incur charges.

若要按计算机查看引入的可计费事件的计数,请使用To see the count of billable events ingested per computer, use

union withsource = tt * 
| where TimeGenerated > ago(24h)
| where _IsBillable == true 
| extend computerName = tolower(tostring(split(Computer, '.')[0]))
| summarize eventCount = count() by computerName  | sort by eventCount nulls last

提示

请谨慎使用这些 union * 查询,因为跨数据类型执行扫描很耗费资源Use these union * queries sparingly as scans across data types are resource intensive to execute. 如果不需要每台计算机都获得结果,则请按使用情况数据类型查询。If you do not need results per computer then query on the Usage data type.

按 Azure 资源、资源组或订阅计算的数据量Data volume by Azure resource, resource group, or subscription

对于 Azure 中托管的节点的数据,可以使用 _ResourceId 属性(提供资源的完整路径)按计算机获取引入的数据的大小For data from nodes hosted in Azure you can get the size of ingested data per computer, use the _ResourceId property, which provides the full path to the resource:

union withsource = tt * 
| where TimeGenerated > ago(24h)
| where _IsBillable == true 
| summarize BillableDataBytes = sum(_BilledSize) by _ResourceId | sort by Bytes nulls last

对于 Azure 中托管的节点的数据,可以__按 Azure 订阅__获取引入的数据的大小,并将 _ResourceId 属性分析为:For data from nodes hosted in Azure you can get the size of ingested data per Azure subscription, parse the _ResourceId property as:

union withsource = tt * 
| where TimeGenerated > ago(24h)
| where _IsBillable == true 
| parse tolower(_ResourceId) with "/subscriptions/" subscriptionId "/resourcegroups/" 
    resourceGroup "/providers/" provider "/" resourceType "/" resourceName   
| summarize BillableDataBytes = sum(_BilledSize) by subscriptionId | sort by Bytes nulls last

subscriptionId 更改为 resourceGroup 后,就会显示可计费的已引入数据量(按 Azure 资源组计算)。Changing subscriptionId to resourceGroup will show the billable ingested data volume by Azure resource group.

提示

请谨慎使用这些 union * 查询,因为跨数据类型执行扫描很耗费资源Use these union * queries sparingly as scans across data types are resource intensive to execute. 如果你不需要每个订阅、资源组或资源名称的结果,则请按使用情况数据类型查询。If you do not need results per subscription, resouce group or resource name, then query on the Usage data type.

警告

使用情况数据类型的某些字段虽然仍在架构中,但已弃用,其值将不再填充。Some of the fields of the Usage data type, while still in the schema, have been deprecated and will their values are no longer populated. 这些是计算机以及与引入相关的字段(TotalBatchesBatchesWithinSlaBatchesOutsideSlaBatchesCappedAverageProcessingTimeMs)。These are Computer as well as fields related to ingestion (TotalBatches, BatchesWithinSla, BatchesOutsideSla, BatchesCapped and AverageProcessingTimeMs.

查询常见的数据类型Querying for common data types

若要更深入地了解特定数据类型的数据源,请使用下面这些有用的示例查询:To dig deeper into the source of data for a particular data type, here are some useful example queries:

  • 基于工作区的 Application Insights 资源Workspace-based Application Insights resources
  • “安全”解决方案Security solution
    • SecurityEvent | summarize AggregatedValue = count() by EventID
  • “日志管理”解决方案Log Management solution
    • Usage | where Solution == "LogManagement" and iff(isnotnull(toint(IsBillable)), IsBillable == true, IsBillable == "true") == true | summarize AggregatedValue = count() by DataType
  • “性能”数据类型Perf data type
    • Perf | summarize AggregatedValue = count() by CounterPath
    • Perf | summarize AggregatedValue = count() by CounterName
  • “事件”数据类型Event data type
    • Event | summarize AggregatedValue = count() by EventID
    • Event | summarize AggregatedValue = count() by EventLog, EventLevelName
  • “Syslog”数据类型Syslog data type
    • Syslog | summarize AggregatedValue = count() by Facility, SeverityLevel
    • Syslog | summarize AggregatedValue = count() by ProcessName
  • AzureDiagnostics 数据类型AzureDiagnostics data type
    • AzureDiagnostics | summarize AggregatedValue = count() by ResourceProvider, ResourceId

有关如何减少数据量的提示Tips for reducing data volume

有关如何减少所收集日志的量的一些提示:Some suggestions for reducing the volume of logs collected include:

高数据量来源Source of high data volume 如何减少数据量How to reduce data volume
安全性事件Security events 选择通用或最低安全性事件Select common or minimal security events
更改安全审核策略,只收集所需事件。Change the security audit policy to collect only needed events. 具体而言,请查看是否需要收集以下对象的事件:In particular, review the need to collect events for
- 审核筛选平台- audit filtering platform
- 审核注册表- audit registry
- 审核文件系统- audit file system
- 审核内核对象- audit kernel object
- 审核句柄操作- audit handle manipulation
- 审核可移动存储- audit removable storage
性能计数器Performance counters 更改性能计数器配置如下:Change performance counter configuration to:
- 降低收集频率- Reduce the frequency of collection
- 减少性能计数器数- Reduce number of performance counters
事件日志Event logs 更改事件日志配置如下:Change event log configuration to:
- 减少收集的事件日志数- Reduce the number of event logs collected
- 仅收集必需的事件级别。- Collect only required event levels. 例如,不收集“信息”级别事件For example, do not collect Information level events
SyslogSyslog 更改 syslog 配置如下:Change syslog configuration to:
- 减少收集的设施数- Reduce the number of facilities collected
- 仅收集必需的事件级别。- Collect only required event levels. 例如,不收集“信息”和“调试”级别事件 For example, do not collect Info and Debug level events
AzureDiagnosticsAzureDiagnostics 更改资源日志集合,以便:Change resource log collection to:
- 减少向 Log Analytics 发送日志的资源数目- Reduce the number of resources send logs to Log Analytics
- 仅收集必需的日志- Collect only required logs
不需解决方案的计算机中的解决方案数据Solution data from computers that don't need the solution 使用解决方案目标,只从必需的计算机组收集数据。Use solution targeting to collect data from only required groups of computers.

获取在“按节点”定价层中计费的节点Getting nodes as billed in the Per Node pricing tier

若要获取将按节点计费的计算机的列表(如果工作区位于旧的“按节点”定价层中),请查找要发送“计费数据类型”(某些数据类型免费)的节点。To get a list of computers which will be billed as nodes if the workspace is in the legacy Per Node pricing tier, look for nodes which are sending billed data types (some data types are free). 为此,请使用 _IsBillable 属性,并使用完全限定域名最左边的字段。To do this, use the _IsBillable property and use the leftmost field of the fully qualified domain name. 这将返回包含每小时计费数据的计算机计数(这是对节点进行计数和计费的粒度):This returns the count of computers with billed data per hour (which is the granularity at which nodes are counted and billed):

union withsource = tt * 
| where _IsBillable == true 
| extend computerName = tolower(tostring(split(Computer, '.')[0]))
| where computerName != ""
| summarize billableNodes=dcount(computerName) by bin(TimeGenerated, 1h) | sort by TimeGenerated asc

获取安全性和自动化节点计数Getting Security and Automation node counts

如果你位于“按节点(OMS)”定价层,则根据所用节点和解决方案数收费,需付费的 Insights and Analytics 节点数将显示在“使用情况和预估成本”页的表中。If you are on "Per node (OMS)" pricing tier, then you are charged based on the number of nodes and solutions you use, the number of Insights and Analytics nodes for which you are being billed will be shown in table on the Usage and Estimated Cost page.

若要查看不同安全节点的数目,可以使用以下查询:To see the number of distinct Security nodes, you can use the query:

union
(
    Heartbeat
    | where (Solutions has 'security' or Solutions has 'antimalware' or Solutions has 'securitycenter')
    | project Computer
),
(
    ProtectionStatus
    | where Computer !in~
    (
        (
            Heartbeat
            | project Computer
        )
    )
    | project Computer
)
| distinct Computer
| project lowComputer = tolower(Computer)
| distinct lowComputer
| count

若要查看不同自动化节点的数目,请使用以下查询:To see the number of distinct Automation nodes, use the query:

 ConfigurationData 
 | where (ConfigDataType == "WindowsServices" or ConfigDataType == "Software" or ConfigDataType =="Daemons") 
 | extend lowComputer = tolower(Computer) | summarize by lowComputer 
 | join (
     Heartbeat 
       | where SCAgentChannel == "Direct"
       | extend lowComputer = tolower(Computer) | summarize by lowComputer, ComputerEnvironment
 ) on lowComputer
 | summarize count() by ComputerEnvironment | sort by ComputerEnvironment asc

评估旧版按节点定价层Evaluating the legacy Per Node pricing tier

有权访问旧版“按节点”定价层的工作区是就在该层更好,还是在“即用即付”层或在“产能预留”层更好,客户通常很难进行评估 。The decision of whether workspaces with access to the legacy Per Node pricing tier are better off in that tier or in a current Pay-As-You-Go or Capacity Reservation tier is often difficult for customers to assess. 这涉及到了解按节点定价层中每个受监视节点的固定成本与其包含的数据分配(500 MB/每节点/每天),以及即用即付(每 GB)层中引入数据的成本之间的权衡。This involves understanding the trade-off between the fixed cost per monitored node in the Per Node pricing tier and its included data allocation of 500 MB/node/day and the cost of just paying for ingested data in the Pay-As-You-Go (Per GB) tier.

为了促进此评估,可以使用以下查询根据工作区的使用情况模式提供最佳定价层的建议。To facilitate this assessment, the following query can be used to make a recommendation for the optimal pricing tier based on a workspace's usage patterns. 此查询将查看过去 7 天内受监视的节点和引入到工作区的数据,并且对每天进行评估了解哪个定价层为最佳。This query looks at the monitored nodes and data ingested into a workspace in the last 7 days, and for each day evaluates which pricing tier would have been optimal. 若要使用查询,需要指定To use the query, you need to specify

  1. 工作区是否通过将 workspaceHasSecurityCenter 设置为 truefalse 来使用 Azure 安全中心,whether the workspace is using Azure Security Center by setting workspaceHasSecurityCenter to true or false,
  2. 如果有特定折扣,请更新价格,并且update the prices if you have specific discounts, and
  3. 通过设置 daysToEvaluate 指定要回看和分析的天数。specify the number of days to look back and analyze by setting daysToEvaluate. 如果查询尝试查看 7 天数据的时间过长,这就很有用。This is useful if the query is taking too long trying to look at 7 days of data.

以下是定价层建议查询:Here is the pricing tier recommendation query:

// Set these parameters before running query
let workspaceHasSecurityCenter = true;  // Specify if the workspace has Azure Security Center
let PerNodePrice = 15.; // Enter your montly price per monitored nodes
let PerNodeOveragePrice = 2.30; // Enter your price per GB for data overage in the Per Node pricing tier
let PerGBPrice = 2.30; // Enter your price per GB in the Pay-as-you-go pricing tier
let daysToEvaluate = 7; // Enter number of previous days look at (reduce if the query is taking too long)
// ---------------------------------------
let SecurityDataTypes=dynamic(["SecurityAlert", "SecurityBaseline", "SecurityBaselineSummary", "SecurityDetection", "SecurityEvent", "WindowsFirewall", "MaliciousIPCommunication", "LinuxAuditLog", "SysmonEvent", "ProtectionStatus", "WindowsEvent", "Update", "UpdateSummary"]);
let StartDate = startofday(datetime_add("Day",-1*daysToEvaluate,now()));
let EndDate = startofday(now());
union withsource = tt * 
| where TimeGenerated >= StartDate and TimeGenerated < EndDate
| extend computerName = tolower(tostring(split(Computer, '.')[0]))
| where computerName != ""
| summarize nodesPerHour = dcount(computerName) by bin(TimeGenerated, 1h)  
| summarize nodesPerDay = sum(nodesPerHour)/24.  by day=bin(TimeGenerated, 1d)  
| join kind=leftouter (
    Heartbeat 
    | where TimeGenerated >= StartDate and TimeGenerated < EndDate
    | where Computer != ""
    | summarize ASCnodesPerHour = dcount(Computer) by bin(TimeGenerated, 1h) 
    | extend ASCnodesPerHour = iff(workspaceHasSecurityCenter, ASCnodesPerHour, 0)
    | summarize ASCnodesPerDay = sum(ASCnodesPerHour)/24.  by day=bin(TimeGenerated, 1d)   
) on day
| join (
    Usage 
    | where TimeGenerated >= StartDate and TimeGenerated < EndDate
    | where IsBillable == true
    | extend NonSecurityData = iff(DataType !in (SecurityDataTypes), Quantity, 0.)
    | extend SecurityData = iff(DataType in (SecurityDataTypes), Quantity, 0.)
    | summarize DataGB=sum(Quantity)/1000., NonSecurityDataGB=sum(NonSecurityData)/1000., SecurityDataGB=sum(SecurityData)/1000. by day=bin(StartTime, 1d)  
) on day
| extend AvgGbPerNode =  NonSecurityDataGB / nodesPerDay
| extend PerGBDailyCost = iff(workspaceHasSecurityCenter,
             (NonSecurityDataGB + max_of(SecurityDataGB - 0.5*ASCnodesPerDay, 0.)) * PerGBPrice,
             DataGB * PerGBPrice)
| extend OverageGB = iff(workspaceHasSecurityCenter, 
             max_of(DataGB - 0.5*nodesPerDay - 0.5*ASCnodesPerDay, 0.), 
             max_of(DataGB - 0.5*nodesPerDay, 0.))
| extend PerNodeDailyCost = nodesPerDay * PerNodePrice / 31. + OverageGB * PerNodeOveragePrice
| extend Recommendation = iff(PerNodeDailyCost < PerGBDailyCost, "Per Node tier", 
             iff(NonSecurityDataGB > 85., "Capacity Reservation tier", "Pay-as-you-go (Per GB) tier"))
| project day, nodesPerDay, ASCnodesPerDay, NonSecurityDataGB, SecurityDataGB, OverageGB, AvgGbPerNode, PerGBDailyCost, PerNodeDailyCost, Recommendation | sort by day asc
//| project day, Recommendation // Comment this line to see details
| sort by day asc

此查询不是对如何计算使用情况的精确复制,而是在大多数情况下用于提供定价层建议。This query is not an exact replication of how usage is calculated, but will work for providing pricing tier recommendations in most cases.

备注

若要使用通过购买用于 System Center 的 OMS E1 套件、OMS E2 套件或 OMS 附加产品所获得的权利,请选择 Log Analytics 的“按节点”定价层。To use the entitlements that come from purchasing OMS E1 Suite, OMS E2 Suite or OMS Add-On for System Center, choose the Log Analytics Per Node pricing tier.

当数据收集量过高时创建警报Create an alert when data collection is high

本部分介绍如何在以下情况下创建警报:This section describes how to create an alert if:

  • 数据量超过指定的量。Data volume exceeds a specified amount.
  • 预测数据量会超过指定的量。Data volume is predicted to exceed a specified amount.

Azure 警报支持使用搜索查询的日志警报Azure Alerts support log alerts that use search queries.

如果在过去 24 小时内收集的数据超过 100 GB,则以下查询就会有结果:The following query has a result when there is more than 100 GB of data collected in the last 24 hours:

union withsource = $table Usage 
| where QuantityUnit == "MBytes" and iff(isnotnull(toint(IsBillable)), IsBillable == true, IsBillable == "true") == true 
| extend Type = $table | summarize DataGB = sum((Quantity / 1000.)) by Type 
| where DataGB > 100

以下查询使用简单的公式来预测在一天中发送的数据何时会超过 100 GB:The following query uses a simple formula to predict when more than 100 GB of data will be sent in a day:

union withsource = $table Usage 
| where QuantityUnit == "MBytes" and iff(isnotnull(toint(IsBillable)), IsBillable == true, IsBillable == "true") == true 
| extend Type = $table 
| summarize EstimatedGB = sum(((Quantity * 8) / 1000.)) by Type 
| where EstimatedGB > 100

若要针对其他数据量发出警报,请在查询中将 100 更改为要发出警报的 GB 数。To alert on a different data volume, change the 100 in the queries to the number of GB you want to alert on.

执行创建新的日志警报中介绍的步骤,当数据收集量超出预期时,系统就会发出通知。Use the steps described in create a new log alert to be notified when data collection is higher than expected.

为第一个查询创建警报时,如果 24 小时内的数据超出 100 GB,则请进行如下设置:When creating the alert for the first query -- when there is more than 100 GB of data in 24 hours, set the:

  • 定义警报条件将 Log Analytics 工作区指定为资源目标。Define alert condition specify your Log Analytics workspace as the resource target.
  • 警报条件指定下列项:Alert criteria specify the following:
    • 信号名称选择“自定义日志搜索”。Signal Name select Custom log search
    • 将“搜索查询”设置为 union withsource = $table Usage | where QuantityUnit == "MBytes" and iff(isnotnull(toint(IsBillable)), IsBillable == true, IsBillable == "true") == true | extend Type = $table | summarize DataGB = sum((Quantity / 1000.)) by Type | where DataGB > 100Search query to union withsource = $table Usage | where QuantityUnit == "MBytes" and iff(isnotnull(toint(IsBillable)), IsBillable == true, IsBillable == "true") == true | extend Type = $table | summarize DataGB = sum((Quantity / 1000.)) by Type | where DataGB > 100
    • 警报逻辑基于“结果数”且条件“大于”阈值“0”Alert logic is Based on number of results and Condition is Greater than a Threshold of 0
    • 将“时间段”设置为 1440 分钟,“警报频率”设置为每 60 分钟,因为使用情况数据一小时才更新一次。Time period of 1440 minutes and Alert frequency to every 60 minutes since the usage data only updates once per hour.
  • 定义警报详细信息指定以下项:Define alert details specify the following:
    • 将“名称”设置为“24 小时内的数据量大于 100 GB”Name to Data volume greater than 100 GB in 24 hours
    • 将“严重性”设置为“警告”Severity to Warning

指定现有的操作组或创建一个新操作组,以便当日志警报匹配条件时,你会收到通知。Specify an existing or create a new Action Group so that when the log alert matches criteria, you are notified.

为第二个查询创建警报时,如果预测 24 小时内的数据会超出 100 GB,则请进行如下设置:When creating the alert for the second query -- when it is predicted that there will be more than 100 GB of data in 24 hours, set the:

  • 定义警报条件将 Log Analytics 工作区指定为资源目标。Define alert condition specify your Log Analytics workspace as the resource target.
  • 警报条件指定下列项:Alert criteria specify the following:
    • 信号名称选择“自定义日志搜索”。Signal Name select Custom log search
    • 将“搜索查询”设置为 union withsource = $table Usage | where QuantityUnit == "MBytes" and iff(isnotnull(toint(IsBillable)), IsBillable == true, IsBillable == "true") == true | extend Type = $table | summarize EstimatedGB = sum(((Quantity * 8) / 1000.)) by Type | where EstimatedGB > 100Search query to union withsource = $table Usage | where QuantityUnit == "MBytes" and iff(isnotnull(toint(IsBillable)), IsBillable == true, IsBillable == "true") == true | extend Type = $table | summarize EstimatedGB = sum(((Quantity * 8) / 1000.)) by Type | where EstimatedGB > 100
    • 警报逻辑基于“结果数”且条件“大于”阈值“0”Alert logic is Based on number of results and Condition is Greater than a Threshold of 0
    • 将“时间段”设置为 180 分钟,“警报频率”设置为每 60 分钟,因为使用情况数据一小时才更新一次。Time period of 180 minutes and Alert frequency to every 60 minutes since the usage data only updates once per hour.
  • 定义警报详细信息指定以下项:Define alert details specify the following:
    • 将“名称”设置为“预期 24 小时内的数据量大于 100 GB”Name to Data volume expected to greater than 100 GB in 24 hours
    • 将“严重性”设置为“警告”Severity to Warning

指定现有的操作组或创建一个新操作组,以便当日志警报匹配条件时,你会收到通知。Specify an existing or create a new Action Group so that when the log alert matches criteria, you are notified.

收到警报后,请执行以下部分介绍的步骤,排查使用量超出预期的原因。When you receive an alert, use the steps in the following section to troubleshoot why usage is higher than expected.

使用 Log Analytics 时的数据传输费用Data transfer charges using Log Analytics

向 Log Analytics 发送数据可能会产生数据带宽费。Sending data to Log Analytics might incur data bandwidth charges. Azure 带宽定价页中所述,在两个区域中的 Azure 服务之间传输数据将按正常费率收取出站数据传输费。As described in the Azure Bandwidth pricing page, data transfer between Azure services located in two regions charged as outbound data transfer at the normal rate. 入站数据传输是免费的。Inbound data transfer is free. 但是,相比 Log Analytics 日志数据引入费,此传输费很低(只占几个百分比)。However, this charge is very small (few %) compared to the costs for Log Analytics data ingestion. 因此,控制 Log Analytics 的成本需要注重引入的数据量,此处提供了相关的指导。Consequently controlling costs for Log Analytics needs to focus on your ingested data volume, and we have guidance to help understand that here.

排查 Log Analytics 不再收集数据的原因Troubleshooting why Log Analytics is no longer collecting data

如果采用的是旧版免费定价层并且某天已发送的数据超过 500 MB,则该天的剩余时间会停止数据收集。If you are on the legacy Free pricing tier and have sent more than 500 MB of data in a day, data collection stops for the rest of the day. 达到每日限制是 Log Analytics 停止数据收集或者看起来缺少数据的常见原因。Reaching the daily limit is a common reason that Log Analytics stops collecting data, or data appears to be missing. 在数据收集启动和停止时,Log Analytics 会创建一个类型为“操作”的事件。Log Analytics creates an event of type Operation when data collection starts and stops. 请在搜索中运行以下查询来检查是否已达到每日限制并缺少数据:Run the following query in search to check if you are reaching the daily limit and missing data:

Operation | where OperationCategory == 'Data Collection Status'

当数据收集停止时,OperationStatus 为 WarningWhen data collection stops, the OperationStatus is Warning. 当数据收集启动时,OperationStatus 为 SucceededWhen data collection starts, the OperationStatus is Succeeded. 下表描述了数据收集停止的原因以及用于恢复数据收集的建议操作:The following table describes reasons that data collection stops and a suggested action to resume data collection:

停止收集的原因Reason collection stops 解决方案Solution
达到旧版免费定价层的每日限制Daily limit of legacy Free pricing tier reached 等到下一天收集自动重启,或者更改为付费定价层。Wait until the following day for collection to automatically restart, or change to a paid pricing tier.
达到了工作区的每日上限Daily cap of your workspace was reached 等到收集自动重启,或者根据“管理每日最大数据量”中所述提高每日数据量限制。Wait for collection to automatically restart, or increase the daily data volume limit described in manage the maximum daily data volume. 每日上限重置时间显示在“数据量管理”页面上。The daily cap reset time is shows on the Data volume management page.
Azure 订阅由于以下原因处于挂起状态:Azure subscription is in a suspended state due to:
试用已结束Trial ended
Azure 许可已过期Azure pass expired
已达到每月支出限制(例如,在 MSDN 或 Visual Studio 订阅上)Monthly spending limit reached (for example on an MSDN or Visual Studio subscription)
转换为付费订阅Convert to a paid subscription
删除限制,或者等到限制重置Remove limit, or wait until limit resets

若想在数据收集停止时收到通知,请使用创建每日数据上限警报中所述的步骤,以便在数据收集停止时收到通知。To be notified when data collection stops, use the steps described in Create daily data cap alert to be notified when data collection stops. 使用创建操作组中介绍的步骤,为警报规则配置电子邮件、Webhook 或 Runbook 操作。Use the steps described in create an action group to configure an e-mail, webhook, or runbook action for the alert rule.

限制摘要Limits summary

存在一些其他的 Log Analytics 限制,其中一些限制取决于 Log Analytics 定价层。There are some additional Log Analytics limits, some of which depend on the Log Analytics pricing tier. 这些限制在此处进行了详细介绍。These are documented here.

后续步骤Next steps