O blog da AWS
Observe suas cargas de trabalho do Azure e da AWS simultaneamente com o Amazon CloudWatch
Por Rich McDonough, Aidan Keane, e Aviad Tamir
Visão geral
A operação eficaz de aplicações e serviços em nuvem exige um forte foco no monitoramento e na observabilidade. É fundamental que suas equipes definam, capturem e analisem métricas, garantindo visibilidade operacional e extraindo insights acionáveis de logs.
Em muitas empresas, as equipes técnicas compartilham sistemas integrados para monitorar os serviços ou a infraestrutura que gerenciam. Os sistemas compartilhados de observabilidade consolidam os dados de desempenho e disponibilidade de uma organização. Eles permitem que as equipes visualizem as conexões entre serviços e componentes. As equipes colaboram com dados em tempo real e identificam rapidamente a origem dos problemas de desempenho, disponibilidade ou segurança.
Em ambientes multicloud, quando as cargas de trabalho são executadas em nuvens diferentes, a criação de uma solução centralizada de observabilidade pode resultar em abordagens com silos, que aumentam a complexidade e os custos diretos e indiretos. Ter uma visão holística e uma abordagem unificada para monitoramento se torna muito importante para clientes que executam cargas de trabalho em ambientes multicloud.
A AWS fornece vários serviços que ajudam a melhorar sua postura de monitoramento e observabilidade em ambientes híbridos e multicloud. Um desses serviços é o Amazon CloudWatch, que ajuda você a monitorar a saúde de seus recursos e aplicações na AWS, on-premises e em outras nuvens.
Hoje, mostraremos como monitorar cargas de trabalho em ambientes multicloud usando um recurso do Amazon CloudWatch: consultar dados de métricas provenientes do Azure Monitor.
Esse recurso ajuda você a obter visibilidade das cargas de trabalho que são executadas em ambientes híbridos e multicloud, bem como de suas próprias fontes de dados personalizadas. Você pode consultar e visualizar dados como a utilização da CPU provenientes das instâncias do Amazon EC2 e das Máquinas Virtuais do Azure no mesmo painel e criar alarmes a partir desses dados.
Figura 1: visão geral dos recursos
As CloudWatch data sources são providas pelo AWS Lambda, que executa as queries das métricas. O armazenamento de credenciais remotas, como segredos de clientes e IDs de assinatura do Azure, é gerenciado pelo AWS Secrets Manager. O AWS CloudFormation cria isso como uma stack para você. Essa abordagem cria uma solução extensível. Ela se baseia na mesma estrutura de métricas de data sources. Essa estrutura permite a inclusão de dados de arquivos CSV no Amazon S3, ou métricas do Amazon Managed Service for Prometheus, na experiência do CloudWatch. Para obter detalhes adicionais sobre outras data sources, consulte nossa documentação de recursos.
Pré-requisitos
- Uma conta da AWS
- Uma account subscription do Azure com permissões de Owner
Passo 1: criar o registro do aplicativo no portal Microsoft Entra ID
A integração das métricas do Azure com o Amazon CloudWatch exige a criação de um app registration no tenant do Azure. Explicaremos esse processo em termos simples, mas não entraremos em detalhes relacionados ao controle de acesso baseado em funções do Azure (Azure RBAC) ou às suas necessidades específicas de segurança e governança nesta postagem.
Antes de implementar o processo descrito aqui, revise-o para garantir que ele atenda aos seus requisitos de segurança. Observe que essa configuração permitirá monitorar o acesso de leitura a todos os recursos da assinatura do Amazon CloudWatch.
- Acesse o centro de administração do Microsoft Entra com no mínimo privilégio de Cloud Application Administrator
- Selecione a opção do menu Identity, seguida por Applications e selecione App Registration.
- Selecione New Registration.
- Dê um nome ao seu registro (por exemplo, Amazon CloudWatch) e selecione a opção do tenant que atenda ao seu caso de uso. Mantenha na configuração padrão “Accounts in this organizational directory only (Default Directory only – Single tenant)”.
- Selecione Register.
- Selecione a opção Certificates & Secrets no menu de opções e, em seguida, selecione New Client Secret.
- Forneça uma descrição e um prazo de validade.
- Note que você deve atualizar esse segredo no lado da AWS antes da expiração.
- Em seguida, selecione Add.
- Copie o Value e mantenha-o seguro. Essa é uma sequência de caracteres sensível semelhante a uma senha ou outros tokens de acesso.
- Copie os seguintes campos da opção de menu Overview:
- Application (client) ID
- Directory (tenant) ID
Com o app registration criado, agora precisaremos conceder permissão para que ele leia os dados da sua subscription do Azure na etapa dois abaixo.
Alternativa: use a CLI do Azure para criar o app registration
Esse comando cria um single tenant app registration:
Substitua o id retornado do comando anterior no argumento abaixo:
Substitua o id no argumento pelo id do primeiro comando no argumento abaixo.
Note a senha exibida no output, pois ela será usada para configurar o Amazon CloudWatch.
Alternativa: use o Azure PowerShell para criar o app registration
Esse comando cria um single tenant app registration:
Substitua o App_ID retornado do comando anterior no argumento abaixo:
Substitua o ID retornado do primeiro comando no argumento abaixo:
Note o valor secreto, pois ele será usado para configurar o Amazon CloudWatch.
Passo 2: conceder permissões para a Azure subscription no portal
- Acesse o Portal do Microsoft Azure, pesquise por Subscriptions na caixa de pesquisa global
- Na aba Subscriptions, selecione a subscription que você deseja integrar com o Amazon CloudWatch.
- Selecione Access Control (IAM) no menu, depois Add e selecione Add Role Assignment.
- Selecione Monitoring Data Reader na lista e selecione Next.
- Escolha Select Members e, em seguida, digite o nome do seu app registration.
- Note que o nome pode não aparecer na lista até ser inserido. Selecione o nome do app registration e clique em Select.
- Por fim, selecione Next e depois Review and Assign.
Você pode validar se estas permissões estão sendo aplicadas revisando outros recursos em sua subscription, como máquinas virtuais, a partir de suas páginas do IAM.
Alternativa: use a CLI do Azure para conceder permissões à assinatura do Azure
Substitua o Subscription_ID no comando abaixo pela sua assinatura e substitua o App_ID pela saída do comando az usado acima.
Alternativa: use o Azure PowerShell para conceder permissões à assinatura do Azure
Substitua o ID retornado do comando New-AzadServicePrincipal no argumento abaixo e substitua Subscription_ID pela sua subscription.
Passo três: configurar o CloudWatch para ler dados métricos do Azure
Primeiro, no console do CloudWatch, selecione Settings na navegação do lado esquerdo e, em seguida, selecione Metric Data Sources.
Figura 2: a página de configurações do serviço CloudWatch
Em seguida, selecione Create Data Source, Azure Monitor e, em seguida, Next.
Figura 3: selecionando o Azure Monitor na lista de Metric Data Sources
Dê um nome à fonte de dados. Observe que esse nome aparecerá como o nome da stack do CloudFormation criada. Insira a ID do diretório (tenant), o ID do aplicativo (client) e o client secret, e selecione Create Data Source.
Figura 4: configurando a nova data source com suas credenciais do Azure App
Opcionalmente, você pode acompanhar o progresso da stack seguindo o link para o CloudFormation. Normalmente, vemos esse processo concluído em menos de dois minutos. Observe que, para outras Metric Data Sources, como Prometheus ou Amazon RDS, você pode criar opcionalmente uma Lambda function em uma VPC, o que pode adicionar um ou dois minutos extras ao tempo de provisionamento. Quando você vir essa tela, sua integração estará completa.
Figura 5: a página de conclusão da integração no CloudWatch
Passo quatro: visualizar dados do seu ambiente do Azure
Agora você pode consultar dados das métricas do Azure Monitor usando o CloudWatch. Clique no botão Open CloudWatch Metrics ou navegue até All Metrics no menu de navegação esquerdo, e depois em Multi Source Query e selecione o nome da sua data source no menu suspenso.
Figura 6: uma visão do console de consulta de várias fontes
Selecione sua subscription, resource group e outros campos. O CloudWatch agora está monitorando sua Azure subscription, assim como faz com sua conta da AWS.
Figura 7: visualizando a CPU de uma VM do Azure usando o CloudWatch
Um comentário sobre como essa integração funciona: o Azure Monitor (semelhante a outros tipos de metric data sources no CloudWatch) não persiste os dados no CloudWatch. Portanto, o CloudWatch consultará o Azure sob demanda à medida que você acessa seus dados. Isso permanece válido para os alarmes do CloudWatch, que também consultam datapoints suficientes por avaliação de alarme para verificar se as condições de alerta foram atendidas. Você pode ver detalhes de cada consulta do log group correspondente à sua métrica Lambda.
Solução de problemas comuns
A Lambda é utilizada para executar consultas afim de integrar as metric data sources e os logs que são armazenados no CloudWatch Logs. O log group é o local para encontrar erros na configuração.
Esses são os problemas mais comuns que vemos e algumas notas sobre como resolvê-los:
Mensagem de erro:
INFO Sending response: { Data: [], SubscriptionIds: [] }
Isso mostra que o Azure IAM não aplicou os grants e que o Lambda não pode enumerar as Azure subscription. Certifique-se de que a segunda etapa tenha sido concluída na subscription correta.
Mensagem de erro:
INFO An error occurred: RestError: Commonly allowed time grains:...
Nem todos os tipos de metric data sources oferecem suporte a esse recurso. Isso pode acontecer ao tentar visualizar dados que são agregados com pouca frequência no Azure Monitor, como métricas de uso da conta de armazenamento. Esse é o comportamento esperado para métricas que são preenchidas com pouca frequência. Consulte a documentação da API do Azure Monitor para obter mais detalhes.
Mensagem de erro:
INFO An error occurred: AuthenticationRequiredError: invalid_client ensure your credentials are correct
Isso geralmente ocorre devido às credenciais erradas armazenadas no AWS Secrets Manager. Verifique novamente se o ID do tenant, o ID do aplicativo e o valor do segredo estão corretos. Você pode alterar esses valores diretamente no AWS Secrets Manager sem recriar a stack do CloudFormation.
Levando a integração para o próximo nível
Uma solução de monitoramento e observabilidade híbrida e multicloud é um mecanismo poderoso para monitorar suas operações na nuvem. Você pode agregar valor no uso do CloudWatch como um componente central da sua solução, usando recursos que automatizam e ampliam essas capacidades. Uma das mais poderosas é criar alarmes com base em dados de métricas de seu ambiente do Azure. Um alarme do CloudWatch pode acionar qualquer fluxo de trabalho automatizado que você possa imaginar — acionar administradores, criar tickets do JIRA, reiniciar servidores ou iniciar operações de failover.
Você pode criar alarmes compostos com o CloudWatch que podem alertar quando surgirem problemas em um ou mais ambientes de nuvem. Considere uma carga de trabalho que opere no Azure e na AWS, e um deployment em ambos os provedores que gere uma falha. Use um alarme composto com base na contagem agregada de erros HTTP em todo o seu cenário de nuvem e acione ações, tudo com base em métricas nativas da nuvem criadas pelo Azure e pela AWS. Para alguns casos de uso, isso pode ser mais adequado do que alarmes separados para cada ambiente.
Custo e Remoção
Não há custo adicional para o uso de metric data sources externas no CloudWatch, embora você incorra em cobranças padrão pelo uso de alarmes do Lambda, do Secrets Manager, do CloudWatch Logs e do CloudWatch. Consulte a documentação do Azure para obter detalhes de preços para extrair dados da API do Azure Monitor.
Você pode remover a integração simplesmente excluindo a stack do CloudFormation que foi criada na etapa três. Isso removerá a Lambda function e os segredos do Secrets Manager.
Resumo
A criação de uma solução de observabilidade multicloud com o CloudWatch permite que você visualize e aja com base em métricas de vários ambientes diferentes. Usando os recursos do CloudWatch, como alarmes, painéis e math metric, você pode criar consultas avançadas que desbloqueiam dados operacionais isolados e ajudam a reduzir o tempo necessário para lidar com a complexidade de usar mais de um provedor de nuvem. Usando esse recurso, você pode acessar e agir sobre dados métricos de fora da AWS, tornando o CloudWatch um ponto central de como você operacionaliza seus dados métricos.
Este artigo foi traduzido do Blog da AWS em Inglês.
Sobre o autor
Aidan Keane é Senior Specialist Solutions Architect na AWS, especializado em Microsoft Workloads. Ele tem 25 anos de experiência na indústria de tecnologia, é apaixonado por tecnologias e gosta de criar e explorar novas soluções técnicas para os clientes. Fora de sua vida profissional, Aidan é um ávido entusiasta do esporte, apaixonado por golfe, ciclismo e pelo Liverpool FC. Ele gosta de passar bons momentos com sua família, além de viajar para a Irlanda e o Peru como seus destinos preferidos.
Aviad Tamir é Senior Solutions Architect na AWS com foco em soluções para o setor de serviços financeiros. Ele tem 25 anos de experiência no setor de tecnologia, trabalhando tanto para Startups quanto para empresas corporativas. Ele gosta de filosofia de código aberto, compartilhamento de conhecimento e criação de software melhor.
Rich McDonough é um Principal Technologist da Amazon Web Services (AWS). Com mais de 20 anos de experiência no setor de TI, ele cultivou suas habilidades na área de Startups, ocupando cargos de diretoria, arquiteto e DevOps, onde suas principais áreas de foco eram o desenvolvimento de back-end, a criação de práticas de DevOps e a migração de empresas nativas digitais para a nuvem. Apoiando os clientes na criação de arquiteturas de nuvem altamente escaláveis, flexíveis e resilientes, abordando problemas comerciais do mundo real e acelerando a adoção dos serviços da AWS, ele é “excessivamente apaixonado pela excelência operacional”. Rich gosta de ministrar workshops, falar em público e desenvolver soluções em nome dos clientes da AWS.
Revisores
Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 14 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.
Luciano Bernardes trabalha atualmente como Sr Solutions Architect na AWS, especializado em workloads Microsoft. Com 15 anos de experiência no mercado, trabalhou a maior parte em consultoria técnica especializada em Microsoft, em clientes de várias verticais, com demandas voltadas para infraestrutura on-premises e em nuvem. Como SA, trabalha próximo a clientes e parceiros de consultoria em LATAM, para apoiá-los em tomadas de decisão e revisão de arquitetura de workoads Microsoft na nuvem AWS.