Belajar Wazuh - Performance Tuning & Capacity Planning

#Pendahuluan

Di episode 18 kita menyambungkan Wazuh ke TheHive, Shuffle, dan jalur notifikasi. Semakin banyak yang dikirim keluar, semakin besar beban yang ditanggung manager dan indexer. Di episode 19 ini kita mundur selangkah untuk merawat fondasinya: bagaimana membuat Wazuh tetap responsif ketika jumlah agent dan volume event naik.

Kita akan membahas dua hal yang sering tertukar. Performance tuning adalah tindakan agar komponen yang ada bekerja efisien, seperti mengatur heap JVM indexer atau memperbesar queue. Capacity planning adalah perhitungan ke depan untuk memastikan sumber daya cukup, seperti berapa CPU, RAM, dan disk untuk 100, 1000, atau 10.000 agent.

Aturan emasnya sederhana: jangan menambah sumber daya sebelum membuang pemborosan. Selalu ukur dulu, lalu tuning, baru putuskan menambah hardware. Kita mulai dari satuan yang paling sering dipakai untuk mengukur beban, yaitu events per second atau EPS.

#EPS sebagai Satuan Ukur Utama

EPS adalah jumlah event yang masuk ke Wazuh per detik. Semua komponen, dari agent, manager, sampai indexer, diukur dengan satuan ini. Kalian bisa memperkirakan total EPS dengan rumus sederhana:

Total EPS sama dengan jumlah agent dikalikan rata-rata event per agent per detik. Satu agent biasa menghasilkan sekitar 1 sampai 5 EPS tergantung sumber yang dipantau. Agent Windows dengan banyak event channel cenderung lebih rajin daripada agent Linux yang hanya membaca beberapa berkas log.

Dari EPS inilah kita menurunkan dua kebutuhan penting. Pertama, kebutuhan compute untuk memproses event tepat waktu. Kedua, kebutuhan storage, karena setiap event yang masuk tersimpan sebagai dokumen di indexer. Jadi sebelum bicara hardware, biasakan menghitung EPS dulu.

#Mengukur Baseline Sebelum Tuning

Tuning tanpa data hanya menebak. Sebelum mengubah apa pun, kumpulkan angka aktual dari dashboard dan API. Beberapa perintah berguna untuk membaca kondisi cluster:

curl -sk https://localhost:9200/_cat/health?v
curl -sk https://localhost:9200/_cat/indices/wazuh-alerts*?h=index,docs.count,store.size

Untuk sisi manager, baca berkas state yang mencatat antrean dan event yang dibuang:

cat /var/ossec/var/run/wazuh-remoted.state

Perhatikan field discarded_count. Jika angka ini terus naik, berarti event mulai dibuang sebelum sempat diproses. Itu tanda bahwa antrean atau worker perlu disetel, bukan tanda untuk langsung menambah RAM.

#Tuning Indexer: JVM Heap

Indexer berbasis OpenSearch berjalan di atas Java, dan heap JVM adalah kunci utama performanya. Heap yang terlalu kecil membuat garbage collection bekerja terlalu sering, sementara heap yang terlalu besar bisa membuat sistem operasi kekurangan memori untuk page cache.

Setelan heap ada di berkas jvm.options milik indexer:

-Xms4g
-Xmx4g

Aturan praktisnya, nilai minimum dan maksimum dibuat sama agar Java tidak bolak-balik mengubah ukuran heap. Patokan umumnya sekitar separuh dari total RAM node indexer, dengan batas wajar 4 GB untuk deployment kecil dan 8 sampai 16 GB untuk deployment besar.

#Retention dengan Index Lifecycle

Data alert Wazuh bertambah tanpa henti, dan storage selalu jadi yang pertama menyerah. Index lifecycle mengatur siklus hidup indeks: kapan harus di-rollover, dipindah, dan akhirnya dihapus. Wazuh memakai kebijakan ini lewat mekanisme Index State Management pada indexer.

Contoh kebijakan sederhana: indeks alert aktif selama satu hari, lalu dihapus setelah 90 hari.

{
  "policy": {
    "description": "Retensi alert Wazuh selama 90 hari",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [
          { "rollover": { "min_index_age": "1d" } }
        ],
        "transitions": [
          { "state_name": "delete" }
        ]
      },
      {
        "name": "delete",
        "actions": [
          { "delete": {} }
        ]
      }
    ]
  }
}

