当前位置： 首页 > news >正文

品牌推广网站怎样做,东莞人才网站,国家对网站建设有什么要求,百度ai助手入口目录 1 Skywalking应用2 agent下载3 agent应用3.1 应用名配置3.2 IDEA集成使用agent3.3 生产环境使用agent 4 Rocketbot4.1 Rocketbot-仪表盘4.2 Rocketbot-拓扑图4.3 追踪4.4 性能分析4.5 告警4.5.1 警告规则详解4.5.2 Webhook规则4.5.3 自定义Webhook消息接收 1 Skywalking应… 目录 1 Skywalking应用2 agent下载3 agent应用3.1 应用名配置3.2 IDEA集成使用agent3.3 生产环境使用agent 4 Rocketbot4.1 Rocketbot-仪表盘4.2 Rocketbot-拓扑图4.3 追踪4.4 性能分析4.5 告警4.5.1 警告规则详解4.5.2 Webhook规则4.5.3 自定义Webhook消息接收 1 Skywalking应用 相关术语 skywalking-collector:链路数据归集器数据可以落地ElasticSearch/H2 skywalking-ui:web可视化平台用来展示落地的数据 skywalking-agent:探针用来收集和发送数据到归集器2 agent下载 Skywalking-agent它简称探针用来收集和发送数据到归集器我们先来学习下探针使用探针对应的jar包在Skywalking源码中我们需要先下载源码。 Skywalking源码下载地址 https://archive.apache.org/dist/skywalking/ 我们当前使用的版本是8.3.0选择下载对应版本。 agent目录结构如下 agent├── activations│ ├── apm-toolkit-kafka-activation-8.3.0.jar│ ├── …│ └── apm-toolkit-trace-activation-8.3.0.jar├── config # Agent 配置文件│ └── agent.config├── logs # 日志文件├── optional-plugins # 可选插件│ ├── apm-customize-enhance-plugin-8.3.0.jar│ ├── apm-gson-2.x-plugin-8.3.0.jar│ └── … …├── bootstrap-plugins # jdk插件│ ├── apm-jdk-http-plugin-8.3.0.jar│ └── apm-jdk-threading-plugin-8.3.0.jar├── plugins # 当前生效插件│ ├── apm-activemq-5.x-plugin-8.3.0.jar│ ├── apm-armeria-0.84.x-plugin-8.3.0.jar│ ├── apm-armeria-0.85.x-plugin-8.3.0.jar│ └── … …├── optional-reporter-plugins│ └── kafka-reporter-plugin-8.3.0.jar└── skywalking-agent.jar【应用的jar包】目录结构说明 activations 当前skywalking正在使用的功能组件。agent.config 文件是 SkyWalking Agent 的唯一配置文件。plugins 目录存储了当前 Agent 生效的插件。optional-plugins 目录存储了一些可选的插件这些插件可能会影响整个系统的性能或是有版权问题如果需要使用这些插件需将相应 jar 包移动到 plugins 目录下。skywalking-agent.jar 是 Agent 的核心 jar 包由它负责读取 agent.config 配置文件加载上述插件 jar 包运行时收集到 的 Trace 和 Metrics 数据也是由它发送到 OAP 集群的。我们在使用Skywalking的时候整个过程中都会用到skywalking-agent.jar而无论是RPC还是HTTP开发的项目用法都一样因此我们讲解当前主流的SpringBoot项目对agent的使用即可。 3 agent应用 项目使用agent如果是开发环境可以使用IDEA集成如果是生产环境需要将项目打包上传到服务器。为了使用agent我们同时需要将下载的apache-skywalking-apm-bin文件包上传到服务器上去。不过无论是开发环境还是生产环境使用agent对项目都是无侵入式的。 3.1 应用名配置 我们需要用到agent此时需要将agent/config/agent.config配置文件拷贝到每个需要集成Skywalking工程的resource目录下我们将agent.config拷贝到工程\hailtaxi-parent的每个子工程目录下并修改其中的 agent.service_name修改如下 hailtaxi-gateway: agent.service_name\({SW_AGENT_NAME:hailtaxi-gateway} hailtaxi-driver: agent.service_name\){SW_AGENT_NAME:hailtaxi-driver} hailtaxi-order: agent.service_name\({SW_AGENT_NAME:hailtaxi-order}agent.config 是一个 KV 结构的配置文件类似于 properties 文件value 部分使用 “\){}” 包裹其中使用冒号:分为两部分前半部分是可以覆盖该配置项的系统环境变量名称后半部分为默认值。例如这里的 agent.service_name 配置项如果系统环境变量中指定了 SW_AGENT_NAME 值注意全是大写则优先使用环境变量中指定的值如果环境变量未指定则使用 hailtaxi-driver 这个默认值。 直接把配置修改好后放到项目的resource目录下(或者其他路径)是最不容易才出错的一种方式同时我们可以采用其他方式覆盖默认值 1)JVM覆盖配置 例如这里的 agent.service_name 配置项如果在 JVM 启动之前明确中指定了下面的 JVM 配置

