Monitorización on Adur

Stack de observabilidad: Prometheus, Grafana y alertas

Sun, 25 Aug 2024 00:00:00 +0000

Los Tres Pilares de la Observabilidad

La observabilidad es la capacidad de entender qué está ocurriendo dentro de tus sistemas examinando sus salidas externas. Se apoya en tres pilares:

Métricas son mediciones numéricas recopiladas a lo largo del tiempo: uso de CPU, latencia de peticiones, tasas de error, profundidad de colas. Son baratas de almacenar, rápidas de consultar e ideales para dashboards y alertas. Prometheus es la herramienta dominante aquí.

Logs son registros de texto con marca de tiempo de eventos discretos: errores de aplicación, logs de acceso, pistas de auditoría. Proporcionan contexto detallado que las métricas no pueden. Loki, Elasticsearch y Fluentd gestionan la agregación de logs.

Trazas siguen una petición individual mientras atraviesa múltiples servicios, mostrando la latencia en cada salto. Jaeger y Tempo son las principales opciones open-source. Las trazas son esenciales para depurar sistemas distribuidos, pero son las más complejas de instrumentar.

Esta guía se centra en métricas y logs usando el stack Prometheus + Grafana + Loki, que cubre la mayoría de las necesidades de observabilidad para la mayoría de equipos.

Arquitectura de Prometheus

Prometheus usa un modelo pull: en lugar de que las aplicaciones empujen métricas a un colector central, Prometheus escanea endpoints HTTP a intervalos regulares. Este diseño tiene algunas ventajas claras:

Los servicios no necesitan conocer el sistema de monitorizacion
Prometheus controla la tasa de escaneo y detecta cuando los targets estan caidos
Es facil ejecutarlo localmente contra cualquier servicio que exponga un endpoint /metrics

Componentes Principales

Prometheus Server: escanea targets, almacena datos de series temporales, evalua reglas de alerta
Exporters: traducen metricas de sistemas de terceros (node_exporter para Linux, mysqld_exporter para MySQL)
Pushgateway: acepta metricas enviadas por trabajos batch de corta duracion
Alertmanager: recibe alertas de Prometheus y las enruta a tus canales de notificacion

Configuracion de Scraping

Una configuracion basica de prometheus.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


global:
 scrape_interval: 15s
 evaluation_interval: 15s

rule_files:
 - "alert_rules.yml"

alerting:
 alertmanagers:
 - static_configs:
 - targets:
 - "alertmanager:9093"

scrape_configs:
 - job_name: "prometheus"
 static_configs:
 - targets: ["localhost:9090"]

 - job_name: "node-exporter"
 static_configs:
 - targets: ["node-exporter:9100"]

 - job_name: "application"
 metrics_path: "/metrics"
 static_configs:
 - targets: ["app:8080"]

 # Service discovery en Kubernetes
 - job_name: "kubernetes-pods"
 kubernetes_sd_configs:
 - role: pod
 relabel_configs:
 - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
 action: keep
 regex: true
 - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
 action: replace
 target_label: __metrics_path__
 regex: (.+)

En Kubernetes, el service discovery encuentra automaticamente los pods anotados con prometheus.io/scrape: "true". Ya no necesitas listar cada target manualmente.

Fundamentos de PromQL

PromQL es el lenguaje de consulta de Prometheus. Aqui tienes los patrones mas utiles:

Vectores Instantaneos y Rate

1
2
3
4
5
6
7
8


# Uso actual de CPU por core
node_cpu_seconds_total{mode="idle"}

# Tasa por segundo de peticiones HTTP en los ultimos 5 minutos
rate(http_requests_total[5m])

# Tasa de peticiones por codigo de estado
sum(rate(http_requests_total[5m])) by (status_code)

Percentiles de Latencia con Histogramas

1
2
3
4
5


# Latencia del percentil 95
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

# Percentil 99 por endpoint
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, handler))

