Quer saber mais sobre o Service Fabric?

  • Artigo

O Azure Service Fabric é uma plataforma de sistemas distribuídos que facilita o empacotamento, a implementação e a gestão de microsserviços dimensionáveis e fiáveis. No entanto, o Service Fabric tem uma grande área de superfície e há muito a aprender. Este artigo fornece uma sinopse do Service Fabric e descreve os principais conceitos, modelos de programação, ciclo de vida da aplicação, testes, clusters e monitorização do estado de funcionamento. Leia a Descrição Geral e O que são microsserviços? para uma introdução e como o Service Fabric pode ser utilizado para criar microsserviços. Este artigo não contém uma lista de conteúdos abrangente, mas liga a artigos de descrição geral e introdução para todas as áreas do Service Fabric.

Conceitos-chave

Terminologia do Service Fabric, Modelo de aplicação e Modelos de programação suportados fornecem mais conceitos e descrições, mas aqui estão as noções básicas.

Tempo de conceção: tipo de serviço, pacote de serviço e manifesto, tipo de aplicação, pacote de aplicação e manifesto

Um tipo de serviço é o nome/versão atribuído aos pacotes de código, pacotes de dados e pacotes de configuração de um serviço. Isto é definido num ficheiro de ServiceManifest.xml. O tipo de serviço é composto por definições de configuração de serviço e código executável, que são carregadas no tempo de execução e dados estáticos que são consumidos pelo serviço.

Um pacote de serviço é um diretório de disco que contém o ficheiro de ServiceManifest.xml do tipo de serviço, que referencia o código, os dados estáticos e os pacotes de configuração do tipo de serviço. Por exemplo, um pacote de serviço pode referir-se ao código, dados estáticos e pacotes de configuração que constituem um serviço de base de dados.

Um tipo de aplicação é o nome/versão atribuído a uma coleção de tipos de serviço. Isto é definido num ficheiro de ApplicationManifest.xml.

Tipos de aplicação e tipos de serviço do Service Fabric

O pacote de aplicação é um diretório de disco que contém o ficheiro de ApplicationManifest.xml do tipo de aplicação, que referencia os pacotes de serviço para cada tipo de serviço que compõe o tipo de aplicação. Por exemplo, um pacote de aplicação para um tipo de aplicação de e-mail pode conter referências a um pacote de serviço de fila, um pacote de serviço de front-end e um pacote de serviço de base de dados.

Os ficheiros no diretório do pacote de aplicações são copiados para o arquivo de imagens do cluster do Service Fabric. Em seguida, pode criar uma aplicação com nome a partir deste tipo de aplicação, que é executada no cluster. Depois de criar uma aplicação com nome, pode criar um serviço com nome a partir de um dos tipos de serviço do tipo de aplicação.

Tempo de execução: clusters e nós, aplicações nomeadas, serviços nomeados, partições e réplicas

Um cluster do Service Fabric é um conjunto ligado à rede de máquinas virtuais ou físicas em que os seus microsserviços são implementados e geridos. Os clusters podem ser dimensionados para milhares de máquinas.

Uma máquina ou VM que faça parte de um cluster é denominada um nó. É atribuído um nome de nó (uma cadeia) a cada nó. Os nós têm características, como as propriedades de colocação. Cada máquina ou VM tem um serviço Windows de início automático, , FabricHost.exeque começa a ser executado após o arranque e, em seguida, inicia dois executáveis: Fabric.exe e FabricGateway.exe. Estes dois executáveis compõem o nó. Para cenários de desenvolvimento ou teste, pode alojar vários nós numa única máquina ou VM ao executar várias instâncias de Fabric.exe e FabricGateway.exe.

Uma aplicação com nome é uma coleção de serviços nomeados que executa uma determinada função ou funções. Um serviço executa uma função completa e autónoma (pode iniciar e executar independentemente de outros serviços) e é composto por código, configuração e dados. Depois de um pacote de aplicação ser copiado para o arquivo de imagens, irá criar uma instância da aplicação no cluster ao especificar o tipo de aplicação do pacote de aplicação (utilizando o respetivo nome/versão). A cada instância de tipo de aplicação é atribuído um nome URI que se assemelha a recursos de infraestrutura:/MyNamedApp. Num cluster, pode criar várias aplicações com nome a partir de um único tipo de aplicação. Também pode criar aplicações com nome a partir de diferentes tipos de aplicações. Cada aplicação nomeada é gerida e versada de forma independente.

