Udrulninger og ændringer

Status200 fører et register over, hvad der har ændret sig i dit projekt: udrulninger, Kubernetes-rollouts, konfigurationsændringer og de rettelser, den selv har kørt. Hver ændring tegnes som en markør på graferne for dens tjeneste, og Status200 AI læser dem, når den undersøger en hændelse, så "det begyndte lige efter udrulningen kl. 10:02" er det første, du får at vide, ikke det sidste.

Sådan virker det#

Hvad Status200 registrerer af sig selv#

Disse kræver ikke, at du sender noget. Status200 registrerer dem ud fra den telemetri, den allerede modtager, og ud fra det, den selv gør.

• Den første version, en tjeneste rapporterer, er dens udgangspunkt, ikke en udrulning. En tjeneste, der har kørt i måneder, bliver ikke udrullet i det øjeblik, Status200 begynder at modtage dens telemetri.
• En rollback til en version, der er set inden for de seneste 30 dage, registreres ikke, fordi den version ikke er ny. En rollback, som Status200 AI kører, registreres som en rettelse.
• Ud over 6 nye versioner eller ReplicaSets inden for en time registreres der ikke flere, før timen er gået. En "version", der ændrer sig med hver pod, for eksempel et build-tidsstempel, ville ellers registrere en udrulning for hver pod.

En udrulning registreres kun for en tjeneste, der rapporterer service.version. Sæt den sammen med miljøet og committen i ressourceattributterne i din OpenTelemetry-SDK eller -collector:

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

En rollout kræver Kubernetes-agenten, som stempler hver pods telemetri med dens Deployment og ReplicaSet.

Registrér en udrulning fra en pipeline#

En pipeline kan registrere en udrulning eller enhver anden ændring, mens den sker: en konfigurationsændring, en migrering, et feature flag. Den skriver med en telemetri-indtagelsesnøgle til dit projekt, den slags, dine applikationer sender telemetri med. Opret en under Projektindstillinger → Telemetri og APM → Indtagelsesnøgler.

En nøgle, der er låst til én tjeneste, registrerer hver ændring under den tjeneste.

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å en selvhostet Status200 skal du bruge din egen adresse i stedet for https://status200.ru. API'et svarer med, hvor mange begivenheder det gemte, og hvor mange det sprang over:

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

Se oneuptime deploy for alle CLI'ens indstillinger.

Sådan bruger Status200 AI ændringer#

Hver AI-undersøgelse af en hændelse eller en advarsel starter fra de ændringer, der er registreret i de 2 timer før den og i de 10 minutter efter, for en pipeline, der først registrerer sin udrulning, når rollouten er færdig. Ændringerne på de tjenester, clustre og værter, som hændelsen er knyttet til, kommer først.

For op til 4 af dem, der nævner en tjeneste, læser Status200 tjenestens telemetri i de 30 minutter før og efter ændringen og markerer ændringen som mistænkt, når tjenesten blev målbart dårligere lige efter den:

Status200 afgør ud fra disse tal, hvilken ændring der er mistænkt, ikke ud fra, hvad en ændrings titel siger. Undersøgelsen tjekker en mistænkt ændring først, siger, om den forårsagede hændelsen, og siger, om det at rulle den tilbage er den hurtigste sikre rettelse.

Når den mistænkte ændring er en Kubernetes-rollout på et cluster, hvor AI-rettelser er slået til, ruller Status200 AI den tilbage først med en kubectl rollout undo, som Status200 bygger ud fra den registrerede ændring. En udrulning, der leverer kode, rulles tilbage gennem sine commits: undersøgelsen nævner den commit eller pull request, der forårsagede problemet, så en pull request med en rettelse kan rulle præcis den tilbage.

Status200 tjekker også hver udrulning af sig selv, uanset om nogen bliver tilkaldt. Når de 30 minutter efter en udrulning er gået, sammenligner den dem med de 30 minutter før efter de samme tærskler, og når tjenesten blev dårligere, nævner en AI-indsigt udrulningen på den tjeneste.

En pull request med en rettelse, som Status200 AI åbnede, kontrolleres på samme måde: når en registreret udrulning indeholder dens commit, holder Status200 der øje med det, rettelsen var til - undtagelsen, operationen, den gjorde hurtigere, monitoren bag hændelsen eller advarslen, telemetrien, den tilføjer - og siger, om rettelsen virkede (se Automatiske koderettelser). Den udrullede rettelse læses kun i udrulningens version, når tjenestens egen telemetri melder den version, og ellers fra 10 minutter efter udrulningen, når gamle instanser er stoppet.

I en undersøgelse og i Ask AI viser recent_changes ændringerne i et hvilket som helst tidsvindue, og get_change_details viser, hvad en udrulning leverede: commits siden tjenestens forrige udrulning, deres forfattere, pull requests og de filer, de ændrede. Det kræver committen på ændringen og et repository, der er forbundet via GitHub App.

Reference#

Felter#

Felterne på øverste niveau gemmes som attributter under OpenTelemetry-navnene: 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 og environment som deployment.environment.name. En attribut, der sendes under et af de navne, går forud for sit felt.

Attributter, hvis navne begynder med status200., er Status200s egne og fjernes fra det, en pipeline sender. Hver ændring, som en pipeline registrerer, angiver det i status200.change.source, som er api.

Grænser#

Næste skridt#