skywalking.是 Skywalking环境变量的默认前缀

-Dskywalking.agent.service_name hailtaxi-driver2)探针配置覆盖 将 Java Agent 配置为如下

默认格式是 -javaagent:agent.jar[option1][value1],[option2][value2]

-javaagent:/path/skywalking-agent.jaragent.service_namehailtaxi-driver此时会使用该 Java Agent 配置值覆盖 agent.config 配置文件中 agent.service_name 默认值。 但是这些配置都有不同优先级优先级如下 探针配置 JVM配置 系统环境变量配置 agent.config文件默认值3.2 IDEA集成使用agent 1、修改agent中数据收集服务的地址agent/config/agent.confg collector.backend_service${SW_AGENT_COLLECTOR_BACKEND_SERVICES:192.168.200.129:11800}当然也可以同构JVM参数配置 2、使用探针配置为3个项目分别配置agent 1)hailtaxi-driver: -javaagent:C:\developer\skywalking\apache-skywalking-apm-bin\agent\skywalking-agent.jar -Dskywalking.agent.service_namehailtaxi-driver将上面配置赋值到IDEA中 2)hailtaxi-order -javaagent:C:\developer\skywalking\apache-skywalking-apm-bin\agent\skywalking-agent.jar -Dskywalking.agent.service_namehailtaxi-order将上面配置赋值到IDEA中 3)hailtaxi-gateway -javaagent:C:\developer\skywalking\apache-skywalking-apm-bin\agent\skywalking-agent.jar -Dskywalking.agent.service_namehailtaxi-gateway将上面配置赋值到IDEA中 此时启动IDEA并访问http://192.168.200.129:8080 效果如下 如果你要追踪Gateway的话你会发现无法通过gateway发现路由的服务链路 原因 Spring Cloud Gateway 是基于 WebFlux 实现必须搭配上apm-spring-cloud-gateway-2.1.x-plugin 和 apm-spring-webflux-x.x-plugin 两个插件 方案将agent/optional-plugins下的两个插件 复制到 agent/plugins目录下 3.3 生产环境使用agent 生产环境使用因此我们需要将agent和每个项目的jar包上传到服务器上上传apache-skywalking-apm-bin至/usr/local/server/skywalking再将工程\hailtaxi-parent中的项目打包并分别上传到服务器上如下三个工程 hailtaxi-order-1.0-SNAPSHOT.jar hailtaxi-gateway-1.0-SNAPSHOT.jar hailtaxi-driver-1.0-SNAPSHOT.jar1)启动hailtaxi-gateway java -javaagent:/usr/local/server/skywalking/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking.agent.service_namehailtaxi-gateway -jar hailtaxi-gateway-1.0-SNAPSHOT.jar 2)启动hailtaxi-driver java -javaagent:/usr/local/server/skywalking/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking.agent.service_namehailtaxi-driver -jar hailtaxi-driver-1.0-SNAPSHOT.jar 3)启动hailtaxi-order java -javaagent:/usr/local/server/skywalking/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking.agent.service_namehailtaxi-order -jar hailtaxi-order-1.0-SNAPSHOT.jar 4 Rocketbot 前面我们已经完成了SkyWalking环境搭建和项目应用agent使用我们来看如何使用 SkyWalking 提供的 UI 界面—— Skywalking Rocketbot。 OAP服务和Rocket其实就是个web项目均已启动 4.1 Rocketbot-仪表盘 具体细则可参考资料Skywalking仪表盘使用 Rocketbot从多个方面展示了服务信息我们分别从多个方面进行讲解。 上图中的【仪表盘】、【拓扑图】、【追踪】、【性能剖析】、【日志】、【警告】属于功能菜单。 仪表盘属于数据统计功能分别从服务热度、响应水平、服务个数、节点信息等展示统计数据。 Global Heatmap 面板热力图从全局展示了某段时间请求的热度。Global Percent Response 面板 展示了全局请求响应时间的 P99、P95、P75 等分位数。Global Brief 面板展示了 SkyWalking 能感知到的 Service、Endpoint 的个数。Global Top Troughput 面板展示了吞吐量前几名的服务。Global Top Slow Endpoint 面板展示了耗时前几名的 Endpoint。Service (Avg) ResponseTime 面板展示了指定服务的平均耗时。Service (Avg) Throughput 面板展示了指定服务的平均吞吐量。Service (Avg) SLA 面板展示了指定服务的平均SLAService Level Agreement服务等级协议。Service Percent Response 面板展示了指定服务响应时间的分位数。Service Slow Endpoint 面板展示了指定服务中耗时比较长的 Endpoint 信息。Running ServiceInstance 面板展示了指定服务下的实例信息。 除了 SkyWalking Rocketbot 默认提供的这些面板我们还可以点击锁型按钮自定义 Global 面板。在 ServiceInstance 面板中展示了很多 ServiceInstance 相关的监控信息例如JVM 内存使用情况、GC 次数、GC 耗时、CPU 使用率、ServiceInstance SLA 等等信息。 4.2 Rocketbot-拓扑图 【拓扑图】展示当前整个业务服务的拓扑图。点击拓扑图中的任意节点可以看到服务相应的状态信息其中包括响应的平均耗时、SLA 等监控信息。点击拓扑图中任意一条边还可以看到一条调用链路的监控信息其中会分别从客户端上游调用方和服务端下游接收方来观测这条调用链路的状态其中展示了该条链路的耗时、吞吐量、SLA 等信息。 4.3 追踪 【追踪】主要用来查询 Trace 信息如下图所示。在①处可以选择 Trace 的查询条件其中可以指定 Trace 涉及到的 Service、ServiceInstance、Endpoint 以及Trace 的状态继续模糊查询还可以指定 TraceId 和时间范围进行精确查询。在②处可以直接根据请求连接查找调用链路信息。在③处展示了 Trace 的简略信息。在④处可以选择不同的方式展示追踪信息。 在这里我们不仅能看到调用链路信息还能看到MySQL操作监控,如下图 错误异常信息也能追踪,如下图 4.4 性能分析 在传统的监控系统中我们如果想要得知系统中的业务是否正常会采用进程监控、日志收集分析等方式来对系统进行监控。当机器或者服务出现问题时则会触发告警及时通知负责人。通过这种方式我们可以得知具体哪些服务出现了问题。但是这时我们并不能得知具体的错误原因出在了哪里开发人员或者运维人员需要到日志系统里面查看错误日志甚至需要到真实的业务服务器上查看执行情况来解决问题。 如此一来仅仅是发现问题的阶段可能就会耗费相当长的时间另外发现问题但是并不能追溯到问题产生具体原因的情况也常有发生。这样反反复复极其耗费时间和精力为此我们便有了基于分布式追踪的APM系统。 通过将业务系统接入分布式追踪中我们就像是给程序增加了一个放大镜功能可以清晰看到真实业务请求的整体链路包括请求时间、请求路径甚至是操作数据库的语句都可以看得一清二楚。通过这种方式我们结合告警便可以快速追踪到真实用户请求的完整链路信息并且这些数据信息完全是持久化的可以随时进行查询复盘错误的原因。 然而随着我们对服务监控理解的加深我们发现事情并没有那么简单。在分布式链路追踪中我们有这样的两个流派代码埋点和字节码增强。无论使用哪种方式底层逻辑一定都逃不过面向切面这个基础逻辑。因为只有这样才可以做到大面积的使用。这也就决定了它只能做到框架级别和RPC粒度的监控。这时我们可能依旧会遇到程序执行缓慢或者响应时间不稳定等情况但无法具体查询到原因。这时候大家很自然的会考虑到增加埋点粒度比如对所有的Spring Bean方法、甚至主要的业务层方法都加上埋点。但是这种思路会遇到不小的挑战 第一增加埋点时系统开销大埋点覆盖不够全面。通过这种方式我们确实可以做到具体业务场景具体分析。但随着业务不断迭代上线弊端也很明显大量的埋点无疑会加大系统资源的开销造成CPU、内存使用率增加更有可能拖慢整个链路的执行效率。虽然每个埋点消耗的性能很小在微秒级别但是因为数量的增加甚至因为业务代码重用造成重复埋点或者循环使用此时的性能开销已经无法忽略。 第二动态埋点作为一项埋点技术和手动埋点的性能消耗上十分类似只是减少的代码修改量但是因为通用技术的特别上一个挑战中提到的循环埋点和重复使用的场景甚至更为严重。比如选择所有方法或者特定包下的所有方法埋点很可能造成系统性能彻底崩溃。 第三即使我们通过合理设计和埋点解决了上述问题但是JDK函数是广泛使用的我们很难限制对JDK API的使用场景。对JDK过多方法、特别是非RPC方法的监控会造成系统的巨大延迟风险。而且有一些基础类型和底层工具类是很难通过字节码进行增强的。当我们的SDK使用不当或者出现bug时我们无法具体得知真实的错误原因。 Skywalking中可以使用性能剖析分析特定端点的性能我们需要先创建一个监控任务 新建任务后在右侧可以查看任务性能分析报表还可以点击分析线程栈信息如下图 4.5 告警 SkyWalking 告警功能是在6.x版本新增的其核心由一组规则驱动这些规则定义在config/alarm-settings.yml文件中。 告警的定义分为两部分 告警规则它们定义了应该如何触发度量警报应该考虑什么条件。Webhook网络钩子定义当警告触发时哪些服务终端需要被告知 4.5.1 警告规则详解 Skywalking每隔一段时间根据收集到的链路追踪的数据和配置的告警规则如服务响应时间、服务响应时间百分比等判断如果达到阈值则发送相应的告警信息。发送告警信息是通过调用webhook接口完成具体的webhook接口可以使用者自行定义从而开发者可以在指定的webhook接口中编写各种告警方式比如邮件、短信等。告警的信息也可以在RocketBot中查看到。 我们可以进入到Skywalking容器中再进入到config文件夹下就可以看到alarm-settings.yml如下图 SkyWalking 的发行版都会默认提供config/alarm-settings.yml文件里面预先定义了一些常用的告警规则。如下

