ほとんどのログファイルがバイナリ形式ではなくプレーンテキストを使用するのはなぜですか？

ロギングは必要ですが、（比較的）ほとんど使用されません。そのため、ストレージの点ではるかにコンパクトにできます。

たとえば、ip、date、timeなどの最も一般的にログに記録されるデータは、整数として表すことができ、テキストとして保存されています。

ロギングがバイナリデータとして保存されている場合、多くのスペースを保存できるため、特に書き込みが制限されているSSDでは、回転が少なく、ディスクの寿命が長くなります。

それほど重要ではない小さな問題だと言う人もいるかもしれませんが、そのようなメカニズムを構築するために必要な労力を考慮すると、それは意味がありません。誰でも2日間ほど空いた時間にこれを作成できます。なぜこれをしないのですか？

systemdログファイルをバイナリ形式で保存することは有名です。私が聞いた主な問題は次のとおりです。

1. ログが破損した場合、専門のツールが必要なため、回復が困難です
2. 彼らが読める人間ではありませんので、あなたのような標準ツールを使用することはできませんvi、grep、tailそれらを分析することなどを

（私の知る限り）バイナリ形式を使用する主な理由は、インデックスの作成など、データベースファイルのように扱う方が簡単だと考えられたからです。

私は、ディスクスペースの利点は実際には比較的小さい（そして減少している）と主張します。大量のログを保存する場合は、ロールされたログを圧縮するのが非常に効率的です。

結局のところ、ほとんどの場合、ツールの使いやすさと親しみやすさの利点は、テキストロギングの側で間違いを犯すでしょう。

ほとんどのログファイルがバイナリ形式ではなくプレーンテキストを使用するのはなぜですか？

Unix哲学のウィキペディアの記事で「テキスト」という単語を検索します。たとえば、次のような文があります。

当時のBell Labs CSRC（Computing Sciences Research Center）の責任者であり、Unixパイプの発明者であったMcIlroyは、Unixの哲学を次のように要約しました：[10]

これがUnixの哲学です。1つのことを実行し、それをうまく実行するプログラムを作成します。連携して動作するプログラムを作成します。テキストストリームを処理するプログラムを作成します。これはユニバーサルインターフェースであるためです。

または、たとえば、Unix Philosophyの基本から、

構成のルール：他のプログラムと接続するプログラムを設計します。

どのプログラムも相互に通信できない場合、複雑すぎるモノリスのプログラミングを避けることは困難です。

Unixの伝統では、シンプルでテキスト形式の、ストリーム指向の、デバイスに依存しない形式を読み書きするプログラムの作成を強く推奨しています。古典的なUnixでは、できるだけ多くのプログラムが単純なフィルターとして作成され、入力で単純なテキストストリームを受け取り、それを出力で別の単純なテキストストリームに処理します。

一般的な神話にもかかわらず、Unixプログラマーがグラフィカルユーザーインターフェイスを嫌うためではなく、この方法が好まれています。単純なテキストストリームを受け入れて送信するプログラムを作成しないと、プログラムを一緒にフックすることがはるかに困難になるためです。

テキストストリームはUnixツール向けであり、メッセージはオブジェクト指向設定のオブジェクト向けです。テキストストリームインターフェイスのシンプルさは、ツールのカプセル化を強制します。リモートプロシージャコールなど、より複雑な形式のプロセス間通信では、プログラムが相互の内部構造に関係しすぎる傾向があります。

誰でも2日間ほど空いた時間にこれを作成できます。なぜこれをしないのですか？

ログファイルをバイナリで保存することは、ほんの始まりです（そして些細なことです）。その後、次のことを行うツールを作成する必要があります。

• ログファイル全体を表示（edit）
• ログの先頭を読み取らずに、ログの末尾を表示します（tail -f）
• ファイル内のものを検索（grep）
• 選択/興味深いもののみを表示するためのフィルター（任意に複雑なフィルター式を使用）
• log-file-decoder-softwareを持っていない他の人にログをメールで送信します
• ログファイルのフラグメントをコピーして貼り付け
• プログラム（ログファイルを作成する）がまだ開発およびデバッグされている間にログファイルを読み取る
• 古いバージョンのソフトウェア（顧客サイトに展開され、実行されている）からログファイルを読み取ります。

