Belajar Vault - Observability, Monitoring & Troubleshooting

#Pendahuluan

Setelah di episode 23 sebelumnya kita memisahkan tenant dan memahami batas Open Source vs Enterprise — pada episode kali ini kita memasuki mata pelajaran yang paling dekat dengan pekerjaan sehari-hari seorang DevOps/SRE yang benar-benar mengoperasikan Vault: Observability, Monitoring & Troubleshooting.

Ada sebuah fakta yang sering tidak disadari sampai terjadi insiden: Vault bisa saja mati tanpa kalian sadari. Vault yang sealed tidak mengirim alarm — ia hanya mulai menolak request. Aplikasi yang mencoba login akan dapat error, dan kalian baru tahu setelah user mengeluh. Pada saat itu, sudah berapa menit production tanpa secret? Sebuah sistem monitoring yang baik menjawab pertanyaan ini lebih awal: "Vault baru saja sealed pada pukul 02:15 — kami sudah membunyikan alarm dan sedang mengatasinya."

Episode ini akan membekali kalian dengan tiga hal: telemetry — bagaimana mengekspos metrik Vault ke Prometheus dan memvisualisasikannya di Grafana; perintah diagnostik — toolbox operator untuk memeriksa kesehatan cluster dari CLI; dan troubleshooting — tabel praktis gejala-ke-penyebab-ke-solusi untuk masalah paling umum yang kita jumpai di lapangan, dari token expired hingga split-brain.

#Pembahasan Utama

#Telemetry Vault: Mengekspos Metrik untuk Prometheus

Vault mengumpulkan metrik internal yang bisa diekspos melalui telemetry. Dengan mengaktifkan blok telemetry di konfigurasi, Vault menyediakan endpoint /v1/sys/metrics dalam format Prometheus — yang bisa langsung di-scrape oleh Prometheus tanpa exporter tambahan.

telemetry {
  prometheus_retention_time = "24h"
  disable_hostname          = true
  unauthenticated_metrics_access = false
}
 
storage "raft" {
  path   = "/opt/vault/data"
  node_id = "vault-node-1"
 
  retry_join {
    leader_api_addr = "https://10.0.0.11:8200"
  }
}
 
listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_disable   = false
  tls_cert_file = "/etc/vault.d/tls/vault.crt"
  tls_key_file  = "/etc/vault.d/tls/vault.key"
}

Beberapa opsi penting:

• prometheus_retention_time — berapa lama Vault menyimpan metrik di memori sebelum bisa dibaca. Nilai "24h" cukup untuk scrape berkala.
• disable_hostname = true — membersihkan label hostname agar metrik antar node mudah di-agregasi (rekomendasi umum di deployment container/VM).
• unauthenticated_metrics_access = false — memaksa request metrik butuh token. Kalian bisa mengaktifkannya tanpa token hanya jika endpoint benar-benar terisolasi jaringan; di kebanyakan produksi, aktifkan autentikasi lalu sediakan token khusus untuk Prometheus.

Setelah restart, uji endpoint dari node yang sama:

curl -s -H "X-Vault-Token: $VAULT_TOKEN" \
  https://10.0.0.11:8200/v1/sys/metrics?format=prometheus | head -30

# HELP vault_core_unsealed Whether the vault is sealed.
# TYPE vault_core_unsealed gauge
vault_core_unsealed 1
 
# HELP vault_core_active_nodes Number of nodes active.
# TYPE vault_core_active_nodes gauge
vault_core_active_nodes 1
 
# HELP vault_raft_leader_last_contact Last contact with leader (ms).
# TYPE vault_raft_leader_last_contact gauge
vault_raft_leader_last_contact 0
 
# HELP vault_api_srv_http_request_count Count of API requests.
# TYPE vault_api_srv_http_request_count counter
vault_api_srv_http_request_count{code="200",method="read",operation="read",path="secret/data/app"} 42

#Metrik Kunci yang Wajib Dimonitor

Berikut metrik inti beserta artinya:

#Konfigurasi Prometheus untuk Scrape Vault

Prometheus perlu diarahkan ke ketiga node cluster (jangan hanya leader — setiap node mengekspos metriknya sendiri, dan follower punya metrik Raft yang penting):

- job_name: 'vault'
  metrics_path: '/v1/sys/metrics'
  params:
    format: ['prometheus']
  scheme: https
  scrape_interval: 15s
  static_configs:
    - targets:
        - '10.0.0.11:8200'
        - '10.0.0.12:8200'
        - '10.0.0.13:8200'
      labels:
        namespace: 'vault-cluster'
  authorization:
    credentials_file: /etc/prometheus/vault-token

Dengan Grafana, buat dashboard yang menampilkan setidaknya: status unseal (per node), node active, raft leader last contact, request rate, dan p95 latency. HashiCorp menyediakan dashboard referensi yang bisa kalian impor, dan komunitas punya banyak dashboard open source untuk Vault — tapi selalu verifikasi metriknya sesuai versi Vault kalian.

#Alert Rules yang Wajib Ada

Dashboard hanya berguna jika ada mata yang melihatnya. Karena itu, definisikan alert rules untuk skenario yang mengancam ketersediaan. Berikut contoh rules.yaml untuk Prometheus/Alertmanager yang mengikuti tabel metrik di atas:

groups:
  - name: vault.rules
    rules:
      - alert: VaultSealed
        expr: vault_core_unsealed == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Vault node sealed"
          description: "Vault node {{ $labels.instance }} dalam keadaan sealed lebih dari 1 menit."
 
      - alert: VaultClusterDown
        expr: vault_core_active_nodes == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Tidak ada active node"
          description: "Tidak ada node Vault yang active — seluruh cluster tidak melayani request."
 
      - alert: VaultLeaderContactLost
        expr: vault_raft_leader_last_contact > 3000
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "Kontak leader hilang"
          description: "Node {{ $labels.instance }} tidak menerima heartbeat leader > 3 detik."

#Perintah Diagnostik Ops (Toolbox Operator)

Selain metrik, operator butuh perintah cepat untuk diagnosis langsung. Ini toolkit-nya:

# 1. Status dasar + detail
vault status
vault status -detailed
 
# 2. Kesehatan cluster Raft
vault operator raft list-peers
vault operator raft read-config
 
# 3. Informasi seal (apakah auto-unseal aktif?)
vault operator seal-status

Key                      Value
---                      -----
Recovery Seal Type       awskms
Initialized              true
Sealed                   false
Total Recovery Shares    5
Threshold                3
Verification Required    false
Version                  1.18.4
Storage Type             raft
HA Enabled               true
HA Mode                  standby

Perhatikan baris Recovery Seal Type awskms — dari sinilah kalian bisa mengonfirmasi bahwa auto-unseal (episode 21) aktif, dan HA Mode standby menunjukkan node ini sedang follower.

vault operator raft read-config

{
  "storage": {
    "raft": {
      "node_id": "vault-node-2",
      "path": "/opt/vault/data",
      "retry_join": [
        { "leader_api_addr": "https://10.0.0.11:8200" },
        { "leader_api_addr": "https://10.0.0.12:8200" },
        { "leader_api_addr": "https://10.0.0.13:8200" }
      ],
      "max_entry_size": 1048576
    }
  }
}

#vault debug: Satu Perintah untuk Semua Log

Ketika insiden benar-benar terjadi, kalian tidak akan punya waktu membaca log satu per satu. Vault menyediakan vault debug — sebuah perintah yang mengumpulkan log, konfigurasi, status, snapshot, dan informasi performance ke dalam satu bundle zip yang bisa langsung di-share ke tim atau dibuka untuk analisis:

vault debug -duration=60s -interval=10s -output=/tmp/vault-debug.zip

Collecting debug data...    https://vault.internal:8200
==> Temporary directory created for storage of collected data
    /tmp/vault-debug/
==> Bundled debug file written to
    /tmp/vault-debug.zip

Bundle ini berisi: health status, seal-status, config yang di-redact, log Vault, dan sampel CPU/memori. vault debug adalah cara tercepat untuk memberi gambaran lengkap ke kolega atau dukungan — jauh lebih baik daripada menyalin potongan log secara manual.

#Troubleshooting Masalah Umum di Lapangan

Berikut peta praktis gejala → kemungkinan penyebab → solusi, berdasarkan pengalaman nyata mengoperasikan Vault:

#Studi Kasus Singkat: Token permission denied

Salah satu insiden paling umum di lapangan adalah aplikasi yang tiba-tiba dapat permission denied. Mari telusuri dengan alat yang sudah kita pelajari:

# 1. Apakah token masih hidup dan kapan expired?
vault token lookup
 
# 2. Capability apa yang dimiliki token pada path tertentu?
vault token capabilities my-token-id secret/data/app
 
# 3. Jika token valid tapi capability kurang — bandingkan dengan policy
vault policy read backend-app
 
# 4. Cek apakah masalahnya namespace (token dibuat di namespace berbeda?)
vault token lookup -namespace=backend my-token-id

Key            Value
---            -----
id             hvs.CAES...
policies       [default backend-app]
expire_time    2026-08-02T11:30:00Z
ttl            1h
type           service

Alur logika ini — cek kesehatan cluster dulu, lalu cek token, policy, dan namespace — menyelamatkan kalian dari berjam-jam menebak. Sembilan dari sepuluh kasus permission denied di Vault adalah salah satu dari: token expired, policy kurang capability, atau token dibuat di namespace yang berbeda dari yang kalian pikir.

#Kesalahan Umum (Common Pitfalls) dalam Monitoring

#Penutup

Pada episode 24 ini kita telah membangun kemampuan observasi dan troubleshooting Vault secara menyeluruh: telemetry — mengekspos metrik seperti vault_core_unsealed, vault_raft_leader_last_contact, dan latensi request lewat blok telemetry dan scrape Prometheus; toolbox diagnostik — vault status, vault operator raft list-peers, vault operator raft read-config, vault debug untuk mengumpulkan bundle lengkap saat insiden; serta peta troubleshooting untuk masalah paling umum dari sealed vault, policy mismatch, token expired, quorum loss, sampai kegagalan LDAP/OIDC. Jangan lupa: monitoring terbaik sekalipun tidak berguna tanpa alarm yang tepat dan runbook yang terlatih.

Kalian sekarang memiliki seluruh bahan teknis untuk mengoperasikan Vault di produksi. Namun kalian mungkin bertanya: bagaimana semua ini dirangkai menjadi satu sistem nyata? Bagaimana cluster HA yang kita bangun di episode 20, auto-unseal di 21, hardening di 22, multi-tenancy di 23, dan observability di 24 bekerja bersama untuk sebuah perusahaan sungguhan? Jawabannya ada di episode terakhir kita: Studi Kasus Complete Production-Grade Vault Architecture — tempat kita merangkai semuanya menjadi arsitektur enterprise end-to-end. Ini puncak dari seluruh perjalanan! 🏔️