Driftsättningar och ändringar

Status200 för bok över vad som ändrades i ditt projekt: driftsättningar, utrullningar i Kubernetes, konfigurationsändringar och de åtgärder som Status200 själv körde. Varje ändring ritas som en markör i diagrammen för sin tjänst, och Status200 AI läser ändringarna när den utreder en incident, så att "det började direkt efter driftsättningen 10:02" är det första du får veta, inte det sista.

Så fungerar det#

Vad Status200 registrerar på egen hand#

Du behöver inte skicka något för de här. Status200 registrerar dem utifrån telemetrin som den redan tar emot och utifrån det som den själv gör.

• Den första versionen som en tjänst rapporterar är dess utgångsläge, inte en driftsättning. En tjänst som har körts i månader driftsätts inte i samma ögonblick som Status200 börjar ta emot dess telemetri.
• En återgång till en version som har setts under de senaste 30 dagarna registreras inte, eftersom den versionen inte är ny. En återgång som Status200 AI kör registreras som en åtgärd.
• Efter 6 nya versioner eller ReplicaSets under en timme registreras inga fler förrän timmen är slut. Annars skulle en "version" som ändras med varje podd, till exempel en tidsstämpel för bygget, registrera en driftsättning för varje podd.

En driftsättning registreras bara för en tjänst som rapporterar service.version. Ange den, tillsammans med miljön och committen, i resursattributen för din OpenTelemetry-SDK eller collector:

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

En utrullning kräver Kubernetes-agenten, som märker varje podds telemetri med dess Deployment och ReplicaSet.

Registrera en driftsättning från en pipeline#

En pipeline kan registrera en driftsättning, eller vilken annan ändring som helst, när den sker: en konfigurationsändring, en migrering, en funktionsflagga. Den skriver med en intagningsnyckel för telemetri från ditt projekt, samma sorts nyckel som dina applikationer skickar telemetri med. Skapa en under Projektinställningar → Telemetri och APM → Intagningsnycklar.

En nyckel som är fäst vid en tjänst registrerar varje ändring under den tjänsten.

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"}]}'

På ett självhostat Status200 använder du din egen adress i stället för https://status200.ru. API:et svarar med hur många händelser det lagrade och hur många det hoppade över:

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

Se oneuptime deploy för alla alternativ i CLI:n.

Så använder Status200 AI ändringar#

Varje AI-utredning av en incident eller ett larm utgår från ändringarna som registrerades under de 2 timmarna före den, och under de 10 minuterna efter, för en pipeline som registrerar sin driftsättning först när utrullningen är klar. Ändringarna på de tjänster, kluster och värdar som incidenten är länkad till kommer först.

För upp till 4 av dem som anger en tjänst läser Status200 tjänstens telemetri under 30 minuter före och efter ändringen, och markerar ändringen som misstänkt när tjänsten blev mätbart sämre direkt efter den:

Status200 avgör vilken ändring som är misstänkt utifrån de här siffrorna, inte utifrån vad en ändrings titel säger. Utredningen kontrollerar en misstänkt ändring först, säger om den orsakade incidenten och säger om det snabbaste säkra sättet att åtgärda den är att rulla tillbaka den.

När den misstänkta ändringen är en utrullning i Kubernetes på ett kluster där AI-åtgärder är påslagna, rullar Status200 AI först tillbaka den, med en kubectl rollout undo som Status200 bygger utifrån den registrerade ändringen. En driftsättning som levererar kod rullas tillbaka genom sina commits: utredningen pekar ut den commit eller pull request som orsakade felet, så att en pull-förfrågan med en korrigering kan återställa precis den.

Status200 kontrollerar också varje driftsättning på egen hand, oavsett om någon larmas eller inte. När de 30 minuterna efter en driftsättning har gått jämför den dem med de 30 minuterna före enligt samma trösklar, och när tjänsten blev sämre nämner en AI-insikt driftsättningen på den tjänsten.

En pull-förfrågan med en korrigering som Status200 AI har öppnat kontrolleras på samma sätt: när en registrerad driftsättning innehåller dess commit bevakar Status200 där det som korrigeringen var till för - undantaget, operationen den gjorde snabbare, monitorn bakom incidenten eller aviseringen, telemetrin den lägger till - och anger om korrigeringen fungerade (se Automatiska kodkorrigeringar). Den driftsatta korrigeringen läses i driftsättningens version bara när tjänstens egen telemetri rapporterar den versionen, och annars från 10 minuter efter driftsättningen, när gamla instanser har stoppats.

I en utredning och i Fråga AI listar recent_changes ändringarna i valfritt tidsfönster, och get_change_details visar vad en driftsättning levererade: commits sedan tjänstens föregående driftsättning, deras författare, pull requests och filerna de ändrade. Det kräver committen på ändringen och ett repository som är anslutet via GitHub App.

Referens#

Fält#

Fälten på toppnivå lagras som attribut under OpenTelemetry-namnen: version som service.version, commit som vcs.ref.head.revision, repository som vcs.repository.url.full, branch som vcs.ref.head.name, pullRequest som vcs.change.id och environment som deployment.environment.name. Ett attribut som skickas under ett av de namnen har företräde framför sitt fält.

Attribut vars namn börjar med status200. är Status200s egna och tas bort från det som en pipeline skickar. Varje ändring som en pipeline registrerar anger det i status200.change.source, som är api.

Gränser#

Nästa steg#