Python日志监控系统处理日志(pyinotify)

前言

最近项目中遇到一个用于监控日志文件的Python包pyinotify,结合自己的项目经验和网上的一些资料总结一下,总的原理是利用pyinotify模块监控日志文件夹,当日志到来的情况下,触发相应的函数进行处理,处理完毕后删除日志文件的过程,下面就着重介绍下pyinotify

pyinotify

Pyinotify是一个Python模块,用来监测文件系统的变化。 Pyinotify依赖于Linux内核的功能—inotify(内核2.6.13合并)。 inotify的是一个事件驱动的通知器,其通知接口通过三个系统调用从内核空间到用户空间。pyinotify结合这些系统调用,并提供一个顶级的抽象和一个通用的方式来处理这些功能。

  • pyinotify 说百了就是通过 调用系统的inotify来实现通知的
  • inotify 既可以监视文件,也可以监视目录
  • Inotify 使用系统调用而非 SIGIO 来通知文件系统事件。

Inotify 可以监视的文件系统事件包括:

Event Name Is an Event Description
IN_ACCESS Yes file was accessed.
IN_ATTRIB Yes metadata changed.
IN_CLOSE_NOWRITE Yes unwrittable file was closed.
IN_CLOSE_WRITE Yes writtable file was closed.
IN_CREATE Yes file/dir was created in watched directory.
IN_DELETE Yes file/dir was deleted in watched directory.
IN_DELETE_SELF Yes 自删除,即一个可执行文件在执行时删除自己
IN_DONT_FOLLOW No don‘t follow a symlink (lk 2.6.15).
IN_IGNORED Yes raised on watched item removing. Probably useless for you, prefer instead IN_DELETE*.
IN_ISDIR No event occurred against directory. It is always piggybacked to an event. The Event structure automatically provide this information (via .is_dir)
IN_MASK_ADD No to update a mask without overwriting the previous value (lk 2.6.14). Useful when updating a watch.
IN_MODIFY Yes file was modified.
IN_MOVE_SELF Yes 自移动,即一个可执行文件在执行时移动自己
IN_MOVED_FROM Yes file/dir in a watched dir was moved from X. Can trace the full move of an item when IN_MOVED_TO is available too, in this case if the moved item is itself watched, its path will be updated (see IN_MOVE_SELF).
IN_MOVED_TO Yes file/dir was moved to Y in a watched dir (see IN_MOVE_FROM).
IN_ONLYDIR No only watch the path if it is a directory (lk 2.6.15). Usable when calling .add_watch.
IN_OPEN Yes file was opened.
IN_Q_OVERFLOW Yes event queued overflowed. This event doesn‘t belongs to any particular watch.
IN_UNMOUNT Yes 宿主文件系统被 umount
IN_ACCESS,即文件被访问
IN_MODIFY,文件被write
IN_ATTRIB,文件属性被修改,如chmod、chown、touch等
IN_CLOSE_WRITE,可写文件被close
IN_CLOSE_NOWRITE,不可写文件被close
IN_OPEN,文件被open
IN_MOVED_FROM,文件被移走,如mv
IN_MOVED_TO,文件被移来,如mv、cp
IN_CREATE,创建新文件
IN_DELETE,文件被删除,如rm
IN_DELETE_SELF,自删除,即一个可执行文件在执行时删除自己
IN_MOVE_SELF,自移动,即一个可执行文件在执行时移动自己
IN_UNMOUNT,宿主文件系统被umount
IN_CLOSE,文件被关闭,等同于(IN_CLOSE_WRITE | IN_CLOSE_NOWRITE)
IN_MOVE,文件被移动,等同于(IN_MOVED_FROM | IN_MOVED_TO)

pyinotify使用例子

#!/usr/bin/python
# coding:utf-8

import os
from pyinotify import WatchManager, Notifier,ProcessEvent,IN_DELETE, IN_CREATE,IN_MODIFY

class EventHandler(ProcessEvent):
 """事件处理"""
 def process_IN_CREATE(self, event):
  print  "Create file: %s " %  os.path.join(event.path,event.name)

 def process_IN_DELETE(self, event):
  print  "Delete file: %s " %  os.path.join(event.path,event.name)

 def process_IN_MODIFY(self, event):
   print  "Modify file: %s " %  os.path.join(event.path,event.name)

def FSMonitor(path=‘.‘):
  wm = WatchManager()
  mask = IN_DELETE | IN_CREATE |IN_MODIFY
  notifier = Notifier(wm, EventHandler())
  wm.add_watch(path, mask,auto_add=True,rec=True)
  print ‘now starting monitor %s‘%(path)
  while True:
   try:
     notifier.process_events()
     if notifier.check_events():
       notifier.read_events()
   except KeyboardInterrupt:
     notifier.stop()
     break

if __name__ == "__main__":
 FSMonitor(‘/root/softpython/apk_url‘)
时间: 2024-08-29 00:29:01

Python日志监控系统处理日志(pyinotify)的相关文章

Elasticsearch and kibana and filebeat 轻量级日志监控系统