Depois de criar uma aplicação com nome, pode criar uma instância de um dos respetivos tipos de serviço (um serviço com nome) no cluster ao especificar o tipo de serviço (utilizando o respetivo nome/versão). A cada instância de tipo de serviço é atribuído um nome URI no âmbito do URI da aplicação com o nome. Por exemplo, se criar um serviço com o nome "MyDatabase" numa aplicação com o nome "MyNamedApp", o URI terá o seguinte aspeto: fabric:/MyNamedApp/MyDatabase. Numa aplicação com nome, pode criar um ou mais serviços nomeados. Cada serviço nomeado pode ter o seu próprio esquema de partição e contagens de instâncias/réplicas.

Existem dois tipos de serviços: sem estado e com estado. Os serviços sem estado não armazenam o estado no serviço. Os serviços sem estado não têm nenhum armazenamento persistente ou armazenam o estado persistente num serviço de armazenamento externo, como o Armazenamento do Azure, a Base de Dados SQL do Azure ou o Azure Cosmos DB. Um serviço com estado armazena o estado no serviço e utiliza modelos de programação Reliable Collections ou Reliable Actors para gerir o estado.

Ao criar um serviço com nome, especifique um esquema de partição. Os serviços com grandes quantidades de estado dividem os dados entre partições. Cada partição é responsável por uma parte do estado completo do serviço, que é distribuído pelos nós do cluster.

O diagrama seguinte mostra a relação entre aplicações e instâncias de serviço, partições e réplicas.

Partições e réplicas num serviço

Criação de partições, dimensionamento e disponibilidade

A criação de partições não é exclusiva do Service Fabric. Uma forma bem conhecida de criação de partições é a criação de partições de dados ou a fragmentação. Os serviços com estado com grandes quantidades de estado dividem os dados entre partições. Cada partição é responsável por uma parte do estado completo do serviço.

As réplicas de cada partição estão distribuídas pelos nós do cluster, o que permite dimensionar o estado do serviço nomeado. À medida que as necessidades de dados aumentam, as partições aumentam e o Service Fabric reequilibra as partições entre nós para utilizar eficazmente os recursos de hardware. Se adicionar novos nós ao cluster, o Service Fabric irá reequilibrar as réplicas de partição através do aumento do número de nós. O desempenho geral da aplicação melhora e a contenção do acesso à memória diminui. Se os nós no cluster não estiverem a ser utilizados de forma eficiente, pode diminuir o número de nós no cluster. O Service Fabric volta a reequilibrar as réplicas de partição no número reduzido de nós para melhorar a utilização do hardware em cada nó.

Numa partição, os serviços nomeados sem estado têm instâncias, enquanto os serviços nomeados com estado têm réplicas. Normalmente, os serviços nomeados sem estado só têm uma partição, uma vez que não têm estado interno, embora existam exceções. As instâncias de partição fornecem disponibilidade. Se uma instância falhar, outras instâncias continuarão a funcionar normalmente e, em seguida, o Service Fabric cria uma nova instância. Os serviços nomeados com estado mantêm o estado dentro das réplicas e cada partição tem o seu próprio conjunto de réplicas. As operações de leitura e escrita são executadas numa réplica (denominada Primária). As alterações ao estado das operações de escrita são replicadas para várias outras réplicas (denominadas Active Secondaries). Se uma réplica falhar, o Service Fabric cria uma nova réplica a partir das réplicas existentes.

Microsserviços com e sem monitorização de estado para o Service Fabric

O Service Fabric permite-lhe criar aplicações que consistem em microsserviços ou contentores. Os microsserviços sem estado (como gateways de protocolos e proxies Web) não mantêm um estado mutável fora dos pedidos nem na respetiva resposta do serviço. As funções de trabalho dos Serviços Cloud do Azure são um exemplo de serviço sem estado. Os microsserviços com estado (como contas de utilizador, bases de dados, dispositivos, carrinhos de compras e filas) mantêm um estado mutável e autoritativo para lá do pedido e da respetiva resposta. As aplicações à escala da cloud dos nossos dias são compostas por uma combinação de microsserviços com e sem estado.

Uma diferenciação fundamental com o Service Fabric é o seu forte foco na criação de serviços com estado, quer com os modelos de programação incorporados , quer com serviços com estado em contentores. Os cenários de aplicação descrevem os cenários em que são utilizados os serviços com estado.

