ELK 日志平台搭建：小团队的轻量级方案
ELK Log Platform Setup: A Lightweight Solution for Small Teams
| David | 2026-09-02T12:35:57
用 ELK Stack 给团队搭了一套日志分析平台，但没用官方的重量级方案，而是做了很多精简。一台 4G 内存的机器就跑起来了。
Built an ELK log analysis platform for the team with significant simplifications. Runs on a single 4GB RAM server.
日志查看一直是我们的痛点，之前排查问题要 ssh 到服务器上 grep 日志文件，效率很低。想搭 ELK 但又觉得太重，后来摸索出一套轻量方案。 轻量化的关键 1. 用 Filebeat 替代 Logstash Logstash 太吃内存了，JVM 起来就要 1G。Filebeat 是 Go 写的，内存占用只有几十 MB，对于简单的日志收集完全够用。 2. Elasticsearch 单节点 小团队不需要集群，单节点足够。重点是调整 JVM 堆大小： # jvm.options -Xms1g -Xmx1g 4G 内存的机器给 ES 分 1G 堆就够了（ES 还需要文件系统缓存，不要把所有内存都给堆）。 3. 索引生命周期管理 日志不需要永久保存，配置 ILM 自动清理： PUT _ilm/policy/logs-policy { "policy": { "phases": { "hot": { "actions": {} }, "delete": { "min_age": "30d", "actions": { "delete": {} } } } } } Filebeat 配置 filebeat.inputs: - type: log paths: - /var/log/app/*.log json.keys_under_root: true json.add_error_key: true output.elasticsearch: hosts: ["localhost:9200"] index: "app-logs-%{+yyyy.MM.dd}" Kibana 看板 配了几个常用的看板： 错误日志实时流（按 level=ERROR 过滤） 接口响应时间分布 按 traceId 搜索完整调用链 错误趋势图（每小时错误数量） 资源占用 整套跑在一台 4G 内存的机器上： Elasticsearch: ~1.5G Kibana: ~500M Filebeat: ~50M 系统: ~500M 每天大约产生 2G 的日志数据，保留 30 天，磁盘占用 60G 左右。
Built a lightweight ELK stack for log analysis, replacing the painful ssh+grep debugging workflow. Key Simplifications Filebeat instead of Logstash (Go-based, ~50MB vs 1GB+ for JVM-based Logstash) Single-node Elasticsearch with 1GB heap ILM for automatic 30-day log cleanup Resource Usage Runs on a 4GB server: ES ~1.5GB, Kibana ~500MB, Filebeat ~50MB. Handles ~2GB/day of logs with 30-day retention (~60GB disk).