大讲堂
倒排索引：这不是字典，是高速公路的匝道
你以为Elasticsearch搜索快是因为分布式？别天真了。单机上的Lucene才是灵魂。核心就四个字：倒排索引。举个栗子，你有一堆文档，每个文档里有“ELK实战”这词。传统数据库会一行一行扫，像在图书馆一个个书架翻书。而倒排索引呢？提前建好“ELK实战”这个词到文档ID的映射，搜的时候直接定位，就像你查字典，先找拼音，再翻页——哦不对，比字典还快，因为直接跳转。ES会在内存里维护Term Dictionary和Term Index，前者是排好序的二分查找，后者是FST（有限状态转换器）结构，这玩意儿本质上是个压缩的字典树，内存占用极小，查询时能直接定位到磁盘block。哎，说到FST，我第一次看源码里的Builder类，那个递归… 不过话说回来，它能把几百万词项压缩到几十MB，真香。 但别高兴太早，倒排索引的代价是写入时要做分词、排序、合并段。ES默认1秒刷新，这1秒里，你的文档其实躺在buffer里，所以“近实时搜索”的“近”就是这么来的。如果瞬间写入量巨大，比如重放几亿条历史日志，你会看到CPU飙满，heap压力陡增。这时候怎么办？关掉refresh_interval，设成-1，写入完再打开。这个技巧，救过我不止一次。
Logstash的管道：线程模型与背压
Logstash经常被骂吃资源，我一开始也骂。后来读了Pipeline.java，才发现这货的设计其实挺精巧。它用的是多线程管道，每个插件都有自己独立的线程，中间通过有界队列通信。input线程负责读，把事件丢给filter队列，filter线程处理完了再丢给output队列。这种架构的好处是解耦，坏处是——队列满了会阻塞！这就是背压机制。你想想，如果Kafka集群慢，output队列堵了，它就会反压filter，filter再压input，最终输入端停止消费。那次我们忘了调pipeline.batch.size和pipeline.workers，默认1个worker，每个batch 125条，处理nginx访问日志里的复杂grok，半小时积压了上千万事件，整个管道直接假死。后来把workers调到cpu核数，batch size调到500，队列大小改到4096，吞吐从200 events/s飙升到8000，内存还稳得像死水。别信什么“默认配置最优”，压测数据不会骗人。
三个坑，踩出血的教训
坑一：脑裂与最低节点数 你肯定听过脑裂。ES集群主节点失联，选出新主，旧主复活，两个主打架，数据全乱。官方文档说设置discovery.zen.minimum_master_nodes，但有人不当回事。我一个5节点集群，设了2，结果网络抖了一下，两个节点以为自己是主，彻底分裂。正确值是(N/2)+1。5节点就设3。现在新版用cluster.initial_master_nodes，但不了解原理照踩不误。那晚恢复集群，我手都在抖——虽然最终靠snapshot救回来了。 坑二：映射的冰山 ES的动态映射很智能，但也愚蠢。我导入过一批access log，里面response_time字段有时是数字，有时是字符串（比如“-”）。ES自动映射成text和keyword两种，然后查询就抽风了，聚合报illegal_argument_exception。提前定义好mapping，用multi-field技术，保留keyword子字段，别让ES猜。还有，禁用_all字段、禁用fielddata在text字段上，都是血泪换来的调优。一次上线压测，QPS从5000跌到200，就因为某个text字段默认开启了fielddata，把heap吃爆了。后来强制使用doc_values，世界清净了。 坑三：Grok调试地狱 Logstash的grok过滤器强大，但写pattern简直是玄学。日志格式稍微变一点，匹配失败，整条日志就废了。更恶心的是，grok超时默默丢弃事件，日志里就一行“_grokparsefailure”。我现在的习惯是，先用Kibana的Grok Debugger在线调试，再写patterns文件，把所有变化用可选分组包住。还有，加个if判断，匹配失败时输出到dead_letter_queue，事后补数据。这套流程，我磨了两个月才稳定。 说这么多，ELK这套组合拳，玩明白了确实能撑起一个几十亿日志的监控平台。玩不明白，就是资金焚烧炉。我甚至觉得，运维ELK就像养一只哥斯拉——喂好了，为你攻城略地；喂不好，一口老血喷你脸上。但谁让我们是搞技术的呢？那股子拧巴的征服欲，停不下来。作者|大讲堂
排版|大讲堂
审核|阿辰