Por que motivo tem microsserviços com estado juntamente com os sem estado? Os dois principais motivos são:

  • Pode criar serviços de processamento de transações online com tolerância a falhas (OLTP) de alto débito, baixa latência e tolerância a falhas ao manter o código e os dados fechados no mesmo computador. Alguns exemplos são lojas interativas, pesquisas, sistemas de Internet das Coisas (IoT), sistemas de negociação, sistemas de processamento de cartões de crédito e sistemas de deteção de fraudes e gestão de registos pessoais.
  • Pode simplificar a conceção da aplicação. Os microsserviços com estado eliminam a necessidade de filas e caches adicionais, que são tradicionalmente necessárias para abordar os requisitos de disponibilidade e latência de uma aplicação puramente sem estado. Os serviços com estado são naturalmente de elevada disponibilidade e baixa latência, o que reduz o número de peças móveis a gerir na sua aplicação como um todo.

Modelos de programação suportados

O Service Fabric oferece várias formas de escrever e gerir os seus serviços. Os serviços podem utilizar as APIs do Service Fabric para tirar o máximo partido das funcionalidades e arquiteturas de aplicações da plataforma. Os serviços também podem ser qualquer programa executável compilado escrito em qualquer idioma e alojado num cluster do Service Fabric. Para obter mais informações, veja Modelos de programação suportados.

Contentores

Por predefinição, o Service Fabric implementa e ativa os serviços como processos. O Service Fabric também pode implementar serviços em contentores. Acima de tudo, pode misturar serviços em processos e serviços em contentores na mesma aplicação. O Service Fabric suporta a implementação de contentores do Linux e contentores do Windows no Windows Server 2016. Pode implementar aplicações existentes, serviços sem estado ou serviços com estado em contentores.

Reliable Services

O Reliable Services é uma arquitetura simples para escrever serviços que se integram na plataforma do Service Fabric e beneficiam de todo o conjunto de funcionalidades da plataforma. O Reliable Services pode ser sem estado (semelhante à maioria das plataformas de serviço, como servidores Web ou Funções de Trabalho no Azure Serviços Cloud), em que o estado persiste numa solução externa, como a BD do Azure ou o Armazenamento de Tabelas do Azure. O Reliable Services também pode ter monitorização de estado, onde o estado é mantido diretamente no próprio serviço com o Reliable Collections. O estado é altamente disponível através da replicação e distribuído através da criação de partições, tudo gerido automaticamente pelo Service Fabric.

Reliable Actors

Criada com base no Reliable Services, a arquitetura Reliable Actor é uma arquitetura de aplicação que implementa o padrão de Ator Virtual, com base no padrão de design de ator. A arquitetura Reliable Actor utiliza unidades independentes de computação e estado com execução de thread único denominada atores. A arquitetura Reliable Actor fornece comunicação incorporada para atores e configurações de escalamento horizontal e persistência de estado predefinida.

ASP.NET Core

O Service Fabric integra-se com ASP.NET Core como um modelo de programação de primeira classe para criar aplicações Web e API. ASP.NET Core podem ser utilizadas de duas formas diferentes no Service Fabric:

  • Alojado como executável convidado. Isto é utilizado principalmente para executar aplicações ASP.NET Core existentes no Service Fabric sem alterações de código.
  • Execute dentro de um Reliable Service. Isto permite uma melhor integração com o runtime do Service Fabric e permite serviços de ASP.NET Core com monitorização de estado.

Executáveis de convidado

Um executável convidado é um executável arbitrário existente (escrito em qualquer linguagem) alojado num cluster do Service Fabric juntamente com outros serviços. Os executáveis convidados não se integram diretamente com as APIs do Service Fabric. No entanto, continuam a beneficiar das funcionalidades que a plataforma oferece, como o estado de funcionamento personalizado, a criação de relatórios de carga e a deteção do serviço ao chamar as APIs REST. Também têm suporte completo para o ciclo de vida da aplicação.

Ciclo de vida da aplicação

Tal como acontece com outras plataformas, uma aplicação no Service Fabric costuma passar pelas seguintes fases: design, desenvolvimento, teste, implementação, atualização, manutenção e remoção. O Service Fabric fornece suporte de primeira classe para o ciclo de vida completo das aplicações na cloud, desde o desenvolvimento até à implementação, gestão diária e manutenção até eventual desativação. O modelo de serviço permite que várias funções diferentes participem de forma independente no ciclo de vida da aplicação. O ciclo de vida das aplicações do Service Fabric fornece uma descrição geral das APIs e como são utilizadas pelas diferentes funções ao longo das fases do ciclo de vida das aplicações do Service Fabric.

