Naar hoofdinhoud gaan
Markers zijn kleine pictogrammen die in grafieken op AppSignal.com worden gebruikt om een verandering aan te geven. Dit kan een code-deploy zijn met een “Deploy marker” of een speciale gebeurtenis met een “Custom marker”. Deploy markers vindt u ook in de sectie “Deploys” in de app-navigatie, die een performance-overzicht per deploy biedt. Een deploy marker geeft een wijziging in de gedeployde versie van een applicatie aan. Dit kan worden gebruikt om voorvallen van fouten en prestatieproblemen binnen een bepaald tijdsbestek te groeperen. Vanaf het moment dat de versie werd gedeployd totdat een nieuwere versie werd gedeployd. Deploy markers zijn ook vereist om backtrace links voor een app in te schakelen. Wanneer een nieuwe deploy wordt gedetecteerd, is de lijst met incidenten leeg voor de nieuwste deploymentversie. Wanneer een fout, of een ander probleem, door AppSignal in uw applicatie wordt gerapporteerd, wordt deze ook bij de nieuwste deploy vermeld. Op de sample-pagina van een incident kunt u zien in welke deploys een incident is opgetreden, met behulp van het raket-pictogram (🚀) als scheidingsteken.
📖 Lees ook onze gids over hoe u deploy markers instelt.
Deploy markers in samples list

​
Deploy-methoden

Er zijn twee methoden om AppSignal op de hoogte te stellen van een nieuwe deploy. Deze twee methoden kunnen niet samen worden gebruikt.
  1. Met de configuratieoptie revision, en;
  2. Door handmatig een deploymelding aan te maken met de AppSignal Push API.
De eerste methode (revision-configuratieoptie) is onze aanbevolen aanpak, omdat dit de meest betrouwbare methode is en beter werkt voor applicaties met meerdere hosts. We detecteren de revisie vanuit de applicatie zelf, zodat we weten welke instance welke versie draait. De tweede aanpak (handmatig een deploy marker aanmaken) is alleen echt nuttig voor kleine applicaties die één host gebruiken. Hij maakt op een specifiek tijdstip een nieuwe deploy marker aan, ongeacht de versie die de applicatie daadwerkelijk draait. Dit betekent ook dat deze methode foutgevoeliger is.

​
De configuratieoptie revision

De aanbevolen manier om AppSignal te laten weten dat er een nieuwe versie van uw applicatie is gedeployed, is door de configuratieoptie revision of de omgevingsvariabele APP_REVISION te gebruiken (zie de configuratiegids voor deploy markers voor meer informatie). Dit wordt automatisch gedetecteerd voor Heroku-apps met de dyno-metadata-labfunctie. Deze configuratieoptie wordt per instance van een applicatie ingesteld, wat het voordeel heeft dat elke versie van een applicatie die tegelijk draait de fouten onder de juiste deploy rapporteert, in plaats van onder de laatste deploy die is gerapporteerd aan AppSignal. Bijvoorbeeld: als één machine nog een oudere versie van de applicatie draait, worden alle fouten van die instance gerapporteerd onder de vorige deploy marker, in plaats van onder de laatst bekende deploy marker. AppSignal maakt een nieuwe deploy marker aan wanneer het transactiedata ontvangt. Wanneer de revision-configuratieoptie voor uw app is ingesteld, wordt de revisie opgeslagen op een transactie die een webrequest / background job volgt. Wanneer onze processor op de AppSignal-servers een nieuwe revisie detecteert, maakt deze een nieuwe deploy marker aan voor de bovenliggende app met de revisie uit de transactie.

​
Configuratieoptie

De configuratieoptie revision kan in elke integratie worden gebruikt om de huidige deploy van de app te rapporteren. Zie de gids voor deploy markers voor meer informatie. 
AppSignal.configure do |config|
  config.revision = "abcdef12"
end
Als u een versie draait waarin deze configuratieoptie niet beschikbaar is, raden we aan om in plaats daarvan de omgevingsvariabele APP_REVISION te gebruiken.

