网站营销的流程,建二手车网站,手机网站建设视频教程,网络管理系统提供网络管理需要的大量运算和记忆资源背景分布式追踪的起源自从微服务的兴起开始#xff0c;整个系统架构开始变得极为庞大和复杂#xff0c;但是服务之间的调用关系#xff0c;调用消耗时间等等信息却依然是半黑盒的状态。为了能够将调用的链路进行串联#xff0c;将系统的各种指标数据展示出来以使得系统的链…背景分布式追踪的起源自从微服务的兴起开始整个系统架构开始变得极为庞大和复杂但是服务之间的调用关系调用消耗时间等等信息却依然是半黑盒的状态。为了能够将调用的链路进行串联将系统的各种指标数据展示出来以使得系统的链路更加透明便于排查故障分布式追踪便应运而生。百花齐放的分布式追踪ZipkinZipkin最初是由Twitter开发并与2012年开源的一款开源追踪系统。Zipkin的使用非常广泛影响了很多的后来人。他的传输头为X-B3SkywalkingSkywalking是由国人开发并且在后续捐赠给了Apache基金会的一个开源项目。现在是Apache基金会的顶级项目。PinpointPinpoint由Naver在2012年开发并于2015年开源。Pinpoint适用于javaphp和python。JaegerJaeger最早是由Uber开发并于2017年开源后续捐赠给了CNCF基金会。OpenTracingOpenTracing 的优势在于制定了一套无关厂商、无关平台的协议标准使开发人员只需要修改 Tracer 就可以更迅捷的添加或更换底层监控的实现被追踪的服务只需要调用相关 API 接口就可被任何实现这套接口的追踪后台支持。也是基于这一点2016 年云原生计算基金会 CNCF 正式接纳 OpenTracing顺利成为 CNCF 第三个项目。而前两个项目都已成为云原生及开源领域的事实标准–Kubernetes 和 PrometheusOpenTracing由CNCF托管具备较为完善的instrumentation库。遵循 OpenTracing 协议的产品有 Jaeger、Zipkin、 LightStep 和 AppDash 等追踪组件并可以轻松集成到 gRPC、Flask、Django 和 Go-kit 等开源框架中。MICROSERVICE PROCESSAPPLICATION CODEEXISTING INSTRUNENTATION CODE(LZIPKINLIGHTSTEPCONTROL FLOW FPAWEWORKSMAIN()OPENTRACINGAPPDAAK(MICRO-)SERVICE FRANEWORKSTRACERRPC FRANEWORKSVENDORSETC.OPEN TRACING STANDARDIZES THE DESCRIPTIONOF APPLICATION AND OSS PACKAGEBEHAVIOR BOTH WITHIN AND BETWEENTRACING INFRASTRUCTUREPROCESSES,ALL WHILE REMAININGVENDOR-NEUTRAL.CSON阿里巴巴云原生TIMEUNIQUEIDCONTEXT]EDGE SERVICE{CONTEXT]{CONTEXT]SPANSTRACECED{CONTEXT]{CONTEXT)DCSDN阿里巴巴云原生OpenCensusOpenCensus由Google发起最初是Google内部追踪平台后开源。OpenCensus 提供了统一的测量工具跨服务捕获跟踪跨度 Span、应用级别指标 Metrics。• 相较于 OpenTracing 只支持 TracesOpenCensus 支持 Traces 和 Metrics。• 相较于 OpenTracing 制定规范OpenCensus 不仅制定规范还包含了 Agent 和 Collector。• 家属团阵容相较 OpenTracing 更加庞大获得 Google、微软支持。收集库和应用记录的可观测结果汇总、导出统计数据并包括 Recording记录、Views聚合度量查询两部分。核心术语介绍除了沿用 OpenTracing 的相关术语之外OpenCensus 也定义了一些新术语。• TagsOpenCensus 允许在记录时将指标与维度相关联。从而能够从不同角度分析测量结果。• Stats收集库和应用记录的可观测结果汇总、导出统计数据并包括 Recording记录、Views聚合度量查询两部分。• Trace除了 Opentracing 所提供的 Span 属性之外OpenCensus 还支持 Parent SpanId、Remote Parent、Attributes、Annotations、Message Events、Links 等属性。• AgentOpenCensus Agent 是一个守护进程允许 OpenCensus 的多语言部署使用Exporter。与传统上为每个语言库和每个应用程序删除和配置 OpenCensus Exporter不同使用 OpenCensus Agent只需为其目标语言单独启用 OpenCensus Agent Exporter。对于运维团队而言实现单个 exporte 管理并从多语言应用程序中获取数据将数据发送到所选择的后端。与此同时尽可能的减少反复启动或部署对于应用的影响。最后Agent 还附带了“Receivers”。“Receivers”使 Agent 直通后端去接收可观测数据并将其路由到所选择的 Exporter。比如 Zipkin、Jaeger 或 Prometheus。OPENCENSUSOCSERVICE ACOLLECTORLIBJAEGEROCSERVICE BLIBOPENCENSUSZIPKINAGENTSERVICE CPROMETHEUSSTACKDRIVERZIPKINSERVICE DOTHER MONITORINGSERVICE EOTHERVMCSBAPRY阿里巴巴云原生• CollectorCollector 作为 OpenCensus 的重要组成部分由 Go 语言便编写可以从任何可用 Receivers 的应用中接受流量而不用关注编程语言以及部署方式而这个好处显而易见。对于提供 Metrics 和 Trace 的服务或应用而言只需要一个 Exporters 导出组件就能从多语言应用中获取数据。OPENCENSUSJAEGER/ZIPKINPROMETHEUS / STATSDOPENCENSUSJAEGERJAEGER/ZIPKINPROMETHEUSPROMETHEUS/STATSDZIPKINOPENCENSUS AGENT(AGENT)JAEGEROPENCENSUSOPENCENSUSCOLLECTORPROMETHEUSJAEGER/ZIPKINZIPKINPROMETHEUS/STATSDOPENCENSUS AGENT(SIDECAR)OPENCENSUSCOLLECTORHOSTOPENCENSUSDATADOGJAEGER/ZIPKINOMNITIONPROMETHEUS/STATSDSTACKDRIVEROPENCENSUS AGENT(DAEMONSET)CSDN阿里巴巴云原生• ExportersOpenCensus 可以通过各种 Exporter 实现将相关数据上传到各种后端比如Prometheus for stats、OpenZipkin for traces、Stackdriver Monitoring for stats and Trace for traces、Jaeger for traces、Graphite for stats。OpenCensus与OpenTracing在上述的项目中有两个项目较为特殊其一是OpenTracing他制定了一套无关平台的统一的Trace的标准后续的很多项目例如Jaeger等都是基于此协议因此他在当时的Trace标准领域具有不小影响力其二是OpenCensus他背靠Google并且它不仅仅实现了Trace还包括了Metrics并且他包含了一系列诸如Agent和Collector的方案可以说是相当完备。在当时这两大流派可以说是互相有一大票的追随者一边是以Google和微软领衔的OpenCensus一边是众多开源项目和厂商使用的OpenTracing两者可以说是各有优劣各领风骚。我们先看看一个典型服务问题排查过程是怎样的• 通过各式各样预设报警发现异常Metrics/Logs• 打开监控大盘查找异常现象并通过查询找到异常模块Metrics• 对异常模块以及关联日志进行查询分析找到核心的报错信息Logs• 通过详细的调用链数据定位到引起问题的代码Tracing为了能够获得更好的可观测性或快速解决上述问题Tracing、Metrics、Logs缺一不可。LOWREQUEST-SCOPED METRICSVOLUMEMETRICSAGGREGATABLETRACINGAGGREGATABLE EVENTSE.G. ROLLUPSREQUESTSCOPEDREQUEST-SCOPEDLOGGINGAGGREGATABLE EVENTSHIGHEVENTSREQUEST-SCOPED EVENTSVOLUMECSDN阿里巴巴云原生与此同时行业中已经有了丰富的开源及商业方案其中包括• MetricZabbix、Nagios、Prometheus、InfluxDB、OpenFalcon、OpenCensus• TracingJaeger、Zipkin、SkyWalking、OpenTracing、OpenCensus• LogsELK、Splunk、SumoLogic、Loki、Loggly。Opentelemetry为了更好的将 Traces、Metrics 和 Logs 融合在一起OpenTelemetry 诞生了。作为 CNCF 的孵化项目OpenTelemetry 由 OpenTracing 和 OpenCensus 项目合并而成是一组规范、API 接口、SDK、工具和集成。为众多开发人员带来 Metrics、Tracing、Logs 的统一标准三者都有相同的元数据结构可以轻松实现互相关联。稀士掘金技术社区OPENTELEMETRY稀土掘金技术社区Opentelemetry可以说是含着金汤匙出生OpenTracing支持OpenCensus支持刚开始就自带经验丰富的的社区人员同时背后也有互联网巨头的支持。OpenTelemetry 与厂商、平台无关不提供与可观测性相关的后端服务。可根据用户需求将可观测类数据导出到存储、查询、可视化等不同后端如 Prometheus、Jaeger 、云厂商服务中。优势OpenTelemetry 核心优势集中在以下部分• 规范的制定和协议的统一OpenTelemetry 采用基于标准的实现方法。对标准的关注对于 OpenTelemetry 来说尤其重要因为需要追踪跨语言的互操作性。许多语言都带有类型定义可以在实现中使用例如用于创建可重用组件的接口。包括可观测客户端内部实现所需要的规范以及可观测客户端与外部通信所需实现的协议规范。具体包括• API定义 Metrics、Tracing、Logs 数据的类型和操作。• SDK定义 API 特定语言实现需求定义配置、数据处理和导出概念。• 数据定义 OpenTelemetry Line Protocol OTLP。虽然在 Opentelemetry中组件支持了 Zipkin v2 或 Jaeger Thrift 协议格式的实现但都以第三方贡献库形式提供。只有 OTLP 是 Opentelemetry 官方原生支持的格式。OPEN TELEMETRY APISEMANTICCONTEXTTRACERMETERCONVENTIONSAPIAPIAPIMETERSHARED CONTEXTTRACERPROPAGATORINSTRUMENTSPANSPANPROCESSORPROCESSORAGGREGATORMETRICREADERSPANSPANMETRICMETRICEXPORTEROPEN TELEMETRY SDKEXPORTEREXPORTEREXPORTEROPEN TELEMETRYCOLLECTOREXTENSION POINTSPANMETRICEXPORTEREXPORTERVENDOR INGESTCSDN阿里巴巴云原生多语言 SDK 的实现和集成OpenTelemetry 为每个常见语言都实现了对应 SDK将导出器与 API 结合在一起。SDK 是具体的、可执行的 API 实现。包含 C、.NET、Erlang/Elixir、Go、Java、JavaScript、PHP、Python、Ruby、Rust、Swift。OpenTelemetry SDK 通过使用 OpenTelemetry API 使用选择的语言生成可观测数据并将该数据导出到后端。并允许为公共库或框架增强。用户可以使用 SDK 进行代码自动注入和手动埋点同时对其他三方库Log4j、LogBack 等集成支持这些包一般都是根据 opentelemetry-specification 里面的规范与定义结合语言自身的特点去实现在客户端采集可观测数据的基本能力。如元数据在服务间、进程间的传递Trace 添加监测与数据导出Metrics 指标的创建、使用及数据导出等。数据收集系统的实现在 Tracing 实践中有个基本原则可观测数据收集过程需要与业务逻辑处理正交。尽量减少可观测客户端对原有业务逻辑的影响Collector 是基于这个原则。OpenTelemetry 基于 OpenCensus Service 的收集系统包括 Agent 和 Collector。Collector 涵盖采集Collect、转换Transform和导出Export可观测数据的功能支持以多种格式例如 OTLP、Jaeger、Prometheus 等接收可观测数据并将数据发送到一个或多个后端。它还支持在输出可观测数据之前对其进行处理和过滤。Collector contrib 软件包支持更多数据格式和后端。从架构层面来说Collector 有两种模式。一种是把 Collector 部署在应用相同的主机内如Kubernetes 的 DaemonSet或者部署在应用相同的 Pod 里面如Kubernetes 中的 Sidecar应用采集到的遥测数据直接通过回环网络传递给 Collector。这种模式统称为 Agent 模式。另一种模式是把 Collector 当作一个独立的中间件应用把采集到的遥测数据往这个中间件里面传递。这种模式称之为 Gateway 模式。两种模式既可以单独使用也可以组合使用只需要数据出口的数据协议格式跟数据入口的数据协议格式保持一致。SigNozOpenTelemetry源自OpenSencuc和OpenTracing的合并它的目标是集成TraceMetricsLogging能力来提供可观测性。过去的分布式追踪往往是各做各的没有固定的标准各个分布式追踪方案各显神通使用不同的协议不同的标准。但是OpenTelemetry不同它提供了一系列的标准 是一个与供应商无关的仪器库。它提供了一组工具、API 和 SDK 来创建和管理遥测数据(TraceMetricsLogging)。所以我们更倾向选择原生支持 OpenTelemetry 协议的工具。而目前火热的 SigNoz 就是一个好的选择。SigNoz 是一个全栈开源应用程序性能监控和可观察性工具旨在原生支持 OpenTelemetry。它还提供了一个快速的 OLAP 数据库——ClickHouse 作为存储后端。带有开箱即用的应用程序指标图表。compareSigNoz vs PrometheusPrometheus is good if you want to do just metrics. But if you want to have a seamless experience between metrics and traces, then current experience of stitching together Prometheus Jaeger is not great.Our goal is to provide an integrated UI between metrics traces - similar to what SaaS vendors like Datadog provides - and give advanced filtering and aggregation over traces, something which Jaeger currently lack.SigNoz vs JaegerJaeger only does distributed tracing. SigNoz supports metrics, traces and logs - all the 3 pillars of observability.Moreover, SigNoz has few more advanced features wrt Jaeger:Jaegar UI doesn’t show any metrics on traces or on filtered tracesJaeger can’t get aggregates on filtered traces. For example, p99 latency of requests which have tag - customer_typepremium. This can be done easily on SigNozSigNoz vs ElasticSigNoz Logs management are based on ClickHouse, a columnar OLAP datastore which makes aggregate log analytics queries much more efficient50% lower resource requirement compared to Elastic during ingestionWe have published benchmarks comparing Elastic with SigNoz. Check it out hereSigNoz vs LokiSigNoz supports aggregations on high-cardinality data over a huge volume while loki doesn’t.SigNoz supports indexes over high cardinality data and has no limitations on the number of indexes, while Loki reaches max streams with a few indexes added to it.Searching over a huge volume of data is difficult and slow in Loki compared to SigNozWe have published benchmarks comparing Loki with SigNoz. Check it out here实践Trace无需改动代码只要启动应用的时候加个代理就可以把全链路的数据传进Signoz里了。java -javaagent:/agent/opentelemetry-javaagent.jar \
-Dotel.logs.exporterotlp \
-Dotel.exporter.otlp.endpointhttp://172.34.91.29:4317 \
-Dotel.resource.attributesservice.nameservice-provider \
-jar service-provider.jarLogging这一块需要侵入应用程序opentelemetry 使用 jaeger 生成 traceId并可以和 logback 集成通过 logback 的 mdc 注入到日志文件中。 dependencygroupIdio.opentelemetry.instrumentation/groupIdartifactIdopentelemetry-spring-boot-starter/artifactIdversion1.22.1-alpha/version/dependencydependencygroupIdio.opentelemetry.instrumentation/groupIdartifactIdopentelemetry-jaeger-spring-boot-starter/artifactIdversion1.22.1-alpha/version/dependencydependencygroupIdio.opentelemetry.instrumentation/groupIdartifactIdopentelemetry-logback-mdc-1.0/artifactIdversion1.22.1-alpha/version/dependency2、需要把我们的日志文件导入到 Signoz 里。Collecting Application Logs from Log file | SigNozMetricsSend Metrics to SigNoz | SigNoz
