Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Planificación de la CloudWatch implementación
La complejidad y el alcance de una solución de registro y supervisión dependen de varios factores, entre ellos:
+ Cuántos entornos, regiones y cuentas se utilizan y cómo podría aumentar este número.
+ La variedad y los tipos de sus cargas de trabajo y arquitecturas existentes.
+ Los tipos de cómputo y los OSs que deben registrarse y supervisarse.
+ Si hay ubicaciones e AWS infraestructura locales.
+ Los requisitos analíticos y de agregación de varios sistemas y aplicaciones.
+ Requisitos de seguridad que impiden la exposición no autorizada de registros y métricas.
+ Productos y soluciones que deben integrarse con su solución de registro y monitoreo para respaldar los procesos operativos.
Debe revisar y actualizar periódicamente su solución de registro y monitoreo con implementaciones de cargas de trabajo nuevas o actualizadas. Las actualizaciones del registro, la supervisión y las alarmas deben identificarse y aplicarse cuando se detecten problemas. Estos problemas se pueden identificar y prevenir de forma proactiva en el futuro.
Debe asegurarse de instalar y configurar de forma coherente el software y los servicios para capturar e ingerir registros y métricas. Un enfoque establecido de registro y supervisión utiliza servicios y soluciones de proveedores de software (ISV) múltiples AWS o independientes para diferentes dominios (por ejemplo, seguridad, rendimiento, redes o análisis). Cada dominio tiene sus propios requisitos de implementación y configuración.
Recomendamos usarlo CloudWatch para capturar e ingerir registros y métricas para varios OSs tipos de procesamiento. Muchos AWS servicios se utilizan CloudWatch para registrar, monitorear y publicar registros y métricas, sin necesidad de configuración adicional. CloudWatch proporciona un [agente de software](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) que se puede instalar y configurar para diferentes OSs entornos. En las siguientes secciones se describe cómo implementar, instalar y configurar el CloudWatch agente para varias cuentas, regiones y configuraciones:
**Topics**
+ [Utilización CloudWatch en cuentas centralizadas o distribuidas](cloudwatch-centralized-distributed-accounts.md)
+ [Administrar los archivos CloudWatch de configuración de los agentes](create-store-cloudwatch-configurations.md)
# Utilización CloudWatch en cuentas centralizadas o distribuidas
Aunque CloudWatch está diseñado para monitorear los AWS servicios o recursos de una cuenta y región, puede usar una cuenta central para capturar registros y métricas de varias cuentas y regiones. Si usa más de una cuenta o región, debe evaluar si desea utilizar el enfoque de cuentas centralizadas o una cuenta individual para capturar registros y métricas. Por lo general, se requiere un enfoque híbrido para las implementaciones con varias cuentas y regiones a fin de cumplir con los requisitos de los propietarios de seguridad, análisis, operaciones y cargas de trabajo.
En la siguiente tabla, se muestran las áreas que se deben tener en cuenta a la hora de elegir un enfoque centralizado, distribuido o híbrido.
****
| | |
| --- |--- |
| Estructuras de cuentas | Su organización puede tener varias cuentas independientes (por ejemplo, cuentas para cargas de trabajo de producción y no relacionadas con la producción) o miles de cuentas para aplicaciones individuales en entornos específicos. Le recomendamos que mantenga los registros y las métricas de las aplicaciones en la cuenta en la que se ejecuta la carga de trabajo, lo que permite a los propietarios de la carga de trabajo acceder a los registros y las métricas. Esto les permite desempeñar un papel activo en el registro y la supervisión. También le recomendamos que utilice una cuenta de registro independiente para agregar todos los registros de carga de trabajo para su análisis, agregación, tendencias y operaciones centralizadas. También se pueden usar cuentas de registro independientes para la seguridad, el archivado, la supervisión y el análisis. |
| Requisitos de acceso | Los miembros del equipo (por ejemplo, los propietarios de las cargas de trabajo o los desarrolladores) necesitan acceder a los registros y las métricas para solucionar problemas y realizar mejoras. Los registros deben mantenerse en la cuenta de la carga de trabajo para facilitar el acceso y la solución de problemas. Si los registros y las métricas se mantienen en una cuenta independiente de la carga de trabajo, es posible que los usuarios tengan que alternar entre cuentas con regularidad. El uso de una cuenta centralizada proporciona información de registro a los usuarios autorizados sin conceder acceso a la cuenta de carga de trabajo. Esto puede simplificar los requisitos de acceso para las cargas de trabajo analíticas cuando se requiere la agregación de las cargas de trabajo que se ejecutan en varias cuentas. La cuenta de registro centralizada también puede tener opciones alternativas de búsqueda y agregación, como un clúster de Amazon OpenSearch Service. Amazon OpenSearch Service [proporciona un control de acceso detallado](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/fgac.html) hasta el nivel de campo para tus registros. Un control de acceso detallado es importante cuando se dispone de datos sensibles o confidenciales que requieren permisos y accesos especializados. |
| Operaciones | Muchas organizaciones tienen un equipo de operaciones y seguridad centralizado o una organización externa de apoyo operativo que requiere acceso a los registros para su supervisión. El registro y la supervisión centralizados pueden facilitar la identificación de tendencias, la búsqueda, la agregación y la realización de análisis en todas las cuentas y cargas de trabajo. Si su organización utiliza el enfoque de «[usted lo crea, lo ejecuta](https://aws.amazon.com//blogs/enterprise-strategy/enterprise-devops-why-you-should-run-what-you-build/)» DevOps, los propietarios de las cargas de trabajo deberán registrar y supervisar la información de sus cuentas. Es posible que se requiera un enfoque híbrido para satisfacer las operaciones y los análisis centrales, además de la propiedad distribuida de las cargas de trabajo. |
| Entorno | Puede optar por alojar los registros y las métricas en una ubicación central para las cuentas de producción y conservar los registros y las métricas de otros entornos (por ejemplo, de desarrollo o de pruebas) en la misma cuenta o en cuentas independientes, según los requisitos de seguridad y la arquitectura de la cuenta. Esto ayuda a evitar que un público más amplio acceda a los datos confidenciales creados durante la producción. |
CloudWatch ofrece [múltiples opciones](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Subscriptions.html) para procesar los registros en tiempo real con filtros de CloudWatch suscripción. Puede utilizar los filtros de suscripción para transmitir los registros en tiempo real a AWS servicios para su procesamiento, análisis y carga personalizados en otros sistemas. Esto puede resultar especialmente útil si adoptas un enfoque híbrido en el que tus registros y métricas estén disponibles en cuentas y regiones individuales, además de en una cuenta y una región centralizadas. La siguiente lista proporciona ejemplos de AWS servicios que se pueden utilizar para ello:
+ [Amazon Data Firehose: Firehose](https://docs.aws.amazon.com//firehose/latest/dev/what-is-this-service.html) proporciona una solución de streaming que escala y cambia el tamaño automáticamente en función del volumen de datos que se esté produciendo. No necesita gestionar el número de fragmentos de una transmisión de datos de Amazon Kinesis y puede conectarse directamente a Amazon Simple Storage Service (Amazon S3), Amazon Service o Amazon OpenSearch Redshift sin necesidad de codificación adicional. Firehose es una solución eficaz si desea centralizar sus registros en esos servicios. AWS
+ [Amazon Kinesis Data](https://docs.aws.amazon.com//streams/latest/dev/introduction.html) Streams: Kinesis Data Streams es una solución adecuada si necesita integrarse con un servicio que Firehose no admite e implementar una lógica de procesamiento adicional. Puede crear un destino de Amazon CloudWatch Logs en sus cuentas y regiones que especifique una transmisión de datos de Kinesis en una cuenta central y una función AWS Identity and Access Management (IAM) que le conceda permiso para colocar registros en la transmisión. Kinesis Data Streams proporciona una zona de aterrizaje flexible y abierta para sus datos de registro que, a su vez, puede ser consumida por diferentes opciones. Puede leer los datos de registro de Kinesis Data Streams en su cuenta, realizar el preprocesamiento y enviar los datos al destino que elija.
Sin embargo, debe configurar las particiones de la transmisión para que tengan el tamaño adecuado para los datos de registro que se generen. Kinesis Data Streams actúa como intermediario temporal o cola para sus datos de registro y puede almacenar los datos en la transmisión de Kinesis durante un período de uno a 365 días. Kinesis Data Streams también admite la función de reproducción, lo que significa que puede reproducir los datos que no se hayan consumido.
+ [Amazon OpenSearch Service](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/what-is.html): CloudWatch los registros pueden transmitir los registros de un grupo de registros a un OpenSearch clúster de una cuenta individual o centralizada. Al configurar un grupo de registros para transmitir datos a un OpenSearch clúster, se crea una función Lambda en la misma cuenta y región que el grupo de registros. La función Lambda debe tener una conexión de red con el OpenSearch clúster. Puede personalizar la función Lambda para realizar un preprocesamiento adicional, además de personalizar la ingesta en Amazon Service. OpenSearch El registro centralizado con Amazon OpenSearch Service facilita el análisis, la búsqueda y la solución de problemas en varios componentes de su arquitectura de nube.
+ [Lambda](https://docs.aws.amazon.com//lambda/latest/dg/welcome.html): si usa Kinesis Data Streams, debe aprovisionar y administrar los recursos de cómputo que consumen datos de su transmisión. Para evitarlo, puede transmitir los datos de registro directamente a Lambda para su procesamiento y enviarlos a un destino según su lógica. Esto significa que no necesita aprovisionar ni administrar los recursos de cómputo para procesar los datos entrantes. [Si decide usar Lambda, asegúrese de que la solución sea compatible con las cuotas de Lambda.](https://docs.aws.amazon.com//lambda/latest/dg/gettingstarted-limits.html)
Es posible que necesite procesar o compartir los datos de registro almacenados en CloudWatch Logs en formato de archivo. Puede crear una tarea de exportación para [exportar un grupo de registros a Amazon S3](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/S3Export.html) para un intervalo de fechas o horas específico. Por ejemplo, puede optar por exportar los registros a diario a Amazon S3 para realizar análisis y auditorías. Lambda se puede utilizar para automatizar esta solución. También puede combinar esta solución con la replicación de Amazon S3 para enviar y centralizar los registros de varias cuentas y regiones a una sola cuenta y región centralizadas.
La configuración del CloudWatch agente también puede especificar un `credentials` campo en la [`agent`sección](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Agentsection). Esto especifica una función de IAM que se utilizará al enviar métricas y registros a una cuenta diferente. Si se especifica, este campo contiene el `role_arn` parámetro. Este campo se puede usar cuando solo necesita el registro y la supervisión centralizados en una cuenta y región centralizadas específicas.
También puede usar el [AWS SDK](https://aws.amazon.com/developer/tools/) para crear su propia aplicación de procesamiento personalizada en el idioma que prefiera, leer los registros y las métricas de sus cuentas y enviar datos a una cuenta centralizada o a otro destino para su posterior procesamiento y supervisión.
# Administrar los archivos CloudWatch de configuración de los agentes
Le recomendamos que cree una configuración de CloudWatch agente de Amazon estándar que incluya los registros y las métricas del sistema que desee capturar en todas sus instancias de Amazon Elastic Compute Cloud (Amazon EC2) y servidores locales. Puede utilizar el [asistente para archivos de configuración](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html) del CloudWatch agente como ayuda para crear el archivo de configuración. Puede ejecutar el asistente de configuración varias veces para generar configuraciones únicas para diferentes sistemas y entornos. También puede modificar el archivo de configuración o crear variantes [mediante el esquema del archivo de configuración](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html). El archivo de configuración del CloudWatch agente se puede almacenar en los parámetros del [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html). Puede crear parámetros de almacén de parámetros independientes si tiene [varios archivos de configuración de CloudWatch agentes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files). Si utiliza varias cuentas de AWS o regiones de AWS, debe gestionar y actualizar los parámetros del almacén de parámetros en cada cuenta y región. Como alternativa, puede gestionar sus CloudWatch configuraciones de forma centralizada como archivos en Amazon S3 o en la herramienta de control de versiones que prefiera.
El `amazon-cloudwatch-agent-ctl` script incluido con el CloudWatch agente le permite especificar un archivo de configuración, un parámetro del almacén de parámetros o la configuración predeterminada del agente. La configuración predeterminada se ajusta al conjunto de métricas básico predefinido y configura el agente para que informe las métricas de memoria y espacio en disco. CloudWatch Sin embargo, no incluye ninguna configuración de archivos de registro. La configuración predeterminada también se aplica si utiliza la [configuración rápida de Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-quick-setup.html) para el CloudWatch agente.
Como la configuración predeterminada no incluye el registro y no está personalizada según sus requisitos, le recomendamos que cree y aplique sus propias CloudWatch configuraciones, personalizadas según sus requisitos.
## Administrar CloudWatch las configuraciones
De forma predeterminada, CloudWatch las configuraciones se pueden almacenar y aplicar como parámetros del almacén de parámetros o como archivos CloudWatch de configuración. La mejor opción dependerá de sus requisitos. En esta sección, analizamos los pros y los contras de estas dos opciones. También se detalla una solución representativa para administrar los archivos de CloudWatch configuración de varias cuentas y regiones de AWS.
**Parámetros del almacén de parámetros de Systems Manager**
El uso de los parámetros del almacén de parámetros para administrar CloudWatch las configuraciones funciona bien si tiene un único archivo de configuración de CloudWatch agente estándar que desea aplicar y administrar en un conjunto reducido de cuentas y regiones de AWS. Al almacenar CloudWatch las configuraciones como parámetros del almacén de parámetros, puede utilizar la herramienta de configuración del CloudWatch agente (`amazon-cloudwatch-agent-ctl`en Linux) para leer y aplicar la configuración desde el almacén de parámetros sin necesidad de copiar el archivo de configuración en la instancia. **Puede utilizar el AmazonCloudWatch documento ManageAgent Systems Manager Command para actualizar la CloudWatch configuración en varias instancias de EC2 en una sola ejecución.** Como los parámetros del almacén de parámetros son regionales, debe actualizar y mantener los CloudWatch parámetros del almacén de parámetros en cada región de AWS y cuenta de AWS. Si tiene varias CloudWatch configuraciones que desea aplicar a cada instancia, debe personalizar el documento **AmazonCloudWatch- ManageAgent** Command**** para incluir estos parámetros.
**CloudWatch archivos de configuración**
Administrar CloudWatch las configuraciones como archivos puede funcionar bien si tiene muchas cuentas y regiones de AWS y administra varios archivos CloudWatch de configuración. Con este enfoque, puede buscarlos, organizarlos y administrarlos en una estructura de carpetas. Puede aplicar reglas de seguridad a carpetas o archivos individuales para limitar y conceder el acceso, como permisos de actualización y lectura. Puede compartirlos y transferirlos fuera de AWS para colaborar. Puede controlar las versiones de los archivos para realizar un seguimiento de los cambios y gestionarlos. Puede aplicar CloudWatch las configuraciones de forma colectiva copiando los archivos de configuración en el directorio de configuración del CloudWatch agente sin aplicar cada archivo de configuración individualmente. Para Linux, el directorio CloudWatch de configuración se encuentra en`/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d`. Para Windows, el directorio de configuración se encuentra en`C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs`.
Al iniciar el CloudWatch agente, el agente agrega automáticamente cada archivo que se encuentra en estos directorios para crear un archivo de configuración CloudWatch compuesto. Los archivos de configuración deben almacenarse en una ubicación central (por ejemplo, un bucket de S3) a la que puedan acceder las cuentas y regiones necesarias. Se proporciona un ejemplo de solución que utiliza este enfoque.
**Organizar CloudWatch las configuraciones**
Independientemente del enfoque utilizado para gestionar CloudWatch las configuraciones, organícelas CloudWatch . Puede organizar las configuraciones en rutas de archivos o almacenes de parámetros mediante un enfoque como el siguiente.
| | |
| --- |--- |
| */config/standard/windows/ec2* | Almacene los archivos de CloudWatch configuración estándar específicos de Windows para Amazon EC2. En esta carpeta, puede clasificar con más detalle las configuraciones de su sistema operativo (SO) estándar para diferentes versiones de Windows, tipos de instancias de EC2 y entornos. |
| */config/standard/windows/onpremises* | Guarde los archivos de CloudWatch configuración estándar específicos de Windows para los servidores locales. También puede clasificar con más detalle las configuraciones de sistema operativo estándar para las diferentes versiones, tipos de servidores y entornos de Windows en esta carpeta. |
| */2 config/standard/linux/ec* | Guarde sus archivos de CloudWatch configuración estándar específicos de Linux para Amazon EC2. En esta carpeta, puede clasificar con más detalle la configuración estándar del sistema operativo para diferentes distribuciones de Linux, tipos de instancias EC2 y entornos. |
| */config/standard/linux/onpremises* | Guarde los archivos de configuración estándar específicos de Linux para CloudWatch los servidores locales. En esta carpeta, puede clasificar con más detalle la configuración estándar del sistema operativo para diferentes distribuciones, tipos de servidores y entornos de Linux. |
| */config/ecs* | CloudWatch Guarde los archivos de configuración específicos de Amazon Elastic Container Service (Amazon ECS) si utiliza instancias de contenedor de Amazon ECS. Estas configuraciones se pueden añadir a las configuraciones estándar de Amazon EC2 para el registro y la supervisión a nivel de sistemas específicos de Amazon ECS. |
| */config/* | Guarde los archivos de configuración específicos de la aplicación CloudWatch . Puede clasificar aún más sus aplicaciones con carpetas y prefijos adicionales para los entornos y las versiones. |
## Ejemplo: almacenar los archivos CloudWatch de configuración en un bucket de S3
En esta sección se proporciona un ejemplo del uso de Amazon S3 para almacenar los archivos de CloudWatch configuración y un manual personalizado de Systems Manager para recuperar y aplicar los archivos de CloudWatch configuración. Este enfoque puede abordar algunos de los desafíos que implica el uso de los parámetros del almacén de parámetros de Systems Manager para CloudWatch la configuración a escala:
+ Si utiliza varias regiones, debe sincronizar las actualizaciones de CloudWatch configuración en el almacén de parámetros de cada región. El almacén de parámetros es un servicio regional y se debe actualizar el mismo parámetro en cada región que utilice el CloudWatch agente.
+ Si tiene varias CloudWatch configuraciones, debe iniciar la recuperación y la aplicación de cada configuración del almacén de parámetros. Debe recuperar individualmente cada CloudWatch configuración del almacén de parámetros y también actualizar el método de recuperación cada vez que añada una nueva configuración. Por el contrario, CloudWatch proporciona un directorio de configuración para almacenar los archivos de configuración y aplica cada configuración del directorio, sin necesidad de especificarlas individualmente.
+ Si utiliza varias cuentas, debe asegurarse de que cada cuenta nueva tenga las CloudWatch configuraciones necesarias en su almacén de parámetros. También debe asegurarse de que cualquier cambio de configuración se aplique a estas cuentas y sus regiones en el futuro.
Puede almacenar CloudWatch las configuraciones en un depósito de S3 al que pueda acceder desde todas sus cuentas y regiones. A continuación, puede copiar estas configuraciones del bucket de S3 al directorio de CloudWatch configuración mediante los manuales de automatización de Systems Manager y el administrador de estado de Systems Manager. Puede usar la plantilla de CloudFormation AWS de [cloudwatch-config-s3 compartimentos .yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) para crear un depósito de S3 al que se pueda acceder desde varias cuentas de una organización en AWS Organizations. [La plantilla incluye un `OrganizationID` parámetro que otorga acceso de lectura a todas las cuentas de su organización.](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
El manual de ejemplo ampliado de Systems Manager, que se incluye en la sección [Configurar State Manager and Distributor para el despliegue y la configuración de los CloudWatch agentes](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/install-cloudwatch-systems-manager.html#set-up-systems-manager-distributor) de esta guía, está configurado para recuperar archivos mediante el depósito de S3 creado por la plantilla AWS [cloudwatch-config-s3-bucket.yaml.](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) CloudFormation
Como alternativa, puede utilizar un sistema de control de versiones (por ejemplo GitHub) para almacenar los archivos de configuración. Si desea recuperar automáticamente los archivos de configuración almacenados en un sistema de control de versiones, debe administrar o centralizar el almacenamiento de credenciales y actualizar el manual de automatización de Systems Manager que se utiliza para recuperar las credenciales de sus cuentas y. Regiones de AWS