データベースのチューニング:インデックスのカスタマイズ

Document created by RSA Information Design and Development on Apr 19, 2018
Version 1Show Document
  • View in full screen mode
 

このトピックでは、カスタム インデックス ファイルを使用してインデックスをカスタマイズする方法について説明します。各NetWitnessNetWitness NextGenサービスは、大半のユーザのニーズに対応するよう設計された、デフォルトのインデックス構成でインストールされます。ただし、カスタム メタを生成するカスタム コンテンツ使用する場合、新しいメタ キーにインデックスを作成することも可能です。

インデックス構成ファイルの場所

インデックスのカスタマイズは、カスタム インデックス ファイルに変更を加えることによって行われます。カスタム インデックス ファイルの場所は、 /etc/netwitness/ng/index-<servicename>-custom.xml です。ここで、 <servicename> は、カスタマイズするサービス名に対応します。たとえば、Concentratorのカスタム インデックス ファイルは/etc/netwitness/ng/index-concentrator-custom.xmlです。

Concentrator製品には、デフォルトのインデックス構成を記述したファイル /etc/netwitness/ng/index-concentrator.xml も含まれます。このファイルは、カスタム インデックス ファイルのフォーマットを示すためのテンプレートとして使用できます。

カスタム インデックス ファイルでは、デフォルトのインデックス構成をオーバーライドできます。

カスタム インデックス ファイルへの変更は、サービスの実行中に行うことができます。サービスでカスタム インデックスが保存されると、カスタム インデックス ファイルへの変更が読み取られ、インデックスに適用されます。

インデックスへの変更が反映されるのは、変更適用後に受信されたデータだけです。 インデックス再構築 を行わない限り、新しいカスタム インデックス構成で変更適用前のデータのインデックスを遡って行うことはできません。

インデックス構成エントリー

カスタム インデックス ファイルはXMLドキュメントです。このドキュメントのルート要素は、 language 要素で、その内部にはメタ キーごとに1つ、各カスタム インデックスについて記述する要素があります。カスタム インデックス構成の各要素は次のとおりです。

 <key name="did" description="Decoder Source" level="IndexValues" format="Text" valueMax="100" /> 

この要素に含まれる各属性の定義:属性 | 説明 -|- 名前 | インデックス付けされた記述となるメタ キーの名前 | メタ タイプ レベルのヒューマンリーダブルな説明 | このメタ キーに関して作成されるインデックスのタイプ | valueMax このキーに関してスライスに格納される一意の値の最大値 | このメタ キー名を持つすべてのメタ項目によって格納されるデータの形式。

この後のセクションでは、これらのパラメータについて詳しく検証します。

メタ名

インデックスによって使用されるメタ名は、メタ データベースの各メタ項目内に含まれているメタ キー名を参照します。これらのメタ名は、解析時にDecoderによって生成されます。Parserは、任意のメタ キー名でメタを生成するよう選択できます。したがって、カスタム インデックスを使用すると、Decoderによって生成されるどのメタ項目にインデックスを付けるかを選択できます。

メタ キー名の最大長は16文字であり、英字または'.'文字のみ指定できます。

データ タイプ

Decoderはメタ項目を生成するときに、データ タイプを割り当てます。各Parserは、メタ データ タイプを選択できます。ただし、デフォルトのメタ キーごとに推奨される標準のデータ タイプがあります。たとえば、ip.srcとip.dstはIPv4メタ タイプとして格納され、alias.hostはTextメタ タイプとして格納されます。各Parserで、Decoderによって生成される各メタ キーのデータ フォーマットと一致させる必要があります。

Concentratorにカスタム インデックスを追加する場合は、そのカスタム インデックスのデータ タイプがDecoderによって生成されるデータのフォーマットと一致していなければなりません。一致していない場合、Concentratorは、生成されたメタをカスタム インデックスに対して指定されたタイプに変換するよう試みます。ただし、これらの変換は失敗する場合があり、不明瞭な結果が生成される可能性があります。

同様に、多数のDecoderとConcentratorがNetWitness環境に存在する場合は、すべてのDecoderとConcentratorで各メタ キーのタイプを一致させる必要があります。NetWitnessNetWitness NextGenサービス間のメタ タイプの不一致は、未知の結果を招く原因となります。

次の表に、NetWitnessNetWitness NextGen サービスによってサポートされるメタデータのタイプを示します。

                                                                                           
タイプ サイズ(バイト単位) 説明
Int8 1 符号付き8ビット整数
UInt8 1 符号なし8ビット整数
Int16 2 符号付き16ビット整数
UInt16 2 符号なし16ビット整数
Int32 4 符号付き32ビット整数
UInt32 4 符号なし32ビット整数
Int64 8 符号付き64ビット整数
UInt64 8 符号なし64ビット整数
UInt128 16 符号なし128ビット整数
Float32 4 32ビット浮動小数点数、単精度
Float64 8 64ビット浮動小数点数、倍精度
TimeT 8 UNIXエポック タイムスタンプ
Binary 1~255 任意のバイナリ データ
Text 1~255 UTF-8エンコード テキスト データ
IPv4 4 IPv4アドレス バイト
IPv6 16 IPv6アドレス バイト
MAC 6 MACアドレス バイト

