Passer au contenu principal
Les marqueurs sont de petites icônes utilisées dans les graphiques sur AppSignal.com pour indiquer un changement. Cela peut être un déploiement de code à l’aide d’un « Marqueur de déploiement » ou un événement spécial avec un « Marqueur personnalisé ». Les marqueurs de déploiement peuvent également être trouvés dans la section « Deploys » dans la navigation de l’application qui fournit un aperçu des performances par déploiement. Un marqueur de déploiement indique un changement dans la version déployée d’une application. Il peut être utilisé pour regrouper les occurrences d’erreurs et de problèmes de performance dans une certaine période. Du moment où la version a été déployée jusqu’au déploiement d’une nouvelle version. Les marqueurs de déploiement sont également requis pour activer les liens de backtrace pour une application. Lorsqu’un nouveau déploiement est détecté, la liste des incidents est vide pour la version de déploiement la plus récente. Lorsqu’une erreur, ou tout autre problème, est signalée par AppSignal dans votre application, elle est également listée pour le déploiement le plus récent. Sur la page d’échantillon d’un incident, vous pouvez voir dans quels déploiements un incident s’est produit à l’aide de l’icône séparatrice fusée (🚀).
📖 Consultez également notre guide sur comment configurer les marqueurs de déploiement.
Marqueurs de déploiement dans la liste des échantillons

Méthodes de déploiement

Il existe deux méthodes pour notifier AppSignal d’un nouveau déploiement. Ces deux méthodes ne peuvent pas être utilisées ensemble.
  1. Utilisation de l’option de configuration revision, et ;
  2. Création manuelle d’une notification de déploiement avec l’API Push d’AppSignal.
La première méthode (option de configuration revision) est notre approche recommandée, car c’est la méthode la plus fiable et fonctionne mieux pour les applications avec plus d’un hôte. Nous détectons la révision à partir de l’application elle-même afin que nous sachions quelle instance exécute quelle version. La seconde approche (création manuelle d’un marqueur de déploiement) est une méthode vraiment utile uniquement pour les petites applications qui utilisent un seul hôte. Elle crée un nouveau marqueur de déploiement à un moment précis, indépendamment de la version réellement exécutée par l’application. Cela signifie également qu’elle est plus sujette aux erreurs.

Option de configuration revision

L’approche recommandée pour informer AppSignal qu’une nouvelle version de votre application est déployée consiste à utiliser l’option de configuration revision ou la variable d’environnement APP_REVISION (consultez le guide de configuration des marqueurs de déploiement pour plus d’informations). Cela est automatiquement détecté pour les applications Heroku en utilisant la fonctionnalité de laboratoire dyno metadata. Cette option de configuration est définie par instance d’une application, ce qui a l’avantage que chaque version d’une application s’exécutant en même temps signale les erreurs sous le bon déploiement, plutôt que sous le dernier déploiement qui a été signalé à AppSignal. Par exemple : Si une machine exécute toujours une ancienne version de l’application, toutes les erreurs de cette instance sont signalées sous le marqueur de déploiement précédent plutôt que sous le dernier marqueur de déploiement connu. AppSignal créera un nouveau marqueur de déploiement lorsqu’il recevra des données de transaction. Lorsque l’option de configuration revision est définie pour votre application, la révision est stockée sur une transaction qui suit une requête web / un job d’arrière-plan. Lorsque notre processeur sur les serveurs AppSignal détecte une nouvelle révision, il créera un nouveau marqueur de déploiement pour l’application parente avec la révision de la transaction.

Option de configuration

L’option de configuration revision peut être utilisée dans n’importe quelle intégration pour signaler le déploiement actuel de l’application. Consultez le guide des marqueurs de déploiement pour plus d’informations.
AppSignal.configure do |config|
  config.revision = "abcdef12"
end
Si vous exécutez une version dans laquelle cette option de configuration n’est pas disponible, nous recommandons d’utiliser la variable d’environnement APP_REVISION à la place.

Variable d’environnement système

