DevOps
Elastic Stack (ELK) Self-Hosted: Setup Produksi dan Pelajaran Operasional
Mei 202612 menit baca
DevOps
Elastic Stack — Elasticsearch, Logstash, dan Kibana (ELK) — adalah solusi logging terpusat yang paling banyak di-deploy dalam produksi. Menurut metrik Elastic sendiri, Elasticsearch diunduh lebih dari 600 juta kali per tahun. Tetapi ELK self-hosted memiliki reputasi sebagai platform yang rakus resource, kompleks secara operasional, dan rentan terhadap mode kegagalan tertentu yang mengejutkan operator baru. Saya men-deploy stack ELK self-hosted di Commsult Indonesia untuk persyaratan kepatuhan klien (retensi log selama 2 tahun dalam yurisdiksi tertentu) dan menghabiskan tiga bulan pertama mempelajari karakteristik operasionalnya dengan cara yang sulit. Panduan ini mencakup apa yang saya harap sudah saya ketahui di awal.
Layanan Elasticsearch terkelola (Elastic Cloud, AWS OpenSearch Service, penawaran terkelola GCP) menghilangkan sebagian besar overhead operasional tetapi jauh lebih mahal daripada self-hosted untuk volume data tinggi. Dengan sekitar 10-50GB data log per hari yang diingest, layanan terkelola dapat menghabiskan $500-2000/bulan. Self-hosted pada infrastruktur yang setara menghabiskan $150-400/bulan. Titik impas di mana self-hosted menjadi hemat biaya dibandingkan terkelola biasanya adalah 10-20GB/hari untuk sebagian besar tim. Alasan lain untuk self-host: persyaratan residensi data (data harus tetap pada hardware tertentu di Indonesia), persyaratan kepatuhan untuk lingkungan air-gapped, atau kebutuhan kustomisasi tertentu yang tidak diizinkan layanan terkelola.
Cluster Elasticsearch single-node bukan tingkat produksi — tidak memiliki toleransi kesalahan dan tidak memiliki high availability. Setup produksi minimum adalah tiga node dalam cluster: ini memungkinkan primary shard pada dua node, replica shard pada yang ketiga, dan pemilihan leader berbasis quorum (2-dari-3 diperlukan untuk penulisan cluster). Setiap node memerlukan minimal 8GB RAM (16GB direkomendasikan), dengan JVM heap diatur ke 50% dari RAM yang tersedia (maks 31GB — jangan melebihi heap 31GB karena kompresi pointer JVM). Storage SSD secara efektif diperlukan — pola baca/tulis acak Elasticsearch membuat performa HDD tidak dapat diterima untuk latensi kueri produksi.
Logstash adalah pipeline pemrosesan data — ia menerima data log dari agen Beats (Filebeat di setiap server), mengurai dan mengubahnya, dan meneruskan ke Elasticsearch. Tahap pipeline Logstash inti adalah input (terima data dari Filebeat atau sumber langsung), filter (urai, perkaya, dan transformasi — pola grok untuk penguraian log, filter date untuk normalisasi timestamp, geoip untuk pengayaan IP), dan output (tulis ke Elasticsearch). Untuk ingest log sederhana tanpa transformasi kompleks, pertimbangkan Filebeat → Elasticsearch langsung, melewati Logstash — ini mengurangi infrastruktur dan overhead operasional dengan mengorbankan fleksibilitas transformasi.
Dari pengalaman saya: atur JVM heap tepat setengah dari RAM server Anda, tetapi tidak pernah lebih dari 31GB. Pada server 32GB RAM, atur -Xms16g -Xmx16g untuk Elasticsearch. Di luar 31GB, JVM beralih dari pointer objek terkompresi ke tidak terkompresi, yang membuang ruang heap dan memperlambat garbage collection. Saya menemukan ini dengan cara yang keras setelah mengatur heap 34GB pada server 64GB dan melihat waktu jeda GC tiga kali lipat dibandingkan heap 31GB pada server yang sama. Atur heap dalam file jvm.options, bukan sebagai variabel lingkungan, untuk memastikan penerapannya benar.
Index Lifecycle Management (ILM) Elasticsearch sangat penting untuk operasi produksi. Tanpa ILM, indeks tumbuh tanpa batas hingga disk penuh. ILM mendefinisikan fase: hot (penulisan aktif, replica diaktifkan), warm (read-only, dapat dipindahkan ke storage lebih lambat), cold (akses jarang, frozen index), dan delete (hapus data lama). Kebijakan indeks log tipikal: fase hot selama 7 hari (aktif, direplikasi), fase warm selama 30 hari (dipindahkan ke warm node, dikompresi), fase cold selama 90 hari (opsional, storage minimal), fase delete pada 365 hari. Lampirkan kebijakan ini ke template indeks Anda sehingga setiap indeks baru secara otomatis mengikuti siklus hidup.
# elasticsearch.yml — Production cluster configuration
cluster.name: prod-logs
node.name: es-node-1
network.host: 0.0.0.0
http.port: 9200
# Cluster discovery (3-node HA cluster)
discovery.seed_hosts:
- es-node-1.internal:9300
- es-node-2.internal:9300
- es-node-3.internal:9300
cluster.initial_master_nodes:
- es-node-1
- es-node-2
- es-node-3
# JVM heap (half of RAM, max 31GB)
# Set in jvm.options:
# -Xms16g
# -Xmx16g
# Index Lifecycle Management policy (via API)
# PUT _ilm/policy/logs-policy
# {
# "policy": {
# "phases": {
# "hot": { "min_age": "0ms", "actions": { "rollover": { "max_age": "7d" } } },
# "warm": { "min_age": "7d", "actions": { "shrink": { "number_of_shards": 1 } } },
# "delete": { "min_age": "365d","actions": { "delete": {} } }
# }
# }
# }
# Check cluster health
curl -u elastic:password https://localhost:9200/_cluster/health?prettyElasticsearch memaparkan REST API untuk kesehatan cluster: GET /_cluster/health mengembalikan status green/yellow/red. Green berarti semua primary dan replica shard dialokasikan. Yellow berarti semua primary shard dialokasikan tetapi beberapa replica tidak (fungsional tetapi redundansi terdegradasi). Red berarti beberapa primary shard tidak dialokasikan (kehilangan data atau tidak tersedia). Tambahkan monitoring kesehatan Elasticsearch ke stack Prometheus + Grafana Anda menggunakan prometheus-elasticsearch-exporter — ini mengekspos metrik Elasticsearch dalam format Prometheus. Alert pada status cluster red (tindakan segera diperlukan) dan yellow selama lebih dari 10 menit (investigasi diperlukan).
┌──────────────────────────────────────────────────────┐
│ Elastic Stack Data Flow │
├──────────────────────────────────────────────────────┤
│ │
│ App Servers │
│ [Filebeat] → reads logs from /var/log/ │
│ ↓ │
│ [Logstash] → grok parse + geoip + timestamp │
│ ↓ │
│ [Elasticsearch Cluster] (3 nodes, HA) │
│ ├── hot: es-node-1 (SSD, active writes) │
│ ├── warm: es-node-2 (HDD, read-only) │
│ └── cold: es-node-3 (compressed, infrequent) │
│ ↓ │
│ [Kibana] → dashboards, Discover, Alerting │
└──────────────────────────────────────────────────────┘Elasticsearch memiliki flood-stage disk watermark (default 95% penggunaan disk) yang, ketika dilampaui, membuat semua indeks menjadi read-only untuk mencegah korupsi data dari kondisi disk-full. Ketika ini terjadi, Logstash mulai menjatuhkan event log karena tidak bisa menulis ke Elasticsearch, dan Kibana menampilkan banner error. Pemulihan memerlukan pembebasan ruang disk secara manual dan kemudian menghapus status read-only melalui API pengaturan indeks. Saya menghadapi ini pukul 2 pagi ketika volume log melonjak tak terduga. Atur alert penggunaan disk pada ambang 75% dan 85%, bukan hanya 90%. Konfigurasikan fase delete ILM secara konservatif dan verifikasi bahwa mereka berjalan. Disk fill Elasticsearch diam-diam hingga menjadi darurat.
Tampilan Discover Kibana untuk pencarian log ad-hoc dan tampilan Dashboard untuk dashboard operasional mencakup sebagian besar kebutuhan sehari-hari. Untuk indeks log akses Nginx, buat dashboard yang menampilkan: request rate berdasarkan status code, endpoint lambat teratas (persentil ke-95 waktu respons), jalur error teratas (status 5xx), distribusi geografis pengunjung (menggunakan pengayaan geoip di Logstash), dan identifikasi traffic bot/crawler. Editor Lens Kibana membuat pembuatan dashboard dapat diakses tanpa pengetahuan mendalam tentang kueri Elasticsearch. Ekspor dashboard sebagai JSON dan simpan dalam version control — dashboard adalah konfigurasi dan harus dapat direproduksi.
Versi Elasticsearch terbaru (8.x) mengaktifkan keamanan secara default — TLS untuk semua komunikasi antar node dan HTTP, serta autentikasi berbasis password. Pengaturan xpack.security.enabled default ke true di Elasticsearch 8.x. Jalankan utilitas elasticsearch-setup-passwords untuk mengatur password awal pengguna bawaan (elastic, kibana_system, logstash_system). Buat role Elasticsearch khusus untuk setiap komponen: role logstash_writer dengan akses tulis hanya ke indeks log, role kibana_user untuk penampil dashboard. Jangan pernah menggunakan akun superuser elastic untuk akses aplikasi — ini memiliki hak admin cluster penuh.
AWS mem-fork Elasticsearch 7.10 pada 2021 untuk membuat OpenSearch setelah Elastic mengubah lisensinya. OpenSearch berlisensi Apache 2.0, artinya dapat digunakan secara bebas untuk tujuan komersial tanpa masalah lisensi. Untuk deployment self-hosted baru di mana fitur Elastic di luar subset open-source tidak diperlukan, OpenSearch adalah alternatif yang layak dengan ekosistem yang berkembang. Namun, Elastic Stack 8.x pada Elastic License 2.0 gratis untuk penggunaan self-hosted — lisensi hanya membatasi penyediaan Elasticsearch sebagai layanan terkelola kepada pihak ketiga. Untuk deployment self-hosted internal, Elastic License 2.0 umumnya kompatibel. Rekomendasi saya: gunakan Elastic Stack jika Anda membutuhkan fitur proprietary Elastic (ML alerting, security analytics) dan nyaman dengan lisensinya; gunakan OpenSearch jika Anda lebih menyukai lisensi Apache 2.0 atau membutuhkan integrasi AWS.
Sumber & Bacaan Lanjutan