AIOps en VPS: monitoreo IA autoalojado open source

Datadog y New Relic cobran por host, por GB, o ambos. Para un desarrollador independiente o un equipo pequeño que gestiona de uno a cinco VPS, esos costes se acumulan rápido con poco retorno. Consulta la página de precios de Datadog y la página de precios de New Relic para las tarifas actuales.

La alternativa: ejecutar toda tu pila de monitoreo, análisis de logs y respuesta a incidentes en un solo VPS. Herramientas open source como SigNoz, Grafana+Loki y Ollama te dan observabilidad, detección de anomalías con IA y remediación automatizada. Coste total: el precio de tu VPS. En Virtua Cloud, eso empieza en 24 EUR/mes por un servidor de 2 vCPU y 4 GB de RAM para observabilidad básica, o 48 EUR/mes por la pila completa en un servidor de 4 vCPU y 8 GB de RAM.

Este artículo mapea las cinco capas de una pila AIOps autoalojada. No es un tutorial paso a paso. Cada sección explica qué hace la capa, recomienda herramientas y enlaza a la guía dedicada donde instalas y configuras todo.

¿Qué es AIOps y por qué importa para operadores de VPS?

AIOps significa usar IA y machine learning para automatizar monitoreo, análisis de logs, detección de anomalías y respuesta a incidentes. Para los operadores de VPS, reemplaza el ciclo manual de revisar dashboards, leer logs y reiniciar servicios. En lugar de pagar plataformas SaaS empresariales, ejecutas herramientas open source en la misma infraestructura que ya gestionas. Tus datos se quedan en tu servidor. Tus costes se mantienen fijos.

La definición empresarial de AIOps se centra en correlacionar miles de alertas en cientos de microservicios. Eso no es lo que cubre esta guía. Para operadores de VPS que gestionan de uno a cinco servidores, AIOps significa:

Recopilar métricas, logs y trazas en un solo lugar en vez de conectarte por SSH a cada servidor.
Ejecutar un LLM local para detectar patrones en los logs que grep y las expresiones regulares no captan.
Automatizar respuestas a fallos comunes como un disco lleno, un proceso caído o una fuga de memoria.
Obtener feedback de IA sobre el código antes de que llegue a producción.

La pila tiene cinco capas. No necesitas todas. Empieza con observabilidad, añade análisis con IA cuando el volumen de logs haga dolorosa la revisión manual, y avanza hacia la autorreparación a medida que ganes confianza.

¿Cuánto cuesta el monitoreo autoalojado comparado con Datadog?

Una pila AIOps autoalojada en un VPS de Virtua Cloud cuesta entre 24 y 96 EUR/mes dependiendo de cuántas capas despliegues. Ese es el coste total: servidor, almacenamiento, ancho de banda y todo el software. Las alternativas comerciales como Datadog usan modelos de precios por host y por GB que escalan con tu infraestructura. Sus costes crecen a medida que añades hosts, ingieres más logs o activas el tracing APM.

Funcionalidad	SaaS comercial (Datadog, New Relic)	Autoalojado (VPS Virtua Cloud)
Monitoreo de infraestructura	Precios por host, escalonados por plan	Incluido (Prometheus + Grafana)
Gestión de logs	Tarifas por GB de ingesta + indexación por evento	Incluido (Loki u OpenObserve)
APM / Trazas	Tarifa adicional por host	Incluido (SigNoz o Tempo)
Análisis de logs con IA	No disponible o complemento separado	Incluido (Ollama + LLM local)
Alertas	Incluido	Incluido (Alertmanager)
Retención de datos	Límites definidos por el proveedor (días a meses)	Tú decides. El disco es el límite.
Ubicación de datos	US/EU (tú eliges región)	Tu VPS. Tu jurisdicción.
Modelo de precios	Por host + por GB, crece con el uso	Coste VPS mensual fijo

Para los precios comerciales actuales, consulta los precios de Datadog y los precios de New Relic. Los costes autoalojados dependen solo del plan VPS que elijas.

La columna de autoalojado asume un plan vCS-8 individual (4 vCPU, 8 GB de RAM, 160 GB SSD) ejecutando la pila de observabilidad completa con Docker Compose. Si solo necesitas métricas y logs básicos, un vCS-4 (2 vCPU, 4 GB de RAM) a 24 EUR/mes maneja Grafana + Loki + Prometheus para cargas de trabajo pequeñas.

