Zum Hauptinhalt springen
Marker sind kleine Symbole, die in Diagrammen auf AppSignal.com verwendet werden, um eine Änderung anzuzeigen. Dies kann ein Code-Deploy mit einem “Deploy-Marker” oder ein besonderes Ereignis mit einem “Custom-Marker” sein. Deploy-Marker finden Sie auch im Abschnitt “Deploys” in der App-Navigation, der eine Performance-Übersicht pro Deploy bietet. Ein Deploy-Marker kennzeichnet eine Änderung der bereitgestellten Version einer Anwendung. Damit lassen sich Fehlervorkommen und Performance-Probleme innerhalb eines bestimmten Zeitraums gruppieren – vom Zeitpunkt der Bereitstellung der Version bis zur Bereitstellung einer neueren Version. Deploy-Marker sind außerdem erforderlich, um Backtrace-Links für eine Anwendung zu aktivieren. Wenn ein neuer Deploy erkannt wird, ist die Liste der Incidents für die neueste Deploy-Version leer. Wenn ein Fehler oder ein anderes Problem von AppSignal in Ihrer Anwendung gemeldet wird, wird er ebenfalls für den neuesten Deploy gelistet. Auf der Sample-Seite eines Incidents können Sie mithilfe des Raketen-Trennsymbols (🚀) erkennen, in welchen Deploys ein Incident aufgetreten ist.
📖 Lesen Sie auch unseren Leitfaden zur Einrichtung von Deploy-Markern.
Deploy-Marker in der Samples-Liste

​
Deploy-Methoden

Es gibt zwei Methoden, um AppSignal über einen neuen Deploy zu informieren. Diese beiden Methoden können nicht zusammen verwendet werden.
  1. Verwendung der Konfigurationsoption revision und
  2. manuelles Erstellen einer Deploy-Benachrichtigung mit der AppSignal Push API.
Die erste Methode (revision-Konfigurationsoption) ist unser empfohlener Ansatz, da sie die zuverlässigste Methode ist und besser für Anwendungen mit mehr als einem Host funktioniert. Wir erkennen die Revision aus der Anwendung selbst, sodass wir wissen, welche Instanz welche Version ausführt. Der zweite Ansatz (manuelles Erstellen eines Deploy-Markers) ist eine Methode, die nur für kleine Anwendungen mit einem einzigen Host wirklich nützlich ist. Sie erstellt zu einem bestimmten Zeitpunkt einen neuen Deploy-Marker, unabhängig von der tatsächlich ausgeführten Version der Anwendung. Das bedeutet auch, dass sie fehleranfälliger ist.

​
Revision-Konfigurationsoption

Der empfohlene Ansatz, um AppSignal mitzuteilen, dass eine neue Version Ihrer Anwendung deployed ist, besteht in der Verwendung der Konfigurationsoption revision oder der Umgebungsvariablen APP_REVISION (siehe Konfigurationsleitfaden für Deploy-Marker für weitere Informationen). Dies wird für Heroku-Apps mithilfe der Dyno-Metadata-Lab-Funktion automatisch erkannt. Diese Konfigurationsoption wird pro Instanz einer Anwendung gesetzt, was den Vorteil hat, dass jede gleichzeitig laufende Version einer Anwendung die Fehler unter dem richtigen Deploy meldet, anstatt unter dem letzten Deploy, der an AppSignal gemeldet wurde. Beispiel: Wenn auf einem Rechner noch eine ältere Version der Anwendung läuft, werden alle Fehler dieser Instanz unter dem vorherigen Deploy-Marker statt unter dem zuletzt bekannten Deploy-Marker gemeldet. AppSignal erstellt einen neuen Deploy-Marker, wenn es Transaktionsdaten empfängt. Wenn die revision-Konfigurationsoption für Ihre App gesetzt ist, wird die Revision in einer Transaktion gespeichert, die einen Webrequest oder Background-Job verfolgt. Wenn unser Processor auf den AppSignal-Servern eine neue Revision erkennt, erstellt er einen neuen Deploy-Marker für die zugehörige App mit der Revision aus der Transaktion.

​
Konfigurationsoption

Die revision-Konfigurationsoption kann in jeder Integration verwendet werden, um den aktuellen Deploy der App zu melden. Weitere Informationen finden Sie im Deploy-Marker-Leitfaden. 
AppSignal.configure do |config|
  config.revision = "abcdef12"
