Monitorar o Azure Service Fabric

Este artigo descreve:

• Os tipos de dados de monitoramento que você pode coletar para este serviço.
• Formas de analisar esses dados.

Nota

Se já estiver familiarizado com este serviço e/ou Azure Monitor e quiser apenas saber como analisar dados de monitorização, consulte a secção Analisar perto do final deste artigo.

Quando você tem aplicativos críticos e processos de negócios que dependem de recursos do Azure, você precisa monitorar e receber alertas para seu sistema. O serviço Azure Monitor coleta e agrega métricas e logs de cada componente do seu sistema. O Azure Monitor fornece uma exibição de disponibilidade, desempenho e resiliência e notifica você sobre problemas. Você pode usar o portal do Azure, PowerShell, CLI do Azure, API REST ou bibliotecas de cliente para configurar e exibir dados de monitoramento.

• Para obter mais informações sobre o Azure Monitor, consulte a visão geral do Azure Monitor.
• Para obter mais informações sobre como monitorar os recursos do Azure em geral, consulte Monitorar recursos do Azure com o Azure Monitor.

Monitoramento do Azure Service Fabric

O Azure Service Fabric tem as seguintes camadas que você pode monitorar:

• Monitoramento de aplicativos: os aplicativos que são executados nos nós. Você pode monitorar aplicativos com a chave do Application Insights ou SDK, EventStore ou log do ASP.NET Core.
• Monitoramento de plataforma (cluster): métricas de cliente, logs e eventos para a plataforma ou nós de cluster, incluindo métricas de contêiner. As métricas e logs são diferentes para nós Linux ou Windows.
• Monitoramento de infraestrutura (desempenho): contadores de integridade e desempenho do serviço para a infraestrutura de serviço.

Você pode monitorar como seus aplicativos são usados, as ações tomadas pela plataforma Service Fabric, sua utilização de recursos com contadores de desempenho e a integridade geral do cluster. Os logs do Azure Monitor e o Application Insights oferecem integração interna com o Service Fabric.

• Para saber mais sobre as práticas recomendadas, consulte Monitoramento e práticas recomendadas de diagnóstico para o Azure Service Fabric.
• Para obter um tutorial que mostra como exibir eventos e relatórios de integridade do Service Fabric, consultar as APIs do EventStore e monitorar contadores de desempenho, consulte Tutorial: Monitorar um cluster do Service Fabric no Azure.
• Para saber como configurar os logs do Azure Monitor para monitorar seus contêineres do Windows orquestrados no Service Fabric, consulte Tutorial: Monitorar contêineres do Windows no Service Fabric usando logs do Azure Monitor.

Service Fabric Explorer

O Service Fabric Explorer, um aplicativo de área de trabalho para Windows, macOS e Linux, é uma ferramenta de código aberto para inspecionar e gerenciar clusters do Azure Service Fabric. Para habilitar a automação, todas as ações que podem ser executadas por meio do Service Fabric Explorer também podem ser feitas por meio do PowerShell ou de uma API REST.

Monitorização da aplicação

O monitoramento de aplicativos rastreia como os recursos e componentes do seu aplicativo estão sendo usados. Você deseja monitorar seus aplicativos para garantir que os problemas que afetam os usuários sejam detetados. A responsabilidade do monitoramento de aplicativos é dos usuários que desenvolvem um aplicativo e seus serviços, uma vez que ele é exclusivo para a lógica de negócios do seu aplicativo. O monitoramento de seus aplicativos pode ser útil nos seguintes cenários:

• Quanto tráfego meu aplicativo está enfrentando? - Você precisa dimensionar seus serviços para atender às demandas dos usuários ou resolver um possível gargalo em seu aplicativo?
• Minhas chamadas de serviço a serviço são bem-sucedidas e rastreadas?
• Que ações são tomadas pelos utilizadores da minha aplicação? - A coleta de telemetria pode orientar o desenvolvimento futuro de recursos e melhores diagnósticos para erros de aplicativos
• Meu aplicativo está lançando exceções não tratadas?
• O que está acontecendo nos serviços executados dentro dos meus contêineres?

