使用 Skywalking 实现全链路监控.docxVIP

使用 Skywalking 实现全链路监控 2021-01-07 一、分布式追踪 （一）三种场景 1、Metrics 目标性统计 比如说我们会去做一个服务的 TBS 的正确率、成功率、流量等，这是我们常见的针对单个目标或者某一个数据库的，这就是 Metrics 单目标分析。 2、Tracing 分布式追踪 这里提到的是一次恳求的范围，也就是我们从扫瞄器或者手机端发起任何的一次调用，甚至我们可以再推广一点，是一次业务训练，比如说一次订购的过程，从扫瞄商品到最终下定单、领取、物流、最终交到我们的手上。这是一个流程化的东西，我们需要轨迹，需要去追踪。 3、?Logging 日志记录 我们程序在执行的过程两头发生了一些日志，会一帧一帧地跳出来给大家去记录这个东西，这是日志记录。 假如你做一个监控的产品， 你需要明确本人的定位，每个领域实际上要关怀的事情是不一样的，而且这些领域之间会有交叉点。比如 Metrics 和 Logging 可能是之于某个目标的统计，但你通过日志的方式去做了一个搜集，最终统计了这些 Metrics 的信息，以及这些 Metrics 信息和对应的 Logging 的关系，那么你走的可能是 Metrics 和 Logging 之间的范围。假如你要去做 Metrics 和 Logging 两头的这些点，你需要清楚你是不是要付出这么大的代价。由于你每去占到这个圆中的一个部分，你的系统简单度、内存的开销、后端的存储都需要付出相应的代价。随着目标数、内容的加入，你所要投入的研发技术难度也在逐渐 上升。 所以大家在选择使用某一个分布式监控系统的时候，肯定要明确你使用它的目的是什么，精确地了解它们的定位！ （二）什么是分布式追踪 上图是常见的微服务的框架，4 个实例，2 个 MySQL、1 个 Redis。实际上它有两次完全不同的恳求进来：有一次的一个恳求会访问 Redis，再去访问 MySQL；另外一个可能走到另外的服务上，然后直接去 MySQL。整个分布式追踪的目的是什么？是为了让我们最终在页面上、UI上、和数据上能够复现这个过程。我们要拿到整个完整的链路，包括精确的响应时间，访问的方法、访问的 circle，访问的 Redis 的 key等，这些是我们在做分布式追踪的时候需要呈现的一个完整的信息。 （三）什么是 OpenTracing? 开发和工程团队由于系统组件水平扩展、开发团队小型化、灵敏开发、CD（持续集成）、解耦等各种需求，正在使用现代的微服务架构替换老旧的单片机系统。也就是说，当一个生产系统面对真正的高并发，或者解耦成大量微服务时，以前很简约实现的重点任务变得困难了。过程中需要面临一系列问题：用户体验优化、后台真是错误缘由分析，分布式系统内各组件的调用情况等。当代分布式跟踪系统（例如，Zipkin, Dapper, HTrace, X-Trace等）旨在处理这些问题，但是他们使用不兼容的API来实现各自的应用需求。虽然这些分布式追踪系统有着相像的API语法，但各种言语的开发人员照旧很难将他们各自的系统（使用不同的言语和技术）和特定的分布式追踪系统进行整合，OpenTracing 通过供应平台无关、厂商无关的 API，使得开发人员能够便利的添加（或更换）追踪系统的实现。OpenTracing 供应了用于运营支撑系统的和针对特定平台的协助程序库。 OpenTracing 是一个规范，它不是一个数据结构，能供应的是语音和概念。OpenTracing 要涵盖的是两头的一层，它是要实现的是一套 API 的套件。你需要依据 OpenTracing 的规范向用户供应 API，实现把数据下送到 API 的探针或者 Tracer 的探针。OpenTracing 的宗旨是在做手动埋点，程序的开发者要自动调用 Tracing 的 API 。我们这里次要是在讲 java ，而不是在讲例如 go、c++、c 等不太好写自动探针的言语。 二、Skywalking SkyWalking 是针对分布式系统的 APM 系统，也被称为分布式追踪系统 全自动探针监控，不需要修改应用程序代码。查看支持的两头件和组件库列表：/apache/incubator-skywalking 支持手动探针监控, 供应了支持 OpenTracing 标准的SDK。掩盖范围扩大到 OpenTracing-Java 支持的组件。查看OpenTracing组件支持列表：/opentracing-contrib/meta 自动监控和手动监控可以同时使用，使用手动监控弥补自动监控不支持的组件，甚至私有化组件。 纯 Java 后端分析程序，供应 RESTful 服务，可为其他言语探针供应分析力量。 高功能纯流式分析。 Skywalking 是去搜集数据，给出分析的