一部のソフトウェアの出力がファイルではなくコンソールに書き込まれる場合、どのような欠点（パフォーマンスの側面）があるのか疑問に思います。
具体的なケースは、一部のプロセスが意図的にstdoutにログインするように構成されているため、Dockerコンテナを実行することです。
ファイルの場合、私が考えることができる唯一の問題は、ログで使用されるスペースとロギングの強度に応じたいくつかのIOです。
たとえば、アクセスログをstdout（コンソール）に記録するDockerコンテナにWebサーバーアプリケーションがあり、コンテナが1年間実行され続けているとします。この大きなバッファはメモリ（カーネル1？）に残ります。それとも、カーネルが特定の制限の後に最終的に時間を消去しますか？
この場合、メモリの枯渇とカーネルパニックを心配する必要がありますか、それとも概念を誤解していますか？
（app | container | nodeが閉じられると、コンソールがdmesg消去されたときと同じように更新されることがわかります。）
ベストアンサー1
これは悪い考えです。
システムコンソールへのログ記録は、ログ出力を次に送信する特別な場合です。どの物理端末またはカーネル仮想端末装置。そこいいえカーネルバッファの増加。端末ディスプレイの上部からスクロールする内容は失われます。
しかし、これはWWWサーバーを記録するのには悪い考えです。
教訓Bash は、特定の受信要求の後に無効な文字を表示します。「そして攻撃者に端末に任意のコンテンツを書き込む方法を与えないでください。特にシステムコンソールの場合。
そして、LANにセキュリティが必要ないと仮定しないでください。 いつも物を受け入れるセキュリティサーバーどのネットワーク。
プロセスの標準エラーと標準出力をパイプに接続し、パイプのもう一方の端は以下に示すツールの1つです。https://unix.stackexchange.com/a/505854/5132:
./記録する内容2>＆1 |自転車ログ/
これらのツールは、ファイルがlogs/指定されたディスク容量を超えないようにし、正しい場所でログを自動的に回転させます。このような簡単な方法でもログを見ると、less攻撃者が提供したデータがエンドデバイスにそのまま送信されるのではなく、ある程度削除されたことを確認できます。 （もちろんoptionsを使用しないでください-R。）less
追加読書
- ジョナサンデボインポラード（2018）。 」Linuxコンソール」。 装備。 Nosh ツールセット。
- ジョナサンデボインポラード（2016）。 」記録」。 スナックガイド。ソフトウェア。
- ジョナサンデボインポラード（2015）。 」記録」。デーモンツールシリーズ。よく与えられる答えです。