Elastic 微服务的分布式跟踪(ELK Stack)

让我们探索 ELK 堆栈上微服务的分布式跟踪。

每天‬分享‬最新‬软件‬开发‬,Devops,敏捷‬,测试‬以及‬项目‬管理‬最新‬,最热门‬的‬文章‬,每天‬花‬3分钟‬学习‬何乐而不为‬,希望‬大家‬点赞‬,评论,加‬关注‬,你的‬支持‬是我‬最大‬的‬动力‬。下方抖音有我介绍自动化测试,以及google cloud 相关视频课程,欢迎观看。
在这个瞬息万变的世界中,企业需要变得灵活,能够比以往更快地向客户交付变更。为了跟上这一点,软件系统和团队应该找到更快构建和更快部署的方法。进入微服务!

微服务

微服务架构是构建分布式系统的现代方式,可满足大多数此类需求。微服务是一组具有单一职责的小型、松散耦合、独立的服务。此架构中的软件应用程序构建为一组通过标准协议进行通信的服务,例如 HTTP(REST/SOAP API)、消息代理(Kafka、RabbitMQ)等。这种架构有很多好处:“小”使它们可以更快地构建和部署;“松散耦合”使它们与平台和技术无关,并且可以独立扩展。这也允许较小的两个披萨团队拥有和管理自己的服务集,无需重叠或需要更大的团队。

Elastic 微服务的分布式跟踪(ELK Stack)

微服务的缺点

微服务也有自己的问题。一些最常见的缺点是服务之间的复杂依赖关系,集成测试服务更加困难并且需要更多的存根,请求必须经过的最终响应的跳数可能会非常高,处理原子的复杂性跨服务的事务等等。

但是我们在这里要讨论的是调试跨越多个服务的请求所面临的挑战。 软件系统拥有数十个(甚至数百个)微服务的情况并不少见,并且通常在向客户端发送响应之前,对应用程序的大多数请求都会跨越两个以上的服务。在传统的单体应用中,如果请求失败或存在性能瓶颈,我们知道去哪里寻找问题——单个单体后端应用程序!使用微服务,很难找到问题所在的服务。如果一个请求通过n 个不同的服务,一些通过 HTTP,一些通过消息代理异步,那么调试就是一场噩梦。

分布式跟踪

分布式跟踪是可观察性的三大支柱之一——日志和指标是另外两个。分布式跟踪是一种在请求通过不同服务传播时观察它的方法,揭示它们中的每一个的行为方式——显示失败、每个步骤所花费的时间等等。OpenTelemetry 定义分布式跟踪如下:

分布式跟踪,通常称为Trace,记录请求(由应用程序或最终用户发出)在通过多服务架构(如微服务和无服务器应用程序)传播时所采用的路径。

追踪概念

Trace:请求通过各种服务时的端到端视图。迹线由跨度组成。

跨度:在单个服务中完成的单个工作单元。跟踪的主要构建块。具有关联的元数据,例如时间间隔。

标签:标签是用户或跟踪系统定义的键值对,丰富了查询、过滤和理解跟踪数据的范围。

跟踪日志:服务在请求时生成的日志是针对此特定跟踪处理的。此关联为更好的调试提供了更多的上下文数据。

Elastic 微服务的分布式跟踪(ELK Stack)

上图显示了跨三个不同服务跟踪的请求。请求employee-service首先到达,经过自己的一些操作后,leaves-service 通过 HTTP 调用,最后将请求放入 Kafka 主题中,由leaves-workflow-service.

分布式跟踪的工作原理

  • 接收请求的每个服务(包括第一个,因为它可能不知道它是第一个),并检查是否存在trace_id 关联(通常在请求标头中)。如果不存在(如果这是第一个服务),则该服务启动一个新的跟踪,设置一个唯一的trace_id,然后设置它。
  • 然后,该服务在跟踪下构建跨度,在所需的代码边界内启动和完成它们。每个服务可以创建多个跨度,每个跨度都将显示在该服务下的跟踪仪表板中
  • 该服务还可以为将通过请求传播的上下文信息(例如 ID)设置跟踪标签,并可用于稍后的查询、过滤和搜索。
  • 跟踪库(例如 Jaeger)自动捕获跨度和跟踪的开始和结束的时间戳。
  • 整个跟踪trace_id与关联的跨度、其元数据和标签一起被捕获。跟踪期间引发的任何错误也会在跟踪下捕获。
  • 跟踪完成后,信息将发送到服务器并在仪表板上进行可视化。

手动实现分布式跟踪

