Instrumenter une application Ruby on Rails sur Heroku avec Datadog
Heroku est une plate-forme populaire utilisée par des développeurs Ruby, et notamment des développeurs Ruby on Rails. Datadog prend en charge Heroku et Ruby. Ainsi, vous pouvez envoyer les métriques, logs et traces de vos applications Ruby Heroku à Datadog.
Ce guide vous présente les étapes à suivre pour envoyer des métriques, données d’intégration, logs et traces à Datadog à partir d’une application Rails déployée sur Heroku.
Prérequis
Ce guide part des hypothèses suivantes :
Création de votre application Heroku et déploiement de l’exemple d’application Ruby
Ce guide se base sur l’exemple d’application Rails de Heroku. Il s’agit d’une application Rails barebone utilisée dans l’article de présentation de Ruby (en anglais) permettant de prendre en main le déploiement d’une application Ruby sur Heroku. Nous nous focaliserons ici sur l’instrumentation d’une application Rails avec Datadog.
L’exemple d’application possède une dépendance pg, qui se résout uniquement si vous avez installé Postgres en local. Veillez donc à effectuer cette installation avant de poursuivre.
Vous pouvez vérifier si l’installation de Postgres a bien fonctionné en exécutant la commande psql. Celle-ci devrait afficher une sortie similaire à ce qui suit :
which psql
/usr/local/bin/psql
Récupérez le code de l’exemple d’application, puis déployez-le tel quel dans une nouvelle application Heroku.
# Choisir un nom pour votre application et exportez-le en tant que variable d'environnement.
# Ici, l'application s'appelle ruby-heroku-datadog.
export APPNAME=ruby-heroku-datadog
# Récupérer le code de l'exemple d'application
git clone https://github.com/heroku/ruby-getting-started.git
cd ruby-getting-started
# Se connecter à Heroku
heroku login
# Créer une application
heroku create -a $APPNAME
# La déployer sur Heroku
git push heroku main
# Ouvrir l'application pour vérifier qu'elle fonctionne
heroku open -a $APPNAME
Votre navigateur par défaut s’ouvre alors avec l’exemple d’application. Une interface similaire à la suivante devrait s’afficher :
Connexion de votre compte Datadog à votre application et déploiement de l’Agent Datadog
Pour obtenir une visibilité intégrale sur votre application Heroku avec Datadog, il convient tout d’abord de déployer l’Agent Datadog et de le connecter à votre compte Datadog.
Pour identifier votre compte, Datadog utilise une clé d’API. Connectez-vous à votre compte Datadog et accédez à la section réservée aux clés d’API. Copiez votre clé d’API :
Déployez ensuite l’Agent Datadog sur votre application. Ce guide tire profit du buildpack Heroku Datadog. Pour en savoir plus sur les buildpacks Heroku et sur leur utilité, référez-vous à la documentation Heroku officielle.
# Enable Heroku Labs Dyno Metadata to set HEROKU_APP_NAME env variable automatically
heroku labs:enable runtime-dyno-metadata -a $APPNAME
# Set hostname in Datadog as appname.dynotype.dynonumber for metrics continuity
heroku config:add DD_DYNO_HOST=true
# Set your Datadog site (for example, us5.datadoghq.com)
heroku config:add DD_SITE=$DD_SITE
# Add this buildpack and set your Datadog API key
heroku buildpacks:add --index 1 https://github.com/DataDog/heroku-buildpack-datadog.git
heroku config:add DD_API_KEY=$DD_API_KEY
# Deploy to Heroku forcing a rebuild
git commit --allow-empty -m "Rebuild slug"
git push heroku main
Une fois l’opération de build terminée, l’Agent Datadog s’exécute dans votre application. Exécutez la commande de statut de l’Agent Datadog, tel qu’expliqué dans l’annexe, pour vérifier que tout fonctionne correctement. Passez en revue la section suivante :
[...]
API Keys status
===============
API key ending with 68306: API Key valid
[...]
Cette sortie indique que l’Agent Datadog s’exécute dans votre application Heroku, et qu’il est bien associé à votre compte Datadog.
Si vous ouvrez la hostmap dans Datadog, vous pouvez voir que votre dyno envoie correctement des données à Datadog :
Configuration des intégrations
Datadog est fourni avec plus de 400 intégrations prêtes à l’emploi qui recueillent des métriques à partir de différentes piles techniques. Le buildpack Datadog vous permet d’activer ces intégrations pour votre application Heroku.
Vous trouverez ci-dessous quatre configurations de l’intégration Heroku couramment utilisées.
Postgres
Heroku ajoute une base de données Postgres via une extension pour chaque application Rails déployée sur Heroku. Vérifiez que l’extension Postgres de l’application est activée :
heroku addons -a $APPNAME
Vous devriez obtenir la sortie suivante :
Add-on Plan Price State
───────────────────────────────────────────── ───────── ───── ───────
heroku-postgresql (postgresql-infinite-14462) hobby-dev free created
└─ as DATABASE
Le tableau ci-dessus indique les extensions et pièces jointes associées à l'application active (ruby-heroku-datadog) ou à d'autres apps.
L’exemple d’application utilise déjà cette base de données dans son code. Toutefois, vous n’avez pas encore créé de table. Exécutez ce qui suit :
heroku run rake db:migrate -a $APPNAME
Running `rake db:migrate` attached to terminal... up, run.3559
Migrating to CreateWidgets (20140707111715)
== 20140707111715 CreateWidgets: migrating ====================================
-- create_table(:widgets)
-> 0.0244s
== 20140707111715 CreateWidgets: migrated (0.0247s) ===========================
Vous pouvez alors visualiser l’endpoint /widgets de votre application qui utilise cette base de données.
Pour activer l’intégration Postgres Datadog, récupérer les identifiants de la base de données depuis Heroku. Exécuter la commande suivante depuis le terminal psql
heroku pg:credentials:url DATABASE -a $APPNAME
Lorsque vous utilisez le buildpack Datadog, les intégrations doivent être activées via une approche particulière. Pour découvrir comment activer toutes les intégrations, consultez la documentation relative au buildpack.
Créez un dossier datadog/conf.d à la racine de votre application :
cd ruby-getting-started
# Create the folder for the integrations configuration in your application code
mkdir -p datadog/conf.d/
Créez un fichier de configuration postgres.yaml en remplaçant votre host, nom de base de données, nom d’utilisateur et mot de passe par les informations obtenues avec la commande précédente :
init_config:
instances:
- host: <YOUR HOSTNAME>
port: <YOUR PORT>
username: <YOUR USERNAME>
password: <YOUR PASSWORD>
dbname: <YOUR DBNAME>
ssl: True
Au lieu de mettre à jour manuellement votre configuration, vous pouvez faire appel aux variables d’environnement Heroku pour configurer votre intégration Postgres et utiliser le script de pré-exécution pour remplacer ces valeurs avant le lancement de l’Agent Datadog :
#!/usr/bin/env bash
# Update the Postgres configuration from above using the Heroku application environment variable
if [ -n "$DATABASE_URL" ]; then
POSTGREGEX='^postgres://([^:]+):([^@]+)@([^:]+):([^/]+)/(.*)$'
if [[ $DATABASE_URL =~ $POSTGREGEX ]]; then
sed -i "s/<YOUR HOSTNAME>/${BASH_REMATCH[3]}/" "$DD_CONF_DIR/conf.d/postgres.d/conf.yaml"
sed -i "s/<YOUR USERNAME>/${BASH_REMATCH[1]}/" "$DD_CONF_DIR/conf.d/postgres.d/conf.yaml"
sed -i "s/<YOUR PASSWORD>/${BASH_REMATCH[2]}/" "$DD_CONF_DIR/conf.d/postgres.d/conf.yaml"
sed -i "s/<YOUR PORT>/${BASH_REMATCH[4]}/" "$DD_CONF_DIR/conf.d/postgres.d/conf.yaml"
sed -i "s/<YOUR DBNAME>/${BASH_REMATCH[5]}/" "$DD_CONF_DIR/conf.d/postgres.d/conf.yaml"
fi
fi
Effectuez le déploiement sur Heroku :
git add .
git commit -m "Enable postgres integration"
git push heroku main
Une fois l’opération de build terminée, l’Agent Datadog lance le check Postgres. Exécutez la commande de statut de l’Agent Datadog, tel qu’expliqué dans l’annexe, pour vérifier que le check Postgres fonctionne correctement. Passez en revue la section suivante :
[...]
=========
Collector
=========
Running Checks
==============
[...]
postgres (5.4.0)
----------------
Instance ID: postgres:e07ef94b907fe733 [OK]
Configuration Source: file:/app/.apt/etc/datadog-agent/conf.d/postgres.d/conf.yaml
Total Runs: 9
Metric Samples: Last Run: 15, Total: 135
Events: Last Run: 0, Total: 0
Service Checks: Last Run: 1, Total: 9
Average Execution Time : 102ms
Last Execution Date : 2021-05-11 14:14:34 UTC (1620742474000)
Last Successful Execution Date : 2021-05-11 14:14:34 UTC (1620742474000)
metadata:
version.major: 13
version.minor: 2
version.patch: 0
version.raw: 13.2 (Ubuntu 13.2-1.pgdg20.04+1)
version.scheme: semver
[...]
Après avoir vérifié que le check Postgres fonctionne correctement, vous pouvez commencer à visualiser les métriques Postgres disponibles sur la page Metrics Summary :
Redis
Si vous utilisez Redis, ajoutez l’extension Redis d’Heroku à votre application Heroku :
heroku addons:create heroku-redis:hobby-dev
Pour vérifier que Redis a bien été associé à votre application, exécutez la commande suivante :
Le texte renvoyé devrait ressembler à ceci :
=== redis-cylindrical-59589
Attachments: ruby-heroku-datadog::REDIS
Installed at: Wed Nov 17 2021 14:14:13 GMT+0100 (Central European Standard Time)
Owning app: ruby-heroku-datadog
Plan: heroku-redis:hobby-dev
Price: free
State: created
Récupérez les identifiants depuis Heroku en exécutant la commande suivante :
heroku config -a $APPNAME | grep REDIS_URL
Créez un fichier de configuration intitulé /datadog/conf.d/redisdb.yaml à la racine de votre application pour remplacer votre host, votre port et votre mot de passe par ceux récupérés avec la commande précédente :
init_config:
instances:
- host: <YOUR_REDIS_HOST>
password: <YOUR_REDIS_PASSWORD>
port: <YOUR_REDIS_PORT>
Au lieu de mettre à jour manuellement votre configuration, vous pouvez faire appel aux variables d’environnement Heroku pour configurer votre intégration Redis et utiliser le script de pré-exécution pour remplacer ces valeurs avant le lancement de l’Agent Datadog :
#!/usr/bin/env bash
# Update the Redis configuration from above using the Heroku application environment variable
if [ -n "$REDIS_URL" ]; then
REDISREGEX='rediss?://([^:]*):([^@]+)@([^:]+):([^/]+)$'
if [[ $REDIS_URL =~ $REDISREGEX ]]; then
sed -i "s/<YOUR_REDIS_HOST>/${BASH_REMATCH[3]}/" "$DD_CONF_DIR/conf.d/redisdb.d/conf.yaml"
sed -i "s/<YOUR_REDIS_PASSWORD>/${BASH_REMATCH[2]}/" "$DD_CONF_DIR/conf.d/redisdb.d/conf.yaml"
sed -i "s/<YOUR_REDIS_PORT>/${BASH_REMATCH[4]}/" "$DD_CONF_DIR/conf.d/redisdb.d/conf.yaml"
fi
fi
Effectuez le déploiement sur Heroku :
# Déploiement sur Heroku
git add .
git commit -m "Enable redis integration"
git push heroku main
Une fois l’opération de build terminée, l’Agent Datadog lance le check Redis. Exécutez la commande de statut de l’Agent Datadog pour vérifier que le check Redis fonctionne correctement.
Le texte suivant s’affiche :
[...]
=========
Collector
=========
Running Checks
==============
[...]
redisdb (4.1.0)
---------------
Instance ID: redisdb:eb3a3807075f89f0 [OK]
Configuration Source: file:/app/.apt/etc/datadog-agent/conf.d/redisdb.d/conf.yaml
Total Runs: 3
Metric Samples: Last Run: 45, Total: 135
Events: Last Run: 0, Total: 0
Service Checks: Last Run: 1, Total: 3
Average Execution Time : 6ms
Last Execution Date : 2021-11-17 13:56:17 UTC (1637157377000)
Last Successful Execution Date : 2021-11-17 13:56:17 UTC (1637157377000)
metadata:
version.major: 6
version.minor: 2
version.patch: 3
version.raw: 6.2.3
version.scheme: semver
[...]
Sidekiq
Sidekiq est un framework de traitement en arrière-plan pour Ruby. Si vous utilisez Sidekiq Pro ou Enterprise, vous pouvez installer l’intégration Datadog pour Sidekiq.
Installez le package dogstatsd-ruby :
gem install dogstatsd-ruby
Activez la collecte de métriques Sidekiq Pro dans votre initialiseur :
require 'datadog/statsd' # gem 'dogstatsd-ruby'
Sidekiq::Pro.dogstatsd = ->{ Datadog::Statsd.new('localhost', 8125, namespace:'sidekiq') }
Sidekiq.configure_server do |config|
config.server_middleware do |chain|
require 'sidekiq/middleware/server/statsd'
chain.add Sidekiq::Middleware::Server::Statsd
end
end
Si vous utilisez Sidekiq Enterprise et que vous souhaitez recueillir des métriques historiques, ajoutez le bloc suivant :
Sidekiq.configure_server do |config|
# Les métriques historiques sont recueillies toutes les 30 secondes par défaut
config.retain_history(30)
end
Ajoutez le bloc suivant à votre script datadog/prerun.sh :
cat << 'EOF' >> "$DATADOG_CONF"
dogstatsd_mapper_profiles:
- name: sidekiq
prefix: "sidekiq."
mappings:
- match: 'sidekiq\.sidekiq\.(.*)'
match_type: "regex"
name: "sidekiq.$1"
- match: 'sidekiq\.jobs\.(.*)\.perform'
name: "sidekiq.jobs.perform"
match_type: "regex"
tags:
worker: "$1"
- match: 'sidekiq\.jobs\.(.*)\.(count|success|failure)'
name: "sidekiq.jobs.worker.$2"
match_type: "regex"
tags:
worker: "$1"
EOF
Effectuez le déploiement sur Heroku :
git add .
git commit -m "Enable sidekiq integration"
git push heroku main
Une fois l’opération de build terminée, l’Agent Datadog lance le check Sidekiq. Exécutez la commande de statut de l’Agent Datadog pour vérifier que le check Sidekiq fonctionne correctement.
Memcached
Memcached est un système de gestion de la mémoire cache distribuée qui est couramment utilisé dans les applications Rails. L’exemple qui suit montre comment ajouter l’extension Memcached Cloud d’Heroku à votre application Heroku :
heroku addons:create memcachedcloud:30
Pour vérifier que Memcached a bien été associé à votre application, exécutez la commande suivante :
heroku addons | grep -A2 memcachedcloud
Le texte suivant s’affiche :
memcachedcloud (memcachedcloud-fluffy-34783) 30 free created
└─ as MEMCACHEDCLOUD
Récupérez les identifiants depuis Heroku en exécutant la commande suivante :
heroku config | grep MEMCACHEDCLOUD
Créez un fichier de configuration intitulé /datadog/conf.d/mcache.yaml à la racine de votre application pour remplacer votre host, votre port, votre nom d’utilisateur et votre mot de passe par ceux récupérés avec la commande précédente :
instances:
- url: <YOUR_MCACHE_HOST>
port: <YOUR_MCACHE_PORT>
username: <YOUR_MCACHE_USERNAME>
password: <YOUR_MCACHE_PASSWORD>
Au lieu de mettre à jour manuellement votre configuration, vous pouvez faire appel aux variables d’environnement Heroku pour configurer votre intégration Memcached et utiliser le script de pré-exécution pour remplacer ces valeurs avant le lancement de l’Agent Datadog :
#!/usr/bin/env bash
# Update the Memcached configuration from above using the Heroku application environment variable
if [ -n "$MEMCACHEDCLOUD_SERVERS" ]; then
MCACHEREGEX='([^:]+):([^/]+)$'
if [[ $MEMCACHEDCLOUD_SERVERS =~ $MCACHEREGEX ]]; then
sed -i "s/<YOUR_MCACHE_HOST>/${BASH_REMATCH[1]}/" "$DD_CONF_DIR/conf.d/mcache.d/conf.yaml"
sed -i "s/<YOUR_MCACHE_PORT>/${BASH_REMATCH[2]}/" "$DD_CONF_DIR/conf.d/mcache.d/conf.yaml"
fi
sed -i "s/<YOUR_MCACHE_USERNAME>/${MEMCACHEDCLOUD_USERNAME}/" "$DD_CONF_DIR/conf.d/mcache.d/conf.yaml"
sed -i "s/<YOUR_MCACHE_PASSWORD>/${MEMCACHEDCLOUD_PASSWORD}/" "$DD_CONF_DIR/conf.d/mcache.d/conf.yaml"
fi
Effectuez le déploiement sur Heroku :
git add .
git commit -m "Enable memcached integration"
git push heroku main
Une fois l’opération de build terminée, l’Agent Datadog lance le check Memcached. Exécutez la commande de statut de l’Agent Datadog pour vérifier que le check Memcached fonctionne correctement.
Le texte suivant s’affiche :
[...]
=========
Collector
=========
Running Checks
==============
[...]
mcache (2.0.0)
--------------
Instance ID: mcache:ca47ee7a0c236107 [OK]
Configuration Source: file:/app/.apt/etc/datadog-agent/conf.d/mcache.d/conf.yaml
Total Runs: 2
Metric Samples: Last Run: 27, Total: 54
Events: Last Run: 0, Total: 0
Service Checks: Last Run: 1, Total: 2
Average Execution Time : 9ms
Last Execution Date : 2021-11-18 12:28:45 UTC (1637238525000)
Last Successful Execution Date : 2021-11-18 12:28:45 UTC (1637238525000)
metadata:
version.major: 1
version.minor: 4
version.patch: 17
version.raw: 1.4.17
version.scheme: semver
[...]
Traces
Pour bénéficier d’un tracing distribué depuis votre application Ruby Heroku, activez l’instrumentation.
Assurez-vous d’être dans le dossier contenant le code de l’application :
Modifiez votre Gemfile et ajoutez la ddtrace :
source 'https://rubygems.org'
gem 'ddtrace', require: 'ddtrace/auto_instrument'
Installez le gem avec bundle install :
Avant de valider les modifications et de les envoyer à Heroku, configurez le tagging unifié pour l’application :
# Définir l'environment de votre application
heroku config:add DD_ENV=production -a $APPNAME
# Définir la version de votre application
heroku config:add DD_VERSION=0.1 -a $APPNAME
# Définir le service de votre application
heroku config:add DD_SERVICE=$APPNAME -a $APPNAME
Validez vos modifications et envoyez-les à Heroku :
git add .
git commit -m "Enable distributed tracing"
git push heroku main
Lors du build, des messages d’erreur s’affichent à propos du traceur, car celui-ci ne parvient pas à atteindre l’endpoint de l’Agent APM Datadog. Il s’agit du comportement attendu. En effet, l’Agent Datadog ne se lance qu’après le processus de build. Vous pouvez ignorer ces messages :
remote: Download Yarn at https://yarnpkg.com/en/docs/install
remote: E, [2021-05-14T10:21:27.664244 #478] ERROR -- ddtrace: [ddtrace] (/tmp/build_d5cedb1c/vendor/bundle/ruby/2.6.0/gems/ddtrace-0.48.0/lib/ddtrace/transport/http/client.rb:35:in `rescue in send_request') Internal error during HTTP transport request. Cause: Failed to open TCP connection to 127.0.0.1:8126 (Connection refused - connect(2) for "127.0.0.1" port 8126) Location: /tmp/build_d5cedb1c/vendor/ruby-2.6.6/lib/ruby/2.6.0/net/http.rb:949:in `rescue in block in connect'
Une fois l’opération de build terminée, votre application envoie des traces à Datadog. Vous pouvez commencer à générer du trafic vers votre application (par exemple, en visitant la page /widgets de votre application) pour obtenir un certain volume de traces.
Exécutez la commande de statut de l’Agent Datadog, tel qu’expliqué dans l’annexe, pour vérifier que l’Agent APM s’exécute correctement et qu’il envoie des traces à Datadog. Passez en revue la section suivante :
[...]
=========
APM Agent
=========
Status: Running
Pid: 54
Uptime: 85 seconds
Mem alloc: 13,971,888 bytes
Hostname: ruby-heroku-datadog.web.1
Receiver: localhost:8126
Endpoints:
https://trace.agent.datadoghq.com
Receiver (previous minute)
==========================
From ruby 2.6.6 (ruby-x86_64-linux), client 0.48.0
Traces received: 43 (55,431 bytes)
Spans received: 129
Default priority sampling rate: 100.0%
Priority sampling rate for 'service:ruby-heroku-datadog,env:': 100.0%
Priority sampling rate for 'service:ruby-heroku-datadog,env:production': 100.0%
Writer (previous minute)
========================
Traces: 0 payloads, 0 traces, 0 events, 0 bytes
Stats: 0 payloads, 0 stats buckets, 0 bytes
[...]
Cette sortie indique que l’Agent APM s’exécute correctement et qu’il envoie des traces à Datadog.
Accédez à la section des traces de l’APM pour visualiser vos traces :
Accédez au Software Catalog pour voir tous vos services d’application et votre vue de service d’application :
Logs
Ensuite, activez les logs en configurant un drain de logs Heroku.
Lorsque vous utilisez un drain de logs, tous les logs arrivent dans Datadog à partir de la même ddsource (généralement heroku), pour qu’il n’y ait pas de parsing automatque des logs en utilisant les intégrations autres que Heroku.
Génération de vos logs Rails
Pour configurer vos logs Rails, Datadog recommande l’utilisation de Lograge. Pour un exemple d’application, configurez-la de façon à mettre en corrélation les logs et les traces.
Assurez-vous d’être dans le dossier contenant le code de l’application :
Modifiez votre Gemfile et ajoutez lograge :
Installez le gem avec bundle install :
Pour configurer Lograge, créez un fichier appelé config/initializers/lograge.rb et ajoutez ce qui suit :
Rails.application.configure do
# Configuration de Lograge
config.lograge.enabled = true
# Indique de se connecter au format JSON
config.lograge.formatter = Lograge::Formatters::Json.new
## Désactive la coloration du log
config.colorize_logging = false
# Journalisation dans STDOUT
config.lograge.logger = ActiveSupport::Logger.new(STDOUT)
config.lograge.custom_options = lambda do |event|
# Récupère les informations des traces pour le thread actuel
correlation = Datadog::Tracing.correlation
{
# Ajoute des ID sous forme de tags vers la sortie de log
:dd => {
# Pour préserver la précision pendant la sérialisation JSON, utilisez les chaînes pour les grands nombres
:trace_id => correlation.trace_id.to_s,
:span_id => correlation.span_id.to_s,
:env => correlation.env.to_s,
:service => correlation.service.to_s,
:version => correlation.version.to_s
},
:ddsource => ["ruby"],
:params => event.payload[:params].reject { |k| %w(controller action).include? k }
}
end
end
Effectuez le déploiement sur Heroku :
git add .
git commit -m "Add lograge"
git push heroku main
Configuration d’un drain de log Heroku
Heroku dispose d’un routeur de logs natif appelé log drain, qui collecte les logs de tous les dynos exécutés dans votre application et les envoie à Heroku. Les logs incluent les logs de votre application, les logs du routeur Heroku et les logs système des dynos Heroku. Vous pouvez configurer le log drain pour acheminer ces logs vers Datadog. Le log drain envoie les logs système Heroku à Datadog depuis ddsource=heroku.
La configuration du drain de logs Heroku permet également d’envoyer à Datadog des métriques système sur les dynos (CPU, mémoire).
Pour configurer le drain de logs Heroku depuis un terminal, exécutez ce qui suit :
export APPNAME=<YOUR_APPLICATION_NAME>
export DD_ENV=<YOUR_APPLICATION_ENVIRONMENT> # example: production, staging
export DD_SERVICE=<YOUR_SERVICE_NAME>
heroku drains:add "https://http-intake.logs.datadoghq.com/api/v2/logs?dd-api-key=$DD_API_KEY&ddsource=heroku&env=$DD_ENV&service=$DD_SERVICE&host=${APPNAME}.web.1" -a $APPNAME
Pour récupérer les métriques système depuis vos dynos, activez non seulement le drain de logs, mais également log-runtime-metrics :
heroku labs:enable log-runtime-metrics -a $APPNAME
# Redémarrer votre application
heroku restart -a $APPNAME
Une fois le drain configuré, vos logs Heroku s’affichent dans la section des logs de Datadog.
Génération des métriques depuis les logs de routeur Heroku
Tout le trafic passant par votre application génère un log de routeur Heroku :
Comme vous pouvez le voir, les logs de routeur Heroku sont automatiquement parsés. Avec le pipeline de logs d’intégration Heroku, appname, dyno etdynotype sont extraits en tant que tags :
Vous pouvez générer une métrique de latence reposant sur ces paramètres parsés.
Accédez à Logs -> Generate Metrics et cliquez sur le bouton « + New Metric » :
Définissez la requête Source:heroku pour filtrer tous les logs Heroku. Sélectionnez la mesure Duration. En outre, il paraît intéressant de pouvoir regrouper cette métrique en fonction de appname, dyno, dynotype et @http.status_code. Gardez à l’esprit que les métriques générées par le parsing des logs sont considérées comme des métriques custom. Nous vous recommandons de générer du trafic vers votre application pour obtenir un certain volume d’entrées de log.
Pour finir, ajoutez un nom à votre métrique et cliquez sur Create Metric :
Une fois la règle créée, patientez quelques minutes le temps de rassembler les nouvelles métriques. Cliquez ensuite sur See in Metric Explorer pour visualiser votre nouvelle métrique :
Génération de métriques Datadog depuis les logs de métrique Heroku
Si log-runtime-metrics est configuré pour votre application, Heroku génère des entrées de log avec des métriques système pour chacun des dynos :
Ces logs sont automatiquement parsés par le pipeline de logs d’intégration de Heroku, qui extrait les measures suivantes :
@heroku.cpu.1m
@heroku.cpu.5m
@heroku.cpu.15m
@heroku.memory.cache
@heroku.memory.quota
@heroku.memory.rss
@heroku.memory.swap
@heroku.memory.total
Consultez la documentation Heroku officielle (en anglais) pour en savoir plus sur chacune de ces valeurs.
Suivez les étapes détaillées dans la section précédente pour générer des métriques avec une rétention de 15 mois pour chaque mesure.
Corrélation des logs et des traces
Si vous suivez les instructions de configuration ci-dessus, les logs envoyés depuis le log drain Heroku sont corrélés aux traces.
Remarque : Le routeur Heroku et les logs système sont générés par Heroku, et leur corrélation avec les traces est impossible.
Vous pouvez vérifier que la configuration est une réussite en naviguant vers la Vue des logs pour voir que les logs de l’application Rails possèdent leur trace en corrélation :
Résumé
Durant ce guide, nous sommes partis d’un exemple d’application Rails, nous l’avons déployé sur Heroku, puis nous l’avons instrumenté avec Datadog pour configurer les métriques, métriques système des dynos, logs, traces et intégrations.
Pour continuer l’instrumentation de votre application avec d’autres intégrations Datadog, suivez les mêmes étapes que pour l’intégration Postgres. Les fichiers de configuration sont indiqués dans notre documentation sur les intégrations.
Annexe : obtenir le statut de l’Agent Datadog
En récupérant le statut de l’Agent Datadog, vous pouvez vérifier qu’il s’exécute correctement, et corriger d’éventuels problèmes. Commencez par SSH votre dyno avec la commande heroku ps:exec :
heroku ps:exec -a $APPNAME
# Establishing credentials... done
# Connecting to web.1 on ⬢ ruby-heroku-datadog...
# DD_API_KEY environment variable not set. Run: heroku config:add DD_API_KEY=<your API key>
#The Datadog Agent has been disabled. Unset the DISABLE_DATADOG_AGENT or set missing environment variables.
~ $
Vous pouvez ignorer les avertissements indiquant que DD_API_KEY n’est pas définie. C’est normal. La raison est qu’Heroku ne définit pas les variables de configuration pour la session SSH elle-même, mais le processus de l’Agent Datadog a pu accéder à ces variables.
Une fois la session SSH ouverte, exécutez la commande de statut Datadog :
~ $ agent-wrapper status
Getting the status from the agent.
===============
Agent (v7.27.0)
===============
Status date: 2021-04-30 10:49:50.692 UTC (1619779790692)
Agent start: 2021-04-30 10:32:54.713 UTC (1619778774713)
Pid: 52
Go Version: go1.14.12
Python Version: 3.8.5
Build arch: amd64
Agent flavor: agent
Check Runners: 4
Log File: /app/.apt/var/log/datadog/datadog.log
Log Level: info
[...]
Pour aller plus loin
Documentation, liens et articles supplémentaires utiles:
