Logs autohospedados en un solo VPS: opciones y RAM

Qué cuesta realmente gestionar registros de forma autohospedada en un solo VPS

La gestión de registros autohospedada en un solo VPS (servidor privado virtual) se reduce a una pregunta: ¿necesita un clúster de búsqueda o necesita rotación y grep? La mayoría de las guías de los proveedores responden a esa pregunta empezando con 3 nodos y 12 GB de RAM, antes de enviar una sola línea de registro. En un solo servidor, esa respuesta no sirve. Por eso, la comparación siguiente se basa en lo que cada opción exige a un equipo pequeño antes de almacenar cualquier dato.

Si administra 1 o 2 servidores y quiere saber qué ocurrió el martes pasado, systemd-journald y logrotate ya cumplen esa función, y puede detenerse después de la sección siguiente. Si varias máquinas deben enviar sus registros a un único lugar y necesita búsquedas de varias semanas, Grafana Loki se adapta a un equipo pequeño porque indexa las etiquetas, no el texto de las líneas. Elasticsearch y OpenSearch ofrecen búsquedas de texto completo reales, pero consumen memoria para ello, porque el heap de la JVM (máquina virtual de Java) tiene un mínimo que no puede reducir.

Empiece por journald, porque la mayoría de los administradores se detiene aquí

systemd-journald ya se está ejecutando en cualquier servidor actual con Ubuntu o Debian. Captura la salida estándar de cada unidad de servicio, los mensajes del kernel y todo lo que se envía a syslog. Cuatro comandos cubren la mayoría de los incidentes.

journalctl -u nginx.service --since "2026-08-14 09:00" --until "2026-08-14 10:00"
journalctl -p err -b
journalctl -f -u ssh.service
journalctl --disk-usage

El último imprime una línea como Archived and active journals take up 1.1G in the file system.. Ese es el número que determina si necesita algo más. Si muestra unos cientos de megabytes y puede encontrar lo que necesita con -u y --since, el problema está resuelto.

Que el journal sobreviva a un reinicio depende de Storage= y de si existe /var/log/journal. Con la configuración habitual Storage=auto, journald escribe en /var/log/journal cuando ese directorio está presente, y en /run/log/journal cuando no lo está. /run usa memoria, por lo que, en un equipo sin ese directorio, todos los registros se borran al reiniciar, justo cuando necesita leerlos. Las imágenes de Ubuntu incluyen el directorio. Las imágenes minimalistas y basadas en contenedores a menudo no lo incluyen.

ls -d /var/log/journal
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
journalctl --disk-usage

Después del reinicio, journalctl --disk-usage debería mostrar un tamaño inferior a /var/log/journal en lugar de /run. Los valores predeterminados ya tienen límites, que es la principal razón por la que journald es una solución adecuada y no una alternativa de emergencia. La página de manual de journald.conf establece SystemMaxUse= en el 10% del tamaño del sistema de archivos y SystemKeepFree= en el 15%, y limita cada valor predeterminado calculado a 4G. SystemMaxFileSize= tiene como valor predeterminado un octavo de SystemMaxUse=, con un límite de 128M, por lo que normalmente conserva siete archivos rotados. MaxRetentionSec= tiene como valor predeterminado 0, lo que desactiva la eliminación basada en la antigüedad. Lea de nuevo ese último valor predeterminado: de fábrica, el journal está limitado sólo por el tamaño, nunca por la antigüedad.

[Journal]
Storage=persistent
SystemMaxUse=2G
MaxRetentionSec=30day

Escriba ese valor en /etc/systemd/journald.conf.d/99-size.conf, reinicie journald y compruebe que journalctl --disk-usage se haya acercado al nuevo límite. Para recuperar espacio ahora, en lugar de esperar a la siguiente rotación, ejecute sudo journalctl --vacuum-size=500M o sudo journalctl --vacuum-time=14d. Ambos muestran cada archivo que eliminan, por lo que una ejecución sin salida significa que no había nada que borrar.

