Guía de despliegue

Grafana Alloy en un VPS: instalar y migrar desde Promtail

Desplegar en un VPS Cloud →

Tutorial

Grafana Alloy en un VPS: instalar y migrar desde Promtail

Seguridad y monitorización12 min de lectura15 pasos

Promtail ya no recibe ninguna actualización: Grafana lo declara al final de su vida útil desde el 2 de marzo de 2026. Si su VPS todavía envía sus logs a Loki con ese agente, cualquier vulnerabilidad descubierta mañana quedará abierta. Grafana Alloy ocupa su lugar y además recoge las métricas del sistema, lo que elimina un exporter más de su servidor. Esta guía instala Alloy como servicio systemd, lo conecta a Loki y Prometheus, migra una configuración de Promtail existente y resuelve los errores de permisos que Alloy no siempre señala.

Contenido· Por qué sustituir Promtail por Alloy ahora1/13
  1. 01Por qué sustituir Promtail por Alloy ahora
  2. 02Lo que cambia un agente único en su servidor
  3. 03Requisitos cuantificados para Alloy en un VPS
  4. 04Instalar Alloy y conectar logs y métricas
  5. 05Alloy y Docker: leer los contenedores sin abrirlo todo
  6. 06Migrar desde Promtail: el riesgo real son las posiciones
  7. 07Migrar una configuración de Promtail sin pérdidas ni duplicados
  8. 08Promtail y Alloy, frente a frente
  9. 09Configuración tras la instalación: UI, secretos y almacenamiento
  10. 10Reforzar el servicio sin romper la recolección
  11. 11Resolución de problemas: los errores que Alloy no grita
  12. 12Mensajes de error y soluciones
  13. 13Un agente al día en un servidor que le pertenece

Por qué sustituir Promtail por Alloy ahora

La página oficial de Promtail no deja lugar a dudas: el agente está al final de su vida útil desde el 2 de marzo de 2026, el soporte comercial ha terminado y todo el desarrollo continúa en Grafana Alloy. Un agente de recolección es un proceso privilegiado que funciona de forma permanente: dejarlo sin correcciones no es sostenible.

Alloy no es un Promtail con otro nombre. Es un recolector único, configurado por componentes: una fuente de logs, un exporter de métricas del sistema, un envío hacia Loki y otro hacia Prometheus. En un VPS que ejecutaba Promtail y node_exporter en paralelo, ahora basta un solo servicio. También puede reenviar OTLP si instrumenta sus aplicaciones, tema tratado en nuestra guía de Tempo y OpenTelemetry.

Esta guía no reinstala Loki ni Prometheus: la parte de servidor se describe en la guía de Loki y Grafana y en la guía de Grafana y Prometheus. Aquí nos ocupamos del agente.

Lo que cambia un agente único en su servidor

  • Un solo servicio que vigilar — logs y métricas pasan por el mismo proceso alloy, con un único registro que leer cuando algo falla.
  • Actualizaciones que siguen llegando — Alloy se publica en los repositorios apt y rpm de Grafana: un apt upgrade lo mantiene al día como el resto del sistema.
  • Una migración con herramientas — el comando alloy convert traduce una configuración de Promtail existente y genera un informe de lo que no ha podido convertir.
  • Métricas del sistema integradas — el componente prometheus.exporter.unix sustituye a node_exporter sin binario adicional ni puerto que abrir.
  • Una interfaz de depuración local — la UI en el puerto 12345 muestra el grafo de componentes y sus valores, accesible mediante un túnel SSH.
  • Salida hacia su propia pila o hacia Grafana Cloud — el mismo archivo envía a un Loki autoalojado o a un servicio gestionado cambiando una URL.

Requisitos cuantificados para Alloy en un VPS

Alloy se instala en Debian, Ubuntu, AlmaLinux o Rocky Linux desde los repositorios oficiales de Grafana. El paquete crea un usuario de sistema alloy, un servicio systemd con el mismo nombre y el archivo de configuración /etc/alloy/config.alloy.

