Belajar Cron Job - Notifikasi & Alerting

#Pendahuluan

Di episode 11 kita menyebar beban agar semua job selesai tepat waktu. Tetapi ada satu pertanyaan yang belum dijawab: bagaimana kalian tahu sebuah job gagal? Job yang gagal diam-diam adalah salah satu bahaya terbesar dalam otomasi — sistem tampak berjalan normal, backup tidak pernah terjadi, dan baru ketahuan saat data hilang. Episode ini membangun lapisan notifikasi dan alerting yang tepat: informatif, tepat sasaran, dan tidak bising.

#MAILTO: Notifikasi via Email

Dari episode 5, output job cron bisa dikirim lewat email dengan MAILTO:

MAILTO=ops@example.com
 
30 2 * * * /usr/local/bin/backup.sh

#Variasi MAILTO per Job

MAILTO bisa di-set per baris dengan meletakkan sebelum perintah:

SHELL=/bin/bash
MAILTO=ops@example.com
 
30 2 * * * /usr/local/bin/backup.sh
15 3 * * * MAILTO=dba@example.com /usr/local/bin/pg_dump.sh

Pola ini berguna saat job yang berbeda ditangani tim yang berbeda.

#Notifikasi ke Slack/Telegram via curl

#Webhook Slack

Slack punya Incoming Webhook — URL yang menerima JSON dan mempostingnya ke channel:

#!/bin/bash
WEBHOOK_URL="https://hooks.slack.com/services/T000/B000/XXX"
curl -fsS -X POST -H 'Content-type: application/json' \
  --data '{"text":"GAGAL: backup tanggal '"$(date +%F)"'"}' \
  "$WEBHOOK_URL"

#Bot Telegram

Telegram memakai Bot API dengan token bot dan chat-id:

#!/bin/bash
TOKEN="123456:ABC-DEF..."
CHAT_ID="-100123456789"
curl -fsS "https://api.telegram.org/bot${TOKEN}/sendMessage" \
  --data-urlencode "chat_id=${CHAT_ID}" \
  --data-urlencode "text=GAGAL: backup $(date +%F)"

#On-Failure Alert: Hanya Ganggu Saat Gagal

Alerting yang baik hanya berbunyi saat exit code != 0. Jika kalian mengirim notifikasi di setiap keberhasilan, tim akan kehilangan sensitivitas terhadap pesan — "alert fatigue". Kirim sukses hanya untuk job yang memang perlu konfirmasi visual:

#!/bin/bash
set -uo pipefail
 
LOG=/var/log/backup.log
echo "=== Backup $(date) ===" >> "$LOG"
 
if /usr/local/bin/backup.sh >> "$LOG" 2>&1; then
    echo "OK" >> "$LOG"
else
    echo "GAGAL (exit $?)" >> "$LOG"
    curl -fsS "$WEBHOOK_URL" -H 'Content-type: application/json' \
        --data '{"text":"GAGAL backup: '"$(date)"'"}' || true
    exit 1
fi

Perhatikan || true pada curl — alert yang gagal tidak boleh mengubah status job. Dengan pola ini, alert adalah sinyal kegagalan murni:

• Exit 0 → sukses, tidak ada alert.
• Exit != 0 → gagal, kirim alert.
• Retry internal yang akhirnya sukses → exit 0, tidak perlu alert.

#Integrasi Monitoring: Zabbix dan Prometheus

#Zabbix: Trapper Items

Zabbix mendukung sender — host mengirim nilai metrik secara push, dan alert dipicu saat nilai melebihi ambang (misal duration > 3600 detik):

zabbix_sender -z zabbix.example.com -s "host-db" -k "backup.duration" -o 42

#Prometheus: Pushgateway

Prometheus umumnya pull (scrape), tetapi untuk job sekali-jalan dipakai Pushgateway:

cat <<EOF | curl -fsS --data-binary @- http://pushgw:9091/metrics/job/backup/instance/host-db
# TYPE backup_success gauge
backup_success 0
EOF

Alert rule di Prometheus bisa mendeteksi backup_success == 0 atau metrik yang tidak muncul sama sekali (missed job — dibahas di episode 20).

#Ringkasan Saluran Notifikasi

#Penutup

Inti yang harus dibawa pulang:

• MAILTO mengirim output job via email; bisa di-set per job.
• Slack/Telegram via curl memberi notifikasi real-time.
• On-failure alert: kirim hanya saat exit code != 0, cegah alert fatigue.
• Guard alert dengan || true agar notifikasi yang gagal tidak merusak status.
• Integrasikan Zabbix sender / Prometheus Pushgateway untuk metrik + alerting.

Di episode 13 selanjutnya kita memasuki fase keamanan: keamanan crontab — allow/deny — bagaimana /etc/cron.allow dan /etc/cron.deny mengontrol siapa boleh membuat jadwal, kapan memakai default deny, dan mengapa job sebaiknya tidak dijalankan sebagai root tanpa alasan!