独自のネットワーク接続を監視する必要がある組み込みLinux/Busyboxシステムがあります。デバイスがネットワーク上で10分以上「一人で」実行されていることを確認し、その場合は修正措置を講じようとします。システムが物理的にアクセスできない場所にある可能性があります。
私は主にシステムのネットワークトラフィックゼロなどの重大なエラーを検出するための一般的なソリューションを探しています。私たちのサーバーは監視できます特定自分の港。
rootfsは最大サイズの16MBにすばやくアクセスしているため、多くの一般的なアプリケーションはもはやオプションではなく、たとえばnmap16MBtcpdumpの制限を超えています。
これが私の考えです：
- の一部のエントリは、
/proc/net最後のTCPまたはUDPパケットの時刻を示すことがあります。 - ネットワーク上の任意のピアを見つけてpingを試みます（聞いている人はいますか？ ？ ？)
- モニター数が
/sys/class/net/eth0/rx_packets増えますか？
最も信頼できるものは何ですか？
答え1
最後の2つのアイデアはすべて良いアイデアです。 （最初のアイデアは3番目のアイデアとほぼ同じです。）問題は、アクティブモニタリングが必要かどうか、手動モニタリングが必要かどうかです。
受動的モニタリングの要点は、例えば、ボックスが提供するサービスを積極的に使用するクライアントがないため、トラフィック不足が正常である可能性があることです。ユースケースに応じてこれが起こらないと仮定できる場合は、手動監視をお勧めします。
アクティブなモニタリングについての反対意見の1つは、モニタリングすることを選択した特定の外部リソースが実際にダウンしている場合（つまり、問題が反対側にある場合）に誤りを誤って宣言することです。複数の外部リソースを事前に監視し、同時にアクセスできない場合にのみ対応することで、この問題を軽減できます。