end
Wenn Sie eine Version verwenden, in der diese Konfigurationsoption nicht verfügbar ist, empfehlen wir stattdessen die Verwendung der Umgebungsvariablen APP_REVISION.

​
Systemumgebungsvariable

Der Wert von APP_REVISION kann jeder Wert sein, den Sie zur Angabe einer Version/Revision verwenden. Beispielsweise eine Versionsnummer 1.4.2 oder ein Git-SHA cf8bc42. Der Revisionswert sollte in der Systemumgebung der Anwendung gesetzt und während eines Deploys der Anwendung aktualisiert werden. 
export APP_REVISION="cf8bc42"
# Start your application
# bundle exec rackup app.rb

​
Heroku-Unterstützung

Wenn Sie Heroku mit aktivierten Heroku Labs: Dyno Metadata verwenden, befüllt Heroku die Umgebungsvariable HEROKU_SLUG_COMMIT mit dem SHA des bereitgestellten Git-Commits. AppSignal setzt die Konfigurationsoption revision automatisch auf den Wert der System-Umgebungsvariable HEROKU_SLUG_COMMIT. Dadurch werden neue Deployments automatisch gemeldet, wenn die Heroku-Anwendung bereitgestellt wird.

​
Render-Unterstützung

Beim Bereitstellen einer Anwendung mit Render wird die Umgebungsvariable RENDER_GIT_COMMIT mit dem SHA des bereitgestellten Git-Commits befüllt. AppSignal setzt die Konfigurationsoption revision automatisch auf den Wert der System-Umgebungsvariable RENDER_GIT_COMMIT. Dadurch werden neue Deployments automatisch gemeldet, wenn die Render-Anwendung bereitgestellt wird.

​
Hatchbox-Unterstützung

Um Deploy-Marker mit Hatchbox zu verwenden, verbinden Sie zunächst Ihr Hatchbox-Konto mit AppSignal:
  1. Gehen Sie in Hatchbox zu Ihren Profileinstellungen und navigieren Sie zu Connected accounts.
  2. Wählen Sie auf der Seite “Connected accounts” Sign in with AppSignal.
  3. Autorisieren Sie im sich öffnenden AppSignal-Fenster Hatchbox, auf Ihre AppSignal-Organisation zuzugreifen, indem Sie Allow access auswählen.
Beim Bereitstellen einer Anwendung mit Hatchbox wird eine REVISION-Datei im Release-Ordner mit dem SHA des bereitgestellten Git-Commits hinzugefügt. AppSignal setzt die Konfigurationsoption revision automatisch auf den Wert der REVISION-Datei. Dadurch werden neue Deployments automatisch gemeldet, wenn die Hatchbox-Anwendung bereitgestellt wird.

​
Kamal-Unterstützung

Beim Bereitstellen einer Anwendung mit Kamal wird die Umgebungsvariable KAMAL_VERSION innerhalb des Containers mit dem SHA des bereitgestellten Git-Commits befüllt. AppSignal setzt die Konfigurationsoption revision automatisch auf den Wert der System-Umgebungsvariable KAMAL_VERSION. Dadurch werden neue Deployments automatisch gemeldet, wenn die Anwendung mit Kamal bereitgestellt wird.

​
Docker-Unterstützung

Wenn Ihre Anwendung in einem Docker-Container läuft, folgen Sie den nachstehenden Anweisungen, um die Revision Ihrer Anwendung festzulegen und einen Deploy-Marker zu erstellen. Fügen Sie zunächst die folgenden Anweisungen in Ihr Dockerfile ein, direkt nach der letzten FROM-Anweisung: 
ARG COMMIT
ENV APP_REVISION=$COMMIT
Sobald dies hinzugefügt wurde, müssen Sie die Revision Ihrer Anwendung beim Erstellen Ihres Docker-Images angeben:
Bash
docker build --build-arg COMMIT=$(git rev-parse HEAD) -t image:latest
Wenn Sie Fly.io zum Bereitstellen Ihrer Anwendung verwenden, wird das Build-Argument COMMIT während des Builds automatisch bereitgestellt.
Dadurch wird die Umgebungsvariable APP_REVISION für Ihre Anwendung festgelegt, sodass die AppSignal-Integration die Revision als Deploy-Marker verwenden kann.

​
GitLab-Unterstützung

