Logs, métriques et alertes

Tout ce qui suit se trouve sur la page de l’application, dans les onglets Logs et Metrics, et dans l’API. Rien n’a besoin d’être installé dans votre application, sauf le SDK OpenTelemetry si vous voulez des traces.

Logs en direct

L’onglet Logs diffuse ce que vos conteneurs affichent, au moment où ils l’affichent. Vous pouvez filtrer par processus. railyard logs my-app --follow --process web fait la même chose depuis un terminal. Download enregistre la sortie récente.

Historique et conservation des logs (bêta)

Railyard stocke aussi chaque ligne, afin que la carte Log history puisse chercher dans le temps.

• Durée de conservation des logs : Team → Logs → Keep app logs for (days). La valeur par défaut est 7 jours.
• Plage de temps : dernière heure, 24 heures, 7 jours, 30 jours, ou entre deux dates et heures.
• Recherche : texte simple, ou /regex/ (/regex/i ignore la casse). Vous pouvez aussi filtrer par niveau minimum, par processus, et pour les logs d’accès par statut et par chemin.
• Pagination : 200 lignes à la fois, les plus récentes d’abord. Older results reprend où vous vous étiez arrêté.
• Download these lines enregistre la plage sous forme de fichier texte.

Recherches enregistrées et alertes de logs

Enregistrez une recherche, et alertez-vous optionnellement sur elle : N matching lines within M minutes. Les alertes vont aux règles de notification où log alerts est cochée, au plus une fois par fenêtre.

Drains de logs

Logs tab → Log drains envoie chaque ligne de log vers votre propre récepteur, soit une destination HTTPS qui accepte du JSON, soit un serveur syslog (syslog://logs.example.com:514). Les lignes de logs d’accès arrivent avec source: "router".

Logs d’accès

Chaque requête qui atteint votre application par le proxy de Railyard devient une ligne 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"

Les réponses 5xx sont journalisées au niveau erreur, donc les filtres d’erreur et les alertes de logs les voient. Les logs d’accès apparaissent dans les logs en direct, la recherche de logs, les téléchargements et les drains. Les propres sondes de disponibilité de Railyard sont exclues. Pour les désactiver, décochez Settings → Networking → Access logs → Collect access logs. Cela prend effet immédiatement, sans besoin de déploiement.

Métriques

L’onglet Metrics affiche les requêtes par minute, la latence p50/p95/p99, le taux d’erreur, la bande passante et les points de terminaison les plus lents.

Alertes de métriques

Dans l’onglet Metrics, la carte Alerts permet aux deployers et aux rôles supérieurs d’ajouter des règles comme p95 response time above 800 ms for 5 minutes. Vous pouvez alerter sur :

• le temps de réponse p95, en ms;
• le taux d’erreur 5xx, en %;
• la mémoire, en % de la limite du conteneur;
• le CPU, en % (100 signifie un cœur).

Les règles sont vérifiées chaque minute. Une règle se déclenche une fois que la valeur est restée au-dessus du seuil pendant toute la durée, et une seule baisse sous le seuil remet le chronomètre à zéro. Quand elle se déclenche, un message va aux règles de notification où metric alerts est cochée, et une entrée s’ouvre dans l’historique de la carte avec l’heure de début, la durée et le pic. Quand la valeur redescend, un message back to normal est envoyé. Vous pouvez mettre en pause et reprendre les règles.

Files de jobs en arrière-plan (bêta)

Pour les applications qui font tourner Sidekiq, Solid Queue, GoodJob, Resque ou Delayed Job, l’onglet Metrics affiche une carte Background jobs. Railyard la lit depuis le Redis ou le Postgres de votre propre application chaque minute. Elle affiche :

• la profondeur de la file et le job en attente le plus ancien;
• combien de jobs sont occupés, traités et échoués;
• les 50 échecs les plus récents, chacun avec Retry et Discard;
• un graphique sur 24 heures.

Quand la file reste engorgée, les règles où job backlog est cochée reçoivent un message, et un autre quand elle est rattrapée.

Elle ne peut pas lire un Redis hors de Railyard, Solid Queue sur MySQL, ni les espaces de noms Sidekiq.

OpenTelemetry

Settings → General → OpenTelemetry. Entrez un point de terminaison OTLP, un protocole (http/protobuf, http/json ou grpc) et des en-têtes facultatifs comme x-honeycomb-team=YOUR_KEY. Les en-têtes sont stockés chiffrés. Au prochain déploiement, Railyard définit les variables que tout SDK OpenTelemetry lit :

• OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_PROTOCOL et OTEL_EXPORTER_OTLP_HEADERS;
• OTEL_SERVICE_NAME, qui est le nom de l’application;
• OTEL_RESOURCE_ATTRIBUTES, qui porte le SHA du commit, l’environnement, l’application et l’équipe.

Une variable que vous définissez vous-même gagne toujours.

Cochez also send Railyard’s CPU, memory and request metrics pour les envoyer à <endpoint>/v1/metrics chaque minute. Cet export utilise toujours OTLP par HTTP (port 4318 sur la plupart des collecteurs).

Pour instrumenter l’application, ajoutez le SDK neutre indépendant du fournisseur et laissez-le lire ces variables. Pour Rails, ce sont opentelemetry-sdk, opentelemetry-exporter-otlp et opentelemetry-instrumentation-all avec c.use_all, sur le protocole http/protobuf. Pour Node, c’est @opentelemetry/auto-instrumentations-node/register, et pour Python, c’est opentelemetry-instrument.

API

Méthode	Chemin	But
GET	/api/applications/:id/logs	Logs récents des conteneurs
GET	/api/applications/:id/log_search	Lignes stockées : q, level, process, status, path, range ou from/to
GET	/api/applications/:id/log_download	Les mêmes filtres, en texte
GET / PATCH / DELETE	/api/applications/:id/otel_export	Réglages OpenTelemetry
GET / POST	/api/applications/:id/metric_alerts	Règles d’alerte et leur historique
GET	/api/applications/:id/job_queue	Statistiques de file et jobs échoués, avec retry et discard