Pular para o conteúdo principal
Markers são pequenos ícones usados em gráficos no AppSignal.com para indicar uma mudança. Isso pode ser um deploy de código usando um “Deploy marker” ou um evento especial com um “Custom marker”. Os deploy markers também podem ser encontrados na seção “Deploys” na navegação do app, que fornece uma visão geral de desempenho por deploy. Um marcador de deploy indica uma mudança na versão implantada de uma aplicação. Isso pode ser usado para agrupar ocorrências de erros e problemas de performance dentro de um determinado intervalo de tempo. Do momento em que a versão foi implantada até quando uma versão mais nova foi implantada. Marcadores de deploy também são necessários para habilitar links de backtrace para uma aplicação. Quando um novo deploy é detectado, a lista de incidentes fica vazia para a versão de deploy mais recente. Quando um erro, ou qualquer outro problema, é reportado pelo AppSignal na sua aplicação, ele também é listado para o deploy mais recente. Na página de samples de um incidente, você pode ver em quais deploys um incidente ocorreu com a ajuda do ícone separador de foguete (🚀).
📖 Leia também nosso guia sobre como configurar deploy markers.
Deploy markers na lista de samples

​
Métodos de deploy

Existem dois métodos para notificar o AppSignal sobre um novo deploy. Esses dois métodos não podem ser usados juntos.
  1. Usando a opção de configuração revision e;
  2. Criando manualmente uma notificação de deploy com a Push API do AppSignal.
O primeiro método (opção de configuração revision) é a nossa abordagem recomendada, porque é o método mais confiável e funciona melhor para aplicações com mais de um host. Detectamos a revisão a partir da própria aplicação, então sabemos qual instância está rodando qual versão. A segunda abordagem (criar um deploy marker manualmente) é um método realmente útil apenas para aplicações pequenas que usam um host. Ela cria um novo deploy marker em um horário específico, independentemente da versão que a aplicação realmente está rodando. Isso também significa que ela é mais suscetível a erros.

​
Opção de configuração revision

A abordagem recomendada para informar ao AppSignal que uma nova versão da sua aplicação foi implantada é usando a opção de configuração revision ou a variável de ambiente APP_REVISION (veja o guia de configuração de deploy markers para mais informações). Isso é detectado automaticamente para apps no Heroku usando o recurso lab de dyno metadata. Essa opção de configuração é definida por instância de uma aplicação, o que tem a vantagem de cada versão de uma aplicação em execução ao mesmo tempo reportar os erros sob o deploy correto, em vez do último deploy que foi reportado ao AppSignal. Por exemplo: se uma máquina ainda estiver rodando uma versão mais antiga da aplicação, todos os erros dessa instância são reportados sob o deploy marker anterior, em vez do último deploy marker conhecido. O AppSignal criará um novo deploy marker ao receber dados de transação. Quando a opção de configuração revision está definida para o seu app, a revisão é armazenada em uma transação que rastreia uma requisição web / background job. Quando nosso processador nos servidores do AppSignal detecta uma nova revisão, ele cria um novo deploy marker para o app pai com a revisão da transação.

​
Opção de configuração

A opção de configuração revision pode ser usada em qualquer integração para reportar o deploy atual do app. Veja o guia de deploy markers para mais informações. 
AppSignal.configure do |config|
  config.revision = "abcdef12"
end
Se você estiver rodando uma versão na qual essa opção de configuração não está disponível, recomendamos usar a variável de ambiente APP_REVISION em vez disso.

​
Variável de ambiente do sistema

O valor de APP_REVISION pode ser qualquer valor que você use para indicar uma versão/revisão. Por exemplo: um número de versão 1.4.2 ou um SHA do git cf8bc42. O valor de revisão deve ser definido no ambiente do sistema da aplicação e atualizado durante o deploy da aplicação. 
export APP_REVISION="cf8bc42"
# Start your application
# bundle exec rackup app.rb

​
Suporte ao Heroku

Ao usar Heroku com o Heroku Labs: Dyno Metadata habilitado, o Heroku preencherá a variável de ambiente HEROKU_SLUG_COMMIT com o SHA do commit Git que está sendo implantado. A AppSignal definirá automaticamente a opção de configuração revision com o valor da variável de ambiente de sistema HEROKU_SLUG_COMMIT. Isso reportará automaticamente novos deploys quando a aplicação Heroku for implantada.

​
Suporte ao Render

Ao fazer deploy de uma aplicação usando Render, ele preencherá a variável de ambiente RENDER_GIT_COMMIT com o SHA do commit Git que está sendo implantado. A AppSignal definirá automaticamente a opção de configuração revision com o valor da variável de ambiente de sistema RENDER_GIT_COMMIT. Isso reportará automaticamente novos deploys quando a aplicação Render for implantada.

​
Suporte ao Hatchbox

Para usar marcadores de deploy com o Hatchbox, primeiro conecte sua conta Hatchbox à AppSignal:
  1. No Hatchbox, vá até as configurações do seu perfil e navegue até Connected accounts.
  2. Na página “Connected accounts”, selecione Sign in with AppSignal.
  3. Na janela da AppSignal que abrir, autorize o Hatchbox a acessar sua organização AppSignal selecionando Allow access.