明らかにソフトウェアはバイナリファイル形式も使用できます（リレーショナルデータベースなど）が、ログファイルに対しては（YAGNIの意味では）価値がなく、通常は実行する価値はありません。

ここには多くの議論の余地がある推定があります。

ロギングは、（ほぼ）私が経験したすべての仕事の不可欠な部分です。アプリケーションの状態に関する何らかの可視性が必要な場合は不可欠です。「フリンジ」の使用であるとは思わない。私が関与してきたほとんどの組織はログを非常に重要だと考えています。

ログをバイナリとして保存することは、ログを読み取る前にデコードする必要があることを意味します。テキストログには、シンプルで使いやすいという長所があります。バイナリルートを検討している場合は、代わりにログをデータベースに保存し、ログを調べて統計的に分析することもできます。

SSDは最近のHDDよりも信頼性が高く、大量の書き込みに対する議論はほとんど議論の余地がありません。本当に心配な場合は、通常のHDDにログを保存してください。

ログファイルは、深刻なアプリケーションの重要な部分です。アプリへのログインが適切であれば、どの主要なイベントがいつ発生したかを確認できます。発生したエラー。問題について聞いて、アプリケーションの組み込み診断を確認する（Webコンソールを開くか、JMXなどの診断ツールを使用する）のが一般的です。ログファイル。

非テキスト形式を使用している場合、すぐにハードルに直面します。バイナリログをどのように読みますか？本番サーバーにはないログ読み取りツールを使用して！またはそれは、しかし、ああ、親愛なる、我々は新しいフィールドを追加しました、そして、これは古い読者です。これをテストしませんでしたか？はい、しかし誰もそれをここに展開しませんでした。その間、ユーザーがpingを実行すると画面が明るくなり始めます。

または、これはアプリではないかもしれませんが、サポートを行っているので、この他のシステムとWTFであることを知っていると思いますか？ログはバイナリ形式ですか？OK、ウィキページを読み始めて、どこから始めますか？これで、ローカルマシンにコピーしましたが、破損していますか？何らかの非バイナリ転送を行いましたか？または、ログ読み取りツールが台無しになっていますか？

要するに、テキスト読み取りツールはクロスプラットフォームでユビキタスであり、ログはしばしば長命であり、急いで読む必要がある場合があります。バイナリ形式を発明すると、十分に理解された使いやすいツールの世界から切り離されます。必要なときに機能が大幅に失われる。

ほとんどのロギング環境は妥協点にぶつかります。現在のログを読み取り可能にして存在させ、古いログを圧縮します。つまり、圧縮のメリットを享受できるということです。実際には、バイナリ形式ではログメッセージが圧縮されないためです。同時に、lessとgrepなどを使用できます。

それでは、バイナリを使用することでどのような利点が得られるでしょうか？少量のスペース効率-ますます重要ではありません。書き込みが少ない（または小さい）まあ、おそらく-実際には、書き込みの数はディスクコミットの数に関連するため、ログラインがディスクのブロックサイズよりも大幅に小さい場合、SSDはとにかく新しいブロックを割り当てます。したがって、次の場合はバイナリが適切な選択です。

• 大量の構造化データを書いている
• ログは特に迅速に作成する必要があります
• 「サポート条件」の下でそれらを分析する必要はほとんどありません

しかし、これはアプリケーションのロギングとは思えません。これらは出力ファイルまたはアクティビティレコードです。それらをファイルに入れることは、おそらくデータベースへの書き込みからわずか1ステップの距離です。

編集

ここでは、「プログラムログ」（ロギングフレームワークごと）と「レコード」（アクセスログ、ログインレコードなど）の間に一般的な混乱があると思います。質問は後者に最も密接に関係していると思われ、その場合、問題はあまり明確に定義されていません。特にトラブルシューティングではなく、明確に定義されて分析に使用される可能性が高いため、メッセージレコードまたはアクティビティログがコンパクトな形式であることは完全に受け入れられます。これを行うツールにはtcpdump、Unixシステムモニターが含まれsarます。一方、プログラムログはアドホックになりがちです。

ややバイナリログの例は広く普及しています：Windowsイベントログ。プロ側では、これにより、ログメッセージが実質的に無料で、おそらく次のように非常に冗長になります（したがって、うまくいけば役立つ）。

