skywalking是什么
【1】skywalking是分布式系统的应用程序性能监视工具,专为微服务、云原生架构和基于容器(Docker、K8s、Mesos)架构而设计。SkyWalking 是观察性分析平台和应用性能管理系统,提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。
【2】主要流程为 采集数据——》传输数据——》存储数据——》分析数据——》监控报警 。
Skywalking整体架构
【1】图示:
【2】整个架构分成四部分:
1.上部分Agent :负责从应用中,收集链路信息,发送给 SkyWalking OAP 服务器;
2.下部分 SkyWalking OAP :负责接收Agent发送的Tracing数据信息,然后进行分析(Analysis Core),存储到外部存储器(Storage),最终提供查询(Query)功能;
3.右部分Storage:Tracing数据存储,目前支持ES、MySQL、Sharding Sphere、TiDB、H2多种存储器,目前采用较多的是ES,主要考虑是SkyWalking开发团队自己的生产环境采用ES为主;
4.左部分SkyWalking UI:负责提供控制台,查看链路等等;
SkyWalking中三个概念【搭建的话可以看 skywalking的搭建笔记】
【1】服务(Service) :表示对请求提供相同行为的一系列或一组工作负载,在使用Agent时,可以定义服务的名字;
【2】服务实例(Service Instance) :上述的一组工作负载中的每一个工作负载称为一个实例, 一个服务实例实际就是操作系统上的一个真实进程;
【3】端点(Endpoint) :对于特定服务所接收的请求路径, 如HTTP的URI路径和gRPC服务的类名 + 方法签名;
SkyWalking的简单使用
【1】通过jar包方式接入
1)编辑startup.sh脚本启动
#!/bin/sh # SkyWalking Agent配置 export SW_AGENT_NAME=springboot-skywalking-demo #Agent名字,一般使用`spring.application.name` export SW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800 #配置 Collector 地址。 export SW_AGENT_SPAN_LIMIT=2000 #配置链路的最大Span数量,默认为 300。 export JAVA_AGENT=-javaagent:/root/skywalking-agent/skywalking-agent.jar java $JAVA_AGENT -jar springboot-skywalking-demo-0.0.1-SNAPSHOT.jar #jar启动
2)java命令启动
java -javaagent:/root/skywalking-agent/skywalking-agent.jar
-DSW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800
-DSW_AGENT_NAME=springboot-skywalking-demo -jar springboot-skywalking-demo-0.0.1-SNAPSHOT.jar
3)在IDEA中使用Skywalking
在运行的程序配置jvm参数 -javaagent:E:\\SpringCloudAlibaba\\apache-skywalking-apm-bin-es7\\agent\\skywalking-agent.jar -DSW_AGENT_NAME=springboot-skywalking-demo -DSW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800
【2】自定义SkyWalking链路追踪【希望对项目中的业务方法,实现链路追踪,方便我们排查问题】
1)引入依赖
<!-- SkyWalking 工具类 --> <dependency> <groupId>org.apache.skywalking</groupId> <artifactId>apm-toolkit-trace</artifactId> <version>8.11.0</version> </dependency>
2)在业务方法中可以TraceContext获取到traceId
@RequestMapping(\"/list\") public List<User> list(){ //TraceContext可以绑定key-value TraceContext.putCorrelation(\"name\", \"fox\"); Optional<String> op = TraceContext.getCorrelation(\"name\"); log.info(\"name = {} \", op.get()); //获取追踪的traceId String traceId = TraceContext.traceId(); log.info(\"traceId = {} \", traceId); return userService.list(); }
3)注解@Trace将方法加入追踪链路
4)注解@Tags或@Tag为追踪链路增加其他额外的信息,比如记录参数和返回信息。实现方式:在方法上增加@Tag或者@Tags,示例:
@Trace @Tag(key = \"list\", value = \"returnedObj\") public List<User> list(){ return userMapper.list(); } @Trace @Tags({@Tag(key = \"param\", value = \"arg[0]\"), @Tag(key = \"user\", value = \"returnedObj\")}) public User getById(Integer id){ return userMapper.getById(id); }
SkyWalking的数据持久化
【1】基于mysql持久化
1)修改config目录下的application.yml
storage: #选择使用mysql 默认使用h2,不会持久化,重启skyWalking之前的数据会丢失 selector: ${SW_STORAGE:mysql} #使用mysql作为持久化存储的仓库 mysql: properties: #数据库连接地址 创建swtest数据库 jdbcUrl: ${SW_JDBC_URL:\"jdbc:mysql://1ocalhost:3306/swtest\"} #用户名 dataSource.user: ${SW_DATA_SOURCE_USER:root} #密码 dataSource.password: ${SW_DATA_SOURCE_PASSWORD:root}
2)添加mysql数据驱动包到oap-libs目录下【注意:需要添加mysql数据驱动包,因为在lib目录下是没有mysql数据驱动包的,所以修改完配置启动是会报错,启动失败的。】
3)启动Skywalking【查看swtest数据库,可以看到生成了很多表,那么就代表成功了】
【2】基于elasticsearch持久化
1)修改config目录下的application.yml
storage: selector: ${SW_STORAGE:elasticsearch} //指定ES作为存储 elasticsearch: nameSpace: ${SW_NAMESPACE:\"myProject-\"} //指定命名空间,用于生成索引前缀 clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:localhost:9200} //配置集群节点,当然可以采用负载均衡【然后把负载均衡的服务器ip与端口写入】,但也可以把节点都写进去 user: ${SW_ES_USER:\"myes\"} //es的用户名 password: ${SW_ES_PASSWORD:\"123456\"} //es的密码
2)启动Skywalking服务
启动时会向elasticsearch中创建大量的index索引用于持久化数据,启动应用程序,查看追踪数据是否已经持久化到elasticsearch的索引中,然后重启skywalking,验证追踪数据会不会丢失
Skywalking告警通知
【1】skywalking告警的核心由一组规则驱动,这些规则定义在config/alarm-settings.yml文件中,告警规则的定义分为三部分:
1.告警规则:它们定义了应该如何触发度量警报,应该考虑什么条件; 2.网络钩子(Webhook}:当警告触发时,哪些服务终端需要被通知; 3.gRPC钩子:远程gRPC方法的主机和端口,告警触发后调用;
【2】skywalking发行版中提供了默认的alarm-setting.yml文件,包括一些规则,每个规则有英文注释。
1)可以根据注释得知每个规则的作用:
# Sample alarm rules. rules: # Rule unique name, must be ended with `_rule`. service_resp_time_rule: metrics-name: service_resp_time op: \">\" threshold: 1000 period: 10 count: 3 silence-period: 5 #在最近10分钟的3分钟内服务平均响应时间超过1000ms message: 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 int metrics-name: service_sla op: \"<\" threshold: 8000 # The length of time to evaluate the metrics period: 10 # How many times after the metrics match the condition, will trigger alarm count: 2 # How many times of checks, the alarm keeps silence after alarm triggered, default as same as period. silence-period: 3 #最近10分钟内,服务成功率在2分钟内低于80% message: Successful rate of service {name} is lower than 80% in 2 minutes of last 10 minutes service_resp_time_percentile_rule: # Metrics value need to be long, double or int metrics-name: service_percentile op: \">\" threshold: 1000,1000,1000,1000,1000 period: 10 count: 3 silence-period: 5 message: 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 > 1000 service_instance_resp_time_rule: metrics-name: service_instance_resp_time op: \">\" threshold: 1000 period: 10 count: 2 silence-period: 5 #服务实例的响应时间在过去10分钟的2分钟内超过1000ms message: Response time of service instance {name} is more than 1000ms in 2 minutes of last 10 minutes database_access_resp_time_rule: metrics-name: database_access_resp_time threshold: 1000 op: \">\" period: 10 count: 2 #数据库访问{name}的响应时间在过去10分钟的2分钟内超过1000ms message: Response time of database access {name} is more than 1000ms in 2 minutes of last 10 minutes endpoint_relation_resp_time_rule: metrics-name: endpoint_relation_resp_time threshold: 1000 op: \">\" period: 10 count: 2 #端点关系{name}的响应时间在过去10分钟的2分钟内超过1000ms message: Response time of endpoint relation {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 minutes #需要自己手动打开 webhooks: - http://127.0.0.1/notify/ # - http://127.0.0.1/go-wechat/
2)参数说明:
metrics-name:度量名称,也是OAL脚本中的度量名。默认配置中可以用于告警的度量有:服务,实例,端点,服务关系,实例关系,端点关系。它只支持long,double和int类型。 op:操作符。 threshold:阈值。 period:多久告警规则需要被检查一下。这是一个时间窗口,与后端部署环境时间相匹配。 count:在一个周期窗口中,如果按op计算超过阈值的次数达到count,则发送告警 silence-period:在时间N中触发报警后,在N -> N + silence-period这段时间内不告警。 message:该规则触发时,发送的通知消息。
【3】实现回调接口
@RequestMapping(\"/notify\") public String notify(@RequestBody Object obj){ //TODO 告警信息,给技术负责人发短信,钉钉消息,邮件,微信通知等 System.err.println(obj.toString()); return \"notify successfully\"; }
【4】接入第三方告警,如对接钉钉(官方还提供了其他第三方的对接,文档地址:https://github.com/apache/skywalking/blob/master/docs/en/setup/backend/backend-alarm.md)
dingtalkHooks: textTemplate: |- { \"msgtype\": \"text\", \"text\": { \"content\": \"Apache SkyWalking Alarm: \\n %s.\" } } webhooks: - url: https://oapi.dingtalk.com/robot/send?access_token=dummy_token secret: dummysecret
【5】Webhook回调通知
SkyWalking告警Webhook回调要求接收方是一个Web容器(比如tomcat服务),告警的消息会通过HTTP请求进行发送, 请求方法为POST, Content-Type为application/json, JSON格式基于List<org.apache.skywalking.oap.server.core.alarm.AlarmMessage>的集合对象数据, 集合中的每个AlarmMessage包含以下信息:
scopeId. 所有可用的Scope,参考:org.apache.skywalking.oap.server.core.source.DefaultScopeDefine; name. 目标 Scope 的实体名称; id0. Scope 实体的 ID; id1. 未使用; ruleName. 在 alarm-settings.yml 中配置的规则名; alarmMessage. 报警消息内容; startTime. 告警时间, 位于当前时间与 UTC 1970/1/1 之间;
skywalking是分布式系统的应用程序性能监视工具,专为微服务、云原生架构和基于容器(Docker、K8s、Mesos)架构而设计。SkyWalking 是观察性分析平台和应用性能管理系统,提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。
来源:https://www.cnblogs.com/chafry/p/16801271.html
本站部分图文来源于网络,如有侵权请联系删除。