Health Check #

Health check adalah mekanisme Nginx untuk mendeteksi server backend yang tidak berfungsi dan mengeluarkannya dari rotasi load balancing secara otomatis. Ini memastikan traffic tidak diteruskan ke server yang sedang down, meminimalkan error yang dilihat pengguna.

Passive vs Active Health Check #

Ada dua pendekatan health check, dan penting untuk memahami mana yang tersedia di Nginx open-source:

Passive health check (tersedia di Nginx open-source): Nginx mendeteksi kegagalan secara tidak langsung — ia hanya tahu server sedang bermasalah setelah ada request yang gagal ke server tersebut. Tidak ada probe aktif.

Active health check (hanya Nginx Plus): Nginx secara proaktif mengirim request ke endpoint health check khusus di setiap backend secara berkala, tanpa menunggu request dari pengguna untuk mendeteksi kegagalan.

Passive (Nginx open-source):
Pengguna → Nginx → Server (gagal) → Nginx catat kegagalan
Pengguna → Nginx → Server (gagal lagi) → kegagalan ke-2
Pengguna → Nginx → Server (gagal lagi) → max_fails tercapai
                                        → Server ditandai down
(Beberapa pengguna terdampak sebelum server dikeluarkan)

Active (Nginx Plus):
Nginx → GET /health → Server (secara berkala, tanpa pengguna)
                    → Gagal → Server langsung ditandai down
(Pengguna tidak terdampak sama sekali)

Passive Health Check: Konfigurasi #

Passive health check dikonfigurasi melalui parameter max_fails dan fail_timeout di setiap server:

upstream app_servers {
    server 10.0.0.1:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.2:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.3:3000 max_fails=3 fail_timeout=30s;
}

server {
    location / {
        proxy_pass http://app_servers;

        # Kondisi yang dihitung sebagai kegagalan
        proxy_next_upstream error timeout http_500 http_502 http_503;

        # Timeout untuk koneksi ke backend
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
    }
}

Nilai default jika tidak ditentukan: max_fails=1 dan fail_timeout=10s. Artinya satu kegagalan sudah cukup untuk mengeluarkan server selama 10 detik — terlalu agresif untuk banyak kasus.

Menyetel nilai yang tepat:

Aplikasi web normal:
  max_fails=3 fail_timeout=30s
  → Server dikeluarkan setelah 3 kegagalan dalam 30 detik
  → Kembali dicoba setelah 30 detik

Aplikasi kritis yang butuh deteksi cepat:
  max_fails=2 fail_timeout=10s

Aplikasi yang sesekali timeout tapi masih sehat:
  max_fails=5 fail_timeout=60s
  → Toleransi lebih tinggi, hindari false positive

Membuat Health Check Endpoint di Aplikasi #

Meskipun Nginx open-source tidak melakukan active health check, kamu tetap bisa membuat infrastruktur yang memungkinkan monitoring tools eksternal (seperti Prometheus, Datadog, atau script cron) melakukan health check:

# Endpoint /health di setiap backend server (langsung, bypass load balancer)
server {
    listen 8080;  # Port terpisah untuk health check internal

    location /health {
        access_log off;
        return 200 '{"status":"ok"}';
        add_header Content-Type application/json;
    }

    # Atau proxy ke health endpoint aplikasi
    location /health {
        proxy_pass http://localhost:3000/health;
        access_log off;
    }
}

Di sisi aplikasi (Node.js sebagai contoh):

// Endpoint health check yang baik memeriksa dependency penting
app.get('/health', async (req, res) => {
    try {
        await db.query('SELECT 1');  // Cek koneksi database
        await redis.ping();           // Cek koneksi cache
        res.json({ status: 'ok', uptime: process.uptime() });
    } catch (error) {
        res.status(503).json({ status: 'error', message: error.message });
    }
});

Mensimulasikan Active Health Check dengan Lua / OpenResty #

Jika kamu menggunakan OpenResty, bisa mengimplementasikan active health check menggunakan modul lua-resty-upstream-healthcheck:

# nginx.conf (OpenResty)
http {
    lua_shared_dict healthcheck 1m;

    init_worker_by_lua_block {
        local hc = require "resty.upstream.healthcheck"
        local ok, err = hc.spawn_checker{
            shm = "healthcheck",
            upstream = "app_servers",
            type = "http",
            http_req = "GET /health HTTP/1.0\r\nHost: localhost\r\n\r\n",
            interval = 2000,    -- cek setiap 2 detik
            timeout = 1000,     -- timeout 1 detik
            fall = 3,           -- 3 kegagalan → tandai down
            rise = 2,           -- 2 sukses → tandai up kembali
            valid_statuses = {200},
        }
    }

    upstream app_servers {
        server 10.0.0.1:3000;
        server 10.0.0.2:3000;
    }
}

Monitoring Status Upstream #

Nginx menyediakan modul stub_status untuk melihat statistik dasar:

server {
    listen 8080;

    location /nginx_status {
        stub_status;
        allow 127.0.0.1;
        allow 10.0.0.0/8;
        deny all;
    }
}

curl http://localhost:8080/nginx_status
# Active connections: 47
# server accepts handled requests
#  1234 1234 5678
# Reading: 0 Writing: 15 Waiting: 32

Untuk monitoring yang lebih detail (termasuk status per-upstream server), tools seperti nginx-module-vts atau Prometheus nginx exporter memberikan metrics yang jauh lebih kaya.

Strategi Keseluruhan: Passive + External Monitoring #

Pendekatan yang realistis untuk Nginx open-source di production:

1. Passive health check (max_fails + fail_timeout)
   → Deteksi otomatis saat ada kegagalan nyata
   → Keluarkan server dari rotasi sementara

2. External health check (cron / monitoring tool)
   → Script atau Prometheus yang secara aktif cek /health
   → Alert ke tim jika server down
   → Bisa trigger konfigurasi ulang Nginx secara otomatis

3. Backup server
   → Server dengan parameter backup sebagai last resort
   → Tampilkan halaman maintenance yang informatif

4. Alert dan on-call
   → Notifikasi ke tim via Slack/PagerDuty saat ada server down
   → Manusia yang memutuskan apakah perlu intervensi

Ringkasan #

• Nginx open-source hanya mendukung passive health check — kegagalan baru terdeteksi setelah ada request nyata yang gagal.
• Setel max_fails=3 fail_timeout=30s sebagai titik awal yang wajar, sesuaikan berdasarkan karakteristik aplikasi.
• Buat health endpoint di setiap backend (/health) yang memeriksa dependency penting — berguna untuk monitoring eksternal meskipun Nginx tidak memanggilnya secara aktif.
• Untuk active health check tanpa Nginx Plus, gunakan OpenResty dengan lua-resty-upstream-healthcheck atau tools monitoring eksternal.
• Active health check (probing proaktif tanpa tergantung user traffic) hanya tersedia di Nginx Plus.

← Sebelumnya: Weighted   Berikutnya: Konsep SSL/TLS →