本文参考《Loki labe 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，来控制日志刷新的超时时间。