rsyslog en la nube: 4 free tiers para centralizar logs sin montar tu propio servidor

rsyslog no sirve únicamente para escribir /var/log/syslog. También puede actuar como forwarder: recibe eventos locales y los envía por red a un colector central.

Eso abre una posibilidad muy útil para servidores pequeños, laboratorios y VPS personales: en lugar de montar y mantener otro servidor de logs, podemos enviar los eventos a un servicio gestionado con un free tier.

La arquitectura puede ser tan sencilla como esta:

Oracle VPS
  │
  ├─ sshd
  ├─ sudo
  ├─ kernel
  ├─ nginx
  └─ aplicaciones
       │
       ▼
    rsyslog
       │
       │ TCP + TLS
       ▼
 servicio de logging
       │
       ├─ búsqueda
       ├─ filtros
       ├─ dashboards
       └─ alertas

A septiembre de 2026 hay varias opciones interesantes. Las cuatro que vale la pena conocer son Loggly, Better Stack, Papertrail y Grafana Cloud.

Los límites de los planes gratuitos cambian con el tiempo. Las cifras de este artículo fueron verificadas el 8 de septiembre de 2026 contra la documentación y páginas de precios oficiales.

Qué identidad conserva rsyslog al enviar un evento

Antes de comparar servicios conviene entender qué viaja dentro de un mensaje syslog.

Un evento tradicional puede verse así:

Sep 8 18:53:12 oracle-vps sshd[1234]: Failed password for invalid user admin

El hostname oracle-vps forma parte del mensaje. Con formatos modernos como RFC 5424 también aparecen campos como:

timestamp
hostname
app-name
process-id
message-id
structured-data
message

Esto significa que un colector central puede recibir eventos de diez servidores distintos y seguir distinguiendo su origen.

Por ejemplo:

host=oracle-vps   app=sshd
host=acer         app=myagent
host=server-03    app=nginx

Hay una distinción importante: el hostname declarado en el mensaje no es necesariamente una identidad criptográficamente confiable. Un receptor también puede conocer la IP de la conexión y, cuando usamos TLS con certificados, autenticar mejor al emisor.

Comparativa rápida

Servicio	Free tier verificado	Retención gratuita	¿rsyslog directo?	Transporte recomendado
Loggly Lite	200 MB/día	7 días	Sí	TCP + TLS
Better Stack	3 GB/mes	3 días	Sí	TCP + TLS, puerto 6514
Papertrail	50 MB/mes	archivo descargable 1 semana	Sí	TCP + TLS
Grafana Cloud Logs	50 GB/mes	14 días	Mediante colector	rsyslog → Alloy → Loki

La tabla parece favorecer inmediatamente a Grafana Cloud por volumen, pero el volumen no es el único factor. La diferencia fundamental está en cuánto trabajo queremos hacer entre rsyslog y el backend.

1. Loggly: probablemente el free tier más cómodo para rsyslog puro

El plan Loggly Lite sigue siendo gratuito y actualmente incluye:

• 200 MB al día de volumen.
• 7 días de retención.
• logging centralizado.
• búsqueda y filtros.
• colección agentless.

La prueba inicial es de 30 días y, según la propia página de precios, al terminar la cuenta se convierte al paquete Lite gratuito.

Loggly soporta syslog por UDP, TCP y TCP con TLS. Para tráfico que sale de nuestra red hacia Internet, TCP con TLS es la opción lógica: TCP permite retransmisión y TLS protege el contenido en tránsito.

Conceptualmente:

rsyslog
   │
   │ TCP/TLS
   ▼
Loggly

Para un VPS pequeño, 200 MB diarios es un margen considerable. Un servidor que sólo genera logs de sistema, SSH, sudo, cron y unas pocas aplicaciones puede quedar muy por debajo de ese límite.

Cuándo lo elegiría: cuando quiero aprender y utilizar rsyslog como pieza principal de forwarding sin introducir otro agente en la máquina.

