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

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

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

Diagnóstico do Azure versão 1.0 enviada pela primeira vez em um modelo de plug-in , o que significa que, quando você instalou o SDK do Azure, você tem a versão de Azure diagnostics enviada com ele.

A partir do SDK 2.5 (diagnóstico versão 1.2), Azure diagnóstico foi 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 de 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 de Azure usam esquemas de configuração diferentes. O esquema 1.0 e 1.2 foram preteridos. Para obter mais informações sobre a versão 1.3 e posterior, consulte o Esquema de Configuração do Diagnóstico 1.3 e posterior.

Histórico de versão

As seções a seguir descrevem as alterações feitas em cada versão da extensão de diagnóstico.

Extensão de diagnóstico 1.11

Adicionado suporte para o coletor de Azure Monitor. Esse coletor só é aplicável aos contadores de desempenho. Permite enviar contadores de desempenho coletados em sua VM, Conjuntos de Dimensionamento de Máquinas Virtuais ou serviço de nuvem para Azure Monitor como métricas personalizadas. O coletor Azure Monitor dá suporte a:

• Recuperando todos os contadores de desempenho enviados para Azure Monitor por meio das APIs de métricas Azure Monitor.
• Alertas em todos os contadores de desempenho enviados para Azure Monitor por meio da nova experiência de alertas unificados em Azure Monitor
• Tratamento do operador curinga em contadores de desempenho como a dimensão de "Instância" na sua métrica. Por exemplo, se você coletasse o contador "LogicalDisk(*)/DiskWrites/s", seria possível filtrar e dividir na dimensão "Instância". Ele permite que você plote ou alerte nas Gravações de Disco/s para cada Disco Lógico. Por exemplo, C:, D:e assim por diante.

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

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

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

Em seguida, você pode configurar seus contadores de desempenho para serem roteados para o coletor de 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 do Diagnóstico 1.9

Adicionar suporte ao Docker.

Extensão do Diagnóstico 1.8.1

Pode especificar um token SAS em vez de uma chave de conta de armazenamento na configuração particular. Se um token SAS for fornecido, a chave de 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 do Diagnóstico 1.8

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

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

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

Extensão do Diagnóstico 1.7

Adicionada a capacidade de rotear para Hubs de Eventos do Azure.

Extensão do diagnóstico 1.5

Adição do elemento de coleta e a capacidade de enviar dados de diagnósticos ao 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 a extensão de diagnóstico 1.3

Para projetos do Serviço de Nuvem em 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 dá suporte a diagnósticos. Essa alteração significa que você pode coletar dados de diagnóstico e garantir que seu aplicativo esteja criando os rastreamentos certos enquanto estiver desenvolvendo e testando em Visual Studio. O 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 (armazenamento de desenvolvimento).
• A conta de armazenamento de diagnóstico cadeia de conexão (Microsoft. WindowsAzure.Plugins.Diagnostics.ConnectionString) é armazenado mais uma vez 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 em SDK do Azure 2.4 e anterior e como ela funciona no SDK do Azure 2.6 e posterior.

• No SDK do Azure 2.4 e anterior, o cadeia de conexão foi usado em runtime 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, Visual Studio usa a cadeia de conexão de diagnóstico para configurar a extensão de diagnóstico com as informações apropriadas da conta de armazenamento durante a publicação. O cadeia de conexão permite definir diferentes contas de armazenamento para diferentes configurações de serviço que Visual Studio usa durante a publicação. No entanto, como o plug-in de diagnóstico não está mais disponível (após 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 de Visual Studio também contém o XML de configuração pública para a extensão de diagnóstico para cada função. Visual Studio usa o diagnóstico cadeia de conexão para preencher as informações da conta de armazenamento presentes na configuração pública. Os arquivos de configuração públicos são criados na pasta Extensões e seguem o padrão PaaSDiagnostics.<RoleName>.PubConfig.xml. Todas as implantações baseadas em PowerShell podem usar esse padrão para mapear cada configuração para uma função.
• O cadeia de conexão no arquivo .cscfg também é usado pelo portal Azure para acessar os dados de diagnóstico para que possam aparecer na guia Monitoring. O cadeia de conexão é necessário para configurar o serviço para mostrar dados detalhados de monitoramento no portal.

Migrando projetos para SDK do Azure 2.6 e posterior

Quando você migra de SDK do Azure 2.5 para 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 contas de armazenamento diferentes para diferentes configurações de armazenamento, você precisa adicionar manualmente o cadeia de conexão ao seu projeto. Se você estiver migrando um projeto do SDK do Azure 2.4 ou anterior para SDK do Azure 2.6, as cadeias de conexão de diagnóstico serão preservadas. No entanto, observe as alterações na forma como as cadeias de conexão são tratadas no SDK do Azure 2.6, conforme especificado na seção anterior.

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

• Se um diagnóstico cadeia de conexão for especificado no arquivo .cscfg, Visual Studio o 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 nenhum diagnóstico cadeia de conexão for especificado no arquivo .cscfg, Visual Studio retornará ao uso da conta de armazenamento especificada no arquivo .wadcfgx. Ele usa essa conta de armazenamento para configurar a extensão de diagnóstico ao publicar e gerar os arquivos xml de configuração pública ao empacotar.
• O diagnóstico cadeia de conexão no arquivo .cscfg tem precedência sobre a conta de armazenamento no arquivo .wadcfgx. Se um cadeia de conexão de diagnóstico for especificado no arquivo .cscfg, Visual Studio usará isso e ignorará a conta de armazenamento em .wadcfgx.

O que as "Cadeias de conexão de armazenamento de desenvolvimento de atualização..." caixa de seleção faz

A caixa de seleção para cadeias de conexão de armazenamento de desenvolvimento Update para diagnóstico e cache com credenciais de conta de armazenamento Microsoft Azure ao publicar no Microsoft Azure oferece uma maneira conveniente de atualizar as cadeias de conexão da conta de armazenamento de desenvolvimento com a conta de armazenamento Azure especificada durante a publicação.

Por exemplo, suponha que você selecione a caixa de seleção e o diagnóstico cadeia de conexão especifica UseDevelopmentStorage=true. Quando você publica o projeto para Azure, Visual Studio atualiza automaticamente o 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 tiver sido especificada como o diagnóstico cadeia de conexão, essa conta será usada.

Diferenças de funcionalidade de diagnóstico entre SDK do Azure 2.4 e anterior e 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, tenha em mente as seguintes diferenças de funcionalidade de diagnóstico.

• Configuration APIs são preteridas – a configuração programática de diagnóstico está disponível em SDK do Azure 2.4 ou versões anteriores, mas é preterida no SDK do Azure 2.5 e posterior. Se a configuração de diagnóstico estiver definida no código no momento, 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 SDK do Azure 2.4 é diagnostics.wadcfg e diagnostics.wadcfgx para SDK do Azure 2.5 e posterior.
• Diagnóstico para aplicativos de serviço de nuvem só podem ser configurados no nível de função, não no nível de instância.
• Toda vez 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 reimplantar seu aplicativo.
• In SDK do Azure 2.5 e posteriores, 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, será necessário transferir manualmente a configuração do código para o arquivo de configuração, pois os despejos de falha não são transferidos durante a migração para SDK do Azure 2.6.