Ao fazer deploy de uma aplicação usando o Hatchbox, ele adicionará um arquivo REVISION na pasta de release com o SHA do commit Git que está sendo implantado. A AppSignal definirá automaticamente a opção de configuração revision com o valor do arquivo REVISION. Isso reportará automaticamente novos deploys quando a aplicação Hatchbox for implantada.

​
Suporte ao Kamal

Ao fazer deploy de uma aplicação usando Kamal, ele preencherá a variável de ambiente KAMAL_VERSION dentro do contêiner com o SHA do commit Git que está sendo implantado. A AppSignal definirá automaticamente a opção de configuração revision com o valor da variável de ambiente de sistema KAMAL_VERSION. Isso reportará automaticamente novos deploys quando a aplicação for implantada usando Kamal.

​
Suporte ao Docker

Se sua aplicação roda em um contêiner Docker, siga as instruções abaixo para definir a revisão da sua aplicação e criar um marcador de deploy. Primeiro, adicione as instruções a seguir ao seu Dockerfile, logo após a última instrução FROM: 
ARG COMMIT
ENV APP_REVISION=$COMMIT
Uma vez adicionado, você precisa incluir a revisão da sua aplicação ao construir sua imagem Docker:
Bash
docker build --build-arg COMMIT=$(git rev-parse HEAD) -t image:latest
Ao usar Fly.io para fazer o deploy da sua aplicação, o argumento de build COMMIT é fornecido automaticamente durante o build.
Isso definirá a variável de ambiente APP_REVISION para sua aplicação e permitirá que a integração da AppSignal use a revisão como um marcador de deploy.

​
Suporte ao GitLab

Ao fazer deploy a partir de um pipeline GitLab CI/CD, defina a variável de ambiente APP_REVISION no seu job de deploy com o SHA do commit, para que a AppSignal a capture quando a aplicação iniciar: 
deploy:production:
  stage: deploy
  variables:
    APP_REVISION: $CI_COMMIT_SHA
  script:
    - ./bin/deploy.sh
CI_COMMIT_SHA é uma das variáveis CI/CD predefinidas do GitLab e resolve para o commit que está sendo implantado. Se sua stack não inclui uma integração da AppSignal, veja o exemplo de GitLab CI/CD como alternativa.

​
Criar manualmente um deploy marker

Esse método de reportar marcadores de deploy está obsoleto e pode ser removido a qualquer momento no futuro. Reportar marcadores de deploy usando esse método só é útil para aplicações pequenas que usam uma única instância da aplicação. Ele cria um novo marcador de deploy em um momento específico, independentemente da versão que a aplicação está realmente executando. Isso também significa que é mais propenso a erros, agrupando dados que não deveriam pertencer ao deploy. Detectamos a implantação automaticamente lendo o arquivo REVISION que o Capistrano adiciona ao diretório de release desde a versão 4.5.18 da gem Ruby.
Esse método de reportar novos deploys ao AppSignal exige que você envie uma requisição POST para o endpoint markers da Push API do AppSignal. Isso pode ser feito com uma requisição HTTP POST manual para outras linguagens. Quando a requisição de criação/notificação de deploy marker é recebida pelos servidores do AppSignal, todos os dados processados pelos nossos servidores a partir desse momento são rastreados sob o deploy recém-criado. Para criar um Deploy marker com uma requisição HTTP POST, você pode usar curl ou alguma outra ferramenta semelhante. O payload da requisição é um objeto JSON com dados sobre o marker, como a revisão, o usuário que fez o deploy e o repositório da aplicação. Leia mais sobre como criar Deploy markers com a nossa API na nossa documentação de endpoint da API.

​
Exemplo de GitLab CI/CD

Se você não puder usar a opção de configuração revision — por exemplo, porque sua stack não inclui uma integração do AppSignal — você pode chamar a Markers API a partir de um job separado de GitLab CI/CD após o deploy ser bem-sucedido. Primeiro, armazene suas credenciais do AppSignal como variáveis mascaradas de CI/CD nas configurações do seu projeto no GitLab em Settings → CI/CD → Variables:
  • APPSIGNAL_API_TOKEN — seu token de API pessoal (Profile → Account settings → Personal → API).
  • APPSIGNAL_APP_ID — o ID do app no AppSignal para o ambiente em que você está fazendo deploy. Encontre-o na URL do AppSignal: https://appsignal.com/<org-slug>/sites/<APPSIGNAL_APP_ID>/....
Em seguida, adicione um job de deploy-marker ao seu .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}\"
              }
            }"
Webhooks do GitLab não podem ser usados para chamar a Markers API diretamente — os payloads dos webhooks do GitLab têm um formato fixo que não corresponde ao corpo de requisição da Markers API, e o GitLab não permite transformar o payload antes de enviá-lo.

​
Solução de problemas

Se o job do marker falhar com 401 Unauthorized, verifique novamente o APPSIGNAL_API_TOKEN. Ele deve ser um token de API pessoal de Profile → Account settings → Personal → API, não a Push API key. Confirme que a variável não está restrita por escopo de Environment a um ambiente diferente daquele em que o job é executado. Se o job do marker falhar com 404 Not Found, o APPSIGNAL_APP_ID está incorreto ou pertence a uma organização diferente. Copie-o da URL do app no AppSignal (https://appsignal.com/<org>/sites/<APPSIGNAL_APP_ID>/...).