以上所有内容都可以使用 Jaeger 等库手动实现,并在 Jaeger 仪表板中可视化。本教程 展示了如何使用 Jaeger 为分布式跟踪检测和设置 Java 服务。由于以下原因,像这样的手动检测既麻烦又容易出错:

  • 可以通过其接收请求的每个访问点(API、消息使用者、计划的作业等)都需要手动编辑以进行跟踪——很容易错过一些。
  • 这需要为每项服务完成,并且您的服务都可以用不同的语言编写。
  • 这个概念并不容易,让每个(新)开发人员理解并遵循这一点可能很困难。

如果你像我一样,你会想要一个更简单的解决方案。

弹性 APM

Elastic APM 是建立在 Elastic Search 和 Kibana(ELK 堆栈的 E 和 K)之上的应用程序性能监控工具。实施 Elastic APM 非常简单——您只需将代理 jar 添加到您的服务并设置一些基本属性即可。这对每个服务执行一次,并启用对该服务的所有请求的分布式跟踪。

检测后可立即使用以下功能:

  • 检测服务的分布式跟踪——传入和传出的 HTTP 调用、数据库请求、缓存命中、计划的作业执行(如 Quartz)、消息代理通信等——所有这些都在 Kibana 的 APM 仪表板中可视化。
  • 自动捕获服务抛出的错误和异常(未处理)。Elastic 还会对错误进行分组以进行详细分析。
  • 链接日志和跟踪,为每个捕获的跟踪提供更多上下文信息。
  • 基本指标包括主机指标(CPU、内存、容器指标等)、代理特定指标(Java 应用程序的 JVM 指标)。

实施弹性 APM

在本节中,我将解释如何为Java 服务设置APM代理。Elastic APM 支持多种语言。

先决条件

  • 基于此处列出的 Elastic APM 支持的技术之一构建的服务。
  • Elastic Stack(Elastic Search,Kibana)的运行实例。这可以是自托管的 ELK 实例或Elastic Cloud帐户,即 Elastic 的 SaaS 产品。

第一步:在 pom.xml 中添加弹性代理依赖

XML


	co.elastic.apm
	apm-agent-attach
	${elastic-version} 

步骤 2:设置 APM 代理的属性

可以通过以下方式之一设置属性:

  1. elasticapm.propertiesclasspath
  2. Java 系统属性
  3. 环境变量

属性名称将根据其设置方式而有所不同。例如,要启用/禁用记录,属性将是recording (in elasticapm.properties)、elastic.apm.recording (in Java System Properties) 和ELASTIC_APM_RECORDING (in env variables)

以下是启动所需的属性:

属性文件

## minimum needed
recording=true
server_urls=
service_name=
environment=prod/dev/test/stage

secret.token=###############

注意: 虽然代理用于访问 Elastic 服务器的秘密令牌可以通过属性传递,但强烈建议将其作为 env 变量通过秘密存储(例如 Kubernetes Secrets)传递。

这里的属性至少是运行 APM 代理所需的。有关属性的完整列表,请参阅Elastic APM 代理配置文档。

第 3 步:在应用启动时附加代理

爪哇

@SpringBootApplication
public class MyApplication {
	public static void main(String[] args) {
      try {
			ElasticApmAttacher.attach();
		} catch (IllegalStateException e) {
			log.error("Error attaching Elastic APM", e);
		}
		SpringApplication.run(MyApplication.class, args);
	}
}

而已!对所有微服务重复这些步骤,部署它们,然后开始在 Kibana APM 仪表板上看到魔力!

附加提示

链接日志和跟踪

如果您要将日志发送到 ELK 堆栈,则可以通过将单个属性添加到elasticapm.properties. 这将链接日志和跟踪,并在 Kibana 的 APM 视图中提供特定于跟踪的日志。

属性文件

enable_log_correlation: "true" ##set to true by default in versions > 1.30

JSON 日志记录

如果您的服务记录纯文本消息,并且您希望结构化符合 Elastic 的 JSON 日志记录,请设置以下属性:

属性文件

log_elastic_reformatting=OVERRIDE

断路器

Elastic APM 代理是轻量级的,不会对您的应用程序性能产生任何明显影响。但是,此属性将让 Elastic 知道,如果系统指标达到某些限制,则应停止 APM 记录(并在低于限制时重新启动)。

circuit_breaker_enabled=true

stress_monitoring_interval=1 ##seconds
stress_monitor_gc_stress_threshold=0.95
stress_monitor_gc_relief_threshold=0.75
stress_monitor_system_cpu_stress_threshold=0.95
stress_monitor_system_cpu_refief_threshold=0.75
Elastic 微服务的分布式跟踪(ELK Stack)

发表评论
留言与评论(共有 0 条评论) “”
   
验证码:

相关文章

推荐文章