skywalking 安装_如何使用skywalking 进行全链路监控
本文涉及内容
- skywalking 全链路监控
- skywalking 的参数配置
- skywalking UI 监控视角与指标介绍
- 一些很有用的点
skywalking 全链路监控
下图是我从网上找到的一个比较常见的微服务架构,看得出来使用的是 spring cloud 框架组件,后端服务是 java。我所谓的全链路监控是 从 Nginx 到数据库 这个链路的监控。
我们知道 skywalking 可以通过 agent 比较方便的监控到后端的 java 应用。有关 skywalking 的安装请参考官方文档[1]
以下是几个界面截图:通过 skywalking , 我们可以从服务入口开始一直监控到数据库,甚至是数据库的 sql 以及参数都可以一览无余(sql 参数显示需要单独配置,后面会讲)。
然而我们并没有监控到请求的上游源头,即 Nginx 入口,如果我们将从 Nginx 入口来的并且经由 java 服务最终到数据库的请求全部监控起来,就完成了请求的全链路监控。上面我们处理了下半段,现在我们来处理上半段。
skywalking-nginx-lua[2] 这是 skywalking 的另一个项目,可以通过它来对nginx进行监控。skywalking-nginx-lua 是使用lua来织入 agent 的。所以要求你的 nginx 要么有 lua 模块,要么用 openResty 这样的自带 Lua 功能模块的软件。
我使用的是openResty,只需要加以下配置就可以实现监控(注意中文注释部分):
http { lua_package_path "/Path/to/.../skywalking-nginx-lua/lib/skywalking/?.lua;;"; # Buffer represents the register inform and the queue of the finished segment lua_shared_dict tracing_buffer 100m; # Init is the timer setter and keeper # Setup an infinite loop timer to do register and trace report. init_worker_by_lua_block { local metadata_buffer = ngx.shared.tracing_buffer -- Set service name metadata_buffer:set('serviceName', 'User Service Name') -- Instance means the number of Nginx deployment, does not mean the worker instances metadata_buffer:set('serviceInstanceName', 'User Service Instance Name') #这是你的skywalking server地址 require("client"):startBackendTimer("http://127.0.0.1:12800") } server { listen 8080; location /ingress { default_type text/html; rewrite_by_lua_block { ------------------------------------------------------ -- NOTICE, this should be changed manually -- This variable represents the upstream logic address -- Please set them as service logic name or DNS name -- -- Currently, we can not have the upstream real network address ------------------------------------------------------ require("tracer"):start("upstream service") -- If you want correlation custom data to the downstream service -- require("tracer"):start("upstream service", {custom = "custom_value"}) } # 这是你的目标下游服务,比如java的微服务网关 proxy_pass http://127.0.0.1:8080/backend; body_filter_by_lua_block { if ngx.arg[2] then require("tracer"):finish() end } log_by_lua_block { require("tracer"):prepareForReport() } } }}
下面是几个监控到的nginx数据的截图
至此我们就完成了整个链路的监控。
skywalking 的参数配置
一些中文文档
- agent的文档[3]
- ui的文档[4]
通过修改agent/config/agenet.config 文件得到的能力
根据文档 https://github.com/apache/skywalking/blob/v8.0.0/docs/en/setup/service-agent/java-agent/README.md 得知
- 1 可以获取 sql中的参数,默认是获取不到的。当然还要设置参数最大长度。但获取参数有可能引起性能问题。
- 2 收集http参数
#收集SpringMVC plugin插件请求参,在tomcat上时这俩设置一个即可plugin.tomcat.collect_http_params or plugin.springmvc.collect_http_params plugin.springmvc.collect_http_params=true #请求参数收集的最大字符长度, 配置过大会影响性能. plugin.http.http_params_length_threshold=1024
- 3 skywalking-oap 的配置文件中关于数据存储时长的配置
core: selector: ${SW_CORE:default} default: # Mixed: Receive agent data, Level 1 aggregate, Level 2 aggregate # Receiver: Receive agent data, Level 1 aggregate # Aggregator: Level 2 aggregate role: ${SW_CORE_ROLE:Mixed} # Mixed/Receiver/Aggregator restHost: ${SW_CORE_REST_HOST:0.0.0.0} restPort: ${SW_CORE_REST_PORT:12800} restContextPath: ${SW_CORE_REST_CONTEXT_PATH:/} gRPCHost: ${SW_CORE_GRPC_HOST:0.0.0.0} gRPCPort: ${SW_CORE_GRPC_PORT:11800} gRPCSslEnabled: ${SW_CORE_GRPC_SSL_ENABLED:false} gRPCSslKeyPath: ${SW_CORE_GRPC_SSL_KEY_PATH:""} gRPCSslCertChainPath: ${SW_CORE_GRPC_SSL_CERT_CHAIN_PATH:""} gRPCSslTrustedCAPath: ${SW_CORE_GRPC_SSL_TRUSTED_CA_PATH:""} downsampling: - Hour - Day - Month # Set a timeout on metrics data. After the timeout has expired, the metrics data will automatically be deleted. enableDataKeeperExecutor: ${SW_CORE_ENABLE_DATA_KEEPER_EXECUTOR:true} # Turn it off then automatically metrics data delete will be close. dataKeeperExecutePeriod: ${SW_CORE_DATA_KEEPER_EXECUTE_PERIOD:5} # How often the data keeper executor runs periodically, unit is minute recordDataTTL: ${SW_CORE_RECORD_DATA_TTL:3} # Unit is day metricsDataTTL: ${SW_CORE_RECORD_DATA_TTL:7} # Unit is day
主要是这四行
enableDataKeeperExecutor: ${SW_CORE_ENABLE_DATA_KEEPER_EXECUTOR:true} # Turn it off then automatically metrics data delete will be close.dataKeeperExecutePeriod: ${SW_CORE_DATA_KEEPER_EXECUTE_PERIOD:5} # How often the data keeper executor runs periodically, unit is minuterecordDataTTL: ${SW_CORE_RECORD_DATA_TTL:3} # Unit is daymetricsDataTTL: ${SW_CORE_RECORD_DATA_TTL:7} # Unit is day
skywalking UI 监控视角与指标介绍
cpm 每分钟请求数
cpm 全称 call per minutes,是吞吐量(Throughput)指标。下图是拼接的全局、服务、实例和接口的吞吐量及平均吞吐量。
第一条185cpm=185/60=3.08个请求/秒。
SLA 服务等级协议
SLA 全称 Service-Level Agreement,直译为 “服务等级协议”,用来表示提供服务的水平。在IT中,SLA可以衡量平台的可用性,下面是N个9的计算:
- 1年 = 365天 = 8760小时
- 99 = 8760 * 1% => 3.65天
- 99.9 = 8760 * 0.1% => 8.76小时
- 99.99 = 8760 * 0.01% => 52.6分钟
- 99.999 = 8760 * 0.001% => 5.26分钟
因此,全年只要发生一次较大规模宕机事故,4个9肯定没戏,一般平台3个9差不多。但2个9就基本不可用了,相当于全年有87.6小时不可用,每周(一个月按4周算)有1.825小时不可用。下图是服务、实例、接口的SLA,一般看年度、月度即可。
Percent Response 百分位数统计
表示采集样本中某些值的占比,Skywalking 有 p50、p75、p90、p95、p99 一些列值。其中的 “p99:390” 表示 99% 请求的响应时间在390ms以内。而99%一般用于抛掉一些极端值,表示绝大多数请求。
Slow Endpoint 慢端点
Endpoint 表示具体的服务,例如一个接口。下面是全局Top N的数据,通过这个可以观测平台性能情况。
Heatmap 热力图
Heapmap 可译为热力图、热度图都可以,其中颜色越深,表示请求数越多,这和GitHub Contributions很像,commit越多,颜色越深。横坐标是响应时间,鼠标放上去,可以看到具体的数量。通过热力图,一方面可以直观感受平台的整体流量,另一方面也可以感受整体性能。
apdex
是一个衡量服务器性能的标准。apdex有三个指标:
- 满意:请求响应时间小于等于T。
- 可容忍:请求响应时间大于T,小于等于4T。
- 失望:请求响应时间大于4T。
T:自定义的一个时间值,比如:500ms。apdex = (满意数 + 可容忍数/2)/ 总数。例如:服务A定义T=200ms,在100个采样中,有20个请求小于200ms,有60个请求在200ms到800ms之间,有20个请求大于800ms。计算apdex = (20 + 60/2)/100 = 0.5。
一些很有用的点
在拓扑图中
红色代表当前节点的请求有一段时间内是响应异常的。当节点全部变红的时候证明服务现阶段内就彻底不可用了。我们可以通过Topology迅速发现某一个服务潜在的问题,并进行下一步的排查并做到预防。
仔细看线是有流向的,有单向和双向的,单向有从左至右的或从右至左的,这样你就知道你的服务是谁依赖了谁。双向的就证明你的服务有循环引用依赖问题。
在最新版本8.1中有endpoint端口依赖的分析,可以分析出接口级别的依赖关系,可以知道某接口是被谁调用,它又调用了谁。
关注公众号 获取更多精彩内容
参考资料
[1]
skywalking官方文档: https://github.com/apache/skywalking/blob/master/docs/en/setup/README.md
[2]
skywalking-nginx-lua项目地址: https://github.com/apache/skywalking-nginx-lua/
[3]
skywalking-agent文档: https://skyapm.github.io/document-cn-translation-of-skywalking/zh/8.0.0/setup/service-agent/java-agent/
[4
skywalking-ui 文档: https://skyapm.github.io/document-cn-translation-of-skywalking/zh/8.0.0/ui/
skywalking 安装_如何使用skywalking 进行全链路监控相关推荐
- 实现一个全链路监控平台很难吗?Pinpoint、skywalking、zipkin,哪个实现比较好?...
点击上方蓝色"方志朋",选择"设为星标"回复"666"获取独家整理的学习资料! 随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往 ...
- 使用Skywalking实现全链路监控
https://opentalk.upyun.com/334.html 2017 年 10 月 29 日,又拍云 Open Talk 联合 Spring Cloud 中国社区成功举办了"进击 ...
- 一文带你入坑全链路监控,skywalking
一,APM概念介绍 APM(Application Performance Management)对应用程序性能和可用性的监控管理系统.它主要有这三个方面的内容,分别是 Logs(日志). Trace ...
- 使用 Skywalking 实现全链路监控
2017 年 10 月 29 日,又拍云 Open Talk 联合 Spring Cloud 中国社区成功举办了"进击的微服务实战派北京站".华为技术专家吴晟作了题为<使用 ...
- 实现全链路监控平台很难吗?Pinpoint、SkyWalking、Zipkin 选型对比
随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务.互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发.可能使用不同的编程语言来实现.有可能布在了 ...
- 微服务项目中引入全链路监控平台:Pinpoint、SkyWalking、Zipkin怎么选?
来源:www.jianshu.com/p/92a12de11f18 0 问题背景 随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务.互联网应用构建在不同的软件模块集上, ...
- cat全链路监控_全链路监控(一):方案概述
为什么需要监控,在哪些层次上监控,监控什么 监控是为复杂的分布式系统服务的,它收集跨不同的应用,不同的服务器的系统行为信息,可通过采样收集所需的性能指标,帮助分析性能问题,并在指标超过正常值时报警. ...
- cat全链路监控_谛听全链路监控平台实践与思考
一.项目背景 近几年,信也科技的研发技术伴随着业务的快速增长逐步演化为微服务化的分布式体系架构,但随之带来的系统间的上下游依赖关系的复杂度也呈指数级上升,已有的烟囱式的监控产品(CAT.ELK等)存在 ...
- cat全链路监控_全链路监控选型
实现全链路监控 SkyWalking SkyWalking是apache基金会下面的一个开源APM项目,为微服务架构和云原生架构系统设计.它通过探针自动收集所需的指标,并进行分布式追踪.通过这些调用链 ...
最新文章
- UI设计培训学习中必须掌握的设计原则
- 美团公开外卖配送中的“预估到达时间”算法规则
- CV之FR:计算机视觉之人脸识别(Face Recognition)方向的简介、代码实现、案例应用之详细攻略
- Live2D WebGL实现
- golang flag包使用示例:接收命令行参数
- CentOS6.x系统挂载NTFS分区的移动硬盘
- (转)Hibernate关联映射——一对多(多对一)
- Repeater控件里面取不到CheckBox的值
- 论ul、ol和dl的区别
- asm.js性能提升,让游戏飞起来
- TensorRt - caffe中支持prelu
- [数值计算-1]:数学建模、科学计算、数值计算的关系
- Android studio 设置签名
- uni-app 在mac电脑连接安卓手机进行真机调试
- 数电票试点扩围 百望云一体化解决方案助力企业数字化升级
- 计算机能使用硬盘吗,电脑内置硬盘可以直接当移动硬盘用吗?
- Kafka部署、原理和使用介绍
- 明月镜片官宣品牌代言人刘昊然;Crocs与欧阳娜娜打造全新联名系列 | 美通企业日报...
- 用python给女朋友写了个自动提醒的程序
- 树洞外链2.1,一款基于七牛的外链分享平台
热门文章
- Intel提供的面向机器学习和深度学习的优化工具和框架
- 一步一步理解Paxos算法
- go 打印 %v %+v %#v 的区别
- 【Python】忘记登录密码?遍历数字字母组合密码+模拟提交表单
- 【SPSS】第十周-面板数据的线性回归
- HMAC算法及其应用
- CentOS下Storm 1.0.0集群安装详解
- c4.5算法 程序语言,决策树之C4.5算法详解-Go语言中文社区
- python相对路径找不到文件_Python相对路径从子文件夹导入
- 基本的Socket通信