En cuanto a recursos, la documentación de Alloy da dos órdenes de magnitud: alrededor de 1 núcleo y 120 MiB de memoria por cada MiB/s de logs ingeridos, y alrededor de 11 GiB de memoria por cada millón de series activas de Prometheus. Un VPS aislado expone unos pocos miles de series y rara vez escribe más de unos cientos de KiB de logs por segundo. Nuestra recomendación editorial: reserve medio vCPU y de 256 a 512 MB de RAM para el agente, y algunos GB de disco en /var/lib/alloy para las posiciones de lectura y el búfer de envío.

Por último, necesita un destino: un Loki accesible en /loki/api/v1/push y un Prometheus iniciado con el indicador --web.enable-remote-write-receiver, que abre el endpoint /api/v1/write. No hay que abrir ningún puerto de entrada en el VPS del agente: Alloy envía, no se le consulta.

Instalar Alloy y conectar logs y métricas

  1. Añadir el repositorio de Grafana en Debian o Ubuntu

    sudo mkdir -p /etc/apt/keyrings
    sudo wget -O /etc/apt/keyrings/grafana.asc https://apt.grafana.com/gpg-full.key
    sudo chmod 644 /etc/apt/keyrings/grafana.asc
    echo "deb [signed-by=/etc/apt/keyrings/grafana.asc] https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
    sudo apt-get update && sudo apt-get install alloy

  2. O instalarlo en AlmaLinux y Rocky Linux

    Importe la clave con wget -q -O gpg.key https://rpm.grafana.com/gpg.key y después sudo rpm --import gpg.key. Cree /etc/yum.repos.d/grafana.repo con baseurl=https://rpm.grafana.com, repo_gpgcheck=1, gpgcheck=1 y enabled=1, como indica la página de instalación de Alloy para Linux, y ejecute sudo dnf install alloy.

  3. Iniciar el servicio y comprobar su usuario

    sudo systemctl enable --now alloy
    sudo systemctl status alloy
    systemctl cat alloy | grep User

    El último comando debe mostrar User=alloy. El paquete no fija ningún Group=: los permisos de lectura vienen, por tanto, de los grupos secundarios de ese usuario, un punto clave para lo que sigue.

  4. Declarar el destino de los logs

    Abra /etc/alloy/config.alloy y añada el envío hacia Loki:

    loki.write "default" {
    endpoint {
    url = "http://127.0.0.1:3100/loki/api/v1/push"
    }
    }

    Sustituya la dirección por la de su Loki. Si es remoto, use HTTPS y un bloque basic_auth.

  5. Recoger journald y los archivos de log

    loki.source.journal "system" {
    forward_to = [loki.write.default.receiver]
    labels = {"job" = "systemd-journal"}
    }
    local.file_match "nginx" {
    path_targets = [{"__path__" = "/var/log/nginx/*.log", "job" = "nginx"}]
    }
    loki.source.file "nginx" {
    targets = local.file_match.nginx.targets
    forward_to = [loki.write.default.receiver]
    }

    Por defecto, la fuente journal lee /var/log/journal y /run/log/journal, y solo retrocede siete horas en el primer arranque.

  6. Recoger las métricas del sistema

    prometheus.exporter.unix "node" { }
    prometheus.scrape "node" {
    targets = prometheus.exporter.unix.node.targets
    forward_to = [prometheus.remote_write.default.receiver]
    }
    prometheus.remote_write "default" {
    endpoint {
    url = "http://127.0.0.1:9090/api/v1/write"
    }
    }

    Si node_exporter ya funcionaba en la máquina, deténgalo tras el cambio para no recoger dos veces las mismas series.

  7. Validar antes de recargar

    sudo alloy validate /etc/alloy/config.alloy
    sudo systemctl reload alloy
    sudo journalctl -u alloy -f

    validate señala un error de sintaxis o un componente mal referenciado antes de que el servicio cargue la configuración.

  8. Conceder permisos de lectura

    id alloy debe listar los grupos adm y systemd-journal. El paquete los añade cuando existen; tras una instalación por binario o un grupo eliminado, restablézcalos con sudo usermod -aG adm,systemd-journal alloy y después sudo systemctl restart alloy. Para una carpeta de aplicación propiedad de otro usuario, la documentación prefiere una ACL a un grupo más: sudo setfacl -R -m u:alloy:rx /var/log/monapp y sudo setfacl -R -d -m u:alloy:rx /var/log/monapp.

  9. Comprobar de extremo a extremo y conectar sus paneles

    Escriba una línea de prueba con logger -t alloy-test "ligne de test alloy" y búsquela en Grafana, pestaña Explore, con la consulta {job="systemd-journal"} |= "ligne de test alloy". En cuanto a métricas, la consulta node_load1 debe devolver una serie para su VPS. Si ambas responden, reutilice los paneles de nuestra guía de Grafana y Prometheus, que leen las mismas series node_*.