A melhor coisa sobre o monitoramento de aplicativos é que os desenvolvedores podem usar quaisquer ferramentas e estruturas que desejarem, uma vez que ele vive dentro do contexto do seu aplicativo! Você pode saber mais sobre a solução do Azure para monitoramento de aplicativos com o Azure Monitor Application Insights em Análise de eventos com o Application Insights.

Também temos um tutorial sobre como configurar isso para aplicativos .NET. Este tutorial aborda como instalar as ferramentas certas, um exemplo para escrever telemetria personalizada em seu aplicativo e exibir o diagnóstico e a telemetria do aplicativo no portal do Azure.

Registo de aplicação

Instrumentar seu código não é apenas uma maneira de obter insights sobre seus usuários, mas também a única maneira de saber se algo está errado em seu aplicativo e diagnosticar o que precisa ser corrigido. Embora tecnicamente seja possível conectar um depurador a um serviço de produção, não é uma prática comum. Por isso, ter dados detalhados de instrumentação é importante.

Alguns produtos instrumentam automaticamente o seu código. Embora essas soluções possam funcionar bem, a instrumentação manual é quase sempre necessária para ser específica para sua lógica de negócios. No final, você deve ter informações suficientes para depurar forense o aplicativo. Os aplicativos do Service Fabric podem ser instrumentados com qualquer estrutura de log. Esta seção descreve algumas abordagens diferentes para instrumentar seu código e quando escolher uma abordagem em vez de outra.

• SDK do Application Insights: o Application Insights tem uma integração avançada com o Service Fabric pronta para uso. Os usuários podem adicionar os pacotes nuget do AI Service Fabric e receber dados e logs criados e coletados visíveis no portal do Azure. Além disso, os usuários são incentivados a adicionar sua própria telemetria para diagnosticar e depurar seus aplicativos e rastrear quais serviços e partes de seus aplicativos são mais usados. A classe TelemetryClient no SDK fornece muitas maneiras de controlar a telemetria em seus aplicativos. Para obter mais informações, consulte Análise e visualização de eventos com o Application Insights.

  Confira um exemplo de como instrumentar e adicionar insights de aplicativos ao seu aplicativo em nosso tutorial para monitorar e diagnosticar um aplicativo .NET.

• EventSource: Quando você cria uma solução do Service Fabric a partir de um modelo no Visual Studio, uma classe derivada de EventSource (ServiceEventSource ou ActorEventSource) é gerada. Um modelo é criado, no qual você pode adicionar eventos para seu aplicativo ou serviço. O nome EventSource deve ser exclusivo e deve ser renomeado a partir da cadeia de caracteres de modelo padrão MyCompany-solution-project<>><. Ter várias definições de EventSource que usam o mesmo nome causa um problema em tempo de execução. Cada evento definido deve ter um identificador exclusivo. Se um identificador não for exclusivo, ocorrerá uma falha de tempo de execução. Algumas organizações pré-atribuem intervalos de valores para identificadores para evitar conflitos entre equipes de desenvolvimento separadas. Para obter mais informações, consulte o blog de Vance ou a documentação do MSDN.

• ASP.NET Registro principal: é importante planejar cuidadosamente como você instrumentará seu código. O plano de instrumentação correto pode ajudá-lo a evitar potencialmente desestabilizar sua base de código e, em seguida, precisar reinstrumentar o código. Para reduzir o risco, você pode escolher uma biblioteca de instrumentação como Microsoft.Extensions.Logging, que faz parte do Microsoft ASP.NET Core. ASP.NET Core tem uma interface ILogger que você pode usar com o provedor de sua escolha, minimizando o efeito no código existente. Você pode usar o código no ASP.NET Core no Windows e Linux e no .NET Framework completo, para que seu código de instrumentação seja padronizado.

Para obter exemplos sobre como usar essas sugestões, consulte Adicionar log ao seu aplicativo do Service Fabric.

Monitorização da plataforma (cluster)

