说明

官方一直在强调的一些字眼：

1. Unlike other logging systems
2. only indexing metadata
3. S3 or GCS
4. cheaper to operate
   从官方文档里的一些关键字眼，以及这些天的实践和原理掌握来看，我们大致可以找出 loki 的适用场景。

场景说明

1. loki 适用于查看日志解决故障
2. loki 适用于少量的小范围内的日志查看，如 5 分钟内的日志，5 分钟前的 500 条日志
3. loki 适用于分布式系统中日志查看，通过 app、pod 等纬度的标签可以定位到应用，也可以定位到实例
4. loki 适用于通过日志定义告警
5. loki 适用于基于 k8s 的云原生的服务发现与日志收集
6. loki 适用于 prometheus 那套的 metrics、log、trace 江湖一统，当然这需要时间

loki 不适合

1. loki 不适用于大型的数据聚合和统一分析，它本身的定位就不是代替 ELK 那套
2. loki 不适用于查看如一天、一个礼拜这样的大范围查询，其本身的 cache 机制还不太完善，另外查询机制是先找内存，内存找不到就找存储，这对于内存的消耗有一定的要求和成本，另外内存击穿后，进入后端存储查询容易产生瓶颈，特别是基于对象存储，当然如果替换对象存储，使用 Cassandra 这样的 nosql 数据库，那么存储成本增加，另外也引入了一套复杂的组件来维护。
3. loki 主要为了成本考虑（存储成本、操作成本），所以决定期不适用于高性能数据处理（至少目前的架构来说）
4. loki 太过依赖于内存，内存、成本、效率、缓存这些有一些折中取舍，而且内存特别容易引发 OOM，并且不好控制，所以也不能将大量的数据丢在内存中
5. 分布式环境虽然可以增加 loki 的性能与扩展，但是引入的组件也较多，资源开销也大，也要做权衡