Logs, métricas y alertas

Todo esto está en la página de la app, en las pestañas Logs y Metrics, y en la API. No necesitas instalar nada en tu app, salvo el SDK de OpenTelemetry si quieres traces.

Logs en vivo

La pestaña Logs transmite lo que imprimen tus contenedores, en el momento en que lo imprimen. Puedes filtrar por proceso. railyard logs my-app --follow --process web hace lo mismo desde una terminal. Download guarda la salida reciente.

Historial y retención de logs (beta)

Railyard también guarda cada línea, así que la tarjeta Log history puede buscar hacia atrás en el tiempo.

• Cuánto se guardan los logs: Team → Logs → Keep app logs for (days). El valor por defecto es 7 días.
• Rango de tiempo: última hora, 24 horas, 7 días, 30 días, o entre dos fechas y horas.
• Búsqueda: texto plano, o /regex/ (/regex/i ignora mayúsculas/minúsculas). También puedes filtrar por nivel mínimo, proceso, y para access logs por status y ruta.
• Paginación: 200 líneas a la vez, las más nuevas primero. Older results continúa desde donde te quedaste.
• Download these lines guarda el rango como un archivo de texto.

Búsquedas guardadas y alertas de log

Guarda una búsqueda, y opcionalmente genera una alerta sobre ella: N líneas coincidentes en M minutos. Las alertas van a las reglas de notificación que tengan marcado log alerts, como máximo una vez por ventana.

Log drains

Logs tab → Log drains envía cada línea de log a tu propio sink, ya sea un endpoint HTTPS que acepte JSON o un servidor syslog (syslog://logs.example.com:514). Las líneas de access log llegan con source: "router".

Access logs

Cada solicitud que llega a tu app a través del proxy de Railyard se convierte en una línea router:

at=info method=GET path="/cart?id=7" host=shop.example.com status=200 duration=12.3ms bytes=532 fwd="203.0.113.9" user_agent="curl/8.4.0"

Las respuestas 5xx se registran en nivel de error, así que los filtros de error y las alertas de log las ven. Los access logs aparecen en logs en vivo, búsqueda de logs, descargas y drains. Las propias sondas de disponibilidad de Railyard quedan fuera. Para desactivarlos, desmarca Settings → Networking → Access logs → Collect access logs. Eso surte efecto de inmediato, sin necesidad de un despliegue.

Metrics

La pestaña Metrics muestra solicitudes por minuto, latencia p50/p95/p99, tasa de error, ancho de banda y los endpoints más lentos.

Alertas de métrica

En la pestaña Metrics, la tarjeta Alerts permite que deployers y roles superiores agreguen reglas como tiempo de respuesta p95 por encima de 800 ms durante 5 minutos. Puedes alertar sobre:

• tiempo de respuesta p95, en ms;
• tasa de error 5xx, en %;
• memoria, como % del límite del contenedor;
• CPU, en % (100 significa un core).

Las reglas se revisan cada minuto. Una regla se dispara una vez que el valor se mantuvo por encima del umbral durante toda la duración, y una sola caída por debajo reinicia el reloj. Cuando se dispara, se envía un mensaje a las reglas de notificación con metric alerts marcado, y se abre una entrada en el History de la tarjeta con la hora de inicio, cuánto duró y el pico. Cuando el valor vuelve a bajar, se envía un mensaje de back to normal. Puedes pausar y reanudar reglas.

Colas de trabajos en segundo plano (beta)

Para apps que corren Sidekiq, Solid Queue, GoodJob, Resque o Delayed Job, la pestaña Metrics muestra una tarjeta Background jobs. Railyard la lee desde el propio Redis o Postgres de tu app cada minuto. Muestra:

• la profundidad de la cola y el trabajo en espera más antiguo;
• cuántos trabajos están ocupados, procesados y fallidos;
• los 50 fallos más recientes, cada uno con Retry y Discard;
• un gráfico de 24 horas.

Cuando la cola se mantiene atrasada, las reglas con job backlog marcado reciben un mensaje, y otro cuando se pone al día.

No puede leer un Redis fuera de Railyard, Solid Queue sobre MySQL, ni namespaces de Sidekiq.

OpenTelemetry

Settings → General → OpenTelemetry. Ingresa un endpoint OTLP, un protocolo (http/protobuf, http/json o grpc) y encabezados opcionales como x-honeycomb-team=YOUR_KEY. Los encabezados se guardan cifrados. En el siguiente despliegue, Railyard define las variables que lee todo SDK de OpenTelemetry:

• OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_PROTOCOL y OTEL_EXPORTER_OTLP_HEADERS;
• OTEL_SERVICE_NAME, que es el nombre de la app;
• OTEL_RESOURCE_ATTRIBUTES, que lleva el SHA del commit, el entorno, la app y el equipo.

Una variable que definas tú mismo siempre gana.

Marca also send Railyard’s CPU, memory and request metrics para enviarlas a <endpoint>/v1/metrics cada minuto. Esa exportación siempre usa OTLP sobre HTTP (puerto 4318 en la mayoría de los collectors).

Para instrumentar la app, agrega el SDK neutral de proveedor y deja que lea esas variables. Para Rails eso es opentelemetry-sdk, opentelemetry-exporter-otlp y opentelemetry-instrumentation-all con c.use_all, en el protocolo http/protobuf. Para Node es @opentelemetry/auto-instrumentations-node/register, y para Python es opentelemetry-instrument.

API

Método	Ruta	Propósito
GET	/api/applications/:id/logs	Logs recientes del contenedor
GET	/api/applications/:id/log_search	Líneas almacenadas: q, level, process, status, path, range o from/to
GET	/api/applications/:id/log_download	Los mismos filtros, como texto
GET / PATCH / DELETE	/api/applications/:id/otel_export	Configuración de OpenTelemetry
GET / POST	/api/applications/:id/metric_alerts	Reglas de alerta y su historial
GET	/api/applications/:id/job_queue	Estadísticas de la cola y trabajos fallidos, con retry y discard