为啥不能配置 Azure 诊断以通过新的 Azure 门户使用 Azure 表存储？

Posted 2023-03-22

【中文标题】为啥不能配置 Azure 诊断以通过新的 Azure 门户使用 Azure 表存储？

【英文标题】：Why can't configure Azure diagnostics to use Azure Table Storage via new Azure Portal?为什么不能配置 Azure 诊断以通过新的 Azure 门户使用 Azure 表存储？

【发布时间】：2016-06-30 14:54:15

【问题描述】：

我正在开发一个将托管在 Azure 中的 Web api。我想使用 Azure 诊断将错误记录到 Azure 表存储。 在经典门户中，我可以将日志配置为转到 Azure 表存储。

Classic Portal Diagnostic Settings

但是在新的 Azure 门户中，我唯一的存储选项是使用 Blob 存储：

New Azure Portal Settings

似乎如果我要使用 Web 角色，我可以配置数据存储以进行诊断，但是在开发 Web api 时，我不想为每个 api 创建单独的 Web 角色我可以登录到 azure 表。

有没有一种方法可以在不使用 Web 角色的情况下以编程方式配置 azure 诊断以将日志消息传播到特定数据存储？为什么新的 Azure 门户只有 Blob 存储而不是表存储的诊断设置？

我目前可以使用经典门户解决此问题，但我担心用于诊断的表存储最终会被弃用，因为它尚未包含在新门户的诊断设置中。

【问题讨论】：

您可能需要查看自定义服务来做到这一点，例如www.trypour.com

【参考方案1】：

（我将对这个问题做一些死灵法，因为这是我在寻找解决方案时发现的最相关的 *** 问题，因为不再可能通过经典门户做到这一点）

免责声明：Microsoft 似乎已经取消了对 Azure 门户中记录到 Table 的支持，所以我不知道这是否已被弃用或即将被弃用，但我有一个现在可以使用的解决方案 (31.03.2017)：

有一些特定的设置决定了日志记录，我首先从 Azure Powershell github 中的一个问题中找到了这方面的信息：https://github.com/Azure/azure-powershell/issues/317

我们需要的具体设置是（来自github）：

AzureTableTraceEnabled = True，& AppSettings 具有： DIAGNOSTICS_AZURETABLESASURL

使用（GUI导航）下的优秀资源浏览器（https://resources.azure.com）：

/subscriptions/subscriptionName/resourceGroups/resourceGroupName/providers/Microsoft.Web/sites/siteName/config/logs

我能够在属性中找到设置 AzureTableTraceEnabled。

属性 AzureTableTraceEnabled 具有 Level 和 sasURL。根据我的经验，更新这两个值 (Level="Verbose",sasUrl="someSASurl") 将起作用，因为在 appsettings 中更新 sasURL 集 DIAGNOSTICS_AZURETABLESASURL。

我们如何改变这一点？我是在 Powershell 中完成的。我首先尝试了 cmdlet Get-AzureRmWebApp，但找不到我想要的 - 旧的 Get-AzureWebSite 确实显示 AzureTableTraceEnabled，但我无法更新它（也许有更多 powershell\azure 经验的人可以提供有关如何使用 ASM cmdlet 来执行此操作）。

对我有用的解决方案是通过 Set-AzureRmResource 命令设置属性，设置如下：

Set-AzureRmResource -PropertyObject $PropertiesObject -ResourceGroupName "$ResourceGroupName" -ResourceType Microsoft.Web/sites/config -ResourceName "$ResourceName/logs" -ApiVersion 2015-08-01 -Force

$PropertiesObject 如下所示：

$PropertiesObject = @applicationLogs=@azureTableStorage=@level="$Level";sasUrl="$SASUrl"

级别对应“错误”、“警告”、“信息”、“详细”和“关闭”。

