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

Last reviewed 2023-03-29 UTC

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
  • Use o Monitoring com o Prometheus e o Fluentd ou o Fluent Bit.
  • Usar o Monitoring com o observIQ 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. Para ter um único painel e uma solução de armazenamento robusta para métricas, registros, traces e eventos, use o Google Cloud Observability. 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 híbrido e geração de registros com o Monitoring e o BindPlane da observIQ

Com o BindPlane do parceiro do Google, observIQ, é possível importar dados de monitoramento e geração de registros de VMs locais e de outros provedores de nuvem, como a Amazon Web Services (AWS), Microsoft Azure, Alibaba Cloud e IBM Cloud no Google Cloud. 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 BindPlane.

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

Com o Google Cloud Managed Service para Prometheus, uma solução de monitoramento de código aberto conhecida e totalmente gerenciada pelo Google Cloud, é 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 GKE 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 os coletores 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.
  • Ele permite monitorar e receber alertas globalmente sobre as cargas de trabalho usando o Prometheus, sem precisar gerenciar e operar manualmente o Prometheus em grande escala.
  • Não há custos de licenciamento extras para usar o Prometheus. As métricas do Prometheus são importadas para o Monitoring. As importações são cobráveis e cobradas pelo número de amostras ingeridas.

Essa arquitetura tem as seguintes desvantagens:

  • O Prometheus é compatível apenas com monitoramento. Portanto, a geração de registros precisa ser configurada separadamente. A seção a seguir discute uma opção comum para geração de registros usando o Fluentd ou o Fluent Bit.

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 sujeita a cobrança. Para evitar custos inesperados, implemente controles de custos do Monitoring.

Geração de registros híbridos do GKE com o Fluentd ou o Fluent Bit e Cloud Logging

Com o Fluentd ou o Fluent Bit, um conhecido agente de geração de registros de código aberto, e o Cloud Logging, é possível ingerir registros de aplicativos em execução no vários clusters do GKE ao Cloud Logging. Essa arquitetura é útil para executar cargas de trabalho do Kubernetes distribuídas pelo GKE em clusters do Google Cloud e do GKE 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 o Fluentd ou o Fluent Bit, 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á outros custos de licenciamento para usar o Fluentd ou o Fluent Bit. Os registros importados para o Logging usando o Fluentd ou o Fluent Bit são faturáveis.

Essa arquitetura tem as seguintes desvantagens:

  • O Fluentd e o Fluent Bit são compatíveis apenas com a geração de registros. Portanto, o monitoramento precisa ser configurado separadamente. Na seção anterior, apresentamos uma opção comum de monitoramento com o Prometheus.

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

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:

Analisar métricas do Prometheus e do Logging com 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 analisa as métricas do Google Cloud e no 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:

Para saber mais, consulte Solução de problemas aprimorada com um plug-in do Cloud Logging para Grafana.

Exportar registros usando o Fluentd

Um padrão anterior coberto por meio do Fluentd ou do Fluent Bit como um coletor de registros do 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 ou o Fluent Bit, incluindo o BigQuery, o Elastic e o Splunk. No diagrama a seguir, ilustramos esse padrão.

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

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.
  • O Fluent Bit também pode ler muitas entradas, incluindo registros do sistema.
  • O Fluent Bit oferece saídas para muitos sistemas conhecidos de geração de registros e análise de dados de terceiros.

Essa arquitetura tem as seguintes desvantagens:

  • O Fluentd e o Fluent Bit são compatíveis apenas com registros. Portanto, o monitoramento precisa ser configurado separadamente. Na seção anterior, apresentamos as opções comuns de monitoramento com o Prometheus e o Grafana.
  • O Fluentd e o Fluent Bit são ferramentas de terceiros, e não produtos oficiais do Google. O Google não oferece suporte a essas ferramentas.
  • Os registros exportados não estão disponíveis ao suporte do Google Cloud para solução de problemas. Em particular, o Google não oferece suporte para clusters do GKE VMware sem o Logging ativado.

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 de aplicativos e sistemas com o GKE Enterprise

O GKE Enterprise no VMware, parte do pacote do GKE Enterprise, inclui o Grafana para o monitoramento de clusters no local. É 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 GKE Enterprise.

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 um exemplo de implementação usando o Elastic Stack como solução de parceiro, consulte Como monitorar o GKE Enterprise com o Elastic Stack.

A seguir