2

我制作了一个执行 nagios 检查的 python 脚本。脚本的功能非常简单，它只是解析日志并匹配一些用于构建 nagios 检查输出的信息。该日志是一个 snmptrapd 日志，它记录来自其他服务器的陷阱，并在/var/log/snmptrapd我只用脚本解析它们之后将它们记录下来。为了获得最新的陷阱，我每次阅读后都会从 python 中删除日志。为了保留信息，我做了一个 cron 作业，它以比 nagios 检查间隔小一点的时间间隔将日志内容复制到另一个日志中。我不明白的是为什么日志增长如此之多（我的意思是消息日志，我猜它有 1000 倍的信息更小）。从我在日志中看到的有很多特殊字符，例如^@我认为这是通过我从 pyton 操作文件的方式完成的，但看到我有三周的经验，我似乎无法找出问题所在。

脚本代码如下：

import sys, os, re

validstring = "OK"
filename = "/var/log/snmptrapd.log"

if os.stat(filename)[6] == 0:
        print validstring
        sys.exit()

else:
        f = open(filename,"r")
        sharestring = ""
        line1 = []
        patte0 = re.compile("[0-9]+-[0-9]+-[0-9]+")
        patte2 = re.compile("NG: [a-zA-Z\s=0-9]+.*")
        for line in f:
                line1 = line.split(" ")
                if re.search(patte0,line1[0]):
                        sharestring = sharestring + line1[1] + " "
                        continue
                result2 = re.search(patte2,line)
                if result2:
                        result22 = result2.group()
                        result22 = result22.replace("NG:","")
                        sharestring = sharestring + result22 + " "
        f.close()
        f1 = open(filename,"w")
        f1.close()
        print sharestring
        sys.exit(2)

~

日志如下所示：

2012-07-11 04:17:16 Some IP(via UDP: [this is an ip]:port) TRAP, SNMP v1, community somestring
    SNMPv2-SMI::enterprises.OID Some info which is not necesarry
    SNMPv2-MIB::sysDescrOID = STRING: info which i'm matching

我很确定这与我擦除文件的方式有关，但我无法弄清楚。如果你有一些想法，我会很感兴趣。谢谢你。

作为有关大小的信息，我有 93 行（Vim 这么说），日志占用 161K，这不好，因为行很短。

好的，这与我读取和擦除文件的方式无关。当我擦除它的日志文件时，snmptrapd 守护进程中的某些东西正在执行此操作。我已经修改了我的代码，现在我在打开文件之前将 SIGSTOP 发送到 snmptrapd reight，我对文件进行了修改，然后在完成后发送 SIGCONT，但似乎我遇到了同样的行为。新代码看起来像（不同的部分）：

else:
    command = "pidof snmptrapd"
    p=subprocess.Popen(shlex.split(command),stdout=subprocess.PIPE)
    pidstring = p.stdout.readline()
    patte1 = re.compile("[0-9]+")
    pidnr = re.search(patte1,pidstring)
    pid = pidnr.group()
    os.kill(int(pid), SIGSTOP)
    time.sleep(0.5)
    f = open(filename,"r+")
    sharestring = ""

和

                  sharestring = sharestring + result22 + " "
    f.truncate(0)
    f.close()
    time.sleep(0.5)
    os.kill(int(pid), SIGCONT)
    print sharestring

我正在考虑停止守护进程擦除文件，然后使用适当的权限重新创建它并启动守护进程。

4

1 回答 1

1

我不认为你可以，但这里有一些事情可以尝试

截断文件

f1 = open(filename, 'w')
f1.close()

是删除文件内容的一种骇人听闻的副作用方式，如果其他应用程序打开该文件，则可能会根据底层操作系统引起不希望的副作用。

使用文件对象方法 truncate()

truncate([size])

截断文件的大小。如果存在可选大小参数，则文件将被截断为（最多）该大小。大小默认为当前位置。当前文件位置没有改变。请注意，如果指定的大小超过了文件的当前大小，则结果取决于平台：可能包括文件可能保持不变、增加到指定的大小，就像用零填充一样，或者增加到指定的大小并带有未定义的新内容。可用性：Windows，许多 Unix 变体。

可能唯一的确定性方法是

在脚本开始处停止snmptrapd进程，使用正确的os module函数remove，然后重新创建文件并snmptrapd在脚本结束时重新启动守护进程。

os.remove(path)

移除（删除）文件路径。如果 path 是目录，则会引发 OSError；请参阅下面的 rmdir() 以删除目录。这与下面记录的 unlink() 函数相同。在 Windows 上，尝试删除正在使用的文件会引发异常；在 Unix 上，目录条目被删除，但分配给文件的存储空间在原始文件不再使用之前不可用。

共享资源关注

您仍然可能会遇到问题，因为两个进程试图在没有某种锁定机制的情况下争取写入单个文件，并且文件发生了不确定的事情。我打赌你可以发送一个SIGINT或类似于你的守护进程的东西，让它重新读取文件或其他东西，检查你的文档。

操作共享资源，尤其是没有独占锁定的文件资源会很麻烦，尤其是在文件系统缓存和数据应用程序缓存的情况下。

于 2012-07-11T08:47:19.303 回答