Monitoramento de soluções híbridas e em várias nuvens e padrões de geração de registros

Neste documento, abordamos as arquiteturas de monitoramento e geração de registros para implantações híbridas e em várias nuvens e apresentamos as práticas recomendadas para implementá-las usando o Google Cloud. Com este documento, é possível identificar quais padrões e produtos são mais adequados aos seus ambientes.

Cada empresa tem um portfólio exclusivo de cargas de trabalho de aplicativos, que estabelecem requisitos e restrições na arquitetura de uma configuração híbrida ou em várias nuvens. Você precisa projetar e adaptar sua arquitetura para atender a essas restrições e requisitos, mas pode confiar em alguns padrões comuns.

Os padrões abordados neste documento estão divididos em duas categorias:

  • Em uma arquitetura de painel único, todo o monitoramento e geração de registros é centralizado, com o objetivo de oferecer um só ponto de acesso e controle.
  • Em uma arquitetura de aplicativos e operações separados, os dados confidenciais do aplicativo são separados dos dados de operações menos confidenciais, com o objetivo de atender aos requisitos de conformidade que regem os dados confidenciais.

Como escolher seu padrão de arquitetura

Use a árvore de decisão no diagrama a seguir para identificar a melhor arquitetura para seu caso de uso.

Árvore de decisão para selecionar uma arquitetura de monitoramento e geração de registros.

Os detalhes de cada arquitetura são discutidos em mais detalhes neste documento, mas, de modo geral, suas opções são as seguintes:

  • Exportar do Monitoring para a solução legada
  • Exportar diretamente para a solução legada
  • Usar o Monitoring com o Prometheus e o Fluentd
  • Usar o Monitoring com o Blue Medora BindPlane

Arquitetura de painel único

Um objetivo comum para um sistema híbrido é integrar informações de monitoramento e geração de registros de várias fontes em vários aplicativos e ambientes a uma única tela. Esse tipo de tela é chamado de painel único.

No diagrama a seguir, ilustramos esse padrão em que os dados de monitoramento e geração de registros de todos os aplicativos, tanto no local quanto na nuvem, são centralizados em um só repositório hospedado na nuvem.

Arquitetura de alto nível para monitoramento e geração de registros.

Essa arquitetura tem as seguintes vantagens:

  • Você tem uma visualização única e consistente de todo o monitoramento e a geração de registros.
  • Você usa um só lugar para gerenciar o armazenamento e a retenção de dados.
  • Você tem controle centralizado de acesso e auditoria. No entanto, você ainda precisa garantir a segurança dos dados em trânsito para o repositório central.

Monitoramento como um painel único

O Cloud Monitoring é uma solução de monitoramento e gerenciamento do Google para serviços, contêineres, aplicativos e infraestrutura. O pacote de operações do Google Cloud oferece um painel único e uma solução de armazenamento robusta para métricas, registros, traces e eventos. O pacote também inclui um conjunto completo de ferramentas de observabilidade, como painéis, relatórios e alertas.

Todos os produtos e serviços do Google Cloud oferecem integração com o Monitoring. Além disso, há várias ferramentas integradas que podem ser usadas para estender o Monitoring a recursos locais e híbridos.

As práticas recomendadas a seguir se aplicam a todas as arquiteturas que usam o Monitoring como um painel único:

Monitoramento e geração de registros híbridos com o Monitoring e o BlueMedora BindPlane

Com o parceiro do Google Blue Medora BindPlane (em inglês), é possível importar dados de monitoramento e geração de registros de VMs locais e de outros provedores de nuvem, como Amazon Web Services (AWS), Microsoft Azure, Alibaba Cloud e IBM Cloud, para o Monitoring. No diagrama a seguir, mostramos como o Monitoring e o BindPlane podem fornecer um painel único para uma nuvem híbrida.

Arquitetura de alto nível para monitoramento e geração de registros com BindPlane e Monitoring.

Essa arquitetura tem as seguintes vantagens:

Para mais detalhes sobre como implementar esse padrão, consulte Como gerar registros e monitorar recursos locais com o Blue Medora.

Monitoramento híbrido do Google Kubernetes Engine com o Prometheus e o Monitoring

Com o Prometheus, uma solução conhecida de monitoramento de código aberto, e o arquivo secundário do Monitoring Prometheus (links em inglês), é possível monitorar aplicativos executados em vários clusters do Kubernetes com o Monitoring. Essa arquitetura é útil para executar cargas de trabalho do Kubernetes distribuídas pelo Google Kubernetes Engine (GKE) em clusters do Google Cloud e do Anthos no VMware no seu data center local, já que ela estabelece uma interface unificada com as duas plataformas. No diagrama a seguir, mostramos como usar o Prometheus e o arquivo secundário do Monitoring para a coleta de dados.

