Logstash评测：这款日志处理神器到底值不值得入手？我踩坑后的真实体验！
大家好呀！今天终于抽出时间来写一篇关于 Logstash评测 的文章了，说实话，之前一直想写，但总觉得得用得足够久、踩够坑才有资格聊这个话题，现在用了一年多，总算能跟大家唠唠嗑了。
初识Logstash：为啥我会选它？
先说说背景吧,我们团队之前处理日志那叫一个乱啊——服务器上的日志文件散得到处都是，出问题的时候排查起来简直要命，后来朋友推荐了ELK这套组合拳，其中的"L"就是今天的主角 Logstash评测，当时我心想，不就是个日志收集工具嘛，能有多复杂？结果……嗯，真香，但也真折腾。
安装配置：入门没那么难，但也没那么简单
第一次装Logstash的时候,我内心是有点崩溃的，因为它是基于JRuby跑的，依赖Java环境，光是JDK版本就让我折腾了半天，不过好在官方文档还算详细，跟着走一遍基本能跑起来。
配置文件用的是它自己的一套DSL,input、filter、output三段式结构，说实话还挺直观的。
input { file { path => "/var/log/*.log" } }
filter { grok { match => { "message" => "%{COMBINEDAPACHELOG}" } } }
output { elasticsearch { hosts => ["localhost:9200"] } }看起来是不是挺清爽的？但你真用起来就会发现，grok正则写错一个字符，它就能给你报一堆看不懂的错，那叫一个抓狂😭。
性能表现：这才是重点！
说到 Logstash评测，性能肯定是绕不开的话题，我拿我们生产环境的日志做了个测试，大概每天500GB左右的日志量，单实例Logstash跑下来，CPU占用是真的高，内存也吃得厉害，后来没办法，只能上多实例+ Kafka做缓冲，才勉强稳住。
所以我的建议是：中小规模用Logstash完全OK，大规模的话一定要考虑架构，别指望一个实例扛所有，那真的会哭。
Filter插件：Logstash的灵魂所在
不得不说,Logstash最强大的地方就是它的filter插件生态，grok、date、mutate、geoip……基本上你能想到的日志处理需求，它都有对应插件，尤其是grok，虽然学习曲线有点陡，但一旦掌握，解析各种奇葩日志格式都不在话下。
我印象最深的一次,是解析一个自定义格式的Nginx日志，字段乱七八糟的，用grok调了半小时，终于搞定，那一刻的成就感，真的爽！
和其他工具的对比
很多人喜欢拿Logstash和Fluentd、Filebeat对比，我的看法是：
- Filebeat：轻量，适合做采集端，但处理能力弱；
- Fluentd：资源占用小，但插件生态没Logstash丰富；
- Logstash：重，但功能全，适合做中心化的日志处理。
所以现在很多架构都是Filebeat采集 + Logstash处理 + Elasticsearch存储，这套组合是真的香。
Logstash评测后的真心话
如果要用一句话总结这次 Logstash评测，那就是：它不完美，但很难被替代。
资源占用高是事实,配置复杂也是事实，但它的插件生态、处理能力和灵活性，目前真的没几个能打的，如果你正在做日志集中处理，Logstash绝对值得一试，当然啦，记得做好架构规划，别让单点成为瓶颈哦！
好了,今天就唠到这，有啥问题欢迎评论区交流，我看到都会回～