Um usuário tem controle sobre qual telemetria vem de seu aplicativo, já que um usuário escreve o próprio código, mas e os diagnósticos da plataforma Service Fabric? Um dos objetivos do Service Fabric é manter os aplicativos resilientes a falhas de hardware. Esse objetivo é alcançado por meio da capacidade dos serviços de sistema da plataforma de detetar problemas de infraestrutura e fazer failover rápido de cargas de trabalho para outros nós no cluster. Mas neste caso em particular, e se os próprios serviços do sistema tiverem problemas? Ou se, ao tentar implantar ou mover uma carga de trabalho, as regras para a colocação de serviços forem violadas? O Service Fabric fornece diagnósticos para esses e outros para garantir que você esteja informado sobre a atividade que está ocorrendo em seu cluster. Alguns cenários de exemplo para monitoramento de cluster incluem:

Para obter mais informações sobre o monitoramento de plataforma (cluster), consulte Monitorando o cluster.

Eventos do Service Fabric

O Service Fabric fornece um conjunto abrangente de eventos de diagnóstico prontos para uso, que você pode acessar por meio da EventStore ou do canal de eventos operacionais que a plataforma expõe. Esses eventos do Service Fabric ilustram ações realizadas pela plataforma em diferentes entidades, como nós, aplicativos, serviços e partições. Os mesmos eventos estão disponíveis em clusters Windows e Linux.

• Canais de eventos do Service Fabric: no Windows, os eventos do Service Fabric estão disponíveis em um único provedor ETW com um conjunto de canais relevantes logLevelKeywordFilters usados para escolher entre os canais Operacional e de Dados & Mensagens. Essa é a maneira pela qual separamos os eventos de saída do Service Fabric para serem filtrados conforme necessário. No Linux, os eventos do Service Fabric vêm por meio do LTTng e são colocados em uma tabela de armazenamento, de onde podem ser filtrados conforme necessário. Esses canais contêm eventos estruturados com curadoria que podem ser usados para entender melhor o estado do cluster. Os diagnósticos são habilitados por padrão no momento da criação do cluster, que cria uma tabela de Armazenamento do Azure para que os eventos desses canais sejam enviados para você consultar no futuro.

• EventStore é um recurso que mostra eventos da plataforma do Service Fabric no Service Fabric Explorer e programaticamente por meio da API REST da Biblioteca do Cliente do Service Fabric. Você pode ver uma exibição instantânea do que está acontecendo em seu cluster para cada nó, serviço e aplicativo e consultar com base na hora do evento. As APIs da EventStore estão disponíveis apenas para clusters do Windows em execução no Azure. Em máquinas Windows, esses eventos são alimentados no Log de Eventos, para que você possa ver Eventos do Service Fabric no Visualizador de Eventos.

Os diagnósticos fornecidos são na forma de um conjunto abrangente de eventos prontos para uso. Esses eventos do Service Fabric ilustram ações realizadas pela plataforma em diferentes entidades, como nós, aplicativos, serviços, partições etc. No último cenário acima, se um nó caísse, a plataforma emitiria um NodeDown evento e você poderia ser notificado imediatamente pela ferramenta de monitoramento de sua escolha. Outros exemplos comuns incluem ApplicationUpgradeRollbackStarted ou PartitionReconfigured durante um failover. Os mesmos eventos estão disponíveis em clusters Windows e Linux.

Os eventos são enviados através de canais padrão no Windows e Linux e podem ser lidos por qualquer ferramenta de monitoramento que os suporte. A solução do Azure Monitor são os logs do Azure Monitor. Sinta-se à vontade para ler mais sobre nossa integração de logs do Azure Monitor, que inclui um painel operacional personalizado para seu cluster e algumas consultas de exemplo a partir das quais você pode criar alertas. Mais conceitos de monitoramento de cluster estão disponíveis na geração de eventos e logs no nível da plataforma.

Monitorização do estado de funcionamento

A plataforma do Service Fabric inclui um modelo de integridade, que fornece relatórios de integridade extensíveis para o status de entidades em um cluster. Cada nó, aplicativo, serviço, partição, réplica ou instância tem um status de integridade atualizável continuamente. O estado de funcionamento pode ser "OK", "Aviso" ou "Erro". Pense em eventos do Service Fabric como verbos feitos pelo cluster para várias entidades e saúde como um adjetivo para cada entidade. Cada vez que a integridade de uma determinada entidade transita, um evento também será emitido. Desta forma, pode configurar consultas e alertas para eventos de saúde na sua ferramenta de monitorização preferida, tal como qualquer outro evento.