​
Systeem-omgevingsvariabele

De waarde van APP_REVISION kan elke waarde zijn die u gebruikt om een versie/revisie aan te duiden. Bijvoorbeeld: een versienummer 1.4.2 of een git-SHA cf8bc42. De revision-waarde moet worden ingesteld in de systeemomgeving van de applicatie en bijgewerkt worden tijdens een deploy van de applicatie. 
export APP_REVISION="cf8bc42"
# Start your application
# bundle exec rackup app.rb

​
Heroku-ondersteuning

Wanneer u Heroku gebruikt met de Heroku Labs: Dyno Metadata ingeschakeld, vult Heroku de omgevingsvariabele HEROKU_SLUG_COMMIT met de SHA van de git-commit die wordt gedeployd. AppSignal stelt de configuratieoptie revision automatisch in op de waarde van de systeem-omgevingsvariabele HEROKU_SLUG_COMMIT. Hierdoor worden nieuwe deploys automatisch gerapporteerd wanneer de Heroku-app wordt gedeployd.

​
Render-ondersteuning

Wanneer u een applicatie deployt met Render, vult deze de omgevingsvariabele RENDER_GIT_COMMIT met de SHA van de git-commit die wordt gedeployd. AppSignal stelt de configuratieoptie revision automatisch in op de waarde van de systeem-omgevingsvariabele RENDER_GIT_COMMIT. Hierdoor worden nieuwe deploys automatisch gerapporteerd wanneer de Render-app wordt gedeployd.

​
Hatchbox-ondersteuning

Om deploy markers met Hatchbox te gebruiken, koppelt u eerst uw Hatchbox-account aan AppSignal:
  1. Ga in Hatchbox naar uw profielinstellingen en navigeer naar Connected accounts.
  2. Selecteer op de pagina “Connected accounts” Sign in with AppSignal.
  3. Autoriseer Hatchbox in het AppSignal-venster dat wordt geopend om toegang te krijgen tot uw AppSignal-organisatie door Allow access te selecteren.
Wanneer u een applicatie deployt met Hatchbox, wordt er een REVISION-bestand toegevoegd in de release-map met de SHA van de Git-commit die wordt gedeployd. AppSignal stelt de configuratieoptie revision automatisch in op de waarde van het REVISION-bestand. Hierdoor worden nieuwe deploys automatisch gerapporteerd wanneer de Hatchbox-app wordt gedeployd.

​
Kamal-ondersteuning

Wanneer u een applicatie deployt met Kamal, vult deze de omgevingsvariabele KAMAL_VERSION binnen de container met de SHA van de git-commit die wordt gedeployd. AppSignal stelt de configuratieoptie revision automatisch in op de waarde van de systeem-omgevingsvariabele KAMAL_VERSION. Hierdoor worden nieuwe deploys automatisch gerapporteerd wanneer de app met Kamal wordt gedeployd.

​
Docker-ondersteuning

Als uw applicatie in een Docker-container draait, volg dan de onderstaande instructies om de revisie van uw applicatie in te stellen en een deploy marker aan te maken. Voeg eerst de volgende instructies toe aan uw Dockerfile, direct na de laatste FROM-instructie: 
ARG COMMIT
ENV APP_REVISION=$COMMIT
Zodra deze zijn toegevoegd, moet u de revisie van uw applicatie meegeven bij het bouwen van uw Docker-image:
Bash
docker build --build-arg COMMIT=$(git rev-parse HEAD) -t image:latest
Wanneer u Fly.io gebruikt om uw applicatie te deployen, wordt het COMMIT build-argument automatisch tijdens de build meegegeven.
Hiermee wordt de omgevingsvariabele APP_REVISION voor uw applicatie ingesteld, zodat de AppSignal-integratie de revisie als deploy marker kan gebruiken.

​
GitLab-ondersteuning