Para equipos que también quieren la capa de análisis con IA (Ollama con un modelo de 3-7B parámetros), el VPS de 8 GB es el mínimo. Ollama con Gemma 2 (2B) funciona con aproximadamente 2 GB de RAM, dejando suficiente margen para SigNoz o Grafana a su lado.

¿Qué herramientas de observabilidad open source funcionan mejor en un VPS?

La capa de observabilidad recopila métricas, logs y trazas de tus aplicaciones e infraestructura. Tres pilas open source dominan este espacio: SigNoz, OpenObserve y Grafana + Loki. Cada una hace compromisos distintos entre funcionalidades, uso de recursos y complejidad.

Herramienta	Ideal para	Logs	Métricas	Trazas	Backend	RAM mín	Complejidad
SigNoz	Reemplazo APM completo de Datadog	Sí	Sí	Sí	ClickHouse	4 GB	Media
OpenObserve	Agregación de logs ligera	Sí	Sí	Sí	Nativo (Rust)	~1 GB	Baja
Grafana + Loki + Prometheus	Ecosistema establecido, extensibilidad	Sí (Loki)	Sí (Prometheus)	Vía Tempo	Múltiple	2-4 GB	Mayor

Las tres soportan OpenTelemetry para instrumentación. Esto significa que puedes instrumentar tu aplicación una vez y cambiar de backend después sin modificar el código de la aplicación.

¿Cuándo elegir SigNoz en lugar de OpenObserve?

Elige SigNoz cuando necesites monitoreo de rendimiento de aplicaciones completo: trazas distribuidas, mapas de servicios, seguimiento de errores y logs correlacionados. SigNoz usa ClickHouse como motor de almacenamiento, que maneja bien datos de alta cardinalidad pero requiere más RAM. Un despliegue con Docker Compose necesita al menos 4 GB de RAM dedicados a SigNoz, con 8 GB recomendados para cargas de producción que incluyen ClickHouse.

Elige OpenObserve cuando tu necesidad principal sea agregación y búsqueda de logs. OpenObserve se distribuye como un binario único escrito en Rust. Arranca con menos de 1 GB de RAM en una configuración básica de Docker Compose. Afirma tener costes de almacenamiento 140 veces menores que Elasticsearch gracias a la compresión columnar. Si eres un indie hacker que ejecuta una sola aplicación y quiere búsqueda rápida de logs sin la sobrecarga de ClickHouse, OpenObserve es el camino más ligero.

Ambas herramientas tienen interfaces web para consultas y dashboards. SigNoz ofrece una experiencia más completa similar a Datadog. OpenObserve es más ligero y más rápido de desplegar.

¿Sigue siendo Grafana + Loki la mejor opción en 2026?

Grafana + Loki sigue siendo la opción más flexible. No es la más sencilla de configurar, pero gana en amplitud de ecosistema. Existen miles de dashboards comunitarios para cada servicio imaginable. Los exportadores Prometheus cubren bases de datos, servidores web, métricas de hardware y métricas personalizadas de aplicación. Loki maneja la agregación de logs con un lenguaje de consultas LogQL que refleja PromQL.

El compromiso: más piezas móviles. Una pila Grafana mínima implica ejecutar Grafana (UI), Prometheus (métricas) y Loki (logs) como contenedores separados. Añade Promtail o Alloy como agente de recolección de logs. Son cuatro contenedores antes de añadir tu propia aplicación. En un VPS de 4 GB, esta pila cabe pero deja poco margen.

Elige Grafana + Loki cuando ya conozcas el ecosistema, necesites personalización avanzada o quieras integrar herramientas que solo soportan exportación de métricas Prometheus.

¿Cómo se añade análisis de logs con IA a tu pila de monitoreo?

Ejecuta un LLM local a través de Ollama para analizar logs sin enviar datos a ninguna API externa. Ollama sirve modelos como Gemma 2 (2B), Llama 3.2 (3B) o Qwen 2.5 (7B) a través de una API HTTP local. Un script o tarea cron alimenta el modelo con fragmentos de logs y le pide identificar anomalías, resumir patrones de error o sugerir causas raíz. Sin costes de API. Sin datos que salgan de tu servidor.

