Su Amazon Linux 2023 il CloudWatch Agent conviene trattarlo come un componente di osservabilità, non come un pacchetto “da mettere e dimenticare”. L’installazione è rapida, ma il punto vero è capire cosa vuoi misurare, con quale identità IAM e come verificare che i dati arrivino davvero in CloudWatch senza esporre segreti o creare rumore inutile.
La scelta più pulita è: installazione dal repository Amazon, configurazione minima, validazione locale dei log del servizio, poi attivazione graduale delle metriche e dei log che ti servono. Se salti la verifica iniziale, finisci facilmente con un agente installato ma silente, oppure con permessi IAM troppo larghi per accelerare il primo test.
Quando ha senso usarlo su Amazon Linux 2023
CloudWatch Agent è utile quando vuoi portare in CloudWatch metriche di sistema più ricche di quelle base: memoria, swap, disco per mountpoint, processi selezionati, log applicativi, metriche custom e, se serve, raccolta di eventi dal file system o dal journal. Su AL2023 hai un sistema moderno con dnf e systemd, quindi l’integrazione è lineare, ma il comportamento resta quello di un demone che va osservato come qualsiasi altro servizio di produzione.
Se hai bisogno solo di CPU, network, disk I/O e status EC2 base, spesso bastano le metriche native di EC2. Se invece devi correlare saturazione memoria, spazio disco e log applicativi, l’agente diventa la strada più utile. In pratica: meno pannellino “gadget”, più visibilità operativa.
Prerequisiti minimi che evitano falsi positivi
Prima di installare, chiarisci tre cose: istanza EC2 con role IAM attaccato, connettività in uscita verso gli endpoint CloudWatch e permessi locali per scrivere i file di configurazione sotto /opt/aws/amazon-cloudwatch-agent/. Se manca uno di questi punti, l’agente può partire ma non pubblicare nulla.
La parte IAM è quella che viene spesso sottovalutata. Per il primo avvio non serve una policy monolitica: bastano i permessi per inviare metriche e, se raccolti, log. Se vuoi essere rigoroso, usa un role dedicato all’istanza e una policy minima. Evita access key in chiaro nel filesystem: non serve e ti complica la rotazione.
Controllo rapido della connettività e del sistema:
curl -I https://monitoring.eu-west-1.amazonaws.com/ 2>/dev/null | head -n 1
systemctl --version
uname -r
Il primo comando non ti dice tutto, ma ti conferma che l’istanza può almeno raggiungere un endpoint pubblico AWS. Se usi VPC endpoint o proxy, la verifica va fatta sul percorso reale, non su internet generico.
Installazione del pacchetto su Amazon Linux 2023
Su AL2023 l’installazione passa normalmente dal repository Amazon. Il nome del pacchetto può variare leggermente a seconda della build, quindi il primo comando utile è cercarlo invece di assumere che sia già presente.
sudo dnf search amazon-cloudwatch-agent
sudo dnf install -y amazon-cloudwatch-agent
Se il pacchetto non compare, non forzare workaround strani: verifica i repository abilitati e la connettività ai mirror. In ambienti chiusi o con immagini personalizzate, il problema è quasi sempre lì, non nel nome del pacchetto.
Dopo l’installazione, controlla che il servizio sia presente e disabilitato fino alla configurazione, oppure già pronto ma fermo. Il punto è capire lo stato reale prima di lanciare a occhi chiusi un enable permanente.
systemctl status amazon-cloudwatch-agent --no-pager
rpm -qi amazon-cloudwatch-agent
Il pacchetto installato non basta: l’agente cerca una configurazione valida, e senza quella può uscire subito o restare in uno stato apparentemente attivo ma inutile. Per questo la parte successiva è la più importante.
Configurazione iniziale: partire piccolo e verificabile
Il modo meno rischioso è creare una configurazione minima che raccolga una sola metrica o un solo gruppo di log, validarla, poi estendere. Per esempio: memoria, swap e disco. Sono tre segnali che dicono molto sulla salute della macchina e sono facili da correlare con i problemi reali.
Il file di configurazione standard viene spesso gestito in JSON sotto /opt/aws/amazon-cloudwatch-agent/bin/config.json o in un percorso simile scelto dall’installazione guidata. Non fissarti sul percorso “magico”: quello che conta è che il servizio punti al file giusto e che il contenuto sia sintatticamente corretto.
Esempio di configurazione minima per metriche di base:
{
"metrics": {
"metrics_collected": {
"mem": {
"measurement": ["mem_used_percent"]
},
"swap": {
"measurement": ["swap_used_percent"]
},
"disk": {
"measurement": ["used_percent"],
"resources": ["/"]
}
},
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
},
"aggregation_dimensions": [["InstanceId"]]
}
}
Questa configurazione è intenzionalmente sobria. Non tenta di raccogliere tutto, non spara metriche su ogni mountpoint, non introduce log collection se non serve. È la base giusta per capire se il flusso funziona.
Caricamento della configurazione e avvio del servizio
Il CloudWatch Agent include un binario di controllo che legge il file JSON e scrive la configurazione nel formato operativo del servizio. Usalo invece di copiare a mano file interni: riduci errori e mantieni il percorso supportato.
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config \
-m ec2 \
-c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json \
-s
Il parametro -s avvia il servizio dopo il fetch della configurazione. Se usi un file differente, cambia il path in modo esplicito e tienilo sotto controllo versione, almeno con un backup locale prima di toccarlo.
Verifica immediata del servizio:
systemctl status amazon-cloudwatch-agent --no-pager
journalctl -u amazon-cloudwatch-agent -n 100 --no-pager
Nel journal cerchi due cose: assenza di errori di parsing e assenza di errori di autorizzazione verso CloudWatch. Se vedi messaggi di AccessDenied, il problema è IAM; se vedi errori di endpoint o timeout, è rete o DNS; se vedi errori di JSON, è configurazione.
Permessi IAM: il punto che rompe più spesso la prima installazione
Per pubblicare metriche e, se necessario, log, l’istanza deve avere un role associato. La policy minima dipende da cosa raccogli, ma per una base operativa spesso servono permessi per cloudwatch:PutMetricData e per la pipeline dei log se li invii a CloudWatch Logs.
Non copiare policy eccessive “per farlo andare”. È una scorciatoia che poi resta lì per mesi. Se devi partire veloce, fai un role dedicato all’istanza con il minimo indispensabile e amplia solo dopo aver visto il traffico reale nel servizio CloudWatch.
Se l’agente non riesce a pubblicare, il journal è il primo posto da leggere. In alternativa, controlla il ruolo associato all’istanza da console EC2 e verifica che non sia un profilo vuoto o quello sbagliato. È un errore banale, ma molto comune quando si clona un’AMI o si sostituisce l’istanza in autoscaling.
Raccolta dei log applicativi: quando serve e come non fare danni
La raccolta dei log è utile quando vuoi correlare errori applicativi e sintomi infrastrutturali. Però va trattata con disciplina: non mandare tutto a CloudWatch solo perché “si può”. Scegli file specifici, ruota correttamente i log e evita di includere path temporanei o file ad alta cardinalità che generano costi e rumore.
Un esempio semplice per un log di servizio web potrebbe essere questo:
{
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/var/log/messages",
"log_group_name": "/ec2/system/messages",
"log_stream_name": "{instance_id}"
}
]
}
}
}
}
Su Amazon Linux 2023 il journal di systemd è spesso più utile del vecchio log “monolitico” in molti casi. Se vuoi raccogliere eventi di servizio specifici, valuta se conviene esportare il journal o un file applicativo già strutturato. La scelta migliore è quella che ti permette di fare query sensate, non quella che produce più righe.
Verifica operativa: come capire se funziona davvero
La verifica non si fa solo con systemctl is-active. Quello ti dice che il processo esiste, non che sta inviando dati. La prova vera è vedere metriche e, se configurati, log nel namespace o nel log group atteso.
Controlli utili in ordine:
- Stato servizio:
systemctl is-active amazon-cloudwatch-agentdeve restituireactive. - Log locale:
journalctl -u amazon-cloudwatch-agent -n 50 --no-pagernon deve mostrare errori di autenticazione o parsing. - Metriche CloudWatch: nel namespace configurato devono comparire i dati entro pochi minuti.
- Log group: se abilitati, i nuovi eventi devono arrivare con ritardo contenuto, non “ore dopo”.
Se vuoi un controllo più diretto dal lato AWS CLI, puoi interrogare le metriche appena pubblicate. L’obiettivo non è automatizzare tutto subito, ma avere una prova ripetibile che chiuda il dubbio “sta solo girando o sta anche parlando con CloudWatch?”.
aws cloudwatch list-metrics --namespace "CWAgent" --region eu-west-1
Se il namespace è diverso, cambia in base alla configurazione. Se la lista è vuota dopo un tempo ragionevole, il problema è quasi sempre in uno di questi punti: policy IAM, configurazione errata, regione sbagliata, o connettività bloccata.
Problemi tipici e come isolarli in pochi minuti
Il guasto più comune è il classico triangolo: configurazione non caricata, permessi insufficienti, endpoint non raggiungibile. In quel caso la strategia giusta è non cambiare tre cose insieme. Parti dal journal, poi verifica il file di configurazione, poi la role.
Se il servizio non parte, cerca errori di sintassi nel JSON o path errati. Se parte ma non pubblica, guarda AccessDenied o timeout. Se pubblica solo una parte delle metriche, verifica i mountpoint e i nomi delle interfacce: in ambienti con volumi multipli o naming non standard è facile chiedere al sistema di monitorare la cosa sbagliata.
Un’altra trappola è la regione. L’agente può essere configurato correttamente ma inviare dati alla regione sbagliata rispetto a dove stai guardando la console. È un errore semplice, ma in incidenti reali fa perdere tempo perché sembra che “non arrivi niente”, mentre arriva altrove.
Approccio reversibile: prima osserva, poi estendi
Se devi portare CloudWatch Agent su più istanze, evita di fare un rollout largo senza una macchina pilota. Installa su una sola EC2, verifica metriche e log, poi replica il profilo. Questo riduce il blast radius e ti lascia un punto di confronto pulito nel caso qualcosa vada storto.
Il rollback è semplice se hai mantenuto separati installazione e configurazione: puoi fermare il servizio, rimuovere la configurazione aggiunta e, se serve, disinstallare il pacchetto. Prima di farlo, conserva il journal e il file JSON; sono la tua evidenza per capire cosa non ha funzionato.
sudo systemctl stop amazon-cloudwatch-agent
sudo dnf remove -y amazon-cloudwatch-agent
Questi comandi sono il rollback operativo più diretto, ma usali solo se l’agente è stato introdotto come change controllato e non è legato ad altri componenti. Se la configurazione è stata distribuita via automazione, annulla anche il template o il file generato, altrimenti il problema si ripresenta al prossimo run.
Scelta pratica della configurazione: cosa monitorare davvero
Per una singola istanza Linux in produzione io partirei con memoria, swap, disco root, load e, se applicabile, un paio di log applicativi. Non mi interessa avere 40 metriche per macchina se poi nessuno le usa. Mi interessa avere segnali che anticipino il problema: disco che sale, swap che compare, memoria che si assottiglia, errori applicativi che aumentano.
Se l’istanza è web, aggiungerei il log del web server o del reverse proxy. Se è un nodo applicativo, preferirei i log del processo o del container runtime. Se è una macchina di supporto, monitorerei soprattutto disco e memoria, perché sono le prime cose che degradano in silenzio.
La regola operativa è semplice: ogni metrica deve avere uno scopo. Se non sai quale decisione prenderai quando la vedi peggiorare, probabilmente non ti serve.
Comando di controllo finale e comportamento atteso
Dopo la configurazione, il test minimo è questo:
systemctl is-active amazon-cloudwatch-agent
journalctl -u amazon-cloudwatch-agent -n 20 --no-pager
Atteso: active e nessun errore ricorrente nel journal. Se vedi riavvii continui, il servizio sta fallendo all’avvio e va corretto prima di pensare alla dashboard. Se vedi un avvio regolare ma nessuna metrica, il problema è a valle, quasi sempre IAM o rete.
In una procedura ben fatta, il risultato finale non è “ho installato il pacchetto”, ma “ho dati affidabili e so come ripristinare lo stato precedente”. È questa la differenza tra una installazione e un’operazione utile in produzione.
Assunzione operativa: l’istanza è una EC2 su Amazon Linux 2023 con accesso in uscita agli endpoint AWS necessari e con role IAM gestibile senza secret statici in chiaro.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.