返信してくれてありがとう！この手のシステム（大規模、イベント駆動）での作業はまだ始めたばかりで、HNには自分よりずっと上手い人がいるから、彼らの意見が気になって投稿したんだ。結局、ログとメトリクスの違いって何なの？ どちらかが構造化されていて、もう一方が非構造化？ 一方が巨大なテキストの塊で、もう一方が時系列データベースに保存されてる？ 現在は、構造化ログをLokiに入れて「メトリクスをログしてる」感じかな。それで、後で解析してプロットできるんだ。君や他のコメント者たちのおかげで、この分野をもっと掘り下げるための語彙が得られたよ。ありがとう！

メトリクスは集約のおかげでクエリがずっと早いし、機能が変わっても安定してることが多い。任意の集約の下で真実であり続けるもののためにメトリクスを保存するのは良いことだよ。例えば、合計、カウント、最大値などは良いけど、パーセンタイルのように集約に耐えられないものは避けた方がいいね。

投稿がいい感じだと思った。前にスクリプトを書いたとき、カウントで印刷して圧倒されちゃったことがある。カウントの数字を変えるんじゃなくて、時間を使えばよかったな。

この投稿はよくある罠にはまってるね；ログとメトリクスを混同してる。これは「混同」ってより、メトリクスをログにエクスポートするためのアドホックなメトリクスサブシステムを構築してるって感じ。x秒ごとにスクレイピングされるプロメテウスのエンドポイントを公開するのと、x秒ごとに同じデータをログに印刷するのに理論的な違いはないよ。

メトリクスやトレース、ログメッセージなどをログした後にフィルタリングと集約をしよう；前にやるんじゃなくて。データの保持やロールアップ、データストレージを制限するための他の戦略は、データを発信するシステムとは別に考えられるよ。少なくとも、適切なデータストアを使えばね。オープンサーチやエラスティックサーチのやり方が結構好きだな。エラスティックサーチではデータストリームがあって、時間やデータサイズに基づいてロールオーバーするように設定できる。ロールオーバーが終わると、インデックスは読み取り専用になって、新しいデータは現在のものに追加される。古いものに対して何をするかを決めるライフサイクルポリシーを定義できるし、例えばコールドストレージに移したり、ロールアップで変換したり、最終的には削除することもできる。アプリケーションのログでは、通常は異なるログレベルを割り当てるよね。トレースやデバッグは通常、本番環境では無効にされてる（そうあるべきだし）。インフォは結構うるさいことが多い。ワーニングは繰り返しがち（開発者が警告を無視して、修正しないことが多いから）。エラーは珍しいはず。エラーがログされると、すぐにメールが来るようにシステムを設定してる。エラーは何かが壊れてるってことだから、修正が必要だよ。エラーにはゼロトレランス。エラーが発生したとき、他のログ情報がコンテキストを提供してくれるから、その価値はある。ただし、せいぜい数日間だけ。週末やクリスマスを乗り越えるのに十分な長さ。だけど、その後はただのノイズになっちゃう。大体2週間で厳しく切ってる。カバー理由で長く保存する必要がある場所もあるけど、データ保持にはもちろんコストがかかる。巨大なデータ量をログして、エラーを無視する会社を見たことがある。1日30GB。ほんとにひどい。私：「あなたのデータベース層がずっとエラー出してるみたいだけど（制約違反とかそれ以上のこと）、何か対策した方がいいんじゃない？」彼ら：「ああ、これは普通だから、無視してるだけだよ」（PHPショップで、無能が普通だった）。私：「じゃあ、何か壊れたときどうやってわかるの？！」彼ら：「......？！」私の高給のコンサルティング仕事は、この運営に少しでも常識を叩き込むことだった。あるマネージャーが、こんな無駄に年間数十万も使ってることに気づいたから。私のフィーはその中では誤差みたいなもんだった。今までで一番簡単な仕事。でも、彼らが実際に何をやってるのか、なぜそうなってるのかを調べ始めると、ちょっと恥ずかしかった。ほとんどが、「ああ、誰かが一度設定しただけで、その後は見てなくて、彼は辞めちゃった。どうするつもり？！」みたいな感じだった。この会社にはそういうのがたくさんあった。リソースの無駄や、ログからの意味のあるフィードバックを気にする人が全くいなかった。もしそれがあなたのチームなら、何か手を打つ必要があるよ。それがあなたの仕事で、ちゃんとできてない。外部のコンサルタントに言われる必要があるなら、大きく変えることを考えた方がいいかもね。