La valeur APP_REVISION peut être n’importe quelle valeur que vous utilisez pour indiquer une version/révision. Par exemple : un numéro de version 1.4.2 ou un SHA git cf8bc42. La valeur de la révision doit être définie dans l’environnement système de l’application et mise à jour lors du déploiement de l’application.
export APP_REVISION="cf8bc42"
# Start your application
# bundle exec rackup app.rb

Support Heroku

Lorsque vous utilisez Heroku avec l’option Heroku Labs: Dyno Metadata activée, Heroku remplira la variable d’environnement HEROKU_SLUG_COMMIT avec le SHA du commit Git en cours de déploiement. AppSignal définira automatiquement l’option de configuration revision sur la valeur de la variable d’environnement système HEROKU_SLUG_COMMIT. Cela signalera automatiquement les nouveaux déploiements lorsque l’application Heroku est déployée.

Support Render

Lors du déploiement d’une application avec Render, la variable d’environnement RENDER_GIT_COMMIT sera renseignée avec le SHA du commit Git en cours de déploiement. AppSignal définira automatiquement l’option de configuration revision sur la valeur de la variable d’environnement système RENDER_GIT_COMMIT. Cela signalera automatiquement les nouveaux déploiements lorsque l’application Render est déployée.

Support Hatchbox

Pour utiliser les marqueurs de déploiement avec Hatchbox, connectez d’abord votre compte Hatchbox à AppSignal :
  1. Dans Hatchbox, accédez aux paramètres de votre profil et naviguez vers Connected accounts.
  2. Sur la page « Connected accounts », sélectionnez Sign in with AppSignal.
  3. Dans la fenêtre AppSignal qui s’ouvre, autorisez Hatchbox à accéder à votre organisation AppSignal en sélectionnant Allow access.
Lors du déploiement d’une application avec Hatchbox, un fichier REVISION sera ajouté dans le dossier de release avec le SHA du commit Git en cours de déploiement. AppSignal définira automatiquement l’option de configuration revision sur la valeur du fichier REVISION. Cela signalera automatiquement les nouveaux déploiements lorsque l’application Hatchbox est déployée.

Support Kamal

Lors du déploiement d’une application avec Kamal, la variable d’environnement KAMAL_VERSION sera renseignée dans le conteneur avec le SHA du commit Git en cours de déploiement. AppSignal définira automatiquement l’option de configuration revision sur la valeur de la variable d’environnement système KAMAL_VERSION. Cela signalera automatiquement les nouveaux déploiements lorsque l’application est déployée avec Kamal.

Support Docker

Si votre application s’exécute dans un conteneur Docker, suivez les instructions ci-dessous pour définir la révision de votre application et créer un marqueur de déploiement. Tout d’abord, ajoutez les instructions suivantes à votre Dockerfile, directement après la dernière instruction FROM :
ARG COMMIT
ENV APP_REVISION=$COMMIT
Une fois ajoutées, vous devez inclure la révision de votre application lors de la construction de votre image Docker :
Bash
docker build --build-arg COMMIT=$(git rev-parse HEAD) -t image:latest
Lorsque vous utilisez Fly.io pour déployer votre application, l’argument de build COMMIT est fourni automatiquement lors de la construction.
Cela définira la variable d’environnement APP_REVISION pour votre application et permettra à l’intégration AppSignal d’utiliser la révision comme marqueur de déploiement.

Support GitLab

Lors d’un déploiement depuis un pipeline GitLab CI/CD, définissez la variable d’environnement APP_REVISION dans votre tâche de déploiement sur le SHA du commit afin qu’AppSignal la récupère au démarrage de l’application :
deploy:production:
  stage: deploy
  variables:
    APP_REVISION: $CI_COMMIT_SHA
  script:
    - ./bin/deploy.sh
CI_COMMIT_SHA est l’une des variables CI/CD prédéfinies de GitLab et correspond au commit en cours de déploiement. Si votre stack n’inclut pas d’intégration AppSignal, consultez plutôt l’exemple GitLab CI/CD.

Créer manuellement un marqueur de déploiement

