エラーログを維持するためのベストプラクティス(システム、デバイスドライバ、およびアプリケーション)

エラーログを維持するためのベストプラクティス(システム、デバイスドライバ、およびアプリケーション)

Ubuntu armhfとWi-Fi経由で接続されたPCサーバーを備えた複数のPandaboardがあります。各組み込みボードには、継続的に実行されるリアルタイムアプリケーションがあります。

多くを監視する必要があるため、ログを正しく維持する方法がわかりません。

  1. システムエラー(ファイルシステム、過熱など)
  2. デバイスドライバエラー(Wi-FiおよびUSB)
  3. アプリケーションの終了(衝突と予想される競合)

これまで私の考え:

  1. 重大度レベル0〜3などのシステムログをフィルタリングして、関連するシステムエラーを見つけます。どうすればいいですか?
  2. デバイスドライバの問題はシステムログにもあります。
  3. 現在私はcoutとcerrを別々のファイルに記録しています。アプリケーションがクラッシュする場合は役に立ちません。デバッグモードで実行するには、あまりにも多くの処理能力が必要であり、システムはもはやリアルタイムではないようです。
  4. 毎日ログを交換するよりも、コンピュータが起動するたびにログが大きすぎるまでsyslogを使用することをお勧めします。あるいは、アプリケーションが起動するたびにアプリケーションログを交換することをお勧めします。
  5. すべての重要な問題は、サーバーで読みやすいファイルにパイプすることができます。

エラーロギングを効率的に維持するためのすべてのアイデアを歓迎します。現在、私はFabric Pythonライブラリを使用してサーバーPCとPandaboardの間で診断情報とアップデートを転送しています。

答え1

システムロガー(System Logger)はこれをシステムロガー(System Logger)と呼びますsyslogが、Ubuntuではシステムロガー(System Logger)というより洗練されたバリエーションを使用することも、使用しないこともありますrsyslog。最も簡単な方法は、ls /etc | grep syslog独自の基本設定ファイルと追加の.d設定を実行するディレクトリです。アプリケーション内でシステムロガーに情報を提供できますが(例:man loggerおよび参照man 3 syslog)、恥ずかしい複雑さを望まない限り、この方法は主要なエラーを処理するのに最適です。

紹介も多いシステムログチュートリアルオンライン。 Rsyslogはsyslogと互換性があるように設計されており、追加のドキュメントは次のように提供されています。彼らのウェブサイト。デフォルトの設定/var/logでは、通常、次のようにメッセージをさまざまなファイルにフィルタリングします。施設そして深刻さ。すべてのメッセージのすべてのコピーを収集するファイル(例/var/log/syslog:)がある場合もあれば、他の形式の重複もあります。 Rsyslogは、コンテンツに基づいてメッセージをフィルタリングする追加機能を提供します(たとえば、通常は特定のアプリケーションに添付されているタグと一致させることができます)。

ログローテーションのWRT関連アプリケーションは、通常デーモンによって実行されますlogrotate(参考文献を参照)。頻度などの制御は、その構成(通常は他のファイルから)とcronを介して実行する必要があります。デフォルトの設定ファイルを使用しないため、関連するcrontabでどのように呼び出されるかを確認したい場合があります。man logrotatecron/etc/logrotate.conf/etc/logrotate.dlogrotate

関連情報