Todo lo que está fuera del journal, como /var/log/nginx/access.log, es responsabilidad de logrotate, que se ejecuta a diario mediante un temporizador de systemd. Hay un fallo que conviene conocer porque parece un error en df. Después de una rotación, el archivo antiguo desaparece del listado del directorio mientras el daemon todavía lo mantiene abierto, por lo que df -h informa de que el disco está lleno, mientras que du -sh /var/log muestra mucho menos espacio utilizado. El espacio sólo se recupera cuando el proceso vuelve a abrir su registro. Para eso sirve la línea de recarga postrotate de la configuración. sudo lsof -nP +L1 muestra los archivos eliminados que todavía están abiertos y el proceso que mantiene abierto cada uno. Pruebe una regla sin modificar nada mediante sudo logrotate -d /etc/logrotate.d/nginx.

Enviar registros de varios servidores a un único colector

Cuando hay más de un equipo, administrar varios servidores Linux a la vez resulta más sencillo si sus registros llegan a un único lugar. rsyslog ya está instalado en la mayoría de las distribuciones, por lo que el colector central más sencillo consiste en un archivo en cada emisor.

*.* action(type="omfwd" target="logs.example.com" port="514" protocol="tcp")

Guárdelo como /etc/rsyslog.d/50-forward.conf, compruébelo con sudo rsyslogd -N1, que valida la configuración y termina sin iniciar nada, y después reinicie rsyslog. En el colector, habilite la entrada TCP.

module(load="imtcp")
input(type="imtcp" port="514")

Hay dos advertencias, ambas mecánicas. Syslog sin más no cifra ni autentica, por lo que cualquier sistema que pueda acceder al puerto 514 puede inyectar líneas de registro que parezcan exactamente suyas. Vincúlelo a una red privada o a una VPN y filtre el puerto con el firewall. Además, la cola de acciones predeterminada reside en memoria. Si el colector no está disponible, la cola se llena y los mensajes se descartan sin conservar una copia. rsyslog documenta una cola asistida por disco para este caso en su tutorial de reenvío fiable.

Por qué la pila ELK no es adecuada para un VPS pequeño

ELK significa Elasticsearch para el almacenamiento y la búsqueda, Logstash para la canalización de ingesta y Kibana para la interfaz. El límite inferior lo marca el heap de la JVM, que se establece antes de que llegue cualquier registro.

La documentación de Elastic indica que el heap no debe superar el 50% de la memoria total disponible para cada nodo de Elasticsearch, porque el proceso también usa búferes fuera del heap y depende de la caché de archivos del sistema operativo para leer rápidamente los archivos de índice. Por tanto, un heap de 2 GB implica una máquina de 4 GB, antes de contar Kibana y la función para la que realmente se adquirió el servidor. Elastic también indica que Elasticsearch calcula automáticamente el tamaño del heap a partir de las funciones del nodo y de la memoria total. Por eso, una máquina pequeña obtiene un heap pequeño y pasa la mayor parte del tiempo ejecutando la recolección de basura.

Logstash es el componente que hace inviable el presupuesto de una máquina pequeña. La propia página de configuración de la JVM de Elastic recomienda un heap de al menos 4 GB y como máximo 8 GB para una ingesta habitual. Eso equivale a todo un VPS de 4 GB para un solo proceso situado en el centro de la canalización.

[
  {
    "label": "Loki plus Alloy (no JVM)",
    "documented_heap_mb": 0
  },
  {
    "label": "OpenSearch demo compose",
    "documented_heap_mb": 512
  },
  {
    "label": "OpenSearch production example",
    "documented_heap_mb": 2048
  },
  {
    "label": "Logstash recommended minimum",
    "documented_heap_mb": 4096
  }
]