Tasas de Error

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# Tasa de error como porcentaje
sum(rate(http_requests_total{status_code=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
* 100

# Disponibilidad (inversa de la tasa de error)
1 - (
 sum(rate(http_requests_total{status_code=~"5.."}[5m]))
 /
 sum(rate(http_requests_total[5m]))
)

Utilizacion de Recursos

1
2
3
4
5


# Porcentaje de uso de memoria
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

# Porcentaje de uso de disco
(1 - node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100

Dashboards de Grafana

Grafana se conecta a Prometheus como fuente de datos y permite construir dashboards con paneles para graficos, tablas, indicadores y heatmaps.

Configuracion

Anade Prometheus como fuente de datos en Grafana ya sea por la UI o mediante provisioning:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# grafana/provisioning/datasources/prometheus.yml
apiVersion: 1
datasources:
 - name: Prometheus
 type: prometheus
 access: proxy
 url: http://prometheus:9090
 isDefault: true

 - name: Loki
 type: loki
 access: proxy
 url: http://loki:3100

Provisioning de Dashboards

En lugar de crear dashboards manualmente en la UI, almacenalos como archivos JSON y aprovisionarlos automaticamente:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# grafana/provisioning/dashboards/default.yml
apiVersion: 1
providers:
 - name: "Default"
 orgId: 1
 folder: ""
 type: file
 disableDeletion: false
 updateIntervalSeconds: 30
 options:
 path: /var/lib/grafana/dashboards
 foldersFromFilesStructure: true

Coloca tus archivos JSON de dashboard en el directorio montado. Exporta dashboards existentes desde la UI de Grafana usando la funcion compartir/exportar y commitealos en Git. Esto te da dashboards versionados y reproducibles.

Consejo útil: al exportar dashboards para provisioning, reemplaza UIDs de datasource hardcodeados con la variable ${DS_PROMETHEUS} para que funcionen en diferentes entornos.

Loki para Agregacion de Logs

Loki es el sistema de agregacion de logs de Grafana. Esta disenado para ser eficiente en coste indexando solo metadatos (labels) en lugar del contenido completo de los logs. Se integra naturalmente con Grafana, permitiendo correlacionar logs y metricas en el mismo dashboard.

Arquitectura

Loki usa el mismo enfoque basado en labels que Prometheus. Los logs se etiquetan con labels como {job="myapp", namespace="production"} y se consultan usando LogQL:

1
2
3
4
5
6
7
8


# Todos los logs de error del servicio de pagos
{job="payment-service"} |= "error"

# Logs estructurados en JSON, filtrar por nivel y extraer campos
{job="api"} | json | level="error" | line_format "{{.msg}}"

# Contar errores por servicio a lo largo del tiempo
sum(count_over_time({job=~".+"} |= "error" [5m])) by (job)

Recopilacion de Logs con Promtail

Promtail es el agente que envia logs a Loki. Una configuracion basica:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


server:
 http_listen_port: 9080

positions:
 filename: /tmp/positions.yaml

clients:
 - url: http://loki:3100/loki/api/v1/push

scrape_configs:
 - job_name: containers
 static_configs:
 - targets:
 - localhost
 labels:
 job: containers
 __path__: /var/log/containers/*.log

En Kubernetes, despliega Promtail como un DaemonSet para recopilar logs de todos los nodos automaticamente.

Alerting con Alertmanager

Alertmanager gestiona el enrutamiento de alertas, agrupacion, deduplicacion y silenciado. Prometheus evalua reglas de alerta y dispara alertas a Alertmanager, que luego entrega las notificaciones.

Reglas de Alerta

Define reglas de alerta en un archivo referenciado por prometheus.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


# alert_rules.yml
groups:
 - name: application
 rules:
 - alert: HighErrorRate
 expr: |
 sum(rate(http_requests_total{status_code=~"5.."}[5m]))
 /
 sum(rate(http_requests_total[5m]))
 > 0.05
 for: 5m
 labels:
 severity: critical
 annotations:
 summary: "Tasa de error alta detectada"
 description: "La tasa de error es {{ $value | humanizePercentage }} en los ultimos 5 minutos"

 - alert: HighLatency
 expr: |
 histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
 > 1.0
 for: 10m
 labels:
 severity: warning
 annotations:
 summary: "Latencia p95 alta"
 description: "La latencia del percentil 95 es {{ $value }}s"

 - alert: DiskSpaceLow
 expr: |
 (1 - node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100
 > 85
 for: 15m
 labels:
 severity: warning
 annotations:
 summary: "Espacio en disco superior al 85%"
 description: "El uso de disco en {{ $labels.instance }} es {{ $value }}%"

Configuracion de Alertmanager

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


# alertmanager.yml
global:
 resolve_timeout: 5m

route:
 group_by: ["alertname", "severity"]
 group_wait: 30s
 group_interval: 5m
 repeat_interval: 4h
 receiver: "default"
 routes:
 - match:
 severity: critical
 receiver: "pagerduty-critical"
 repeat_interval: 1h
 - match:
 severity: warning
 receiver: "slack-warnings"

receivers:
 - name: "default"
 slack_configs:
 - api_url: "https://hooks.slack.com/services/XXX/YYY/ZZZ"
 channel: "#alerts"
 title: '{{ .GroupLabels.alertname }}'
 text: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'

 - name: "pagerduty-critical"
 pagerduty_configs:
 - service_key: "<pagerduty-service-key>"

 - name: "slack-warnings"
 slack_configs:
 - api_url: "https://hooks.slack.com/services/XXX/YYY/ZZZ"
 channel: "#warnings"

Despliegue con Docker Compose

Aqui tienes un docker-compose.yml completo para levantar el stack de observabilidad localmente:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64


version: "3.8"

services:
 prometheus:
 image: prom/prometheus:latest
 volumes:
 - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
 - ./prometheus/alert_rules.yml:/etc/prometheus/alert_rules.yml
 - prometheus_data:/prometheus
 ports:
 - "9090:9090"
 command:
 - "--config.file=/etc/prometheus/prometheus.yml"
 - "--storage.tsdb.retention.time=30d"

 alertmanager:
 image: prom/alertmanager:latest
 volumes:
 - ./alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml
 ports:
 - "9093:9093"

 grafana:
 image: grafana/grafana:latest
 volumes:
 - ./grafana/provisioning:/etc/grafana/provisioning
 - ./grafana/dashboards:/var/lib/grafana/dashboards
 - grafana_data:/var/lib/grafana
 ports:
 - "3000:3000"
 environment:
 - GF_SECURITY_ADMIN_PASSWORD=changeme

 loki:
 image: grafana/loki:latest
 volumes:
 - loki_data:/loki
 ports:
 - "3100:3100"

 promtail:
 image: grafana/promtail:latest
 volumes:
 - ./promtail/config.yml:/etc/promtail/config.yml
 - /var/log:/var/log:ro
 command: -config.file=/etc/promtail/config.yml

 node-exporter:
 image: prom/node-exporter:latest
 ports:
 - "9100:9100"
 volumes:
 - /proc:/host/proc:ro
 - /sys:/host/sys:ro
 - /:/rootfs:ro
 command:
 - "--path.procfs=/host/proc"
 - "--path.sysfs=/host/sys"
 - "--path.rootfs=/rootfs"

volumes:
 prometheus_data:
 grafana_data:
 loki_data:

Levanta el stack con:

1

docker-compose up -d

Accede a Grafana en http://localhost:3000, Prometheus en http://localhost:9090 y Alertmanager en http://localhost:9093.

Consejos para Produccion

Usa recording rules para consultas PromQL costosas que los dashboards ejecutan frecuentemente. Pre-calcula y almacena el resultado como una nueva metrica para reducir la carga de consultas.
Configura la retencion segun la resolucion: mantener datos de alta resolucion (intervalos de 15s) durante 15 dias, luego downsample a 5m durante 90 dias usando Thanos o Cortex para almacenamiento a largo plazo.
La cardinalidad de labels importa: evita labels con valores ilimitados (IDs de usuario, IDs de peticion). Labels de alta cardinalidad dispararan el uso de memoria de Prometheus.
Usa carpetas y equipos en Grafana para organizar dashboards por servicio o equipo. Omite el mega-dashboard que intenta mostrar todo.
Alerta sobre sintomas, no causas: alerta sobre “la tasa de error es alta” en lugar de “el Pod se reinicio.” Los usuarios se preocupan por el impacto, no por el mecanismo interno.
Implementa runbooks de alertas: cada alerta debe enlazar a un runbook describiendo que comprobar y como mitigar. Anade el enlace en la anotacion de la alerta.
Testea tus alertas: usa promtool check rules alert_rules.yml para validar la sintaxis de las reglas. Usa tests unitarios para expresiones PromQL complejas.
Asegura tu stack: pon Grafana detras de SSO/OAuth, restringe el acceso a Prometheus a redes internas, habilita TLS entre componentes en produccion.

El stack Prometheus + Grafana + Loki proporciona una base solida de observabilidad que escala bien para la mayoria de organizaciones. Empieza con metricas y alertas, anade agregacion de logs cuando necesites correlacionar eventos, e introduce trazas cuando depurar latencia entre servicios se convierta en algo habitual.

Introducción a AIOps: operaciones de TI inteligentes

Mon, 05 Dec 2022 00:00:00 +0000

¿Qué es AIOps?

AIOps (Artificial Intelligence for IT Operations) aplica machine learning y analítica de datos a los datos operativos (logs, métricas, eventos, trazas) para automatizar y mejorar flujos de trabajo. Gartner acuñó el término en 2017, pero la idea es simple: usar algoritmos para gestionar el volumen y la complejidad que los humanos no pueden manejar manualmente.

En términos prácticos, las plataformas AIOps ingieren datos de herramientas de monitorización, sistemas APM, agregadores de logs y fuentes de eventos. Aplican modelos de ML para detectar anomalías, correlacionar eventos, identificar causas raíz y, en algunos casos, desencadenar remediación automatizada. El objetivo es reducir el tiempo medio de detección (MTTD) y el tiempo medio de resolución (MTTR) mientras se libera a los equipos de operaciones de la fatiga por alertas.

Por qué la monitorización tradicional se queda corta

La monitorización funcionaba bien cuando los sistemas eran simples. Tenías pocos servidores, unas pocas apps y un número limitado de métricas. Un umbral estático de CPU o un regex en logs era suficiente.

La infraestructura moderna rompió ese modelo:

Escala: Un clúster de Kubernetes genera millones de métricas y logs por minuto. No puedes vigilar dashboards a esa escala.
Complejidad: Los microservicios crean dependencias enredadas. Una petición puede atravesar docenas de servicios. Encontrar qué causó una latencia significa correlacionar datos entre todos.
Entornos dinámicos: Auto-scaling, contenedores efímeros, serverless. Las baselines cambian constantemente y los umbrales estáticos explotan con falsos positivos.
Fatiga por alertas: Los equipos se hunden en alertas. Cuando el 90% es ruido, ese crítico 10% desaparece. Los ingenieros empiezan a ignorar todo.

AIOps no reemplaza la monitorización. Se sitúa encima de lo que ya tienes y lo hace más inteligente.

Capacidades clave

1. Detección de anomalías

En lugar de umbrales estáticos, AIOps usa modelos de ML (frecuentemente análisis de series temporales, clustering o autoencoders) para aprender qué aspecto tiene lo “normal” para cada métrica y servicio. Cuando el comportamiento se desvía significativamente de la línea base aprendida, se marca una anomalía.

Esto maneja el problema de la línea base dinámica. Si tu aplicación normalmente ve un pico de tráfico cada lunes a las 9 de la mañana, el modelo aprende ese patrón y no alerta por ello. Pero un pico inesperado a las 3 de la madrugada de un miércoles sí se marca.

2. Correlación de eventos

Un único problema de infraestructura puede generar cientos o miles de alertas relacionadas en diferentes herramientas de monitorización. AIOps correlaciona estos eventos — agrupándolos por tiempo, topología y relaciones causales — para presentar un único incidente en lugar de un muro de alertas.

Por ejemplo, un fallo en un switch de red podría disparar alertas en: el propio switch, todos los servidores conectados (conectividad perdida), todas las aplicaciones en esos servidores (fallos en health checks), y servicios downstream (errores de timeout). Una plataforma AIOps correlaciona todos estos en un incidente: “Switch de red X ha fallado.”

3. Análisis de causa raíz

Más allá de la correlación, AIOps intenta identificar la causa raíz de un incidente. Al comprender la topología de tu infraestructura y la cadena causal de eventos, puede sugerir que el fallo del switch de red es la causa raíz, en lugar de presentar el timeout de la aplicación como un problema independiente.

Aquí es donde el valor se vuelve tangible. En lugar de que un ingeniero de guardia pase 30 minutos rastreando a través de dashboards y logs, la plataforma muestra la causa raíz probable inmediatamente.

4. Auto-remediación

Las implementaciones más maduras de AIOps cierran el ciclo disparando acciones de remediación automatizadas. Si se detecta un patrón conocido (disco llenándose, un pod en CrashLoopBackOff, un proceso descontrolado consumiendo memoria), la plataforma puede ejecutar runbooks predefinidos automáticamente.

Ejemplos:

Reiniciar un pod o servicio caído.
Escalar un deployment cuando se detecta carga anómala.
Limpiar un directorio de logs cuando el uso de disco supera un umbral dinámico.
Disparar un failover cuando una base de datos primaria deja de responder.

La auto-remediación requiere un diseño cuidadoso. Empieza con acciones de bajo riesgo y amplía conforme crece la confianza.

Plataformas y herramientas comunes

El panorama de AIOps incluye tanto plataformas comerciales como bloques de construcción open-source:

Plataformas comerciales

Plataforma	Fortalezas
Dynatrace	Auto-descubrimiento robusto, motor de IA (Davis), observabilidad full-stack
Datadog	Monitorización unificada + alertas con ML, detección de anomalías Watchdog
Splunk ITSI	Analítica de logs potente + toolkit de ML, bueno para correlación de eventos
Moogsoft	Pionero en el espacio AIOps, fuerte correlación de eventos y reducción de ruido
BigPanda	Enfocado en correlación de eventos y automatización, se integra con herramientas existentes
PagerDuty	Gestión de incidentes con reducción de ruido por ML y agrupación inteligente

Bloques de construcción open-source

Puedes ensamblar un stack similar a AIOps con componentes open-source:

Recolección de datos: Prometheus, Grafana Agent, OpenTelemetry Collector, Fluentd/Fluent Bit.
Almacenamiento de datos: Prometheus (métricas), Elasticsearch/OpenSearch (logs), Jaeger/Tempo (trazas).
Detección de anomalías: Facebook Prophet, Isolation Forest (scikit-learn), luminol, Grafana ML.
Correlación de eventos: Lógica personalizada sobre streams de eventos, o StackStorm para automatización dirigida por eventos.
Alertas y automatización: Alertmanager, Grafana OnCall, StackStorm, Rundeck.

Construir un stack AIOps personalizado es significativamente más trabajo que usar una plataforma comercial, pero te da control total y evita el vendor lock-in. Un punto medio razonable es usar una plataforma comercial para las capacidades core de AIOps mientras mantienes tu pipeline de datos en open-source.

Casos de uso prácticos

Reducción de ruido en gestión de alertas

Un equipo que recibe más de 500 alertas al día implementa correlación de eventos AIOps. Las alertas relacionadas se agrupan en incidentes, los duplicados se suprimen y las alertas fluctuantes se silencian. El volumen de alertas baja un 80%, y el ingeniero de guardia puede enfocarse en incidentes reales.

Planificación proactiva de capacidad

Los modelos AIOps analizan tendencias históricas de uso de recursos y predicen cuándo se alcanzarán los límites de capacidad. En lugar de reaccionar a una alerta de disco lleno a las 2 de la madrugada, la plataforma predice el problema con dos semanas de antelación y crea un ticket para que el equipo lo aborde en horario laboral.

Respuesta a incidentes más rápida

Durante una caída de producción, la plataforma AIOps correlaciona alertas de todo el stack de monitorización, identifica la causa raíz (un despliegue reciente que introdujo una fuga de memoria) y muestra el commit del despliegue relevante. El MTTR baja de 45 minutos a 10 minutos.

Escalado automático

La plataforma detecta patrones de tráfico anómalos que se desvían de la línea base aprendida. En lugar de esperar a que la CPU alcance el 80% (el umbral estático), dispara una acción de scale-up basada en la tasa de cambio, asegurando que la capacidad está lista antes de que los usuarios experimenten degradación.

Cómo encaja AIOps en los flujos de trabajo DevOps

AIOps no es un reemplazo de las prácticas DevOps. Es una capa de mejora:

1
2
3
4
5


Código ──> CI/CD Pipeline ──> Deploy ──> Observar ──> Capa AIOps ──> Actuar
 │ │
 Monitoring Stack Modelos ML
 (métricas, logs, (detección de anomalías,
 trazas, eventos) correlación, RCA)

Los desarrolladores se benefician de una identificación más rápida de la causa raíz cuando su código causa problemas en producción.
Los equipos de operaciones se benefician de la reducción de ruido, remediación automatizada y alertas proactivas.
Los equipos SRE se benefician del seguimiento de SLOs basado en datos y el análisis de tasa de consumo del error budget.

AIOps funciona mejor cuando tu base de observabilidad es sólida. Si no estás recolectando buenos datos (logs estructurados, métricas significativas, trazas distribuidas), los modelos de ML no producirán insights significativos. Arregla primero tu observabilidad, luego añade AIOps encima.

Primeros pasos: Un camino pragmático

Si estás considerando AIOps, aquí tienes un enfoque práctico:

Audita tu stack de observabilidad actual. ¿Qué datos estás recolectando? ¿Los logs están estructurados? ¿Las métricas están etiquetadas de forma consistente? ¿Las trazas se propagan entre servicios? AIOps es tan bueno como los datos que ingiere.
Empieza con la reducción de ruido. Esta es la fruta que cuelga más baja. Implementa agrupación y deduplicación de alertas. Incluso una correlación básica basada en reglas (antes de cualquier ML) reducirá la fatiga por alertas significativamente.
Añade detección de anomalías a métricas clave. Elige 3-5 métricas críticas de negocio e infraestructura. Aplica un modelo de detección de anomalías de series temporales. Facebook Prophet o recording rules de Prometheus con ajustes estacionales son buenos puntos de partida.
Implementa remediación automatizada para problemas conocidos. Identifica los 5 incidentes recurrentes principales. Escribe runbooks para ellos. Automatiza los runbooks usando StackStorm, Rundeck o el motor de automatización de tu plataforma.
Evalúa una plataforma comercial cuando la complejidad lo requiera. Si tienes cientos de servicios, múltiples herramientas de monitorización y un equipo de operaciones creciente, la inversión en una plataforma AIOps comercial puede justificarse solo por la reducción en MTTR.
Mide el impacto. Sigue MTTD, MTTR, ratio alerta-a-incidente y tasa de falsos positivos. Sin métricas, no puedes probar que AIOps vale la pena.

AIOps no es magia. Es un conjunto de técnicas que, aplicadas a buenos datos operativos, pueden reducir la carga sobre los equipos y mejorar la fiabilidad. Empieza pequeño, mide todo, y escala lo que funcione.