HolmesGPT untuk Alert Kubernetes: Runbook Mengalahkan Pilihan Model

Angka yang membuat saya berhenti bukan biayanya, melainkan 16 menjadi 2. Sebelum tim STCLab menulis exclusion rule, setiap investigasi HolmesGPT membuang 16 tool call untuk sistem yang tidak ada di cluster mereka. Sesudahnya tinggal dua. Tidak ada pergantian model di tulisan mereka yang menggeser angka sejauh itu.

Tulisan ini membaca dengan teliti artikel CNCF April 2026 karya Grace Park dan Ihyeok Song, lalu mencocokkan setiap mekanismenya dengan dokumentasi HolmesGPT yang saya ambil pada 2026-10-17. Saya belum menjalankan pipeline mereka. Di bagian yang tidak dijelaskan artikelnya, seperti isi tujuh runbook, saya menyebutkannya dan menandai sketsa buatan saya sebagai milik saya.

Dari alert ke thread Slack: pipeline dalam lima tahap

Tim SRE STCLab terdiri dari dua engineer dan menjalankan beberapa cluster Amazon EKS dengan workload produksi ber-traffic tinggi. Stack observability mereka adalah OpenTelemetry yang mengalirkan data ke Mimir, Loki, dan Tempo, dan Robusta OSS sudah memperkaya alert Prometheus lalu mengirimnya ke Slack. Triage manual memakan 15 sampai 20 menit per alert, jadi targetnya adalah analisis pertama yang tertulis di thread Slack yang sama.

Dua angka menggambarkan hasilnya. Sekitar 40 alert mentah per hari menyusut menjadi sekitar 12 investigasi unik, dan engineer membaca ringkasan di thread dalam waktu kurang dari dua menit, bukan 15 sampai 20 menit triage manual. Sekitar 40 persen investigasi selesai dengan sendirinya, kebanyakan pola yang sudah dikenal seperti OOMKilled dan ImagePullBackOff yang cocok dengan sebuah runbook. Semua angka ini berasal dari tim itu sendiri, dilaporkan sekali, tanpa pengukuran independen.

Runbook menggeser skor lebih jauh daripada model

Bukti terkuat artikel itu adalah perbandingan terkontrol pada model yang sama. Pada alert handshake ClickHouse, Holmes dengan runbook menemukan pola yang dikenal dalam 3 sampai 4 tool call. Tanpa runbook, Holmes mengejar tiga hipotesis yang tidak berhubungan dan memakai 20 langkah atau lebih. Anggaran 12 langkah sudah cukup dengan runbook.

Baca baris terakhir dengan teliti: baris itu membandingkan sebelum dan sesudah exclusion rule, bukan runbook melawan tanpa runbook, dan artikel mengaitkan peningkatannya dengan aturan seperti tidak ada Loki, tidak ada Tempo, dan tidak ada Istio di sini. Artikel tidak menjelaskan bagaimana skor 4,6 dan 3,6 dihasilkan, jadi anggap itu arah, bukan benchmark. Dokumentasi HolmesGPT sendiri menjelaskan lebih dari 150 eval yang dinilai terhadap daftar pernyataan yang diharapkan, dan harness seperti itulah yang Anda perlukan untuk mereproduksi hasil ini pada alert Anda sendiri.

Isi sebenarnya dari sebuah runbook

Artikel menyebut setiap runbook adalah file markdown dengan header Meta berisi field scope, tools, dan caution, dan Holmes memanggil fetch_runbook di awal untuk mengetahui tool mana yang dipakai atau dilewati. Contoh scope dan caution-nya adalah scope khusus satu namespace dan catatan bahwa sebagian container dikecualikan dari pengumpulan log. Artikel tidak menerbitkan ketujuh runbook itu, jadi file di bawah ini adalah rekonstruksi saya dari field yang dijelaskan, bukan milik mereka.

## Meta
scope: namespace=payments only
tools: kubernetes, prometheus
caution: the batch-export containers are excluded from log collection,
         so an empty Loki result for them means nothing

## Do not use
Loki, Tempo and Istio are not deployed in this cluster. Do not query them.

## Alert: KubePodCrashLooping
1. Read the last termination reason from the pod status.
2. OOMKilled: compare the memory limit with the working set in Prometheus.
3. ImagePullBackOff: read the image tag and the pull secret, nothing else.
4. Stop at three tool calls unless the reason is none of the above.

Di Holmes terbaru pengetahuan yang sama berbentuk skill: sebuah direktori berisi SKILL.md, frontmatter YAML dengan description yang wajib ada, dan bagian yang direkomendasikan bernama Goal, Workflow, Synthesize Findings, dan Recommended Remediation Steps. Description inilah yang dicocokkan model dengan alert, jadi harus menyebut masalah yang konkret. Berikut runbook crash-loop yang sama dalam bentuk itu, lagi-lagi contoh buatan saya.