Além disso, permitimos que os usuários substituam a integridade por entidades. Se seu aplicativo estiver passando por uma atualização e você tiver testes de validação falhando, você poderá gravar na Integridade do Service Fabric usando a API de Integridade para indicar que seu aplicativo não está mais íntegro e o Service Fabric reverterá automaticamente a atualização! Para obter mais informações sobre o modelo de integridade, confira a introdução ao monitoramento de integridade do Service Fabric

Cães de guarda

Geralmente, um cão de guarda é um serviço separado que monitora a integridade e a carga entre serviços, pings de pontos de extremidade e relata eventos de integridade inesperados no cluster. Isso pode ajudar a evitar erros que podem não ser detetados com base apenas no desempenho de um único serviço. Os vigilantes também são um bom lugar para hospedar código que executa ações corretivas que não exigem interação do usuário, como limpar arquivos de log no armazenamento em determinados intervalos de tempo. Se você quiser um serviço de vigilância SF de código aberto totalmente implementado que inclua um modelo de extensibilidade de cão de guarda fácil de usar e que seja executado em clusters Windows e Linux, consulte o projeto FabricObserver . O FabricObserver é um software pronto para produção. Incentivamos você a implantar o FabricObserver em seus clusters de teste e produção e estendê-lo para atender às suas necessidades, seja por meio de seu modelo de plug-in ou forjando-o e escrevendo seus próprios observadores integrados. O primeiro (plug-ins) é a abordagem recomendada.

Monitorização da infraestrutura (desempenho)

Agora que já abordamos os diagnósticos em seu aplicativo e na plataforma, como sabemos que o hardware está funcionando conforme o esperado? O monitoramento da infraestrutura subjacente é uma parte fundamental para entender o estado do cluster e a utilização dos recursos. A medição do desempenho do sistema depende de muitos fatores que podem ser subjetivos dependendo de suas cargas de trabalho. Estes fatores são normalmente medidos através de contadores de desempenho. Esses contadores de desempenho podem vir de várias fontes, incluindo o sistema operacional, o .NET Framework ou a própria plataforma Service Fabric. Alguns cenários em que seriam úteis são:

• Estou a utilizar o meu hardware de forma eficiente? Você deseja usar seu hardware em 90% CPU ou 10% CPU. Isso é útil ao dimensionar o cluster ou otimizar os processos do aplicativo.
• Posso prever problemas de infraestrutura de forma proativa? - muitos problemas são precedidos por mudanças repentinas (quedas) no desempenho, para que você possa usar contadores de desempenho, como E/S de rede e utilização da CPU para prever e diagnosticar os problemas proativamente.

Uma lista de contadores de desempenho que devem ser coletados no nível da infraestrutura pode ser encontrada em Métricas de desempenho.

Os Logs do Azure Monitor são recomendados para monitorar eventos no nível do cluster. Depois de configurar o agente do Log Analytics com seu espaço de trabalho, você pode coletar:

• Métricas de desempenho, como utilização da CPU.
• Contadores de desempenho .NET, como utilização da CPU no nível do processo.
• Contadores de desempenho do Service Fabric, como o número de exceções de um serviço confiável.
• Métricas de contêiner, como utilização da CPU.

Tipos de recursos

O Azure usa o conceito de tipos de recursos e IDs para identificar tudo em uma assinatura. Os tipos de recursos também fazem parte das IDs de recursos para cada recurso em execução no Azure. Por exemplo, um tipo de recurso para uma máquina virtual é Microsoft.Compute/virtualMachines. Para obter uma lista de serviços e seus tipos de recursos associados, consulte Provedores de recursos.

O Azure Monitor organiza de forma semelhante os principais dados de monitoramento em métricas e logs com base em tipos de recursos, também chamados de namespaces. Diferentes métricas e logs estão disponíveis para diferentes tipos de recursos. Seu serviço pode estar associado a mais de um tipo de recurso.

Para obter mais informações sobre os tipos de recursos para o Azure Service Fabric, consulte Referência de dados de monitoramento do Service Fabric.

