Partilhar via

Histórico e versões do esquema de configuração da extensão de Diagnóstico do Windows Azure (WAD)

  • Artigo

Este artigo fornece o histórico de versões da extensão de Diagnóstico do Azure para Windows (WAD) versões do esquema fornecidas como parte do SDK do Microsoft Azure.

SDK do Azure e gráfico de envio de versões de diagnóstico

Versão do SDK do Azure Versão da extensão de diagnóstico Modelo
1.x 1.0 plug-in
2.0 - 2.4 1.0 plug-in
2.5 1.2 extensão
2.6 1.3 "
2,7 1.4 "
2.8 1.5 "
2.9 1.6 "
2.96 1.7 "
2.96 1.8 "
2.96 1.8.1 "
2.96 1.9 "
2.96 1.11 "
2.96 1.21 "

O Diagnóstico do Azure versão 1.0 foi fornecido pela primeira vez em um modelo de plug-in, o que significa que, quando você instalou o SDK do Azure, recebeu a versão do diagnóstico do Azure fornecida com ele.

A partir do SDK 2.5 (versão de diagnóstico 1.2), o diagnóstico do Azure passou para um modelo de extensão. As ferramentas para utilizar novos recursos só estavam disponíveis em SDKs do Azure mais recentes, mas qualquer serviço usando o diagnóstico do Azure pegaria a versão de envio mais recente diretamente do Azure. Por exemplo, qualquer pessoa que ainda esteja usando o SDK 2.5 estaria carregando a versão mais recente mostrada na tabela anterior, independentemente de estar usando os recursos mais recentes.

Índice de esquemas

Diferentes versões do diagnóstico do Azure usam esquemas de configuração diferentes. Os esquemas 1.0 e 1.2 foram preteridos. Para obter mais informações sobre a versão 1.3 e posterior, consulte Diagnostics 1.3 e esquema de configuração posterior

Histórico de versões

Extensão de diagnóstico 1.11

Adicionado suporte para o coletor do Azure Monitor. Este coletor só é aplicável a contadores de desempenho. Permite enviar contadores de desempenho coletados em sua VM, VMSS ou serviço de nuvem para o Azure Monitor como métricas personalizadas. O coletor do Azure Monitor suporta:

  • Recuperando todos os contadores de desempenho enviados para o Azure Monitor por meio das APIs de métricas do Azure Monitor.
  • Alertas em todos os contadores de desempenho enviados para o Azure Monitor através da nova experiência de alertas unificados no Azure Monitor
  • Tratar o operador curinga em contadores de desempenho como a dimensão "Instância" em sua métrica. Por exemplo, se você coletou o contador "LogicalDisk(*)/DiskWrites/sec", poderá filtrar e dividir na dimensão "Instância" para plotar ou alertar nas gravações de disco/s para cada disco lógico (C:, D:, etc.)

Definir o Azure Monitor como um novo coletor em sua configuração de extensão de diagnóstico

"SinksConfig": {
    "Sink": [
        {
            "name": "AzureMonitorSink",
            "AzureMonitor": {}
        },
    ]
}

<SinksConfig>  
  <Sink name="AzureMonitorSink">
      <AzureMonitor/>
  </Sink>
</SinksConfig>

Nota

Configurar o coletor do Azure Monitor para VMs Clássicas e Serviço CLoud Clássico requer mais parâmetros a serem definidos na configuração privada da extensão de Diagnóstico.

Para obter mais detalhes, consulte a documentação detalhada do esquema de extensão de diagnóstico.

Em seguida, você pode configurar seus contadores de desempenho para serem roteados para o Coletor do Azure Monitor.

"PerformanceCounters": {
    "scheduledTransferPeriod": "PT1M",
    "sinks": "AzureMonitorSink",
    "PerformanceCounterConfiguration": [
        {
            "counterSpecifier": "\\Processor(_Total)\\% Processor Time",
            "sampleRate": "PT1M",
            "unit": "percent"
        }
    ]
},

<PerformanceCounters scheduledTransferPeriod="PT1M", sinks="AzureMonitorSink">  
  <PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Processor Time" sampleRate="PT1M" unit="percent" />  
</PerformanceCounters>

Extensão de diagnóstico 1.9

Adicionado suporte ao Docker.

Extensão de diagnóstico 1.8.1

Pode especificar um token SAS em vez de uma chave de conta de armazenamento na configuração privada. Se um token SAS for fornecido, a chave da conta de armazenamento será ignorada.