Alloy y Docker: leer los contenedores sin abrirlo todo

Para leer los logs de sus contenedores, Alloy instalado en el host combina discovery.docker y loki.source.docker, ambos apuntando a unix:///var/run/docker.sock. El usuario alloy debe entonces poder abrir ese socket, lo que en la práctica pasa por sudo usermod -aG docker alloy. Hágalo con conocimiento de causa: la documentación de Docker recuerda que el grupo docker concede privilegios equivalentes a root. Su agente de logs se convierte, de hecho, en administrador de la máquina.

También puede ejecutar Alloy en un contenedor, con la imagen grafana/alloy, el archivo montado en /etc/alloy/config.alloy y el argumento --storage.path=/var/lib/alloy/data sobre un volumen persistente. Montar el socket como :ro no limita las llamadas a la API de Docker: un socket sigue siendo un socket. Y para las métricas del host, el contenedor debe recibir el sistema de archivos, /proc y /sys de la máquina como montajes.

En un único VPS, el paquete systemd sigue siendo lo más sencillo de auditar.

Migrar desde Promtail: el riesgo real son las posiciones

Promtail mantiene un archivo de posiciones que guarda, para cada archivo seguido, dónde dejó de leer. Alloy guarda las suyas en otro lugar, en la carpeta definida por --storage.path. La conversión lo tiene en cuenta: el bloque loki.source.file generado por alloy convert incluye un argumento legacy_positions_file que apunta al archivo antiguo, para retomar la lectura en el punto correcto.

Este mecanismo tiene un punto débil documentado. En la issue grafana/alloy #5493, un usuario describe el error error reading legacy positions file seguido de permission denied: Alloy no pudo leer el archivo antiguo, lo ignoró y reenvió todos los logs del servidor desde el principio. El mantenedor consideró legítimo detener Alloy en ese caso y la issue está cerrada, pero no apueste por su versión: compruebe los permisos antes del primer arranque.

El otro riesgo es el contrario: Promtail y Alloy activos a la vez envían cada línea dos veces. El orden siguiente evita ambos.