Setzen Sie beim Deployment aus einer GitLab-CI/CD-Pipeline die Umgebungsvariable APP_REVISION in Ihrem Deploy-Job auf den Commit-SHA, damit AppSignal sie beim Start der Anwendung übernimmt: 
deploy:production:
  stage: deploy
  variables:
    APP_REVISION: $CI_COMMIT_SHA
  script:
    - ./bin/deploy.sh
CI_COMMIT_SHA ist eine der vordefinierten CI/CD-Variablen von GitLab und entspricht dem Commit, der bereitgestellt wird. Wenn Ihr Stack keine AppSignal-Integration enthält, sehen Sie sich stattdessen das GitLab-CI/CD-Beispiel an.

​
Einen Deploy-Marker manuell erstellen

Diese Methode zum Melden von Deploy-Markern ist veraltet und kann in Zukunft jederzeit entfernt werden. Das Melden von Deploy-Markern mit dieser Methode ist nur für kleine Anwendungen sinnvoll, die eine einzige Anwendungsinstanz verwenden. Sie erstellt zu einem bestimmten Zeitpunkt einen neuen Deploy-Marker, unabhängig davon, welche Version die Anwendung tatsächlich ausführt. Das bedeutet auch, dass es fehleranfälliger ist, da Daten, die nicht zum Deployment gehören sollten, diesem zugeordnet werden können. Wir erkennen Deployments automatisch, indem wir die REVISION-Datei lesen, die Capistrano seit Ruby-Gem 4.5.18 zum Release-Verzeichnis hinzufügt.
Diese Methode zum Melden neuer Deploys an AppSignal erfordert, dass Sie eine POST-Anfrage an den Markers-Endpunkt der AppSignal Push API senden. Dies kann für andere Sprachen mit einer manuellen HTTP-POST-Anfrage erfolgen. Wenn die Anfrage zum Erstellen/Benachrichtigen über den Deploy-Marker von den AppSignal-Servern empfangen wird, werden alle Daten, die nach diesem Zeitpunkt von unseren Servern verarbeitet werden, unter dem neu erstellten Deploy erfasst. Um einen Deploy-Marker mit einer HTTP-POST-Anfrage zu erstellen, können Sie curl oder ein ähnliches Tool verwenden. Die Payload der Anfrage ist ein JSON-Objekt mit Daten zum Marker, wie der Revision, dem Benutzer, der ihn deployed hat, und dem Repository der Anwendung. Lesen Sie in unserer Dokumentation zum API-Endpunkt mehr darüber, wie Sie Deploy-Marker mit unserer API erstellen.

​
GitLab-CI/CD-Beispiel

Wenn Sie die Konfigurationsoption revision nicht verwenden können — beispielsweise, weil Ihr Stack keine AppSignal-Integration enthält — können Sie die Markers-API in einem separaten GitLab-CI/CD-Job aufrufen, nachdem Ihr Deploy erfolgreich war. Speichern Sie zunächst Ihre AppSignal-Anmeldedaten als maskierte CI/CD-Variablen in den Settings → CI/CD → Variables Ihres GitLab-Projekts:
  • APPSIGNAL_API_TOKEN — Ihr persönlicher API-Token (Profile → Account settings → Personal → API).
  • APPSIGNAL_APP_ID — die AppSignal-App-ID für die Umgebung, die Sie deployen. Sie finden sie in der AppSignal-URL: https://appsignal.com/<org-slug>/sites/<APPSIGNAL_APP_ID>/....
Fügen Sie dann einen Deploy-Marker-Job zu Ihrer .gitlab-ci.yml hinzu: 
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 können nicht verwendet werden, um die Markers-API direkt aufzurufen — GitLab- Webhook-Payloads haben ein festes Format, das nicht zum Request-Body der Markers-API passt, und GitLab lässt Sie die Payload vor dem Versenden nicht transformieren.

​
Fehlerbehebung

Wenn der Marker-Job mit 401 Unauthorized fehlschlägt, überprüfen Sie APPSIGNAL_API_TOKEN erneut. Es muss ein persönlicher API-Token aus Profile → Account settings → Personal → API sein, nicht der Push-API-Key. Stellen Sie sicher, dass die Variable nicht durch den Environment-Scope auf eine andere Umgebung beschränkt ist als die, in der der Job ausgeführt wird. Wenn der Marker-Job mit 404 Not Found fehlschlägt, ist APPSIGNAL_APP_ID falsch oder gehört zu einer anderen Organisation. Kopieren Sie sie aus der URL der AppSignal-App (https://appsignal.com/<org>/sites/<APPSIGNAL_APP_ID>/...).