Por qué una base única para la observabilidad
Métricas, logs y trazas describen el mismo incidente desde tres ángulos. Cuando viven en tres herramientas, saltas de una pestaña a otra copiando marcas de tiempo, y la pregunta «¿qué peticiones lentas precedieron a estos errores?» exige tres consultas en tres lenguajes.
GreptimeDB los guarda todos en tablas, en un motor columnar diseñado para series temporales. Las métricas recibidas de Prometheus siguen siendo consultables en PromQL, y todo —métricas, logs y trazas— se consulta también en SQL, con uniones y agregados. Grafana la ve como una fuente Prometheus corriente.
Lo que aporta GreptimeDB
- Tres señales, un motor — métricas, logs y trazas en tablas de un mismo almacenamiento columnar.
- SQL y PromQL — uniones, ventanas y agregados en SQL; tus consultas PromQL funcionan tal cual.
- Compatible con Prometheus — destino
remote_write, API de consulta Prometheus, fuente de datos de Grafana sin plugin. - OpenTelemetry nativo — ingesta OTLP/HTTP de métricas, logs y trazas.
- Otros protocolos — API push de Loki, line protocol de InfluxDB, API SQL por HTTP.
- Panel integrado — editor SQL y PromQL, exploración de tablas, gráficos de los resultados.
GreptimeDB frente a una pila Prometheus, Loki y Tempo
Desplace la tabla
| GreptimeDB | Prometheus + Loki + Tempo | |
|---|---|---|
| Servicios que operar | Un solo contenedor | Tres servicios, tres configuraciones |
| Lenguajes de consulta | SQL y PromQL | PromQL, LogQL y TraceQL |
| Cruzar logs y métricas | Una consulta SQL | Varias consultas, a mano |
| Ingesta | remote_write, OTLP, Loki, InfluxDB, SQL | Un protocolo por servicio |
| Grafana | Fuente de datos Prometheus | Una fuente por servicio |
| Retención | Por base o por tabla, en SQL | Un ajuste por servicio |
Requisitos previos
Un VPS Ubuntu 24.04 con 2 GB de RAM basta para empezar; prevé 4 GB y más disco si centralizas muchos servicios, porque los logs y las trazas ocupan mucho más espacio que las métricas. Necesitas Docker con el plugin Compose y un nombre de dominio que apunte al VPS, con nginx y un certificado HTTPS: tus servidores le enviarán sus datos y Grafana la consultará.
Instalar GreptimeDB con Docker Compose
Preparar el directorio y la contraseña
Crea el directorio de la aplicación y un archivo
.envcon la contraseña del usuarioadmin.mkdir -p /opt/greptimedb && cd /opt/greptimedb echo "ADMIN_PASSWORD=$(openssl rand -hex 16)" > .env chmod 600 .envEscribir el docker-compose.yml
El puerto solo se publica en la interfaz local: solo nginx accede a él. La opción
--user-providerdeclara el usuarioadminy protege toda la API HTTP. La variableGREPTIMEDB_STANDALONE__ENABLE_TELEMETRYdesactiva el informe de uso anónimo enviado al editor.services: greptimedb: image: greptime/greptimedb:v1.3.0 restart: unless-stopped ports: - "127.0.0.1:4000:4000" environment: GREPTIMEDB_STANDALONE__ENABLE_TELEMETRY: "false" command: - standalone - start - --http-addr=0.0.0.0:4000 - --data-home=/greptimedb_data - --user-provider=static_user_provider:cmd:admin=${ADMIN_PASSWORD} volumes: - greptimedb-data:/greptimedb_data volumes: greptimedb-data: {}Arrancar y comprobar
El arranque tarda unos segundos.
/healthresponde sin autenticación; la API SQL devuelve 401 sin credenciales.docker compose up -d curl -fsS http://127.0.0.1:4000/health curl -u admin:TU_CONTRASENA http://127.0.0.1:4000/v1/sql -d 'sql=SHOW TABLES'Publicar en HTTPS con nginx
En el vhost de tu dominio (certificado obtenido con certbot), redirige hacia el puerto local. Aumenta
client_max_body_size: los lotesremote_writey OTLP superan pronto el límite por defecto.location / { proxy_pass http://127.0.0.1:4000; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; client_max_body_size 32m; }
Sin --user-provider, la base queda abierta a todos
Sin proveedor de usuarios, GreptimeDB acepta cualquier petición: quien conozca la dirección puede leer tus logs y escribir, modificar o borrar tablas en SQL. Mantén la autenticación activa y nunca publiques el puerto 4000 directamente en la IP pública: pasa siempre por el proxy inverso HTTPS. Los puertos gRPC, MySQL y PostgreSQL de GreptimeDB tampoco necesitan publicarse.
Enviar las métricas de Prometheus
En el prometheus.yml de cada servidor, añade un bloque remote_write hacia GreptimeDB. El parámetro db indica la base de destino; public existe desde el primer arranque.
remote_write:
- url: https://greptime.example.ma/v1/prometheus/write?db=public
basic_auth:
username: admin
password: TU_CONTRASENARecarga Prometheus: cada métrica se convierte en una tabla, visible con SHOW TABLES; en el panel.
Enviar logs y trazas por OpenTelemetry
En el OpenTelemetry Collector (o directamente en el SDK de tu aplicación), declara un exportador OTLP/HTTP hacia GreptimeDB. La cabecera Authorization lleva admin:contraseña codificado en Base64, y las trazas exigen además la cabecera X-Greptime-Pipeline-Name: greptime_trace_v1. Declara por tanto dos exportadores: puesta en los logs, esa cabecera hace que se rechacen.
exporters:
otlphttp/greptime:
endpoint: https://greptime.example.ma/v1/otlp
headers:
Authorization: "Basic BASE64_ADMIN_CONTRASENA"
otlphttp/greptime-traces:
endpoint: https://greptime.example.ma/v1/otlp
headers:
Authorization: "Basic BASE64_ADMIN_CONTRASENA"
X-Greptime-Pipeline-Name: greptime_trace_v1
service:
pipelines:
logs:
exporters: [otlphttp/greptime]
metrics:
exporters: [otlphttp/greptime]
traces:
exporters: [otlphttp/greptime-traces]Las métricas llegan a /v1/otlp/v1/metrics, los logs a /v1/otlp/v1/logs y las trazas a /v1/otlp/v1/traces: el colector añade estos sufijos por sí mismo. Si ya envías tus logs a Loki, Promtail y Grafana Alloy pueden apuntar a /v1/loki/api/v1/push.
Consultar GreptimeDB desde Grafana
En Grafana, añade una fuente de datos de tipo Prometheus con la URL https://tu-dominio/v1/prometheus, activa la autenticación básica e introduce el usuario admin y su contraseña. Tus paneles PromQL funcionan sin cambios.
Para logs y trazas, escribe tus consultas en SQL en el panel integrado (https://tu-dominio/dashboard/), donde las credenciales se introducen en los ajustes de conexión. Una consulta como SELECT * FROM opentelemetry_logs ORDER BY timestamp DESC LIMIT 50; muestra los últimos logs recibidos.
Retención, disco y copias de seguridad
Por defecto, GreptimeDB no borra nada. La retención se fija en SQL, para una base entera o por tabla (opción ttl al crearla). El comando COPY DATABASE exporta una base en formato Parquet dentro del volumen de datos, en /greptimedb_data/copy/:
ALTER DATABASE public SET 'ttl'='90d';
COPY DATABASE public TO 'backup/' WITH (FORMAT='parquet');Copia después esa carpeta fuera del VPS, o respalda el volumen Docker greptimedb-data completo con el contenedor detenido. Vigila el espacio en disco: casi siempre es el tamaño de los logs lo que decide.
Actualizar GreptimeDB
Lee primero las notas de versión: una actualización mayor puede requerir un paso de migración. Cambia la etiqueta de la imagen en docker-compose.yml y después:
cd /opt/greptimedb
docker compose pull && docker compose up -d
docker compose logs --tail 20Los datos del volumen se conservan. Haz un COPY DATABASE justo antes de una actualización mayor: es tu punto de retorno.
Instalación en un clic desde el Marketplace de ServOrbit
El Marketplace de ServOrbit instala GreptimeDB en tu VPS sin línea de comandos: despliega el contenedor oficial, genera la contraseña del usuario admin, activa la autenticación en toda la API HTTP, desactiva el informe de uso anónimo y publica el panel en HTTPS en un subdominio de tu dominio o en el subdominio gratuito del VPS (greptimedb.{dns_slug}.servorbit-dns.com). La contraseña aparece en tu área de cliente; solo queda conectar Prometheus, OpenTelemetry y Grafana.