カスタム インデックスを定義するときは、メタに最も適したデータ タイプを使用することが重要です。たとえば、テキスト表現はIPv4表現よりも多くのバイトを消費するため、IPアドレスをテキストとして格納すべきではありません。

インデックス レベル

作成できるインデックスのレベル(またはタイプ)は、IndexNone、IndexKeys、IndexValuesの3つです。

IndexNone

このタイプでは、実際にはインデックスが作成されません。IndexNoneレベルを持つカスタム インデックス エントリーは、メタ キーを定義してしておくためだけに存在します。IndexNoneエントリーをDecoderのカスタム インデックスで使用すると、Decoder上のすべてのParserで特定のデータ タイプをメタ キーに適用できます。

IndexKeys

このタイプのカスタム インデックスは、このメタ キー名の付いたメタ項目を含んでいるセッションのみインデックスによって追跡されることを示し、メタ キーに対応するメタ データベース内の一意の値はインデックス付けされません。

キー レベル インデックスの管理では、必要なストレージ領域、メモリ、CPU負荷は大幅に少なくて済みますが、queryやvalues演算の実行に使用される場合は、クエリ エンジンの負荷が大幅に高くなります。

Where句で使用される場合、キー レベルでインデックス付けされたメタ キーは、existsや!existsなどの演算を解決するためにしか使用できません。

IndexValues

このタイプのカスタム インデックスには、メタ キーの個々の一意の値を含んでいるセッションに設定されます。このタイプのインデックスは「フル インデックス」とも呼ばれます。

このタイプのインデックスは、大半のWhere句を効率的に処理するためと、values呼び出しのfieldNameパラメータとしてこのメタ キーを使用するために必要となります。

Value Max

Value Maxは、Valueレベル インデックスの確度とパフォーマンスに大きな影響を与えるパラメータです。

Decoderは、パケットまたはログをパースするときに、任意の値を持つ任意のタイプのメタを作成できます。通常、これらのメタ項目は、パケットまたはログから直接コピーされたデータから作成されます。そのため、ほぼあらゆるイベントに応じて、誰でも一意のメタ値を作成できます。

インデックスのパフォーマンスは、各メタ キーについて検出される一意の値の数によって直接左右されます。検出される一意の値の数が増えるにつれ、新しいメタがインデックス付けされる速度が下がり、クエリの実行速度も遅くなります。一意のメタ値の作成には誰でも影響を与える可能性があるため、インデックスのパフォーマンスにも誰でも影響を与える可能性があります。

Value Maxパラメータは、インデックスを入力できる一意の値の数を制限します。そのため、悪意のあるユーザが大量の一意の値を投入してNetWitnessシステムの機能を麻痺させようとするのを防ぎます。

メタ キーの値が着信パケットまたはログの影響を直接受ける可能性がある場合は、それらのメタ キーに対してValue Maxを設定することが重要です。

Value Maxは、前回のインデックス保存処理の後で追加された値にのみ適用されます。

Value Maxの設定方法に関する制限はバージョンごとに異なり、また、NetWitnessNetWitness NextGenサービスの使用可能なRAM容量によっても異なります。バージョン10.3では、推奨されるValue Maxの上限値はどのメタ キーの場合も5,000,000です。カスタム インデックスが多数ある場合は、Value Maxの値を低くする必要が生じる可能性があります。

maxLength

max lengthパラメータは word メタ タイプで排他的に使用されます。これは、wordトークン メタを生成するLog Decoderサービスの /decoder/parsers/config/token.max.length の対応する設定に一致する必要があります。インデックスはmaxLengthを使用して、 msearch SDK機能にフィードされる検索語を正しく解釈します。

キーの名称変更

インデックス言語は、キーの名称変更という概念をサポートしています。この機能は、古いキー名を廃止して置き換える新しいキー名の下位互換性互換性を提供するために使用されます。名称変更は、 rename 要素をキーに追加することによって実行します。これには、親キーがrename要素でキーを名称変更することを示す効果があります。たとえば、以下のキー定義は、 port_src という新しいキーを定義し、キー名を tcp.srcport に変更します。

 <key name="port_src" description="Source Port" format="UInt16" level="IndexValues"> <rename name="tcp.srcport"/> </key> 

rename要素は、親キーを使用するデータベースを参照します。この場合、 port_src には、port_srcタイプのメタ アイテムとtcp.srcportタイプのメタ アイテムの両方が含まれます。したがって、新しいメタ アイテムをデータベースに追加し、 port_src を使用して照会することができます。このようなクエリは、tcp.srcportに以前保存された情報も返します。

rename要素は、以前定義されたキーを参照する単一の属性 name を受け入れます。

rename要素で参照されたキーのタイプは、親キーと同じでなければなりません。

rename要素で参照されたキーのインデックス レベルは、親キーと同じでなければなりません。

カスタム インデックス ファイルでキーが新定義され、新定義されたキーにrename要素が含まれている場合、以前定義したrename要素があれば新しいrename要素で置き換えます。

Previous Topic:クエリ
You are here
Table of Contents > インデックスのカスタマイズ

Attachments

    Outcomes