Dimarts, febrer 10, 2026

El dia a dia d'un administrador de sistemes

CLOUD & DEVOPS

Monitorització amb CloudWatch per a un servidor Linux

Rafael Quintero

Amazon CloudWatch pot semblar senzill al començament, però com sol passar amb AWS, la documentació oficial cobreix bé el “què” però es queda curta amb el “com” quan el que busques és un sistema funcional, consistent i mantenible per a entorns Linux reals. Això no és una guia pas a pas. Aquí explico com muntar-ho en producció, què pot funcionar (i què no), i els detalls que tendeixen a passar-se per alt fins que t’exploten a la cara.

1. CloudWatch: què ve per defecte i què falta?

Quan llences una instància EC2 amb una AMI estàndard d’Amazon Linux o Ubuntu, tens mètriques bàsiques a CloudWatch des del minut u: CPU, disc root i xarxa. Però no tens res del sistema operatiu real: ús de memòria, particions addicionals, processos, càrrega, ni logs. Això és el primer que cal entendre. Molta gent assumeix que “CloudWatch ho monitoritza tot”, però no és així. El que veus sense configurar res és el que exposa l’ hypervisor, no el sistema.

Per tenir mètriques reals del sistema (memòria, disc, etc.), necessites instal·lar i configurar el CloudWatch Agent. I si vols alguna cosa mitjanament útil, has de personalitzar la seva configuració.

2. Instal·lació del CloudWatch Agent: no l’ automatitzis encara

He vist equips automatitzar la instal·lació de l’agent a Terraform o CloudFormation sense provar-ho abans de forma manual. Error. L’agent és perepunyetes. Depenent de la distribució, el sistema d’arxius, i la política de permisos del teu IAM role, pot fallar sense fer soroll. La millor pràctica és muntar-lo manualment en un entorn controlat, verificar que escriu a CloudWatch, i només llavors integrar la instal·lació a IaC.

Passos mínims a Amazon Linux 2 o Ubuntu:

sudo yum install amazon-cloudwatch-agent -y     # A Amazon Linux
sudo apt install amazon-cloudwatch-agent -y     # A Ubuntu

O si prefereixes el binari:

cd /tmp
curl -O https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/amazon-cloudwatch-agent.deb
sudo dpkg -i -E ./amazon-cloudwatch-agent.deb

3. El fitxer de configuració: més val declaratiu que interactiu

AWS t’ofereix un assistent interactiu (amazon-cloudwatch-agent-config-wizard) que genera un JSON amb la configuració de l’agent. Pot estar bé per començar, però en producció gairebé mai es fa servir. El que podem fer és tenir plantilles JSON versionades, revisades, i adaptades a cada tipus de servidor. Perquè si tens una flota amb rols diferents —per exemple, servidors web, workers, i bases de dades—, no vols el mateix nivell de detall a tots.

Aquí un exemple simplificat d’un fitxer /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json que es pot fer servir com a base:

{
  "agent": {
    "metrics_collection_interval": 60,
    "logfile": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log",
    "run_as_user": "root"
  },
  "metrics": {
    "namespace": "MyApp/Linux",
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}",
      "InstanceType": "${aws:InstanceType}"
    },
    "metrics_collected": {
      "cpu": {
        "measurement": ["usage_idle", "usage_user", "usage_system"],
        "metrics_collection_interval": 60,
        "totalcpu": true
      },
      "mem": {
        "measurement": ["mem_used_percent"],
        "metrics_collection_interval": 60
      },
      "disk": {
        "resources": ["*"],
        "measurement": ["used_percent"],
        "metrics_collection_interval": 60
      },
      "diskio": {
        "measurement": ["io_time"],
        "metrics_collection_interval": 60
      },
      "swap": {
        "measurement": ["swap_used_percent"]
      }
    }
  }
}

