REVIEW：、モジュールを取り扱うログ増分変換モジュール、抽出手順の全体量は、処理モジュールオペレータ、ハートビート監視モジュール、ウェブ管理モジュールログ：データバスDバスの全体的なアーキテクチャ、すなわち、6つのモジュールを含みます。6つのモジュールは、Dバスの動作原理を形成するように相互接続されている各機能：リアルタイム（フルサポートを引っ張る量）で増分データRDBMSログの増分を読み取ることによってログを取得し、ベースLogstash、水路、実際のクローラ等filebeatデータが出力構成されている方法を視覚化するために、データを取得します。本論文では、実装されたログ構造化Dバス変換ベースのビジュアル構成の一部を説明します。
ログの最初に、構造的な原則
1.1ログソースのクロール
Dバス・ログは、例えば、様々なデータソースをインターフェースすることができる：Logstash、水路、Filebeatが好き。不要避けながらホイールを重複を作成し、上記成分は、使用者の技術的なソリューションを簡単に統合のための1つの手とユーザーフレンドリーな統一業界標準に、より一般的な業界誌クローラーです。我々のデータは、元のデータ（生データログ）、カフカが書き込み把持アセンブリと呼ばれるログフェッチ次の処理Dバスを待ちます。
1.2可視化構成規則は、ログ構造化することを
ユーザーが設定ログ送信元と送信先のエンドをカスタマイズすることができます。同じソース・データ・ログは、シンクの複数に出力することができます。各「ログソース - シンク」行は、ユーザが自分のニーズに応じてフィルタリングルールを構成することができます。ポストルール計算サブ処理ログが構成された後、即ち：データベーステーブルと同様のスキーマの制約。
1.3ルールの演算子
データの操作をカスタマイズするための豊富なと簡単にDバスのデザインは、演算子を使用します。再利用可能な異なるオペレータは、彼らが必要とするデータを切り出すために、変換されるまで、及び、ユーザ・データの処理は、複数のステップに分割することができる処理結果データの各ステップは、即時確認することができ、検証。
1.4実行エンジン
オペレータに適用される設定されたルールは、実行エンジン、対象ログデータ、予め形成された構造化データ、カフカへの出力、消費者の使用のためのダウンストリームデータを設定します。次のようにシステムのフローチャートです。
Dバスのログ設計原理、同じ生ログは、1つまたは複数のテーブルに抽出することができます。各テーブルは、同じスキーマの制約を満たすように構成されています。
- 各テーブルは、オペレータセットのルールの集合であり、各テーブルは1つまたは複数のルールオペレータ基を有していてもよいです。
- 各ルールセットのオペレータ、オペレータのルールの組み合わせのセット、独立性を有する各オペレータ;
いずれかのログ生データ（生データログ）のために、それがどのテーブル、それに属している必要がありますか？
ユーザがシート論理テーブルの数（T1、T2 ...）を定義した場合、ログの種類を抽出するために、各ルールグループオペレーターと照合するログ。
- 特定のテーブルT1のオペレータグループのすべてのルールに実行アクセス
- 資格オペレータは、ルールセットを入力し、実行エンジンは、テーブルのデータ構造に変換されます。
- ログの下にルールオペレータグループの条件を満たしていない抽出しようとすると
- 要件が満たされていない場合T1オペレータ設定されているすべてのルールについて、プロセスは、その次のテーブルT2を実行し、に進み
- ログは_unknown_table_に任意のフィルタルールにテーブル、テーブルと一致していなかった場合
例えば、複数のルールのセット又は表に属していてもよい同一のアプリケーションログのため、ルール・セット、または我々があれば、フィルタ条件を満足するように定義表に、アプリケーションログは、同じことを確実にするために、すなわち、ルールのセットを抽出することができますアプリケーションログには、ルールや表の異なるセットに属していてもよいです。
オペレータは、ルール・データのフィルタリング、処理、ベースユニットの変換です。オペレータ共通規則は上に示しました。
オペレータ間の独立性は、反復演算子を使用することにより、複雑な、高レベルの機能の数を達成することができ、最終的にどのようなデータ処理目的のために達成することができる演算子の間の任意の組み合わせで使用することができます。ユーザーは、カスタム演算子を開発することができ、子どもの発達のオペレータがいる限り、ユーザー・インターフェースは、基本的な原則に従うことなど、何か作業を開発することができ、非常に簡単です。
二、Dバスログ処理例
Dバスクラスタ環境への、例えば、2台のマシンがDバスクラスタ（すなわち、マスター・スレーブ）の監視、統計、早期警告のためのハートビートの手順を展開するがあり、急速な心拍プログラムは、いくつかのアプリケーションログを持っています、アプリケーションログには、この種のイベントが含まれています私たちは、データベース構造にこれらのログを処理し、分類したい場合は情報を、我々はDバスのログプログラムを使用してログを扱うことができます。
Dバスは、複数のデータソース（Logstash、水路、Filebeat等）にアクセスすることができる、ここで説明するためにDバス例をLogstashする方法アクセスログデータ及びアラーム監視。
監視と早期警戒へのdbus-N2と我々はLogstashプログラムを展開し二台のマシン上にあったそのためのdbus-N3二台のマシン上でログました。彼らはハートビートないため、ハートビートデータは、Logstashその役割統計データおよび出力のためのDバスを容易にするためにあるハートビートプラグイン、並びにソース抽出ログ（ここでLogstash）端Filebeat水路のための早期警告（とを搬送することによって生成されますプラグインなので、追加のデータタイミングジェネレータハートビートの必要性）。通常、だけでなく、心拍データの両方のデータ形式に書き込まれたカフカLogstashプログラムデータ。
ここではちょうど2つのプログラム展開Logstashマシンに限定されるものではなく、Dバスがない、あなただけの各マシン上でLogstashプログラムを展開する必要があるようなマシンの数百数十人に分散アプリケーションログとしてLogstash、数の制限、および統一されたデータで同じカフカトピックに描かれた、Dバスは、データ処理、監視、早期警告、および統計情報のすべてのホストのデータに対して実行することができます。
2.1 Logstashを開始
Logstashプログラムを開始した後、我々はトピックからすることができ、次のようheartbeat_log_logstashは、データサンプルをデータをお読みください。
1）ハートビートデータ
2）通常のログデータ
2.2構成ルール
次に、我々は処理できるデータにDバスのWebでの適切なルールを設定する必要があります。
最初の論理テーブルsink_info_tableを作成し、テーブルは、元としてログ情報シンクイベントは、対応するテーブルのthenルール（一つ以上ではなく、フィルタルールスキーマ属性の同じセットを満たすために必要なデータの全て）、heartbeat_log_logstashを抽出するために使用されトピックのデータは、我々は、リアルタイム操作の設定（WYSIWYG、即興の検証）にデータを視覚化することができます。
1）生データのログを読んで
Logstashが以前のlog4jは、そのようなパス、@タイムスタンプ、レベルなど、基本的な情報が含まれて抽出されてから見ることができます。しかし、データの詳細は、ログフィールドにログインします。異なる出力ログデータに同じではないので、そのログデータ列が異なっていることが分かります。
関心の2）抽出カラム
私たちは生の情報をタイムスタンプに興味がある場合は、ログインして、その上、あなたはこれらのフィールドを抽出するためにtoIndexの演算子を追加することができます。
それは注意しなければならない、我々は、配列の添字モードの使用を検討し、理由がある： - 対象外のすべての列は、独自のカラム名が付いています（例えば水路は、生データを抽出し、またはサブ処理した後、カウントデータ列を分割する）; - 下付きモードあなたが（例えば、パイソン同様に、1：1：3が1、2列表す）列配列を指定することができ、配列添字アクセスモードしたがって、すべての後続の動作を制御します。
フィールドが抽出された後、ルールの実装、我々は状況を見ることができます：
3）データのフィルタリングが必要
この例では、「OK influxdbに沈む！」のデータを含むにのみ関心があります。だから、フィルタ演算子を追加し、抽出カラム7は、行データの内容「！OKをinfluxdbに沈む」が含まれます。
実行後、資格のログ行のデータが存在します。
4）特定の列の抽出
選択オペレータを追加、我々は、第一及びコンテンツ三ので、抽出のための2つの列に興味を持っています。
選択オペレータ行われ、データは1つだけと3含まれています。
5）正規表現のデータを処理するように
私たちは、最初の列からのデータの値に沿って、特定の正規表現を抽出する、データをフィルタリングするregexExtract演算子を使用します。:.を次のように正規表現があります（。*）（*）（*）（。*）。HTTP_CODE =（\ D *）*タイプ=、DSの=、スキーマ=、テーブル= \ ERRORCOUNT =（S * \ dは*）、ユーザーは、カスタムの正規表現を書くことができます。
実行後、正規表現の実行後にそれを取得します。
6）カラムの出力を選択します
最後に、我々は、リレーショナルデータベースで持ちやすい、列出力に興味がある、名前を付けて保存演算子を使用して、列名とタイプを指定します。
名前を付けて保存演算子を行った後、これは良好なプロセス最終的な出力データ・サンプルです。
構造化された出力2.3を参照してください。
さらにオペレータDバスのエンジンを実行した後にルールのセット、ログデータを保存するように構成され、それが適切な構造化データを生成することができます。現在の実際のプロジェクトデータによると、あなたがUMSを使用しない場合、あなたは単純な開発、実装、カスタマイズを渡すことができ、出力のDBus UMS形式です。
注：UMS Dバスは、共通データ交換フォーマット標準JSON、定義され使用されます。これは、データとスキーマの両方が含まれています。より多くのUMS Dバスのオープンソースプロジェクトホームページの紹介を紹介して参照してください。オープンソース・アドレスします。https：//github.com/bridata/dbus
以下は、テストケース、UMSデータ出力例の構造です。
2.4ログ監視
抽出マスタデータ、ルールのマッチング、モニタリング、早期警戒状況を容易にするために、我々はいつでもあなたは次のことを知って、図に示すように、視覚的なリアルタイム監視インタフェースを抽出するログデータを提供します。
- リアルタイムデータの数
- 記事番号のエラー状況（エラーの数が意味：エラーの実行回数の深夜イベントを、いくつかのデータを失うことがないように、オペレータが作業を変更するためのデータと一致するかどうかを発見する手助けするために、Dバスはまた、ログ機能のリードバックを提供）
- データ遅延状況
- 正常終了をログ抽出
それぞれ、データ、統計および早期警告を監視するために、IP（またはドメイン名）をホストするために、クラスタ内の各ホストからの監視情報に含まれる情報を監視します。
テーブルには、監視はすべてが一致するデータの数にはバーを_unkown_table_ないことを示していると呼ばれるもあります。たとえば：Logstashデータは、イベントの我々だけで3種類のキャプチャ5さまざまなイベントを、持っているログログの取得、試合には他のデータは_unkown_table_数ですべてではないがあります。
Dバスはまた、水路、Filebeat、UMSおよび他のデータ・ソースにアクセスするだけの小さな構成を必要とすることができ、説明Dバスプロセスのログの複数を指し、同一のデータソースLogstash結果に同様の処理を実現することが可能です。
-
https://bridata.github.io/DBus/install-logstash-source.html
-
https://bridata.github.io/DBus/install-flume-source.html
-
https://bridata.github.io/DBus/install-filebeat-source.html
処置Dバス・アプリケーション・ログインした後、そのようなデータベースワームホールデータに落下などによる使用のために消費者に提供カフカ下りデータに構造化されたデータ出力、のためにコンバータの生データを記録。：どのようにDバスがワームホールと組み合わせて使用し、参照してくださいリアルタイムデータプラットフォーム（技術論文）を設計する方法。
著者：Zhongzhen林