Monitoramento e diagnóstico no Azure Service Fabric

  • Artigo

Este artigo fornece uma visão geral de monitoramento e diagnóstico do Azure Service Fabric. O monitoramento e o diagnóstico são essenciais para o desenvolvimento, os testes e a implantação de cargas de trabalho em qualquer ambiente. Por exemplo, você pode controlar como seus aplicativos são usados, as ações realizadas pela plataforma do Service Fabric, a utilização de recursos com contadores de desempenho e a integridade geral do seu cluster. Você pode usar essas informações para diagnosticar e corrigir problemas e evitar que eles ocorram no futuro. As próximas seções explicarão brevemente cada área do monitoramento do Service Fabric a ser considerada para as cargas de trabalho de produção.

Observação

Este artigo foi atualizado recentemente para usar o termo logs do Azure Monitor em vez de Log Analytics. Os dados de log ainda são armazenados em um espaço de trabalho do Log Analytics e ainda são coletados e analisados pelo mesmo serviço do Log Analytics. Estamos atualizando a terminologia para refletir melhor a função dos logs no Azure Monitor. Confira as alterações de terminologia do Azure Monitor para obter detalhes.

Monitoramento de aplicativo

O monitoramento de aplicativo controla como os recursos e componentes de um aplicativo estão sendo usados. Você deseja monitorar seus aplicativos para garantir que os problemas que impactam os usuários são capturados. A responsabilidade do monitoramento de aplicativos é dos usuários que desenvolvem um aplicativo e seus serviços, pois depende exclusivamente da lógica de negócios do aplicativo. Monitorar os seus aplicativos pode ser útil nos seguintes cenários:

  • A quantidade de tráfego está enfrentando com o meu aplicativo? - Você precisa dimensionar seus serviços para atender às demandas dos usuários ou resolver um possível gargalo em seu aplicativo?
  • São minhas chamadas de serviço a serviço com êxito e controladas?
  • Quais ações são executadas pelos usuários do meu aplicativo? -Coleta de telemetria pode guiar o desenvolvimento futuro de recursos e melhorar diagnósticos para erros de aplicativo
  • Meu aplicativo está lançando exceções não tratadas?
  • O que está acontecendo dentro dos serviços em execução dentro de Meus contêineres?

A grande novidade sobre monitoramento de aplicativos é que os desenvolvedores podem usar qualquer estrutura que gostariam de uma vez que ele reside dentro do contexto de seu aplicativo e as ferramentas! Você pode aprender mais sobre a solução do Azure para o monitoramento de aplicativos com o Azure Monitor Application Insights em Análise de eventos com o Application Insights. Também temos um tutorial com a maneira configurar isso para aplicativos .NET. Este tutorial aborda como instalar as ferramentas corretas, um exemplo para gravar a telemetria personalizada em seu aplicativo e visualizar o diagnóstico e a telemetria do aplicativo no portal do Azure.

Monitoramento da plataforma (cluster)

Um usuário está no controle sobre qual telemetria é proveniente de seus aplicativos, pois um usuário escreve o código em si, mas o que sobre o diagnóstico da plataforma do Service Fabric? Uma das metas do Service Fabric é manter os aplicativos resilientes a falhas de hardware. Esse objetivo é conseguido por meio da capacidade de serviços de sistema da plataforma para detectar problemas de infraestrutura e rápidas failover de cargas de trabalho para outros nós no cluster. Mas, neste caso específico, 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 veiculação de serviços forem violadas? O Service Fabric fornece diagnósticos para esses e mais para garantir que você seja informado sobre a atividade que ocorre em seu cluster. Alguns cenários de amostra para monitoramento de cluster incluem:

O Service Fabric fornece um conjunto abrangente de eventos fora da caixa. Esses eventos do Service Fabric podem ser acessados por meio do EventStore ou do canal operacional (canal de eventos exposto pela plataforma).

  • Canais de eventos do Service Fabric - No Windows, eventos do Service Fabric estão disponíveis a partir de um único provedor ETW com um conjunto de logLevelKeywordFilters relevante usado para escolher entre os canais Operacional e Dados e Mensagens - é assim que separamos eventos do Service Fabric de saída para serem filtrados conforme necessário. No Linux, todos os eventos do Service Fabric são fornecidos por meio de LTTng e são colocados em uma tabela de Armazenamento, de onde eles podem ser filtrados conforme necessário. Esses canais contém eventos curados e estruturados que podem ser usados para entender melhor o estado do cluster. O Diagnóstico é habilitado por padrão no momento da criação do cluster, que cria uma tabela de Armazenamento do Azure onde os eventos desses canais são enviados para a consulta no futuro.

  • EventStore - o EventStore é um recurso oferecido pela plataforma que fornece eventos de plataforma do Service Fabric disponíveis no Service Fabric Explorer e por meio da API REST. Você pode ver uma exibição de instantâneo do que está acontecendo em seu cluster para cada entidade, por exemplo, nó, serviço, aplicativo e consulta com base na hora do evento. Você também pode ler mais sobre o EventStore na Visão geral do EventStore.