Esos son los valores que publica cada proyecto en su propia documentación. No son mediciones realizadas en una máquina de prueba, y la carga de trabajo puede modificarlos. El archivo compose de ejemplo de OpenSearch establece 512 MB por nodo para una demostración y 2048 MB en su ejemplo de producción, mientras que el límite inferior recomendado para Logstash es 4096 MB. La columna del heap muestra 0 para Loki y Alloy porque son programas escritos en Go que no necesitan reservar un heap de la JVM. Esa es toda la diferencia resumida en un número: un componente basado en la JVM reserva esa memoria lleguen o no registros.

Si aun así quiere ejecutar la pila Elastic en un solo servidor pequeño, elimine Logstash y envíe los datos directamente a Elasticsearch con un recolector ligero. Logstash existe para analizar y transformar grandes volúmenes de datos. En una sola máquina, puede realizar ese trabajo en el extremo de la ingesta o prescindir de él.

Tanto Elasticsearch como OpenSearch también necesitan que vm.max_map_count se aumente a 262144, porque asignan mediante memory mapping los archivos de índice y el límite predeterminado de Linux es demasiado bajo. Si un contenedor termina pocos segundos después del arranque en una máquina recién configurada, normalmente la causa es esta y nada más.

OpenSearch o Elasticsearch: ¿cuál puede implementar?

La breve historia de las licencias es importante porque determina qué puede ejecutar. En enero de 2021, Elastic cambió Elasticsearch y Kibana de Apache 2.0 a un modelo dual con SSPL (Server Side Public License) y Elastic License 2.0. AWS bifurcó el último código con licencia Apache 2.0 para crear OpenSearch, que continúa bajo Apache 2.0. En septiembre de 2024, Elastic añadió AGPLv3 (GNU Affero General Public License versión 3) como otra opción para el código fuente libre. Si una sola persona aloja el software en un único VPS, todas esas licencias permiten hacerlo. Las restricciones de las licencias aparecen cuando ofrece el software a otras personas como servicio administrado.

La diferencia práctica en un servidor pequeño es menor de lo que sugiere la historia, porque ambos usan el mismo motor subyacente. Los nombres cambian: el ciclo de vida de los índices se denomina ISM (index state management) en OpenSearch e ILM (index lifecycle management) en Elasticsearch. En agosto de 2026, OpenSearch 2.12 y las versiones posteriores no se inician si no se establece una contraseña de administrador durante la primera ejecución.

sudo sysctl -w vm.max_map_count=262144
printf 'vm.max_map_count = 262144\n' | sudo tee /etc/sysctl.d/99-opensearch.conf
docker run -d -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" \
  -e "OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password>" \
  opensearchproject/opensearch:latest

La línea sysctl -w aplica ahora la configuración, y el archivo de /etc/sysctl.d/ contiene la parte que se conserva tras reiniciar. Compruebe que el contenedor se haya iniciado con curl -k -u admin:<password> https://localhost:9200. Responde mediante https usando un certificado de demostración, por lo que -k omite la verificación, y una respuesta correcta es un pequeño bloque JSON que indica el clúster y la versión. La página de instalación de OpenSearch también indica a los usuarios de Docker Desktop que permitan al host usar al menos 4 GB de memoria. Esto es una referencia razonable de los recursos que espera tener el proceso.

Cómo Loki mantiene un tamaño reducido: etiquetas en lugar de un índice de texto completo

Loki mantiene un índice sobre las etiquetas y almacena las líneas de registro como bloques comprimidos. Primero, una consulta selecciona los streams y después filtra el texto. {unit="ssh.service"} |= "Failed password" selecciona el stream mediante su etiqueta y luego busca la cadena en esos bloques. No se indexa el contenido de ninguna línea, por lo que la ingesta es económica y no hay ningún índice invertido que mantener en memoria. El coste se traslada al momento de la consulta. Es un buen intercambio cuando normalmente se sabe qué servicio se está consultando.

La documentación de Grafana sitúa el modo monolítico, es decir, todo Loki en un solo proceso con -target=all, en volúmenes de lectura y escritura de hasta aproximadamente 20GB al día. Un VPS está muy por debajo de ese límite.