也可以在 ARM 模板中执行此操作（重要位在站点日志资源的属性中）：

        
            "apiVersion": "2015-08-01",
            "name": "[variables('webSiteName')]",
            "type": "Microsoft.Web/sites",
            "location": "[resourceGroup().location]",
            "tags": 
                "displayName": "WebApp"
            ,
            "dependsOn": [
                "[resourceId('Microsoft.Web/serverfarms/', variables('hostingPlanName'))]"
            ],
            "properties": 
                "name": "[variables('webSiteName')]",
                "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]"
            ,
            "resources": [
            
                "name": "logs",
                "type": "config",
                "apiVersion": "2015-08-01",
                "dependsOn": [
                    "[resourceId('Microsoft.Web/sites/', variables('webSiteName'))]"
                ],
                "tags": 
                    "displayName": "LogSettings"
                ,
                "properties": 
                    "azureTableStorage": 
                        "level": "Verbose",
                        "sasUrl": "SASURL"
                    
                
            
        

在 ARM 中执行此操作的问题是我还没有找到生成正确 SAS 的方法，可以获取 Azure 存储帐户密钥（来自：ARM - How can I get the access key from a storage account to use in AppSettings later in the template?） ：

"properties": 
    "type": "AzureStorage",
        "typeProperties": 
            "connectionString": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'),';AccountKey=',listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), providers('Microsoft.Storage', 'storageAccounts').apiVersions[0]).keys[0].value)]"
    

还有一些巧妙的方法可以使用链接模板生成它们（来自：http://wp.sjkp.dk/service-bus-arm-templates/）。

我目前采用的解决方案（时间限制）是一个自定义的 Powershell 脚本，看起来像这样：

...
$SASUrl = New-AzureStorageTableSASToken -Name $LogTable -Permission $Permissions -Context $StorageContext -StartTime $StartTime -ExpiryTime $ExpiryTime -FullUri
$PropertiesObject = @applicationLogs=@azureTableStorage=@level="$Level";sasUrl="$SASUrl"
Set-AzureRmResource -PropertyObject $PropertiesObject -ResourceGroupName "$ResourceGroupName" -ResourceType Microsoft.Web/sites/config -ResourceName "$ResourceName/logs" -ApiVersion 2015-08-01 -Force
...

这是一个非常丑陋的解决方案，因为除了 ARM 模板之外，您还需要维护一些额外的东西 - 但它简单、快速，并且在我们等待 ARM 模板更新时（或者比我来开导我们）。

【参考方案2】：

我们通常不建议将表用于日志数据 - 这可能会导致仅附加模式在大规模上无法有效地用于表存储。请参阅本指南Table Design Guide 中的日志数据反模式。我们经常看到，即使人们认为日志数据是结构化的——他们通常查询它的方式使 Blob 更有效率。

设计指南节选：

日志数据反模式

通常，您应该使用 Blob 服务而不是表服务来存储日志数据。

背景和问题

日志数据的一个常见用例是检索特定日期/时间范围的日志条目选择：例如，您想查找应用程序在 15:04 到 15 之间记录的所有错误和关键消息： 06 在特定日期。您不想使用日志消息的日期和时间来确定将日志实体保存到的分区：这会导致热分区，因为在任何给定时间，所有日志实体都将共享相同的 PartitionKey 值（请参阅第前置/附加反模式）。 ...

解决方案

上一节重点介绍了尝试使用表服务存储日志条目的问题，并提出了两种不令人满意的设计。一种解决方案导致热分区存在写入日志消息性能不佳的风险；另一种解决方案导致查询性能不佳，因为需要扫描表中的每个分区以检索特定时间跨度的日志消息。 Blob 存储为此类场景提供了更好的解决方案，这就是 Azure 存储分析存储它收集的日志数据的方式。

本部分概述了存储分析如何将日志数据存储在 blob 存储中，以说明这种存储您通常按范围查询的数据的方法。

Storage Analytics 以分隔格式将日志消息存储在多个 blob 中。分隔格式使客户端应用程序可以轻松解析日志消息中的数据。

Storage Analytics 使用 Blob 的命名约定，使您能够找到包含您正在搜索的日志消息的 Blob（或多个 Blob）。例如，名为“queue/2014/07/31/1800/000001.log”的 blob 包含与 2014 年 7 月 31 日 18:00 开始的小时内的队列服务相关的日志消息。“000001”表示此是此期间的第一个日志文件。 Storage Analytics 还会记录存储在文件中的第一条和最后一条日志消息的时间戳，作为 blob 元数据的一部分。 Blob 存储 API 使您可以根据名称前缀在容器中定位 Blob：要定位包含从 18:00 开始的一小时的队列日志数据的所有 Blob，您可以使用前缀“queue/2014/07/31 /1800。”

Storage Analytics 在内部缓冲日志消息，然后定期更新相应的 blob 或使用最新一批日志条目创建新的 blob。这减少了它必须对 blob 服务执行的写入次数。

如果您在自己的应用程序中实施类似的解决方案，则必须考虑如何在可靠性（将每个日志条目写入 blob 存储时）与成本和可扩展性（在应用程序中缓冲更新和将它们批量写入 blob 存储）。

问题和注意事项

在决定如何存储日志数据时考虑以下几点：

如果您创建的表设计可以避免潜在的热分区，您可能会发现无法高效地访问日志数据。

为了处理日志数据，客户端通常需要加载许多记录。

虽然日志数据通常是结构化的，但 Blob 存储可能是更好的解决方案。

【讨论】：

感谢回复，有没有可以查询的blob存储查看器推荐？目前，当我尝试从云资源管理器访问数据时，似乎必须下载一个 csv 文件才能查看日志？

我喜欢查询日志表的方式。

是否有一个 nuget 库来帮助“查询”以这种文件结构存储在 Azure blob 存储中的应用程序日志？

我创建了一个实用类来查询存储在 blob 存储中的日志 - 以防其他人感兴趣：gist.github.com/CameronWills/0a7e4a8fc8ee9ede65a2cbaac9c0693c

有没有办法恢复这个选项？我们完整的日志记录和分析逻辑都建立在此之上。