Pilih masa retensi sesuai kebutuhan compliance. Regulasi seperti PCI DSS meminta periode penyimpanan tertentu, jadi sesuaikan dengan kewajiban yang berlaku, bukan sekadar berapa sisa disk. Ingat, data yang dihapus tidak bisa diambil kembali kecuali ada backup terpisah.

#Shard Sizing yang Wajar

Setiap indeks dibagi menjadi shard, dan shard terlalu kecil atau terlalu banyak sama-sama merepotkan. Terlalu kecil membuat banyak shard kosong yang hanya menambah overhead. Terlalu besar membuat operasi recovery dan redistribusi lambat.

Patokan umumnya satu shard menampung sekitar 5 sampai 20 GB data. Dengan rollover harian, ukuran indeks harian bisa dikontrol agar tetap masuk rentang itu. Ukuran shard sebenarnya bisa diperkirakan dari EPS dikalikan durasi rollover, lalu dikalikan ukuran rata-rata satu alert.

Jangan tergoda menambah shard hanya agar terlihat scalable. Perhatikan apakah query dashboard sudah lambat, baru sesuaikan jumlah shard dan skala node indexer.

#Queue dan Worker di Manager

Manager menerima event dari ribuan agent lewat wazuh-remoted, lalu memprosesnya di wazuh-analysisd. Dua titik ini punya antrean dan worker yang bisa disetel ketika terjadi lonjakan.

<remote>
  <connection>secure</connection>
  <port>1514</port>
  <protocol>tcp</protocol>
  <queue_size>196608</queue_size>
</remote>

remoted.worker_pool=8
analysisd.event_threads=4
analysisd.winevt_threads=8
analysisd.rule_matching_threads=8

Perbesar queue hanya jika antrean menumpuk pada saat lonjakan singkat. Tambah worker hanya pada kategori event yang benar-benar menjadi titik macet. Menambah semua worker ke nilai maksimum justru memicu banyaknya context switching dan bisa memperlambat semuanya.

#Capacity Planning: 100, 1000, dan 10.000 Agent

Setelah tuning, kita hitung sumber daya. Angka berikut adalah titik awal yang wajar, bukan harga mati:

• 100 agent. Satu server all-in-one masih masuk akal: 4 vCPU, 8 GB RAM, dan heap indexer 4 GB. Disk 500 GB cukup untuk retensi 90 hari bila rata-rata EPS tidak liar.
• 1.000 agent. Mulai pisahkan peran. Manager 8 vCPU dengan 16 GB RAM, indexer satu node dengan 16 GB RAM dan heap 8 GB, dashboard terpisah 4 vCPU dan 8 GB RAM. EPS di level ini biasanya mencapai ribuan, jadi pantau indexer paling ketat.
• 10.000 agent. Masuk arsitektur terdistribusi. Manager cluster dengan beberapa worker node membagi beban agent, dan indexer cluster multi-node membagi indexing serta search. Tambahkan node indexer setiap kebutuhan EPS bertambah sekitar 1000 sampai 2000.

Disk menyusul dengan rumus sederhana: total EPS dikali 86.400 detik dikali lama retensi, lalu dikalikan ukuran rata-rata satu alert. Karena angka ini bisa cepat membengkak, gunakan rumus tersebut untuk menantang kebijakan retensi kalian sendiri.

#Penutup

Di episode 19 ini kalian mengenal cara merawat Wazuh agar tetap gesit:

• EPS adalah satuan utama untuk mengukur beban dan merencanakan kapasitas.
• Ukur baseline dulu, baru tuning, jangan menebak.
• JVM heap indexer disetel seimbang antara kebutuhan Java dan page cache.
• Index lifecycle mengontrol retensi dan mencegah disk penuh.
• Ukuran shard dijaga agar tidak terlalu kecil maupun terlalu besar.
• Queue dan worker disetel per titik macet, bukan serentak.
• Kapasitas 100, 1000, dan 10.000 agent butuh arsitektur yang berbeda.

Inti yang harus dibawa pulang:

• Selalu ukur sebelum mengubah konfigurasi atau menambah hardware.
• Total EPS menjadi dasar perhitungan CPU, RAM, dan disk.
• Naikkan heap dan worker bertahap sambil memantau dampaknya.
• Retention policy menentukan biaya storage jangka panjang.
• Disk sering menjadi titik pertama yang menyerah, jadi desain retensi sejak awal.
• Ketika satu node tidak lagi cukup, mulai pikirkan arsitektur cluster.

Di episode 20 kita membahas sisi yang justru paling sering terlupakan: memonitor Wazuh itu sendiri dan menyiapkan backup recovery yang benar. Sampai jumpa!