---
name: payments-crashloop-triage
description: Pods crash-looping in the payments namespace on the production cluster
last_updated: 2026-10-17
---

## Goal
Name the termination reason and the one change that fixes it.

## Workflow
1. Do not query Loki, Tempo or Istio: none are deployed here.
2. Read the pod status for the last termination reason.
3. OOMKilled: compare the memory limit with usage in Prometheus.

## Synthesize Findings
State the reason, the evidence, and what you did not check.

## Recommended Remediation Steps
- Owner: payments team, #payments-oncall. Escalate to the SRE lead.

Perhatikan untuk apa kedua file itu memakai kata-katanya: apa yang dilewati, kapan berhenti, dan siapa pemilik masalahnya. Tidak ada prompting yang pintar di sini. Isinya adalah pengetahuan yang dibawa seorang engineer senior tentang satu cluster ini, ditulis di tempat yang dibaca agent sebelum memilih tool.

Runbook menjadi skill: apa yang berubah jika Anda mulai hari ini

Dokumentasi HolmesGPT saat ini menyebut skill sebagai pengganti runbook, tersedia sejak Holmes 0.26.0, sedangkan versi sebelumnya memakai sistem runbook lama. Saya tidak bisa memastikan versi mana yang dipakai STCLab, dan halaman dokumentasi tidak menyebut fetch_runbook sama sekali, jadi saya menganggap keduanya sebagai ide yang sama dalam dua generasi, bukan mengklaim bagaimana keduanya dipetakan satu per satu.

Konsekuensi praktisnya, skill hidup di repo Git dengan proses review, dan di situlah basis pengetahuan tujuh file seharusnya berada. Dokumentasi menambahkan bahwa Holmes bisa membuat draf skill dari investigasi yang sudah selesai, tetapi hasilnya perlu direview sebelum di-commit, karena skill hasil generate yang tidak direview bisa berisi langkah yang salah.

Glue code adalah tempat pipeline ini benar-benar bekerja

Pelajaran STCLab di sini, Holmes menangani penalaran dan sekitar 200 baris Python menangani sisanya: menemukan thread Slack yang sudah dibuat Robusta, meniru routing namespace-ke-channel miliknya, dan membuat fingerprint alert di level workload supaya alert berulang ditahan selama 30 menit saat rollout. Kunci di level workload penting karena rollout mengganti nama setiap pod. Ini sketsa saya untuk aturan tersebut, bukan playbook mereka.

# My sketch of the dedup rule, not STCLab's code. Their playbook is about
# 200 lines of Python inside Robusta and also finds the Slack thread and
# replicates the namespace-to-channel routing.
import time

SUPPRESS_SECONDS = 30 * 60  # the 30-minute window from the CNCF write-up
_last_seen: dict[str, float] = {}


def workload_fingerprint(labels: dict[str, str]) -> str:
    # Wrong: key on the pod name. A rollout renames every pod, so every
    # replacement looks like a brand-new alert and the window never holds.
    # Right: key on the owning workload plus the alert name.
    workload = (
        labels.get("deployment")
        or labels.get("statefulset")
        or labels.get("daemonset")
        or labels.get("pod", "unknown")
    )
    return "|".join([labels.get("namespace", "-"), workload, labels["alertname"]])


def should_investigate(labels: dict[str, str], now: float | None = None) -> bool:
    now = time.time() if now is None else now
    fp = workload_fingerprint(labels)
    if now - _last_seen.get(fp, 0.0) < SUPPRESS_SECONDS:
        return False  # same workload, same alert, still inside the window
    _last_seen[fp] = now
    return True


# In-memory state dies with the process. A restart mid-rollout lets one
# duplicate through; persist the map if that costs you more than it saves.

Deduplikasi itulah garis antara 40 alert mentah dan 12 investigasi, sehingga juga antara tagihan yang bisa diabaikan dan yang harus dipantau. Artikel menyebut biayanya sekitar 0,04 dolar per investigasi, kira-kira 12 dolar per bulan, dan saya menganggap keduanya angka dari tim itu sendiri, bukan sesuatu yang saya ukur.

Mereproduksi langkah pertama di Alertmanager Anda sendiri

Anda tidak membutuhkan playbook mereka untuk melihat Holmes bernalar atas alert sungguhan. Walkthrough Holmes melakukan port-forward ke Alertmanager, secara opsional mengirim alert uji KubePodCrashLooping, lalu menjalankan holmes investigate alertmanager dengan filter. Konfigurasi skill dan Slack token di bawah disalin dari halaman skills dan operator.

# 1. Reach Alertmanager (the Holmes walkthrough does it this way)
kubectl port-forward svc/<Your-Alertmanager-Service> 9093:9093

