我们很高兴地宣布Linkerd 2.6增加了对分布式跟踪的支持!这意味着Linkerd数据平面代理,现在可以发出跟踪跨度(span),允许你查看请求在跟踪请求的Linkerd代理中花费的确切时间。由于在实践中使用分布式跟踪是相当困难的,在这篇文章中,我们收集了一个参考架构,并推荐了使用Linkerd进行分布式跟踪的最佳方法。
在本文结束时,您将了解如何使用 OpenTelemetry Operator 在应用程序中实现跟踪,而无需更改任何代码。
Hello folks,我是 Luga,今天我们来聊一下云原生生态核心技术—— 可观测性,即 “基于 OpenTelemetry 进行 Kubernetes 全链路观测” 。
Kubernetes 可用于导出指标、日志和事件以实现可观察性。事件是了解服务中正在发生的事情的丰富信息来源,并且可以使用多种工具来充分利用它们。
OpenTelemetry 是一种开源的可观测性框架,提供一组 API 和库,用于收集、处理和导出遥测数据,如追踪、指标和日志。它允许开发人员以最小的开销来检测他们的应用程序,并提供一种收集和导出遥测数据的标准化方法。
Jaeger:开源的端到端分布式跟踪,监视复杂的分布式系统中的事务并进行故障排除。 下图对比了常用的开源全链路追踪方案,目前SkyWalking和Pinpoint使用比较多,Jaeger相比客户端支持语言比较多,特别是对C++的支持,所以这次选择测试下。
1、固定采样(sampler.type=const)sampler.param=1 全采样, sampler.param=0 不采样。
在实践中使用分布式跟踪可能很复杂, 为了从高层次解释您得到了什么以及它是如何完成的, 我们整理了一个list of myths。
你可能已经知道Kubernetes是领先的容器编排系统。根据最新的CNCF 研究,可能已经将它用于生产工作负载或在未来一年考虑使用它。2021 年的研究发现,惊人的 96% 的受访者正在使用 Kubernetes 或计划在不久的将来使用它——而 69% 的受访者目前正在生产中使用 Kubernetes。Kubernetes 为大型组织和小型组织提供了许多好处:它提高了开发人员的生产力、降低了成本、提高了效率,并最终为最终用户带来了更好的体验。
Jaeger Agent是负责从已检测的应用程序接收跨度,并将其转发到Jaeger Collector的组件,以便适当地存储数据。除了充当应用程序和收集器之间的跨度缓冲区之外,Jaeger Agent还从收集器接收有关采样策略的更新,通过Jaeger客户端查询的REST端点提供所述策略,部署在已检测的应用程序中。
其中,最为核心的问题莫过于微服务分布式性质导致的运行问题,以及带来的 2 个至关重要的挑战:
基于解决不同行业、业务应用的可扩展性、可用性等一系列问题,由此而生的微服务架构得到了各大厂商的、组织以及个人的青睐,随之而来便广泛应用于各种行业场景应用中。然而,随着时间的推移,越来越多的问题慢慢地呈现在大众的视野中。
在生产环境中运行系统涉及到对高可用性、弹性和故障恢复的要求。在运行云原生应用程序时,这一点变得更加关键,因为在这种环境中,基本的假设是计算节点会中断,Kubernetes节点会宕机,微服务实例可能会失败,而服务预计会继续运行。
当谈到云原生可观察性时,可能每个人都会提到OpenTelemetry (OTEL),因为社区需要依赖标准来将所有集群组件开发指向到同一方向。OpenTelemetry 使我们能够将日志、指标(metrics)、跟踪(traces)和其他上下文信息组合到一个资源中。集群管理员或软件工程师可以使用此资源来获取在定义的时间段内集群中正在发生的事情的视图。
OpenTelemetry Operator 是一个用于部署和管理 OpenTelemetry 组件的 Kubernetes Operator。它是一个自定义的 Kubernetes 控制器,使用 Operator 模式自动化了 OpenTelemetry 环境的部署、配置和管理过程。
在可观察性里,指标是最能够从多方面去反映系统运行状况的。因为指标有各种各样,我们可以通过多维数据分析的方式来对系统的各个维度进行一个测量和监控。
在一个微服务分布式架构的系统中,可能存在复杂的、深层的层层服务调用关系,大致如下图
在构建应用程序时,了解系统的行为方式是运维它的重要部分——这包括能够观察应用程序的内部调用、衡量其性能并在问题发生时能够立即找到问题。这对任何系统来说都是具有挑战性的,对于由多个微服务组成的分布式系统更是如此,其中由多个调用组成的流可能在一个微服务中开始,但在另一个微服务中继续调用。可观测性在生产环境中至关重要,在开发过程中对于了解瓶颈、提高性能和跨微服务执行基本调试也很有用。
随着业务的发展,所有的系统都会走向微服务化体系,微服务进行拆分后,服务的依赖关系变得复杂,如果出现了错误和异常,定位的过程将会变得复杂,一个请求可能需要调用很多个服务,所以微服务架构中,分布式链路跟踪的实现至关重要,去跟进一个请求到底有哪些服务参与,参与的顺序又是怎样的,从而达到每个请求的步骤清晰可见。如何快速查询整个请求链路上的信息并呈现出来是解决排查问题复杂度的根本方法。
最新的Jaeger v1.35 版本[1]引入了通过OpenTelemetry 协议(OTLP)[2]接收 OpenTelemetry 追踪数据的能力,所有 OpenTelemetry SDK 都需要支持该协议。这是之前宣布淘汰 Jaeger“经典”客户端库[3]的后续。
因此,在实际的生产业务场景中,为了能够全方位地追踪每一个相关组件的行为轨迹,就需要一些能够可以帮助我们理解、追踪系统行为、用于分析性能问题的工具,以便发生故障的时候,能够快速定位和暴露问题之间的相关关键点,从而高效地解决问题。基于上述痛点,此时,APM 系统便应运而生。
目前监控k8s集群指标是SkyWalking v9版本新特性,配置的时候网上一篇文章没有,搞了很久,记录一下,经验之谈就是多番找GitHub中 Issues 和阅读官方文档。
第7章 可视化工具 分布式追踪 分布式追踪(Distributed Tracing)主要用于记录整个请求链的信息。在微服务应用中,一个完整的业务往往需要调用多个服务才能完成,服务之间就产生了交互。当出现故障时,如何找到问题的根源非常重要。追踪系统可以地展示出请求的整个调用链以及每一步的耗时,方便查找问题所在 本节主要介绍如何使用Jaeger在Istio中实现追踪 启动Jaeger Jaeger是一个开源的分布式追踪系统,它可以在复杂的分布式系统中进行监控和故障排查。Jaeger的主要功能包括分布式请求监控
与日志记录和可观察性一样,分布式追踪是保持服务健康和可预测的关键功能。与日志和可观察性(显示服务上发生了什么)相反,追踪允许开发人员和操作人员遵循特定的请求,以及它如何调用不同的服务和依赖关系。它是围绕微服务架构设计的,而微服务架构不同于单体架构,它使用许多小型服务来运行一个平台。这些服务彼此通信,也与外部服务通信,以提供和存储用户请求的信息。
Hello folks,我是 Luga,今天我们来分享一下与云原生体系有关的话题- 云原生可观测性-OpenTelemetry。 作为一个云原生“核心”标准,OpenTelemetry在观测分布式微服务应用程序和云基础设施的可见性和控制自动化层面具有举足轻重的意义。
访问日志提供了一种从单个工作负载实例的角度监控和理解行为的方法,同样访问日志是我们在生产环境中必不可少的一种监控手段,Istio 通过 Envoy 来提供访问日志功能,Envoy Proxy 打印访问信息到标准输出,Envoy 容器的标准输出能够通过 kubectl logs 命令打印出来。
Docker 是 Kubernetes Pod 中最常用的容器运行时,但 Pod 也能支持其他的容器运行,比如 rkt、podman等。
Navigational sextant by Lars Plöger via Pixabay
OpenTelemetry Collector 是由 OpenTelemetry 提供的独立服务。它可以用作遥测处理系统,具有许多灵活的配置选项,用于收集和管理遥测数据。让我们深入了解一下 OpenTelemetry Collector,以了解它的工作原理。
之前小白有讲到线上服务的可观察性在当下无论是运维还是研发的同学都是必须要掌握和了解的特性。对于当前服务可观察所要承担的功能,各大公司或社区也已基本形成共识,其主要也是围绕三个方向来提出要求:
微服务架构管理中最大的挑战之一是如何通过简单方法就能了解系统各个组件之间的关系。终端用户的一次会话可能会流经多个甚至几十个独立部署的微服务,因此,发现哪里有性能瓶颈或错误变得尤为重要。
opentelemetry是一套由CNCF主导的云原生可观测性的标准协议,全称:OpenTelemetry Protocol,简称OTLP。
现在越来越多的应用迁移到基于微服务的云原生的架构之上,微服务架构很强大,但是同时也带来了很多的挑战,尤其是如何对应用进行调试,如何监控多个服务间的调用关系和状态。如何有效的对微服务架构进行有效的监控成为微服务架构运维成功的关键。用软件架构的语言来说就是要增强微服务架构的可观测性(Observability)。
翻译自 How OpenTelemetry Works with Kubernetes 。
最近,OpenTelemetry宣布成为CNCF新的沙箱项目,由OpenTracing和OpenCensus[1]、[2]、[3]、[4]合并而成。已经有几个人问我,OpenTelemetry对Jaeger项目(在CNCF孵化阶段)意味着什么,以及它是否会取代Jaeger。我将在这篇文章中尝试回答这些问题。
Jaeger是一个基于opentracing规范的链路追踪工具,官方地址:https://www.jaegertracing.io/
微服务架构 作为云原生核心技术之一,提倡将单一应用程序划分成一组小的服务(微服务),服务之间互相协调、互相配合,为用户提供最终价值。
上一篇文章讲解了如何使用Azure DevOps持续部署应用到Azure Kubernetes上。但是部署是否成功?会不会遇到什么问题?项目运行中是否会出现问题?我们该怎么样查看这些问题,并且对问题进行针对性解决?这就是今天要讲的。
记一次完整的落地全链路监控项目的完整过程,我们来一起复盘下,我是如何进行技术选型的。
咱们以前单体应用里面有很多的应用和功能,依赖各个功能之间相互调用,使用公共的代码包等等,排查问题,使用类似于 gdb/dlv 工具或者直接查看代码日志,进行定位和分析
对于微服务实现或云原生架构来说,其中一个非常重要的点就是可观测性,分布式服务的本质决定了需要对它进行有效的度量与观测。
实现de 分布式链路追踪成了微服务的标配,随着opentracing标准的推出,jaeger+es几乎成了标配。它的架构如下
人工智能模拟人类解决故障的方法,可以实现民主化,并改善人们识别和修复 Kubernetes 问题的方式。
在近几个月对某产品后台微服务的SLI建设过程中,逐渐意识到这类监控的最佳方式还是通过jaeger/opentracing这类链式tracing才能以最佳的监控数据结构提供全链路的数据监控
查看一下相关的日志看看(kubectl describe pods test-pod):
k8spacket是用 Golang 编写的工具,它使用gopacket第三方库来嗅探工作负载(传入和传出)上的 TCP 数据包。它在运行的容器网络接口上创建 TCP 侦听器。当 Kubernetes 创建一个新容器时,CNI 插件负责提供与其他容器进行通信的可能性。最常见的方法是用linux namespace隔离网络并用veth pair连接隔离的 namespace 与网桥。除了bridge 类型,CNI 插件还可以使用其他类型(vlan, ipvlan,macvlan),但都为容器创建了一个网络接口,它是k8spacket嗅探器的主要句柄。
Kubernetes 已成为一个被广泛采用的行业工具,对可观测性工具的需求也在不断增加。为此,OpenTelemetry 创建了许多不同的工具,来帮助 Kubernetes 用户观察他们的集群和服务。
Grafana内置了对Jaeger的支持,它提供了开源的端到端分布式跟踪。本文解释了针对Jaeger数据源的配置和查询。
目前很多的大中小公司都在探索和实践着微服务这种软件开发架构,将复杂庞大的重量型项目通过明确定义的 API 拆分成多个小型可复用的独立服务单元或者说是服务组件,这样让应用程序更易于扩展和更快地开发,从而加速创新并缩短新功能的上市时间。但是复用和拆分依旧简化不了系统的复杂度,虽然微服务架构拆分了业务单元,但是各种组件之间的调用也是错中复杂,因此带来一系列的问题:
在Kubernetes中,每个容器都有自己的标准输出和标准错误输出,我们可以使用容器运行时提供的工具来采集这些输出,并将其重定向到日志文件中。例如,我们可以使用Docker提供的“docker logs”命令来查看容器的日志输出:
领取专属 10元无门槛券
手把手带您无忧上云