警告：foobarのキューは、過去90秒間で517アイテム増加しました。これが1日に1回程度発生した場合、心配することはありません。頻繁に発生する場合や連続して発生する場合は、foobarアプリケーションで使用可能なRAMの量を確認することをお勧めします。ただし、イベント12345と一緒に発生する場合は、使用されていないデータベースを使用しているようで、データの損失を防ぐために+ 1-555-12345のサポートに連絡することをお勧めします。

このメッセージの主要部分は、アプリケーションと共にインストールされるリソースとして1回だけ存在します。ただし、このリソースが正しくインストールされていない場合（たとえば、この古いメッセージをサポートしなくなった新しいバージョンがインストールされているため）、イベントログに表示されるのは、単に空想的な言葉遣いの標準メッセージだけです

ダンノ、「517」と「90」のあるもの。

もはや役に立ちません。

テキストとバイナリを選択する前に尋ねたい主な2つの質問は次のとおりです。

• 私の聴衆は誰ですか？
• どのようなコンテンツを伝える必要がありますか？

一般的な意見は、ログメッセージの対象者は人間だということです。これは明らかに完全な仮定ではありません。多くのログクロールスクリプトがそこにありますが、それは一般的なものです。この場合、人間が快適な媒体で情報を伝えることは理にかなっています。テキストには、この媒体であるという長年の伝統があります。

内容に関しては、バイナリログは明確に定義された形式でなければならないことを考慮してください。他の人がそれらのログを操作するソフトウェアを作成できるように、フォーマットは十分に定義されている必要があります。いくつかのログは非常によく構造化されています（質問にはいくつかリストされています）。他のログには、あまり明確に定義されていない自然言語形式でコンテンツを伝達する機能が必要です。このような自然言語の場合は、バイナリ形式にはあまり適していません。

バイナリで十分に説明できるログについては、選択する必要があります。テキストはすべての人に有効であるため、多くの場合、デフォルトの選択肢と見なされます。結果をテキストで記録すると、他の人がログを操作できます。何千回も証明されています。バイナリファイルは複雑です。その結果、開発者は、それがどのように振る舞うかを誰もが知っているという理由だけでテキストを出力する可能性があります。

TL; DR：サイズは重要ではありませんが、使用の利便性は重要です

まず第一に、短期的なログ保存のためのテキスト形式とバイナリ形式のそれぞれの利点を比較することは重要な問題ですが、サイズは実際には重要ではありません。これには2つの理由があります。

1. ログは非常に冗長な情報であり、非常によく圧縮されます。私の経験では、サイズが元のファイルのサイズの5％以下である圧縮ログファイルを見ることは珍しくありません。したがって、テキストまたはバイナリ形式を使用しても、ログの長期保存に測定可能な影響はありません。

2. どの形式を選択しても、ログファイルを圧縮して長期ストレージプラットフォームに送信する「ログファイルシンク」を実装しないと、ログはサーバーディスクをすぐにいっぱいにします。バイナリ形式を使用すると、これが少し遅くなる可能性がありますが、10倍に変更してもそれほど問題にはなりません。

テキストとバイナリログ形式

Unixシステムの約束は、grep、sort、join、sed、awkなどの行で構造化されたテキストファイルで作業する標準ツールセットを使用することを学べば、あらゆるジョブを実行するプロトタイプを迅速に組み立てることができることですゆっくりと粗雑ではありますが。プロトタイプの有用性が実証されたら、実際に設計されたソフトウェアに変換して、パフォーマンスを向上させたり、他の便利な機能を追加したりすることができます。これは、少なくとも私の理解では、Unix哲学の本質です。

別の言い方をすれば、今日までに理解できない治療や分析を実行する必要がある場合、この分析を誰が実行すべきかわからない場合など、プロトタイプを使用する段階にあり、ログはおそらく最適です。十分に特定された少数の治療を繰り返し実行する必要がある場合、多年生のソフトウェアシステムを設計してこの分析を実行し、リレーショナルデータベースなどのログのバイナリ形式または構造化形式を実行する必要があります最適な。

（しばらく前に、これについてのブログ記事を書きました。）

ログファイルはテキスト形式です。これは、任意のタイプのテキストエディターを使用するか、コンソールコマンドで内容を表示することで簡単に読み取れるためです。

