说明
官方一直在强调的一些字眼：
- Unlike other logging systems
- only indexing metadata
- S3 or GCS
- cheaper to operate
从官方文档里的一些关键字眼，以及这些天的实践和原理掌握来看，我们大致可以找出 loki 的适用场景。
场景说明
- loki 适用于查看日志解决故障
- loki 适用于少量的小范围内的日志查看，如 5 分钟内的日志，5 分钟前的 500 条日志
- loki 适用于分布式系统中日志查看，通过 app、pod 等纬度的标签可以定位到应用，也可以定位到实例
- loki 适用于通过日志定义告警
- loki 适用于基于 k8s 的云原生的服务发现与日志收集
- loki 适用于 prometheus 那套的 metrics、log、trace 江湖一统，当然这需要时间
loki 不适合
- loki 不适用于大型的数据聚合和统一分析，它本身的定位就不是代替 ELK 那套
- loki 不适用于查看如一天、一个礼拜这样的大范围查询，其本身的 cache 机制还不太完善，另外查询机制是先找内存，内存找不到就找存储，这对于内存的消耗有一定的要求和成本，另外内存击穿后，进入后端存储查询容易产生瓶颈，特别是基于对象存储，当然如果替换对象存储，使用 Cassandra 这样的 nosql 数据库，那么存储成本增加，另外也引入了一套复杂的组件来维护。
- loki 主要为了成本考虑（存储成本、操作成本），所以决定期不适用于高性能数据处理（至少目前的架构来说）
- loki 太过依赖于内存，内存、成本、效率、缓存这些有一些折中取舍，而且内存特别容易引发 OOM，并且不好控制，所以也不能将大量的数据丢在内存中
- 分布式环境虽然可以增加 loki 的性能与扩展，但是引入的组件也较多，资源开销也大，也要做权衡
