Loki最佳实践（译）
image.png
本文参考《Loki label best practice》，并结合小白实际的工作经验总结而来，不对的地方还请海涵。
1. 尽量使用静态标签
使用静态标签可以在日志时的开销更小。通常日志在发送到Loki之前，在注入label时，常见的推荐静态标签包含：
- 物理机：kubernetes/hosts
- 应用名：kubernetes/labels/app_kubernetes_io/name
- 组件名：kubernetes/labels/name
- 命名空间：kubernetes/namespace
- 其他kubernetes/label/* 的静态标签，如环境、版本等信息
2. 谨慎使用动态标签
过多的标签组合会造成大量的流，它会让Loki存储大量的索引和小块的对象文件。这些都会显著消耗Loki的查询性能。为避免这些问题，在你知道需要之前不要添加标签！loki的优势在于并行查询，使用过滤器表达式( lable = "text", |~ "regex", …)来查询日志会更有效，并且速度也很快。
那么，我该什么时候添加标签？
chunk_target_size默认为1MB，loki将以1MB的压缩后大小来切割日志块，大约等于5MB的原始日志文件（根据你配置的压缩级别来决定）。如果在max_chunk_age时间内，你的日志流足以生成一个或者多个压缩块，那么你可以考虑添加标签，将日志流拆得更细一点。从Loki 1.4.0开始，有一个指标可以帮助我们了解日志块刷新的情况
sum by (reason) (rate(loki_ingester_chunks_flushed_total{cluster="dev"}[1m]))
3. 有界的标签值范围
不管怎样，到最后如果你不得不采用动态标签的话，那你也要注意控制标签的范围和value值的长度。举个例子，如果你想将nginx的访问日志提取一些字段后存储到loki，
{"@timestamp":"2020-09-30T12:16:07+08:00","@source":"172.16.1.1","hostname":"node1","ip":"-","client":"172.16.2.1","request_method":"GET","scheme":"https","domain":"xxx.com","referer":"-","request":"/api/v1/asset/asset?page_size=-1&group=23","args":"page_size=-1&group=23","size":975,"status": 200,"responsetime":0.065,"upstreamtime":"0.064","upstreamaddr":"172.16.3.1:8080","http_user_agent":"python-requests/2.22.0","https":"on"}
这里面@source代表客户端源地址，由于源地址是公网地址，那么在建立loki标签时它的值就是个无界的。 再比如这里面@request代表请求URL。可能存在某些请求参数过长，loki的标签值也会过大。如果再将两者相乘，那么这个标签的规模是无法接受的。
以上这种情况是比较属于典型无界的动态标签值，在loki里面我们用Cardinality来表述它，Cardinality值越高，loki的查询效率越低。。Loki社区给出动态标签的范围应尽量控制在10以内。
4. 客户端应用的动态标签
Loki的几个客户端（Promtail、Fluentd，Fluent Bit，Docker插件等）都带有配置标签来创建日志流的方法。我们有时需要在loki里面去排查哪些应用使用了动态标签，这时候我们可以用logcli工具来辅助我们。在Loki1.6.0及更高版本中，logcli series命令添加了--analyze-labels参数专门用于调试高cardinality的标签。例如：
$ logcli series --analyze-labels '{app="nginx"}'
Total Streams: 25017
Unique Labels: 8
Label Name Unique Values Found In Streams
requestId 24653 24979
logStream 1194 25016
logGroup 140 25016
accountId 13 25016
logger 1 25017
source 1 25016
transport 1 25017
format 1 25017
可以看到这里面requestId这个标签就有24653个值，这是非常不好的。我们应该将requestId从label里面去删除,通过这种方式查询
{app="nginx"} |= "requestId=1234567"
5. 配置缓存
关于loki的缓存，可以参考小白之前的文章《巧用缓存加速Loki查询》
缓存在Loki的应用比较灵活，你可以让loki所有组件公用一个缓存，也可以让每个loki组件单独使用自己的缓存，具体可以参考小白前面关于loki分布式部署的相关文章
6. 日志的时间必须顺序递增
对于一个日志流里面出现时间戳早于该流收到的最新日志，那么这条日志将被删除
{job=”syslog”} 00:00:00 i’m a syslog!
{job=”syslog”} 00:00:02 i’m a syslog!
{job=”syslog”} 00:00:01 i’m a syslog! \\这条日志会被删除
如果你的服务是分布式跑在多个节点上，而且存在时间差的话，那你只有为这类日志添加新的标签来存储了
{job=”syslog”, instance=”host1”} 00:00:00 i’m a syslog! \\新日志流1
{job=”syslog”, instance=”host1”} 00:00:02 i’m a syslog!
{job=”syslog”, instance=”host2”} 00:00:01 i’m a syslog! \\新日志流2
{job=”syslog”, instance=”host1”} 00:00:03 i’m a syslog! \\在日志流1里时间有序
{job=”syslog”, instance=”host2”} 00:00:02 i’m a syslog! \\在日志流2里时间有序
这个没啥好说的，小白建议日志采集时按照客户端的时间为每条日志添加时间戳。如果你的时间戳是从应用日志里面提取出来，并且出现时间乱序的话，那还是请你先解决应用的问题😂
7. 使用chunk_target_size参数
上文说到chunk_target_size可以有效的将日志流压缩到一个合理的空间大小，Loki中每个日志流都包含一个块。如果我们将日志文件分解成更多的流，内存中存储的块就越多，在被刷新到磁盘之前，理论上来说都有丢日志的风险。那么这个时候就需要组合max_chunk_age默认1h和chunk_idle_period默认30m，来控制日志刷新的超时时间。
8. 使用-print-config-stderr或-log-config-reverse-order参数
从1.6.0版开始，Loki和Promtail支持这类参数，当启动时，loki会把整个配置信息打印到stderr或日志文件中。，这样我们可以快速看到整个Loki配置，便于调试。
当这个参数-log-config-reverse-order启用时，我们在grafna上查询loki时将以顺序的方式查看日志，这个可以让我们更加方便一点。
9. 使用query-frontend
query-frontend可以有效的将日志查询拆分成多个小查询分发给querier去并发执行。这件极大的提高loki的查询效率，理论上来说你可以扩容上百个querier去并发处理GB或者TB级别的日志，不过前提是你的查询客户端能够容得下这些日志。😃
关于云原生小白
云原生小白的创号目的是将平日里离大家较远云原生应用以实用的角度展现出来，站在小白的角度来看待和使用云原生，并以每篇文章解决一个实际问题的出发点带领大家走进云原生。
