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.
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.
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:
- Para atender aos requisitos de conformidade que regem a retenção de registros, configure coletores de registros na sua organização.
- Para análise rápida de eventos de registro, configure exportações de registros para o BigQuery para análise de segurança e acesso.
- Para analisar os registros armazenados no bucket, execute consultas SQL no Log Analytics.
- Para projetos que contêm dados confidenciais, considere ativar os registros de auditoria de acesso a dados para controlar quem acessou os dados.
- Para remover informações sensíveis, como CPF ou CNPJ, números de cartão de crédito e endereços de e-mail, filtre os dados de registro. É possível filtrar ao usar uma configuração personalizada do Fluent Bit ou ao ingerir com exclusões de registros. Também é possível exportar registros não filtrados separadamente para atender aos requisitos de conformidade.
- Para otimizar os custos, analise seu uso do Monitoring e do Logging e implemente controles de custo. O Monitoring e o Logging são serviços gerenciados com cobranças baseadas no volume para registros e métricas.
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.
Essa arquitetura tem as seguintes vantagens:
- Além de monitorar recursos como VMs, o BindPlane tem integração profunda integrada com mais de 50 fontes de dados conhecidas.
- Não há custos extras de licenciamento para usar o BindPlane. As métricas do BindPlane são importadas para o Monitoring como métricas personalizadas, que são cobráveis. Igualmente, a mesma taxa dos outros registros do Logging é aplicada aos registros do BindPlane.
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) no Google Cloud e no Google Distributed Cloud 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.
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 no Google Cloud e Google Distributed Cloud 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.
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 o Fluent Bit para registros do Google Kubernetes Engine.
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.
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:
- Datadog: como monitorar métricas do Compute Engine e coletar registros do Logging (links em inglês)
- Elastic: como exportar registros do Logging para o Elastic Cloud
- Splunk: cenários para exportar o Logging
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.
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 é compatível apenas com monitoramento. Portanto, a geração de registros precisa ser configurada separadamente, por exemplo, usando Fluentd ou o plug-in do Cloud Logging para Grafana.
- 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 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.
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 compatibilidade com clusters do Google Distributed Cloud 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.
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.
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
- Saiba mais sobre as práticas recomendadas de ambientes híbridos e de várias nuvens com a série Padrões e práticas de implementações híbridas e em várias nuvens, incluindo padrões de arquitetura e padrões de arquitetura de rede segura.
- Inscreva-se na pesquisa de prática recomendada do Cloud Kubernetes (em inglês) para ver exercícios práticos sobre a observabilidade e muito mais sobre o GKE.
- Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.