Migrar una configuración de Promtail sin pérdidas ni duplicados

  1. Localizar la configuración y el archivo de posiciones

    Abra la configuración de Promtail, a menudo /etc/promtail/config.yml, y anote el valor de positions.filename. En una instalación con Docker Compose, ese archivo vive en un volumen: anote su ruta real en el host.

  2. Convertir con un informe

    alloy convert --source-format=promtail --report=/tmp/promtail-report.txt --output=/tmp/promtail.alloy /etc/promtail/config.yml

    Lea el informe antes que nada. La opción --bypass-errors fuerza una conversión parcial, pero la documentación advierte de que el comportamiento puede diferir entonces del original.

  3. Comprobar que el usuario alloy lee el archivo antiguo

    grep legacy_positions_file /tmp/promtail.alloy
    sudo -u alloy cat /var/lib/promtail/positions.yaml

    Adapte la ruta a la que anotó antes. Si el segundo comando falla, copie el archivo en una carpeta legible por alloy y corrija la ruta en la configuración convertida.

  4. Detener Promtail antes de iniciar Alloy

    sudo systemctl stop promtail, o docker compose stop promtail para una pila en contenedores. Promtail escribe entonces sus últimas posiciones y ninguna línea se envía dos veces durante el cambio.

  5. Cambiar la configuración

    Lleve los bloques convertidos a /etc/alloy/config.alloy, ejecute sudo alloy validate /etc/alloy/config.alloy y después sudo systemctl restart alloy. Compruebe enseguida sudo journalctl -u alloy | grep -i positions: no debe aparecer ninguna línea error reading legacy positions file.

  6. Vigilar una semana y desinstalar

    Compare el volumen de logs en Grafana antes y después del cambio, y siga el contador loki_write_sent_entries_total de Alloy. Conserve la configuración de Promtail unos días, luego sudo systemctl disable promtail y retire el paquete o el servicio de Compose.

Promtail y Alloy, frente a frente

Desplace la tabla

CriterioPromtailGrafana Alloy
EstadoFin de vida desde el 2 de marzo de 2026, sin más actualizacionesDesarrollo activo, sucesor designado por Grafana
Señales recogidasSolo logsLogs, métricas, trazas OTLP y perfiles
Métricas del sistemanode_exporter que instalar aparteComponente `prometheus.exporter.unix` integrado
ConfiguraciónYAMLSintaxis de Alloy por componentes, conversión con `alloy convert`
Posiciones de lecturaArchivo definido en la configuraciónCarpeta `--storage.path`, reanudación con `legacy_positions_file`
DepuraciónRegistro del servicioRegistro del servicio y UI local en el puerto 12345
Usuario del servicioSegún el modo de instalación`alloy`, grupos `adm` y `systemd-journal` añadidos por el paquete

Configuración tras la instalación: UI, secretos y almacenamiento

La interfaz de depuración escucha por defecto en 127.0.0.1:12345. Déjela así y ábrala mediante un túnel: ssh -L 12345:127.0.0.1:12345 [email protected] y después http://localhost:12345 en su navegador. Si aun así quiere exponerla, añada --server.http.listen-addr=0.0.0.0:12345 a CUSTOM_ARGS, pero solo detrás de un cortafuegos que filtre ese puerto.

Las opciones de arranque están en /etc/default/alloy en Debian y Ubuntu, y en /etc/sysconfig/alloy en AlmaLinux y Rocky. Ahí también van los secretos: declare una variable LOKI_PASSWORD, léala en la configuración con sys.env("LOKI_PASSWORD") y mantenga la contraseña fuera de config.alloy.

Para un Loki remoto, no envíe nunca HTTP sin cifrar por Internet: coloque Loki detrás de un proxy inverso TLS con autenticación, como se describe en nuestra guía de Loki. Por último, vigile el espacio de /var/lib/alloy: si Loki no está accesible, ahí se acumula lo que espera ser enviado.

Reforzar el servicio sin romper la recolección

La documentación de Alloy propone un archivo drop-in, creado con sudo systemctl edit alloy para que sobreviva a las actualizaciones del paquete: NoNewPrivileges=yes, ProtectSystem=strict, ProtectHome=yes, PrivateTmp=yes y ReadWritePaths=/var/lib/alloy. Con ProtectSystem=strict, añada ReadOnlyPaths=/var/log/journal y ReadOnlyPaths=/run/log/journal; si no, la fuente journal deja de leer. Termine con sudo systemctl daemon-reload y sudo systemctl restart alloy. Prefiera una ACL por carpeta a añadir grupos, y conceda el grupo docker solo si realmente recoge contenedores.

Resolución de problemas: los errores que Alloy no grita

La mayoría de los fallos de Alloy en un VPS no son caídas. El servicio está activo, la interfaz está en verde y Grafana sigue vacío. La razón la documentan los propios mantenedores en la issue grafana/alloy #2994, cerrada en favor de la #6340: la salud de un componente significa que se ejecuta, no que transmite.

Dos reflejos bastan para salir de esa niebla. Lea el registro del servicio con sudo journalctl -u alloy --since "10 min ago" y consulte las métricas internas del agente con curl -s http://127.0.0.1:12345/metrics | grep loki_write. El contador loki_write_sent_entries_total debe subir; loki_write_dropped_entries_total cuenta las líneas descartadas después de agotar todos los intentos de envío.

Mensajes de error y soluciones

  • La fuente journal arranca, pero no llega ninguna línea — la documentación de loki.source.journal lo dice: sin los grupos adm y systemd-journal, el componente arranca sin error y no recoge nada. Corríjalo con sudo usermod -aG adm,systemd-journal alloy y reinicie el servicio, porque un grupo añadido solo se aplica en el siguiente arranque.
  • failed to tail the file: open /var/log/…: permission denied — el archivo existe, pero alloy no puede leerlo. Conceda una ACL en la carpeta con setfacl -R -m u:alloy:rx y su variante -d para los archivos que cree después la rotación.
  • Ningún mensaje, ninguna línea de toda una carpeta — la issue grafana/alloy #6542 describe logs que nunca se envían sin el menor error. Un mantenedor confirma allí que un archivo ilegible se registra, pero una carpeta inaccesible no. Pruebe con sudo -u alloy ls /var/log/monapp.
  • error reading legacy positions file … permission denied — Alloy no leyó las posiciones de Promtail y puede reenviarlo todo desde el principio (issue #5493). Detenga el servicio, haga el archivo legible para alloy y vuelva a iniciarlo.
  • failed to identify the read-write layer ID … mount-id: permission denied — error del componente cAdvisor bajo systemd (issue #4068). El grupo docker no basta; algunos usuarios indican que un drop-in con AmbientCapabilities=CAP_DAC_READ_SEARCH y CapabilityBoundingSet=CAP_DAC_READ_SEARCH lo resuelve sin ejecutar el servicio como root. Es una solución de la comunidad, que conviene probar antes de generalizarla.
  • La UI está en verde, pero Grafana sigue vacío — compruebe loki_write_sent_entries_total y la línea de prueba escrita con logger. Si el contador no avanza, el fallo está antes, en la fuente.

Un agente al día en un servidor que le pertenece

Alloy necesita lo que un alojamiento compartido no ofrece: un servicio systemd, acceso de lectura a /var/log y al journal, a veces el socket de Docker. En un VPS, usted elige su distribución, conserva su pila de Loki y Prometheus y decide qué permisos recibe el agente. Si prefiere no administrar el sistema usted mismo, la opción de administración de VPS existe para el servidor.

La documentación oficial sigue siendo la referencia para cada componente: la migración desde Promtail, los permisos en Linux y la página de fin de vida de Promtail. Para el trazado de aplicaciones, continúe con nuestra guía de Tempo y OpenTelemetry.

Un VPS donde su agente de recolección tiene los permisos que necesita

En un VPS de ServOrbit.com, tiene acceso root, elección de sistema operativo entre Ubuntu, Debian, AlmaLinux y Rocky, y control sobre systemd, los grupos y las ACL. Instala Alloy, Loki o Prometheus como prefiera, y la opción de administración de VPS existe para el servidor.

¿Necesita ayuda?

Consulte nuestro centro de ayuda y nuestra FAQ, o contacte con nuestro equipo: llamada, WhatsApp o correo electrónico. Soporte en francés, inglés y árabe.

Escribir por WhatsAppse abre en una pestaña nueva