Algunes notes:

  1. “namespace” convé personalitzar-lo per no barrejar-lo amb les mètriques per defecte.
  2. “append_dimensions” és clau si fas servir dashboards amb filtres per tipus d’instància.
  3. “resources”: [“*”] en disc funciona, però si tens discos muntats en rutes inusuals (com /mnt/data en EBS), verifica que hi siguin presents.
  4. “run_as_user”: “root” és l’opció menys problemàtica. Executar-lo com un altre usuari requereix ajustos en permisos de /proc, i potser no val la pena.

4. IAM: el que sovint falta als rols

Per a què l’agent funcioni, el role d’IAM associat a la instància ha de tenir permisos per a enviar mètriques i logs a CloudWatch. L’error més comú és oblidar-se d’incloure permisos per a PutMetricData i per a logs:CreateLogStream.

Una política mínima funcional per a l’agent (si no fas servir Systems Manager):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:PutMetricData",
        "ec2:DescribeTags",
        "logs:PutLogEvents",
        "logs:DescribeLogStreams",
        "logs:DescribeLogGroups",

        "logs:CreateLogStream",
        "logs:CreateLogGroup"
      ],
      "Resource": "*"
    }
  ]
}

Si fas servir Systems Manager per a arrencar l’agent remotament o aplicar configuració amb ssm-agent, necessites afegir ssm:SendCommand, ssm:GetParameter, i companyia. Però això complica les coses si no tens ben muntat SSM, així que no és el camí per defecte.

5. Logs: què enviar, què no, i com mantenir-lo net

CloudWatch Logs és útil, però car si et passes. Si envies /var/log/syslog, /var/log/messages o qualsevol log d’app sense filtrar, pots acabar pagant més pels logs que per les instàncies.

El que es pot fer:

  • Només enviar logs rellevants per a alertes o troubleshooting ràpid. Per exemple:
  • /var/log/auth.log
  • Logs de Nginx o Apache si no els tenim centralitzats
  • Logs de processos crítics amb rotació controlada
  • Limitar la mida del batch i la freqüència d’ enviament a la configuració:
"log_stream_name": "{instance_id}-auth",
"timestamp_format": "%b %d %H:%M:%S",
"file_fingerprint_lines": "1",
"multi_line_start_pattern": "^\w{3} \d{1,2} \d{2}:\d{2}:\d{2}",
"buffer_duration": 5000
  • Rotació local: l’ agent no rota logs. Si el fitxer creix, s’envia sencer. Per a evitar-ho, logrotate ben configurat és obligatori. Si el log canvia de nom (com app.log -> app.log.1), l’agent no el segueix automàticament. Assegura’t de mantenir el nom constant o reconfigurar després de rotació.

6. Alertes: quant pots automatitzar sense soroll innecessari

CloudWatch permet crear alarmes en base a mètriques que recopila. L’obvi és posar llindars de CPU, memòria, disc. Però si poses alertes genèriques, tindràs falsos positius i fatiga d’alertes.

Regles que podem seguir:

  • CPU > 90% durant 5 min: només si no tens càrregues per lots o processos cron. En aquests casos, millor 15 minuts i amb almenys 2 períodes consecutius.
  • Memòria: difícil d’interpretar a Linux. L’ ús de swap és el millor indicador. Alerta si swap_used_percent > 30% durant 10 minuts.
  • Disc: alertes si used_percent > 80% en particions específiques. No tot disc ple és crític (e.g. /mnt vs /var).
  • Logs: si activem alertes per logs, és per patrons concrets. Exemple real:
"filterPattern": "?ERROR ?Exception -\"ExpectedException\""
  • Alarma per absència de dades: subestimades. Un servidor que deixa d’enviar mètriques és més greu que un amb CPU alta. Activem alarmes si no hi ha dades en 5 minuts per a qualsevol mètrica crítica.

7. Costos: on es dispara sense que t’ adonis

CloudWatch cobra per:

  • Mètriques personalitzades (0.30 USD per mètrica/mes en algunes regions)
  • Logs (ingestió i emmagatzematge)
  • Quadres
  • Alarmes

