Este documento aborda as arquiteturas de monitorização e registo para implementações híbridas e em várias nuvens, e fornece práticas recomendadas para as implementar através da utilização do Google Cloud. Com este documento, pode identificar os padrões e os produtos mais adequados para os seus ambientes.
Cada empresa tem um portefólio único de cargas de trabalho de aplicações que impõem requisitos e restrições à arquitetura de uma configuração híbrida ou multicloud. Embora tenha de conceber e adaptar a sua arquitetura para cumprir estas restrições e requisitos, pode basear-se em alguns padrões comuns.
Os padrões abordados neste documento dividem-se em duas categorias:
- Numa arquitetura de painel único, toda a monitorização e registo são centralizados, com o objetivo de fornecer um único ponto de acesso e controlo.
- Numa arquitetura de aplicação e operações separadas, os dados confidenciais da aplicação são separados dos dados de operações menos confidenciais, com o objetivo de cumprir os requisitos de conformidade para dados confidenciais.
Escolher o padrão de arquitetura
Pode usar a árvore de decisões no diagrama seguinte para identificar a melhor arquitetura para o seu exemplo de utilização.
Os detalhes de cada arquitetura são abordados mais detalhadamente neste documento, mas, a nível geral, as suas opções são as seguintes:
- Exporte do Monitoring para a solução antiga.
- Exporte diretamente para a solução antiga.
- Use a monitorização com o Prometheus e o Fluentd ou o Fluent Bit.
- Use a monitorização com o observIQ BindPlane.
Arquitetura de painel único de vidro
Um objetivo comum de um sistema híbrido é integrar informações de monitorização e registo de várias fontes em várias aplicações e ambientes num único ecrã. Este tipo de ecrã é denominado painel único.
O diagrama seguinte ilustra este padrão em que os dados de monitorização e registo de todas as aplicações, tanto nas instalações como na nuvem, são centralizados num único repositório alojado na nuvem.
Esta arquitetura tem as seguintes vantagens:
- Tem uma vista única e consistente para toda a monitorização e registo.
- Tem um único local para gerir o armazenamento e a retenção de dados.
- Tem acesso centralizado ao controlo e à auditoria. No entanto, continua a ter de garantir a segurança dos dados em trânsito para o repositório central.
Monitorização como um único painel
O Cloud Monitoring é uma solução de monitorização e gestão gerida pela Google para serviços, contentores, aplicações e infraestrutura. Para um único painel de controlo e uma solução de armazenamento robusta para métricas, registos, rastreios e eventos, use o Google Cloud Observability. O conjunto de ferramentas também oferece um conjunto completo de ferramentas de observabilidade, como painéis de controlo, relatórios e alertas.
Todos os Google Cloud produtos e serviços suportam a integração com a monitorização. Além disso, existem várias ferramentas integradas que pode usar para estender a monitorização a recursos híbridos e no local.
As seguintes práticas recomendadas aplicam-se a todas as arquiteturas que usam a monitorização como um único painel:
- Para cumprir os requisitos de conformidade para a retenção de registos, configure destinos de registos para a sua organização.
- Para uma análise rápida dos eventos de registo, configure as exportações de registos para o BigQuery para análise de segurança e acesso.
- Para analisar registos armazenados no seu contentor de registos, execute consultas SQL através do Log Analytics.
- Para projetos que contenham dados confidenciais, considere ativar os registos de auditoria de acesso a dados, para poder acompanhar quem acedeu aos dados.
- Para remover informações confidenciais, como números de segurança social, números de cartões de crédito e endereços de email, pode filtrar os dados de registo. Pode filtrar através de uma configuração personalizada do Fluent Bit ou carregar com exclusões de registos. Também pode exportar registos não filtrados separadamente para cumprir os requisitos de conformidade.
Monitorização e registo híbridos com o Monitoring e o BindPlane da observIQ
Com o BindPlane do parceiro da Google observIQ, pode importar dados de monitorização e registo de VMs no local e de outros fornecedores de nuvem, como os serviços Web da Amazon (AWS), o Microsoft Azure, o Alibaba Cloud e o IBM Cloud para o Google Cloud. O diagrama seguinte mostra como a monitorização e o BindPlane podem fornecer um único painel para uma nuvem híbrida.
Esta arquitetura tem as seguintes vantagens:
- Além de monitorizar recursos como VMs, o BindPlane tem uma integração detalhada incorporada para mais de 50 origens de dados populares.
- Não existem custos de licenciamento adicionais para usar o BindPlane. As métricas do BindPlane são importadas para o Monitoring como métricas personalizadas, que são cobradas. Da mesma forma, os registos do BindPlane são cobrados à mesma taxa que outros registos do Logging.
Para mais detalhes sobre a implementação deste padrão, consulte o artigo Registo e monitorização de recursos no local com o BindPlane.
Monitorização híbrida do Google Kubernetes Engine com o Prometheus e o Monitoring
Com o Google Cloud Managed Service for Prometheus, uma solução de monitorização de código aberto popular totalmente gerida pela Google Cloud, pode monitorizar aplicações em execução em vários clusters do Kubernetes com o Monitoring. Esta arquitetura é útil quando executa cargas de trabalho do Kubernetes distribuídas no Google Kubernetes Engine (GKE) noGoogle Cloud e no Google Distributed Cloud no seu centro de dados no local, uma vez que fornece uma interface unificada em ambos. O diagrama seguinte mostra como usar o Prometheus e os coletores de monitorização para a recolha de dados.
Esta arquitetura tem as seguintes vantagens:
- Métricas do Kubernetes consistentes em ambientes na nuvem e nas instalações.
- Permite-lhe monitorizar e receber alertas sobre as suas cargas de trabalho globalmente através do Prometheus, sem ter de gerir e operar manualmente o Prometheus à escala.
- Não existem custos de licenciamento adicionais para usar o Prometheus. As métricas do Prometheus são importadas para o Monitoring. As importações são cobradas e têm um preço baseado no número de amostras carregadas.
Esta arquitetura tem as seguintes desvantagens:
- O Prometheus suporta apenas a monitorização, pelo que o registo tem de ser configurado separadamente. A secção seguinte aborda uma opção comum para registar através do Fluentd ou do Fluent Bit.
Recomendamos a seguinte prática recomendada:
- Por predefinição, o Prometheus recolhe todas as métricas expostas, cada uma das quais se torna uma métrica faturável. Para evitar custos inesperados, considere implementar controlos de custos de monitorização.
Registo do GKE híbrido com o Fluentd ou o Fluent Bit e o Cloud Logging
Com o Fluentd ou o Fluent Bit, um agente de registo de código aberto popular e o Cloud Logging, pode carregar registos de aplicações executadas em vários clusters do GKE para o Cloud Logging. Esta arquitetura é útil quando executa cargas de trabalho do Kubernetes distribuídas no GKE e no Google Distributed Cloud no seu centro de dados no local, porque oferece uma interface unificada em ambos. Google Cloud O diagrama seguinte ilustra o fluxo dos registos.
Esta arquitetura tem as seguintes vantagens:
- Pode ter registos do Kubernetes consistentes em ambientes na nuvem e no local.
- Pode personalizar o registo para filtrar informações confidenciais.
- Não existem custos de licenciamento adicionais para usar o Fluentd ou o Fluent Bit. Os registos que são importados para o Logging através do Fluentd ou do Fluent Bit são faturáveis.
Esta arquitetura tem as seguintes desvantagens:
- O Fluentd e o Fluent Bit suportam apenas o registo, pelo que a monitorização tem de ser configurada separadamente. A secção anterior aborda uma opção comum para a monitorização com o Prometheus.
Para mais detalhes sobre a implementação deste padrão, consulte o artigo Personalizar o Fluent Bit para registos do Google Kubernetes Engine.
Serviços de parceiros como painéis únicos
Se já estiver a usar um serviço de monitorização ou registo de terceiros, como o Datadog ou o Splunk, pode não querer mudar para o Logging. Se for o caso, pode exportar dados do Google Cloud para muitos serviços comuns de monitorização e registo. Pode optar por usar um serviço de monitorização e registo integrado ou selecionar serviços de monitorização e registo separados que melhor se adequem às suas necessidades.
Exporte do Logging para serviços de parceiros
Neste padrão, autoriza o serviço de monitorização do parceiro, como o Datadog, a estabelecer ligação à API Cloud Monitoring. Esta autorização permite que o serviço carregue todas as métricas disponíveis para o Logging, para que o Datadog possa funcionar como um único painel de controlo para monitorização.
Para dados de registo, o Logging fornece exportações (destinos de registo) para o Pub/Sub. Estas exportações oferecem um método de registo de parceiros com bom desempenho e resiliente para serviços como o Elastic e o Splunk, de modo a ingerir grandes volumes de registos do Logging em tempo real. Assim, estes serviços de parceiros podem apresentar um único painel de controlo para os registos.
A arquitetura combinada para registo e monitorização é apresentada no diagrama seguinte.
Esta arquitetura tem as seguintes vantagens:
- Pode continuar a usar as ferramentas existentes familiares.
- Google Cloud O apoio técnico continua a ter acesso aos registos de registo para resolução de problemas.
Esta arquitetura tem as seguintes desvantagens:
- Normalmente, as soluções de parceiros são alojadas externamente, o que significa que podem não estar disponíveis ou recolher dados se as ligações de rede forem interrompidas. Por vezes, pode mitigar este risco através da auto-hospedagem, mas ao custo de ter de manter a infraestrutura da solução por si próprio.
- Os painéis de controlo alojados externamente não estão diretamente disponíveis para o Google Cloud apoio técnico. Esta falta de disponibilidade pode atrasar a resolução de problemas e a mitigação.
- As soluções de parceiros comerciais podem implicar mais taxas de licenciamento.
Alguns exemplos detalhados de integrações incluem o seguinte:
- Datadog: Monitorizar métricas do Compute Engine e Recolher registos de registo
- Elastic: Exportar registos do Logging para o Elastic Cloud
- Splunk: Cenários de exportação de registos
Analise métricas do Prometheus e do Logging com o Grafana
O Grafana é uma ferramenta de monitorização de código aberto popular, normalmente associada ao Prometheus para a recolha de métricas. Nesta arquitetura, usa o Prometheus como a camada de recolha nas instalações e usa o Grafana como um único painel de controlo para os recursos na nuvem e nas instalações.Google Cloud O diagrama seguinte mostra uma arquitetura de exemplo que analisa métricas de Google Cloud e no local.
Esta arquitetura tem as seguintes vantagens:
- É adequado para ambientes híbridos com VMs e contentores.
- Se a sua organização já estiver a usar o Prometheus e o Grafana, os seus utilizadores podem continuar a usá-los.
Esta arquitetura tem as seguintes desvantagens:
- O Prometheus suporta apenas a monitorização, pelo que o registo tem de ser configurado separadamente, por exemplo, através do Fluentd ou do plugin Cloud Logging para Grafana.
- O Prometheus é de código aberto e extensível, mas suporta apenas uma gama limitada de integrações de software empresarial.
- O Prometheus e o Grafana são ferramentas de terceiros e não são produtos oficiais da Google. A Google não oferece apoio técnico para o Prometheus nem o Grafana.
Para mais informações, consulte o artigo Melhore a resolução de problemas com um plug-in do Cloud Logging para o Grafana.
Exporte registos através do Fluentd
Um padrão anterior foi abordado com o Fluentd ou o Fluent Bit como um coletor de registos para o Logging. A mesma arquitetura básica também pode ser usada para outros sistemas de registo ou estatísticas de dados que suportam o Fluentd ou o Fluent Bit, incluindo o BigQuery, o Elastic e o Splunk. O diagrama seguinte ilustra este padrão.
Esta arquitetura tem as seguintes vantagens:
- É adequado para ambientes híbridos com VMs e contentores.
- O Fluentd pode ler a partir de muitas origens de dados, incluindo registos do sistema.
- O Fluentd oferece plug-ins de saída para muitos sistemas populares de registo e estatísticas de dados de terceiros.
- O Fluent Bit também pode ler a partir de muitas entradas, incluindo registos do sistema.
- O Fluent Bit oferece saídas para muitos sistemas populares de registo e estatísticas de dados de terceiros.
Esta arquitetura tem as seguintes desvantagens:
- O Fluentd e o Fluent Bit só suportam registos, pelo que a monitorização tem de ser configurada separadamente. A secção anterior aborda as opções comuns para a monitorização com o Prometheus e o Grafana.
- O Fluentd e o Fluent Bit são ferramentas de terceiros e não produtos oficiais da Google. A Google não oferece apoio técnico para os mesmos.
- Os registos exportados não estão disponíveis para o apoio técnico do Google Cloud para resolução de problemas. Em particular, a Google não oferece apoio técnico para clusters do Google Distributed Cloud sem o Logging ativado.
Separe os dados de aplicações e operações
As arquiteturas de painel único requerem a monitorização de aplicações de streaming e o registo de dados na nuvem. No entanto, pode ter requisitos regulamentares ou de conformidade que exigem a manutenção dos dados dos clientes no local ou impõem restrições rigorosas sobre os dados que podem ser armazenados na nuvem pública.
Um padrão útil para estes ambientes híbridos é separar os dados de aplicações confidenciais dos dados de operações de menor risco, conforme ilustrado no diagrama seguinte.
Separe os dados da aplicação e do sistema com o GKE Enterprise
O GKE Enterprise no VMware, que faz parte do conjunto GKE Enterprise, inclui o Grafana para monitorizar clusters no local. Além disso, pode optar por instalar uma solução de parceiros, como o Elastic Stack ou o Splunk, para registo. Com estas soluções, pode carregar e ver dados de aplicações confidenciais totalmente no local, ao mesmo tempo que exporta dados do sistema para o Logging noGoogle Cloud. O diagrama seguinte ilustra esta arquitetura.
Esta arquitetura tem as seguintes vantagens:
- Os dados confidenciais da aplicação são mantidos totalmente no local.
- A monitorização e o registo no local não têm dependências da nuvem e permanecem disponíveis mesmo que a ligação de rede seja interrompida.
- Todos os dados do sistema do GKE, tanto no local como Google Cloud, estão centralizados no Logging e também estão acessíveis ao Google Cloud apoio técnico, conforme necessário.
Para ver um exemplo de implementação que usa o Elastic Stack como solução de parceiros, consulte o artigo Monitorizar o GKE Enterprise com o Elastic Stack.
O que se segue?
- Saiba mais sobre as práticas recomendadas híbridas e multicloud com a série Padrões e práticas híbridas e multicloud, incluindo padrões de arquitetura e padrões de arquitetura de rede segura.
- Inscreva-se na missão de práticas recomendadas do Kubernetes na nuvem para exercícios práticos sobre observabilidade e muito mais no GKE.
- Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.