Deploy e modifiche

Status200 tiene traccia di ciò che è cambiato nel tuo progetto: deploy, rollout di Kubernetes, modifiche di configurazione e le correzioni che ha eseguito da sé. Ogni modifica viene disegnata come un marcatore sui grafici del suo servizio, e Status200 AI le legge quando indaga su un incidente, così "è iniziato subito dopo il deploy delle 10:02" è la prima cosa che scopri, non l'ultima.

Come funziona#

Che cosa registra Status200 da solo#

Per queste non devi inviare nulla. Status200 le registra a partire dalla telemetria che riceve già e da ciò che fa da sé.

• La prima versione che un servizio riporta è il suo punto di partenza, non un deploy. Un servizio che gira da mesi non viene rilasciato nel momento in cui Status200 inizia a riceverne la telemetria.
• Un rollback a una versione vista negli ultimi 30 giorni non viene registrato, perché quella versione non è nuova. Un rollback eseguito da Status200 AI viene registrato come correzione.
• Oltre 6 nuove versioni o nuovi ReplicaSet in un'ora, la registrazione si ferma fino alla fine dell'ora. Altrimenti una "versione" che cambia a ogni pod, come un timestamp di build, registrerebbe un deploy per ogni pod.

Un deploy viene registrato solo per un servizio che riporta service.version. Impostala, insieme all'ambiente e al commit, negli attributi di risorsa del tuo SDK o collector OpenTelemetry:

OTEL_RESOURCE_ATTRIBUTES="service.version=2.3.1,deployment.environment.name=production,vcs.ref.head.revision=$GIT_SHA"

Un rollout richiede l'agent Kubernetes, che contrassegna la telemetria di ogni pod con il suo Deployment e il suo ReplicaSet.

Registrare un deploy da una pipeline#

Una pipeline può registrare un deploy, o qualsiasi altra modifica, nel momento in cui avviene: una modifica di configurazione, una migrazione, un feature flag. Scrive con una chiave di acquisizione della telemetria del tuo progetto, dello stesso tipo con cui le tue applicazioni inviano la telemetria. Creane una in Impostazioni del progetto → Telemetria e APM → Chiavi di acquisizione.

Una chiave vincolata a un servizio registra ogni modifica sotto quel servizio.

oneuptime deploy \
  --service checkout \
  --service-version 2.3.1 \
  --commit "$GIT_SHA" \
  --environment production \
  --url https://status200.ru \
  --ingestion-key "$STATUS200_TELEMETRY_INGESTION_KEY"

- name: Record the deploy in Status200
  env:
    STATUS200_URL: https://status200.ru
    STATUS200_TELEMETRY_INGESTION_KEY: ${{ secrets.STATUS200_TELEMETRY_INGESTION_KEY }}
  run: |
    npx -y @status200/cli deploy \
      --service checkout \
      --service-version "${{ github.ref_name }}" \
      --commit "${{ github.sha }}" \
      --repository "${{ github.server_url }}/${{ github.repository }}" \
      --environment production

curl -X POST https://status200.ru/telemetry/change-events/v1/ingest \
  -H "Content-Type: application/json" \
  -H "x-status200-token: $STATUS200_TELEMETRY_INGESTION_KEY" \
  -d '{"events": [{"serviceName": "checkout", "version": "2.3.1", "commit": "1a2b3c4", "environment": "production"}]}'

Su un Status200 self-hosted, usa il tuo indirizzo invece di https://status200.ru. L'API risponde con quanti eventi ha memorizzato e quanti ne ha saltati:

{ "ingested": 1, "skipped": 0 }

Vedi oneuptime deploy per tutte le opzioni della CLI.

Come Status200 AI usa le modifiche#

Ogni indagine IA di un incidente o di un avviso parte dalle modifiche registrate nelle 2 ore precedenti, e nei 10 minuti successivi, per una pipeline che registra il suo deploy a rollout concluso. Le modifiche sui servizi, cluster e host a cui l'incidente è collegato vengono per prime.

Per un massimo di 4 di esse che nominano un servizio, Status200 legge la telemetria del servizio nei 30 minuti prima e dopo la modifica, e segna la modifica come sospetta quando il servizio è peggiorato in modo misurabile subito dopo:

Status200 decide quale modifica è sospetta in base a questi numeri, non a ciò che dice il titolo di una modifica. L'indagine controlla per prima una modifica sospetta, dice se ha causato l'incidente e dice se annullarla con un rollback è la correzione sicura più rapida.

Quando la modifica sospetta è un rollout Kubernetes su un cluster le cui correzioni IA sono attive, Status200 AI ne fa prima il rollback, con un kubectl rollout undo che Status200 costruisce a partire dalla modifica registrata. Un deploy che rilascia codice viene annullato tramite i suoi commit: l'indagine indica il commit o la pull request che ha causato il problema, così una pull request di correzione può annullare esattamente quello.

Status200 controlla anche ogni deploy da solo, che qualcuno venga avvisato o no. Trascorsi i 30 minuti dopo un deploy, li confronta con i 30 minuti prima secondo le stesse soglie e, quando il servizio è peggiorato, un AI Insight indica il deploy su quel servizio.

Una pull request di correzione che Status200 AI ha aperto viene verificata allo stesso modo: appena un deploy registrato contiene il suo commit, Status200 osserva lì ciò per cui serviva la correzione - l'eccezione, l'operazione che ha reso più veloce, il monitor dietro l'incidente o l'avviso, la telemetria che aggiunge - e indica se la correzione ha funzionato (vedi Correzioni automatiche del codice). La correzione distribuita viene letta nella versione del deploy solo quando la telemetria del servizio riporta essa stessa quella versione, e altrimenti da 10 minuti dopo il deploy, quando le vecchie istanze si sono fermate.

In un'indagine e in Chiedi all'IA, recent_changes elenca le modifiche in qualsiasi finestra di tempo, e get_change_details mostra che cosa ha rilasciato un deploy: i commit dal deploy precedente del servizio, i loro autori, le pull request e i file che hanno toccato. Per questo servono il commit sulla modifica e un repository collegato tramite la GitHub App.

Riferimento#

Campi#

I campi di primo livello vengono memorizzati come attributi con i nomi OpenTelemetry: version come service.version, commit come vcs.ref.head.revision, repository come vcs.repository.url.full, branch come vcs.ref.head.name, pullRequest come vcs.change.id e environment come deployment.environment.name. Un attributo inviato con uno di quei nomi prevale sul suo campo.

Gli attributi il cui nome inizia con status200. sono di Status200 e vengono scartati da ciò che invia una pipeline. Ogni modifica registrata da una pipeline lo dice in status200.change.source, che vale api.

Limiti#

Passaggi successivi#