Fuente: Loggly Pricing y Cloud Syslog Solution.

2. Better Stack: integración directa y una experiencia más moderna

Better Stack ofrece actualmente en su plan gratuito:

• 3 GB de logs al mes.
• 3 días de retención.
• Live Tail.
• consultas y filtros.
• integración con el resto de su plataforma de observabilidad.

Tiene documentación específica para rsyslog.

Su receptor escucha:

TCP + TLS :6514
UDP       :6517

Better Stack recomienda TCP cifrado. Además, no basta con enviar cualquier mensaje al puerto: su configuración de rsyslog añade un source_token dentro de los structured data de syslog para autenticar la fuente.

La acción termina pareciéndose conceptualmente a:

rsyslog
   │
   │ RFC 5424 + source token
   │ TCP/TLS :6514
   ▼
Better Stack

La documentación oficial incluso proporciona un script que genera la configuración correspondiente y configura una cola en disco para evitar perder mensajes cuando la conexión está caída.

Ese detalle importa. Un sistema remoto de logs no debería convertir una interrupción temporal de Internet en pérdida inmediata de evidencia.

Cuándo lo elegiría: cuando quiero una UI moderna, Live Tail y una configuración soportada explícitamente para rsyslog, aceptando que la retención gratuita es corta.

Fuentes: Better Stack Pricing y Send logs to Better Stack with RSyslog.

3. Papertrail: el modelo syslog clásico llevado a SaaS

Papertrail es posiblemente la idea más fácil de visualizar.

Creas un destino y recibes algo equivalente a:

logsN.papertrailapp.com:XXXXX

Después apuntas rsyslog hacia ese host y puerto.

El free tier actual ofrece 50 MB al mes. Además, Papertrail indica que los archivos descargables del plan gratuito se mantienen durante una semana.

La configuración básica de rsyslog puede verse así:

*.* @logsN.papertrailapp.com:XXXXX

Un solo @ significa UDP.

Para TCP:

*.* @@logsN.papertrailapp.com:XXXXX

Dos @ significan TCP.

Papertrail también soporta syslog sobre TCP con TLS, que es lo que deberíamos preferir para enviar eventos sensibles por Internet.

Cuándo lo elegiría: para una máquina con poco volumen donde quiero la experiencia más cercana a «dame un endpoint syslog y yo te mando eventos».

Su principal limitación es clara: 50 MB/mes es muy poco comparado con las otras alternativas.

Fuentes: Papertrail Plans, Unix and BSD system logs y TLS encrypted syslog.

4. Grafana Cloud: el free tier enorme, pero con una pieza intermedia

Grafana Cloud Logs ofrece un free tier especialmente generoso:

• 50 GB de logs ingeridos al mes.
• 14 días de retención.

Eso cambia completamente la escala de la comparación.

Pero Grafana Cloud no es la opción más directa si nuestro objetivo específico es practicar rsyslog como cliente de un SaaS syslog.

Grafana recomienda Grafana Alloy como colector. Alloy incluye el componente loki.source.syslog, capaz de escuchar mensajes RFC 5424 y RFC 3164 por TCP o UDP, procesarlos y enviarlos a Loki.

La topología típica sería:

Linux / rsyslog
      │
      │ syslog
      ▼
Grafana Alloy
      │
      │ loki.write
      ▼
Grafana Cloud Logs / Loki
      │
      ▼
Grafana

Alloy puede además transformar etiquetas y conservar información útil como:

hostname
severity
facility
app_name
proc_id
connection_ip

Es un salto de complejidad, pero también un salto de capacidad: pasamos de «un servidor syslog remoto» a una plataforma de observabilidad completa.

Cuándo lo elegiría: cuando quiero mucho volumen gratuito, retención de dos semanas y la posibilidad de crecer hacia dashboards, métricas, traces y una arquitectura LGTM.

