Catégories

Dernière mise à jour le 17 septembre 2020

Les journaux d’une application Heroku sont agrégés à partir des flux de sortie de tous ses processus en cours d’exécution, composants système et services de soutien. Le Logplex de Heroku achemine les flux de journaux de toutes ces sources diverses vers un canal unique, fournissant une base pour une journalisation complète.

Types de journaux

Journaux d’exécution

Heroku agrège les catégories de journaux suivantes pour une app déployée :

  • Journaux d’application – Sortie de journaux de l’application elle-même. Cela inclut les journaux générés par le code et les dépendances de votre app. (Filter : --source app)
  • Journaux du système – Messages sur les actions prises par l’infrastructure de la plateforme Heroku pour le compte de votre app, par exemple : redémarrer un processus planté, endormir ou réveiller un web dyno, ou servir une page d’erreur en raison d’un problème dans votre app. (Filter : --source heroku)
  • Journaux API – Messages concernant les actions administratives prises par vous et d’autres développeurs travaillant sur votre app, telles que : le déploiement d’un nouveau code, la mise à l’échelle de la formation du processus ou le basculement du mode maintenance. (Filtre : --source app --dyno api)
  • Journaux des modules complémentaires – Messages provenant des services des modules complémentaires. Consultez l’article du Dev Center de l’add-on pour plus de détails. (Le filtre varie selon le module complémentaire)

Journaux de construction

Les journaux générés lors de la construction et du déploiement de votre application sont distincts des journaux d’exécution de l’application. Les journaux des constructions réussies et non réussies sont disponibles à partir de l’onglet Activityde votre app dans le tableau de bord Heroku :

Capture d'écran de

Cliquez sur View build log pour tout événement de construction dans le flux d’activité pour voir ses journaux :

Capture d'écran de

Les limites de l’historique des journaux

Logplex est conçu pour rassembler et acheminer les messages des journaux, et non pour les stocker. Il conserve les 1 500 lignes les plus récentes de vos journaux consolidés, qui expirent après 1 semaine.

Pour une persistance des journaux plus adaptée à la production, vous pouvez ajouter à votre application l’un des modules complémentaires de journalisation disponibles sur la plateforme Heroku. La plupart de ces add-ons offrent un plan gratuit pour commencer.

Alternativement, vous pouvez implémenter vos propres drains de logs pour un contrôle total de ce qui se passe dans vos logs.

Écrire dans votre log

Tout ce que votre app écrit dans standard out (stdout) ou standard error (stderr) est capturé dans vos logs. Cela signifie que vous pouvez journaliser à partir de n’importe où dans le code de votre application avec une simple déclaration de sortie.

En Ruby, vous pourriez utiliser quelque chose comme:

puts "Hello, logs!"

En Java:

System.err.println("Hello, logs!");System.out.println("Hello, logs!");

Il en va de même pour tous les autres langages pris en charge par Heroku.

Pour profiter de la journalisation en temps réel, vous devrez peut-être désactiver toute mise en mémoire tampon du journal que votre application effectue. Par exemple, en Ruby, ajoutez ceci à votre fichier config.ru:

$stdout.sync = true

Certains frameworks envoient la sortie du journal ailleurs que sur stdout par défaut. Ceux-ci peuvent nécessiter une configuration supplémentaire. Par exemple, lorsque vous utilisez le TaggedLogger de Ruby on Rails par ActiveSupport, vous devez ajouter ce qui suit dans la configuration de votre app pour obtenir une journalisation stdout :

config.logger = Logger.new(STDOUT)

Récupération des journaux via CLI

Voir les journaux

Pour récupérer les journaux les plus récents de votre app, utilisez la commande heroku logs:

$ heroku logs2010-09-16T15:13:46.677020+00:00 app: Processing PostController#list (for 208.39.138.12 at 2010-09-16 15:13:46) 2010-09-16T15:13:46.677023+00:00 app: Rendering template within layouts/application2010-09-16T15:13:46.677902+00:00 app: Rendering post/list2010-09-16T15:13:46.678990+00:00 app: Rendered includes/_header (0.1ms)2010-09-16T15:13:46.698234+00:00 app: Completed in 74ms (View: 31, DB: 40) | 200 OK 2010-09-16T15:13:46.723498+00:00 heroku: at=info method=GET path="/posts" host=myapp.herokuapp.com" fwd="204.204.204.204" dyno=web.1 connect=1ms service=18ms status=200 bytes=9752010-09-16T15:13:47.893472+00:00 app: 2 jobs processed at 16.6761 j/s, 0 failed ...

Dans cet exemple, la sortie comprend les lignes de journal d’un des dynos web de l’app, du routeur HTTP Heroku et d’un des workers de l’app.

