Shell Script Health Check dan Auto-Recovery di Linux Production (Panduan Praktis)

Target keyword: shell script health check linux production
Keyword cluster bulanan: linux automation reliability, shell scripting production, incident prevention
Weekly intent rotation: Problem-solving (how-to implementasi cepat + aman)

Kalau kamu sering pegang server Linux, pasti pernah ketemu momen begini: service tiba-tiba “hidup tapi nggak sehat”. Process masih jalan, tapi endpoint timeout. Atau job cron masih nulis log, tapi output-nya kosong karena dependency putus. Secara teknis service up, tapi secara bisnis udah down.

Di titik ini, shell script bukan cuma alat automasi kecil-kecilan. Dengan desain yang benar, shell script bisa jadi lapisan health check + auto-recovery yang ringan, cepat, dan cukup ampuh buat banyak skenario production.

Artikel ini bahas cara bikin flow yang aman:

cek kesehatan service secara bertahap,
ambil aksi recovery otomatis,
cegah recovery loop yang bikin makin rusak,
simpan jejak log yang enak diinvestigasi,
dan tetap SEO-friendly plus gampang dipraktikkan tim kecil.

Kenapa health check + auto-recovery itu penting?

Di production, gangguan jarang datang dalam bentuk crash total. Yang sering justru kondisi abu-abu:

proses jalan, tapi deadlock,
memory leak bikin response makin lambat,
dependency eksternal melambat lalu timeout,
queue numpuk karena worker “setengah hidup”.

Kalau nunggu manual intervention terus, MTTR (mean time to recovery) jadi panjang. Sementara kalau recovery otomatis terlalu agresif, bisa muncul restart storm dan downtime makin parah.

Tujuannya bukan “semua harus auto-fix”, tapi:

deteksi dini,
pulihkan kasus ringan otomatis,
eskalasi cepat kalau kasus berat.

Prinsip desain yang wajib sebelum nulis script

Sebelum coding, pastikan 5 prinsip ini beres:

Idempotent: script aman dijalankan berulang tanpa efek samping liar.
Bounded action: ada batas retry/restart per window waktu.
Observable: log jelas (CHECK, RECOVER, FAIL, ESCALATE).
Fail-safe: kalau ragu, jangan aksi destruktif otomatis.
Non-overlap: jangan biarkan 2 script recovery jalan bareng.

Untuk poin no-overlap, kamu bisa pakai flock seperti di artikel ini:
Mencegah Cron Job Tumpang Tindih di Linux dengan flock.

Arsitektur sederhana yang works di banyak tim

Pattern minimal yang saya rekomendasikan:

Health check berlapis
- Layer 1: process check (systemctl is-active)
- Layer 2: functional check (HTTP endpoint / command test)
- Layer 3: dependency check ringan (disk, DNS, port DB)
Recovery bertingkat
- Step A: soft action (reload/reconnect)
- Step B: restart service
- Step C: eskalasi alert + stop auto action sementara
Circuit breaker sederhana
- Kalau gagal terus dalam 15 menit, hentikan auto-restart
- Kirim alert agar manusia investigasi

Pattern ini cocok untuk service web kecil, worker internal, agent sinkronisasi, sampai ETL ringan berbasis shell.

Contoh implementasi script (siap adaptasi)

Berikut template practical yang bisa kamu pakai sebagai fondasi:

#!/usr/bin/env bash
set -euo pipefail

SERVICE_NAME="myapp-worker"
HEALTH_URL="http://127.0.0.1:8080/health"
LOCK_FILE="/var/lock/myapp-health.lock"
STATE_FILE="/var/tmp/myapp-recovery.state"
LOG_FILE="/var/log/myapp-healthcheck.log"
MAX_RECOVERY=3
WINDOW_SECONDS=900   # 15 menit

log() {
  echo "[$(date -Is)] $*" | tee -a "$LOG_FILE"
}

init_state() {
  if [[ ! -f "$STATE_FILE" ]]; then
    echo "0:0" > "$STATE_FILE" # count:window_start_epoch
  fi
}

read_state() {
  IFS=':' read -r RECOVERY_COUNT WINDOW_START < "$STATE_FILE"
}

write_state() {
  echo "${RECOVERY_COUNT}:${WINDOW_START}" > "$STATE_FILE"
}

reset_window_if_needed() {
  local now
  now=$(date +%s)
  if (( now - WINDOW_START > WINDOW_SECONDS )); then
    RECOVERY_COUNT=0
    WINDOW_START=$now
    write_state
  fi
}

is_service_active() {
  systemctl is-active --quiet "$SERVICE_NAME"
}

is_functional_ok() {
  curl -fsS --max-time 3 "$HEALTH_URL" >/dev/null
}

