Loki还是Elasticsearch：省下索引空间，也会改变查询方式

Loki更适合先按服务和时间缩小范围、再查日志正文的团队；经常只掌握一段报错文字、需要跨服务搜索的团队，则更能用上Elasticsearch的全文索引。Grafana的Loki架构文档说明，索引用于定位一组标签对应的日志块，索引文件和日志块都可以存入对象存储。正文不逐词进入常规索引，节省的空间会体现为查询时对选中日志块的读取和筛选。

Elasticsearch的优势取决于字段怎样映射，而非产品名本身：Elastic的全文检索说明解释，文本经过分析后形成词项到文档的倒排索引，查询也经过分析，并可按相关性排序。给日志正文保留这种能力需要相应的存储；若日常查询已有可靠的服务标签，预先为大量正文建索引的价值就要结合实际搜索频率判断。

同一批日志，落盘差了多少

Platform Monkey的单节点实验将相同的30万行、40.9 MB Kubernetes式日志写入Loki 3.7.8和Elasticsearch 9.5.4：采用TSDB索引与本地文件系统对象存储的Loki落盘10.1 MB，采用logsdb模式的Elasticsearch落盘52.6 MB；在Elasticsearch的logsdb_columnar配置中，message字段按keyword处理时为7.9 MB，明确映射为text后为32.4 MB。

这组结果说明，最小的Elasticsearch落盘值对应的是另一套查询能力。keyword映射没有把消息正文拆成供全文搜索的词项；实验将message改为text后，短语检索能够命中，存储量也明显上升。因此，比较空间时要同时说明字段映射，不能把最紧凑的配置当作全文检索配置的成本。

实验把两套程序放在同一台主机上，输入同一批日志，但测量口径并不完全相同：Loki在日志块刷新后用文件系统工具统计，Elasticsearch在索引刷新后读取自身的存储统计。语料以访问日志和重复的运维消息为主，压缩效果会随正文重复程度、字段内容和标签划分变化。这些数值适合解释该配置的落盘差异，不能直接推算副本、计算资源和保留期都不同的生产账单。

省下的是哪一部分索引

Loki把标签组合视为日志流，并用索引找出相关日志块；块中保存对应时间范围内的日志行。查询者若已经知道应用或命名空间，索引可以先排除无关的流。随后对正文做字符串或正则过滤时，系统仍要处理选中块里的日志行：标签负责定位，正文条件负责进一步筛选。

Elasticsearch为映射成text的字段执行文本分析，并保存倒排索引。搜索一个词项时，可以先查哪些文档包含它，再取回候选日志；短语查询还依赖分析后的词项及其位置。写入阶段多做的工作，换来的是在来源未知时从大量正文中寻找候选记录的能力。具体能否找到原样字符串或预期短语，还取决于分析器和查询方式，不能仅凭字段名判断。

列式配置把这笔交换展示得很清楚：减少默认建立的索引结构，可以缩小落盘文件；为message恢复全文索引，存储量随之增加。两套系统都能调整写入与查询之间的分工，所以应比较具备所需查询能力的配置，而不是各取一个最有利的磁盘数字。

已知服务和时间：标签先圈定日志

当故障线索已指向某个服务，Loki的查询路径与排障顺序相合。Grafana的LogQL查询文档说明，日志查询必须包含流选择器；后续的管道阶段才对选中的日志流进行行过滤、解析或标签过滤。选择器越能限定相关来源，正文过滤需要处理的范围通常就越小。

假设值班人员已知异常发生在某个生产命名空间的API服务，查询可以先选命名空间与应用，再在故障时间段查找报错文字。这里的报错文字无需在写入时预先拆词，但查询仍要读取候选日志行。若把同样的正文条件放到所有应用和很长的时间范围，标签索引排除的数据就少了，读取量可能上升。

这也解释了为什么标签设计属于查询设计。稳定且常用于限定来源的属性有助于缩小范围；只偶尔出现的词句保留在正文中，仍可在选定范围内查找。团队若经常不知道日志来自哪个服务，虽然Loki仍能搜索正文，却无法总是享受精准流选择器带来的便利。

临时全文搜索：提前建立索引的回报

探索式调查的起点往往只有一段异常消息，而没有可信的应用或命名空间线索。此时，已为message建立全文索引的Elasticsearch更契合查询形态：调查者可以从正文词项寻找候选文档，再逐步收窄条件。它提前支付索引空间与写入处理成本，换取这类查询时更直接的检索路径。

全文检索与精确匹配仍是两回事。经过分析的text字段适合词项和短语检索；未按text映射的消息字段，不能因为也存有字符串就被视为具备相同能力。尤其在比较紧凑存储配置时，必须先确认常用报错片段会怎样被索引、怎样被查询。否则，磁盘上看似节省的部分，可能正是团队调查故障时需要的索引。

如果跨服务搜索只在少数事件中发生，长期为所有正文保留全文索引是否划算，要看发生频率、可接受的等待时间和每次查询覆盖的日志量。相反，若探索式搜索是日常工作，查询阶段反复扫描大范围日志也有代价。落盘量回答的是保存了什么，不能单独回答调查者等多久。

高基数字段：Loki的标签不能无限加

请求ID和追踪ID虽然能帮助定位单次请求，却不适合直接变成Loki流标签。Grafana的标签基数文档指出，取值众多或短暂变化的标签会制造大量日志流，使索引膨胀，并产生许多细小日志块，进而损害性能。多个各自取值有限的标签组合起来，也可能形成过多日志流。

因此，不能为了让每个字段都能预先定位，就不断把正文属性提升为标签。应用、环境和命名空间等相对稳定的来源属性更适合作为流选择条件；频繁变化的标识可以保留在正文或结构化元数据中，再在选定范围内筛选。结构化元数据不会自动成为普通流标签索引，它解决的是保存和按字段过滤这类信息的问题，而非让任意正文查询都无需读取候选日志。

选择由主要查询形态决定：已知来源的排障可以利用Loki较小的标签索引，代价是在候选日志中继续筛选正文；频繁跨来源查词句，则更需要Elasticsearch对相关text字段建立的倒排索引。高基数标识若同时大量参与调查，尤其要算清标签分裂或字段索引各自带来的成本。省下的索引空间是真实的收益，前提是团队接受随之而来的查询路径。

相关阅读：

• Wise还是Airwallex：香港企业别只比汇率，收款方式会改写费用
• Airtable还是Notion：20美元同价，付费成员算法会改变总账
• HubSpot还是Zoho CRM？免费起步后，席位数会先改变账单