最近将一个项目的可观测性方案从Logs(ElasticSearch,Fuentbit,Kibana), Traces(Jaeger+OpenTracing)迁移到了OpenTelemetry。此项目由多个微服务组成，部署在一个Kubernetes集群中。 OpenTelemetry Collector由OpenTelemetry K8S Operator管理，并以DaemonSet的形式部署在Kubernetes集群的各个节点上。即每个K8S节点上都有一个OTEL Collector Agent进程负责收集并处理本节点上微服务Pod实例的Logs, Traces, Metrics数据，并将Logs, Traces数据发送到后端的日志存储(Loki或ES)、Traces数据存储(Jaeger或Tempo)，同时将Metrics数据暴露给Prometheus。
...Tempo是一个支持多租户的分布式追踪系统。它通过使用一个名为X-Scope-OrgID的header来实现多租户支持。
前面我们部署了Tempo，但使用OTEL Collector向其中推送追踪数据时并没有启用多租户支持，通过查看我们的MinIO存储中的数据也能确认。
...可以使用Grafana Agent将分布式追踪数据发送到Tempo，但这不是必需的。实际上，Tempo服务是一个暴露符合Open Telemetry TraceService标准的gRPC端点，通过HTTP Basic授权进行访问。任何能够使用正确的HTTP请求头调用该端点的工具都可以发送跟踪数据。
...如何部署Tempo取决于我们的tracing需求。Tempo有两种部署模式：单体式或微服务式。当使用Helm在Kubernetes集群上部署Tempo时，对这两种模式都支持。
使用Tempo的Helm Charts可以在Kubernetes集群中配置、安装和升级Tempo。
...Grafana Tempo是一个开源的、易于使用的且高吞容量的分布式追踪后端。Tempo具有成本效益高的特点，只需要一个对象存储来运行。Tempo可以和Grafana、Mimir、Prometheus和Loki 深度集成。可以使用Tempo与包括Jaeger、Zipkin或OpenTelemetry在内的开源追踪协议一起使用。
...kubeadm是Kubernetes官方提供的用于快速安部署Kubernetes集群的工具。伴随Kubernetes每个版本的发布，kubeadm可能会对集群配置方面的一些实践做调整，通过实验kubeadm可以学习到Kubernetes官方在集群配置上一些新的最佳实践。
...前面学习了Loki中日志的保留策略，本文整理一下对于使用Loki官方helm chart部署Loki时如何在values.yaml中配置日志保留策略。
所有的配置参考都可以在这个helm chart的默认的values.yaml中获得，地址是https://github.com/grafana/loki/blob/main/production/helm/loki/values.yaml。
基于默认的values.yaml结合前面已经学习的保留策略配置，对我们使用的values.yaml定制如下(下面只保留了"保留策略相关的配置"):
...BoltDB Shipper使您能够在不依赖于NoSQL存储的情况下运行Loki，用来存储索引。它将索引以BoltDB文件的形式在本地存储，并将这些文件发送到共享对象存储(即用于存储数据块chunks的相同对象存储)。它还通过从共享对象存储同步BoltDB文件到配置的本地目录，获取由同一Loki集群的其他服务创建的索引。这样可以在运行Loki时减少一个依赖项，并且在存储方面节省成本，因为对象存储很可能比托管或运行自托管的NoSQL存储实例的成本更低。
...Loki需要存储两种不同类型的数据：块（chunks）和索引（indexes）。
Loki接收来自不同流的日志，每个流通过其租户ID和标签集来唯一标识。当来自流的日志条目到达时，它们会被压缩为“块”(chunks)并保存在块存储(chunks存储)中。
...前面学习了Promtail的基础知识和配置示例，本节做一个实战练习，使用Promtail收集Java应用日志发送给Loki。
这里假设的场景是一个Spring Boot的Java程序，日志框架使用了Logback。这个程序使用Logback将日志以文件形式写到磁盘上。 Logback的配置如下:
...