escalate() {
  log "ESCALATE: recovery limit tercapai. Butuh investigasi manual."
  # contoh integrasi:
  # /usr/local/bin/send-alert "[CRITICAL] $SERVICE_NAME unhealthy, recovery limit reached"
}

recover_once() {
  log "RECOVER: restart service $SERVICE_NAME"
  systemctl restart "$SERVICE_NAME"
  sleep 2
}

main() {
  exec 200>"$LOCK_FILE"
  if ! flock -n 200; then
    log "SKIP: health check masih berjalan (lock aktif)"
    exit 0
  fi

  init_state
  read_state
  reset_window_if_needed

  if is_service_active && is_functional_ok; then
    log "OK: service sehat"
    exit 0
  fi

  log "WARN: service tidak sehat, mulai recovery"

  if (( RECOVERY_COUNT >= MAX_RECOVERY )); then
    escalate
    exit 1
  fi

  recover_once
  RECOVERY_COUNT=$((RECOVERY_COUNT + 1))
  write_state

  if is_service_active && is_functional_ok; then
    log "RECOVERED: service kembali sehat (attempt=$RECOVERY_COUNT)"
    exit 0
  fi

  log "FAIL: recovery belum berhasil (attempt=$RECOVERY_COUNT)"
  if (( RECOVERY_COUNT >= MAX_RECOVERY )); then
    escalate
  fi
  exit 1
}

main "$@"

Cara jadwalkan aman via cron

Jangan jalankan tanpa lock. Gunakan cron seperti ini:

*/2 * * * * /usr/bin/flock -n /var/lock/myapp-health.lock /usr/local/bin/myapp-healthcheck.sh >> /var/log/myapp-healthcheck.log 2>&1

Kenapa tetap flock di cron padahal script sudah lock internal? Supaya ada double safety kalau suatu saat script berubah atau dipanggil dari entrypoint lain.

Kalau kamu lagi bangun fondasi shell automation yang lebih rapi, lanjut baca juga:
Shell Script Retry, Backoff, Timeout Patterns Linux Automation dan
Idempotent Shell Script: Jalankan Berkali-kali Tanpa Berantakan.

Anti-pattern yang sering bikin recovery gagal

1) Check cuma process, bukan fungsi

systemctl is-active itu perlu, tapi belum cukup. Service bisa active tapi endpoint mati. Selalu tambah functional check.

2) Restart tanpa batas

Kalau dependency utama mati (mis. DB down), restart service berkali-kali cuma buang resource. Wajib ada retry budget atau batas recovery per window.

3) Tidak ada timeout

Health check tanpa timeout bisa nge-hang dan bikin job overlap. Selalu set timeout ketat (curl --max-time, timeout command, dsb).

4) Logging minim

Log “error” doang nggak cukup. Catat state transisi: CHECK_FAIL, RECOVER_START, RECOVER_DONE, ESCALATE.

5) Recovery terlalu destruktif

Hindari auto tindakan berisiko tinggi (hapus file data, rotate credential, migrasi schema) tanpa guardrail dan approval.

Integrasi observability biar nggak “silent failure”

Minimal, tambahkan 3 metrik sederhana:

healthcheck_fail_total
recovery_attempt_total
recovery_escalation_total

Kalau belum punya stack metrics, parse dari log pun cukup untuk tahap awal. Yang penting tim bisa jawab pertanyaan ini setiap incident:

Gagalnya sejak kapan?
Sudah berapa kali auto-recover?
Recovery berhasil atau cuma muter di loop?

Untuk debugging shell script lebih cepat saat incident, kamu bisa refer ke:
Debug Shell Script Linux Production: Teknik Cepat Menemukan Error.

Kapan harus stop auto-recovery dan naikkan ke manual?

Gunakan rule praktis ini:

Kasus ringan berulang < 3x/15 menit → auto-recover masih oke.
Lebih dari itu → stop auto action, eskalasi ke on-call.
Ada indikasi data corruption/security issue → langsung manual incident mode.

Ingat: auto-recovery yang baik itu bukan yang paling agresif, tapi yang paling terukur dan aman.

Checklist deploy ke production

Sebelum aktif di semua host, cek ini dulu:

Script pakai set -euo pipefail
Semua command pakai absolute path bila perlu
Health check punya timeout
Recovery punya batas attempt per window
Ada lock (flock) untuk cegah overlap
Log tersimpan dan bisa dipantau
Ada jalur eskalasi alert
Sudah dites skenario dependency down (staging)

Kalau pengen baseline shell script makin kuat, kamu juga bisa gabungkan dengan praktik di:
Bash Strict Mode and Safe Automation Checklist for Linux Servers.

FAQ

1) Apakah auto-recovery cocok untuk semua service Linux?