El riesgo está en la cardinalidad de las etiquetas. Cada combinación distinta de valores de etiquetas forma un stream, y el número de streams determina el tamaño de la memoria y del índice de Loki. Una etiqueta que contenga una dirección IP de cliente o un identificador de solicitud crea un stream por cada valor. Por eso, un servidor web con mucha actividad puede producir decenas de miles de streams en un día, y el proceso crece hasta que el kernel lo detiene. Limite las etiquetas a valores que pueda contar sobre el papel: unit, host, job, level. Coloque los datos variables en la propia línea, donde una expresión de filtro pueda encontrarlos durante la consulta.

Instalar Loki y Alloy en un VPS

Dos procesos hacen el trabajo. Loki almacena los registros y responde a las consultas. Grafana Alloy lee los registros y los envía. Promtail era el agente de envío anterior y llegó al final de su vida útil el 2 de marzo de 2026, por lo que las instalaciones nuevas usan Alloy. El ejemplo de Docker del propio Loki también incluye ahora una configuración de Alloy.

wget https://raw.githubusercontent.com/grafana/loki/v3.7.0/cmd/loki/loki-local-config.yaml -O loki-config.yaml

Lea ese archivo antes de usarlo. Configura path_prefix: /tmp/loki con fragmentos en /tmp/loki/chunks, lo que es correcto para una demostración, pero incorrecto para un servidor: nada de lo que haya en /tmp del contenedor sobrevive a su recreación, por lo que el historial desaparece con la siguiente actualización de la imagen. Use una ruta que monte en el contenedor.

common:
  instance_addr: 127.0.0.1
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

docker volume create loki-data
docker run --name loki -d \
  -v $(pwd):/mnt/config -v loki-data:/loki \
  -p 127.0.0.1:3100:3100 \
  grafana/loki:3.7.0 -config.file=/mnt/config/loki-config.yaml
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3100/ready

El último comando debe mostrar 200, porque /ready devuelve HTTP 200 cuando Loki está listo para aceptar tráfico. Cualquier otro resultado indica que el proceso todavía está iniciándose o que se rechazó la configuración. docker logs loki muestra la causa. Hay dos detalles deliberados en el comando de ejecución. El puerto sólo se publica en 127.0.0.1, porque la configuración de ejemplo incluye auth_enabled: false y Loki no proporciona autenticación de usuarios propia. Por tanto, cualquier sistema que pueda acceder al puerto 3100 puede leer todos los registros y escribir registros falsos. Manténgalo en loopback o detrás de una VPN o un reverse proxy con autenticación. El volumen con nombre es importante porque la imagen se ejecuta como el usuario loki con UID 10001. Por ello, un directorio del host montado mediante bind y propiedad de root no permite escrituras del contenedor.

sudo apt-get update && sudo apt-get install -y gpg wget
sudo mkdir -p /etc/apt/keyrings/
sudo wget -O /etc/apt/keyrings/grafana.asc https://apt.grafana.com/gpg-full.key
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 -y alloy

Alloy lee /etc/alloy/config.alloy. Esta configuración toma el journal del sistema y un conjunto de archivos, y envía ambos al Loki local.

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

loki.relabel "journal" {
  forward_to = []
  rule {
    source_labels = ["__journal__systemd_unit"]
    target_label  = "unit"
  }
}

loki.source.journal "read" {
  forward_to    = [loki.write.local.receiver]
  relabel_rules = loki.relabel.journal.rules
  labels        = {job = "systemd-journal", host = "app-01"}
}

local.file_match "nginx" {
  path_targets = [{"__path__" = "/var/log/nginx/*.log", "job" = "nginx", "host" = "app-01"}]
}

loki.source.file "nginx" {
  targets    = local.file_match.nginx.targets
  forward_to = [loki.write.local.receiver]
}

La regla de relabel copia el campo del journal __journal__systemd_unit en una etiqueta llamada unit. Esto permite que {unit="ssh.service"} funcione más adelante. Sin esa regla, el nombre de la unidad queda dentro de la entrada y no en una etiqueta. Por tanto, no puede seleccionarlo mediante esa etiqueta y cada consulta debe revisar todas las entradas.

