Monitorização do cluster

  • Artigo

É importante monitorar no nível do cluster para determinar se o hardware e o cluster estão se comportando conforme o esperado. Embora o Service Fabric possa manter os aplicativos em execução durante uma falha de hardware, você ainda precisa diagnosticar se um erro está ocorrendo em um aplicativo ou na infraestrutura subjacente. Você também deve monitorar seus clusters para planejar melhor a capacidade, ajudando nas decisões sobre como adicionar ou remover hardware.

O Service Fabric expõe vários eventos de plataforma estruturados, como eventos do Service Fabric, por meio da EventStore e de vários canais de log prontos para uso.

No Windows, os eventos do Service Fabric estão disponíveis em um único provedor ETW com um conjunto de relevantes usados para escolher entre os canais Operacional e de Dados & Mensagens - essa é a maneira pela qual separamos os eventos de saída do logLevelKeywordFilters Service Fabric para serem filtrados conforme necessário.

  • Operações operacionais 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. Veja a lista completa de eventos aqui.

  • Operacional - detalhado
    Relatórios de integridade e decisões de balanceamento de carga.

O canal de operação pode ser acessado por meio de várias maneiras, incluindo logs de eventos ETW/Windows, a EventStore (disponível no Windows nas versões 6.2 e posteriores para clusters do Windows). O EventStore oferece acesso aos eventos do cluster por entidade (entidades, incluindo cluster, nós, aplicativos, serviços, partições, réplicas e contêineres) e os expõe por meio de APIs REST e da biblioteca de cliente do Service Fabric. Use o EventStore para monitorar seus clusters de desenvolvimento/teste e para obter uma compreensão point-in-time do estado de seus clusters de produção.

  • Dados & Mensagens
    Logs críticos e eventos gerados no sistema de mensagens (atualmente apenas o ReverseProxy) e no caminho de dados (modelos de serviços confiáveis).

  • Dados & Mensagens - detalhado
    Canal detalhado que contém todos os logs não críticos de dados e mensagens no cluster (este canal tem um volume muito alto de eventos).

Além destes, há dois canais EventSource estruturados fornecidos, bem como logs que coletamos para fins de suporte.

  • Eventos do Reliable Services
    Programação de eventos específicos do modelo.

  • Eventos de Reliable Actors
    Programação de eventos específicos do modelo e contadores de desempenho.

  • Registos de suporte
    Os logs do sistema gerados pelo Service Fabric só podem ser usados por nós ao fornecer suporte.

Esses vários canais cobrem a maior parte do log de nível de plataforma recomendado. Para melhorar o registro em log no nível da plataforma, considere investir em compreender melhor o modelo de integridade e adicionar relatórios de integridade personalizados, além de adicionar Contadores de Desempenho personalizados para criar uma compreensão em tempo real do impacto de seus serviços e aplicativos no cluster.

Para aproveitar esses logs, é altamente recomendável deixar "Diagnóstico" habilitado durante a criação do cluster no Portal do Azure. Ao ativar o diagnóstico, quando o cluster é implantado, o Diagnóstico do Windows Azure é capaz de reconhecer os canais Operacionais, Serviços Confiáveis e Atores Confiáveis e armazenar os dados, conforme explicado mais detalhadamente em Eventos agregados com o Diagnóstico do Azure.

Relatórios de integridade e carga do Azure Service Fabric

O Service Fabric tem seu próprio modelo de integridade, que é descrito em detalhes nestes artigos:

O monitoramento de integridade é essencial para vários aspetos da operação de um serviço, especialmente durante uma atualização de aplicativo. Depois que cada domínio de atualização do serviço é atualizado, o domínio de atualização deve passar por verificações de integridade antes que a implantação seja movida para o próximo domínio de atualização. Se o status de integridade OK não puder ser alcançado, a implantação será revertida, para que o aplicativo permaneça em um estado OK conhecido. Embora alguns clientes possam ser afetados antes que os serviços sejam revertidos, a maioria dos clientes não terá problemas. Além disso, uma resolução ocorre relativamente rapidamente sem ter que esperar pela ação de um operador humano. Quanto mais verificações de integridade forem incorporadas ao seu código, mais resiliente será seu serviço a problemas de implantação.

Outro aspeto da integridade do serviço é o relatório de métricas do serviço. As métricas são importantes no Service Fabric porque são usadas para equilibrar o uso de recursos. As métricas também podem ser um indicador da integridade do sistema. Por exemplo, você pode ter um aplicativo que tenha muitos serviços e cada instância relata uma métrica de solicitações por segundo (RPS). Se um serviço estiver usando mais recursos do que outro, o Service Fabric moverá instâncias de serviço pelo cluster, para tentar manter a utilização uniforme dos recursos. Para obter uma explicação mais detalhada de como funciona a utilização de recursos, consulte Gerenciar o consumo e a carga de recursos no Service Fabric com métricas.