En una flota amb desenes de servidors, si no selecciones bé les mètriques personalitzades, acabes amb 30–50 mètriques per node. Multiplica. El que podem fer:

  • Mètriques per servidor → baixem freqüència o fem servir statistic_set si afegim diverses
  • Logs → evitar nivells de debug o verbose
  • Dashboards → fem servir només els compartits, res d’un per node

8. Lliçons apreses i defaults no recomanables

  • El metrics_collection_interval per defecte de 60s està bé per a CPU, però pot ser excessiu per a disc o PSARU. Reduir freqüència estalvia costos.
  • L’agent no reintenta si perd connexió amb CloudWatch. Si hi ha canvis de política IAM en calent, de vegades has de reiniciar el servei (systemctl restart amazon-cloudwatch-agent).
  • Si automatitzes amb Ansible o similar, assegura’t de validar que l’agent està enviant dades, no només que el procés està corrent.
  • No combinis mètriques i logs al mateix namespace. Si separes els logs de sistema i els d’aplicació, després és més fàcil assignar alarmes o revisar històrics.

9. Exemples de configuracions

Aquí van alguns que podem fer servir com a punt de partida, amb notes específiques per a cada cas:

a) Servidor web (Nginx / Apache)

{
  "agent": {
    "metrics_collection_interval": 60
  },
  "metrics": {
    "namespace": "WebServer/Linux",
    "metrics_collected": {
      "cpu": {
        "totalcpu": true
      },
      "mem": {
        "measurement": ["mem_used_percent"]
      },
      "disk": {
        "resources": ["/", "/var/log"],
        "measurement": ["used_percent"]
      },
      "diskio": {
        "measurement": ["io_time"]
      }
    }
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/nginx/access.log",
            "log_group_name": "/nginx/access",
            "log_stream_name": "{instance_id}"
          },
          {
            "file_path": "/var/log/nginx/error.log",
            "log_group_name": "/nginx/error",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}
  • Recollir només les mètriques necessàries.
  • Només monitoritzar /var/log si hi ha risc de saturació.
  • Accés i error logs de Nginx van a CloudWatch, però sense nivells de debug, per a evitar saturació.
  • Si es fan servir rotacions tipus logrotate, ajustar el patró d’arxiu per a seguir la nova ruta (access.log.1 o similars).

b) Worker / proceso batch

Aquí l’enfocament canvia: menys logs, més èmfasi en l’ús de CPU i estat de processos.

{
  "metrics": {
    "namespace": "Batch/Workers",
    "metrics_collected": {
      "cpu": {
        "measurement": ["usage_user", "usage_system"],
        "totalcpu": true
      },
      "mem": {
        "measurement": ["mem_used_percent"]
      },
      "swap": {
        "measurement": ["swap_used_percent"]
      }
    }
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/myapp/worker.log",
            "log_group_name": "/myapp/workers",
            "log_stream_name": "{instance_id}",
            "timestamp_format": "%Y-%m-%d %H:%M:%S",
            "multi_line_start_pattern": "^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}"
          }
        ]

      }
    }
  }
}
  • “multi_line_start_pattern” és clau si els logs del worker tenen traces.
  • Si el worker fa servir molts threads, també mesurar load_average per complementar.
  • Si els workers escriuen logs molt verbosos, els filtrem en origen o fem servir log_level al propi procés.

c) Servidor amb múltiples EBS o punts de muntatge

Error habitual: només configurar mètriques per a /, oblidant /mnt/data, /opt o volums addicionals.

Solució:

"disk": {
  "resources": ["/", "/mnt/data", "/opt"],
  "measurement": ["used_percent"],
  "metrics_collection_interval": 60
}

I sempre validar amb:

df -h | grep -v tmpfs

perquè el que està muntat pot no coincidir amb el que esperes (especialment si hi ha scripts de muntatge dinàmic).

10. Desplegament a escala

Quan cal desplegar l’agent a desenes o centenars de nodes, convé automatitzar, però amb cap. El que funciona millor:

  • Ansible amb un rol específic per a CloudWatch Agent.
    • Defineix variables per tipus de host.
    • Fes servir templates versionats de configuració.
    • Valida amb una tasca post-deploy que revisi si l’agent està corrent i si ha creat el log group.
  • Terraform, només quan l’AMI és immutable.
    • En aquest cas, empaqueta el JSON de configuració directament a l’AMI (Packer o similar).
    • L’ agent s’ arrenca a cloud-init amb un script tipus:
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config -m ec2 \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json \
  -s