Screenshot shows the EVENTS tab of the Nodes pane several events, including a NodeDown event.

Os diagnósticos fornecidos estão na forma de um conjunto abrangente de eventos prontos para uso. Esses eventos do Service Fabric ilustram ações executadas pela plataforma em entidades diferentes, como Nós, Aplicativos, Serviços, Partições, etc. No último cenário acima, se um nó fosse desativado, 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 nos clusters Windows e Linux.

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

Monitoramento da integridade

A plataforma do Service Fabric inclui um modelo de integridade, que fornece o relatório de integridade extensível para o status de entidades em um cluster. Cada nó, aplicativo, serviço, partição, réplicas ou instância, tem um status de integridade continuamente atualizável. O status de integridade pode ser "OK", "Aviso" ou "Erro". Pense em eventos do Service Fabric como verbos feitos pelo cluster para várias entidades e health como um adjetivo para cada entidade. Cada vez que a integridade de uma determinada entidade transita, um evento também será emitido. Dessa forma, você pode configurar consultas e alertas para eventos de integridade em sua ferramenta de monitoramento escolhida, assim como qualquer outro evento.

Além disso, até permitimos que os usuários substituam a integridade de entidades. Se o seu aplicativo estiver passando por uma atualização e você tiver testes de validação com falha, poderá gravar no Service Fabric Health usando a Health API 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

SFX health dashboard

Watchdogs

Em geral, um watchdog é um serviço separado que inspeciona a integridade e a carga entre serviços, executa ping em pontos de extremidade e relata eventos de integridade inesperados no cluster. Isso pode ajudar a evitar erros que podem não ser detectados com base apenas no desempenho de um único serviço. Os watchdogs também são um bom local para hospedar o código que executa ações corretivas que não exigem a interação do usuário, como limpeza de arquivos de log no armazenamento em determinados intervalos de tempo. Se você quiser um serviço de watchdog SF de software livre totalmente implementado que inclua um modelo de extensibilidade de watchdog 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 nos clusters de teste e produção e estendê-lo para atender às suas necessidades, por meio de seu modelo de plug-in ou com a bifurcação e a criação de seus próprios observadores internos. O primeiro (plug-ins) é a abordagem recomendada.

Monitoramento de infraestrutura (desempenho)

Agora que abordamos os diagnósticos em seu aplicativo e na plataforma, como sabemos se o hardware está funcionando conforme o esperado? Monitoramento de sua infraestrutura subjacente é uma parte importante para compreender o estado do seu cluster e a utilização de recursos. O desempenho do sistema de medição depende de muitos fatores que podem ser subjetivos, dependendo de suas cargas de trabalho. Esses fatores geralmente são medidos por meio de contadores de desempenho. Esses contadores de desempenho podem vir de uma variedade de fontes, incluindo o sistema operacional, o .NET framework ou a própria plataforma do Service Fabric. Alguns cenários em que eles seriam úteis são

  • Eu estou utilizando o meu hardware com eficiência? Você quer usar seu hardware com 90% da CPU ou 10% da CPU. Isso é útil ao dimensionar seu cluster ou otimizar os processos do seu aplicativo.
  • Posso prever problemas de infraestrutura proativamente? - muitos problemas são precedidos por alterações bruscas no desempenho, para que você possa usar contadores de desempenho, como I / O de rede e utilização da CPU, para prever e diagnosticar os problemas de maneira proativa.

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

O Service Fabric também fornece um conjunto de contadores de desempenho para os modelos de programação Reliable Services e Actors. Se você estiver usando um desses modelos, esses contadores de desempenho poderão fornecer informações para garantir que seus atores estejam girando corretamente, ou que suas solicitações de serviço confiáveis sejam tratadas com rapidez suficiente. Para obter mais informações, consulte Monitoramento para comunicação remota do Reliable Service e Monitoramento de desempenho para Reliable Actors.

A solução do Azure Monitor para coletá-las é logs do Azure Monitor, assim como o monitoramento de nível de plataforma. Você deve usar o agente Log Analytics para coletar os contadores de desempenho apropriados e visualizá-los nos logs do Azure Monitor.

Agora que passamos sobre cada área de cenários de monitoramento e exemplo, aqui está um resumo do Azure, ferramentas de monitoramento e configurar necessários para monitorar todas as áreas acima.

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

Outras soluções de registro em log

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

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

Próximas etapas