As métricas também podem ajudá-lo a obter informações sobre o desempenho do seu serviço. Com o tempo, você pode usar métricas para verificar se o serviço está operando dentro dos parâmetros esperados. Por exemplo, se as tendências mostrarem que às 9h da manhã de segunda-feira o RPS médio é 1.000, você pode configurar um relatório de integridade que o alerte se o RPS estiver abaixo de 500 ou acima de 1.500. Tudo pode estar perfeitamente bem, mas pode valer a pena dar uma olhada para ter certeza de que seus clientes estão tendo uma ótima experiência. Seu serviço pode definir um conjunto de métricas que podem ser relatadas para fins de verificação de integridade, mas que não afetam o balanceamento de recursos do cluster. Para fazer isso, defina o peso métrico como zero. Recomendamos que você inicie todas as métricas com um peso zero e não aumente o peso até ter certeza de que entende como a ponderação das métricas afeta o balanceamento de recursos para seu cluster.

Gorjeta

Não use muitas métricas ponderadas. Pode ser difícil entender por que as instâncias de serviço estão sendo movidas para balanceamento. Algumas métricas podem ajudar muito!

Qualquer informação que possa indicar a integridade e o desempenho do seu aplicativo é candidata a métricas e relatórios de integridade. Um contador de desempenho da CPU pode dizer como o nó é utilizado, mas não informa se um determinado serviço está íntegro, porque vários serviços podem estar sendo executados em um único nó. Mas, métricas como RPS, itens processados e latência de solicitação podem indicar a integridade de um serviço específico.

Logs de suporte do Service Fabric

Se você precisar entrar em contato com o suporte da Microsoft para obter ajuda com seu cluster do Azure Service Fabric, os logs de suporte são quase sempre necessários. Se o cluster estiver hospedado no Azure, os logs de suporte serão configurados e coletados automaticamente como parte da criação de um cluster. Os logs são armazenados em uma conta de armazenamento dedicada no grupo de recursos do cluster. A conta de armazenamento não tem um nome fixo, mas na conta você vê contêineres de blob e tabelas com nomes que começam com malha. Para obter informações sobre como configurar coleções de logs para um cluster autônomo, consulte Criar e gerenciar um cluster autônomo do Azure Service Fabric e Definições de configuração para um cluster autônomo do Windows. Para instâncias autônomas do Service Fabric, os logs devem ser enviados para um compartilhamento de arquivos local. É necessário ter esses logs para suporte, mas eles não se destinam a ser utilizados por ninguém fora da equipe de suporte ao cliente da Microsoft.

Medir desempenho

Medir o desempenho do cluster ajudará você a entender como ele é capaz de lidar com a carga e orientar as decisões em torno do dimensionamento do cluster (veja mais sobre como dimensionar um cluster no Azure ou localmente). Os dados de desempenho também são úteis quando comparados às ações que você ou seus aplicativos e serviços podem ter tomado, ao analisar logs no futuro.

Para obter uma lista de contadores de desempenho a serem coletados ao usar o Service Fabric, consulte Contadores de desempenho no Service Fabric

Aqui estão duas maneiras comuns de configurar a coleta de dados de desempenho para seu cluster:

  • Usando um agente
    Esta é a maneira preferida de coletar o desempenho de uma máquina, uma vez que os agentes geralmente têm uma lista de possíveis métricas de desempenho que podem ser coletadas, e é um processo relativamente fácil escolher as métricas que você deseja coletar ou alterar. Leia sobre o Azure Monitor que oferece logs do Azure Monitor na integração de logs do Azure Monitor do Service Fabric e Configurando o agente do Log Analytics para saber mais sobre o agente do Log Analytics, que é um desses agentes de monitoramento que é capaz de coletar dados de desempenho para VMs de cluster e contêineres implantados.

  • Contadores de desempenho para o Armazenamento de Tabela do Azure
    Você também pode enviar métricas de desempenho para o mesmo armazenamento de tabela que os eventos. Isso requer alterar a configuração do Diagnóstico do Azure para pegar os contadores de desempenho apropriados das VMs em seu cluster e permitir que ele pegue estatísticas do docker se você estiver implantando contêineres. Leia sobre como configurar Contadores de Desempenho no WAD no Service Fabric para configurar a coleta de contadores de desempenho.

Próximos passos

  • Leia sobre a integração de logs do Azure Monitor do Service Fabric para coletar diagnósticos de cluster e criar consultas e alertas personalizados
  • Saiba mais sobre a experiência de diagnóstico integrada do Service Fabric, a EventStore
  • Percorrer alguns cenários de diagnóstico comuns no Service Fabric