sudo systemctl reload alloy
systemctl show -p User alloy
sudo journalctl -n 5
sudo -u alloy journalctl -n 5

Aquí es donde se detiene la mayoría de las configuraciones. Alloy se ejecuta con su propia cuenta de servicio, no como root. La lectura del journal del sistema requiere pertenecer al grupo systemd-journal, mientras que los archivos de /var/log/nginx pertenecen al grupo adm en Debian y Ubuntu. Sustituya la cuenta que mostró systemctl show en el último comando. Si devuelve muchas menos entradas que la ejecución como root, esa cuenta no puede leer el journal del sistema. Loki permanecerá vacío aunque la configuración sea correcta. Añada los grupos y reinicie con sudo usermod -aG systemd-journal,adm alloy seguido de sudo systemctl restart alloy.

curl -G -s "http://127.0.0.1:3100/loki/api/v1/query_range" \
  --data-urlencode 'query={job="systemd-journal"}' \
  --data-urlencode 'limit=5' | jq '.data.result | length'

Un número superior a 0 significa que existen streams con esa etiqueta y que contienen entradas. Un valor 0 significa que todavía no ha llegado nada con esa etiqueta. Un valor predeterminado explica una alerta falsa habitual: loki.source.journal establece max_age en 7h, por lo que un arranque nuevo lee las últimas siete horas del journal y no lee nada más antiguo. Para disponer de una interfaz, ejecute Grafana en el mismo equipo y configure una fuente de datos de Loki que apunte a http://127.0.0.1:3100.. Los registros de contenedores requieren otra fuente: Alloy descubre los contenedores Docker en ejecución y sigue sus registros, como hace el ejemplo de inicio de Loki. En un clúster k3s de un solo nodo en un VPS, ese trabajo se traslada al directorio de registros de los pods donde escribe kubelet.

Retención: elija cuándo se eliminan los registros

Casi nadie elige el periodo de retención hasta que el disco se llena. En ese momento, lo decide a las 3 a. m. con el servicio detenido. Defínalo desde el primer día a partir de dos preguntas: ¿hasta cuándo retrocede realmente al consultar los registros? ¿Qué información debe conservar durante la revisión de un incidente el próximo mes? Para un solo servidor, entre 14 y 30 días suele responder a ambas preguntas.

Loki no elimina nada hasta que habilita el compactor. La retención está desactivada de forma predeterminada. Esto sorprende a quienes vieron llenarse el volumen mientras retention_period permanecía en la configuración sin hacer nada.

limits_config:
  retention_period: 744h

compactor:
  working_directory: /loki/retention
  compaction_interval: 10m
  retention_enabled: true
  retention_delete_delay: 2h
  retention_delete_worker_count: 150
  delete_request_store: filesystem

744h equivale a 31 días. Cuatro reglas documentadas rigen ese bloque:

• La retención la aplica el compactor, y la documentación de Grafana indica que el compactor debe ejecutarse como una sola instancia. En un VPS esto ocurre automáticamente.
• El periodo mínimo de retención es 24h, y la retención sólo funciona cuando el periodo del índice es 24h. El ejemplo schema_config ya usa period: 24h, así que déjelo sin cambios.
• delete_request_store es obligatorio cuando retention_enabled es true. Indica el almacén que contiene las solicitudes de eliminación, por lo que en un nodo único respaldado por un sistema de archivos coincide con object_store: filesystem, que ya aparece en el esquema.
• Los chunks se marcan primero y se eliminan después de retention_delete_delay, que aquí es 2h. Por eso, el espacio libre se recupera más tarde de lo que indica la política. No evalúe la configuración según df cinco minutos después de recargarla.

OpenSearch elimina índices completos en lugar de líneas individuales. Por eso, los índices de registros se crean por día. Una política de ISM mueve un índice por distintos estados y lo elimina cuando alcanza la antigüedad establecida. Un ism_template asocia la política a los índices nuevos para que no tenga que recordarlo.

