ElasticRAM -Xmx31g OOPs & Shard Studio

Công bố liên kết đối tác ElasticRAM: Nhấp vào các liên kết /go/ trên ElasticRAM có thể mang lại khoản hoa hồng giới thiệu mà không làm tăng chi phí thanh toán của bạn. Xem chính sách minh bạch hoa hồng ElasticRAM.

WAZUH-4X-SIEM // Kiến Trúc An Ninh Wazuh SIEM

Bản Vẽ Định Cỡ Wazuh 4.x SIEM Indexer Trên ElasticRAM: Số Agent, EPS, Ổ NVMe & ISM

Theo mô hình định cỡ an ninh trên ElasticRAM, Wazuh Indexer (nền tảng OpenSearch 2.x) liên tục ghi nhận sự kiện EDR, kiểm tra toàn vẹn tệp FIM, quét lỗ hổng CVE và cảnh báo Suricata. Thiếu hụt ổ NVMe hoặc giữ mặc định 3 shard/ngày sẽ sớm chạm trần 1.000 shard gây treo bảng điều khiển SOC.

Chúng tôi tính toán dung lượng Wazuh Indexer kèm hệ số lập chỉ mục 1.15x và chia cho 0.85 nhằm giữ ổ NVMe luôn thông thoáng dưới ngưỡng cảnh báo 85% ngay cả khi bùng phát sự cố.

Nạp Cấu Hình WAZUH-4X-SIEM Vào Trình Sinh File ElasticRAM →

Ma Trận Định Cỡ RAM, JVM Heap & Đệm Lucene Cho WAZUH-4X-SIEM Trên ElasticRAM

Quy Mô Tải / Phân Hạng RAM Máy Chủ Cờ JVM Heap Đệm Lucene / Ổ NVMe Trạng Thái Con Trỏ / Shard
50–150 Endpoints (~10 GB/day • 30d) 16 GB Single-Node -Xms8g -Xmx8g 420 GB NVMe (KVM 8 / VDS) 1 Primary Shard / Rollover
300–800 Endpoints (~50 GB/day • 30d) 64 GB Dedicated VDS -Xms31g -Xmx31g 2 TB NVMe (Bare-Metal Ryzen 64GB) Rollover @ 30 GB/shard
1,500+ Endpoints + Suricata (100 GB/d • 30d HA) 3x 64 GB HA Cluster 3x -Xmx31g 3x 2 TB NVMe (8.1 TB Hot Total) 1 Replica Quorum HA
SOC Compliance Archive (250 GB/d • 90d HA) 5x 64 GB / 3x 128 GB 5x -Xmx31g Multi-TB Ryzen + S3 Cold Snapshots PCI-DSS / ISO 27001 Retention

Đoạn Mã Cấu Hình Mẫu (WAZUH-4X-SIEM) Từ ElasticRAM

ElasticRAM Reference // wazuh-siem-indexer-sizing
// PUT _index_template/wazuh-custom-sizing (Prevent daily tiny-shard explosion)
{
  "index_patterns": ["wazuh-alerts-4.x-*"],
  "priority": 500,
  "template": {
    "settings": {
      "index.number_of_shards": 1,
      "index.number_of_replicas": 1,
      "index.codec": "best_compression",
      "index.refresh_interval": "15s",
      "plugins.index_state_management.rollover_alias": "wazuh-alerts"
    }
  }
}

Quy Tắc Tinh Chỉnh Sản Xuất Trên ElasticRAM Cho WAZUH-4X-SIEM

  • Tăng index.refresh_interval từ 1s lên 10s–15s cho mẫu chỉ mục wazuh-alerts-4.x-*: chuyên viên SOC hầu như không nhận ra độ trễ 10 giây nhưng giảm mạnh tần suất ghi phân đoạn Lucene trên NVMe.
  • Bật chế độ nén sâu index.codec: best_compression cho log JSON bảo mật giúp thu gọn log Windows Event và Suricata đáng kể trên ổ cứng.
  • Khi lưu lượng vượt 40 GB/ngày (~1.500 EPS duy trì), tách riêng máy chủ Wazuh Manager (giải mã rule) khỏi cụm Wazuh Indexer để tránh tranh chấp nhân vCPU.

Gói Máy Chủ Khớp Cấu Hình WAZUH-4X-SIEM Theo Bảng Giá Công Khai (2026-11-12)

Chúng tôi ghép các nhà cung cấp bên dưới dựa trên dung lượng RAM DDR5 ECC và ổ cứng NVMe niêm yết ngày 2026-11-12; giá khuyến mãi và gia hạn có thể thay đổi nên hãy xác nhận tại giỏ hàng chính thức.

Câu Hỏi Thường Gặp Về WAZUH-4X-SIEM Trên ElasticRAM

ElasticRAM ước tính lưu lượng bao nhiêu GB log mỗi ngày cho 100 máy cài Wazuh Agent?

Theo tài liệu định cỡ Wazuh công khai, máy chủ Linux tiêu chuẩn sinh khoảng 50–90 MB/agent/ngày, máy trạm Windows hoặc Domain Controller sinh 150–300 MB/agent/ngày; riêng luồng tường lửa FortiGate/Suricata cộng thêm 10–50+ GB/ngày.

Tại sao Wazuh Indexer ngừng ghi log khi ổ NVMe chạm ngưỡng 85%–95% trên OpenSearch?

OpenSearch ngừng cấp phát shard mới ở mốc 85% (watermark.low) và khóa toàn bộ chỉ mục sang chế độ chỉ đọc ở mốc 95% (flood_stage) để bảo vệ tệp Lucene khi trộn. Công thức ElasticRAM luôn tự động chừa 15% dung lượng trống.

Các Bản Vẽ OpenSearch & SIEM Liên Quan Trên ElasticRAM