Todo o ciclo de vida da aplicação pode ser gerido com cmdlets do PowerShell, comandos da CLI, APIs C#, APIs Java e APIs REST. Também pode configurar pipelines de integração contínua/implementação contínua com ferramentas como o Azure Pipelines ou o Jenkins.

Veja esta ligação para obter um vídeo de formação que descreva como gerir o ciclo de vida da sua aplicação:

Testar aplicações e serviços

Para criar serviços verdadeiramente à escala da cloud, é fundamental verificar se as suas aplicações e serviços podem suportar falhas do mundo real. O Serviço de Análise de Falhas foi concebido para testar serviços criados no Service Fabric. Com o Serviço de Análise de Falhas, pode induzir falhas significativas e executar cenários de teste completos nas suas aplicações. Estas falhas e cenários exerçam e validam os inúmeros estados e transições que um serviço irá experimentar ao longo da sua duração, tudo de forma controlada, segura e consistente.

As ações visam um serviço para testar com falhas individuais. Um programador de serviços pode utilizá-los como blocos modulares para escrever cenários complicados. Exemplos de falhas simuladas são:

  • Reinicie um nó para simular qualquer número de situações em que uma máquina virtual ou VM seja reiniciada.
  • Mova uma réplica do seu serviço com monitorização de estado para simular o balanceamento de carga, a ativação pós-falha ou a atualização da aplicação.
  • Invoque a perda de quórum num serviço com estado para criar uma situação em que as operações de escrita não podem prosseguir porque não existem réplicas de "cópia de segurança" ou "secundárias" suficientes para aceitar novos dados.
  • Invoque a perda de dados num serviço com monitorização de estado para criar uma situação em que todo o estado dentro da memória é completamente eliminado.

Os cenários são operações complexas compostas por uma ou mais ações. O Serviço de Análise de Falhas fornece dois cenários completos incorporados:

  • Cenário de caos– simula falhas contínuas e intercaladas (corretas e ingratas) em todo o cluster durante longos períodos de tempo.
  • Cenário de ativação pós-falha – uma versão do cenário de teste de caos que visa uma partição de serviço específica, deixando outros serviços inalterados.

Clusters

Um cluster do Service Fabric é um conjunto ligado à rede de máquinas virtuais ou físicas no qual os seus microsserviços são implementados e geridos. Os clusters podem ser dimensionados para milhares de máquinas. Uma máquina ou VM que faz parte de um cluster é denominada nó de cluster. É atribuído um nome de nó (uma cadeia) a cada nó. Os nós têm características, como as propriedades de colocação. Cada máquina ou VM tem um serviço de arranque automático, FabricHost.exe, que começa a ser executado após o arranque e, em seguida, inicia dois executáveis: Fabric.exe e FabricGateway.exe. Estes dois executáveis compõem o nó. Para cenários de teste, pode alojar vários nós num único computador ou VM ao executar várias instâncias de Fabric.exe e FabricGateway.exe.

Os clusters do Service Fabric podem ser criados em máquinas virtuais ou físicas com o Windows Server ou Linux. Pode implementar e executar aplicações do Service Fabric em qualquer ambiente onde tenha um conjunto de computadores Windows Server ou Linux interligados: no local, no Microsoft Azure ou em qualquer fornecedor de cloud.

Veja esta ligação para obter um vídeo de formação que descreva a arquitetura do Service Fabric, os conceitos principais e muitas outras funcionalidades do service fabric

Clusters no Azure

A execução de clusters do Service Fabric no Azure fornece integração com outras funcionalidades e serviços do Azure, o que torna as operações e a gestão do cluster mais fáceis e fiáveis. Um cluster é um recurso do Azure Resource Manager, pelo que pode modelar clusters como qualquer outro recurso no Azure. Resource Manager também fornece uma gestão fácil de todos os recursos utilizados pelo cluster como uma única unidade. Os clusters no Azure estão integrados nos diagnósticos do Azure e nos registos do Azure Monitor. Os tipos de nós de cluster são conjuntos de dimensionamento de máquinas virtuais, pelo que a funcionalidade de dimensionamento automático está incorporada.

Pode criar um cluster no Azure através do portal do Azure, a partir de um modelo ou do Visual Studio.

O Service Fabric no Linux permite-lhe criar, implementar e gerir aplicações altamente disponíveis e altamente dimensionáveis no Linux, tal como faria no Windows. As arquiteturas do Service Fabric (Reliable Services e Reliable Actors) estão disponíveis em Java no Linux, além de C# (.NET Core). Também pode criar serviços executáveis convidados com qualquer linguagem ou arquitetura. A orquestração de contentores do Docker também é suportada. Os contentores do Docker podem executar executáveis convidados ou serviços nativos do Service Fabric, que utilizam as arquiteturas do Service Fabric. Para obter mais informações, leia sobre o Service Fabric no Linux.

