Aquesta és una revisió antiga del document
cloudwatch
- servicio de monitorización
- la mayoría de servicios incorporan de base algún sistema de monitorización de manera automáticamente
- se pueden personalizar ($)
- High Resolution Custom Metrics
- permite métricas cada segundo
- la retención de métrica pasa de 14 días a 15 meses
- las métricas de menos de 60 segundos están disponibles 3 horas
- de más de 60 segundos, están disponibles 15 días
- de más de 300 segundos, están disponibles 63 días
- de más de 3600 segundos, están disponibles 455 días
- al pasar su periodo de disponibilidad, se agrupan, perdiendo detalle
- despliegue por regiones
- namespaces (se agrupa por servicios)
EC2
- CPU
- Network
- Disk
- Status Check
- System Status Check : hard por debajo del server (necesario STOP y START para que cambie de hard. No sirve reboot)
- Instance Status Check : la VM falla, Reboot (mala configuración network, sin memoria, problemas de disco..)
- health chechs van cada minuto
- 5 minutos de intervalo
- Custom metric : RAM, espacio disco usado/libre
- (mirarse la métricas disponibles)
- SSD
- HDD (NO ROOT volumen)
- … mirar números
Alarmas
- Crear alarmas
- permite notificaciones
- permite tomar acciones
I/O Credits
- credito inicial : 5.4 millones de I/O credits, permite 3000 IOPS durante 30 minutos (pensado para el arranque y sobretodo en volúmenes pequeños)
- los discos de más de 1024GB tienen una performance igual o superior a estos 3000 IOPS que nos ofrecen en créditos, este crédito no computa
- 3 IOPS/1GB
- ejemplo: 100GiB tiene 300IOPS
- una manera de mejorar el rendimiento se puede subir la capacidad del disco (que hace que aumenten los IOS)
- o aumentarlos desde el manejo de EBS - volumen
- también el tipo de disco
- en ambos casos, $
EBS Volumes
- para conseguir el rendimiento óptimo
- inicialización : cuando recuperas un snapshot desde un S3, ejecutar un comando (dd de lectura) para optimizarlo
- Métricas EBS:
- VolumeQueueLength : cantidad de peticiones en cola pendientes
- Status:
- OK
- warning : degradado o bastante degradado
- impaired : no disponible o totalmente degradado.
RDS
- database connection
- Disk Queue Depth
- Free Storage Space
- ReplicaLag
- Rea/Write IOPS
- Read/Write Latency
ELB
- 60 segundos por defecto
- 3 tipos:
- classic (no recomiendan su suo)
- capa 7
- capa 4
- métricas:
- SpilloverCount : rechazadas
- SurgeQueueLength : cola
- HTTPCode_ELB_5XX_Count
- RequestCountPerTarget
- TargetResponseTime
ElasticCache
- redis / memcached
- Métricas
- CPUUtilization
- memcached:más allá del 90%, se ha de escalar (más nodos)
- Redis: en función del número de cores
- SwapUsage : mala señal si se usa SWAP en un servicio
- por encima de 0 es que algo va mal, pero sobre todo por encima de 50MB → aumentar ConnectionOverhead
- Evictions : falta de memoria
- reemplazo de items nuevos por viejos
- CurrConnections
- en función de la aplicación desplegada, hay que «jugar» con los valores para montarnos nuestras alarmas
Consolidated Billing - AWS Organizartions
- descuento por volumen (cuanto más servicios consumes, más baratos te salen)
- tengo una cuenta «madre» y enlazo las cuentas hijas para no perder el volumen
- en la madre no debería haber recursos desplegados
- uso de tags
- instancias reservadas EC2 (del mismo tipo, región, AZ) compartidas entre las diferentes cuentas
- market place : venta de EC2 reservadas (si ya no la necesitamos)
- AWS Organizartions
- creación de unidades organizativas
- gestión de cuentas hijas (estructura) ≡ ldap
- billing alerts
CloudTrail
- activado por región por cada AWS Account
- auditoria
- puedes consolidar los logs en un bucket S3
- con una bucket policy para permitir acceso cruzado de cuentas