3

ツイストベースのクライアントは、UDPパケットをループで送信します。したがって、私はクラスDatagramProtocolを使用しています。これがソースです：

#!/usr/bin/python
# -*- coding: utf-8 -*-
from twisted.application.service import Service
from twisted.internet import reactor
from twisted.internet.task import LoopingCall
from twisted.internet.protocol import DatagramProtocol
from twisted.python import log
import logging

class HeartbeatClient(Service):
    def __init__(self, host, port, data, beat_period):
        self.ip = host
        self.port = int(port)
        self.data = data
        self.beat = int(beat_period)

    def startService(self):
        self._call = LoopingCall(self._heartbeat)
        self._call.start(self.beat)

    def stopService(self):
        self._call.stop()

    def _heartbeat(self):
        protocol = DatagramProtocol()
        protocol.noisy = False
        port = reactor.listenUDP(0, protocol)
        port.write(self.data, (self.ip, self.port))
        port.stopListening()

このクライアントをtwistedで実行すると、Twistedクラス、つまりDatagramProtocolクラスからログメッセージが永続的に取得されます。

2011-09-11 18:39:25+0200 [-] (Port 55681 Closed)
2011-09-11 18:39:30+0200 [-] twisted.internet.protocol.DatagramProtocol starting on 44903
2011-09-11 18:39:30+0200 [-] (Port 44903 Closed)
2011-09-11 18:39:35+0200 [-] twisted.internet.protocol.DatagramProtocol starting on 50044
2011-09-11 18:39:35+0200 [-] (Port 50044 Closed)
2011-09-11 18:39:40+0200 [-] twisted.internet.protocol.DatagramProtocol starting on 37450

これらのログメッセージは自分の「自分の」ログを汚染しているので、これらのログメッセージを無効にできるかどうか疑問に思います。ご覧のとおり、を呼び出すことでログの量をすでに減らしましたがprotocol.noisy = False、他のログメッセージが表示されます。また、コマンドg = protocol.ClientFactory().noisy = Falseは役に立ちません。

すべてのモジュールについて、一般的な方法で、すべてのツイスト内部クラスのロギングを無効にすることは可能ですか？たぶん、ツイストロギング構成を使用することによって？

4

1 に答える 1

5

Twistedのロギングはすべて非常に単純です。ただし、これが当てはまる必要がある理由はありません。これtwisted.python.logは非常に機能的であり、あなた（および他の人）が興味を持っている種類の選択的なレポートを作成できるためです。

ログイベントは、任意のキーと値の単なる辞書です。デフォルトのオブザーバーは、キーを持つ辞書について知ってい'message'ます。おそらくこれが原因で、Twisted自体によって発行されたほとんどのログメッセージは、このキーに関連付けられた人間が読める文字列を提供する以外は何もしようとしません（また、発行されたメッセージの多くは、現在のTwistedロギングシステムより前に追加されたためです。消費者としてより古く、より原始的なシステムを持っていた）。

少し前まで、この問題は、チケットを提出し、特に問題のUDP部分の解決に取り掛かるように促された誰かを悩ませました。この問題はほぼ解決されていますが、まだやるべきことがいくつかあります。

試みられた解決策は、同じ情報を伝達するがメッセージがないため、デフォルトのオブザーバーによって記録されない構造化されたメッセージをログに記録することです。これにより、デフォルトでログに表示されるメッセージが回避されますが、これらのイベントに特に関心のあるオブザーバーは、メッセージを監視し、必要に応じて処理できます。

チケットはしばらく手つかずのままです。誰かがパッチを手に取って、完成までの最後のビットを手に入れるのはおそらく簡単でしょう。

于 2011-09-12T21:30:16.367 に答える