最简单的多线程爬虫实例

写这个例子主要还是了解多线程的使用和运行方式,因为爬虫是用多线程的实现的典型应用场景,基本写爬虫的没有不用多线程的,因为太多的网页或内容你不可能一一去获取,如果爬的数据量太大而不去并发执行,那时间估计是人无法忍受的,如果对python了解多一些的小伙伴可能知道GIL, 全称Global Interpreter Lock,  也就是python的全局锁,这把锁是为了 解决多线程之间数据完整性和状态同步的,也正因为这把锁的存在,python无法实现真正意义上的多线程,因为在某个时刻只能有一个线程在占用CPU资源,这才能保证数据的决对完整性,当然这是对cpytho来说的,像jpython就没有gIL, 所以如果Python运行在多核cpu上推荐用多进程模式,线程模式运用场景是IO密集型的,对于cpu计算密集型来说效率会降低,就爬虫程序来说,它就是一个典型的IO密集型操作,所以用Python最好不过,如果不知道上面那些这些内容也没关系,就记住在什么场景下使用就可以了,今天主要是给爬虫例子,代码如下:

这个脚本只是个简单例子,定义了一个数据保存函数save(),一个获取网页内容函数crawl(),模块用的第三方模块requests, MyCrawler类中调用父类的初始化方法,然后重新run函数,就是要把我们要执行的代码放到这个函数里,之前我写过一篇文章,详细写了python线程的使用方式,一般来说我们经常使用的就是函数或者用类来包装线程对象,例子里这次我们用的是类包装的方法,就是直接从threading.Thread继承,然后重写__init__方法和run方法, 例子很简单,不详细解释代码含义了,有兴趣的可以再这个代码上进行修改,实现更复杂的爬虫程序。

 

python分析nginx日志

上周咳嗽比较厉害,暂停了一周更新,收到很多小伙伴的留言关心,真是非常感动,非常感谢大家支持,我会尽我努力给大家分享干货, 现在吃了几天药,基本好的差不多了,这周接着聊python在运维中的实践,今天的脚本是分析nginx的访问日志, 主要为了检查站点uri的访问次数的,检查的结果会提供给研发人员做参考,因为谈到分析嘛,那肯定要用到正则表达式了,所以请没有接触过正则的小伙伴自行补脑,因为涉及正则的内容,实在没法展开写,正则的内容太过庞大,根本不是一篇两篇能写清楚的,开始前,我们先看看要分析的日志结构:

这是修改过的日志内容,敏感内容都以删除或替换了,不过不影响我们的分析结果,当然格式什么的这都不重要,Nginx访问日志是可以自定义的,每家公司可能都会稍有不同,所以要能理解脚本内容,并通过自己修改应用到了自己工作中才是重点,我给的日志格式也就是个参考,我打赌你在你公司服务器上看到的日志格式肯定跟我的格式不一样, 看完日志格式,我们开始要写我们的脚本了,我先贴代码,稍后解释:

脚本解释,parser_logfile()函数功能是分析日志,返回匹配的行列表,正则部分就不解释了,大家看注释应该知道它是匹配什么内容的,parser_urllist()函数功能是将获取用户访问的url,get_urldict()函数功能是返回一个字典,以url为键,如果键相同值增1,返回的字典是每个url和最大的访问次数,url_count()函数功能就是调用了之前定义的函数,主函数部分,就说说itemgetter,它可以实现按指定元素进行排序,举例就明白了:

reverse=True参数表示降序排序,就是从大到小排序,脚本运行结果:

 

站点监控报警

在小型公司里如果产品线单一的话,比如就一个app,  一般1~2个运维就够用了,如果产品过于庞大,就需要多个运维人员,但对于多产品线的公司来说,运维人员就要必须分多个人负责,因为超过200个站点让1个人维护,那工作量是巨大的,就单单给开发的沟通时间,估计就要占用一整天时间了,目前我所在的公司站点非常多,为管理方便,之前我们这里是实行过站长制,就是不同人承担不同的项目维护,每个人就是自己所负责项目的站长,这个站长制完后,就有个监控问题,之前只要站点有问题,是每个人都可以收到,但为了防止报警泛滥,所以就需要把监控改成故障站点只发给负责该站点的站长,有了这个背景,我们今天就来实现这个需求,脚本基本实现首先要有一个能够报警的函数,还需要一个检查站点是否故障的函数,最后一个函数是如果站点恢复后,要重新加入要监控的列表中,到这基本差不多了,但如果站点太多,用循环去检查还是效率太低了点,所以我们考虑采用线程并发执行, 如果都想清楚了,就可以开始着手我们代码的编写了:

首先导入我们所需要的模块:

然后定义要检查的站点列表和报警邮件发送人:

接下来实现检查是否站点故障函数:

这个函数就是用requests检查站点返回的状态码,如果是200就认为正常,否则就把该站点加到临时的一个字典中,然后从检查字典中删除该站点。

因为站点偶尔出现问题不代表是站点问题,也可能是网络抖动,所以重新检查站点是否故障要等待一个固定时间,实现如下:

这个函数就是从临时字典中取出第一次检查出有问题的站点,15分钟后再次检查,如果返回200,就发送邮件,并从临时字典中移除,重新加入监控列表中,如果仍然未恢复,就要发送报警邮件了。

最后,我们采用并发的方式执行函数:

如果到这里就算结束这篇文章, 大家拿着脚本肯定是不能运行的,因为少代码,我们也sleep 2分钟,看大家是否发现漏掉了什么,是的,我还没给出发报警邮件的函数代码,不但没贴而且不妨告诉大家我是故意的,之所以没直接给呢, 第一:是因为现在报警方式太多了,我建议大家在这个脚本基础上进行修改实现自己想要的报警方式,第二:就当是留个作业吧,毕竟多动手才能提高编程水平,其它不多说了,最重要的是第三点:请帮忙转发,:)

 

python实现windows盘符探测器

windows系统对经常玩linux的运维兄弟来说,如果碰到自己业务中有一大堆win系统要去运维,如果不太熟悉还是非常头疼的,尤其面对上百台后,各种情况更加复杂,因为这百台里可能存在不同的配置,尤其是磁盘的配置,可能刚开始都比较统一,但后续经过长时间运维后,因为升级过磁盘会造成每台机器会有不同的分区,如果面对一个你刚接收的业务,你要快速了解这些信息,你不可能去每台登陆上去人肉去看,当然最好是写一个脚本来获取这些信息,今天不我们不展开其它内容,来个最简单的需求,就是去探测每台机器上有哪些盘符,例如:C盘,D盘等。

上代码:

运行结果:

没用什么复杂的逻辑,都是python自带的内部函数, ord() 参数是一个ascii字符,返回值是对应的十进制整数,chr()参数是0 – 256 的一个整数,返回值是当前整数对应的ascii字符,参数可以是10进制也可以是16进制的形式,主要是判断这些盘符是否存在,如果存在就加入drive_list列表中,最后打印出来,完毕。

django1.8使用表单上传文件

在django中我们可以采用Form类来处理表单,通过实例化处理和在模板中渲染,就可以轻松完成表单的需求,采用django的表单处理方式,能帮我们省去很多的工作,比如验证不能为空,或者要符合某种模式的输入才有效,这些处理起来非常方便,不用自己再单独写代码去验证表单的数据正确性,所以在开发中比较常用,Form提供了很多表单字段,比如日期,文本类型等,如果你熟悉基本的html,学起来会非常容易上手,所以今天我们不打算对每个表单的字段进行逐一说明,今天只说下表单文件的上传,因为这个类型比较特殊,需要一点特殊的处理,我们来创建一个简单的一个实例:

首先我们用Form创建一个简单的表单:

这个表单就2个字段,要求用户输入用户名和上传一个文件或图片。

接下来我们放到模板中去渲染,这时候就可以看到一个基本表单了,视图函数如下:

这个函数判断用户的是否为POST请求,如果是并验证是有效的,然后就返回OK,在验证正确和返回OK的中间放我们的上传文件代码,因为只有文件上传成功能返回OK,我们一会说,如果是GET请求,就直接显示一个空表单,让用户输入。

处理上传文件就是往服务器上生成一个文件,并将上传的文件内容写到新的文件中,所以它的基本函数是这样的,接收上传文件对象为参数,然后本地打开一个文件,从上传的文件中读出文件,写入新的文件中,代码如下:

有了这个上传文件的处理函数,我们就可以进一步完善我们的视图函数里,最终的代码如下:

这样就完成了一个文件的上传,完毕。