Grafana Tempo笔记04: 多租户支持和数据保留策略
启用多租户支持 Tempo是一个支持多租户的分布式追踪系统。它通过使用一个名为X-Scope-OrgID的header来实现多租户支持。 前面我们部署了Tempo，但使用OTEL Collector向其中推送追踪数据时并没有启用多租户支持，通过查看我们的MinIO存储中的数据也能确认。
#Tracing
← 全部文章Grafana Tempo笔记03: 使用OpenTelemetry Collector将跟踪数据发送Tempo
可以使用Grafana Agent将分布式追踪数据发送到Tempo，但这不是必需的。实际上，Tempo服务是一个暴露符合Open Telemetry TraceService标准的gRPC端点，通过HTTP Basic授权进行访问。任何能够使用正确的HTTP请求头调用该端点的工具都可以发送跟踪数据。
Grafana Tempo笔记02: 使用Helm安装Tempo
本文内容可能已过期 如何部署Tempo取决于我们的tracing需求。Tempo有两种部署模式：单体式或微服务式。当使用Helm在Kubernetes集群上部署Tempo时，对这两种模式都支持。 使用Tempo的Helm Charts可以在Kubernetes集群中配置、安装和升级Tempo。
Grafana Tempo笔记01: Tempo基础知识
Tempo介绍 Grafana Tempo是一个开源的、易于使用的且高吞容量的分布式追踪后端。Tempo具有成本效益高的特点，只需要一个对象存储来运行。Tempo可以和Grafana、Mimir、Prometheus和Loki 深度集成。可以使用Tempo与包括Jaeger、Zipkin或OpenTelemetry在内的开源追踪协议一起使用。
分布式跟踪系统Jaeger(三)：在Kubernetes上部署Jaeger
前面我们使用Jaeger的all in one docker镜像和Jaeger的HotROD示例应用简单试用了一下， 并对Jaeger的基本概念和组成做了初步了解。接下来该为了在生产环境中部署Jaeger做下一步的试验了。 本篇我们将尝试再Kubernetes集群上部署Jaeger，并使用我们已经存在的Elasticsearch集群作为数据存储。
分布式跟踪系统Jaeger(四)：使用Kubernetes的CronJob进行Jaeger的服务依赖分析
之前我们已经将Jaeger部署到了Kubernetes上，并且对Jaeger官方的示例应用HotROD进行了分布式跟踪。 我们使用Elasticsearch作为Jaeger的后端存储。借助Jaeger我们可以很容易的进行微服务架构应用的服务链调用追踪，进一步实现应用的性能分析和延迟优化。
分布式跟踪系统Jaeger(二)：Jaeger的基本概念
1.Opentracing Opentracing是一个分布式追踪标准，与平台和语言无关，统一接口，方便接入不同的分布式追踪系统。 Jaeger也是支持Opentracing标准的项目之一。学习jaeger有必要了解Opentracing规范。 以下是jaeger的文档资料：
分布式跟踪系统Jaeger(一)：Jaeger简介和示例应用HotROD
当使用微服务构建我们的程序时，客户端的一次请求会产生大量服务调用，包括服务和数据库等中间件的调用。 由单体应用迁移至微服务时，服务间调用的延迟是我们需要面对的一个问题。为了定位每次调用过程中的延迟问题和性能瓶颈，我们需要知道客户端一次请求所经历的过程，分别调用了哪些服务，调用每个服务花费的时长，以及调用每个服务花费的时长，这些将会成为我们性能调优的参考。因此，分布式追踪系统是微服务架构中不可缺少的一部分。
分布式跟踪系统Dapper的简单理解
现在一些开源的分布式调用跟踪系统大多都参考了Google的论文《Dapper，大规模分布式系统的跟踪系统》。 这里我们简单学习一下Dapper的基本概念。 分布式调用跟踪系统实际上是随着微服务才火起来的一个概念，当然Google在很多年前已经微服务化了，所以他的分布式跟踪理论应该是最成熟的。 分布式跟踪系统出现的原因简单的说是因为在分布式系统中一次请求中会包含很多的RPC，迫切需要一些可以帮助理解系统行为和分析性能问题的工具，需要断定具体哪个服务拖了后腿。