As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Planejando sua CloudWatch implantação
<a name="planning-cloudwatch-deployment"></a>

A complexidade e o escopo de uma solução de registro e monitoramento dependem de vários fatores, incluindo:
+ Quantos ambientes, regiões e contas são usados e como esse número pode aumentar.
+ A variedade e os tipos de suas cargas de trabalho e arquiteturas existentes.
+ Os tipos de computação e esses OSs devem ser registrados e monitorados.
+ Se há locais e AWS infraestrutura locais.
+ Os requisitos analíticos e de agregação de vários sistemas e aplicativos.
+ Requisitos de segurança que evitam a exposição não autorizada de registros e métricas.
+ Produtos e soluções que devem ser integrados à sua solução de registro e monitoramento para dar suporte aos processos operacionais.

Você deve revisar e atualizar regularmente sua solução de registro e monitoramento com implantações de carga de trabalho novas ou atualizadas. As atualizações em seu registro, monitoramento e alarme devem ser identificadas e aplicadas quando problemas são observados. Esses problemas podem então ser identificados e evitados de forma proativa no futuro. 

Você deve se certificar de instalar e configurar consistentemente o software e os serviços para capturar e ingerir registros e métricas. Uma abordagem estabelecida de registro e monitoramento usa serviços e soluções de fornecedores de software (ISV) múltiplos AWS ou independentes para diferentes domínios (por exemplo, segurança, desempenho, rede ou análise). Cada domínio tem seus próprios requisitos de implantação e configuração. 

Recomendamos usar CloudWatch para capturar e ingerir registros e métricas para vários tipos OSs de computação. Muitos AWS serviços são usados CloudWatch para registrar, monitorar e publicar registros e métricas, sem a necessidade de configuração adicional. CloudWatch fornece um [agente de software](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) que pode ser instalado e configurado para diferentes OSs ambientes. As seções a seguir descrevem como implantar, instalar e configurar o CloudWatch agente para várias contas, regiões e configurações:

**Topics**
+ [

# Uso CloudWatch em contas centralizadas ou distribuídas
](cloudwatch-centralized-distributed-accounts.md)
+ [

# Gerenciando arquivos de configuração do CloudWatch agente
](create-store-cloudwatch-configurations.md)

# Uso CloudWatch em contas centralizadas ou distribuídas
<a name="cloudwatch-centralized-distributed-accounts"></a>

Embora tenha sido CloudWatch projetado para monitorar AWS serviços ou recursos em uma conta e região, você pode usar uma conta central para capturar registros e métricas de várias contas e regiões. Se você usa mais de uma conta ou região, deve avaliar se deve usar a abordagem de conta centralizada ou uma conta individual para capturar registros e métricas. Normalmente, uma abordagem híbrida é necessária para implantações em várias contas e em várias regiões para atender aos requisitos de segurança, análise, operações e proprietários de cargas de trabalho. 

A tabela a seguir fornece áreas a serem consideradas ao escolher usar uma abordagem centralizada, distribuída ou híbrida.


****  