ただし、大量のデータがある場合、一部のログファイルはバイナリ形式です。たとえば、私が作業している製品には、最大15000レコードが保存されます。最小の部屋にレコードを保存するために、それらはバイナリで保存されます。ただし、レコードを表示したり、使用可能な形式（スプレッドシートなど）に変換したりするには、特別なアプリケーションを作成する必要があります。

要約すると、すべてのログファイルがテキスト形式ではありません。テキスト形式には、コンテンツを表示するためにカスタムツールが必要ないという利点があります。大量のデータがある場合、ファイルはバイナリ形式である場合があります。バイナリ形式には、データを読み取り、人間が読める形式で表示するための（カスタム）アプリケーションが必要です。より多くのデータをバイナリ形式にパックできます。テキスト形式とバイナリ形式のどちらを使用するかは、データの量とコンテンツの表示のしやすさに基づいて決定されます。

ランタイム中に利用可能な出力チャンネルがないかもしれない組み込みシステムでは、アプリケーションはロギングによって課せられた速度の打撃に耐えられないか、ロギングは記録しようとしている効果を変更またはマスクします。バイナリデータを配列またはリングバッファーに詰め込み、テスト実行の最後にprintf（）するか、それを生でダンプしてインタープリターを記述して読み取り可能に出力することに頼りました。いずれにせよ、私は読み取り可能なデータになりたいです。

より多くのリソースを備えたシステムで、最適化が不要なものを最適化するスキームを作成する理由は何ですか？

ログファイルは、問題のデバッグを支援することを目的としています。通常、ハードドライブのスペースはエンジニアリングの時間よりもはるかに安価です。ログファイルはテキストを使用します。テキストを操作するためのツールが多数あるためです（などtail -f）。HTTPでさえプレーンテキストを使用します（httpのテキストの代わりにバイナリを送信しない理由も参照してください）。

さらに、プレーンテキストロギングシステムを開発して動作することを確認する方が安価であり、問​​題が発生した場合にデバッグしやすく、システムに障害が発生してログの一部が破損した場合に役立つ情報を簡単に復元できます。

破損したテキストファイルは、破損した部分の周囲でも読み取り可能です。破損したバイナリファイルは復元できる場合がありますが、復元できない場合もあります。たとえ復元可能であったとしても、かなり多くの作業が必要になります。もう1つの理由は、バイナリログ形式により、「一時的な修正」（別名「すべての修正の中で最も永続的な」）を急いで作成する可能性が低くなるためです。

ソフトウェアの堅牢性を達成し、維持するための単体テストを期待しています。（ほとんどのコードはサーバーで実行され、ヘッドレスです。ログファイルの操作後の分析が重要な戦略です。）実装のほぼすべてのクラスは、何らかのロギングを実行します。単体テストの重要な部分は、単体テスト時に使用される「モック」ロガーの使用です。単体テストは、模擬ロガーを作成し、テスト対象のアイテムに提供します。次に、（有用/適切な場合）ログに記録された内容（特にエラーと警告）を分析します。テキストベースのログ形式を使用すると、「実際の」ログで実行された分析とほぼ同じ理由で、これがはるかに簡単になります。

歴史的に、ログは公式の手書きのイベントの連続した記録でした。機械がイベントを記録できるようになると、これらはテレタイププリンターなどのハードコピー出力デバイスに書き込まれ、永久シーケンシャルレコードを生成しましたが、テキストのみを処理でき、時々ベルを鳴らしました...

私のメインフレーム時代には、カスタムデザインのバイナリログ形式を使用していました。主な理由はスペースを節約することではなく、古いエントリを新しいエントリで上書きすることでログが有限のスペースを占有するようにしたかったためです。最後にしたかったのは、ディスクがいっぱいになったために発生した問題を診断できないことでした（1980年には1 MBあたり1,000ドルのディスクスペースが必要だったため、人々は必要以上に購入しませんでした）。

今でも私は今でも循環ログファイルのアイデアが好きで、オペレーティングシステムがそのような野獣を提供していたなら、私はためらうことなくそれを使用するでしょう。しかし、バイナリは悪い考えでした。重大な問題を解決する必要があるときに、ログファイルを解読するための適切なコマンドを見つけるのに時間を浪費する必要はありません。