La commande logs récupère 100 lignes de journal par défaut. Vous pouvez spécifier le nombre de lignes de journal à récupérer (jusqu’à un maximum de 1 500 lignes) en utilisant l’option --num (ou -n).

$ heroku logs -n 200

Real-time tail

Similaire à tail -f, la queue en temps réel affiche les journaux récents et laisse la session ouverte pour que les journaux en temps réel affluent. En visualisant un flux de journaux en direct de votre application, vous pouvez avoir un aperçu du comportement de votre application en direct et déboguer les problèmes actuels.

Vous pouvez tailer vos journaux en utilisant --tail (ou -t).

$ heroku logs --tail

Quand vous avez terminé, appuyez sur Ctrl+C pour revenir à l’invite.

Une session de queue en temps réel est automatiquement terminée après une heure d’inactivité.

Format du journal

Le format de sortie de la commande heroku logs est le suivant :

timestamp source: message
  • Horodatage – La date et l’heure enregistrées au moment où la ligne de journal a été produite par le banc ou le composant. L’horodatage est au format spécifié par RFC5424, et inclut une précision de l’ordre de la microseconde.
  • Source – Tous les dynos de votre app (dynos web, background workers, cron) ont la source, app. Tous les composants système de Heroku (routeur HTTP, gestionnaire de dynos) ont la source, heroku.
  • Dyno – Le nom du dyno ou du composant qui a écrit la ligne de journal. Par exemple, worker #3 apparaît comme worker.3, et le routeur HTTP Heroku apparaît comme router.
  • Message – Le contenu de la ligne de journal. Les lignes générées par les dynos qui dépassent 10000 octets sont divisées en chunks de 10000 octets sans nouvelles lignes de queue supplémentaires. Chaque fragment est soumis comme une ligne de journal séparée.

Filtrage

Si vous voulez seulement récupérer les journaux avec une certaine source, un certain dyno, ou les deux, vous pouvez utiliser les arguments de filtrage --source (ou -s) et --dyno (ou -d):

$ heroku logs --dyno router2012-02-07T09:43:06.123456+00:00 heroku: at=info method=GET path="/stylesheets/dev-center/library.css" host=devcenter.heroku.com fwd="204.204.204.204" dyno=web.5 connect=1ms service=18ms status=200 bytes=132012-02-07T09:43:06.123456+00:00 heroku: at=info method=GET path="/articles/bundler" host=devcenter.heroku.com fwd="204.204.204.204" dyno=web.6 connect=1ms service=18ms status=200 bytes=20375$ heroku logs --source app2012-02-07T09:45:47.123456+00:00 app: Rendered shared/_search.html.erb (1.0ms)2012-02-07T09:45:47.123456+00:00 app: Completed 200 OK in 83ms (Views: 48.7ms | ActiveRecord: 32.2ms)2012-02-07T09:45:47.123456+00:00 app: 1 jobs processed at 23.0330 j/s, 0 failed ...2012-02-07T09:46:01.123456+00:00 app: Started GET "/articles/buildpacks" for 4.1.81.209 at 2012-02-07 09:46:01 +0000$ heroku logs --source app --dyno worker2012-02-07T09:47:59.123456+00:00 app: Article#record_view_without_delay completed after 0.02212012-02-07T09:47:59.123456+00:00 app: 5 jobs processed at 31.6842 j/s, 0 failed ...

Lorsque vous filtrez par dyno, soit le nom de base (par ex, --dyno web) ou le nom complet (par ex, --dyno web.1) peuvent être utilisés.

Vous pouvez également combiner les commutateurs de filtrage avec --tail pour obtenir un flux en temps réel de sortie filtrée.

$ heroku logs --source app --tail

Organisation des messages de journal

Lorsque vous récupérez des journaux, vous pouvez remarquer qu’ils ne sont pas toujours dans un ordre chronologique exact, en particulier lorsque plusieurs composants sont impliqués. Les journaux proviennent de nombreuses sources (nœuds de routeur, dynos, etc.) et sont assemblés en un seul flux de journaux par Logplex. Logplex lui-même utilise une architecture distribuée pour assurer une haute disponibilité, ce qui signifie que les messages de journal pourraient être collectés sur plusieurs nœuds Logplex et donc être livrés dans le désordre.

Récupération des journaux via le tableau de bord web

Voir les journaux

Vous pouvez voir vos journaux sur le web en vous connectant à votre tableau de bord Heroku. Naviguez jusqu’à l’application que vous voulez voir par exemple https://dashboard.heroku.com/apps/<app-name>. Une fois sur cette page sélectionnez « plus » vous devriez voir un menu déroulant:

Dans ce menu sélectionnez « Voir les logs ».

Leave a Reply