Cette méthode de signalement des marqueurs de déploiement est obsolète et peut être supprimée à tout moment à l’avenir. Signaler des marqueurs de déploiement avec cette méthode n’est utile que pour les petites applications qui utilisent une seule instance d’application. Elle crée un nouveau marqueur de déploiement à un moment précis, indépendamment de la version réellement exécutée par l’application. Cela signifie également qu’elle est plus sujette aux erreurs en regroupant sous le déploiement des données qui ne devraient pas en faire partie. Nous détectons automatiquement le déploiement en lisant le fichier REVISION que Capistrano ajoute au répertoire de release depuis la gem Ruby 4.5.18.
Cette méthode de signalisation de nouveaux déploiements à AppSignal nécessite que vous envoyiez une requête POST au point de terminaison de l’API Push d’AppSignal pour les marqueurs. Cela peut être fait avec une requête HTTP POST manuelle pour d’autres langages. Lorsque la requête de création/notification de marqueur de déploiement est reçue par les serveurs AppSignal, toutes les données traitées par nos serveurs après cette heure sont suivies sous le déploiement nouvellement créé. Pour créer un marqueur de déploiement avec une requête HTTP POST, vous pouvez utiliser curl ou un autre outil similaire. La charge utile de la requête est un objet JSON contenant des données sur le marqueur, telles que la révision, l’utilisateur qui l’a déployée et le dépôt de l’application. Pour en savoir plus sur la création de marqueurs de déploiement avec notre API, consultez notre documentation sur le point de terminaison API.

Exemple GitLab CI/CD

Si vous ne pouvez pas utiliser l’option de configuration revision — par exemple, parce que votre pile n’inclut pas d’intégration AppSignal — vous pouvez appeler l’API Markers depuis un job GitLab CI/CD séparé après la réussite de votre déploiement. Tout d’abord, stockez vos identifiants AppSignal en tant que variables CI/CD masquées dans les Settings → CI/CD → Variables de votre projet GitLab :
  • APPSIGNAL_API_TOKEN — votre jeton API personnel (Profile → Account settings → Personal → API).
  • APPSIGNAL_APP_ID — l’ID de l’application AppSignal pour l’environnement que vous déployez. Trouvez-le dans l’URL AppSignal : https://appsignal.com/<org-slug>/sites/<APPSIGNAL_APP_ID>/....
Ajoutez ensuite un job deploy-marker à votre .gitlab-ci.yml :
stages:
  - deploy
  - notify

deploy:production:
  stage: deploy
  script:
    - ./bin/deploy.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

appsignal:deploy_marker:
  stage: notify
  image: curlimages/curl:latest
  needs: ["deploy:production"]
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  script:
    - |
      curl --fail --silent --show-error \
        -H "Content-Type: application/json" \
        -X POST "https://appsignal.com/api/${APPSIGNAL_APP_ID}/markers.json?token=${APPSIGNAL_API_TOKEN}" \
        -d "{
              \"marker\": {
                \"kind\": \"deploy\",
                \"repository\": \"${CI_PROJECT_URL}.git\",
                \"revision\": \"${CI_COMMIT_SHA}\",
                \"user\": \"${GITLAB_USER_LOGIN}\"
              }
            }"
Les webhooks GitLab ne peuvent pas être utilisés pour appeler directement l’API Markers — les charges utiles des webhooks GitLab ont un format fixe qui ne correspond pas au corps de la requête de l’API Markers, et GitLab ne vous permet pas de transformer la charge utile avant l’envoi.

Dépannage

Si le job du marqueur échoue avec 401 Unauthorized, revérifiez APPSIGNAL_API_TOKEN. Il doit s’agir d’un jeton API personnel depuis Profile → Account settings → Personal → API, et non de la Push API key. Confirmez que la variable n’est pas restreinte par la portée d’environnement à un environnement différent de celui dans lequel le job s’exécute. Si le job du marqueur échoue avec 404 Not Found, le APPSIGNAL_APP_ID est incorrect ou appartient à une autre organisation. Copiez-le depuis l’URL de l’application AppSignal (https://appsignal.com/<org>/sites/<APPSIGNAL_APP_ID>/...).