{
  "policy": {
    "description": "delete log indexes after 14 days",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [],
        "transitions": [
          { "state_name": "delete", "conditions": { "min_index_age": "14d" } }
        ]
      },
      {
        "name": "delete",
        "actions": [ { "delete": {} } ],
        "transitions": []
      }
    ],
    "ism_template": { "index_patterns": ["logs-*"], "priority": 100 }
  }
}

Independientemente del sistema que use, un valor de retención sólo es útil si se acompaña de una comprobación del espacio libre. Eliminar los registros después de 14 días no sirve si los registros de 10 días ya llenan el volumen. Por tanto, combine la política con monitorización del estado del disco en un VPS y una alerta cuando el uso alcance el 80%.

Cuánto espacio de disco ocupa 1 GB de registros

La respuesta exacta depende de tus líneas y campos. Mídelo con tus propios datos en lugar de confiar en una proporción publicada. Los mecanismos son lo bastante diferentes como para prever la tendencia. OpenSearch y Elasticsearch escriben un índice invertido para cada campo indexado junto con el documento almacenado. Por tanto, lo que ocupa espacio en disco es mayor que el texto sin procesar y cada réplica lo multiplica. En un nodo único, establece el número de réplicas en 0. Un shard de réplica en el mismo nodo no puede sobrevivir al fallo de ese nodo. Si lo dejas en 1, duplicas el espacio de disco y el estado del clúster permanece en amarillo indefinidamente. Loki escribe chunks comprimidos y un índice de etiquetas pequeño. Por tanto, su uso de espacio sigue el tamaño comprimido de las líneas.

sudo du -sh /var/lib/docker/volumes/loki-data/_data
curl -k -u admin:<password> "https://localhost:9200/_cat/indices?v&h=index,docs.count,store.size"

Ejecuta el método que corresponda durante dos días consecutivos. La diferencia es el crecimiento diario. Multiplícala por el número de días de retención y añade aproximadamente un 30 % de margen para la compactación y las fusiones. Después, compárala con el volumen. Si no cabe, reduce la retención antes de comprar más disco. Un volumen mayor sólo retrasa el mismo problema unas semanas.

Qué falla primero en un servidor pequeño

La memoria se agota primero. El killer OOM (out of memory) del kernel elige un proceso grande, y el proceso más grande en un servidor de registros es la JVM. journalctl -k | grep -i "killed process" muestra la terminación con el nombre del proceso entre corchetes. La víctima no siempre es la pila de registros: también puede elegirse sshd o la base de datos. Así es como un experimento de registro puede dejar fuera de servicio la aplicación de la que quería obtener registros. Asigne límites máximos explícitos a los contenedores para que el fallo se produzca en el componente elegido. Para eso sirven los límites de memoria en Docker Compose.

El disco se llena después, y los motores de búsqueda fallan de una forma específica y fácil de reconocer. Elasticsearch y OpenSearch supervisan el uso del disco en varios niveles. El umbral bajo está en 85% y el umbral alto, en 90%. En el nivel de inundación del 95%, todos los índices que tienen un shard en ese nodo reciben el bloqueo index.blocks.read_only_allow_delete, y las escrituras fallan con blocked by: [FORBIDDEN/12/index read-only / allow delete (api)]. El bloqueo se libera cuando el uso vuelve a caer por debajo del umbral alto. Libere espacio primero y elimine el bloqueo manualmente sólo si persiste.

curl -k -u admin:<password> -X PUT "https://localhost:9200/_all/_settings" \
  -H 'Content-Type: application/json' \
  -d '{"index.blocks.read_only_allow_delete": null}'

Loki falla de forma más silenciosa. No tiene un modo de sólo lectura al que cambiar, por lo que un volumen lleno aparece como envíos fallidos en el emisor y como interrupciones en los resultados de las consultas. El problema de cardinalidad se manifiesta como un aumento lento de la memoria, no como un error. Supervise periódicamente el tamaño del directorio de chunks, no después de un incidente.

