抽出ルールを実行する位置に応じて、センター側とログ側の２種類のプラクティスが存在する。
中央エンドは、Kafka 送信などを介して、処理対象のすべてのマシンのログを中央センターに送信し、最終的に Elasticsearch に送信されます。インデックス抽出ルールは、ストリーム コンピューティング タスクとして Kafka チャネルに挿入できます。パフォーマンスとリアルタイムパフォーマンスは比較的優れています。または、スケジュールされたタスクを直接書き込み、Elasticsearch のインターフェイスを呼び出してログをクエリし、同時に集計計算関数を提供し、Elasticsearch にインジケーター データを返させ、それをタイミング ライブラリに書き込みます。貧しいかもしれないが、基本的には十分です。
ログ側の処理とは、抽出ルールがログを生成するマシン上で直接実行され、ストリーミング方式でログを読み取り、正規表現と照合することを意味します。ヒット ログの場合、その数値部分を指標として抽出するか、数値を抽出せずにヒット ログの行数のみをカウントすることが有益な場合があります。たとえば、エラーや例外の発生数をカウントする場合などです。キーワードを入力すると、システムがわかります。エラーですか?
ログ端末処理メソッドには多くのオープンソース ソリューションがあり、より有名なものは mtail と grok_exporter です。
mtail や grok_exporter などのツールは、ログ ファイルに対して tail -f を実行するようなもので、ログを受信するたびに、事前定義された正規表現と一致します。一致に成功した場合は、いくつかのアクションが実行され、それ以外の場合は待機をスキップします。次のログ。
mtail のデプロイメントでは、mtail を使用してインジケーターを抽出する必要があるマシン上に 5 つのアプリケーションがあり、各アプリケーションのログ形式が異なる場合は、5 つの mtail プロセスを開始して個別に処理することをお勧めします。管理は面倒ですが性能は良くお互いに影響はありません。
すべての抽出ルールを 1 つのディレクトリに配置し、これらの複数のアプリケーションのログ パスを -logs パラメータで複数回同時に指定すると、1 つの mtail プロセスでも処理できますが、mtail はログの各行に対してすべての抽出ルールを取得する すべての抽出ルールを一度に実行するのはパフォーマンスの無駄であり、通常の抽出の速度は速くありません。さらに、一部のインジケーターはすべてのアプリケーションで再利用される可能性があるため、一緒に処理すると相互に干渉しやすくなり、不正確な統計データが生成されます。この 2 つの観点から、分解して個別に対処してみると、管理が面倒になりますが、それだけの価値はあります。
コンテナ シナリオではそのような問題は発生しません。コンテナ シナリオはサイドカーを使用して直接デプロイできます。各ポッドにはアプリケーションが 1 つだけ必要であり、関連付けられた mtail はこのアプリケーションのログの処理のみに集中できます。
指標を抽出する方法はいくつかありますが、一般的にはセントラルターミナルとログターミナルの2種類があり、セントラルターミナルの処理方法は商用ソフトウェアで一般的であるため、オープンソースのソリューションは見当たりません。ログ側の核となる処理ロジックは同じで、tail -f と同様の方法でログ内容を継続的に読み取り、ログの行ごとに定期的なマッチングを実行します。ログの形式が固定されていないため、処理が困難です。構造化された処理方法を持つ必要があるため、これらのツールはすべて、フィルター インジケーターを抽出するために通常の方法を使用することを選択します。
この記事は8月のDay13の学習ノートです 内容はGeek Timeの「運用保守監視システム実践ノート」です この講座はオススメです。