Elasticsearch and kibana and filebeat Elasticsearch and kibana and filebeat 轻量级日志监控系统 说明: elasticsearch 依赖java Logstash 依赖于JVM,内存消耗比较高 filebeat go语言轻量级日志监控系统 安装 elasticsearch-6.2.3.tar.gz filebeat-6.2.3-linux-x86_64.tar.gz kibana-6.2.3-linux-x86_64.t

日志监控系统中,大批量查询mysql方案

最近开发遇到一个问题:需要查询一个大时间段内的数据,分1000个小段,即为1000个点.X轴是时间,Y轴是该小时间段内统计后数据.注意:数据返回是一个list,其中每个对象返回值都是该小时间段内数据统计出来的,且需要根据入参顺序返回(这样前端展示就方便).举例,查询12点到1点的数据,查询频率是30分钟,那么就需要查询11:30-12:00,12:00-12:30,12:30-1:00这三段数据(因为监控系统都是查询过去的数据,所以12点的那个值应该是之前半个小时的).问题来了, 方案一:直接热

django项目之efk日志监控系统的搭建

一.下载efk的tar.gz的离线包 wget http://download.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-x64.tar.gz?AuthParam=1536892035_945cb24c750d0971b8c5b1925cc723a9 wget https://artifacts.elastic.co/downloads/elasticsearch/

Sentry错误日志监控你会用了吗?

无论作为新手还是老手程序员在程序的开发过程中,代码运行时难免会抛出异常,而且项目在部署到测试.生产环境后,我们便不可能像在开发时那样容易的及时发现处理错误了.一般我们都是在错误发生一段时间后,错误信息才会传递到开发人员那里,然后一顿操作查看程序运行的日志,就熟练使用awk和grep去分析日志,但是往往我们会因为日志中缺少上下文关系,导致很难分析真正的错误是什么. Sentry由此应运而生成为了解决这个问题的一个很好的工具,设计了诸多特性帮助开发者更快.更方面.更直观的监控错误信息. 关于日志管理

如何使用ARMS配置tengine的日志监控

来自 深圳市小亿网络有限公司 王昕岩 的撰稿 最近公司通过阿里云的业务实时监控服务 ARMS成功搭建了基于tengine的日志监控系统.这里简单分享一下使用[font=&quot]ARMS用于监控[font=&quot]tengine日志的经验.[font=&quot] 公司发展至今,现阶段所有接口都使用阿里的tengine作为web容器,类似nginx,在日志中也记录了包括host,url, ip, 包体大小,响应时长等信息.目前的业务需求场景是希望有一套系统来监控接口的异常,来

基于Flume的美团日志收集系统(一)架构和设计【转】

美团的日志收集系统负责美团的所有业务日志的收集,并分别给Hadoop平台提供离线数据和Storm平台提供实时数据流.美团的日志收集系统基于Flume设计和搭建而成. <基于Flume的美团日志收集系统>将分两部分给读者呈现美团日志收集系统的架构设计和实战经验. 第一部分架构和设计,将主要着眼于日志收集系统整体的架构设计,以及为什么要做这样的设计. 第二部分改进和优化,将主要着眼于实际部署和使用过程中遇到的问题,对Flume做的功能修改和优化等. 1 日志收集系统简介 日志收集是大数据的基石.

基于Flume的美团日志收集系统(一)架构和设计

来自:美团技术博客 http://tech.meituan.com/mt-log-system-arch.html 美团的日志收集系统负责美团的所有业务日志的收集,并分别给Hadoop平台提供离线数据和Storm平台提供实时数据流.美团的日志收集系统基于Flume设计和搭建而成. <基于Flume的美团日志收集系统>将分两部分给读者呈现美团日志收集系统的架构设计和实战经验. 第一部分架构和设计,将主要着眼于日志收集系统整体的架构设计,以及为什么要做这样的设计. 第二部分改进和优化,将主要着眼于

基于Flume的美团日志收集系统(二)改进和优化

问题导读: 1.Flume-NG与Scribe对比,Flume-NG的优势在什么地方? 2.架构设计考虑需要考虑什么问题? 3.Agent死机该如何解决? 4.Collector死机是否会有影响? 5.Flume-NG可靠性(reliability)方面做了哪些措施? 美团的日志收集系统负责美团的所有业务日志的收集,并分别给Hadoop平台提供离线数据和Storm平台提供实时数据流.美团的日志收集系统基于Flume设计和搭建而成. <基于Flume的美团日志收集系统>将分两部分给读者呈现美团日

ELKR分布式搭建nginx日志分析系统

ELKR分布式搭建nginx日志分析系统 一.名词介绍 1.什么是elk ELK 其实并不是一款软件,而是一整套解决方案,是三个软件产品的首字母缩写,Elasticsearch,Logstash 和 Kibana.这三款软件都是开源软件,通常是配合使用. 2.Elasticsearch 2.1.Elasticsearch介绍 Elasticsearch 是一个实时的分布式搜索和分析引擎,它可以用于全文搜索,结构化搜索以及分析.它是一个建立在全文搜索引擎 Apache Lucene 基础上的搜索引