作者简介:
郭宏泽,现任为胜科技技术总监,高级咨询师,IT解决方案专家。拥有12年IT行业工作经验,其中有8年一线运维经验,4年运维开发经验,曾就职于易车网、电信云计算、跟谁学等公司。开发过日志分析系统、CDN流量计费结算系统,自动化容器管理平台等。精通Linux相关技术及Python、Shell、JavaScript等语言。现任多家大型公司咨询顾问,已帮助IBM、惠普、朗讯等多家跨国公司进行容器化及DevOps转型。
AdminSet开源运维平台创建者,DevOps Master,全球运维大会金牌讲师,高效运维社区核心成员。
Python是一个浩瀚如烟的旷阔领域,有着丰富的应用场景,业务系统、云计算、大数据、人工智能都有Python的身影。
Python是一个易于学习的语言,是一个以简洁实用为宗旨的语言,我在以前的工作中接触过PHP、C#、Java等语言,但当我第一次看到Python的时候,有一种相见恨晚的感觉,心里冒出一句话“就它了”。
Python的兴起是由于云计算时代的来临,当IaaS逐渐成熟、PaaS百花齐放的时代到来时,Python终于迎来了它的黄金时代。
由于入门简单、语法精炼、功能库丰富,Python在计算机领域渐渐成为了一种通用语言,无论是应用、平台还是工具,哪个没有Python的API接口或是SDK呢?这正说明了Python的实力。正因为这些原因,Python在DevOps领域成为一种标准,而且不可替代。
Python目前有两个主流版本,Python 2和Python 3,而且都在维护更新,且这两个版本互不兼容。
我们先来看看Python 2和Python 3 之间的主要区别,参见下表。更多新特性请参考:https://docs.python.org/3/whatsnew/3.0.html。
Python 2 |
Python 3 |
|
Print 变函数 |
Print“abc” |
Print("abc") |
类 |
旧式类和新式类 |
只有新式类 |
运算 |
1/2=0 |
1/2=0.5 |
字符串格式化 |
%,Format |
Format,% |
xrange |
xrange |
Range |
long重命名为int |
Long,int |
Int |
包导入 |
相对导入 |
绝对导入 |
源文件编码 |
Ascii |
utf8 |
从Python社区官方态度来看,官方强烈建议直接学习Python 3,因为Python 2只会维护到2020年。那么看到这儿,可能你会觉得应该直接学习Python 3了,但实际上不是这样,我们必须从Python 2开始。
如果我们对一件事举棋不定,那么最好看看别人是怎么做的,下图是Python各版本在2016年7月和8月的下载量统计图。
通过数据换算(Y轴是指数),Python 2.6和Python 2.7的下载量占比超过90%。数据不会说谎,事实就是当前仍然是Python 2主导的世界,Python 2作为大部分应用和工具的基础,还会在相当长的时间内存在。
为什么会出现这样的情况呢?原因有三:
技术的发展是快的,但是在生产中落地是非常缓慢的。
如果Python 2就能用,为什么非得升级到Python 3呢。
Python 3不是所有操作系统的默认解释器,在系统环境中使用Python 3会消耗巨大的成本。
出于实用主义考虑,如果能用螺丝刀解决的问题绝不会用一个电钻来解决。使用Python的人大多数是实用主义者,所以出现了在Python3出现多年以后仍然无法普及的现象。
Python 2和Python 3还有一种平衡的方法,可以同时兼容两个版本,那就是在Python 2中引用Python的__future__库。__future__库里面包含了Python 3的大多特性。
从Python 2开始学习,向Python 3演进,使用Python 2.7版本,利用Python 2.7的语法兼容性,尽量使用Python 2版本和Python 3版本都能兼容的语法,这样既保证了在现有系统中的兼容性,又为将来全面向Python 3迁移做好了准备。
事实上Python 2的最新版本Python 2.7和Python 3的差异不超过10%,可以说是比较小的,另外Python 2.7已经尽可能地弥合了Python 2与Python 3之间的差异,做到了尽可能多地兼容Python 3。
比如在Python 2.7中使用print “hello world”和 print(“hello world”) 两者都是可以的,但我们应该使用后者,以便全面向Python 3版本迁移。
最后给出几条学习建议:
从Python 2.7开始学习,不要使用Python 2.7以前的版本。
了解Python 3弃用的语法和包,在书写代码过程中尽量避免。
不要使有Python 3.5之前的Python 3.x版本。
尽量多地使用Python 2与Python 3相兼容的语法。
熟悉__future__库。
DevOps工程师应主要使用Python 2.7。
业务开发工程师可以直接使用Python 3.5。
“ 因为你是我的眼,让我看见这世界就在我眼前”,这是一首耳熟能详的歌曲《你是我的眼》。监控,对于运维工程师来说就是眼睛,如果没有监控,运维工作就无从谈起;如果没有监控,运维工程师就成了盲人。
一个良好的监控系统可以快速地发现并定位问题,减少宕机时间,提高故障处理速度,减轻运维工作压力,甚至可以促进家庭和谐。
但是对于这么重要的系统,我发现很多公司都做的都不好:要么监控不到位,很多盲区;要么监控过多,太多无效条目导致报警麻木;要么监控系统五花八门,工具琳琅满目,重复监控,条理不清,等等。
我认为产生这些问题的原因主要有两点。其一,人的问题,是我们的运维工作人员对监控没有深刻的认识,经验不足;其二,工具的问题,没有得心应手的工具,开源、闭源,五花八门,难以统筹高效利用及整合。
以前我们习惯于拿来主义,有问题需要用工具,上网查查别人都在用什么,我也下载一个试一试,差不多就行了。
但是现在时代变了,IaaS、PaaS、SaaS的结构越来越复杂,对于运维工程师说来,必须对监控有深度定制或二次开发的能力才能满足当下的需要。
所以我的建议是,可以考虑自研一套监控系统,这固然有压力,但是一旦成功,收益巨大。俗话说万事开头难,开了头其实就不难。我以自己的经验来说说自写一套监控系统的套路。
前端开发主要会用到大量的页面元素,我建议使用目前开源的adminlte,这个前端框架元素非常丰富,页面简洁,比较适合作为监控系统的基础页面框架。
adminlte本身是基于Bootstrap开发的,对于我们将来进行深度页面定制是非常友好的。图表库内置了font awesome和iconic,表单整合了Select2,adminlte几乎能满足你的任何要求。
在图形展示上,建议使用Echarts监控图表(参见下图),它由百度团队开发维护,资料文档非常丰富,在图形质量、异步获取和加载方面都比较成熟,要把它嵌入到系统中,只需要引入一个JavaScript包发即可。
后台开发使用Django,主要是快,无论是Model、FORM、Auth等系统,还是在插件中间件的丰富程度、文档的完善度上,Django都具有绝对优势。通过将平台微服务化,Django本身的速度劣势将被弥补。
在监控数据的设计方面,对资产信息、用户关系等的监控肯定要使MySQL这种关系性数据库,但是对于监控条目的处理就得三思而后行了,我见过很多项目都是把监控条目直接丢到MySQL里,导致后期扩展困难,数据库成了监控平台的巨大瓶颈。
我的方法是将所有监控信息全部写入MongoDB这样的NoSQL数据库,无论是在可扩展性还是性能上,它们都能应对当前海量的监控数据需求。
然后在服务端写一个独立的微服务接口,负责接收客户端上传的监控信息,然后将数据进行处理后插入MongoDB,以供前端进行数据调用,下面代码截图是一个API插入的示例。
这个API通过HTTP Server的方式启动,然后监听客户端的POST数据,接收到数据后以服务器本地时间为基准,打上监控数据的时间戳后存入MongoDB,并以主机名为依据,直接进行分表。
客户端的开发相对来说比较简单,主要引入了requests 进行HTTP动作的处理,引入了Schedule进行定时上报和计划任务,引入了Psutil进行性能信息采集。
客户端的性能数据主要依靠Psutil采集,Psutil有非常丰富的监控接口,能够轻松实现对CPU、内存、网络、磁盘的监控。
获取磁盘信息的函数截图如下:
通过Psutil提供的接口采集性能信息,然后将结果封装成一个Json数据,使用Requests Post提交到服务器的API接口中去——一次监控过程就完成了。
监控平台的通道也就打开了,以后监控任意条目的套路不过如此。NPM、中间件监控、APM,不都是这样吗?采集数据、上报、存盘并展现。
服务端、客户端,数据库和图表展现完成之后,一个简单的监控平台雏形就完成了。这只是一个开始,DevOps的核心思想是持续学习、持续迭代,在这个过程中不断完善。有了平台和架子,我们就可以不断地添砖加瓦。
对于硬件监控,可以通过Linux系统命令(比如smartctl、dmidecode等)来获取相关信息。
对于NPM、CPU、内存、磁盘、网络和进程,可使用Psutil来完成。
对于中间件监控,比如MySQL、Nginx,可以通过命令行或是中间件的监控接口来采集数据。
对于某些自定义监控,比如监控某个文件大小、某个目录的文件数、某个文件的属性,可以用Shell来完成。
对于APM、应用程序指标、函数调用、响应时间、业务数据等,我们可以通过埋点、API或是JVM嗅探来完成。
对于报警系统,可以使用邮件、微信等形式,这个可以根据企业自身的需要来设置,都是十几行代码即可搞定。
如果我们使用开源软件Cacti Zabbix,在实现和整合上都会比较麻烦,很多时候会受制于软件原有的结构,二次开发比较麻烦。
所以,我们何不自己写一个,将所有的控制权都放在自己手上呢?况且又不是特别难,在开发平台的过程中,你的Python技术、软件工程能力都会有很大的提升,你将能够快速实现企业的需求,而不是跑到社区去哭诉“给我加个功能吧”。
Python 开发三十六计:
如果您对其中内容表示质疑,欢迎指出并发表意见,一经采纳,您将成为内测版读者,《DevOps三十六计》在年末的第一批印刷将在第一时间送到您的手中。
想与郭宏泽老师直接交流?请加入 DevOps 三十六计交流群
入群请加微信:gaoxiaoyunweiliuce
关注 DevOps 三十六计公众号
我们将长期发布 DevOps 三十六计完整内容
更多相关文章阅读
用 Python 代码自动抢火车票
携程运维自动化平台,上万服务器变更也可以很轻松
智能运维就是 由 AI 代替运维人员?
看腾讯运维应对“18岁照片全民怀旧”事件的方案,你一定不后悔!
运行无间:阿里巴巴运维保障体系的一种最佳实践
芳华永在!一个老运维的20年奋斗史
饿了么异地双活数据库实战
运维版《成都》,听哭了多少人...
阿里万亿交易量级下的秒级监控
IT 运维的救赎——顺丰运维的理想践行
腾讯 SNG 团队首次系统性披露其运维体系:
第九届GOPS全球运维大会将于2018年4月13日-14日在深圳召开。大会为期2天,侧重方向包括AIOps、运维自动化和 DevOps。
为期两天的大会将涵盖众多先进的技术与理念:
点击阅读原文,进入大会官网