Tanquem el capítol d'observabilitat amb dues eines molt populars en el món del codi obert que AWS ofereix com a serveis gestionats: Prometheus (per recopilar i emmagatzemar mètriques) i Grafana (per visualitzar-les en panells preciosos). Són l'estàndard de facto en moltes empreses, especialment amb Kubernetes, i entendre què són i per què utilitzar-los en la seva versió gestionada t'obre la porta a un ecosistema enorme.
El context: l'ecosistema open source d'observabilitat
A més de CloudWatch (l'eina nativa d'AWS), existeix un ecosistema d'eines de codi obert molt estès per a observabilitat. Dues de les més populars són:
- Prometheus: per recopilar i emmagatzemar mètriques.
- Grafana: per visualitzar aquestes mètriques (i d'altres) en panells.
Molta gent les fa servir juntes i són gairebé un estàndard, sobretot en entorns amb Kubernetes (recorda EKS, subcapítol 17.4). El problema: instal·lar-les i mantenir-les tu mateix dóna feina (servidors, actualitzacions, escalat, còpies...). Per això AWS ofereix versions gestionades d'ambdues, on AWS s'encarrega de tota aquesta operació (recorda la idea de «servei gestionat» que vam veure amb RDS al Capítol 8).
Què és Prometheus (i Managed Prometheus)
Prometheus és un sistema de codi obert per recopilar i emmagatzemar mètriques, molt popular, especialment en el món dels contenidors i Kubernetes. Recull mètriques de les teves aplicacions i serveis i les guarda de manera optimitzada per consultar-les.
Amazon Managed Service for Prometheus és la versió gestionada que ofereix AWS: tu utilitzes Prometheus, però AWS s'encarrega dels servidors, l'escalat, la disponibilitat i el manteniment. Tu et centres en les teves mètriques, no en operar la infraestructura de Prometheus.
Les teves aplicacions / Kubernetes
│ (emeten mètriques)
▼
Managed Prometheus (recull i emmagatzema les mètriques)
│ AWS gestiona els servidors, escalat, disponibilitat...
▼
llestes per consultar i visualitzarAnalogia: Prometheus és com un magatzem especialitzat a guardar mesuraments (milions de números al llarg del temps), molt ben organitzat per trobar-los ràpid. La versió gestionada és com llogar aquest magatzem amb tot el personal inclòs: tu hi poses i consultes les mesuraments, però no t'has de preocupar de mantenir l'edifici, la seguretat ni d'ampliar-lo quan s'omple. AWS ho opera per tu.
Què és Grafana (i Managed Grafana)
Grafana és una eina de codi obert per visualitzar dades en panells (dashboards) molt potents, flexibles i atractius. És famosa per les seves gràfiques espectaculars i per poder ajuntar dades de moltes fonts diferents en un mateix panell (de Prometheus, de CloudWatch, de bases de dades...).
Amazon Managed Grafana és la versió gestionada: AWS opera Grafana per tu (servidors, actualitzacions, escalat, seguretat), i tu només crees i utilitzes els teus dashboards.
┌──────────── Dashboard de Grafana ────────────┐ │ Dades de Managed Prometheus + CloudWatch │ │ + base de dades + altres fonts, JUNTS │ │ 📊 gràfiques potents i personalitzables │ └───────────────────────────────────────────────┘
Analogia: Grafana és com un estudi de disseny de panells de control professional: agafa dades d'on sigui i les converteix en pantalles visuals clares, boniques i molt configurables. La versió gestionada és contractar aquest estudi «clau en mà»: tu dissenyes els teus panells, però no mantens el local ni els equips.
Com treballen junts Prometheus i Grafana
La combinació clàssica és Prometheus recull, Grafana visualitza:
Aplicacions → Managed Prometheus (recull i guarda mètriques)
│
▼
Managed Grafana (visualitza aquestes mètriques en dashboards)Prometheus és el «magatzem de números» i Grafana la «pantalla bonica» que els mostra. Junts formen una solució d'observabilitat completa i molt utilitzada a la indústria.
Per què utilitzar aquestes versions gestionades?
La pregunta clau: si ja existeix CloudWatch, per què utilitzar Prometheus i Grafana gestionats? Raons habituals:
- Estàndard de la indústria: Prometheus i Grafana són l'estàndard de facto en moltíssimes empreses, sobretot amb Kubernetes. Si el teu equip ja els coneix o el teu ecosistema els utilitza, té molt sentit.
- Sense el dolor d'operar-los: obtens aquestes potents eines open source sense haver-les d'instal·lar ni mantenir (AWS ho fa).
- Flexibilitat de Grafana: Grafana pot ajuntar dades de moltes fonts (Prometheus, CloudWatch, altres núvols, bases de dades...) en un mateix panell, ideal per a entorns multi-núvol o híbrids.
- Portabilitat: com que són eines estàndard, la teva inversió en dashboards i configuració és portable (encaixa amb la filosofia d'OpenTelemetry del subcapítol 24.4: evitar el lock-in).
Exemple del món real: una empresa que executa les seves aplicacions en Kubernetes (EKS) ja utilitza Prometheus i Grafana, com és habitual en aquest món. En lloc de mantenir aquests sistemes ells mateixos (amb la feina d'operació que comporta), adopten Managed Prometheus i Managed Grafana. Conserven exactament les eines que el seu equip domina, els seus dashboards funcionen igual, però ara AWS s'ocupa de mantenir-los disponibles i escalats. A més, a Grafana ajunten en un mateix panell les mètriques de Prometheus i algunes de CloudWatch, tenint una visió unificada. El millor dels dos mons: eines estàndard que coneixen, operades per AWS.
CloudWatch vs Prometheus/Grafana: quin?
No és que un sigui millor; depèn del context:
| CloudWatch | Managed Prometheus + Grafana | |
|---|---|---|
| Origen | Natiu d'AWS | Open source (estàndard de la indústria) |
| Integració amb AWS | Total i immediata | Bona, però menys «nativa» |
| Ideal si | Estàs centrat en AWS i vols el més simple | Utilitzes Kubernetes, multi-núvol, o el teu equip ja domina aquestes eines |
| Portabilitat | Lligada a AWS | Alta (eines estàndard) |
Per començar i si només utilitzes AWS, CloudWatch és el més directe. Si vens del món Kubernetes/open source o treballes multi-núvol, Prometheus + Grafana gestionats encaixen millor.
El que has de recordar
- Existeix un ecosistema open source d'observabilitat molt estès; dues peces clau són Prometheus (recull i emmagatzema mètriques) i Grafana (les visualitza en dashboards), molt utilitzades juntes, sobretot amb Kubernetes.
- AWS ofereix versions gestionades: Amazon Managed Service for Prometheus i Amazon Managed Grafana, on AWS opera els servidors, escalat i manteniment (com qualsevol servei gestionat).
- Prometheus = «magatzem de mesuraments» optimitzat; Grafana = «estudi de panells» que ajunta dades de moltes fonts en gràfiques potents. Combinació clàssica: Prometheus recull, Grafana visualitza.
- S'utilitzen per ser l'estàndard de la indústria (especialment amb Kubernetes), per evitar el dolor d'operar-los, per la flexibilitat de Grafana amb múltiples fonts, i per la seva portabilitat (sense lock-in, en línia amb OpenTelemetry).
- CloudWatch és ideal si et centres en AWS i vols simplicitat; Prometheus + Grafana gestionats, si utilitzes Kubernetes/multi-núvol o el teu equip ja els domina.
Has completat el Capítol 24 i, amb ell, domines l'observabilitat a AWS: logs, mètriques, alarmes, dashboards, traçat distribuït, l'estàndard OpenTelemetry i les eines gestionades open source! Al Capítol 25 abordarem un altre aspecte crucial d'operar al núvol: la optimització de costos.
Cloud, AWS & Terraform — De zero a expert
Capítol 1 · Què és el cloud computing
- 1.1 El model client-servidor tradicional
- 1.2 Problemes que venia a resoldre el núvol
- 1.3 On-premise vs cloud vs híbrid
- 1.4 Els tres models de servei: IaaS, PaaS, SaaS
- 1.5 Els cinc pilars del cloud (segons NIST)
- 1.6 Avantatges reals: elasticitat, pagament per ús, disponibilitat global
Capítol 2 · El mercat cloud i els grans proveïdors
- 2.1 AWS, Azure i GCP: diferències i quotes de mercat
- 2.2 Per què aprendre AWS primer
- 2.3 Conceptes que són universals entre proveïdors
Capítol 3 · Regions, zones de disponibilitat i edge
- 3.1 Què és una regió AWS i com triar-la
- 3.2 Availability Zones: alta disponibilitat des del disseny
- 3.3 Edge locations i CloudFront
- 3.4 Latència, resiliència i sobirania de dades
Capítol 4 · Càlcul: EC2
- 4.1 Instàncies: tipus, famílies i quan triar cadascuna
- 4.2 AMIs, key pairs i Security Groups
- 4.3 Cicle de vida d'una instància
- 4.4 Elastic IPs i Placement Groups
- 4.5 Savings Plans vs Reserved vs On-Demand vs Spot
Capítol 5 · Emmagatzematge: S3
- 5.1 Buckets, objectes i claus
- 5.2 Classes d'emmagatzematge (Standard, IA, Glacier…)
- 5.3 Versionat i cicle de vida d'objectes
- 5.4 Polítiques de bucket i ACLs
- 5.5 Hosting de llocs web estàtics
Capítol 6 · Xarxes: VPC
- 6.1 Què és una VPC i per què la necessites
- 6.2 Subxarxes públiques i privades
- 6.3 Internet Gateway i NAT Gateway
- 6.4 Route Tables i Network ACLs
- 6.5 VPC Peering i endpoints
Capítol 7 · Identitat i accés: IAM
- 7.1 Usuaris, grups, rols i polítiques
- 7.2 El principi de mínim privilegi
- 7.3 Polítiques basades en identitat vs en recurs
- 7.4 MFA i credencials temporals (STS)
- 7.5 Bones pràctiques de seguretat IAM
Capítol 8 · Bases de dades gestionades
- 8.1 RDS: motors, Multi-AZ i rèpliques de lectura
- 8.2 Aurora i els seus avantatges sobre RDS vanilla
- 8.3 DynamoDB: model clau-valor / documents
- 8.4 ElastiCache per a memòria cau en memòria
- 8.5 Quan utilitzar cada tipus de base de dades
Capítol 9 · Per què Infraestructura com a Codi
- 9.1 Problemes del provisionament manual
- 9.2 IaC declaratiu vs imperatiu
- 9.3 Terraform vs CloudFormation vs Pulumi vs CDK
- 9.4 El cicle plan → apply → destroy
Capítol 10 · HCL: el llenguatge de Terraform
- 10.1 Blocs resource, variable, output, locals
- 10.2 Tipus de dades: string, number, bool, list, map, object
- 10.3 Expressions, referències i funcions built-in
- 10.4 Condicionals i bucles (count, for_each, for)
Capítol 11 · Providers i estat
- 11.1 Com funciona el provider d'AWS
- 11.2 El fitxer terraform.tfstate i la seva importància
- 11.3 State local vs state remot (S3 + DynamoDB)
- 11.4 Comandes essencials: init, plan, apply, destroy, fmt, validate
Capítol 12 · La teva primera infraestructura real amb Terraform
- 12.1 Crear una VPC amb subxarxes des de zero
- 12.2 Posar en marxa una instància EC2 pública
- 12.3 Associar un Security Group i una Elastic IP
- 12.4 Outputs i referències entre recursos
- 12.5 Flux de treball en equip: PR review de plans
Capítol 13 · Balanceig de càrrega i autoescalat
- 13.1 Application Load Balancer vs Network Load Balancer
- 13.2 Target Groups, listeners i regles
- 13.3 Auto Scaling Groups: polítiques i mètriques
- 13.4 Warm pools i lifecycle hooks
Capítol 14 · Serverless amb Lambda
- 14.1 El model d'execució de Lambda
- 14.2 Triggers: API Gateway, S3, DynamoDB Streams, SQS
- 14.3 Gestió de dependències i capes (Layers)
- 14.4 Cold starts i estratègies per reduir-los
- 14.5 Límits i antipatrones
Capítol 15 · Missatgeria i esdeveniments
- 15.1 SQS: cues estàndard vs FIFO, DLQ
- 15.2 SNS: topics, subscripcions, fan-out
- 15.3 EventBridge: event buses i regles
- 15.4 Patrons: pub/sub, desacoblament, saga
Capítol 16 · Lliurament de contingut i DNS
- 16.1 Route 53: tipus de registres i routing policies
- 16.2 CloudFront: distribucions, memòries cau i origins
- 16.3 ACM: certificats SSL/TLS gratuïts
- 16.4 WAF integrat amb CloudFront
Capítol 17 · Contenidors a AWS
- 17.1 Docker: repàs exprés de conceptes clau
- 17.2 ECR: registre privat d'imatges
- 17.3 ECS: task definitions, services, Fargate vs EC2
- 17.4 EKS: quan Kubernetes i quan no
Capítol 18 · Mòduls: reutilització i composició
- 18.1 Anatomia d'un mòdul Terraform
- 18.2 Variables d'entrada, outputs i dependències
- 18.3 Mòduls locals vs mòduls del Terraform Registry
- 18.4 Versionat de mòduls amb Git tags
- 18.5 Disseny de mòduls genèrics vs específics de domini
Capítol 19 · Workspaces i gestió d'entorns
- 19.1 Workspaces de Terraform: casos d'ús i limitacions
- 19.2 Estratègia de directoris per entorn (dev/stg/prod)
- 19.3 Terragrunt: DRY per a configuracions d'entorn
- 19.4 Variables d'entorn i fitxers .tfvars
Capítol 20 · Backends remots i locking
- 20.1 Configurar S3 + DynamoDB com a backend
- 20.2 State locking: evitar corrupció en equip
- 20.3 Migració d'estat entre backends
- 20.4 terraform import: portar recursos existents a l'estat
Capítol 21 · Testing d'infraestructura
- 21.1 Terraform validate i fmt en CI
- 21.2 Checkov i tfsec: anàlisi de seguretat estàtica
- 21.3 Terratest: tests d'integració en Go
- 21.4 Contract testing entre mòduls
Capítol 22 · Terraform en CI/CD
- 22.1 Pipeline bàsic: lint → plan → apply a GitHub Actions
- 22.2 Atlantis: GitOps per a Terraform
- 22.3 Terraform Cloud / HCP Terraform
- 22.4 Drift detection i reconciliació automàtica
Capítol 23 · Seguretat en profunditat
- 23.1 AWS Organizations i Service Control Policies
- 23.2 AWS Config: compliment continu
- 23.3 GuardDuty: detecció d'amenaces
- 23.4 Security Hub: visió centralitzada
- 23.5 KMS: gestió de claus i rotació
- 23.6 Secrets Manager vs Parameter Store
Capítol 24 · Observabilitat: logs, mètriques i traces
- 24.1 CloudWatch Logs, mètriques i alarmes
- 24.2 CloudWatch Dashboards i Contributor Insights
- 24.3 X-Ray: traçat distribuït
- 24.4 OpenTelemetry a AWS
- 24.5 Managed Grafana i Managed Prometheus
Capítol 25 · Optimització de costos
- 25.1 AWS Cost Explorer i pressupostos amb alertes
- 25.2 Trusted Advisor i Compute Optimizer
- 25.3 Rightsizing: com detectar sobredimensionament
- 25.4 Savings Plans vs Reserved Instances: decisió estratègica
- 25.5 FinOps: cultura i processos per controlar la despesa
Capítol 26 · Alta disponibilitat i disaster recovery
- 26.1 RTO i RPO: definir els objectius
- 26.2 Estratègies: backup/restore, pilot light, warm standby, multi-site
- 26.3 Route 53 health checks i failover automàtic
- 26.4 AWS Backup: política centralitzada de còpies
Capítol 27 · Well-Architected Framework d'AWS
- 27.1 Els sis pilars: excel·lència operacional, seguretat, fiabilitat, eficiència de rendiment, optimització de costos, sostenibilitat
- 27.2 Well-Architected Tool: revisions formals
- 27.3 Com aplicar el framework en decisions de disseny
Capítol 28 · Arquitectures serverless a escala
- 28.1 Event-driven architecture amb Lambda + EventBridge
- 28.2 Saga pattern per a transaccions distribuïdes
- 28.3 Step Functions: orquestració de workflows complexos
- 28.4 Lambda@Edge i CloudFront Functions
Capítol 29 · Plataformes de dades a AWS
- 29.1 Data Lake amb S3, Glue i Athena
- 29.2 Kinesis Data Streams i Firehose per a streaming
- 29.3 Redshift: data warehousing a escala
- 29.4 Lake Formation: govern del dada
Capítol 30 · Multi-compte i landing zones
- 30.1 Per què separar workloads en comptes diferents
- 30.2 AWS Control Tower i Account Factory
- 30.3 Gestió centralitzada de logs i seguretat
- 30.4 Terraform a escala multi-compte amb mòduls compartits
Capítol 31 · Platform Engineering i Internal Developer Platform
- 31.1 Golden paths i abstraccions sobre Terraform
- 31.2 Service Catalog d'AWS
- 31.3 Backstage com a portal de desenvolupadors
- 31.4 Mòduls Terraform com a producte intern
Capítol 32 · Certificacions AWS rellevants
- 32.1 Cloud Practitioner: val la pena?
- 32.2 Solutions Architect Associate → Professional
- 32.3 DevOps Engineer Professional
- 32.4 Specialty: Security, Database, Networking
- 32.5 HashiCorp Terraform Associate
Capítol 33 · Projectes per consolidar el que s'ha après
- 33.1 Projecte 1: blog serverless (S3 + CloudFront + Lambda + DynamoDB)
- 33.2 Projecte 2: API REST amb ECS Fargate + RDS + ALB
- 33.3 Projecte 3: plataforma de dades amb Glue + Athena + Redshift
- 33.4 Projecte 4: landing zone multi-compte amb Terraform i Control Tower