Fuentes: Grafana Cloud Pricing, loki.source.syslog y Collect logs with Grafana Alloy.

@ y @@: la pequeña sintaxis que conviene recordar

La sintaxis clásica de rsyslog tiene una regla fácil de memorizar:

*.* @servidor:514

significa UDP.

Mientras que:

*.* @@servidor:514

significa TCP.

El selector de la izquierda:

*.*

significa todas las facilities y todas las prioridades.

Podemos filtrar. Por ejemplo:

auth,authpriv.* @@logs.example.com:514

para enviar únicamente eventos de autenticación.

Sin embargo, hay que evitar una simplificación peligrosa: usar @@ no significa automáticamente que la conexión esté cifrada.

@@ selecciona TCP. Para TLS hacen falta los parámetros de netstream/TLS, certificados y autenticación que exija el proveedor.

Para Internet, no usaría UDP salvo que exista una razón concreta

UDP sigue siendo útil dentro de ciertas redes porque es simple y barato, pero no confirma entrega.

En un envío remoto por Internet prefiero:

TCP
 + TLS
 + cola local de rsyslog

La cola es importante porque desacopla dos eventos:

se generó el log
        ≠
la nube estaba accesible en ese instante

Con una cola en disco, rsyslog puede retener temporalmente eventos y reintentar cuando se restablece la conexión.

No conviene enviar absolutamente todo

Centralizar logs facilita investigar un incidente, pero también puede crear tres problemas:

1. consumir rápidamente el free tier;
2. aumentar ruido y dificultar búsquedas;
3. sacar de la máquina datos que no deberían abandonar el host.

Antes de usar:

*.* ...

conviene decidir qué queremos centralizar.

Por ejemplo, para un VPS podríamos comenzar con:

auth/authpriv
sshd
sudo
kernel warnings/errors
nginx errors
servicios críticos propios

Después ampliar según las necesidades reales.

Los logs pueden contener nombres de usuario, direcciones IP, URLs, parámetros, paths y ocasionalmente secretos filtrados por aplicaciones mal diseñadas. TLS protege el tránsito, pero no soluciona qué información decidimos enviar.

¿Cuál elegir?

Si el objetivo es específicamente aprender rsyslog y centralizar los eventos de uno o varios VPS, mi orden práctico sería:

1. Loggly
   200 MB/día · 7 días
   rsyslog directo

2. Better Stack
   3 GB/mes · 3 días
   rsyslog directo y TLS bien documentado

3. Grafana Cloud
   50 GB/mes · 14 días
   muchísimo más margen, pero añadiendo Alloy

4. Papertrail
   extremadamente sencillo
   pero sólo 50 MB/mes

No significa que Loggly sea «mejor» que Grafana Cloud en general. Significa que Loggly encaja mejor con la pregunta concreta de enviar rsyslog directamente a un servicio gratuito.

Si el objetivo evoluciona hacia una plataforma completa de observabilidad, Grafana Cloud resulta mucho más atractivo.

La arquitectura mínima que usaría en un VPS

Para un servidor Linux expuesto a Internet:

journald / aplicaciones
        │
        ▼
     rsyslog
        │
        ├─ archivos locales
        │
        └─ cola persistente
              │
              │ TCP + TLS
              ▼
       servicio remoto

Así conservamos dos propiedades importantes:

• una copia local útil para diagnóstico inmediato;
• una copia externa que sigue existiendo aunque el host sea comprometido o destruido.

Esa segunda propiedad es una de las razones más fuertes para centralizar logs de seguridad: si el atacante consigue controlar la máquina, los registros que sólo viven en esa máquina dejan de ser una fuente completamente confiable.

rsyslog, pese a ser una pieza veterana del ecosistema Linux, sigue resolviendo elegantemente un problema muy moderno: mover telemetría desde muchas máquinas hacia un lugar central, con filtros, colas, estructura y transporte seguro.