Aquí es donde el AIOps autoalojado diverge del monitoreo tradicional. Grafana y Prometheus te dicen qué pasó. Un LLM local te ayuda a entender por qué.

Lo que hace la capa de análisis con IA:

Detección de anomalías: alimenta el modelo con las últimas 1.000 líneas de logs con un prompt como "identifica patrones inusuales o errores en estos logs". El modelo señala las entradas que se desvían de los patrones normales.
Resumen de errores: cuando un incidente genera cientos de líneas de logs, el LLM las condensa en un resumen legible con la causa raíz probable.
Reconocimiento de patrones: con el tiempo, surgen patrones de error recurrentes. El LLM puede agrupar errores relacionados e identificar problemas recurrentes que no activarían alertas basadas en umbrales.

Dimensionamiento de modelos para VPS:

Modelo	Parámetros	Uso de RAM	Velocidad (tokens/seg, CPU)	Ideal para
Gemma 2 (2B)	2.600 M	~2 GB	~15-20	Triaje rápido de logs en VPS con poca RAM
Llama 3.2 (3B)	3.200 M	~2,5 GB	~10-15	Análisis y velocidad equilibrados
Qwen 2.5 (7B)	7.000 M	~5 GB	~5-8	Análisis profundo, requiere VPS de 8 GB+

En un VPS de 4 vCPU sin GPU, la inferencia es solo por CPU. Un modelo de 2-3B produce análisis de logs útil en 5-15 segundos por consulta. Es suficiente para análisis por lotes cada pocos minutos, no para streaming en tiempo real.

Esto no es magia. Los modelos pequeños alucinan. Pierden contexto. A veces señalan entradas de logs normales como sospechosas. Trata el análisis de logs con LLM como un asistente de triaje, no como un oráculo. Verifica siempre sus sugerencias contra los logs y métricas reales.

¿Qué es un VPS autorreparador y cómo funciona?

Un VPS autorreparador detecta y remedia automáticamente fallos comunes sin intervención humana. La arquitectura básica: Prometheus monitorea métricas, Alertmanager dispara alertas cuando se superan umbrales, y un receptor de webhooks ejecuta scripts de remediación. Añadir un LLM a este bucle permite manejar fallos que no coinciden con reglas predefinidas.

El pipeline de autorreparación:

Prometheus recopila métricas cada 15 segundos (CPU, memoria, disco, estado de procesos, tasas de error HTTP).
Las reglas de alerta definen condiciones: uso de disco por encima del 90 %, un servicio sin responder durante 60 segundos, uso de memoria sostenido por encima del 95 %.
Alertmanager recibe la alerta y la enruta a un endpoint de webhook.
El manejador de remediación recibe el webhook. Para condiciones conocidas (disco lleno, servicio caído), ejecuta un script predefinido. Para condiciones desconocidas, llama al LLM local vía Ollama con el contexto de la alerta y los logs recientes, pidiendo un diagnóstico y una sugerencia de remediación.
Ejecución (opcional): para remediaciones conocidas de alta confianza (reiniciar un servicio, limpiar archivos temporales, rotar logs), el manejador ejecuta automáticamente. Para acciones sugeridas por el LLM, envía la sugerencia a tu canal de notificación para aprobación humana.

Remediaciones automatizadas comunes:

Disco lleno: limpiar /tmp, rotar logs antiguos, podar imágenes Docker con docker system prune.
Servicio caído: systemctl restart <service>, luego verificar que está sano. Si cae de nuevo en 5 minutos, escalar a un humano.
Presión de memoria: identificar el mayor consumidor de memoria, reiniciarlo si excede su línea base esperada.
Expiración de certificado: lanzar una renovación de Certbot cuando el certificado tenga menos de 7 días restantes.

Empieza de forma conservadora. Automatiza solo remediaciones que hayas ejecutado manualmente docenas de veces y que entiendas por completo. Deja que el LLM sugiera acciones para situaciones desconocidas, pero mantén a un humano en el bucle para la ejecución.

Para un enfoque sin código en el enrutamiento de alertas y los workflows de remediación, n8n puede actuar como la capa de orquestación entre Alertmanager y tus scripts de remediación.