El último fallo consiste en introducir datos incorrectos. Un sistema de registros no es un sistema de métricas: conservar como texto la carga de CPU muestreada cada 10 segundos resulta costoso y dificulta la representación gráfica. Esa tarea corresponde a algo como un servidor de monitorización Zabbix en Ubuntu 24.04. Las excepciones de las aplicaciones necesitan agrupación, deduplicación y una vista de la traza de pila. Esa es la función de un gestor de errores autoalojado. Saber si el sitio está caído es otra tarea distinta, que se resuelve con una página de disponibilidad y estado como Uptime Kuma. Reserve el sistema de registros para las líneas de texto que una persona vaya a leer.

FAQ

¿Necesito Elasticsearch para buscar en los registros de mi servidor?

No para uno o dos servidores. journalctl ya filtra por unidad, prioridad, arranque y rango de tiempo, y los archivos rotados responden a grep y zgrep. Un clúster de búsqueda justifica su consumo de memoria cuando tiene muchas máquinas, cuando necesita búsquedas de texto libre en todas ellas a la vez o cuando varias personas necesitan una interfaz compartida. Por debajo de ese volumen, journald con un límite de tamaño y un tiempo de retención hace el mismo trabajo sin RAM adicional.

¿Cuánta RAM necesito para administrar registros en servidores propios?

Use las cifras publicadas por cada proyecto en lugar de aplicar una regla general. Loki y Alloy son programas escritos en Go y no necesitan reservar el heap por adelantado, y Grafana documenta Loki monolítico con hasta aproximadamente 20GB al día. El compose de ejemplo de OpenSearch establece 512 MB de heap para una demostración y 2 GB en su ejemplo de producción. Elastic indica que el heap debe mantenerse en 50% o menos de la memoria total, por lo que un heap de 2 GB implica una máquina de 4 GB antes de añadir Kibana. La documentación de Logstash recomienda al menos 4GB de heap para el propio servicio. Son configuraciones documentadas, no pruebas de rendimiento. Mida su propia carga antes de dimensionar el plan.

¿Cuál es la diferencia real entre Loki y OpenSearch para los registros?

El modelo de índices. Loki indexa sólo las etiquetas y conserva el cuerpo del registro en bloques comprimidos que se exploran durante la consulta. Por eso, las escrituras son económicas y las consultas amplias tienen un coste mayor. OpenSearch indexa el contenido de los campos. Así, las búsquedas arbitrarias de texto completo son rápidas, pero tanto la memoria como el disco deben almacenar el índice. Elija Loki cuando sepa qué servicio y qué intervalo de tiempo quiere consultar. Elija OpenSearch cuando necesite buscar texto que no puede predecir de antemano.

¿Cuánto tiempo debo conservar los registros en un VPS?

Elija el número antes de que el disco lo elija por usted. Configúrelo en un único lugar por sistema: MaxRetentionSec= y SystemMaxUse= para journald, retention_period con el compactador habilitado para Loki y una política ISM con min_index_age para OpenSearch. En la mayoría de las configuraciones de un solo servidor, de 14 a 30 días cubren la depuración y la revisión de incidentes. Todo lo que deba conservar durante más tiempo debe pertenecer a una copia almacenada fuera del equipo, porque un registro conservado sólo en el servidor que falló no es un registro fiable.

¿Sigue siendo Promtail la forma recomendada de enviar registros a Loki?

No. Promtail llegó al final de su vida útil el 2 de marzo de 2026 y Grafana Alloy lo sustituye. El ejemplo de instalación de Loki para Docker ahora incluye una configuración de Alloy, y Grafana proporciona un conversor que transforma una configuración existente de Promtail en sintaxis de Alloy. Una instalación existente de Promtail sigue funcionando, pero no recibe correcciones. Trate la migración como una tarea de mantenimiento, no como una actualización que pueda aplazar indefinidamente.