私が関わってきたほとんどすべてのアプリケーションでそうであるように、ロギングは、古き良き文字列ロギングフレームワークに依存する二級市民になりがちです。
しかし最近、ロギングには現在の文字列ベースのロギングシステムでできること以上のことがたくさんあることに気づきました。特に、システムがスケーラビリティに優れたクラウドにデプロイされている場合、テキストファイルをキャプチャして公共の場所に集約することは、ハッキングのように感じられます。
最近のアプリケーションでは、文字列ベースのロギングの欠如を補う、より複雑な情報を持つメッセージングメカニズムが実装されました。メッセージはアプリケーションの中心にある」と言った同僚に感謝しなければなりません。ロギングがシステムの中核であるとは考えていませんでした。ビジネスロジックがアプリケーションの中心であり、ロギングではありません。しかし、彼の言葉は真実に富んでいます。なぜなら、システムが期待通りに動作しているかどうかを知るための優れたメカニズムなしには何もデプロイできないからです。
- 現在開発中のタスク
- データソース
- ログを開始するコンポーネントである
- 例外がスローされます。
- 入力パラメータ
- リクエストを伝える Spring統合メッセージのメッセージ履歴。
複雑なオブジェクトを "スキーマレス "のスタイルで保存できるので、ログをクエリすることもできます。このようにして、大量のエラーが検出されたときに警告とレポートを生成するスケジュールされたタスクを持つことができます。
アラート専用のフレームワークがまだないため、これはカスタムロギングの実装ですが、古典的な文字列ベースのログファイルよりも多くの価値を得ることができました。
私は、まだlog4jとlogbackが素晴らしい実装であり、単にそれらの制限を克服するために追加のロギング機能を追加して、まだそれらを置き換えていないと思います。もし、デバッグの目的で使用していて、本番環境で追加の監視方法があるのであれば、開発環境と本番環境の両方で適用できる賢いロギングソリューションを使用する時かもしれません。
10年前、リレーショナル・データベースがストレージの世界を支配していた頃、それを実装するのは難しく、ファイルベースのロギングが良い妥協点でした。現在では、より良いロギングフレームワークを実装する方法があると思います。現在の "文字列ベースのファイルロギング "モデルは、特にサーバーが1台のマシンに垂直にスケールされる場合には、十分に効率的です。しかし、多くのサーバーが水平に分散している世界では、このモデルは追加の処理を必要とします。
LinkedIn Kafkaのログ処理など、大手企業はすでにこの新世代のログシステムを利用しています。
私はLinkedInのソリューションがとても好きで、CQRS方式で動作する新しいロギングシステムを探求するきっかけを与えてくれたのも彼でした。このロギングシステムでは、ログエンティティはイベントのようにログデータベースにデポジットされ、各イベントは一連の操作を通して現在のシステム状態を更新します。これはログとモニターを組み合わせたもので、各モニターコマンドは直接***システム状態のプレゼンテーションをキャッシュします：
- アラート
- ステータス・レポート
- 現在のシステム状態を監視するビュー
また、新世代のログのためのオープンソースプロジェクトを開始する時が来たのでしょうか？