¿Cómo encaja la IA en tu pipeline CI/CD?

La revisión de código con IA detecta bugs, problemas de seguridad y problemas de rendimiento antes de que el código llegue a tu servidor. Los workflows de GitHub Actions pueden enviar diffs de pull requests a Claude o Gemini para análisis, publicar comentarios de revisión y bloquear merges cuando se encuentran problemas críticos. Esto se ejecuta en tu pipeline CI/CD sin cambios en tu VPS.

Lo que la revisión de código con IA detecta y los linters no:

Errores de lógica y casos límite que el análisis estático no puede detectar.
Vulnerabilidades de seguridad en contexto (un linter señala funciones peligrosas, pero un LLM entiende por qué el código circundante las hace explotables).
Regresiones de rendimiento: "esta consulta dentro de un bucle va a consultar la base de datos N veces".
Vacíos de documentación: manejo de errores ausente, nombres de variables poco claros, efectos secundarios no documentados.

Esta capa difiere de las demás porque normalmente se ejecuta en tu plataforma CI (GitHub Actions, GitLab CI), no en tu VPS. Sin embargo, si quieres mantener todo autoalojado, puedes ejecutar un runner CI en tu VPS y enrutar las solicitudes de revisión de código a tu instancia local de Ollama. El compromiso: revisiones más lentas con modelos más pequeños frente a revisiones más rápidas y precisas con APIs en la nube.

¿Qué es la observabilidad LLM y por qué la necesitas?

La observabilidad LLM rastrea el rendimiento de tus herramientas de IA: uso de tokens, latencia, tasas de error, costes y calidad de los resultados. Si ejecutas alguna funcionalidad alimentada por LLM (chatbot, asistente de código, analizador de logs, generador de contenido), Langfuse te da visibilidad de cada llamada. Es la capa de "monitorear a los monitores" de tu pila AIOps.

Langfuse es una plataforma open source de ingeniería LLM. Autoalojada, funciona con dos contenedores (web + worker) con PostgreSQL y opcionalmente ClickHouse para analítica. Proporciona:

Trazado: ver cada llamada LLM con entrada, salida, latencia y recuento de tokens. Profundizar en workflows de agentes multi-paso para encontrar dónde se gastan el tiempo y los tokens.
Evaluación: puntuar resultados con LLM-as-a-judge, feedback humano o métricas personalizadas. Seguir la calidad a lo largo del tiempo.
Seguimiento de costes: calcular el gasto real por llamada LLM, por usuario, por funcionalidad. Comparar el rendimiento de modelos a diferentes puntos de precio.
Gestión de prompts: versionar y hacer tests A/B de prompts. Revertir cuando un nuevo prompt degrada la calidad de los resultados.

Si ejecutas Ollama para análisis de logs (capa 2 de esta pila), Langfuse traza cada solicitud de análisis. Ves qué consultas de logs producen resultados útiles, cuáles dan problemas al modelo y cómo cambia la latencia al cambiar de modelo.

Langfuse se integra con OpenTelemetry, LangChain, LlamaIndex y el SDK de OpenAI (con el que Ollama es compatible). La instrumentación normalmente son unas pocas líneas de código.

Necesitas esta capa cuando tu uso de LLM va más allá de la experimentación. Una vez que dependes de los resultados de la IA para alertas o remediación, necesitas saber cuándo el modelo empieza a producir basura.

¿Qué recursos de VPS necesitas para una pila AIOps completa?

Los recursos dependen de qué capas despliegues. Aquí hay tres configuraciones mapeadas a los planes VPS de Virtua Cloud:

Configuración	Capas	Plan VPS	CPU	RAM	Disco	EUR/mes
Starter	Grafana + Prometheus + Loki	vCS-4	2 vCPU	4 GB	80 GB	24
Standard	SigNoz + Ollama (modelo 3B)	vCS-8	4 vCPU	8 GB	160 GB	48
Pila completa	SigNoz + Ollama (7B) + Langfuse + Alertmanager	vCS-16	8 vCPU	16 GB	320 GB	96

Starter maneja métricas y agregación de logs para una a tres aplicaciones pequeñas. Dashboards y alertas sin análisis con IA.