Armazenamento de dados

Para o Azure Monitor:

• Os dados de métricas são armazenados no banco de dados de métricas do Azure Monitor.
• Os dados de log são armazenados no repositório de logs do Azure Monitor. O Log Analytics é uma ferramenta no portal do Azure que pode consultar este armazenamento.
• O log de atividades do Azure é um repositório separado com sua própria interface no portal do Azure.

Opcionalmente, você pode rotear dados de métricas e logs de atividades para o repositório de logs do Azure Monitor. Em seguida, você pode usar o Log Analytics para consultar os dados e correlacioná-los com outros dados de log.

Muitos serviços podem usar configurações de diagnóstico para enviar dados de métrica e log para outros locais de armazenamento fora do Azure Monitor. Os exemplos incluem o Armazenamento do Azure, sistemas de parceiros hospedados e sistemas de parceiros que não são do Azure, usando Hubs de Eventos.

Para obter informações detalhadas sobre como o Azure Monitor armazena dados, consulte Plataforma de dados do Azure Monitor.

Métricas da plataforma Azure Monitor

O Azure Monitor fornece métricas de plataforma para muitos serviços. Para obter uma lista de todas as métricas que é possível reunir para todos os recursos no Azure Monitor, consulte Métricas suportadas no Azure Monitor.

Este serviço não reúne métricas da plataforma.

Métricas não baseadas no Azure Monitor

Este serviço fornece outras métricas que não estão incluídas no banco de dados de métricas do Azure Monitor.

Métricas do SO convidado

As métricas do sistema operacional convidado (SO) executado em nós de cluster do Service Fabric devem ser coletadas por meio de um ou mais agentes executados no sistema operacional convidado. As métricas do SO convidado incluem contadores de desempenho que rastreiam a porcentagem da CPU convidada ou o uso da memória, ambos frequentemente usados para dimensionamento automático ou alertas.

Uma prática recomendada é usar e configurar o agente do Azure Monitor para enviar métricas de desempenho do SO convidado por meio da API de métricas personalizadas para o banco de dados de métricas do Azure Monitor. Você pode enviar as métricas do SO convidado para os Logs do Azure Monitor usando o mesmo agente. Em seguida, você pode consultar essas métricas e logs usando o Log Analytics.

Nota

O agente do Azure Monitor substitui a extensão de Diagnóstico do Azure e o agente do Log Analytics para roteamento de SO convidado. Para obter mais informações, consulte Visão geral dos agentes do Azure Monitor.

Logs de recursos do Azure Monitor

Os logs de recursos fornecem informações sobre operações que foram feitas por um recurso do Azure. Os logs são gerados automaticamente, mas você deve roteá-los para os Logs do Azure Monitor para salvá-los ou consultá-los. Os logs são organizados em categorias. Um determinado namespace pode ter várias categorias de log de recursos que você pode coletar.

Esse serviço não coleta logs de recursos, mas você pode encontrar informações sobre eles em Monitoramento de dados de recursos do Azure.

Logs e eventos do Service Fabric

O Service Fabric pode coletar os seguintes logs:

• Para clusters do Windows, você pode configurar o monitoramento de cluster com os logs do Agente de Diagnóstico e do Azure Monitor.
• Para clusters Linux, o Azure Monitor Logs também é a ferramenta recomendada para monitoramento de infraestrutura e plataforma do Azure. O diagnóstico da plataforma Linux requer configurações diferentes. Para obter mais informações, consulte Eventos de cluster do Service Fabric Linux no Syslog.
• Você pode configurar o agente do Azure Monitor para enviar logs do sistema operacional convidado para os Logs do Azure Monitor, onde você pode consultá-los usando o Log Analytics.
• Você pode gravar logs de contêiner do Service Fabric em stdout ou stderr para que estejam disponíveis nos Logs do Azure Monitor.
• Você pode configurar a solução de monitoramento de contêiner para Logs do Azure Monitor para exibir eventos de contêiner.

Outras soluções de registo