{
    "storageAccountName": "diagstorageaccount",
    "storageAccountEndPoint": "https://core.windows.net",
    "storageAccountSasToken": "{sas token}",
    "SecondaryStorageAccounts": {
        "StorageAccount": [
            {
                "name": "secondarydiagstorageaccount",
                "endpoint": "https://core.windows.net",
                "sasToken": "{sas token}"
            }
        ]
    }
}

<PrivateConfig>
    <StorageAccount name="diagstorageaccount" endpoint="https://core.windows.net" sasToken="{sas token}" />
    <SecondaryStorageAccounts>
        <StorageAccount name="secondarydiagstorageaccount" endpoint="https://core.windows.net" sasToken="{sas token}" />
    </SecondaryStorageAccounts>
</PrivateConfig>

Extensão de diagnóstico 1.8

Tipo de armazenamento adicionado ao PublicConfig. StorageType pode ser Table, Blob, TableAndBlob. Tabela é o padrão.

{
    "WadCfg": {
    },
    "StorageAccount": "diagstorageaccount",
    "StorageType": "TableAndBlob"
}

<PublicConfig>
    <WadCfg />
    <StorageAccount>diagstorageaccount</StorageAccount>
    <StorageType>TableAndBlob</StorageType>
</PublicConfig>

Extensão de diagnóstico 1.7

Adicionada a capacidade de rotear para o EventHub.

Extensão de diagnóstico 1.5

Adicionado o elemento coletores e a capacidade de enviar dados de diagnóstico para o Application Insights , facilitando o diagnóstico de problemas em seu aplicativo, bem como no nível do sistema e da infraestrutura.

SDK do Azure 2.6 e extensão de diagnóstico 1.3

Para projetos do Serviço de Nuvem no Visual Studio, as seguintes alterações foram feitas. (Essas alterações também se aplicam a versões posteriores do SDK do Azure.)

  • O emulador local agora suporta diagnóstico. Essa alteração significa que você pode coletar dados de diagnóstico e garantir que seu aplicativo esteja criando os rastreamentos corretos enquanto você está desenvolvendo e testando no Visual Studio. A cadeia de conexão UseDevelopmentStorage=true habilita a coleta de dados de diagnóstico enquanto você executa seu projeto de serviço de nuvem no Visual Studio usando o Emulador de Armazenamento do Azure. Todos os dados de diagnóstico são coletados na conta de armazenamento (Development Storage).
  • A cadeia de conexão da conta de armazenamento de diagnóstico (Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString) é armazenada novamente no arquivo de configuração de serviço (.cscfg). No SDK do Azure 2.5, a conta de armazenamento de diagnóstico foi especificada no arquivo diagnostics.wadcfgx.

Há algumas diferenças notáveis entre como a cadeia de conexão funcionava no SDK do Azure 2.4 e anteriores e como ela funciona no SDK do Azure 2.6 e posterior.

  • No SDK do Azure 2.4 e anteriores, a cadeia de conexão era usada em tempo de execução pelo plug-in de diagnóstico para obter as informações da conta de armazenamento para transferir logs de diagnóstico.
  • No SDK do Azure 2.6 e posterior, o Visual Studio usa a cadeia de conexão de diagnóstico para configurar a extensão de diagnóstico com as informações de conta de armazenamento apropriadas durante a publicação. A cadeia de conexão permite definir diferentes contas de armazenamento para diferentes configurações de serviço que o Visual Studio usará ao publicar. No entanto, como o plug-in de diagnóstico não está mais disponível (após o SDK do Azure 2.5), o arquivo .cscfg por si só não pode habilitar a Extensão de Diagnóstico. Você precisa habilitar a extensão separadamente por meio de ferramentas como Visual Studio ou PowerShell.
  • Para simplificar o processo de configuração da extensão de diagnóstico com o PowerShell, a saída do pacote do Visual Studio também contém o XML de configuração pública para a extensão de diagnóstico para cada função. O Visual Studio usa a cadeia de conexão de diagnóstico para preencher as informações da conta de armazenamento presentes na configuração pública. Os arquivos de configuração pública são criados na pasta Extensões e seguem o padrão PaaSDiagnostics.<RoleName>.PubConfig.xml. Qualquer implantação baseada no PowerShell pode usar esse padrão para mapear cada configuração para uma Função.
  • A cadeia de conexão no arquivo .cscfg também é usada pelo portal do Azure para acessar os dados de diagnóstico para que eles possam aparecer na guia Monitoramento . A cadeia de conexão é necessária para configurar o serviço para mostrar dados de monitoramento detalhados no portal.