Standard añade análisis de logs con IA. SigNoz ocupa aproximadamente 4 GB y Ollama con un modelo 3B usa unos 2,5 GB. La RAM restante va al sistema operativo y a las aplicaciones monitoreadas. Es el punto óptimo para un desarrollador independiente o un equipo pequeño.

Pila completa ejecuta todas las capas descritas en esta guía. Un modelo de 7.000 millones de parámetros produce mejor análisis que un modelo 3B pero necesita más RAM. Langfuse añade aproximadamente 1 GB. Esta configuración es para equipos que ejecutan funcionalidades alimentadas por LLM en producción y necesitan observabilidad total sobre su infraestructura y su IA.

Todas las configuraciones ejecutan todo a través de Docker Compose. Los artículos dedicados cubren los archivos docker-compose.yml exactos para cada herramienta.

Una nota sobre el uso de disco: los datos de observabilidad crecen rápido. SigNoz con ClickHouse comprime bien (espera compresión de 5 a 10x en logs), pero planifica de 1 a 5 GB de datos nuevos por día dependiendo de la verbosidad de tus logs. Establece políticas de retención desde el primer día. Un disco de 160 GB te da aproximadamente de uno a tres meses de datos con tasas de ingesta moderadas.

Soberanía de datos: la ventaja RGPD del monitoreo autoalojado

Cuando ejecutas tu pila de monitoreo en un VPS europeo, tus datos de observabilidad nunca salen de la jurisdicción. Las métricas, logs y trazas a menudo contienen datos personales: direcciones IP, IDs de usuario, rutas de solicitud, mensajes de error con contexto de usuario. Enviar esos datos a una plataforma SaaS con base en EE. UU. introduce riesgo de transferencia RGPD, incluso cuando el proveedor ofrece una región EU.

Con una pila autoalojada en un VPS de Virtua Cloud en Francia o Alemania, controlas:

Dónde se almacenan los datos. En disco, en tu VPS, en un centro de datos europeo.
Quién puede acceder a ellos. Sin empleados del proveedor, sin subprocesadores, sin acuerdos de datos con terceros que auditar.
Cuánto tiempo se conservan. Tú defines la política de retención. Sin mínimos impuestos por el proveedor ni calendarios de eliminación de datos.

Esto no es una opinión legal. Consulta a tu delegado de protección de datos para tu situación específica. Pero desde un punto de vista técnico, el monitoreo autoalojado elimina toda una categoría de preguntas sobre transferencia de datos.

¿Por dónde deberías empezar?

Tu punto de partida depende de tu experiencia y del problema que estés resolviendo ahora mismo.

Si eres nuevo en monitoreo de servidores (indie hackers, primer VPS):

Empieza con SigNoz. Te da métricas, logs y trazas en una sola herramienta con interfaz web. Un archivo Docker Compose, una herramienta que aprender.
Una vez que te sientas cómodo leyendo dashboards, añade Ollama para análisis de logs con IA.
No automatices la remediación todavía. Entiende primero el comportamiento normal de tu servidor.

Si ya usas Prometheus o Grafana (profesionales DevOps):

Añade Loki para agregación de logs si aún no lo has hecho.
Integra Ollama para triaje de logs asistido por IA junto a tus reglas de alerta existentes.
Construye workflows de autorreparación con webhooks de Alertmanager.
Añade Langfuse cuando empieces a depender de los resultados del LLM para decisiones operativas.

Si quieres la pila completa desde el primer día (desarrolladores IA):

Despliega un VPS vCS-8 o vCS-16 en Virtua Cloud.
Configura SigNoz para observabilidad.
Ejecuta Ollama con un modelo 7B para análisis de logs y detección de anomalías.
Conecta Alertmanager a tus scripts de remediación.
Despliega Langfuse para monitorear tu capa LLM.
Añade revisión de código con IA a tu pipeline CI/CD.

Cada artículo dedicado en este clúster temático es un tutorial independiente. Puedes seguirlos en cualquier orden. La pila es modular: cada capa funciona de forma independiente y aporta valor por sí sola.

Copyright 2026 Virtua.Cloud. Todos los derechos reservados. Este contenido es una obra original del equipo de Virtua.Cloud. La reproducción, republicación o redistribución sin permiso escrito está prohibida.