Nggak semua. Cocok untuk gangguan operasional ringan dan berulang (hang sementara, timeout intermiten). Untuk sistem dengan risiko data tinggi, recovery harus lebih ketat dan sering butuh approval manual.

2) Lebih baik pakai cron atau systemd timer?

Dua-duanya bisa. Kalau sudah heavily systemd, timer + unit dependency sering lebih rapi. Kalau existing workflow berbasis cron, tetap valid asalkan pakai lock, timeout, dan logging yang disiplin.

3) Perlu simpan state recovery di mana?

Untuk single-host, file state lokal cukup (/var/tmp atau /run). Untuk multi-host, lebih aman pakai state terpusat (Redis/DB) agar keputusan recovery konsisten lintas node.

4) Bagaimana bedakan “service lambat” vs “service rusak”?

Gunakan multi-layer check: process + functional endpoint + latency threshold. Jangan langsung restart hanya karena satu timeout acak.

FAQ Schema-ready (JSON-LD)

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "Apakah auto-recovery cocok untuk semua service Linux?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Tidak selalu. Auto-recovery paling cocok untuk gangguan operasional ringan dan berulang. Untuk sistem berisiko data tinggi, perlu guardrail ketat dan sering membutuhkan approval manual."
        }
      },
      {
        "@type": "Question",
        "name": "Lebih baik pakai cron atau systemd timer?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Keduanya bisa. Cron cocok untuk workflow sederhana, sedangkan systemd timer sering lebih kuat untuk dependency dan kontrol service. Apa pun pilihannya, tetap gunakan lock, timeout, dan logging."
        }
      },
      {
        "@type": "Question",
        "name": "Perlu simpan state recovery di mana?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Single-host cukup file state lokal seperti /var/tmp. Multi-host sebaiknya pakai state terpusat seperti Redis atau database agar konsisten lintas node."
        }
      },
      {
        "@type": "Question",
        "name": "Bagaimana membedakan service lambat dan service rusak?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Gunakan health check berlapis: status process, endpoint fungsional, dan ambang latency. Hindari restart otomatis hanya karena satu timeout acak."
        }
      }
    ]
  }
</script>

Penutup

Kalau kamu cari quick win reliability di Linux production, kombinasi health check berlapis + auto-recovery terukur + anti-overlap lock adalah langkah yang sangat worth it. Mulai dari 1 service paling sering bikin gangguan, ukur hasilnya 1–2 minggu, lalu replikasi pattern ke service lain.

Kuncinya sederhana: jangan kejar auto-recovery yang paling “galak”, tapi yang stabil, bisa diaudit, dan aman untuk bisnis.

Runbook mini saat incident (biar tim nggak panik)

Saat alert masuk jam rawan (malam/dini hari), runbook sederhana ini sangat membantu supaya respons tetap konsisten:

Konfirmasi gejala utama
Cek metrik/error log 5–10 menit terakhir. Pastikan benar ada degradasi, bukan false alarm.
Cek status auto-recovery
Lihat log script: apakah recovery sudah dilakukan? Berapa kali? Apakah sudah kena limit?
Validasi dependency
Ping service upstream (DB, Redis, API eksternal). Banyak kasus gagal recover bukan dari servicenya, tapi dari dependency yang masih gangguan.
Ambil keputusan cepat
- Jika recover sukses dan stabil: lanjut monitor ketat 15–30 menit.
- Jika flapping berulang: matikan auto-recovery sementara, pindah ke investigasi manual.
Catat timeline singkat
Simpan waktu kejadian, aksi yang dilakukan, dan hasilnya. Ini penting untuk postmortem dan tuning threshold berikutnya.

Dengan runbook ini, tim on-call jadi punya jalur keputusan yang jelas, bukan trial-and-error di tengah tekanan.

Validasi pasca-recovery: jangan berhenti di “service up”

Kesalahan umum setelah restart berhasil adalah langsung menganggap incident selesai. Padahal bisa saja service kembali up, tapi kualitas layanan belum normal.

Lakukan verifikasi cepat berikut:

Latency check: bandingkan P95/P99 sebelum dan sesudah recovery.
Error rate check: pastikan 5xx/timeout turun signifikan.
Queue/backlog check: lihat apakah antrean mulai turun, bukan makin naik.
Business sanity check: pastikan transaksi/pekerjaan penting benar-benar jalan.

Kalau salah satu indikator belum membaik dalam window observasi (mis. 10–15 menit), jangan tunda eskalasi. Lebih baik naikkan lebih cepat daripada membiarkan sistem terlihat “hijau palsu”.

Praktik ini juga bikin auto-recovery kamu makin matang dari waktu ke waktu: setiap incident menghasilkan data untuk menyetel threshold lebih tepat, bukan sekadar feeling.