L’important és que amazon-cloudwatch-agent-ctl té una lògica rara: si no fas -s al final, no arrenca el servei encara que tot estigui ben configurat.

11. Problemes comuns i el seu diagnòstic

a) L’ agent no envia mètriques i no hi ha errors en el log

  • Verifica si /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log existeix. Si està buit, el servei no està corrent.
  • Executa:
systemctl status amazon-cloudwatch-agent

Si veus errors tipus Permission denied, revisa els permisos IAM.

  • Comprova si hi ha logs en /var/log/messages o syslog.

b) Els logs no apareixen a CloudWatch Logs

  • Confirma que el nom del grup estigui ben escrit i no tingui errors de capitalització.
  • Verifica si tens permisos per a logs:CreateLogGroup, perquè si el grup no existeix i no pot crear-lo, simplement falla.
  • En configuracions amb logrotate, assegura’t que l’agent segueix apuntant al nou fitxer.

c) Mètriques que desapareixen després d’un reinici

  • Si la configuració es fa des d’ amazon-cloudwatch-agent-ctl, sense persistir en amazon-cloudwatch-agent.json, es perd en reiniciar.
  • L’ús fixe de fitxer de configuració en ruta estàndard evita aquest problema.

12. CloudWatch o alternativa?

Hi ha alternatives per a diferents entorns:

  • Datadog: bona integració, però car. Més amigable per a equips de dev, però sobreenginyeria per a només mètriques bàsiques.
  • Prometheus + Node Exporter: molt potent si ja tens Grafana, però exigeix mantenir un altre stack. CloudWatch és preferible per a entorns sense gaire infraestructura paral·lela.
  • Zabbix o Nagios: obsolets per a molts casos moderns, encara que útils en entorns mixtos o on-prem.

CloudWatch té sentit si:

  • Ja estàs a AWS.
  • Vols menys peces que mantenir.
  • Necessites integració nativa amb alertes, Lambda, SNS o escalat automàtic.

No és l’eina més potent ni la més barata, però ben feta servir cobreix el 80% dels casos reals.

Val la pena CloudWatch com a solució de monitorització completa?

Com sempre, depèn. Per a una infraestructura 100% AWS sense gaire complexitat, és una solució raonable. Si ja fas servir Prometheus o Grafana Loki, probablement faràs servir CloudWatch només com a capa mínima o de backup. Però quan tens molts nodes Linux i necessites una cosa simple, nativa i que puguis automatitzar, CloudWatch ben configurat et dona visibilitat decent sense afegir noves dependències.

Això sí: si ho deixes amb els defaults, serà o insuficient o car, i de vegades tots dos.

Muntar monitorització amb CloudWatch a Linux no és complicat, però hi ha massa petits detalls que poden fer que acabis pagant més, rebent menys, o tenint mètriques que no serveixen per a alertar ni per a diagnosticar. Fer-ho bé no implica fer servir tot el que ofereix CloudWatch, sinó configurar només el necessari, de forma declarativa, versionada, i amb automatització progressiva.

Això no substitueix una solució d’observabilitat completa si el teu stack ho necessita, però si necessites saber què passa als teus servidors sense muntar un altre sistema més, CloudWatch és suficient, sempre que ho configuris tu, no com ve per defecte.

Lo principal és entendre què monitoritzar, com s’envia, i què passa si deixa de fer-ho. La resta és només configuració.

You May Also Like

Ús d’ AWS Secrets Manager per a contrasenyes en scripts

Rafael Quintero

Configurar backups automàtics a S3

Rafael Quintero

Automatitzar tasques amb AWS Lambda

Rafael Quintero

Deixa un comentari

L'adreça electrònica no es publicarà. Els camps necessaris estan marcats amb *