ログを通じてメトリクスを収集するシステムを作ったんだけど、全く別のシステムを設定したくないときに、私のアプリにはうまく機能してるよ。

これに対する一つの例外は、インストーラーやrsync、curl、ddなどの明確な開始と終了があるバッチスクリプトやCLIツールだね。ここでメトリクスを設定するのは過剰すぎるし、ユーザーは進行状況に興味があるかもしれない。ログを通じて提供するのが一番簡単だよ。カースUIはいい中間地点かもしれないけど、やっぱり過剰になることが多い。

アマゾンでのメトリクスシステムは楽しかったし、オクタでも似たようなAPIで書いたんだ。オープンソース用にもう一つ書くのもいいかも。メトリクスシステムで欠けてるのは、ビジネスオペレーションの文脈で細かいメトリクスを保持して、トレンドのために遅延集計を使うことだと思う。前に見たとき、ほとんどのメトリクスシステムは個々のイベントをログに記録して、集計するには処理が必要だったり、早すぎる段階で集計してしまって、個別のオペレーションやリクエストへの影響がわからなかったりした。リクエストごとのカウントや統計、タイミングを取得しつつ、ホストやデータセンター、地域、粒度で集計して高レベルのトレンドを得るというバランスが必要なんだけど、ほとんどのメトリクスAPIはこの考え方と合わないんだよね。

テキストの行ではなくJSONオブジェクトとしてログを残す または、人間にとって読みやすく、オーバーヘッドが低く、構造化されていて、少なくともGrafana/Lokiで解析やクエリに対応しているlogfmtもいいね。

同僚たちはできるだけログを少なくしようとするし、俺が見てきたプロジェクトのほとんどは、ログをイベントストリームではなくファイルとして扱ってる。検索やフィルタリング、分類、自動アラートができるのにね。ちょっと残念だな。例えば、コード内の分岐をログに残すことに反対する声があったりするけど、トレースログ（他の人が追加しないもの）だけは問題が起きた時にオフになってることが多い。個人プロジェクトではかなり助かるけど、限られたトラフィックのおかげで、十分なログが引き起こすかもしれない問題が最小限に抑えられてる。少なくとも、GlitchTipやSkywalkingのようなAPMを追加する方向に進むことはできるね。

可能なら、ユーザーごとにログレベルを設定して、特定のユーザーの問題をデバッグできるように それは賢いアイデアだね。今後絶対に使わせてもらうよ。

このアドバイスに従って、ログを生成することが主な機能と言えるサービスを見たことがある。実際にユーザーへの応答は生成されるトラフィックのほんの一部に過ぎなかった。私たちが本当に必要なのはスマートなログだよ：エラーが検出されたときだけフルスパンをログする、それ以外は必要ない。だけど、あまりサポートされてないケースなんだよね。

それでも、各スレッドは毎秒（またはその期間）ごとに別々のログ呼び出しをすることになるから、全スレッドが一つのログ呼び出しに集約するわけじゃないんだ。

なんか、開発者が実際のメトリクスの代わりにログを使うのが好きな理由に気づいたよ。うちはDatadogを使っていて、何度も開発者がアプリケーションに追加のロギングを加えて、そのログイベントをカウントするモニターを作るのを見た。これは抵抗が少ない道を選んでるって感じだね。ログを出すのはすごく簡単だし、カウントするのも簡単。実際のメトリクスを報告するのも難しくはないけど、システムに慣れてないと、どうやってやるかを見つけるのがログラインを出すよりも手間がかかるから、そうなるんだよね。