Arquitetura de alto nível para monitoramento do GKE com o Prometheus e o Monitoring.

Essa arquitetura tem as seguintes vantagens:

  • Métricas consistentes do Kubernetes em ambientes locais e na nuvem.
  • Não há custos de licenciamento extras para usar o Prometheus. As métricas do Prometheus são importadas para o Monitoring como métricas personalizadas, que são cobradas de acordo com as taxas padrão.

Essa arquitetura tem as seguintes desvantagens:

  • O arquivo secundário do Monitoring Prometheus é compatível apenas com ambientes do GKE.
  • O Prometheus é compatível apenas com monitoramento. Portanto, a geração de registros precisa ser configurada separadamente. Na seção a seguir, apresentamos uma opção comum para geração de registros, o Fluentd.

Recomendamos a seguinte prática recomendada:

  • Por padrão, o Prometheus coleta todas as métricas expostas, e cada uma delas torna-se uma métrica personalizada sujeita a cobrança. Para evitar custos inesperados, implemente os Controles de custo do Monitoring e considere adicionar filtros ao arquivo secundário do Monitoring Prometheus para limitar a ingestão.

Para mais detalhes de como implementar esse padrão, consulte Como monitorar apps executados em vários clusters do GKE usando o Prometheus e o Monitoring.

Geração de registros híbrida do GKE com o Fluentd e o Logging

Com o Fluentd (em inglês), um conhecido agente de geração de registros de código aberto, e o Cloud Logging, é possível ingerir registros de aplicativos executados em vários clusters do GKE para o Cloud Logging. Essa arquitetura é útil para executar cargas de trabalho do Kubernetes distribuídas pelo GKE em clusters do Google Cloud e do Anthos no VMware no seu data center local, já que ela estabelece uma interface unificada com as duas plataformas. No diagrama a seguir, ilustramos o fluxo de registros.

Arquitetura de alto nível para monitoramento do GKE com Fluentd, Monitoring e Logging.

Essa arquitetura tem as seguintes vantagens:

  • Você tem geração de registros consistentes do Kubernetes em ambientes locais e na nuvem.
  • É possível personalizar o Logging para filtrar informações confidenciais.
  • Não há custos de licenciamento extras para usar o Fluentd. Os registros do Fluentd importados para o Logging são cobrados de acordo com as taxas padrão.

Essa arquitetura tem as seguintes desvantagens:

Para mais detalhes de como implementar esse padrão, consulte Como personalizar registros do Logging para o Google Kubernetes Engine com o Fluentd.

Serviços de parceiros como painéis únicos

Se você já estiver usando um serviço de monitoramento ou geração de registros de terceiros, como o Datadog ou o Splunk, talvez não queira mudar para o Logging. Se for esse o caso, é possível exportar os dados do Google Cloud para vários serviços comuns de monitoramento e geração de registros. É possível usar um serviço integrado de monitoramento e geração de registros ou selecionar serviços separados que atendam melhor às suas necessidades.

Exportar do Logging para serviços de parceiros

Nesse padrão, você autoriza o serviço de monitoramento do parceiro, como o Datadog (em inglês), a se conectar à API Cloud Monitoring. Essa autorização permite ao serviço ingerir todas as métricas disponíveis para o Logging, de modo que o Datadog possa funcionar como um painel único de monitoramento.

Para os dados de geração de registros, o Logging fornece exportações (coletores de registros) para o Pub/Sub. Essas exportações fornecem um método eficiente e resiliente para serviços de geração de registros de parceiros, como Elastic (em inglês) e Splunk, para ingerir grandes volumes de registros do Logging em tempo real. Desse modo, esses serviços de parceiros podem exibir um painel único de registros.

A arquitetura combinada de geração de registros e monitoramento é mostrada no diagrama a seguir.

Arquitetura de alto nível para exportar dados de monitoramento e geração de registros para serviços de parceiros.

Essa arquitetura tem as seguintes vantagens:

  • Você continua usando as ferramentas atuais de costume.
  • O suporte do Google Cloud continua tendo acesso aos registros do Logging para solução de problemas.

Essa arquitetura tem as seguintes desvantagens:

  • As soluções de parceiros normalmente são hospedadas externamente, o que significa que elas talvez não estejam disponíveis nem coletem dados se as conexões de rede forem interrompidas. Às vezes, é possível reduzir esse risco com hospedagem própria. No entanto, você assume o trabalho para manter a infraestrutura da solução.
  • Os painéis hospedados externamente não estão diretamente disponíveis ao suporte do Google Cloud. Essa falta de disponibilidade pode atrasar a solução de problemas e a mitigação.
  • As soluções de parceiros comerciais podem acarretar mais taxas de licenciamento.