# 2. Investigate every active alert, or narrow it down
holmes investigate alertmanager --alertmanager-url http://localhost:9093
holmes investigate alertmanager --alertmanager-url http://localhost:9093 \
  --alertmanager-alertname "KubePodCrashLooping"
holmes investigate alertmanager --alertmanager-url http://localhost:9093 \
  --alertmanager-label "namespace=production"

# 3. Give Holmes your skills (Holmes 0.26.0 or later), ~/.holmes/config.yaml
cat >> ~/.holmes/config.yaml <<'EOF'
skill_repos:
  - url: https://github.com/<org>/<repo>.git
    branch: main
    sub_path: skills
    token_env: GITHUB_SKILLS_TOKEN
EOF

# 4. In-cluster, post operator results to Slack (Helm values.yaml)
#    additionalEnvVars:
#      - name: SLACK_TOKEN
#        valueFrom:
#          secretKeyRef:
#            name: holmes-secrets
#            key: slack-token

Ini adalah jalur CLI dan jalur operator, dan keduanya terpisah. Tujuan Slack di dokumentasi operator berlaku untuk health check dalam mode alert dan melaporkan sent, failed, atau skipped per tujuan. Jalur itu tidak memberi perilaku balasan-di-thread seperti playbook STCLab, dan itulah alasan glue code tersebut ada.

Di mana semuanya gagal: berburu model dan pengetahuan yang basi

Bagian paling berguna dari artikel itu adalah daftar model yang gagal, karena menunjukkan bahwa keandalan tool calling dan infrastruktur adalah masalah pertama, bukan kualitas penalaran.

Syarat tim itu adalah output bahasa Korea, format Slack, pengambilan runbook, dan korelasi log lintas cluster, dan itu sebabnya hanya satu keluarga model yang lolos. Mereka berakhir dengan model self-hosted di staging dan API terkelola di produksi, diganti lewat satu blok konfigurasi model dengan temperature 0, dan mereka mengganti backend tiga kali tanpa mengubah pipeline. Satu perbaikan upstream, perubahan tiga baris untuk autentikasi pod identity, di-merge sebagai PR 1850.

Satu batas lagi pada buktinya: ini cerita tim dua orang di cluster mereka sendiri, dalam bahasa Korea, dengan playbook kustom. Tidak ada yang menunjukkan angka yang sama pada alert Anda, dan itulah alasan langkah pertama hari Senin adalah mengukur baseline Anda sendiri.

Yang dikerjakan hari Senin

Kerjakan berurutan. Masing-masing kecil, dan yang pertama memberi tahu apakah sisanya layak dikerjakan.

1. Jalankan satu alert sungguhan lewat holmes investigate dan hitung tool call yang menyentuh sistem yang tidak Anda jalankan. Hitungan itu adalah versi Anda dari angka 16.
2. Tulis satu skill untuk alert paling berisik dengan description yang spesifik, daftar jangan-dipakai, kondisi berhenti, dan pemilik. Jauhkan secret darinya.
3. Taruh skill di repo Git, arahkan skill_repos ke sana, dan tambahkan field last_updated dengan review per kuartal supaya pengetahuan yang basi dihapus.
4. Atur TOOL_MEMORY_LIMIT_MB dengan sengaja dan naikkan batas memori pod agar sepadan, lalu tambahkan deduplikasi level workload sebelum ada yang diposting ke channel.
5. Simpan model dalam satu blok konfigurasi dan jalankan ulang alert yang sama saat menggantinya, sehingga pergantian model berupa selisih hasil, bukan pipeline baru.

# Step 1: find your wasted tool calls before writing a single skill.
# Run one real alert and count the tool calls Holmes makes that touch a
# system you do not run. Each one is a line for the "do not use" section.
holmes investigate alertmanager --alertmanager-url http://localhost:9093 \
  --alertmanager-alertname "KubePodCrashLooping"

# Step 4: cap tool subprocess memory, and raise the pod limit to match.
export TOOL_MEMORY_LIMIT_MB=2000   # default is 800 MB on x86_64

Langkah berikutnya di artikel, yaitu mengalirkan metrik jaringan eBPF seperti TCP retransmit dan latensi koneksi dari Inspektor Gadget ke Prometheus, adalah jenis perluasan yang tepat: lebih banyak bukti untuk agent, dengan disiplin runbook yang sama di sekelilingnya.

Aturan yang saya ambil dari sini: sebelum memilih model untuk agent triage alert, tuliskan apa yang tidak ada di cluster Anda dan seperti apa kegagalan yang sudah dikenal. Runbook STCLab hanya butuh beberapa file markdown dan, menurut cerita tim itu sendiri, lebih penting daripada pergantian model. Perlakukan pengetahuan itu seperti kode, review, dan biarkan model tetap bisa diganti.