Existem algumas funcionalidades suportadas no Windows, mas não no Linux. Para saber mais, leia Diferenças entre o Service Fabric no Linux e o Windows.

Clusters autónomos

O Service Fabric fornece um pacote de instalação para criar clusters autónomos do Service Fabric no local ou em qualquer fornecedor de cloud. Os clusters autónomos dão-lhe a liberdade de alojar um cluster onde quiser. Se os seus dados estiverem sujeitos a restrições de conformidade ou regulamentares ou quiser manter os seus dados locais, pode alojar o seu próprio cluster e aplicações. As aplicações do Service Fabric podem ser executadas em vários ambientes de alojamento sem alterações, pelo que o seu conhecimento sobre a criação de aplicações passa de um ambiente de alojamento para outro.

Crie o primeiro cluster autónomo do Service Fabric

Os clusters autónomos do Linux ainda não são suportados.

Segurança do cluster

Os clusters têm de ser protegidos para impedir que utilizadores não autorizados se liguem ao cluster, especialmente quando tem cargas de trabalho de produção em execução no mesmo. Embora seja possível criar um cluster não seguro, fazê-lo permite que os utilizadores anónimos se liguem ao mesmo se os pontos finais de gestão estiverem expostos à Internet pública. Não é possível ativar posteriormente a segurança num cluster não seguro: a segurança do cluster é ativada no momento da criação do cluster.

Os cenários de segurança do cluster são:

  • Segurança do nó para o nó
  • Segurança cliente a nó
  • Controlo de acesso baseado em funções do Service Fabric

Para obter mais informações, leia Proteger um cluster.

Dimensionamento

Se adicionar novos nós ao cluster, o Service Fabric reequilibrará as réplicas de partição e as instâncias em todo o número aumentado de nós. O desempenho geral da aplicação melhora e a contenção do acesso à memória diminui. Se os nós no cluster não estiverem a ser utilizados de forma eficiente, pode diminuir o número de nós no cluster. O Service Fabric volta a reequilibrar as réplicas de partição e as instâncias em todo o número reduzido de nós para melhorar a utilização do hardware em cada nó. Pode dimensionar clusters no Azure de forma manual ou programática. Os clusters autónomos podem ser dimensionados manualmente.

Atualizações do cluster

Periodicamente, são lançadas novas versões do runtime do Service Fabric. Efetue atualizações de runtime ou recursos de infraestrutura no cluster para que esteja sempre a executar uma versão suportada. Além das atualizações de recursos de infraestrutura, também pode atualizar a configuração do cluster, como certificados ou portas de aplicação.

Um cluster do Service Fabric é um recurso do qual é proprietário, mas que é parcialmente gerido pela Microsoft. A Microsoft é responsável por corrigir o SO subjacente e efetuar atualizações de recursos de infraestrutura no cluster. Pode definir o cluster para receber atualizações automáticas de recursos de infraestrutura, quando a Microsoft lançar uma nova versão ou optar por selecionar uma versão de recursos de infraestrutura suportada pretendida. Os recursos de infraestrutura e as atualizações de configuração podem ser definidos através do portal do Azure ou através de Resource Manager. Para obter mais informações, leia Atualizar um cluster do Service Fabric.

Um cluster autónomo é um recurso do qual é totalmente proprietário. É responsável por aplicar patches ao SO subjacente e iniciar atualizações de recursos de infraestrutura. Se o cluster conseguir ligar ao https://www.microsoft.com/download, pode definir o cluster para transferir e aprovisionar automaticamente o novo pacote de runtime do Service Fabric. Em seguida, iniciaria a atualização. Se o cluster não conseguir aceder https://www.microsoft.com/downloadao , pode transferir manualmente o novo pacote de runtime a partir de um computador ligado à Internet e, em seguida, iniciar a atualização. Para obter mais informações, leia Atualizar um cluster autónomo do Service Fabric.

Monitorização do estado de funcionamento