Licensed to the Apache Software Foundation (ASF) under one

or more contributor license agreements. See the NOTICE file

distributed with this work for additional information

regarding copyright ownership. The ASF licenses this file

to you under the Apache License, Version 2.0 (the

License); you may not use this file except in compliance

with the License. You may obtain a copy of the License at

#

http://www.apache.org/licenses/LICENSE-2.0

#

Unless required by applicable law or agreed to in writing, software

distributed under the License is distributed on an AS IS BASIS,

WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

See the License for the specific language governing permissions and

limitations under the License.# Sample alarm rules.

rules:# Rule unique name, must be ended with _rule.service_resp_time_rule:metrics-name: service_resp_timeop: threshold: 1000period: 10count: 3silence-period: 5message: Response time of service {name} is more than 1000ms in 3 minutes of last 10 minutes.service_sla_rule:# Metrics value need to be long, double or intmetrics-name: service_slaop: threshold: 8000# The length of time to evaluate the metricsperiod: 10# How many times after the metrics match the condition, will trigger alarmcount: 2# How many times of checks, the alarm keeps silence after alarm triggered, default as same as period.silence-period: 3message: Successful rate of service {name} is lower than 80% in 2 minutes of last 10 minutesservice_resp_time_percentile_rule:# Metrics value need to be long, double or intmetrics-name: service_percentileop: threshold: 1000,1000,1000,1000,1000period: 10count: 3silence-period: 5message: Percentile response time of service {name} alarm in 3 minutes of last 10 minutes, due to more than one condition of p50 1000, p75 1000, p90 1000, p95 1000, p99 1000service_instance_resp_time_rule:metrics-name: service_instance_resp_timeop: threshold: 1000period: 10count: 2silence-period: 5message: Response time of service instance {name} is more than 1000ms in 2 minutes of last 10 minutes