Wanneer u deployt vanuit een GitLab CI/CD-pipeline, stel dan de omgevingsvariabele APP_REVISION in uw deploy-job in op de commit-SHA, zodat AppSignal deze oppikt wanneer de app start: 
deploy:production:
  stage: deploy
  variables:
    APP_REVISION: $CI_COMMIT_SHA
  script:
    - ./bin/deploy.sh
CI_COMMIT_SHA is een van GitLabs vooraf gedefinieerde CI/CD-variabelen en verwijst naar de commit die wordt gedeployd. Als uw stack geen AppSignal-integratie bevat, raadpleeg dan het GitLab CI/CD-voorbeeld.

​
Handmatig een deploy marker aanmaken

Deze methode om deploy markers te rapporteren is verouderd en kan op elk moment in de toekomst worden verwijderd. Het rapporteren van deploy markers via deze methode is alleen nuttig voor kleine applicaties met één applicatie-instantie. Hiermee wordt op een specifiek tijdstip een nieuwe deploy marker aangemaakt, ongeacht de versie die de applicatie daadwerkelijk uitvoert. Dit betekent ook dat het foutgevoeliger is om gegevens onder de deploy te groeperen die er niet bij thuishoren. We detecteren deployment automatisch door het REVISION-bestand te lezen dat Capistrano sinds Ruby gem 4.5.18 aan de release-map toevoegt.
Bij deze methode om nieuwe deploys aan AppSignal te rapporteren, stuurt u een POST-request naar de markers-endpoint van de AppSignal Push API. Dit kan voor andere talen gedaan worden met een handmatige HTTP POST-request. Wanneer het create/notify-request voor de deploy marker wordt ontvangen door de AppSignal-servers, wordt alle data die na dat moment door onze servers wordt verwerkt, bijgehouden onder de nieuw aangemaakte deploy. Om een deploy marker aan te maken met een HTTP POST-request kunt u curl of een vergelijkbare tool gebruiken. De payload van de request is een JSON-object met data over de marker, zoals de revisie, de gebruiker die deze heeft gedeployed en de repository van de applicatie. Lees meer over hoe u deploy markers met onze API kunt aanmaken in onze API-endpoint-documentatie.

​
Voorbeeld voor GitLab CI/CD

Als u de revision-configuratieoptie niet kunt gebruiken — bijvoorbeeld omdat uw stack geen AppSignal-integratie bevat — kunt u de Markers API aanroepen vanuit een aparte GitLab CI/CD-job nadat uw deploy is geslaagd. Sla eerst uw AppSignal-credentials op als gemaskeerde CI/CD-variabelen in Settings → CI/CD → Variables van uw GitLab-project:
  • APPSIGNAL_API_TOKEN — uw persoonlijke API-token (Profile → Account settings → Personal → API).
  • APPSIGNAL_APP_ID — de AppSignal-app-id voor de omgeving die u deployt. Te vinden in de AppSignal-URL: https://appsignal.com/<org-slug>/sites/<APPSIGNAL_APP_ID>/....
Voeg vervolgens een deploy-marker-job toe aan uw .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}\"
              }
            }"
GitLab-webhooks kunnen niet worden gebruikt om de Markers API rechtstreeks aan te roepen — payloads van GitLab-webhooks hebben een vast formaat dat niet overeenkomt met de body van de Markers API-request, en GitLab biedt geen mogelijkheid om de payload aan te passen voordat deze wordt verzonden.

​
Probleemoplossing

Als de marker-job mislukt met 401 Unauthorized, controleer dan APPSIGNAL_API_TOKEN. Het moet een persoonlijke API-token zijn uit Profile → Account settings → Personal → API, niet de Push API key. Controleer of de variabele niet via Environment scope beperkt is tot een andere omgeving dan waarin de job draait. Als de marker-job mislukt met 404 Not Found, dan klopt de APPSIGNAL_APP_ID niet of behoort deze tot een andere organisatie. Kopieer deze uit de URL van de AppSignal-app (https://appsignal.com/<org>/sites/<APPSIGNAL_APP_ID>/...).