|  |  | 
| --- |--- |
| Estruturas de contas | Sua organização pode ter várias contas separadas (por exemplo, contas para cargas de trabalho não produtivas e de produção) ou milhares de contas para aplicativos únicos em ambientes específicos. Recomendamos que você mantenha registros e métricas do aplicativo na conta em que a carga de trabalho é executada, o que dá aos proprietários da carga de trabalho acesso aos registros e métricas. Isso permite que eles tenham um papel ativo no registro e no monitoramento. Também recomendamos que você use uma conta de registro separada para agregar todos os registros de carga de trabalho para análise, agregação, tendências e operações centralizadas. Contas de registro separadas também podem ser usadas para segurança, arquivamento, monitoramento e análise.  | 
| Requisitos de acesso | Os membros da equipe (por exemplo, proprietários de cargas de trabalho ou desenvolvedores) precisam de acesso a registros e métricas para solucionar problemas e fazer melhorias. Os registros devem ser mantidos na conta da carga de trabalho para facilitar o acesso e a solução de problemas. Se os registros e as métricas forem mantidos em uma conta separada da carga de trabalho, talvez os usuários precisem alternar regularmente entre contas. O uso de uma conta centralizada fornece informações de registro para usuários autorizados sem conceder acesso à conta de carga de trabalho. Isso pode simplificar os requisitos de acesso para cargas de trabalho analíticas em que a agregação é necessária de cargas de trabalho executadas em várias contas. A conta de registro centralizada também pode ter opções alternativas de busca e agregação, como um cluster do Amazon OpenSearch Service. O Amazon OpenSearch Service [fornece controle de acesso refinado](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/fgac.html) até o nível do campo para seus registros. O controle de acesso refinado é importante quando você tem dados sensíveis ou confidenciais que exigem acesso e permissões especializados. | 
| Operações | Muitas organizações têm uma equipe centralizada de operações e segurança ou uma organização externa para suporte operacional que requer acesso aos registros para monitoramento. O registro e o monitoramento centralizados podem facilitar a identificação de tendências, a pesquisa, a agregação e a realização de análises em todas as contas e cargas de trabalho. Se sua organização usa a abordagem “[você cria, você executa](https://aws.amazon.com//blogs/enterprise-strategy/enterprise-devops-why-you-should-run-what-you-build/)” DevOps, os proprietários da carga de trabalho precisam registrar e monitorar as informações em suas contas. Pode ser necessária uma abordagem híbrida para satisfazer as operações e análises centrais, além da propriedade distribuída da carga de trabalho. | 
| Ambiente |  Você pode escolher hospedar registros e métricas em um local central para contas de produção e manter registros e métricas para outros ambientes (por exemplo, desenvolvimento ou teste) na mesma conta ou em contas separadas, dependendo dos requisitos de segurança e da arquitetura da conta. Isso ajuda a evitar que dados confidenciais criados durante a produção sejam acessados por um público mais amplo.   | 

CloudWatch fornece [várias opções](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Subscriptions.html) para processar registros em tempo real com filtros de CloudWatch assinatura. Você pode usar filtros de assinatura para transmitir registros em tempo real para AWS serviços de processamento, análise e carregamento personalizados em outros sistemas. Isso pode ser particularmente útil se você adotar uma abordagem híbrida em que seus registros e métricas estejam disponíveis em contas e regiões individuais, além de uma conta e região centralizadas. A lista a seguir fornece exemplos de AWS serviços que podem ser usados para isso:
+ [Amazon Data Firehose — O Firehose](https://docs.aws.amazon.com//firehose/latest/dev/what-is-this-service.html) fornece uma solução de streaming que escala e redimensiona automaticamente com base no volume de dados que está sendo produzido. Você não precisa gerenciar o número de fragmentos em um stream de dados do Amazon Kinesis e pode se conectar diretamente ao Amazon Simple Storage Service (Amazon S3) OpenSearch , Amazon Service ou Amazon Redshift sem codificação adicional. O Firehose é uma solução eficaz se você quiser centralizar seus registros nesses serviços. AWS 
+ [Amazon Kinesis Data](https://docs.aws.amazon.com//streams/latest/dev/introduction.html) Streams — O Kinesis Data Streams é uma solução adequada se você precisar se integrar a um serviço ao qual o Firehose não oferece suporte e implementar lógica de processamento adicional. Você pode criar um destino do Amazon CloudWatch Logs em suas contas e regiões que especifica um stream de dados do Kinesis em uma conta central e AWS Identity and Access Management uma função (IAM) que concede permissão para colocar registros no stream. O Kinesis Data Streams fornece uma landing zone flexível e aberta para seus dados de log, que pode então ser consumida por diferentes opções. Você pode ler os dados de log do Kinesis Data Streams em sua conta, realizar o pré-processamento e enviar os dados para o destino escolhido. 

  No entanto, você deve configurar os fragmentos do stream para que ele seja dimensionado adequadamente para os dados de log produzidos. O Kinesis Data Streams atua como intermediário temporário ou fila para seus dados de log, e você pode armazenar os dados no stream do Kinesis por entre um e 365 dias. O Kinesis Data Streams também oferece suporte ao recurso de repetição, o que significa que você pode reproduzir dados que não foram consumidos.
+ [Amazon OpenSearch Service](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/what-is.html) — CloudWatch Os registros podem transmitir registros em um grupo de registros para um OpenSearch cluster em uma conta individual ou centralizada. Quando você configura um grupo de registros para transmitir dados para um OpenSearch cluster, uma função Lambda é criada na mesma conta e região do seu grupo de registros. A função Lambda deve ter uma conexão de rede com o OpenSearch cluster. Você pode personalizar a função Lambda para realizar um pré-processamento adicional, além de personalizar a ingestão no Amazon Service. OpenSearch O registro centralizado com o Amazon OpenSearch Service facilita a análise, a pesquisa e a solução de problemas em vários componentes em sua arquitetura de nuvem.
+ [Lambda](https://docs.aws.amazon.com//lambda/latest/dg/welcome.html) — Se você usa o Kinesis Data Streams, precisa provisionar e gerenciar recursos computacionais que consomem dados do seu stream. Para evitar isso, você pode transmitir dados de log diretamente para o Lambda para processamento e enviá-los para um destino com base na sua lógica. Isso significa que você não precisa provisionar e gerenciar recursos computacionais para processar os dados recebidos. [Se você optar por usar o Lambda, certifique-se de que sua solução seja compatível com as cotas do Lambda.](https://docs.aws.amazon.com//lambda/latest/dg/gettingstarted-limits.html)

Talvez seja necessário processar ou compartilhar dados de registro armazenados em CloudWatch Registros em formato de arquivo. Você pode criar uma tarefa de [exportação para exportar um grupo de logs para o Amazon S3](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/S3Export.html) em uma data ou intervalo de tempo específico. Por exemplo, você pode optar por exportar registros diariamente para o Amazon S3 para análise e auditoria. O Lambda pode ser usado para automatizar essa solução. Você também pode combinar essa solução com a replicação do Amazon S3 para enviar e centralizar seus logs de várias contas e regiões para uma conta e região centralizadas. 

A configuração do CloudWatch agente também pode especificar um `credentials` campo na [`agent`seção](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Agentsection). Isso especifica uma função do IAM a ser usada ao enviar métricas e registros para uma conta diferente. Se especificado, esse campo contém o `role_arn` parâmetro. Esse campo pode ser usado quando você só precisa de registro e monitoramento centralizados em uma conta e região centralizadas específicas. 

Você também pode usar o [AWS SDK](https://aws.amazon.com/developer/tools/) para criar seu próprio aplicativo de processamento personalizado em um idioma de sua escolha, ler registros e métricas de suas contas e enviar dados para uma conta centralizada ou outro destino para processamento e monitoramento adicionais.

# Gerenciando arquivos de configuração do CloudWatch agente
<a name="create-store-cloudwatch-configurations"></a>

Recomendamos que você crie uma configuração padrão de CloudWatch agente da Amazon que inclua os registros e métricas do sistema que você deseja capturar em todas as suas instâncias e servidores locais do Amazon Elastic Compute Cloud (Amazon EC2). Você pode usar o [assistente do arquivo de configuração do CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html) agente para ajudá-lo a criar o arquivo de configuração. Você pode executar o assistente de configuração várias vezes para gerar configurações exclusivas para diferentes sistemas e ambientes. Você também pode modificar o arquivo de configuração ou criar variações [usando o esquema do arquivo de configuração](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html). O arquivo de configuração do CloudWatch agente pode ser armazenado nos parâmetros do [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html).  Você pode criar parâmetros separados do Parameter Store se tiver [vários arquivos de configuração do CloudWatch agente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files). Se você estiver usando várias contas da AWS ou regiões da AWS, deverá gerenciar e atualizar os parâmetros do Parameter Store em cada conta e região. Como alternativa, você pode gerenciar centralmente suas CloudWatch configurações como arquivos no Amazon S3 ou em uma ferramenta de controle de versão de sua escolha. 

O `amazon-cloudwatch-agent-ctl` script incluído no CloudWatch agente permite que você especifique um arquivo de configuração, um parâmetro do Parameter Store ou a configuração padrão do agente. A configuração padrão se alinha ao conjunto de métricas básico e predefinido e configura o agente para o qual reportar métricas de memória e espaço em disco. CloudWatch No entanto, ele não inclui nenhuma configuração de arquivo de log. A configuração padrão também será aplicada se você usar o [Systems Manager Quick Setup](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-quick-setup.html) para o CloudWatch agente.

Como a configuração padrão não inclui registro e não é personalizada para seus requisitos, recomendamos que você crie e aplique suas próprias CloudWatch configurações, personalizadas de acordo com seus requisitos.

## Gerenciando CloudWatch configurações
<a name="store-cloudwatch-configuration-s3"></a>

Por padrão, CloudWatch as configurações podem ser armazenadas e aplicadas como parâmetros do Parameter Store ou como arquivos CloudWatch de configuração. A melhor escolha dependerá de suas necessidades. Nesta seção, discutiremos os prós e os contras dessas duas opções. Uma solução representativa também é detalhada para gerenciar arquivos de CloudWatch configuração para várias contas e regiões da AWS.

**Parâmetros do Systems Manager Parameter Store**

Usar os parâmetros do Parameter Store para gerenciar CloudWatch configurações funciona bem se você tiver um único arquivo de configuração de CloudWatch agente padrão que deseja aplicar e gerenciar em um pequeno conjunto de contas e regiões da AWS. Ao armazenar suas CloudWatch configurações como parâmetros do Parameter Store, você pode usar a ferramenta de configuração do CloudWatch agente (`amazon-cloudwatch-agent-ctl`no Linux) para ler e aplicar a configuração do Parameter Store sem precisar copiar o arquivo de configuração para sua instância. Você pode usar o documento **AmazonCloudWatch- ManageAgent ** Systems Manager Command para atualizar a CloudWatch configuração em várias instâncias do EC2 em uma única execução. Como os parâmetros do Parameter Store são regionais, você deve atualizar e manter os parâmetros do CloudWatch Parameter Store em cada região da AWS e conta da AWS. Se você tiver várias CloudWatch configurações que deseja aplicar a cada instância, deverá personalizar o documento **AmazonCloudWatch- ManageAgent** Command**** para incluir esses parâmetros.

**CloudWatch arquivos de configuração**

Gerenciar suas CloudWatch configurações como arquivos pode funcionar bem se você tiver muitas contas e regiões da AWS e estiver gerenciando vários arquivos de CloudWatch configuração. Usando essa abordagem, você pode navegar, organizar e gerenciá-los em uma estrutura de pastas.  Você pode aplicar regras de segurança a pastas ou arquivos individuais para limitar e conceder acesso, como permissões de atualização e leitura. Você pode compartilhá-los e transferi-los para fora da AWS para colaboração. Você pode controlar a versão dos arquivos para rastrear e gerenciar as alterações. Você pode aplicar CloudWatch configurações coletivamente copiando os arquivos de configuração para o diretório de configuração do CloudWatch agente sem aplicar cada arquivo de configuração individualmente. Para Linux, o diretório CloudWatch de configuração é encontrado em`/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d`. Para Windows, o diretório de configuração é encontrado em`C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs`.

Quando você inicia o CloudWatch agente, o agente anexa automaticamente cada arquivo encontrado nesses diretórios para criar um arquivo de configuração CloudWatch composto. Os arquivos de configuração devem ser armazenados em um local central (por exemplo, um bucket S3) que possa ser acessado pelas contas e regiões necessárias. Um exemplo de solução usando essa abordagem é fornecido.

**Organizando CloudWatch configurações**

Independentemente da abordagem usada para gerenciar suas CloudWatch configurações, organize suas CloudWatch configurações. Você pode organizar suas configurações em caminhos de arquivo ou de armazenamento de parâmetros usando uma abordagem como a seguinte.


|  |  | 
| --- |--- |
| */config/standard/windows/ec2* | Armazene arquivos de CloudWatch configuração padrão específicos do Windows para o Amazon EC2. Você pode categorizar ainda mais as configurações padrão do sistema operacional (SO) para diferentes versões do Windows, tipos de instância do EC2 e ambientes nessa pasta. | 
| */config/standard/windows/onpremises* | Armazene arquivos de CloudWatch configuração padrão específicos do Windows para servidores locais. Você também categoriza ainda mais suas configurações de sistema operacional padrão para diferentes versões, tipos de servidores e ambientes do Windows nessa pasta. | 
| */config/standard/linux/ec2* | Armazene seus arquivos de CloudWatch configuração padrão específicos do Linux para o Amazon EC2. Você pode categorizar ainda mais sua configuração de sistema operacional padrão para diferentes distribuições Linux, tipos de instância EC2 e ambientes nesta pasta. | 
| */config/standard/linux/onpremises* | Armazene seus arquivos de CloudWatch configuração padrão específicos do Linux para servidores locais. Você pode categorizar ainda mais a configuração padrão do sistema operacional para diferentes distribuições, tipos de servidores e ambientes Linux nesta pasta. | 
| */config/ecs* | Armazene arquivos de CloudWatch configuração específicos do Amazon Elastic Container Service (Amazon ECS) se você usar instâncias de contêiner do Amazon ECS. Essas configurações podem ser anexadas às configurações padrão do Amazon EC2 para registro e monitoramento específicos em nível de sistema do Amazon ECS. | 
| */config/* <application\$1name> | Armazene seus arquivos de configuração específicos do aplicativo CloudWatch . Você pode categorizar ainda mais seus aplicativos com pastas e prefixos adicionais para ambientes e versões. | 

## Exemplo: armazenamento de arquivos CloudWatch de configuração em um bucket do S3
<a name="example"></a>

Esta seção fornece um exemplo do uso do Amazon S3 para armazenar arquivos de CloudWatch configuração e um runbook personalizado do Systems Manager para recuperar e aplicar os arquivos de configuração. CloudWatch Essa abordagem pode resolver alguns dos desafios de usar os parâmetros do Systems Manager Parameter Store para CloudWatch configuração em grande escala:
+ Se você usar várias regiões, deverá sincronizar as atualizações de CloudWatch configuração no repositório de parâmetros de cada região. O Parameter Store é um serviço regional e o mesmo parâmetro deve ser atualizado em cada região que usa o CloudWatch agente.
+ Se você tiver várias CloudWatch configurações, deverá iniciar a recuperação e a aplicação de cada configuração do Parameter Store. Você deve recuperar individualmente cada CloudWatch configuração do Parameter Store e também atualizar o método de recuperação sempre que adicionar uma nova configuração. Por outro lado, CloudWatch fornece um diretório de configuração para armazenar arquivos de configuração e aplica cada configuração no diretório, sem exigir que sejam especificados individualmente.
+ Se você usa várias contas, deve garantir que cada nova conta tenha as CloudWatch configurações necessárias em seu Parameter Store. Você também precisa se certificar de que todas as alterações de configuração sejam aplicadas a essas contas e suas regiões no futuro.

Você pode armazenar CloudWatch configurações em um bucket do S3 que pode ser acessado de todas as suas contas e regiões. Em seguida, você pode copiar essas configurações do bucket do S3 para o diretório de CloudWatch configuração usando os runbooks do Systems Manager Automation e o Systems Manager State Manager. Você pode usar o modelo [cloudwatch-config-s3-bucket.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) da CloudFormation AWS para criar um bucket do S3 que pode ser acessado por várias contas dentro de uma organização no AWS Organizations. O modelo inclui um `OrganizationID` parâmetro que concede acesso de leitura a todas as contas da sua [organização](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html).

[A amostra aumentada do runbook do Systems Manager, fornecida na seção [Configurar o Gerenciador Estadual e Distribuidor para implantação e configuração de CloudWatch agentes](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/install-cloudwatch-systems-manager.html#set-up-systems-manager-distributor) deste guia, está configurada para recuperar arquivos usando o bucket S3 criado pelo modelo AWS 3-bucket.yaml. cloudwatch-config-s](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) CloudFormation 

Como alternativa, você pode usar um sistema de controle de versão (por exemplo, GitHub) para armazenar seus arquivos de configuração. Se você quiser recuperar automaticamente os arquivos de configuração armazenados em um sistema de controle de versão, precisará gerenciar ou centralizar o armazenamento de credenciais e atualizar o runbook do Systems Manager Automation que é usado para recuperar as credenciais em suas contas e. Regiões da AWS