状態
Linuxで次のものを生成するプログラムを実行しています。詳細なログがたくさんあります。到着するstdout
。
プログラム自体は機能を使用してバックグラウンドに移動しますsystemd.service
。
これまで、私は主なログレベルのみをディスクに保存し(使用syslog
または読み取りjournalctl
)、マイナーな詳細ログはstdout
。
という非常に安定したアプリがあります。リダイレクトこれにより、詳細なロギングptyに再接続できます。
したがって、プログラムで誤動作が発生するたびにそのPTYに再接続し、詳細なログを調べて何が起こっているのかを確認できます。
質問
スキーマを次に変更しました。建築 64そして、このプラットフォームではリダイレクトが利用できないようです。
考えられる解決策
- すべての詳細ログをディスクに保存し、通常どおりに確認します
tmpfs
。より重要なデフォルトログを早く失います。 - 疑似ttyから始める:リソースの無駄なので、systemd.serviceをscreenまたはtmuxで使用する可能性があるかどうかわかりません。
ほとんどの場合、メインログのみが必要です。毎週または2週間に1回チェックインします。
ただし、奇妙な動作が発生した場合は、詳細なログを調べてください。誤動作がなくなり、ログも失われるため、アプリケーションを再起動することはできません。
それでは、現在のptyをaarch64のカスタムアプリケーションのデフォルトのptyにどのように再接続しますか?
答え1
詳細なログをプログラムからファイルに送信し、それをファイルからシステムログに挿入できます。このファイルを頻繁に回転させます。 syslogは、優先順位の異なるログメッセージを別のファイルにフィルタリングし、必要に応じてファイルを循環します。