Embora as duas soluções recomendadas, logs do Azure Monitor e Application Insights, tenham incorporado a integração com o Service Fabric, muitos eventos são gravados por meio de provedores ETW e são extensíveis com outras soluções de log. Você também deve examinar o Elastic Stack (especialmente se estiver considerando executar um cluster em um ambiente offline), o Dynatrace ou qualquer outra plataforma de sua preferência. Para obter uma lista de parceiros integrados, consulte Parceiros de monitoramento do Azure Service Fabric.

Os pontos-chave para qualquer plataforma que você escolher devem incluir o quão confortável você está com a interface do usuário, os recursos de consulta, as visualizações personalizadas e painéis disponíveis e as ferramentas adicionais que eles fornecem para melhorar sua experiência de monitoramento.

Registo de atividades do Azure

O log de atividades contém eventos no nível de assinatura que rastreiam as operações para cada recurso do Azure visto de fora desse recurso; por exemplo, criar um novo recurso ou iniciar uma máquina virtual.

Coleção: os eventos do log de atividades são gerados e coletados automaticamente em um repositório separado para exibição no portal do Azure.

Roteamento: você pode enviar dados de log de atividades para os Logs do Azure Monitor para analisá-los junto com outros dados de log. Outros locais, como o Armazenamento do Azure, Hubs de Eventos do Azure e determinados parceiros de monitoramento da Microsoft também estão disponíveis. Para obter mais informações sobre como rotear o log de atividades, consulte Visão geral do log de atividades do Azure.

Analise os dados de monitoramento

Existem muitas ferramentas para analisar dados de monitoramento.

Ferramentas do Azure Monitor

O Azure Monitor dá suporte às seguintes ferramentas básicas:

• Explorador de métricas, uma ferramenta no portal do Azure que permite exibir e analisar métricas para recursos do Azure. Para obter mais informações, consulte Analisar métricas com o explorador de métricas do Azure Monitor.

• Log Analytics, uma ferramenta no portal do Azure que permite consultar e analisar dados de log usando a linguagem de consulta Kusto (KQL). Para obter mais informações, consulte Introdução às consultas de log no Azure Monitor.

• O log de atividades, que tem uma interface de usuário no portal do Azure para exibição e pesquisas básicas. Para fazer uma análise mais aprofundada, você precisa rotear os dados para os logs do Azure Monitor e executar consultas mais complexas no Log Analytics.

As ferramentas que permitem uma visualização mais complexa incluem:

• Painéis que permitem combinar diferentes tipos de dados em um único painel no portal do Azure.
• Pastas de trabalho, relatórios personalizáveis que você pode criar no portal do Azure. As pastas de trabalho podem incluir texto, métricas e consultas de log.
• Grafana, uma ferramenta de plataforma aberta que se destaca em dashboards operacionais. Você pode usar o Grafana para criar painéis que incluem dados de várias fontes diferentes do Azure Monitor.
• Power BI, um serviço de análise de negócios que fornece visualizações interativas em várias fontes de dados. Você pode configurar o Power BI para importar automaticamente dados de log do Azure Monitor para aproveitar essas visualizações.

Para obter uma visão geral dos cenários comuns de análise de monitoramento do Service Fabric, consulte Diagnosticar cenários comuns com o Service Fabric.

Ferramentas de exportação do Azure Monitor

Você pode obter dados do Azure Monitor para outras ferramentas usando os seguintes métodos:

• Métricas: use a API REST para métricas para extrair dados de métricas do banco de dados de métricas do Azure Monitor. A API suporta expressões de filtro para refinar os dados recuperados. Para obter mais informações, consulte Referência da API REST do Azure Monitor.

• Logs: use a API REST ou as bibliotecas de cliente associadas.

• Outra opção é a exportação de dados do espaço de trabalho.

Para começar a usar a API REST para o Azure Monitor, consulte Passo a passo da API REST de monitoramento do Azure.

Consultas do Kusto

Você pode analisar dados de monitoramento no repositório Azure Monitor Logs / Log Analytics usando a linguagem de consulta Kusto (KQL).

Importante

