Belajar Data Center Engineer - Monitoring & DCIM

#Pendahuluan

Setelah di episode 9 kita mengunci pintu-pintu fasilitas, sekarang kita memasang matanya: monitoring & DCIM. Data center yang tidak termonitor bukan fasilitas — melainkan museum kejutan. Suhu naik dua jam tanpa ada yang sadar, UPS pindah ke baterai karena satu fase drop, PDU rack mendekati breaker limit — semuanya bisu tanpa sistem pengamatan.

Dua kata kuncinya sering dicampur, padahal beda: DCIM (Data Center Infrastructure Management) mengelola aset & kapasitas fisik; monitoring (Zabbix/Prometheus) mengawasi kondisi & metrik real-time. DC engineer profesional menjalankan keduanya sebagai satu kesatuan.

#Apa Itu DCIM?

DCIM adalah lapisan software yang menjadi sumber kebenaran operasional fisik:

Di episode 0 kita sudah menyiapkan NetBox — open-source DCIM/IPAM paling populer. Ia tidak polling sensor real-time; ia mencatat struktur. Kondisi real-time datang dari monitoring, dan keduanya saling merujuk lewat nama device.

#Sensor: Mata Fisik Fasilitas

Sumber data lingkungan tersebar di banyak protokol:

Kita sudah praktik IPMI di episode 3-4. Sekarang contoh membaca UPS via NUT (Network UPS Tools):

sudo apt install nut-client
upsc ups@localhost

Baris output yang paling sering kalian butuhkan:

ups.load: 34
battery.runtime.low: 480
input.voltage: 228.0
output.voltage: 230.0
battery.charge: 100

ups.load di atas 70-80% berarti kapasitas UPS hampir habis — alarm kapasitas ini lebih penting daripada alarm "mati", karena ia memberi waktu berencana sebelum bencana.

#Merancang Alerting yang Tidak Melukai

Alerting yang buruk lebih berbahaya daripada tanpa alerting: tim jadi tuli (alert fatigue) dan insiden nyata tenggelam. Prinsip desain:

1. Tiga tingkat: info (dicatat saja) → warning (tindakan hari kerja) → critical (panggil orang sekarang).
2. Setiap critical punya runbook — alert tanpa instruksi respons hanyalah spam terstruktur.
3. Threshold dari baseline — jangan tebak; pakai data historis (episode 3 sudah kalian bangun).
4. Escalation chain tertulis — warning tak ditangani 30 menit → eskalasi ke lead → ke manager.

Contoh threshold awal yang wajar untuk data hall:

Inlet temp      : warning > 27°C   ; critical > 32°C
RH              : warning < 30% / > 70%
UPS load        : warning > 70%    ; critical > 85%
PDU bank load   : warning > 80% breaker rating
Battery runtime : warning < 10 menit pada beban saat itu

#Praktik: Setup Prometheus + snmp_exporter

Sekarang rakit pipeline monitoring open-source standar industri. Komponen: Prometheus (collect), snmp_exporter (jembatan SNMP), Grafana (visual).

docker run -d --name snmp-exporter -p 9116:9116 \
  prom/snmp-exporter:v0.26.0

Tambahkan target PDU/sensor ke konfigurasi scrape Prometheus (prometheus.yml):

global:
  scrape_interval: 60s
 
scrape_configs:
  - job_name: "dc-snmp"
    metrics_path: /snmp
    params:
      module: [if_mib]
    static_configs:
      - targets:
          - 10.10.10.9   # rack pdu a
          - 10.10.10.10  # rack pdu b
        labels:
          site: dc-jkt01
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: snmp-exporter:9116

Untuk metrik server, node_exporter + ipmi_exporter memberikan suhu/power per host. Lalu definisikan aturan alert pertama kalian (alerts.yml):

groups:
  - name: dc-environment
    rules:
      - alert: RackPDULoadHigh
        expr: snmp_pdu_bank_load_percent > 80
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Load PDU tinggi di {{ $labels.instance }}"
          runbook: https://docs.lab/runbooks/pdu-load.md
 
      - alert: UpsOnBattery
        expr: nut_ups_on_batt == 1
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "UPS {{ $labels.instance }} ON BATTERY"
          runbook: https://docs.lab/runbooks/ups-battery.md

Perhatikan field runbook — setiap alert langsung menunjuk prosedur. Reload konfigurasi dan uji:

curl -X POST http://localhost:9090/-/reload
curl -s http://localhost:9090/api/v1/rules | python3 -m json.tool | head -n 20

Terakhir, hubungkan dunia: di NetBox tambahkan URL dashboard/device sebagai custom field, sehingga dari aset langsung bisa lompat ke grafik kondisinya — dan sebaliknya dari alert bisa lompat ke aset.

#Reporting: Dari Metrik Menjadi Keputusan

Monitoring tanpa pelaporan hanya hiburan grafik. Dua laporan minimum engineer DC:

• Laporan harian/mingguan: peak temp per hall, UPS/PDU utilization trend, alert count by severity, alert yang belum ditutup.
• Laporan kapasitas (bulanan): utilisasi power/U/port per hall + proyeksi 6-12 bulan (dibangun penuh di episode 12).

Grafana membuat keduanya otomatis via scheduled report; yang penting angka yang sama dipakai lintas laporan agar percaya diri saat dipertanyakan manajemen.

#Common Pitfalls Monitoring

• Memantau semua, mengabaikan rantai — alert CPU server ramai-rana, tapi transfer switch tidak dimonitor sama sekali; monitor urutan kritisnya dulu.
• Threshold statik selamanya — beban musiman berubah; review threshold minimal per kuartal.
• Monitoring ikut mati saat DC mati — taruh Prometheus/NMS di luar site yang dimonitor (atau minimal di feed daya berbeda).
• Sensor tunggal dipercaya mentah — satu sensor macet bisa memicu evakuasi palsu; validasi silang antar sensor sebelum aksi drastis.

#Penutup

Inti yang harus dibawa pulang:

• DCIM mengelola aset/kapasitas fisik; monitoring mengawasi kondisi real-time — keduanya wajib dan saling terhubung.
• Sensor tersebar di IPMI, SNMP, Modbus/BACnet; mulai dari yang paling kritikal: power chain.
• Alerting tiga tingkat + runbook + escalation = sistem yang tetap didengar orang.
• Prometheus + snmp_exporter + Grafana adalah stack open-source siap produksi; NetBox menjadi kamus penghubungnya.

Di episode 11 selanjutnya kita masuk ke rutinitas yang menjaga semua sistem ini tetap sehat: maintenance & operations — jadwal preventive maintenance, anatomi SOP/MOP/EOP, shift handover, dan praktik menyusun MOP lengkap dengan rollback yang layak diaudit. Sampai jumpa di episode 11!