Skywalking--python 介绍与使用

为什么要引入skywalking？在用户发现问题前，提前知晓服务问题服务发生问题时，无从下手；没有日志采集系统查日志，如果是负载均衡方式，不能很快定位问题提升现有服务的服务质量，提升用户感知度，有利于调优接口性能选型skywalking 已经成为apache顶级项目，社区活跃，易二次开发，消耗服务资源相对最少，对java支持最好，但对Python支持也友好，也有其他语言的各种agent，如golang，易于之后微服务化容器化后多语言并存skywalking的架构skywalking 前端UI 用的是skywalking -Rocketbot，VUE实现，可以做二次开发Storage可以用mysql influxdb等，我们选择ES，也不用重复搭建ELK做日志采集分析

python集成skywalkingpip install apache-skywalking 安装包在flask启动py中导入skywalking

# -*- coding:utf-8 -*-

##导入skywalking链路监控 开始

from skywalking import agent, config

#config.disable_plugins = ['sw_http_server', 'sw_urllib_request','sw_django','sw_tornado','sw_urllib3','sw_sanic','sw_aiohttp','sw_pyramid']#也可以排除一些不想纳入跟踪的组件

config.init(collector='112.126.86.53:11800', service='songling') #采集服务的地址，给自己的服务起个名称

agent.start()

##导入结束

import logging

from framework import app

if __name__ != '__main__': #gunicorn 启动

gunicorn_logger = logging.getLogger('gunicorn.error')

app.logger.handlers = gunicorn_logger.handlers

app.logger.setLevel(gunicorn_logger.level)

if __name__ == '__main__':#flask 启动

app.run(host=app.config["HOST"], port=app.config["PORT"], debug=app.config["DEBUG_MODEL_SWITCH"])

启动flask时，会在日志看到类似信息skywalking [MainThread] [WARNING] failed to install plugin sw_aiohttp

skywalking [MainThread] [WARNING] failed to install plugin sw_django

skywalking [MainThread] [WARNING] failed to install plugin sw_elasticsearch这些是系统中没有引入的组件，如果发现pymysql也没有引入，是因为配置mysql驱动时需要配置成mysql+pymysql(不引入pymysql组件，跟踪中就没有访问mysql的相关数据)SQLALCHEMY_DATABASE_URI = "mysql+pymysql://*******"对于gunicorn发布的flask服务，一定注意worker_class = 'sync'

worker_class不能是gevent，也不用在flask启动py中引入与gevent相关包，如import gevent.monkey.（目前还不知具体原因）

Python集成skywalking的plugin原理

几行代码就能把需要的链路 跨度信息反馈到skywalking？

# -*- coding:utf-8 -*-

# @Time : 2021/3/4 20:27

# @Author: sl

class MyFlask():

def method_old(self):

print("假定flask执行逻辑")

_method_old=MyFlask.method_old

def method_new(this:MyFlask):

print("加入执行前逻辑")

_method_old(this)

print("加入执行后逻辑")

MyFlask.method_old = method_new #类方法替换,包装了原来的方法，类似java切面

my = MyFlask() #替换后，再涉及flask服务都会被拦截处理

my.method_old()

plugin开发遵循 OpenTraing规范，每个调用都是一个Span（跨度），一个Span有多个子Span。如，一次访问flask接口，就产生一个flaskSpan,这个接口内部访问了mysql数据库，又产生了一个mysqlSpan，每次访问都会分配一个TraceID，在http访问时该id存在于head中，在mq访问时存在于附加消息中。这样每次访问的一个链条通过traceid串联起来。简单理解一下即可，除非去开发pluginUI主要观测点服务概况Apdex是用户体验指标，满意度的量化值，在0到1区间，越趋近于1，说明大部分访问的延迟是越理想的，对用户的响应很快Service Avg Responde Time 响应时间曲线，Service Responde Time Percentile是响应时间的百分比，P75值170就是在选定的时间范围内,百分之75的请求，都在170毫秒完成Successful Rate 如果不是100，说明在选定时间范围内，有错误的请求出现Service Load 服务每分钟请求数选定的时间在展示界面切换的时候是不变的端点概况CPM 每分钟某端点被调用次数，被调用次数多的接口，看是否还有优化空间Slow Endpoint 是某个接口平均响应时间，越响应慢的接口越排在前面。如果接口响应过慢，就一定要调整接口代码SuccessFul Rate 如果接口成功率不是100，提示出现了访问异常，需要及时查看接口日志，解决问题拓扑显示概况

主要是以拓扑的形式展示服务和与服务交互的其他服务或数据库 中间件的调用关系，

在这可以配置一些服务所属组，来区分每个负责人，对应自己负责的服务状况

4. 追踪端口具体信息

追踪某个服务的所有接口调用情况，可以查到具体调用所花费时间，请求了哪个中间件或数据库。对于数据库访问的Span可以查看具体请求的sql语句

告警对于Successful Rate ，CPM 等度量点，当服务的阈值触发时，可以在告警出查看异常调用。并可以通过webhook发钉钉等提示信息。配置阈值，需要在skywalking后端配置config/ Alarm -settings.yml日志模块如果需要具体报错信息，就需要用代码侵入方式打印日志，我们不采用此种，用ELK采集服务日志做查询与分析。