Agregação e coleta de eventos usando o Diagnóstico do Windows Azure
Quando você estiver executando um cluster do Azure Service Fabric, é uma boa ideia coletar os logs de todos os nós em um local central. Ter os logs em um local central ajuda a analisar e solucionar problemas no cluster ou problemas nos aplicativos e serviços em execução nesse cluster.
Uma maneira de carregar e coletar logs é usar a extensão WAD (Diagnóstico do Windows Azure), que carrega logs no Armazenamento do Azure e também tem a opção de enviar logs para o Azure Application Insights ou Hubs de Eventos. Você também pode usar um processo externo para ler os eventos do armazenamento e colocá-los em um produto de plataforma de análise, como logs do Azure Monitor ou outra solução de análise de log.
Nota
Recomendamos que utilize o módulo do Azure Az PowerShell para interagir com o Azure. Veja Instalar o Azure PowerShell para começar. Para saber como migrar para o módulo do Az PowerShell, veja Migrar o Azure PowerShell do AzureRM para o Az.
Pré-requisitos
As seguintes ferramentas são usadas neste artigo:
Eventos da plataforma Service Fabric
O Service Fabric configura você com alguns canais de log prontos para uso, dos quais os seguintes canais são pré-configurados com a extensão para enviar dados de monitoramento e diagnóstico para uma tabela de armazenamento ou outro lugar:
- Eventos operacionais: operações de nível superior executadas pela plataforma Service Fabric. Os exemplos incluem a criação de aplicativos e serviços, alterações de estado do nó e informações de atualização. Estes são emitidos como logs ETW (Event Tracing for Windows)
- Atores confiáveis programando eventos modelo
- Eventos do modelo de programação de serviços confiáveis
Implantar a extensão Diagnostics através do portal
A primeira etapa na coleta de logs é implantar a extensão Diagnóstico nos nós do conjunto de dimensionamento de máquina virtual no cluster do Service Fabric. A extensão Diagnostics coleta logs em cada VM e os carrega na conta de armazenamento especificada. As etapas a seguir descrevem como fazer isso para clusters novos e existentes por meio do portal do Azure e dos modelos do Azure Resource Manager.
Implantar a extensão de Diagnóstico como parte da criação de cluster por meio do portal do Azure
Ao criar o cluster, na etapa de configuração do cluster, expanda as configurações opcionais e verifique se Diagnostics está definido como On (a configuração padrão).
É altamente recomendável que você baixe o modelo antes de clicar em Criar na etapa final. Para obter detalhes, consulte Configurar um cluster do Service Fabric usando um modelo do Azure Resource Manager. Você precisa do modelo para fazer alterações em quais canais (listados acima) coletar dados.
Agora que você está agregando eventos no Armazenamento do Azure, configure os logs do Azure Monitor para obter informações e consultá-los no portal de logs do Azure Monitor
Nota
Atualmente, não há como filtrar ou preparar os eventos que são enviados para as tabelas. Se você não implementar um processo para remover eventos da tabela, a tabela continuará a crescer (o limite padrão é de 50 GB). Instruções sobre como alterar isso estão mais abaixo neste artigo. Além disso, há um exemplo de um serviço de aliciamento de dados em execução no exemplo do Watchdog, e é recomendável que você escreva um para si mesmo, a menos que haja um bom motivo para armazenar logs além de um período de 30 ou 90 dias.
Implantar a extensão de Diagnóstico por meio do Azure Resource Manager
Criar um cluster com a extensão de diagnóstico
Para criar um cluster usando o Gerenciador de Recursos, você precisa adicionar o JSON de configuração de Diagnóstico ao modelo completo do Gerenciador de Recursos. Fornecemos um exemplo de modelo do Gerenciador de Recursos de cluster de cinco VMs com a configuração de Diagnóstico adicionada a ele como parte de nossos exemplos de modelo do Gerenciador de Recursos. Você pode vê-lo neste local na galeria de Exemplos do Azure: Exemplo de modelo de cluster de cinco nós com Gerenciador de Recursos de Diagnóstico.
Para ver a configuração Diagnóstico no modelo do Gerenciador de Recursos, abra o arquivo azuredeploy.json e procure IaaSDiagnostics. Para criar um cluster usando esse modelo, selecione o botão Implantar no Azure disponível no link anterior.
Como alternativa, você pode baixar o exemplo do Gerenciador de Recursos, fazer alterações nele e criar um cluster com o modelo modificado usando o comando em uma janela do New-AzResourceGroupDeployment Azure PowerShell. Consulte o código a seguir para os parâmetros que você passa para o comando. Para obter informações detalhadas sobre como implantar um grupo de recursos usando o PowerShell, consulte o artigo Implantar um grupo de recursos com o modelo do Azure Resource Manager.
Adicionar a extensão de diagnóstico a um cluster existente
Se você tiver um cluster existente que não tenha o Diagnóstico implantado, poderá adicioná-lo ou atualizá-lo por meio do modelo de cluster. Modifique o modelo do Gerenciador de Recursos usado para criar o cluster existente ou baixe o modelo do portal, conforme descrito anteriormente. Modifique o arquivo template.json executando as seguintes tarefas:
Adicione um novo recurso de armazenamento ao modelo adicionando à seção de recursos.
{
"apiVersion": "2018-07-01",
"type": "Microsoft.Storage/storageAccounts",
"name": "[parameters('applicationDiagnosticsStorageAccountName')]",
"location": "[parameters('computeLocation')]",
"sku": {
"name": "[parameters('applicationDiagnosticsStorageAccountType')]"
"tier": "standard"
},
"tags": {
"resourceType": "Service Fabric",
"clusterName": "[parameters('clusterName')]"
}
},
Em seguida, adicione à seção de parâmetros logo após as definições da conta de armazenamento, entre supportLogStorageAccountName. Substitua o espaço reservado, o nome da conta de armazenamento de texto vai aqui pelo nome da conta de armazenamento desejada.
"applicationDiagnosticsStorageAccountType": {
"type": "string",
"allowedValues": [
"Standard_LRS",
"Standard_GRS"
],
"defaultValue": "Standard_LRS",
"metadata": {
"description": "Replication option for the application diagnostics storage account"
}
},
"applicationDiagnosticsStorageAccountName": {
"type": "string",
"defaultValue": "**STORAGE ACCOUNT NAME GOES HERE**",
"metadata": {
"description": "Name for the storage account that contains application diagnostics data from the cluster"
}
},
Em seguida, atualize a VirtualMachineProfile seção do arquivo template.json adicionando o código a seguir dentro da matriz de extensões. Certifique-se de adicionar uma vírgula no início ou no final, dependendo de onde ela está inserida.
{
"name": "[concat(parameters('vmNodeType0Name'),'_Microsoft.Insights.VMDiagnosticsSettings')]",
"properties": {
"type": "IaaSDiagnostics",
"autoUpgradeMinorVersion": true,
"protectedSettings": {
"storageAccountName": "[parameters('applicationDiagnosticsStorageAccountName')]",
"storageAccountKey": "[listKeys(resourceId('Microsoft.Storage/storageAccounts', parameters('applicationDiagnosticsStorageAccountName')),'2015-05-01-preview').key1]",
"storageAccountEndPoint": "https://core.windows.net/"
},
"publisher": "Microsoft.Azure.Diagnostics",
"settings": {
"WadCfg": {
"DiagnosticMonitorConfiguration": {
"overallQuotaInMB": "50000",
"EtwProviders": {
"EtwEventSourceProviderConfiguration": [
{
"provider": "Microsoft-ServiceFabric-Actors",
"scheduledTransferKeywordFilter": "1",
"scheduledTransferPeriod": "PT5M",
"DefaultEvents": {
"eventDestination": "ServiceFabricReliableActorEventTable"
}
},
{
"provider": "Microsoft-ServiceFabric-Services",
"scheduledTransferPeriod": "PT5M",
"DefaultEvents": {
"eventDestination": "ServiceFabricReliableServiceEventTable"
}
}
],
"EtwManifestProviderConfiguration": [
{
"provider": "cbd93bc2-71e5-4566-b3a7-595d8eeca6e8",
"scheduledTransferLogLevelFilter": "Information",
"scheduledTransferKeywordFilter": "4611686018427387904",
"scheduledTransferPeriod": "PT5M",
"DefaultEvents": {
"eventDestination": "ServiceFabricSystemEventTable"
}
},
{
"provider": "02d06793-efeb-48c8-8f7f-09713309a810",
"scheduledTransferLogLevelFilter": "Information",
"scheduledTransferKeywordFilter": "4611686018427387904",
"scheduledTransferPeriod": "PT5M",
"DefaultEvents": {
"eventDestination": "ServiceFabricSystemEventTable"
}
}
]
}
}
},
"StorageAccount": "[parameters('applicationDiagnosticsStorageAccountName')]"
},
"typeHandlerVersion": "1.5"
}
}
Depois de modificar o arquivo template.json conforme descrito, publique novamente o modelo do Gerenciador de Recursos. Se o modelo foi exportado, a execução do arquivo deploy.ps1 republica o modelo. Depois de implantar, verifique se ProvisioningState foi bem-sucedido.
Gorjeta
Se você for implantar contêineres em seu cluster, habilite o WAD para coletar estatísticas do docker adicionando-as à seção WadCfg > DiagnosticMonitorConfiguration .
"DockerSources": {
"Stats": {
"enabled": true,
"sampleRate": "PT1M"
}
},
Atualizar cota de armazenamento
Como as tabelas preenchidas pela extensão crescem até que a cota seja atingida, convém considerar diminuir o tamanho da cota. O valor padrão é 50 GB e é configurável no modelo sob o overallQuotaInMB campo em DiagnosticMonitorConfiguration
"overallQuotaInMB": "50000",
Configurações de coleta de log
Logs de canais adicionais também estão disponíveis para coleta, aqui estão algumas das configurações mais comuns que você pode fazer no modelo para clusters em execução no Azure.
Canal Operacional - Base: Habilitado por padrão, operações de alto nível executadas pelo Service Fabric e pelo cluster, incluindo eventos para um nó que está chegando, um novo aplicativo sendo implantado ou uma reversão de atualização, etc. Para obter uma lista de eventos, consulte Eventos do canal operacional.
"scheduledTransferKeywordFilter": "4611686018427387904"Canal Operacional - Detalhado: Inclui relatórios de integridade e decisões de balanceamento de carga, além de tudo no canal operacional de base. Esses eventos são gerados pelo sistema ou pelo seu código usando as APIs de relatório de integridade ou carga, como ReportPartitionHealth ou ReportLoad. Para exibir esses eventos no Visualizador de Eventos de Diagnóstico do Visual Studio, adicione "Microsoft-ServiceFabric:4:0x4000000000000008" à lista de provedores ETW.
"scheduledTransferKeywordFilter": "4611686018427387912"Data and Messaging Channel - Base: Logs críticos e eventos gerados no sistema de mensagens (atualmente apenas o ReverseProxy) e no caminho de dados, além de logs de canal operacionais detalhados. Esses eventos são falhas de processamento de solicitações e outros problemas críticos no ReverseProxy, bem como solicitações processadas. Esta é a nossa recomendação para uma exploração madeireira abrangente. Para exibir esses eventos no Visualizador de Eventos de Diagnóstico do Visual Studio, adicione "Microsoft-ServiceFabric:4:0x4000000000000010" à lista de provedores ETW.
"scheduledTransferKeywordFilter": "4611686018427387928"Data & Messaging Channel - Detalhado: canal detalhado que contém todos os logs não críticos de dados e mensagens no cluster e o canal operacional detalhado. Para obter uma solução de problemas detalhada de todos os eventos de proxy reverso, consulte o guia de diagnóstico de proxy reverso. Para exibir esses eventos no visualizador de eventos de diagnóstico do Visual Studio, adicione "Microsoft-ServiceFabric:4:0x4000000000000020" à lista de provedores ETW.
"scheduledTransferKeywordFilter": "4611686018427387944"
Nota
Esse canal tem um volume muito alto de eventos, permitindo que a coleta de eventos desse canal detalhado resulte em muitos rastreamentos sendo gerados rapidamente e pode consumir capacidade de armazenamento. Só ligue se for absolutamente necessário.
Para habilitar o Canal Operacional Base nossa recomendação para registro abrangente com a menor quantidade de ruído, O WadCfgEtwManifestProviderConfiguration no do seu modelo seria parecido com o seguinte:
"WadCfg": {
"DiagnosticMonitorConfiguration": {
"overallQuotaInMB": "50000",
"EtwProviders": {
"EtwEventSourceProviderConfiguration": [
{
"provider": "Microsoft-ServiceFabric-Actors",
"scheduledTransferKeywordFilter": "1",
"scheduledTransferPeriod": "PT5M",
"DefaultEvents": {
"eventDestination": "ServiceFabricReliableActorEventTable"
}
},
{
"provider": "Microsoft-ServiceFabric-Services",
"scheduledTransferPeriod": "PT5M",
"DefaultEvents": {
"eventDestination": "ServiceFabricReliableServiceEventTable"
}
}
],
"EtwManifestProviderConfiguration": [
{
"provider": "cbd93bc2-71e5-4566-b3a7-595d8eeca6e8",
"scheduledTransferLogLevelFilter": "Information",
"scheduledTransferKeywordFilter": "4611686018427387904",
"scheduledTransferPeriod": "PT5M",
"DefaultEvents": {
"eventDestination": "ServiceFabricSystemEventTable"
}
},
{
"provider": "02d06793-efeb-48c8-8f7f-09713309a810",
"scheduledTransferLogLevelFilter": "Information",
"scheduledTransferKeywordFilter": "4611686018427387904",
"scheduledTransferPeriod": "PT5M",
"DefaultEvents": {
"eventDestination": "ServiceFabricSystemEventTable"
}
}
]
}
}
},
Coletar de novos canais EventSource
Para atualizar o Diagnóstico para coletar logs de novos canais EventSource que representam um novo aplicativo que você está prestes a implantar, execute as mesmas etapas descritas anteriormente para a configuração do Diagnóstico para um cluster existente.
Atualize a seção no arquivo template.json para adicionar entradas para os novos canais EventSource antes de aplicar a EtwEventSourceProviderConfiguration atualização de configuração usando o New-AzResourceGroupDeployment comando PowerShell. O nome da fonte de evento é definido como parte do seu código no arquivo ServiceEventSource.cs gerado pelo Visual Studio.
Por exemplo, se a fonte do evento for chamada My-Eventsource, adicione o código a seguir para colocar os eventos de My-Eventsource em uma tabela chamada MyDestinationTableName.
{
"provider": "My-Eventsource",
"scheduledTransferPeriod": "PT5M",
"DefaultEvents": {
"eventDestination": "MyDestinationTableName"
}
}
Para coletar contadores de desempenho ou logs de eventos, modifique o modelo do Gerenciador de Recursos usando os exemplos fornecidos em Criar uma máquina virtual do Windows com monitoramento e diagnóstico usando um modelo do Azure Resource Manager. Em seguida, publique novamente o modelo do Gerenciador de Recursos.
Coletar contadores de desempenho
Para coletar métricas de desempenho do cluster, adicione os contadores de desempenho ao "WadCfg > DiagnosticMonitorConfiguration" no modelo do Gerenciador de Recursos do cluster. Consulte Monitoramento de desempenho com WAD para obter etapas sobre como modificar seu WadCfg para coletar contadores de desempenho específicos. Contadores de Desempenho do Service Fabric de referência para obter uma lista de contadores de desempenho que recomendamos coletar.
Se você estiver usando um coletor do Application Insights, conforme descrito na seção abaixo, e quiser que essas métricas apareçam no Application Insights, certifique-se de adicionar o nome do coletor na seção "coletores", conforme mostrado acima. Isso enviará automaticamente os contadores de desempenho configurados individualmente para seu recurso do Application Insights.
Enviar logs para o Application Insights
Configurando o Application Insights com o WAD
Nota
No momento, isso só é aplicável a clusters do Windows.
Há duas maneiras principais de enviar dados do WAD para o Azure Application Insights, o que é obtido adicionando um coletor do Application Insights à configuração do WAD, por meio do portal do Azure ou por meio de um modelo do Azure Resource Manager.
Adicionar uma chave de instrumentação do Application Insights ao criar um cluster no portal do Azure
Ao criar um cluster, se o Diagnóstico estiver ativado, será exibido um campo opcional para inserir uma chave de instrumentação do Application Insights. Se você colar sua chave do Application Insights aqui, o coletor do Application Insights será configurado automaticamente para você no modelo do Gerenciador de Recursos usado para implantar seu cluster.
Adicionar o coletor do Application Insights ao modelo do Resource Manager
No "WadCfg" do modelo do Gerenciador de Recursos, adicione um "Coletor" incluindo as duas alterações a seguir:
Adicione a configuração do coletor diretamente após a
DiagnosticMonitorConfigurationconclusão da declaração:"SinksConfig": { "Sink": [ { "name": "applicationInsights", "ApplicationInsights": "***ADD INSTRUMENTATION KEY HERE***" } ] }Inclua o Sink no
DiagnosticMonitorConfigurationadicionando a seguinte linha noDiagnosticMonitorConfigurationde (logo antes doWadCfgEtwProviderssão declarados):"sinks": "applicationInsights"
Em ambos os trechos de código anteriores, o nome "applicationInsights" foi usado para descrever o coletor. Isso não é um requisito e, desde que o nome do coletor esteja incluído em "coletores", você pode definir o nome para qualquer cadeia de caracteres.
Atualmente, os logs do cluster aparecem como rastreamentos no visualizador de logs do Application Insights. Como a maioria dos rastreamentos provenientes da plataforma são de nível "Informativo", você também pode considerar alterar a configuração do coletor para enviar apenas logs do tipo "Aviso" ou "Erro". Isso pode ser feito adicionando "Canais" à sua pia, como demonstrado neste artigo.
Nota
Se você usar uma chave incorreta do Application Insights no portal ou no modelo do Resource Manager, terá que alterar manualmente a chave e atualizar o cluster / reimplantá-lo.
Próximos passos
Depois de configurar corretamente o diagnóstico do Azure, você verá dados em suas tabelas de armazenamento dos logs ETW e EventSource. Se você optar por usar logs do Azure Monitor, Kibana ou qualquer outra plataforma de visualização e análise de dados que não esteja configurada diretamente no modelo do Gerenciador de Recursos, certifique-se de configurar a plataforma de sua escolha para ler os dados dessas tabelas de armazenamento. Fazer isso para logs do Azure Monitor é relativamente trivial e é explicado em Análise de eventos e logs. O Application Insights é um caso especial nesse sentido, já que pode ser configurado como parte da configuração da extensão Diagnostics, portanto, consulte o artigo apropriado se você optar por usar IA.
Nota
Atualmente, não há como filtrar ou preparar os eventos que são enviados para a mesa. Se você não implementar um processo para remover eventos da tabela, a tabela continuará a crescer. Atualmente, há um exemplo de um serviço de aliciamento de dados em execução no exemplo do Watchdog, e é recomendável que você escreva um para si mesmo, a menos que haja um bom motivo para armazenar logs além de um período de 30 ou 90 dias.
- Saiba como coletar contadores de desempenho ou logs usando a extensão Diagnóstico
- Análise e visualização de eventos com o Application Insights
- Análise e visualização de eventos com logs do Azure Monitor
- Análise e visualização de eventos com o Application Insights
- Análise e visualização de eventos com logs do Azure Monitor