Migrando projetos para o SDK do Azure 2.6 e posterior

Ao migrar do SDK do Azure 2.5 para o SDK do Azure 2.6 ou posterior, se você tiver uma conta de armazenamento de diagnóstico especificada no arquivo .wadcfgx, ela permanecerá lá. Para aproveitar a flexibilidade de usar diferentes contas de armazenamento para diferentes configurações de armazenamento, você terá que adicionar manualmente a cadeia de conexão ao seu projeto. Se você estiver migrando um projeto do SDK do Azure 2.4 ou anterior para o SDK do Azure 2.6, as cadeias de conexão de diagnóstico serão preservadas. No entanto, observe as alterações em como as cadeias de conexão são tratadas no SDK do Azure 2.6, conforme especificado na seção anterior.

Como o Visual Studio determina a conta de armazenamento de diagnóstico

  • Se uma cadeia de conexão de diagnóstico for especificada no arquivo .cscfg, o Visual Studio a usará para configurar a extensão de diagnóstico ao publicar e ao gerar os arquivos xml de configuração pública durante o empacotamento.
  • Se nenhuma cadeia de conexão de diagnóstico for especificada no arquivo .cscfg, o Visual Studio voltará a usar a conta de armazenamento especificada no arquivo .wadcfgx para configurar a extensão de diagnóstico ao publicar e gerar os arquivos xml de configuração pública ao empacotar.
  • A cadeia de conexão de diagnóstico no arquivo .cscfg tem precedência sobre a conta de armazenamento no arquivo .wadcfgx. Se uma cadeia de conexão de diagnóstico for especificada no arquivo .cscfg, o Visual Studio usará isso e ignorará a conta de armazenamento em .wadcfgx.

O que faz a "Atualizar cadeias de conexão de armazenamento de desenvolvimento..." caixa de seleção fazer?

A caixa de seleção Atualizar cadeias de conexão de armazenamento de desenvolvimento para Diagnóstico e Cache com credenciais de conta de armazenamento do Microsoft Azure ao publicar no Microsoft Azure oferece uma maneira conveniente de atualizar qualquer cadeia de conexão de conta de armazenamento de desenvolvimento com a conta de armazenamento do Azure especificada durante a publicação.

Por exemplo, suponha que você marque essa caixa de seleção e a cadeia de conexão de diagnóstico especifique UseDevelopmentStorage=true. Quando você publica o projeto no Azure, o Visual Studio atualiza automaticamente a cadeia de conexão de diagnóstico com a conta de armazenamento especificada no assistente de publicação. No entanto, se uma conta de armazenamento real foi especificada como a cadeia de conexão de diagnóstico, essa conta será usada.

Diferenças de funcionalidade de diagnóstico entre o SDK do Azure 2.4 e anteriores e o SDK do Azure 2.5 e posterior

Se você estiver atualizando seu projeto do SDK do Azure 2.4 para o SDK do Azure 2.5 ou posterior, lembre-se das seguintes diferenças de funcionalidade de diagnóstico.

  • As APIs de configuração foram preteridas – a configuração programática do diagnóstico está disponível no SDK do Azure 2.4 ou em versões anteriores, mas foi preterida no SDK do Azure 2.5 e posterior. Se sua configuração de diagnóstico estiver atualmente definida no código, você precisará reconfigurar essas configurações do zero no projeto migrado para que o diagnóstico continue funcionando. O arquivo de configuração de diagnóstico para o SDK do Azure 2.4 é diagnostics.wadcfg e diagnostics.wadcfgx para o SDK do Azure 2.5 e posterior.
  • O diagnóstico para aplicativos de serviço de nuvem só pode ser configurado no nível da função, não no nível da instância.
  • Sempre que você implanta seu aplicativo, a configuração de diagnóstico é atualizada – Isso pode causar problemas de paridade se você alterar a configuração de diagnóstico do Gerenciador de Servidores e, em seguida, reimplantar seu aplicativo.
  • No SDK do Azure 2.5 e posterior, os despejos de memória são configurados no arquivo de configuração de diagnóstico, não no código – Se você tiver despejos de memória configurados no código, terá que transferir manualmente a configuração do código para o arquivo de configuração, porque os despejos de memória não são transferidos durante a migração para o SDK do Azure 2.6.