Active endpoint related metrics alarm will cost more memory than service and service instance metrics alarm.

Because the number of endpoint is much more than service and instance.

#

endpoint_avg_rule:

metrics-name: endpoint_avg

op:

threshold: 1000

period: 10

count: 2

silence-period: 5

message: Response time of endpoint {name} is more than 1000ms in 2 minutes of last 10 minuteswebhooks:

- http://127.0.0.1/notify/

- http://127.0.0.1/go-wechat/

告警规则配置项的说明 Rule name规则名称也是在告警信息中显示的唯一名称。必须以_rule结尾前缀可自定义Metrics name度量名称取值为oal脚本中的度量名目前只支持long、double和int类型。Include names该规则作用于哪些实体名称比如服务名终端名可选默认为全部Exclude names该规则作不用于哪些实体名称比如服务名终端名可选默认为空Threshold阈值OP 操作符目前支持 、、Period多久告警规则需要被核实一下。这是一个时间窗口与后端部署环境时间相匹配Count在一个Period窗口中如果values超过Threshold值按op达到Count值需要发送警报Silence period在时间N中触发报警后在TN - TN period这个阶段不告警。 默认情况下它和Period一样这意味着相同的告警在同一个Metrics name拥有相同的Id在同一个Period内只会触发一次message告警消息 在配置文件中预先定义的告警规则总结如下 在过去10分钟内服务平均响应时间超过1秒达3次在过去10分钟内服务成功率低于80%达2次在过去10分钟内服务90%响应时间低于1秒达3次在过去10分钟内服务的响应时间超过1秒达2次在过去10分钟内端点的响应时间超过1秒达2次 这些警告信息最终会在Skywalking-UI上展示效果如下 4.5.2 Webhook规则 Webhook配置其实是警告消息接收回调处理我们可以在程序中写一个方法接收警告信息Skywalking会以application/json格式通过http请求发送消息格式声明为Listorg.apache.skywalking.oap.server.core.alarm.AlarmMessage。 字段如下 scopeId, scope: 所有的scope实体在 org.apache.skywalking.oap.server.core.source.DefaultScopeDefine 里面声明。name. 目标scope实体名称。id0: scope实体ID匹配名称。id1: 不使用。ruleName: 配置在 alarm-settings.yml 里面的规则名称.alarmMessage: 告警信息.startTime触发告警的时间 示例 [{scopeId: 2,scope: SERVICE_INSTANCE,name: c00158f28efc45cd813e21b6b8848a3a192.168.1.104 of hailtaxi-driver,id0: aGFpbHpdmVy.1_YzAwMAMTkyLjE2OC4xLjEwNA\u003d\u003d,id1: ,ruleName: service_instance_resp_time_rule,alarmMessage: Response time of service instance c00158f28efc45cd813e21b6b8848a3a192.168.1.104 of hailtaxi-driver is more than 1000ms in 2 minutes of last 10 minutes,startTime: 1611612258056} ]4.5.3 自定义Webhook消息接收 我们按照如下步骤可以在自己程序中接收警告信息 1)定义消息接收对象 在hailtaxi-api中创建com.itheima.skywalking.model.AlarmMessage代码如下 Data ToString AllArgsConstructor NoArgsConstructor public class AlarmMessage {private int scopeId;private String name;private String id0;private String id1;private String alarmMessage;private long startTime;String ruleName; }2)接收警告方法创建 在hailtaxi-driver中创建com.itheima.driver.controller.AlarmMessageController用于接收警告消息代码如下 一般情况下这种接收告警的api会被放置在比较清闲的后台服务中 RestController RequestMapping(value /skywalking) public class AlarmMessageController {/**** 接收警告信息* param alarmMessageList*/PostMapping(/webhook)public void webhook(RequestBody ListAlarmMessage alarmMessageList) {for (AlarmMessage alarmMessage : alarmMessageList) {System.out.println(webhook:alarmMessage);}} }3)修改Webhook地址 修改alarm-settings.yml中的webhook地址 webhooks:

- http://127.0.0.1/notify/

- http://127.0.0.1/go-wechat/- http://192.168.200.10:8001/driver/skywalking/webhook因为skywalking默认有一个告警规则10分钟内服务成功率低于80%超过2次 所以为了能演示出告警效果我们在hailtaxi-driver项目中的driver/info接口中添加一个一句话 /***** 司机信息*///GetMapping(value /info/{id})RequestMapping(value /info/{id})public Driver info(PathVariable(value id)String id,HttpServletRequest request){int i 1/ 0; // 产生异常EnumerationString headerNames request.getHeaderNames();while (headerNames.hasMoreElements()){String name headerNames.nextElement();String value request.getHeader(name);System.out.println(name:value);System.out.println(————————–);}return driverService.findById(id);}测试时将网关的条件断言给注释一下 此时我们程序中就能接收警告信息了。