Fenomena botsitting terjadi ketika tim engineering harus mengawasi AI agent atau LLM background worker secara manual demi memastikan proses tidak mengalami hallucination loop, rate limit exhaustion, atau silent hang. Mengawasi log streaming secara langsung menghilangkan efisiensi otomatisasi. Untuk mengatasi human toil ini, sistem memerlukan arsitektur self-healing berbasis telemetri deterministik, health check bertingkat, dan skema auto-rollback otomatis.

Metrik Observability Esensial untuk Worker AI

Mendeteksi degradasi pada worker AI tidak cukup hanya bergantung pada exit code proses. Worker berbasis LLM dapat terus berjalan (status 200 OK) meski terjebak dalam penalaran looping tanpa menghasilkan output valid. Tiga metrik utama yang wajib diekspos ke Prometheus:

  • Loop Execution Time: Durasi penyelesaian satu unit tugas (misalnya: chain of thought, retrieval, hingga tool calling). Lonjakan tajam menandakan dependensi eksternal hang atau model terjebak dalam loop.
  • Model Failure Rate: Rasio kegagalan parser schema JSON, invalid tool calls, atau response parsing error terhadap total panggilan LLM.
  • Retry Exhaustion Rate: Frekuensi task memicu retry hingga batas maksimum (misalnya backoff limit tercapai).

Contoh eksposisi metrik menggunakan modul prometheus_client di Python:

from prometheus_client import Counter, Histogram, start_http_server
import time

AI_LOOP_DURATION = Histogram(
    'ai_worker_loop_duration_seconds',
    'Waktu eksekusi satu cycle agent loop',
    buckets=[1.0, 5.0, 15.0, 30.0, 60.0, 120.0]
)
AI_FAILURE_TOTAL = Counter(
    'ai_worker_failures_total',
    'Total kegagalan inferensi atau validasi output',
    ['error_type']
)

def process_task(task):
    start = time.time()
    try:
        # Eksekusi reasoning engine / call tool
        execute_agent_logic(task)
    except OutputValidationError:
        AI_FAILURE_TOTAL.labels(error_type='validation_error').inc()
        raise
    except UpstreamProviderTimeout:
        AI_FAILURE_TOTAL.labels(error_type='llm_timeout').inc()
        raise
    finally:
        AI_LOOP_DURATION.observe(time.time() - start)

Implementasi Health Check Bertingkat

Pemeriksaan kondisi worker harus dipisahkan menjadi dua lapisan: liveness dan readiness/health berbasis status stateful.

1. Liveness Check (Process & Memory)

Memastikan proses worker masih aktif dan tidak mengalami deadlock. Jika thread worker mati atau konsumsi memori melampaui ambang batas OOM, supervisor (seperti Kubernetes liveness probe atau systemd watchdog) langsung mereboot container.

2. Readiness / Work Quality Check (Semantic Health)

Memvalidasi apakah worker masih terhubung dengan vector DB, Redis message broker, dan API endpoint provider LLM. Jika worker kehilangan context storage atau API key terblokir kuota, endpoint readiness harus mengembalikan status non-200 agar traffic dialihkan dari pod tersebut.

Konfigurasi Prometheus Alertmanager

Ketika worker memproduksi anomali berulang, Prometheus mendeteksi kondisi kritis dan mengirim payload ke webhook receiver untuk penanganan insiden otomatis.

groups:
  - name: ai_worker_guardrails
    rules:
      - alert: AIWorkerExhaustedRetries
        expr: rate(ai_worker_failures_total[5m]) > 0.25
        for: 2m
        labels:
          severity: critical
          action: auto-rollback
        annotations:
          summary: "Tingkat kegagalan AI Worker melampaui 25% dalam 5 menit"

      - alert: AIWorkerExecutionStall
        expr: histogram_quantile(0.95, sum(rate(ai_worker_loop_duration_seconds_bucket[5m])) by (le)) > 90
        for: 3m
        labels:
          severity: critical
          action: auto-rollback
        annotations:
          summary: "P95 loop duration melebihi ambang batas toleransi (90 detik)"

Eksekusi Auto-Rollback Berbasis Webhook

Saat alert AIWorkerExhaustedRetries aktif, Alertmanager mengirimkan webhook HTTP POST ke controller perantara. Controller ini bertugas mengeksekusi rollback ke versi release deployment sebelumnya.

Berikut implementasi webhook handler minimal menggunakan FastAPI dan library Kubernetes client:

from fastapi import FastAPI, Request, HTTPException
from kubernetes import client, config
import os

app = FastAPI()
config.load_incluster_config()
k8s_apps = client.AppsV1Api()

DEPLOYMENT_NAME = os.getenv("DEPLOYMENT_NAME", "ai-agent-worker")
NAMESPACE = os.getenv("NAMESPACE", "production")

@app.post("/alerts/auto-rollback")
async def handle_alert(request: Request):
    payload = await request.json()
    alerts = payload.get("alerts", [])
    
    for alert in alerts:
        labels = alert.get("labels", {})
        if labels.get("action") == "auto-rollback" and alert.get("status") == "firing":
            execute_rollback(DEPLOYMENT_NAME, NAMESPACE)
            return {"status": "rollback_triggered", "target": DEPLOYMENT_NAME}
            
    return {"status": "ignored"}

def execute_rollback(deployment_name: str, namespace: str):
    # Revert deployment ke revision sebelumnya via patch image atau helm rollback
    # Contoh sederhana: patch deployment annotation untuk trigger native undo/redeploy
    patch_body = {
        "spec": {
            "template": {
                "metadata": {
                    "annotations": {"rollback.kubernetes.io/trigger": "prometheus-alert"}
                }
            }
        }
    }
    k8s_apps.patch_namespaced_deployment(
        name=deployment_name,
        namespace=namespace,
        body=patch_body
    )

Isolasi State Drift dan Circuit Breaker

Worker otonom rentan terhadap degradasi state yang tersisa di memory atau caching layer. Jika prompt injection atau corrupt response tersimpan di Redis/vector database, deployment ulang saja tidak cukup.

  • Isolasi Workspace: Buat session context bersifat ephemeral. Bersihkan working memory agent pada setiap task lifecycle selesai atau gagal.
  • State Checkpoint: Simpan checkpoint deterministik di database transaksional. Jika rollback terjadi, worker dapat kembali ke state valid terakhir tanpa memproses ulang input korup.
  • Circuit Breaker Integrasi LLM: Terapkan circuit breaker (misalnya pola 3 state: Closed, Open, Half-Open) pada upstream LLM. Jika error berturut-turut mencapai threshold, putuskan koneksi sementara untuk menghindari pemborosan token dan biaya API.

Kerangka Postmortem Ringan Pasca Rollback

Sistem self-healing harus didukung pelaporan insiden yang ringkas untuk continuous improvement:

  1. Root Cause Identification: Apakah penyebabnya perubahan sistemik prompt, regresi library runtime, drift data input, atau degradasi upstream model?
  2. Impact Window: Berapa lama waktu sejak alert pertama hingga deployment kembali ke kondisi stabil?
  3. Data Isolation Check: Apakah ada side-effect atau state corruption yang berhasil lolos ke storage persistent sebelum rollback terjadi?