Veja a seguir algumas integrações de exemplo detalhadas:

Exportar métricas do Prometheus e do Logging para o Grafana

O Grafana é uma ferramenta conhecida de monitoramento de código aberto muito associada ao Prometheus (links em inglês) para a coleção de métricas. Nesta arquitetura, você usa o Prometheus como a camada de coleção local, e o Grafana como um painel único para recursos tanto do Google Cloud quanto locais. No diagrama a seguir, mostramos um exemplo de arquitetura que exporta métricas do Google Cloud e do local.

Arquitetura de alto nível para monitoramento com o Grafana como painel único.

Essa arquitetura tem as seguintes vantagens:

  • Ela é adequada a ambientes híbridos com VMs e contêineres.
  • Se sua organização já estiver usando o Prometheus e o Grafana, seus usuários poderão continuar a usá-los.

Essa arquitetura tem as seguintes desvantagens:

  • O Prometheus e o Grafana são compatíveis apenas com o monitoramento. Sendo assim, a geração de registros precisa ser configurada separadamente, por exemplo, com o Fluentd.
  • O Prometheus é extensível e de código aberto, mas é compatível apenas com um intervalo limitado de integrações de software corporativo (em inglês).
  • O Prometheus e o Grafana são ferramentas de terceiros, e não produtos oficiais do Google. O Google não oferece suporte para o Prometheus ou o Grafana.

Para mais informações, consulte Introdução ao Logging como fonte de dados do Grafana. Para ver um tutorial detalhado da implantação do Prometheus e do Grafana com o GKE e o Logging, consulte Como usar o Prometheus e o Grafana para monitoramento de IoT.

Exportar registros usando o Fluentd

Um padrão anterior apresentado que usa o Fluentd como coletor de registros para o Logging. A mesma arquitetura básica também pode ser usada para outros sistemas de geração de registros ou análise de dados compatíveis com o Fluentd, incluindo BigQuery, Elastic e Splunk. No diagrama a seguir, ilustramos esse padrão.

Arquitetura de alto nível da exportação de registros diretamente do Fluentd.

Essa arquitetura tem as seguintes vantagens:

  • Ela é adequada a ambientes híbridos com VMs e contêineres.
  • O Fluentd pode ler muitas fontes de dados (em inglês), incluindo registros do sistema.
  • O Fluentd oferece plug-ins de saída (em inglês) para muitos sistemas conhecidos de geração de registros e análise de dados de terceiros.

Essa arquitetura tem as seguintes desvantagens:

Para um exemplo de integração do Fluentd com o BigQuery, consulte Como analisar registros em tempo real usando o Fluentd e o BigQuery.

Separar dados de aplicativos e operações

As arquiteturas de painel único requerem o streaming dos dados de monitoramento e de geração de registros dos aplicativos para a nuvem. No entanto, você pode ter requisitos regulatórios ou de conformidade que exigem a manutenção dos dados dos clientes no local ou que impõem restrições rigorosas em relação aos dados que podem ser armazenados na nuvem pública.

Um padrão útil para esses ambientes híbridos é separar os dados confidenciais do aplicativo dos dados de operações de menor risco, conforme ilustrado no diagrama a seguir.

Arquitetura de alto nível para separar dados de aplicativos e de operações.

Separar os dados do aplicativo e do sistema com o Anthos

O Anthos on VMware, parte do pacote Anthos, inclui o Grafana para monitorar clusters locais. É possível também instalar uma solução de parceiro, como o Elastic Stack ou o Splunk, para geração de registros. Com essas soluções, é possível ingerir e visualizar dados confidenciais de aplicativos totalmente no local e ainda exportar dados do sistema para o Logging no Google Cloud. No diagrama a seguir, ilustramos essa arquitetura.

Como separar os dados do aplicativo e do sistema com o Anthos.

Essa arquitetura tem as seguintes vantagens:

  • Os dados de aplicativos confidenciais são mantidos totalmente no local.
  • O monitoramento e a geração de registros no local não têm dependências de nuvem e permanecem disponíveis mesmo que a conexão de rede seja interrompida.
  • Todos os dados do sistema do GKE, no local e no Google Cloud, são centralizados no Logging e também podem ser acessados pelo suporte do Google Cloud, conforme necessário.

Para ver um exemplo de implementação usando o Elastic Stack como solução de parceiro, consulte Como monitorar o Anthos com o Elastic Stack.

A seguir