Quando você seleciona Logs no menu do serviço no portal, o Log Analytics é aberto com o escopo da consulta definido para o serviço atual. Esse escopo significa que as consultas de log incluirão apenas dados desse tipo de recurso. Se quiser executar uma consulta que inclua dados de outros serviços do Azure, selecione Logs no menu Azure Monitor . Consulte Escopo e intervalo de tempo da consulta de log no Azure Monitor Log Analytics para obter detalhes.

Para obter uma lista de consultas comuns para qualquer serviço, consulte a interface de consultas do Log Analytics.

Consultas de amostra

As consultas a seguir retornam eventos do Service Fabric, incluindo ações em nós. Para outras consultas úteis, consulte Eventos do Service Fabric.

Eventos operacionais de retorno registrados na última hora:

ServiceFabricOperationalEvent
| where TimeGenerated > ago(1h)
| join kind=leftouter ServiceFabricEvent on EventId
| project EventId, EventName, TaskName, Computer, ApplicationName, EventMessage, TimeGenerated
| sort by TimeGenerated

Retornar relatórios de integridade com HealthState == 3 (erro) e extrair mais propriedades do EventMessage campo:

ServiceFabricOperationalEvent
| join kind=leftouter ServiceFabricEvent on EventId
| extend HealthStateId = extract(@"HealthState=(\S+) ", 1, EventMessage, typeof(int))
| where TaskName == 'HM' and HealthStateId == 3
| extend SourceId = extract(@"SourceId=(\S+) ", 1, EventMessage, typeof(string)),
         Property = extract(@"Property=(\S+) ", 1, EventMessage, typeof(string)),
         HealthState = case(HealthStateId == 0, 'Invalid', HealthStateId == 1, 'Ok', HealthStateId == 2, 'Warning', HealthStateId == 3, 'Error', 'Unknown'),
         TTL = extract(@"TTL=(\S+) ", 1, EventMessage, typeof(string)),
         SequenceNumber = extract(@"SequenceNumber=(\S+) ", 1, EventMessage, typeof(string)),
         Description = extract(@"Description='([\S\s, ^']+)' ", 1, EventMessage, typeof(string)),
         RemoveWhenExpired = extract(@"RemoveWhenExpired=(\S+) ", 1, EventMessage, typeof(bool)),
         SourceUTCTimestamp = extract(@"SourceUTCTimestamp=(\S+)", 1, EventMessage, typeof(datetime)),
         ApplicationName = extract(@"ApplicationName=(\S+) ", 1, EventMessage, typeof(string)),
         ServiceManifest = extract(@"ServiceManifest=(\S+) ", 1, EventMessage, typeof(string)),
         InstanceId = extract(@"InstanceId=(\S+) ", 1, EventMessage, typeof(string)),
         ServicePackageActivationId = extract(@"ServicePackageActivationId=(\S+) ", 1, EventMessage, typeof(string)),
         NodeName = extract(@"NodeName=(\S+) ", 1, EventMessage, typeof(string)),
         Partition = extract(@"Partition=(\S+) ", 1, EventMessage, typeof(string)),
         StatelessInstance = extract(@"StatelessInstance=(\S+) ", 1, EventMessage, typeof(string)),
         StatefulReplica = extract(@"StatefulReplica=(\S+) ", 1, EventMessage, typeof(string))

Obtenha eventos operacionais do Service Fabric agregados ao serviço e ao nó específicos:

ServiceFabricOperationalEvent
| where ApplicationName  != "" and ServiceName != ""
| summarize AggregatedValue = count() by ApplicationName, ServiceName, Computer 

Alertas

Os alertas do Azure Monitor notificam proativamente quando condições específicas são encontradas em seus dados de monitoramento. Os alertas permitem-lhe identificar e resolver problemas no seu sistema antes que os seus clientes os percebam. Para obter mais informações, consulte Alertas do Azure Monitor.

Há muitas fontes de alertas comuns para recursos do Azure. Para obter exemplos de alertas comuns para recursos do Azure, consulte Consultas de alerta de log de exemplo. O site Azure Monitor Baseline Alerts (AMBA) fornece um método semiautomatizado de implementação de alertas métricos de plataforma, painéis e diretrizes importantes. O site aplica-se a um subconjunto em contínua expansão dos serviços do Azure, incluindo todos os serviços que fazem parte da Zona de Aterragem do Azure (ALZ).

