Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Pianificazione dell' CloudWatch implementazione
La complessità e la portata di una soluzione di registrazione e monitoraggio dipendono da diversi fattori, tra cui:
+ Quanti ambienti, regioni e account vengono utilizzati e in che modo questo numero potrebbe aumentare.
+ La varietà e i tipi di carichi di lavoro e architetture esistenti.
+ I tipi e i tipi di elaborazione devono essere OSs registrati e monitorati.
+ Se ci sono sia sedi che infrastrutture locali. AWS
+ I requisiti di aggregazione e analisi di più sistemi e applicazioni.
+ Requisiti di sicurezza che impediscono l'esposizione non autorizzata di log e metriche.
+ Prodotti e soluzioni che devono integrarsi con la vostra soluzione di registrazione e monitoraggio per supportare i processi operativi.
È necessario rivedere e aggiornare regolarmente la soluzione di registrazione e monitoraggio con implementazioni di carichi di lavoro nuove o aggiornate. Gli aggiornamenti alla registrazione, al monitoraggio e agli allarmi devono essere identificati e applicati quando si riscontrano problemi. Questi problemi possono quindi essere identificati in modo proattivo e prevenuti in futuro.
È necessario assicurarsi di installare e configurare in modo coerente software e servizi per l'acquisizione e l'acquisizione di log e metriche. Un approccio consolidato di registrazione e monitoraggio utilizza servizi e soluzioni di fornitori di software diversi AWS o indipendenti (ISV) per diversi domini (ad esempio sicurezza, prestazioni, rete o analisi). Ogni dominio ha i propri requisiti di distribuzione e configurazione.
Si consiglia di CloudWatch utilizzarlo per acquisire e inserire log e metriche per diversi OSs tipi di elaborazione. Molti AWS servizi lo utilizzano CloudWatch per registrare, monitorare e pubblicare log e metriche, senza richiedere ulteriori configurazioni. CloudWatch fornisce un [agente software](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) che può essere installato e configurato per diversi ambienti OSs . Le seguenti sezioni descrivono come distribuire, installare e configurare l' CloudWatch agente per più account, regioni e configurazioni:
**Topics**
+ [Utilizzo CloudWatch in account centralizzati o distribuiti](cloudwatch-centralized-distributed-accounts.md)
+ [Gestione dei file di configurazione dell'agente CloudWatch](create-store-cloudwatch-configurations.md)
# Utilizzo CloudWatch in account centralizzati o distribuiti
Sebbene CloudWatch sia progettato per monitorare AWS servizi o risorse in un unico account e regione, è possibile utilizzare un account centrale per acquisire registri e metriche da più account e regioni. Se utilizzi più di un account o di una regione, dovresti valutare se utilizzare l'approccio centralizzato dell'account o un singolo account per acquisire log e metriche. In genere, è necessario un approccio ibrido per le implementazioni con più account e più regioni per supportare i requisiti di sicurezza, analisi, operazioni e proprietari dei carichi di lavoro.
La tabella seguente fornisce le aree da considerare quando si sceglie di utilizzare un approccio centralizzato, distribuito o ibrido.
****
| | |
| --- |--- |
| Strutture degli account | L'organizzazione potrebbe avere diversi account separati (ad esempio, account per carichi di lavoro non di produzione e di produzione) o migliaia di account per singole applicazioni in ambienti specifici. Ti consigliamo di conservare i log e le metriche delle applicazioni nell'account su cui viene eseguito il carico di lavoro, in modo da consentire ai proprietari dei carichi di lavoro di accedere ai log e alle metriche. Ciò consente loro di svolgere un ruolo attivo nella registrazione e nel monitoraggio. Si consiglia inoltre di utilizzare un account di registrazione separato per aggregare tutti i registri dei carichi di lavoro per analisi, aggregazione, tendenze e operazioni centralizzate. È inoltre possibile utilizzare account di registrazione separati per la sicurezza, l'archiviazione, il monitoraggio e l'analisi. |
| Requisiti di accesso | I membri del team (ad esempio, i proprietari dei carichi di lavoro o gli sviluppatori) richiedono l'accesso a log e metriche per risolvere i problemi e apportare miglioramenti. I log devono essere conservati nell'account del carico di lavoro per facilitare l'accesso e la risoluzione dei problemi. Se i log e le metriche vengono conservati in un account separato dal carico di lavoro, gli utenti potrebbero dover alternare regolarmente gli account. L'utilizzo di un account centralizzato fornisce informazioni di registro agli utenti autorizzati senza concedere l'accesso all'account del carico di lavoro. Ciò può semplificare i requisiti di accesso per i carichi di lavoro analitici in cui è richiesta l'aggregazione dei carichi di lavoro eseguiti su più account. L'account di registrazione centralizzato può anche avere opzioni di ricerca e aggregazione alternative, come un cluster Amazon OpenSearch Service. Amazon OpenSearch Service [fornisce un controllo granulare degli accessi](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/fgac.html) ai log fino al livello di campo. Un controllo granulare degli accessi è importante quando si dispone di dati sensibili o riservati che richiedono accessi e autorizzazioni specializzati. |
| Operazioni | Molte organizzazioni dispongono di un team operativo e di sicurezza centralizzato o di un'organizzazione esterna per il supporto operativo che richiede l'accesso ai registri per il monitoraggio. La registrazione e il monitoraggio centralizzati possono semplificare l'identificazione delle tendenze, la ricerca, l'aggregazione e l'esecuzione di analisi su tutti gli account e i carichi di lavoro. Se la tua organizzazione utilizza l'approccio «[tu lo costruisci, lo esegui](https://aws.amazon.com//blogs/enterprise-strategy/enterprise-devops-why-you-should-run-what-you-build/)» DevOps, i proprietari dei carichi di lavoro devono registrare e monitorare le informazioni nel proprio account. Potrebbe essere necessario un approccio ibrido per soddisfare le operazioni e l'analisi centrali, oltre alla proprietà distribuita dei carichi di lavoro. |
| Ambiente | Puoi scegliere di ospitare log e metriche in una posizione centrale per gli account di produzione e conservare log e metriche per altri ambienti (ad esempio, sviluppo o test) nello stesso account o in account separati, a seconda dei requisiti di sicurezza e dell'architettura dell'account. Questo aiuta a impedire l'accesso ai dati sensibili creati durante la produzione da parte di un pubblico più ampio. |
CloudWatch offre [diverse opzioni](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Subscriptions.html) per elaborare i log in tempo reale con filtri di CloudWatch abbonamento. È possibile utilizzare i filtri di abbonamento per trasmettere i log in tempo reale a AWS servizi per l'elaborazione, l'analisi e il caricamento personalizzati su altri sistemi. Ciò può essere particolarmente utile se si adotta un approccio ibrido in cui i log e le metriche sono disponibili in singoli account e regioni, oltre a un account e una regione centralizzati. L'elenco seguente fornisce esempi di AWS servizi che possono essere utilizzati a tale scopo:
+ [Amazon Data Firehose — Firehose](https://docs.aws.amazon.com//firehose/latest/dev/what-is-this-service.html) fornisce una soluzione di streaming che si ridimensiona e si ridimensiona automaticamente in base al volume di dati prodotto. Non è necessario gestire il numero di shard in un flusso di dati Amazon Kinesis e puoi connetterti direttamente ad Amazon Simple Storage Service (Amazon S3) OpenSearch , Amazon Service o Amazon Redshift senza codifica aggiuntiva. Firehose è una soluzione efficace se si desidera centralizzare i log in tali servizi. AWS
+ [Amazon Kinesis Data Streams — Kinesis](https://docs.aws.amazon.com//streams/latest/dev/introduction.html) Data Streams è una soluzione appropriata se è necessario integrarsi con un servizio che Firehose non supporta e implementare una logica di elaborazione aggiuntiva. Puoi creare una destinazione Amazon CloudWatch Logs nei tuoi account e nelle tue regioni che specifichi un flusso di dati Kinesis in un account centrale e un ruolo AWS Identity and Access Management (IAM) che gli conceda l'autorizzazione a inserire record nel flusso. Kinesis Data Streams offre una landing zone flessibile e aperta per i dati di registro, che possono poi essere utilizzati da diverse opzioni. Puoi leggere i dati di registro di Kinesis Data Streams nel tuo account, eseguire la preelaborazione e inviare i dati alla destinazione prescelta.
Tuttavia, è necessario configurare gli shard per lo stream in modo che abbia le dimensioni appropriate per i dati di registro prodotti. Kinesis Data Streams funge da intermediario o coda temporanea per i dati di registro e puoi archiviare i dati all'interno del flusso Kinesis per un periodo compreso tra uno e 365 giorni. Kinesis Data Streams supporta anche la funzionalità di replay, il che significa che puoi riprodurre dati che non sono stati consumati.
+ [Amazon OpenSearch Service](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/what-is.html): CloudWatch i log possono trasmettere i log di un gruppo di log a un OpenSearch cluster in un account individuale o centralizzato. Quando si configura un gruppo di log per lo streaming di dati verso un OpenSearch cluster, viene creata una funzione Lambda nello stesso account e nella stessa regione del gruppo di log. La funzione Lambda deve disporre di una connessione di rete con il OpenSearch cluster. Puoi personalizzare la funzione Lambda per eseguire una preelaborazione aggiuntiva, oltre a personalizzare l'inserimento in Amazon Service. OpenSearch La registrazione centralizzata con Amazon OpenSearch Service semplifica l'analisi, la ricerca e la risoluzione dei problemi tra più componenti della tua architettura cloud.
+ [Lambda](https://docs.aws.amazon.com//lambda/latest/dg/welcome.html): se utilizzi Kinesis Data Streams, devi fornire e gestire le risorse di calcolo che consumano i dati del tuo stream. Per evitare ciò, puoi trasmettere i dati di registro direttamente a Lambda per l'elaborazione e inviarli a una destinazione in base alla tua logica. Ciò significa che non è necessario fornire e gestire le risorse di calcolo per elaborare i dati in arrivo. [Se scegli di utilizzare Lambda, assicurati che la tua soluzione sia compatibile con le quote Lambda.](https://docs.aws.amazon.com//lambda/latest/dg/gettingstarted-limits.html)
Potrebbe essere necessario elaborare o condividere i dati di registro memorizzati in CloudWatch Logs in formato file. Puoi creare un'attività di esportazione per [esportare un gruppo di log in Amazon S3](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/S3Export.html) per una data o un intervallo di tempo specifico. Ad esempio, puoi scegliere di esportare i log su base giornaliera in Amazon S3 per analisi e audit. Lambda può essere utilizzata per automatizzare questa soluzione. Puoi anche combinare questa soluzione con la replica di Amazon S3 per spedire e centralizzare i log da più account e regioni a un unico account e regione centralizzati.
[La configurazione CloudWatch dell'agente può anche specificare un `credentials` campo nella sezione. `agent`](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Agentsection) Questo specifica un ruolo IAM da utilizzare per l'invio di metriche e log a un account diverso. Se specificato, questo campo contiene il parametro. `role_arn` Questo campo può essere utilizzato quando sono necessari solo la registrazione e il monitoraggio centralizzati in un account e in una regione centralizzati specifici.
Puoi anche utilizzare [AWS SDK](https://aws.amazon.com/developer/tools/) per scrivere la tua applicazione di elaborazione personalizzata in una lingua a tua scelta, leggere i log e le metriche dei tuoi account e inviare dati a un account centralizzato o a un'altra destinazione per ulteriori elaborazioni e monitoraggio.
# Gestione dei file di configurazione dell'agente CloudWatch
Ti consigliamo di creare una configurazione standard CloudWatch dell'agente Amazon che includa i log di sistema e i parametri che desideri acquisire su tutte le istanze Amazon Elastic Compute Cloud (Amazon EC2) e i server locali. Puoi utilizzare la [procedura guidata del file di configurazione dell' CloudWatch agente per aiutarti a creare il file](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html) di configurazione. È possibile eseguire la procedura guidata di configurazione più volte per generare configurazioni uniche per sistemi e ambienti diversi. È inoltre possibile modificare il file di configurazione o creare varianti [utilizzando lo schema del file di configurazione](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html). Il file di configurazione CloudWatch dell'agente può essere archiviato nei parametri di [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html). Puoi creare parametri Parameter Store separati se disponi di [più file di configurazione degli CloudWatch agenti](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files). Se utilizzi più account AWS o regioni AWS, devi gestire e aggiornare i parametri di Parameter Store in ogni account e regione. In alternativa, puoi gestire centralmente le CloudWatch configurazioni come file in Amazon S3 o uno strumento di controllo delle versioni a tua scelta.
Lo `amazon-cloudwatch-agent-ctl` script incluso nell' CloudWatch agente consente di specificare un file di configurazione, un parametro Parameter Store o la configurazione predefinita dell'agente. La configurazione predefinita si allinea al set di metriche di base predefinito e configura l'agente per riportare i parametri di memoria e spazio su disco. CloudWatch Tuttavia, non include alcuna configurazione dei file di registro. La configurazione predefinita viene applicata anche se si utilizza [Systems Manager Quick Setup](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-quick-setup.html) per l' CloudWatch agente.
Poiché la configurazione predefinita non include la registrazione e non è personalizzata in base alle esigenze dell'utente, si consiglia di creare e applicare CloudWatch configurazioni personalizzate, personalizzate in base alle proprie esigenze.
## Gestione delle configurazioni CloudWatch
Per impostazione predefinita, CloudWatch le configurazioni possono essere archiviate e applicate come parametri di Parameter Store o come CloudWatch file di configurazione. La scelta migliore dipenderà dalle vostre esigenze. In questa sezione, discutiamo i pro e i contro di queste due opzioni. Viene inoltre fornita una soluzione rappresentativa per la gestione dei file di CloudWatch configurazione per più account AWS e regioni AWS.
**Parametri del Parameter Store di Systems Manager**
L'utilizzo dei parametri Parameter Store per gestire CloudWatch le configurazioni funziona bene se disponi di un unico file di configurazione standard CloudWatch dell'agente che desideri applicare e gestire in un piccolo set di account e regioni AWS. Quando memorizzi le CloudWatch configurazioni come parametri di Parameter Store, puoi utilizzare lo strumento di configurazione dell' CloudWatch agente (`amazon-cloudwatch-agent-ctl`su Linux) per leggere e applicare la configurazione da Parameter Store senza dover copiare il file di configurazione sull'istanza. È possibile utilizzare il documento **AmazonCloudWatch- ManageAgent ** Systems Manager Command per aggiornare la CloudWatch configurazione su più istanze EC2 in un'unica esecuzione. Poiché i parametri di Parameter Store sono regionali, è necessario aggiornare e mantenere i CloudWatch parametri di Parameter Store in ogni regione AWS e account AWS. Se hai più CloudWatch configurazioni da applicare a ciascuna istanza, devi personalizzare il documento **AmazonCloudWatch- ManageAgent** Command**** per includere questi parametri.
**CloudWatch file di configurazione**
La gestione CloudWatch delle configurazioni come file potrebbe funzionare bene se disponi di molti account e regioni AWS e gestisci più file di CloudWatch configurazione. Utilizzando questo approccio, puoi sfogliarli, organizzarli e gestirli in una struttura di cartelle. È possibile applicare regole di sicurezza a singole cartelle o file per limitare e concedere l'accesso, ad esempio autorizzazioni di aggiornamento e lettura. Puoi condividerli e trasferirli al di fuori di AWS per la collaborazione. Puoi controllare la versione dei file per tracciare e gestire le modifiche. È possibile applicare CloudWatch le configurazioni collettivamente copiando i file di configurazione nella directory di configurazione dell' CloudWatch agente senza applicare ogni file di configurazione singolarmente. Per Linux, la directory di CloudWatch configurazione si trova all'indirizzo. `/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d` Per Windows, la directory di configurazione si trova in`C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs`.
Quando si avvia l' CloudWatch agente, l'agente aggiunge automaticamente ogni file trovato in queste directory per creare un file di configurazione CloudWatch composito. I file di configurazione devono essere archiviati in una posizione centrale (ad esempio, un bucket S3) a cui possono accedere gli account e le regioni richiesti. Viene fornito un esempio di soluzione che utilizza questo approccio.
**Organizzazione delle CloudWatch configurazioni**
Indipendentemente dall'approccio utilizzato per gestire le CloudWatch configurazioni, organizza le CloudWatch configurazioni. È possibile organizzare le configurazioni in percorsi di file o Parameter Store utilizzando un approccio come il seguente.
| | |
| --- |--- |
| */2 config/standard/windows/ec* | Archivia file di CloudWatch configurazione standard specifici per Windows per Amazon EC2. Puoi classificare ulteriormente le configurazioni del sistema operativo (OS) standard per diverse versioni di Windows, tipi di istanze EC2 e ambienti in questa cartella. |
| */config/standard/windows/onpremises* | Archivia i file di CloudWatch configurazione standard specifici di Windows per i server locali. In questa cartella puoi inoltre classificare ulteriormente le configurazioni del sistema operativo standard per diverse versioni di Windows, tipi di server e ambienti. |
| */2 config/standard/linux/ec* | Archivia i tuoi file di CloudWatch configurazione standard specifici per Linux per Amazon EC2. Puoi classificare ulteriormente la configurazione del sistema operativo standard per diverse distribuzioni Linux, tipi di istanze EC2 e ambienti in questa cartella. |
| */config/standard/linux/onpremises* | Archivia i tuoi file di configurazione standard specifici per Linux CloudWatch per i server locali. È possibile classificare ulteriormente la configurazione del sistema operativo standard per diverse distribuzioni Linux, tipi di server e ambienti in questa cartella. |
| */config/ecs* | Archivia i file di CloudWatch configurazione specifici di Amazon Elastic Container Service (Amazon ECS) se utilizzi istanze di container Amazon ECS. Queste configurazioni possono essere aggiunte alle configurazioni standard di Amazon EC2 per la registrazione e il monitoraggio a livello di sistema specifici di Amazon ECS. |
| */config/* | Archivia i file di configurazione specifici dell'applicazione CloudWatch . È possibile classificare ulteriormente le applicazioni con cartelle e prefissi aggiuntivi per ambienti e versioni. |
## Esempio: memorizzazione dei file CloudWatch di configurazione in un bucket S3
Questa sezione fornisce un esempio di utilizzo di Amazon S3 per archiviare i file di CloudWatch configurazione e un runbook Systems Manager personalizzato per recuperare e applicare i file di configurazione. CloudWatch Questo approccio può risolvere alcune delle sfide legate all'utilizzo dei parametri di Systems Manager Parameter Store per la CloudWatch configurazione su larga scala:
+ Se si utilizzano più regioni, è necessario sincronizzare gli aggiornamenti di CloudWatch configurazione nell'archivio dei parametri di ciascuna regione. Parameter Store è un servizio regionale e lo stesso parametro deve essere aggiornato in ogni regione che utilizza l' CloudWatch agente.
+ Se si dispone di più CloudWatch configurazioni, è necessario avviare il recupero e l'applicazione di ciascuna configurazione di Parameter Store. È necessario recuperare singolarmente ogni CloudWatch configurazione dal Parameter Store e aggiornare anche il metodo di recupero ogni volta che si aggiunge una nuova configurazione. Al contrario, CloudWatch fornisce una directory di configurazione per l'archiviazione dei file di configurazione e applica ogni configurazione nella directory, senza richiedere che vengano specificate singolarmente.
+ Se si utilizzano più account, è necessario assicurarsi che ogni nuovo account disponga CloudWatch delle configurazioni richieste nel relativo Parameter Store. È inoltre necessario assicurarsi che eventuali modifiche alla configurazione vengano applicate a questi account e alle relative regioni in futuro.
Puoi archiviare CloudWatch le configurazioni in un bucket S3 accessibile da tutti i tuoi account e regioni. È quindi possibile copiare queste configurazioni dal bucket S3 nella directory di CloudWatch configurazione utilizzando i runbook di Systems Manager Automation e Systems Manager State Manager. Puoi utilizzare il modello CloudFormation AWS [cloudwatch-config-s3-bucket.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) per creare un bucket S3 accessibile da più account all'interno di un'organizzazione in AWS Organizations. [Il modello include un `OrganizationID` parametro che garantisce l'accesso in lettura a tutti gli account all'interno dell'organizzazione.](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
[Il runbook di esempio aumentato di Systems Manager, fornito nella sezione [Configurare State Manager and Distributor per la distribuzione e la configurazione degli CloudWatch agenti](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/install-cloudwatch-systems-manager.html#set-up-systems-manager-distributor) di questa guida, è configurato per recuperare i file utilizzando il bucket S3 creato dal modello 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
In alternativa, puoi utilizzare un sistema di controllo della versione (ad esempio) per archiviare i file di configurazione. GitHub Se desideri recuperare automaticamente i file di configurazione archiviati in un sistema di controllo delle versioni, devi gestire o centralizzare l'archiviazione delle credenziali e aggiornare il runbook di Systems Manager Automation utilizzato per recuperare le credenziali tra i tuoi account e. Regioni AWS