如何实现多站点运维监控?

来源:python运维技术

ID:python运维技术

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

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

from threading import Thread import requests import time import smtplib

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

clients = {"http://www.mindg.cn":"xxx@xx.com", "http://www.google.com":"gg@gg.com", "http://www.baidu.com":"cc@cc.com"}

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

temp_dic = {} def site_up(): while True: for client, email in clients.items(): try: r = requests.get(client) if r.status_code == 200: print client, 'Site ok' time.sleep(60) else: print client, 'Site first registered as down - added to the "site down" monitoring' temp_dic[client]=email del clients[client] except requests.ConnectionError: print client, 'Site first registered as down - added to the "site down" monitoring' temp_dic[client]=email del clients[client]

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

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

## site 'down' function def site_down(): while True: time.sleep(900) for client, email in temp_dic.items(): try: r = requests.get(client) if r.status_code == 200: print client, 'Site is back up!!' email_sender('Site back up!! ', email, client) clients[client]=email del temp_dic[client] else: email_sender('Site down!! ', email, client) print client, 'Site Currently down - email sent' except requests.ConnectionError: email_sender('Site down!! ', email, client) print client, 'Site Currently down - email sent'

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

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

t1 = Thread(target = site_up) t2 = Thread(target = site_down) t1.start() t2.start()

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

*声明:推送内容及图片来源于网络,部分内容会有所改动,版权归原作者所有,如来源信息有误或侵犯权益,请联系我们删除或授权事宜。

- END -


原文发布于微信公众号 - 马哥Linux运维(magedu-Linux)

原文发表时间:2018-08-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏架构师之路

服务读写分离架构,绝不推荐

缘起 在《服务读写分离(读服务,写服务),是否可行?》中,对背景做了交代,互联网架构设计上,数据库可以读写分离,服务能否读写分离呢? 下面是两种常见的“服务读写...

45711
来自专栏JAVA高级架构

电商平台备战促销季的运维秘诀——高可用服务层

1122
来自专栏叁金大数据

存储是怎样炼成的?

什么FAT,NTFS,NFS,DAS,SAN,NAS,OSD这些名词我一个都不认识。

1563
来自专栏顾宇的研习笔记

AWS 上的生产环境架构优化案例

在AWS 上的生产环境性能分析案例一文中,记录了我对客户应用生产环境的一次性能分析。接下来,我们要根据所发现的性能问题进行架构优化,以提升可用性和性能。同时,这...

1431
来自专栏云计算认知升级

小程序·云开发 项目开发经验分享

近期,小程序开放了新的能力——「小程序·云开发」,帮助开发者快速构建微信小程序的后端服务。我作为一名微信小程序的开发者,也在第一时间尝试了小程序云开发,并将我自...

3.7K14
来自专栏皮振伟的专栏

[kvm][qemu]影响虚拟化热迁移的设备

前言 虚拟化场景下,热迁移、HA都会受到部分设备的影响。设备的实现上,包含“透传”、“直通”、“passthrough”,基本上就限制了虚拟机的迁移能力。 作...

4886
来自专栏jerryteng的专栏

如何利用最低配的腾讯云快速搭建高并发在线服务

这里是作为开发用,我们就选择一个普通的服务器,我也是很不好意思的申请了相关的学生机,那我们就用学生机来搭建一个高并发的在线服务。这个机器配置很低,我还进行了降级...

88910
来自专栏ImportSource

微服务应具备的12个属性

该文翻译自Pivotal公司的 Matt Stine大牛的书籍《Migrating to Cloud Native Application Architectu...

2799
来自专栏后台全栈之路

基于汇编的 C/C++ 协程 - 背景知识

近几年来,协程在 C/C++ 服务器中的解决方案开始涌现。本文主要阐述以汇编实现上下文切换的协程方案,并且说明其在异步开发模式中的应用。

3064
来自专栏架构师小秘圈

cdn技术原理

作者:IT世界,来自:www.it.com.cn 1. 前言   Internet的高速发展,给人们的工作和生活带来了极大的便利,对Internet的服务品质和...

1.2K9

扫码关注云+社区