日志在可观测技术发展的早期是用做故障回顾的。我们通过 metrics 发现指标异常，比如成功率下降，然后通过 trace 找到了有异常的某个服务，最后才通过日志找到具体的原因（接口返回异常）。在现代日志系统里，这些都可以通过日志来一站式解决：trace 本身就是一种特殊格式的日志，metrics 可以通过日志来实时生成。

日志主要有三个明显优势：

• 生成和采集非常容易，基本上各个编程语言都有日志框架；
• 采集是旁路的，不需要用户系统做任何改造。日志生成到文件，日志采集器去读文件后采集到日志系统；
• 保留了大量的细节。

日志的挑战也很明确：日志量大，流量容易突发，非结构化的数据难以利用。

本文将主要探讨如何解决日志面临的挑战。

字节跳动日志系统介绍

EB 级日志系统 TLS（Tinder Log Service）

字节跳动在集团内部和火山引擎（公有云）是一套统一的日志系统 TLS（Tinder Log Service），下面简称TLS。集团内部包括抖音、头条、飞书、懂车帝在内的大部分用户的日志都是在 TLS上。用户的日志包含了运营、运维、审计和 Trace 等类型的日志。TLS 对用户提供采集、存储、加工、查询分析、告警、消费、投递等功能。大家知道字节跳动的业务规模增长比较迅猛、最近的抖音电商也是快速增长，TLS 经受住了业务快速增长导致日志规模快速增长的考验。

字节跳动日志系统的演进

早期字节跳动没有统一的日志系统，各业务系统存在日志需求，不得不各自自建，选用的方案五花八门，有基于 ELK 的，有基于 Clickhouse 的，也有基于对象存储+Hive 的。

自建的日志系统存在稳定性不足、运维复杂、成本高、弹性不足等诸多痛点，于是我们构建了日志的 1.0 系统。因为主要是运维日志，我们调研了业内开源的一些方案，综合需求和进度要求，最终选择了类似 Loki 的方案。

Loki 是 Grafana 旗下一款开源的日志低成本解决方案，没有全文索引，查询日志主要通过扫描。日志 1.0 的数据存储在 HDFS 上，采用扫描式查询，解决了自建系统的稳定性不足、运维复杂、成本高和弹性不足的问题。但是日志 1.0 有一个问题没有解决，那就是性能。因为没有索引，所以查询速度很慢，有同学调侃，查日志的时间，都可以去泡杯咖啡了。

1.0 显然不能满足客户的需求，所以我们又马不停蹄的开发了日志 2.0，我们在 1.0 的基础上增加了自研的倒排索引，同时把底层存储更换为了字节内部自研的池化存储 bytestore，2.0 上线后查询性能得到了很大的提升，所以我们把 trace 的数据也接入进来了。

随着业务系统的进一步演进，只有索引还是不够的，因为有很多用户希望能基于日志来做运营分析，需要实时的日志报表分析，日志告警等能力。因此我们又开发了日志 3.0（TLS），我们认为 TLS 是一个比较现代且全面的日志系统。日志 3.0 在 2.0 的基础上增加了列存、OLAP 分析引擎以及智能 AI 引擎，同时底层存储也引入了高性能的混合存储。为了满足业务系统多样性的需求，我们还加大了在生态兼容方面的投入，3.0 时代，我们的日志规模也达到了 EB 级。