Despliegues y cambios

Status200 lleva un registro de lo que cambió en tu proyecto: despliegues, rollouts de Kubernetes, cambios de configuración y las correcciones que ejecutó él mismo. Cada cambio se dibuja como un marcador en los gráficos de su servicio, y Status200 AI los lee cuando investiga un incidente, así que «empezó justo después del despliegue de las 10:02» es lo primero que sabes, no lo último.

Cómo funciona#

Lo que Status200 registra por su cuenta#

Para estos no tienes que enviar nada. Status200 los registra a partir de la telemetría que ya recibe y de lo que hace él mismo.

• La primera versión que informa un servicio es su punto de partida, no un despliegue. Un servicio que lleva meses en marcha no se despliega en el momento en que Status200 empieza a recibir su telemetría.
• Una reversión a una versión vista en los últimos 30 días no se registra, porque esa versión no es nueva. Una reversión que ejecuta Status200 AI se registra como una corrección.
• Con más de 6 versiones o ReplicaSets nuevos en una hora, se deja de registrar hasta que termina la hora. De lo contrario, una «versión» que cambia con cada pod, como una marca de tiempo de compilación, registraría un despliegue por cada pod.

Un despliegue solo se registra para un servicio que informa service.version. Defínelo, junto con el entorno y el commit, en los atributos de recurso de tu SDK o collector de OpenTelemetry:

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

Un rollout necesita el agente de Kubernetes, que marca la telemetría de cada pod con su Deployment y su ReplicaSet.

Registrar un despliegue desde un pipeline#

Un pipeline puede registrar un despliegue, o cualquier otro cambio, en el momento en que ocurre: un cambio de configuración, una migración, un feature flag. Escribe con una clave de ingesta de telemetría de tu proyecto, del mismo tipo que la que usan tus aplicaciones para enviar telemetría. Crea una en Ajustes del proyecto → Telemetría y APM → Claves de ingesta.

Una clave fijada a un servicio registra cada cambio en ese servicio.

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

En un Status200 autoalojado, usa tu propia dirección en lugar de https://status200.ru. La API responde con cuántos eventos guardó y cuántos omitió:

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

Consulta oneuptime deploy para ver todas las opciones de la CLI.

Cómo usa Status200 AI los cambios#

Cada investigación de IA de un incidente o de una alerta parte de los cambios registrados en las 2 horas anteriores, y en los 10 minutos posteriores, para un pipeline que registra su despliegue una vez terminado el rollout. Primero van los cambios de los servicios, clústeres y hosts con los que está vinculado el incidente.

Para un máximo de 4 de ellos que nombran un servicio, Status200 lee la telemetría del servicio en los 30 minutos anteriores y posteriores al cambio, y marca el cambio como sospechoso cuando el servicio empeoró de forma medible justo después:

Status200 decide qué cambio es sospechoso a partir de estas cifras, no de lo que dice el título de un cambio. La investigación comprueba primero un cambio sospechoso, dice si causó el incidente y dice si revertirlo es la corrección segura más rápida.

Cuando el cambio sospechoso es un rollout de Kubernetes en un clúster cuyas correcciones de IA están activadas, Status200 AI lo revierte primero, con un kubectl rollout undo que Status200 construye a partir del cambio registrado. Un despliegue que publica código se revierte a través de sus commits: la investigación nombra el commit o el pull request que causó el problema, para que un pull request de corrección pueda revertir exactamente eso.

Status200 también comprueba cada despliegue por su cuenta, se avise a alguien o no. Cuando han pasado los 30 minutos posteriores a un despliegue, los compara con los 30 minutos anteriores según los mismos umbrales y, si el servicio empeoró, un hallazgo de IA nombra el despliegue en ese servicio.

Un pull request de corrección que Status200 AI abrió se comprueba de la misma forma: en cuanto un despliegue registrado contiene su commit, Status200 vigila allí aquello para lo que era la corrección - la excepción, la operación que hizo más rápida, el monitor detrás del incidente o la alerta, la telemetría que añade - e indica si la corrección funcionó (consulta Correcciones de código automáticas). La corrección desplegada solo se lee en la versión del despliegue cuando la propia telemetría del servicio indica esa versión, y si no, desde 10 minutos después del despliegue, cuando las instancias antiguas ya se han detenido.

En una investigación y en Preguntar a la IA, recent_changes lista los cambios de cualquier intervalo, y get_change_details muestra lo que publicó un despliegue: los commits desde el despliegue anterior del servicio, sus autores, los pull requests y los archivos que tocaron. Para eso hacen falta el commit en el cambio y un repositorio conectado a través de la GitHub App.

Referencia#

Campos#

Los campos de nivel superior se guardan como atributos con los nombres de OpenTelemetry: version como service.version, commit como vcs.ref.head.revision, repository como vcs.repository.url.full, branch como vcs.ref.head.name, pullRequest como vcs.change.id y environment como deployment.environment.name. Un atributo enviado con uno de esos nombres prevalece sobre su campo.

Los atributos cuyos nombres empiezan por status200. son propios de Status200 y se eliminan de lo que envía un pipeline. Cada cambio que registra un pipeline lo indica en status200.change.source, que vale api.

Límites#

Próximos pasos#