O esquema de alerta comum padroniza o consumo de notificações de alerta do Azure Monitor. Para obter mais informações, consulte Esquema de alerta comum.

Tipos de alertas

Você pode alertar sobre qualquer fonte de dados de métrica ou log na plataforma de dados do Azure Monitor. Há muitos tipos diferentes de alertas, dependendo dos serviços que você está monitorando e dos dados de monitoramento que você está coletando. Diferentes tipos de alertas têm vários benefícios e desvantagens. Para obter mais informações, consulte Escolher o tipo de alerta de monitoramento correto.

A lista a seguir descreve os tipos de alertas do Azure Monitor que você pode criar:

• Os alertas métricos avaliam as métricas de recursos em intervalos regulares. As métricas podem ser métricas de plataforma, métricas personalizadas, logs do Azure Monitor convertidos em métricas ou métricas do Application Insights. Os alertas métricos também podem aplicar várias condições e limites dinâmicos.
• Os alertas de log permitem que os usuários usem uma consulta do Log Analytics para avaliar logs de recursos em uma frequência predefinida.
• Os alertas do log de atividades são acionados quando ocorre um novo evento do log de atividades que corresponde às condições definidas. Os alertas de Integridade do Recurso e os alertas de Integridade do Serviço são alertas de log de atividades que relatam a integridade do serviço e do recurso.

Alguns serviços do Azure também suportam alertas de deteção inteligente, alertas Prometheus ou regras de alerta recomendadas.

Para alguns serviços, você pode monitorar em escala aplicando a mesma regra de alerta de métrica a vários recursos do mesmo tipo que existem na mesma região do Azure. Notificações individuais são enviadas para cada recurso monitorado. Para serviços e nuvens do Azure com suporte, consulte Monitorar vários recursos com uma regra de alerta.

Regras de alerta do Service Fabric

A tabela a seguir lista algumas regras de alerta para o Service Fabric. Estes alertas são apenas exemplos. Você pode definir alertas para qualquer métrica, entrada de log ou entrada de log de atividades listada na referência de dados de monitoramento do Service Fabric ou na Lista de eventos do Service Fabric.

Tipo de alerta	Condição	Description
Evento do nó	Nó desce	ServiceFabricOperationalEvent onde EventID >= 25622 e EventID <= 25626. Essas IDs de evento são encontradas na referência de eventos de nó.
Evento de candidatura	Reversão de atualização de aplicativo	ServiceFabricOperationalEvent onde EventID == 29623 ou EventID == 29624. Essas IDs de evento são encontradas na referência de eventos do aplicativo.
Estado de funcionamento de recursos	Serviço de atualização inacessível/indisponível	O cluster vai para o estado UpgradeServiceUnreachable.

Recomendações do assistente

Para alguns serviços, se ocorrerem condições críticas ou alterações iminentes durante as operações de recursos, será exibido um alerta na página Visão geral do serviço no portal. Você pode encontrar mais informações e correções recomendadas para o alerta em Recomendações do Advisor em Monitoramento no menu à esquerda. Durante as operações normais, nenhuma recomendação do consultor é exibida.

Para obter mais informações sobre o Azure Advisor, consulte Visão geral do Azure Advisor.

Configuração recomendada

Agora que analisamos cada área de monitoramento e cenários de exemplo, aqui está um resumo das ferramentas de monitoramento do Azure e da configuração necessária para monitorar todas as áreas acima.

• Monitoramento de aplicativos com o Application Insights
• Monitoramento de cluster com logs do Agente de Diagnóstico e do Azure Monitor
• Monitoramento de infraestrutura com logs do Azure Monitor

Você também pode usar e modificar o modelo ARM de exemplo para automatizar a implantação de todos os recursos e agentes necessários.

Conteúdos relacionados

• Consulte Referência de dados de monitoramento do Service Fabric para obter uma referência das métricas, logs e outros valores importantes criados para o Service Fabric.
• Consulte Monitorando recursos do Azure com o Azure Monitor para obter detalhes gerais sobre o monitoramento de recursos do Azure.
• Consulte a Lista de eventos do Service Fabric.