Logs, métricas e alertas

Tudo aqui está na página do app, nas abas Logs e Metrics, e na API. Nada precisa ser instalado no seu app, exceto o SDK do OpenTelemetry se você quiser traces.

Logs em tempo real

A aba Logs transmite o que seus containers imprimem, no momento em que imprimem. Você pode filtrar por processo. railyard logs my-app --follow --process web faz a mesma coisa a partir de um terminal. Download salva a saída recente.

Histórico e retenção de logs (beta)

O Railyard também guarda cada linha, então o card Log history pode buscar no tempo.

• Por quanto tempo os logs ficam guardados: Team → Logs → Keep app logs for (days). O padrão é 7 dias.
• Período: última hora, 24 horas, 7 dias, 30 dias, ou entre duas datas e horários.
• Busca: texto simples, ou /regex/ (/regex/i ignora maiúsculas/minúsculas). Você também pode filtrar por nível mínimo, processo, e para logs de acesso, por status e path.
• Paginação: 200 linhas por vez, mais recentes primeiro. Older results continua de onde você parou.
• Download these lines salva o período como um arquivo de texto.

Buscas salvas e alertas de log

Salve uma busca e, se quiser, alerte sobre ela: N linhas correspondentes em M minutos. Alertas vão para as regras de notificação com log alerts marcado, no máximo uma vez por janela.

Log drains

Aba Logs → Log drains envia cada linha de log para o seu próprio destino, seja um endpoint HTTPS que recebe JSON ou um servidor syslog (syslog://logs.example.com:514). Linhas de log de acesso chegam com source: "router".

Logs de acesso

Toda requisição que chega ao seu app pelo proxy do Railyard se torna uma linha 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"

Respostas 5xx são registradas em nível de erro, então filtros de erro e alertas de log as capturam. Logs de acesso aparecem nos logs em tempo real, na busca de logs, nos downloads e nos drains. As próprias sondas de uptime do Railyard ficam de fora. Para desativá-los, desmarque Settings → Networking → Access logs → Collect access logs. Isso vale imediatamente, sem precisar de deploy.

Métricas

A aba Metrics mostra requisições por minuto, latência p50/p95/p99, taxa de erro, consumo de banda e os endpoints mais lentos.

Alertas de métrica

Na aba Metrics, o card Alerts permite que deployers e acima adicionem regras como tempo de resposta p95 acima de 800 ms por 5 minutos. Você pode alertar sobre:

• tempo de resposta p95, em ms;
• taxa de erro 5xx, em %;
• memória, como % do limite do container;
• CPU, em % (100 significa um núcleo).

As regras são verificadas a cada minuto. Uma regra dispara quando o valor ficou acima do limite durante toda a duração definida, e qualquer queda abaixo reinicia a contagem. Quando dispara, uma mensagem vai para as regras de notificação com metric alerts marcado, e uma entrada abre no histórico do card com o horário de início, quanto tempo durou e o pico. Quando o valor volta ao normal, uma mensagem de back to normal é enviada. Você pode pausar e retomar regras.

Filas de jobs em segundo plano (beta)

Para apps rodando Sidekiq, Solid Queue, GoodJob, Resque ou Delayed Job, a aba Metrics mostra um card Background jobs. O Railyard lê isso do próprio Redis ou Postgres do seu app a cada minuto. Ele mostra:

• a profundidade da fila e o job mais antigo esperando;
• quantos jobs estão em execução, processados e com falha;
• as 50 falhas mais recentes, cada uma com Retry e Discard;
• um gráfico de 24 horas.

Quando a fila fica congestionada por muito tempo, regras com job backlog marcado recebem uma mensagem, e outra quando ela se recupera.

Ele não consegue ler um Redis fora do Railyard, Solid Queue em MySQL, ou namespaces do Sidekiq.

OpenTelemetry

Settings → General → OpenTelemetry. Informe um endpoint OTLP, um protocolo (http/protobuf, http/json ou grpc) e headers opcionais como x-honeycomb-team=YOUR_KEY. Os headers são armazenados criptografados. No próximo deploy, o Railyard define as variáveis que todo SDK do OpenTelemetry lê:

• OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_PROTOCOL e OTEL_EXPORTER_OTLP_HEADERS;
• OTEL_SERVICE_NAME, que é o nome do app;
• OTEL_RESOURCE_ATTRIBUTES, que carrega o commit SHA, o ambiente, o app e a equipe.

Uma variável que você define você mesmo sempre vence.

Marque also send Railyard’s CPU, memory and request metrics para enviar essas métricas para <endpoint>/v1/metrics a cada minuto. Essa exportação sempre usa OTLP sobre HTTP (porta 4318 na maioria dos coletores).

Para instrumentar o app, adicione o SDK neutro de fornecedor e deixe ele ler essas variáveis. Para Rails isso é opentelemetry-sdk, opentelemetry-exporter-otlp e opentelemetry-instrumentation-all com c.use_all, no protocolo http/protobuf. Para Node é @opentelemetry/auto-instrumentations-node/register, e para Python é opentelemetry-instrument.

API

Método	Caminho	Finalidade
GET	/api/applications/:id/logs	Logs recentes do container
GET	/api/applications/:id/log_search	Linhas armazenadas: q, level, process, status, path, range ou from/to
GET	/api/applications/:id/log_download	Os mesmos filtros, como texto
GET / PATCH / DELETE	/api/applications/:id/otel_export	Configurações do OpenTelemetry
GET / POST	/api/applications/:id/metric_alerts	Regras de alerta e seu histórico
GET	/api/applications/:id/job_queue	Estatísticas da fila e jobs com falha, com retry e discard