O Service Fabric introduz um modelo de estado de funcionamento concebido para sinalizar condições de aplicação e cluster em mau estado de funcionamento em entidades específicas (como nós de cluster e réplicas de serviço). O modelo de estado de funcionamento utiliza repórteres de saúde (componentes do sistema e cães de guarda). O objetivo é um diagnóstico e reparação fáceis e rápidos. Os escritores de serviços precisam de pensar antecipadamente sobre saúde e como conceber relatórios de saúde. Qualquer condição que possa afetar o estado de funcionamento deve ser reportada, especialmente se puder ajudar a sinalizar problemas próximos da raiz. As informações de estado de funcionamento podem poupar tempo e esforço na depuração e investigação assim que o serviço estiver a funcionar em escala na produção.

Os repórteres do Service Fabric monitorizam as condições de interesse identificadas. Comunicam essas condições com base na sua vista local. O arquivo de estado de funcionamento agrega os dados de estado de funcionamento enviados por todos os jornalistas para determinar se as entidades estão globalmente em bom estado de funcionamento. O modelo destina-se a ser rico, flexível e fácil de utilizar. A qualidade dos relatórios de estado de funcionamento determina a precisão da vista de estado de funcionamento do cluster. Os falsos positivos que apresentam incorretamente problemas de mau estado de funcionamento podem afetar negativamente as atualizações ou outros serviços que utilizam dados de estado de funcionamento. Exemplos desses serviços são serviços de reparação e mecanismos de alerta. Por conseguinte, é necessário algum pensamento para fornecer relatórios que capturem condições de interesse da melhor forma possível.

Os relatórios podem ser feitos a partir de:

  • A réplica ou instância do serviço Service Fabric monitorizada.
  • Watchdogs internos implementados como um serviço do Service Fabric (por exemplo, um serviço sem estado do Service Fabric que monitoriza as condições e os relatórios de problemas). Os watchdogs podem ser implementados em todos os nós ou podem ser afinizados com o serviço monitorizado.
  • Os watchdogs internos que são executados nos nós do Service Fabric, mas não são implementados como serviços do Service Fabric.
  • Watchdogs externos que pesquisam o recurso fora do cluster do Service Fabric (por exemplo, serviço de monitorização como Gomez).

Desativados, os componentes do Service Fabric comunicam o estado de funcionamento de todas as entidades no cluster. Os relatórios de estado de funcionamento do sistema fornecem visibilidade sobre a funcionalidade do cluster e da aplicação e sinalizam problemas através do estado de funcionamento. Para aplicações e serviços, os relatórios de estado de funcionamento do sistema verificam se as entidades estão implementadas e estão a comportar-se corretamente do ponto de vista do runtime do Service Fabric. Os relatórios não fornecem qualquer monitorização do estado de funcionamento da lógica de negócio do serviço nem detetam processos que deixaram de responder. Para adicionar informações de estado de funcionamento específicas à lógica do seu serviço, implemente relatórios de estado de funcionamento personalizados nos seus serviços.

O Service Fabric fornece várias formas de ver relatórios de estado de funcionamento agregados no arquivo de estado de funcionamento:

Veja esta página para obter um vídeo de formação que descreva o modelo de estado de funcionamento do Service Fabric e como é utilizado:

Monitorização e diagnóstico

A monitorização e o diagnóstico são fundamentais para o desenvolvimento, teste e implementação de aplicações e serviços em qualquer ambiente. As soluções do Service Fabric funcionam melhor quando planeia e implementa monitorização e diagnósticos que ajudam a garantir que as aplicações e os serviços estão a funcionar conforme esperado num ambiente de desenvolvimento local ou em produção.

Os principais objetivos de monitorização e diagnóstico são:

  • Detetar e diagnosticar problemas de hardware e infraestrutura
  • Detetar problemas de software e aplicações, reduzir o tempo de inatividade do serviço
  • Compreender o consumo de recursos e ajudar a impulsionar as decisões de operações
  • Otimizar o desempenho da aplicação, do serviço e da infraestrutura
  • Gerar informações empresariais e identificar áreas de melhoria

O fluxo de trabalho geral de monitorização e diagnóstico consiste em três passos:

  1. Geração de eventos: inclui eventos (registos, rastreios, eventos personalizados) na infraestrutura (cluster), plataforma e nível de aplicação/serviço
  2. Agregação de eventos: os eventos gerados têm de ser recolhidos e agregados antes de poderem ser apresentados
  3. Análise: os eventos têm de ser visualizados e acessíveis em algum formato, para permitir a análise e apresentação, conforme necessário

Estão disponíveis vários produtos que abrangem estas três áreas e pode escolher diferentes tecnologias para cada um. Para obter mais informações, leia Monitorização e diagnósticos do Azure Service Fabric.

Passos seguintes