Splunk 5.0.2 『 Knowledge Manager Manual』 作成：2013 年 3 月 13 日 午前 8 時 5 分 Copyright (c) 2013 Splunk Inc. All Rights Reserved Table of Contents ナレッジ管理にようこそ 8 Splunk のナレッジとは？ PDF を作成 8 8 Splunk ナレッジを管理する 訳 9 ナレッジ管理の前提 条 件 9 ナレッジオブジェクトの編成と管理 10 Splunk ナレッジの管理 Splunk の代わりに設定ファイルを使用する ナレッジオブジェクトの監視と編成 ナレッジオブジェクトの共有と昇格 ナレッジオブジェクトの無 効 化または削除 10 11 11 12 14 ナレッジオブジェクトの命名規則の策定 共通の情報モデルの使用 例 - 保存 みサ ー チの命名規則の設定 15 15 16 共通の情報モデルの理解と使用 標準イベントフォ ー マットの正規化 標準フィ ー ルド イベントタイプタグの標準化 ホストタグの標準化 16 16 17 28 30 デ ー タの解 釈 ：フィ ー ルドとフィ ー ルドの抽出 30 フィ ー ルドについて 自動フィ ー ルド抽出の例 カスタムサ ー チフィ ー ルドの追加と管理 31 31 32 デフォルトフィ ー ルドの使用 32 デフォルトフィ ー ルドの使用 内 部フィ ー ルド その他のデフォルトフィ ー ルド デフォルトの日時フィ ー ルド 32 33 33 35 サ ー チ時フィ ー ルド抽出の 概 要 話式フィ ー ルド抽出を使った新規フィ ー ルドの作成 Splunk 管理を使ったフィ ー ルド抽出の追加と管理 props.conf および transforms.conf のフィ ー ルド抽出の設定 サ ー チコマンドを使ったフィ ー ルド抽出の作成 36 36 37 37 37 IFX による 話式のフィ ー ルド抽出 38 Splunk 管理での [フィ ー ルドの抽出 ] ペ ー ジの使用 Splunk 管理でのサ ー チ時フィ ー ルド抽出のレビュ ー 新しいフィ ー ルド抽出の追加 既 存のフィ ー ルド抽出の更新 フィ ー ルドの抽出 限の更新 フィ ー ルド抽出の削除 41 41 42 43 44 44 Splunk 管理での [フィ ー ルド 換 ] ペ ー ジの使用 フィ ー ルド抽出のフィ ー ルド 換を設定する理由 Splunk 管理でのサ ー チ時フィ ー ルド 換のレビュ ー と更新 新しいフィ ー ルド 換の作成 フィ ー ルド 換 限の更新 フィ ー ルド 換の削除 44 45 45 46 47 47 設定ファイルを使ったサ ー チ時フィ ー ルド抽出の作成と管理 48 正規表現とフィ ー ルド名の構文 48 props.conf の編集による基本的なサ ー チ時フィ ー ルド抽出の作 48 成 インライン (props.conf のみ ) サ ー チ時フィ ー ルド抽出の例 50 フィ ー ルド 換を使った高度なサ ー チ時フィ ー ルド抽出の作成 51 フィ ー ルド 換を使ったカスタムサ ー チ時フィ ー ルド抽出の例 55 特定のソ ー ス、ソ ー スタイプ、またはホストに する、サ ー チ時 58 自動フィ ー ルド抽出の無 効 化 複 数 値フィ ー ルドの設定 fields.conf を使った複 数 値フィ ー ルドの設定 例 58 58 59 計算 みフィ ー ルドの定義 59 props.conf の編集による計算 みフィ ー ルドの作成 59 すべての計算 みフィ ー ルドが相互に 独 立して判 断 されることを 60 示す例 ルックアップフィ ー ルドと計算 みフィ ー ルド 61 Splunk の正規表現について 用語と構文 正規表現の例 モジュ ー ル正規表現 61 61 62 63 デ ー タ分類：イベントタイプとトランザクション 63 イベントタイプについて イベントとイベントタイプ イベントタイプの分類 イベントタイプの 出 新たなイベントタイプの作成 イベントタイプタグ イベントタイプの設定ファイル 63 63 63 64 64 64 64 類似イベントの分類とグル ー プ化 サ ー チの新規イベントタイプとしての保存 重要なイベントタイプ定義の制限事項 punct による類似イベントの識別 typelearner を使った新規イベントタイプの 出 タグを使った類似イベントのグル ー プ化と 索 64 64 65 65 65 66 Splunk Web でのイベントタイプの定義と管理 重要なイベントタイプ定義の制限事項 サ ー チのイベントタイプとしての保存 イベントタイプの自動 索 /作成 Splunk 管理を使ったイベントタイプの追加と管理 66 66 66 66 68 event t ypes.conf を使ったイベントタイプの設定 重要なイベントタイプ定義の制限事項 設定 例 イベントタイプの無 効 化 69 69 69 70 70 イベントタイプテンプレ ー トの設定 イベントタイプテンプレ ー トの設定 例 71 71 71 トランザクションについて トランザクションサ ー チ トランザクションタイプの設定 トランザクションの代わりに stats を使用する場合 71 71 71 72 トランザクションのサ ー チ サ ー チオプション トランザクションおよびマクロサ ー チ トランザクションサ ー チの例 72 72 73 73 トランザクションの設定 transactiontypes.conf へのトランザクションタイプの設定 その他のトランザクション設定 属 性 73 74 75 デ ー タの 強 化：ルックアップとワ ー クフロ ー アクション 76 ルックアップとワ ー クフロ ー アクションについて テ ー ブルのルックアップ ワ ー クフロ ー アクション 76 76 76 フィ ー ルドルックアップを使ったイベントへの情報の追加 既 存のルックアップテ ー ブルの表示または新しいファイルの アップロ ー ド 既 存のルックアップ定義の編集または新たなファイルベ ー スの ルックアップまたは外部ルックアップの定義 既 存の自動ルックアップの編集または新たなルックアップの設 定 HTTP ステ ー タスルックアップの例 77 77 77 78 78 フィ ー ルドルックアップの設定 静 的ファイルに基づくフィ ー ルドルックアップの設定 サ ー チ結果を使ったルックアップテ ー ブルの設定 外部コマンドまたはスクリプトに基づくフィ ー ルドルックアッ プの設定 時間ベ ー スのフィ ー ルドルックアップの設定 ルックアップのトラブルシュ ー ティング - ルックアップスタン ザで同一の名前を使用 81 82 84 84 Splunk 管理を使ったワ ー クフロ ー アクションの作成と管理 Splunk 管理を使ったワ ー クフロ ー アクションの定義 特定のイベントグル ー プへのワ ー クフロ ー アクションのタ ー ゲット設定 フィ ー ルドおよびイベントメニュ ー へのワ ー クフロ ー アクショ ンの表示設定 GET ワ ー クフロ ー アクションの設定 POST ワ ー クフロ ー アクションの設定 イベントからのフィ ー ルド値を動的に記入する二次サ ー チの設 定 ワ ー クフロ ー アクションでの特別なパラメ ー タの使用 URL または HTTP フォ ー ムフィ ー ルド値のエスケ ー プ 処 理を防 止するための $! プリフィックスの使用 87 87 87 act ions.conf を使ったワ ー クフロ ー アクションの設定 93 デ ー タの正規化：タグとエイリアス 93 タグとエイリアスについて 93 Splunk Web でのフィ ー ルド値のタグとエイリアス設定 フィ ー ルド値のタグとエイリアスの設定方法 タグ設定した値のサ ー チ タグの無 効 化と削除 ソ ー スタイプ名の 更 94 94 95 95 95 タグの定義と管理 Splunk 管理の [タグ ] ペ ー ジの使用 タグの無 効 化と削除 95 96 98 フィ ー ルドのエイリアスの作成 ルックアップ用のフィ ー ルドエイリアスの追加例 98 99 ホストフィ ー ルドのタグ設定 Splunk Web を使ったホストフィ ー ルドへのタグの追加 ホスト名 vs. ホストフィ ー ルドのタグ設定 99 99 99 85 86 88 89 90 91 92 93 イベントタイプのタグ設定 Splunk 管理でのイベントタイプへのタグの追加 100 100 サ ー チとサ ー チジョブの保存、共有、管理 100 サ ー チの保存とサ ー チ結果の共有 サ ー チの手動保存 Splunk がサ ー チを自動保存する場合 サ ー チ結果の保存： サ ー チ結果の共有 保存 みサ ー チのナビゲ ー ションの管理 Answers 100 100 104 105 105 106 106 保存 みサ ー チの管理 106 スケジュ ー ル みサ ー チの優先度の設定 106 サ ー チスケジュ ー ラによる同時サ ー チの 処 理方法 107 リアルタイムスケジュ ー リングと連 続 スケジュ ー リングの例 107 リアルタイムスケジュ ー ルオプションの設定 108 レポ ー ト高速化とサ ー チサ ー チスケジュ ー ラ ー 108 サ ー チジョブとサ ー チジョブ管理について ユ ー ザ ー が 実 行できるジョブの制限 長期 実 行しているジョブの自動停止 108 108 109 ジョブ管理によるサ ー チジョブの管理 サ ー チジョブの 寿 命 ジョブ管理のコントロ ー ル 109 109 110 OS からのサ ー チジョブの管理 *nix でのジョブの管理 Windows でのジョブの管理 ファイルシステムを使ったジョブの管理 111 111 111 112 マクロサ ー チの設計 サ ー チマクロの設定と管理 112 112 フォ ー ムサ ー チの設計 112 保存 みサ ー チやレポ ー トへのナビゲ ー ションの定義 デフォルトコレクションの設定 保存 みサ ー チのネスト化したコレクションへの編成 保存 みサ ー チの動的なグル ー プ化 112 113 113 113 デ ー タサマリ ー を使ったサ ー チの高速化 114 レポ ー トの高速化とサマリ ー インデックスについて レポ ー トの高速化 サマリ ー インデックス 114 114 115 レポ ー ト高速化の管理 レポ ー ト高速化を有 効 にする レポ ー ト高速化に適したサ ー チ レポ ー ト高速化サマリ ー の理解 115 115 116 117 [レポ ー ト高速化サマリ ー ] ペ ー ジの使用 サマリ ー 詳細のレビュ ー サマリ ー インデックスを使ったレポ ー ト 効 率の向上 サマリ ー インデックスの使用事例 サマリ ー インデックス用レポ ー トコマンドの使用 Splunk Web でのサマリ ー インデックスサ ー チの設定 サマリ ー インデックスの仕組み タイムスタンプを持たないデ ー タのサマリ ー インデックス 「 si」で始まるサマリ ー インデックスコマンドで追加された フィ ー ルド 119 119 122 122 123 124 126 126 126 サマリ ー インデックスのギャップとオ ー バ ー ラップの管理 126 バックフィルスクリプトを使った他のデ ー タの追加 /ギャップ 127 の埋め し サマリ ー インデックスの設定 129 保存 みスケジュ ー ルサ ー チのサマリ ー インデックスのカスタ 129 マイズ サマリ ー インデックスに役立つサ ー チコマンド 130 サマリ ー インデックスにデ ー タを追加するサ ー チの手動設定 130 サマリ ー インデックスサ ー チ定義の 討事項 131 サマリ ー インデックス設定の例 132 サマリ ー インデックスの影響を受けるその他の設定ファイル 132 ナレッジ管理にようこそ Splunk のナレッジとは？ Splunk は、お客 の IT データの詳細や大規模なパターンを判別するために役立つ、強力なサーチ/分析エンジンで す。Splunk を使用する場合、単にログファイル内の個別のエントリを参照するのではありません。それらのデー タが保有している情報を総合的に活用して、IT 環境を総合的かつ詳細に把握することができます。 Splunk はお客 の IT データ (イベント、フィールド、タイムスタンプなど) からさまざまな知識 (ナレッジ) を抽出 して、より理解、把握しやすく、有益な情報を導き出せます。このような情報の一部は、Splunk が IT データのイ ンデックスを作成する時 (インデックス時) に抽出されます。しかし、この情報の大半は「サーチ時」に Splunk と ユーザーの両方により作成されます。あらかじめ抽出する情報を決めるまたは分析しておく、データベースまたは スキーマベースの分析ツールと違い、Splunk では raw データから必要に じて動的にナレッジを抽出することがで きます。 Splunk を使用するにつれて、イベントタイプ、タグ、ルックアップ、フィールド抽出、ワークフローアクショ ン、保存 みサーチなどの、さまざまな Splunk ナレッジオブジェクトが作成されていきます。 Splunk のナレッジは、IT データのさまざまな側面を発見/分析するための各種ツールと考えることができます。た とえば、イベントタイプにより類似のイベントを手 に分類、グループ化して、それを使って 密に定義されたイベ ントのサブグループに して分析的サーチを実施できます。 『ナレッジ管理』マニュアルでは、Splunk Web、Splunk 管理、および設定ファイルを使った一連のナレッジオブ ジェクトの管理方法、およびナレッジを使った現実世界の問題の解決方法について 明していきます。 Splunk ナレッジは、5 つのカテゴリに分類できます。 データの解釈：フィールドおよびフィールドの抽出 - フィールドとフィールドの抽出は、Splunk でもっとも 使用されるナレッジです。IT データから Splunk が自動的に抽出するフィールドは、raw データに意味をも たらし、一目見ただけでは把握できないデータをどのように扱えば良いかを明らかにします。自分で手動抽 出したフィールドを活用すれば、情報の価値と意味をさらに 張、強化できます。 データ分類：イベントタイプとトランザクション - イベントタイプとトランザクションを使って、関連する 複数の類似イベントをグループ化できます。イベントタイプはサーチで 出された一連のイベントをグループ 化します。一方トランザクションは、一定期間内に発生した概念的に関連しているイベントの集合体です。 データの強化：ルックアップとワークフローアクション - ルックアップとワークフローアクションは、デー タの有用性をさまざまな方法で 張する、ナレッジオブジェクトのカテゴリです。フィールドルックアップに より、静的なテーブル (CSV ファイル) や Python ベースのコマンドなどの、外部データソースからフィール ドを追加することができます。ワークフローアクションにより、データ内のフィールドと他のアプリケー ションや Web リソース間の 話操作を行えます (例：IP アドレスを含むフィールドの WHOIS ルックアッ プ)。 データの正規化：タグとエイリアス - タグとエイリアスは、一連のフィールド情報を管理、標準化するため に使用されます。タグとエイリアスを使って一連の関連するフィールド値をグループ化したり、抽出した フィールドにその特性を表すタグを指定したりすることができます。たとえば、特定の場所 (例：建物や市 など) にある一連のホストからのイベントをグループ化するには、単純に各ホストに同じタグを設定しま す。また、異なるフィールド名を使用する 2 つの異なるソースに同じデータを参照させるには、エイリアス を使ってデータを標準化します (例：clientip にエイリアス ipaddress を設定)。 保存 みサーチ - 保存 みサーチも、Splunk ナレッジのカテゴリに分類できます。社内の各 Splunk ユーザー により大量の保存 みサーチが作成されることもありますが、有益で洞察力のある保存 みサーチは他のユー ザーにとっても役立ちます。また、保存 みサーチの高度な使用方法もあります。ダッシュボード内で再利用 可能なサーチマクロとして活用したり、さまざまな場面に 用できます。 ナレッジ管理マニュアルには、サマリーインデックスに関する章も用意されています。サマリーインデックスの設 定と監視は、ナレッジ管理ロールのユーザーにとって特に役立ちます。 この時点で、「なぜナレッジを管理する必要があるの？」という疑問が湧く方もいるでしょう。その答えについて は、この章の次のトピック「Splunk ナレッジを管理する訳」を参照してください。 ナレッジ管理者は、最低でもデータ取り込み設定、イベントの処理、およびインデックス作成の概念に関する基本 的な知識を理解しておく必要があります。詳細は、この章の 3 番目のトピック「ナレッジ管理の前提条件」を参照 してください。 PDF を 作 成 このマニュアルの PDF 版が欲しい場合は、このページの目次の左下にある赤い [Download the Knowledge Manager Manual as PDF] リンクをクリックしてください。PDF 版のマニュアルがその場で作成されます。作成 8 された PDF は後で利用するために保存、印刷することができます。 Splunk ナレッジを管理する 訳 Splunk デプロイ環境内で、かなり大量のナレッジオブジェクトを保有する必要がある場合、そのナレッジの管理 が重要になります。このことは、特に多数の Splunk ユーザーが存在している組織、そして多数のチームが Splunk で作業を行っている場合に当てはまります。ユーザー数が 加すると、Splunk ナレッジも 加していきます。 このような状況を放置すると、ユーザーが大量のオブジェクトを誤った方法で調査したり、名前の競合が発生した り、不適切に App/ 限が割り当てられたオブジェクトの使用に 苦 したりする可能性があります。さらには、シス テム内のどこかにすでに存在しているのに、保存 みサーチやフィールド抽出などの、類似のオブジェクトの作成 に貴重な時間を費やしてしまう可能性があります。 Splunk 管理者は、このようなナレッジを集中管理します。ナレッジを管理することには以下のような利点があり ます。 チーム、部門、およびデプロイ環境全体の、ナレッジオブジェクト作成と使用を管理、監督する。大規模な Splunk デプロイ環境で多数のチームが作業を行っている場合、時間の 過に伴い各チームがすでの他のチー ムが作成したオブジェクトと同じようなオブジェクトを再び独自に開発するような、「再作成の輪」ができ ていることに気が付くことでしょう。ナレッジ管理者は、オブジェクトの作成をモニターして、役に立つ 「汎用目的」オブジェクトをデプロイ環境の一部または全体で共有することにより、このような無駄を最低 限に抑えることができます。 詳細は、このマニュアルの「Splunk ナレッジの管理」を参照してください。 イベントデータの標準化。単純に言うと、時間の 過とともにナレッジオブジェクトは 加していきます。 Splunk はデータインデックスをベースにしておりデータベースではありませんが、標準化の基本原則はその まま適用されます。どんなに堅牢でよく使われている Splunk 環境でも、同じフィールドに多数のタグが付 けられると、分かりにくいオブジェクトになってしまい、ユーザーに混乱と非効率をもたらす可能性があり ます。このマニュアルでは、ナレッジオブジェクトライブラリに、一定の命名規則を導入し、Splunk の共通 情報モデルを採用することによる標準化のコツを 明しています。 詳細は、「ナレッジオブジェクトの命名規則の策定」を参照してください。 設定ファイルを使ってナレッジオブジェクトを管理する。ナレッジ管理の達人は、Splunk ナレッジを管理す るために、Splunk の設定ファイルを活用しています。ナレッジオブジェクトの設定に、設定ファイルを利用 する方が効率的なさまざまな事例が存在しています。このマニュアルでは、このような方法でのナレッジの 利用について取り上げています。 設定ファイルを使ったナレッジの管理方法については、このマニュアルの「サーチ時フィールド抽出の作 成」を参照してください。 保存 みサーチとレポート、およびビューとダッシュボードの App レベルのナビゲーションの設定と管 理。保存 みサーチ、レポート、ビュー、ダッシュボードを何も管理せずに放置すると、それらのオブジェク トが Splunk の App に追加されていくにつれて大きな混乱が生じる可能性があります。Splunk App の開発者 ではなくても、ユーザーが各自の作業を円滑に行うために必要なサーチ、レポート、ビュー、およびダッ シュボードを素早く探し出して利用できるようにすることは可能です。 詳細は、このマニュアルの「保存 みサーチとレポートへのナビゲーションの定義」を参照してください。 サマリーインデックスの設定と使用のレビュー。デプロイ環境内で多数のチームがサマリーインデックスを 使用して、大量のデータに して効率的なサーチを実行できます。ただし、それらの使用量は総合的なライセ ンスボリュームに してもカウントされます。ナレッジ管理により、社内のサマリーインデックスの使用を集 中管理して、正しく作成、利用して、必要に じて他のユーザーと共有することができます。 注意：リリース 4.1 の場合、サマリーインデックスの使用量は、総合的なライセンスボリュームに してカウ ントされません。 詳細は、このマニュアルの「レポートの効率を向上するサマリーインデックスの使用」を参照してくださ い。 ナレッジ管理の前提 条 件 ナレッジ管理作業の大半は、「サーチ時」のイベント操作に関連しています。一般的なナレッジ管理者は、データ 入力の設定、イベント処理アクティビティの調整、デフォルトのフィールド抽出の問題の修正、インデックスの作 成と管理、転送と受信の設定などの、イベントのインデックス作成前に行われる作業には注意を払いません。 ただし、ナレッジ管理者はこのような「Splunk 管理者」の概念を理解しておくことをお勧めします。このような 9 知識をしっかりと理解しておくことで、適切な方法でナレッジ管理を行えるだけでなく、何らかの問題が発生した ような場合にも的確に 処することができます。 ここでは、ナレッジ管理者の方に必要な「管理者」としての知識を得るために役立つ、いくつかのトピックを紹介 します。 Splunk App の利用：デプロイ環境で複数の Splunk App を使用している場合、それらの編成方法や App の 管理方法を理解しておく必要があります。『管理マニュアル』の「App とは」、「App のアーキテクチャと オブジェクトの所有 」、および「App の管理」を参照してください。 設定ファイルの管理：Splunk の設定ファイルはどこにあるのでしょう？どのように編成されているの？各設 定ファイルの優先順位は？このような疑問については、『管理マニュアル』の「設定ファイルについて」と 「設定ファイルの優先度」を参照してください。 Splunk のインデックス作成：インデックスとは何でどのように機能するのでしょうか？「インデックス 時」と「サーチ時」の違い、そしてなぜこのように区別されているのでしょうか？『インデクサーとクラス タの管理』の「インデックスとインデクサーについて」およびそれ以降の章を参照してください。特にイン デックス時とサーチ時の違いについてはしっかりと理解してください。 Splunk へのイベントデータの取り込み：Splunk のデータ取り込みに関する基本的な概念を理解しておく必 要があります。『Getting Data In』マニュアルの「What Splunk can index」および他のトピックを参照して ください。 転送と受信の設定の理解：フォワーダーとレシーバーを利用している場合、それらがどのように導入されて いるのかを理解しておくと、ナレッジの管理方針の策定に役立ちます。『Distributed Deployment』マニュア ルの「About forwarding and receiving」を参照してください。 イベント処理の理解：Splunk がデータのインデックスを作成する前の「解析」方法を理解しておくことをお 勧めします。このような知識は、イベントデータに関する問題や「インデックス時」のイベント処理に関す る問題をトラブルシューティングするために役立ちます。『Getting Data In』マニュアルの「Overview of event processing」およびその他の関連記事を参照してください。 デフォルトのフィールド抽出：フィールド抽出の大部分はサーチ時に行われますが、特定のデフォルト フィールドはインデックス時に抽出されます。ナレッジ管理者は、主にサーチ時のフィールド抽出に注目し ますが、デフォルトのフィールド抽出の管理方法も理解しておくと便利です。また、Splunk が各イベントに して適用する、host、source、および sourcetype フィールドの問題に関するトラブルシューティングにも 役立ちます。『Getting Data In』マニュアルの「About default fields」を参照してください。 ユーザーとロールの管理：一般的なナレッジ管理者は、ユーザーとロールの設定に直接関与することはあり ません。ただし、デプロイ環境内でどのように設定されているのかを理解しておくと、各ユーザーグループ 間でのナレッジの共有と利用の促進に役立ちます。詳細は、『管理マニュアル』の「ユーザーとロールにつ いて」および他の関連する記事を参照してください。 ナレッジオブジェクトの編成と管理 Splunk ナレッジの管理 社内で Splunk が使われるに従って、イベントデータの基本セットにナレッジが追加されていきます。また、サー チが保存、スケジュール設定されます。フィールドにタグが追加されます。一連のイベントをグループ化した、イ ベントタイプやトランザクションが定義されます。ルックアップやワークフローが開発されます。 ナレッジオブジェクトの作成プロセスは当初は徐々に進んでいきますが、時間の 過とともに複 になっていく可能 性があります。ユーザーが「再作成の輪」に陥って、すでに存在しているサーチを作成したり、冗長なイベントタ イプを開発したりするなどの無駄や混乱は容易に発生する可能性があります。ユーザー数が少ない場合はこれもさ ほど問題にはならないかもしれませんが、時間の 過とともにナレッジが蓄積されていくと、無用な混乱や反復作 業が発生する可能性があります。 ここでは、Splunk 管理を使ったナレッジオブジェクトの管理方法について 明していきます。Splunk 管理を利用 すれば、どのようなナレッジオブジェクトが現在作成されているか、作成者は誰か、そして (ある程度ですが) ど のように使用されているのかを手 に把握することができます。 Splunk 管理では以下の作業を行えます。 必要に じて最初から、またはオブジェクトを複製して、新たなナレッジオブジェクトを作成する。 作成されたナレッジオブジェクトをレビューして、無駄が発生していないか、命名規則に従っているかなど を確認し、また「不良な」オブジェクトが他に 影響を及ぼす前に取り除く。 ナレッジオブジェクトが特定の作業チームだけでなく、他のチーム、ロール、ユーザーなどにも利用させら れるかどうかを確認する。 10 「下流」への依存関係が小さく、他に影響を与えないナレッジオブジェクトを削除する。 注意：このトピックでは、ナレッジ管理者が Admin ロールまたは同等の 限を持つロールを保有していることを前 提にしています。 Splunk の代わりに設定ファイルを使用する 前のリリースの Splunk では、ユーザーは Splunk 設定ファイルを直接編集して、ナレッジオブジェクトを追加、 更新、または削除していました。現在は、使いやすいインターフェイスである Splunk 管理を使って、設定ファイ ルと同じように作業を行えます。 設定ファイルについても理解しておくことをお勧めします。理由を以下に示します。 設定ファイルレベルでの機能を理解しておけば、Splunk 管理で何を行っているのかをより詳細に把握できま す。特に [フィールドの抽出] および [フィールド 換] ページで作業を行う場合にこれが当てはまります。 特定のナレッジオブジェクトタイプに存在する機能の一部は、Splunk 管理の UI には表示されません。 古くなった、冗長な、または不適切なナレッジオブジェクトの一括削除は、設定ファイルを使ってのみ行え ます。 直接設定ファイルを編集する方が効率的なことがあります。たとえば、長期間 Splunk を使い続けており設 定ファイルを熟知しているユーザーの方なら、ナレッジオブジェクトの取り扱いにも慣れていることでしょ う。また、単に設定ファイルでできる細かな調整を行いたいユーザーも存在しています。 Splunk 設定ファイルは必要に じて自由に使用することができます。ナレッジ管理マニュアルには、設定ファイル を使った各種ナレッジオブジェクトタイプの取り扱い方法が記載されています。詳細は、タイプに じた各トピッ クを参照してください。 Splunk の設定ファイルに関する全般情報については、管理マニュアルの以下のトピックを参照してください。 設定ファイルについて 設定ファイルの優先度 現在の .spec および .example 設定ファイルの例については、『管理マニュアル』の「設定ファイルリファレン ス」を参照してください。 ナレッジオブジェクトの監視と編成 ナレッジ管理者は、Splunk 環境内のナレッジオブジェクトコレクションを定期的にチェックする必要がありま す。以下の事項に注意する必要があります。 命名規則違反 重複/無駄 他のユーザーと共有した方が良いかどうか 古くなったまたは貧弱な設計のため無効化/削除するかどうか 定期的にナレッジオブジェクトをチェックすることで、異常を 出したり、それに起因する問題を事前に防止する ことができます。 例：タグの維持 一般的に Splunk 環境では、フィールド/値の集合体にサーチを実行するために用いられるタグが数多く作成されま す。ただし、時間の 過とともに似たような名前のタグを使っても、それぞれがまったく別個の結果を生み出すよ うになることも珍しくはありません。このような状況は非常に混乱を招き、また不 の原因にもなってしまいま す。 ここでは、タグを正常な状態に維持するための管理手順について 明していきます。この方法は、他のタイプのナ レッジオブジェクトにも 用できます。 1. [管理] > [タグ] > [タグ名別表示] に移動します。 2. 同じ App に所属している (またはすべてのユーザーが利用できるようになっている)、類似のまたは重複してい る名前を持つタグを探します。たとえば、同じ App 内に authentication と authentications のような類似のタグ があるけれども、片方のタグには別のタグとはまったく異なるフィールド/値のペアセットが設定されている場合 があります。 また、crash と Crash のように、大文字/小文字が違うだけで同名のタグが使われていることもあるでしょう。タグ では大文字と小文字が区別されるため、Splunk はこれらのタグを個別のナレッジオブジェクトと認識します。 [App コンテキスト] に「すべて」を設定している場合は、別な App に所属するタグが同名であってもそれは正常 であることに注意してください。一般的にはこのような状況は許容できるものです。たとえば、Windows App の authentication タグには、UNIX App の authentication タグとまったく異なるフィールド/値のペアが設定されて 11 タグには、UNIX App の いることも珍しくはありません。 タグとまったく異なるフィールド/値のペアが設定されて 3. 適切な 限がある場合は、見つかった重複するタグや古くなったタグを、無効にするかまたは削除してくださ い。ただし、オブジェクトに依存関係があって、それによって影響を受けるオブジェクトがある可能性があること に注意してください。タグが保存 みサーチ、ダッシュボードサーチ、他のイベントタイプ、またはトランザク ション内で使用されている場合、タグを削除するとそれらのオブジェクトが機能しなくなってしまいます。また、 ある App コンテキストに所属しているオブジェクトを他の App コンテキストに移動する場合にも、問題が発生す る可能性があります。 詳細は、「ナレッジオブジェクトの無効化または削除」を参照してください。 4. 新しい独自の名前を持った代わりのタグを作成する場合は、置換するタグと同じフィールド/値のペアが設定さ れていることを確認してください。 オブジェクト命名上の問題を防止する命名規則の使用 Splunk 導入の初期段階にナレッジオブジェクトの命名規則を制定すれば、オブジェクトの命名に関する問題を防 止することができます。詳細は、「ナレッジオブジェクトの命名規則の策定」を参照してください。 ナレッジオブジェクトの共有と昇格 ナレッジ管理者は、ナレッジオブジェクト 限を設定して、Splunk 環境内のさまざまなナレッジオブジェクトへの アクセスを制限/ 張することができます。 場合によっては、特定のナレッジオブジェクトを特定のロール、特定の App 内でのみ使用させるようにします。 また逆に、特定の人のみが利用していたナレッジオブジェクトを、すべてのユーザーがすべての App で利用でき るようにすることもあります。ナレッジ管理のあらゆる側面に当てはまりますが、これらのアクセス制限/ 張が暗 的に意味することを入念に 討する必要があります。 Splunk ユーザーが保存 みサーチ、イベントタイプ、トランザクション、または他のナレッジオブジェクトを作成 した場合、当初はそのユーザーのみがそれを利用できます。そのオブジェクトを他のユーザーも利用できるように するには、次のような方法があります (適切な 限がある場合)。以下の作業を行えます。 ナレッジオブジェクトをグローバルにすべての App のユーザーが利用できるようにする (オブジェクトを 「昇格」する)。 ナレッジオブジェクトをすべての App のすべてのユーザーに利用できるようにする。 ユーザーまたはロール単位に、オブジェクトをグローバルまたは App 固有のものに制限 (または 張) する。 ロールに して App レベルで読み取り/書き込み 限を設定し、ユーザーに自己が所有していないオブジェクト を共有または削除する。 限がナレッジオブジェクトの使用に与える影響 これらの選 肢がナレッジオブジェクトの使用に与える影響を理解するために、架空の Network Security (ネット ワークセキュリティ) App のユーザーである Bob を考えてみましょう。彼は、「Firewall Manager」ロールを保有 しており、ファイアウォール関係のイベントを探す新しいイベントタイプ firewallbreach を作成しました。ここ で、発生する 限関連の問題と、その 処方法と結果を以下に示します。 問題 処 結果 Bob が firewallbreach を 作成した時点では、彼のみ がそれを利用できます。そ の他のユーザーは参照する ことも使用することもでき ません。そこで Bob は、 Network Security App を使 用する他の同僚とこれを共 有することにしました。 Bob は firewallbreach イベン トタイプの 限を更新して、その ロールに関係なく Network Security App のすべてのユー ザーが利用できるようにしまし た。また、新たなイベントタイ プを設定し、Network Security のすべてのユーザーがその定義 内容を編集できるようにしまし た。 Network Security App コンテキストで Splunk を 使用する任意のユーザーが、firewallbreach イ ベントタイプを表示、利用、編集することができ ます。同じ Splunk 環境内の他の App のユーザー は、そのイベントタイプの存在を知りません。 その後ナレッジ管理者の Mary が、Firewall Manager ロールのユー ザーのみが firewallbreach イベント タイプを編集または更新で きるようにする必要がある ことに気が付きました。 そこで Mary は、イベントタイ プの編集を Firewall Manager ロールのユーザーのみに制限す るようにしました。 Network Security App のユーザーは firewallbreach イベントタイプをトランザク ション、サーチ、ダッシュボードなどで利用する ことはできますが、ナレッジオブジェクトを編集 できるのは、Firewall Manager ロールを持つユー ザーと管理者レベルの 限を持つユーザー (ナレッ ジ管理者など) だけになります。他の App コンテ キスト内で Splunk を使用しているユーザーは、 まだこのイベントタイプの存在を知りません。 12 その後しばらくして、 Network Security App 内 で、便利な firewallbreach イベント タイプを使い慣れてきた一 部のユーザーが、これを Windows App コンテキス ト内でも利用したいと考え るようになりました。 そこでナレッジ管理者にその旨 を依頼した所、firewallbreach イベントタイプが昇格されてグ ローバルに利用できるようにな りました。 この Splunk 環境の全員が、App コンテキストに 関係なく firewallbreach イベントタイプを使用 できるようになりました。ただし、イベントタイ プ定義の更新は、管理者レベルのユーザーと Firewall Manager ロールを持つユーザーに制限さ れています。 注意：Splunk 環境で、管理者レベルのロールを持つユーザーのみが、ナレッジオブジェクトを共有、昇格させる ことができるように設定できます。これにより、あなた (および同僚のナレッジ管理者) は、新しいナレッジオブ ジェクトの共有を承認できる 限を持つことになります。 限 - はじめに ナレッジオブジェクトの 限を 更するには、以下の手順に従ってください。 1.Splunk 管理で、 限を更新するナレッジオブジェクトタイプのページに移動します (例：[サーチとレポート] や [イベントタイプ] など)。 2. 作成したナレッジオブジェクトを探して (必要に じてページ上部のフィールドのフィルタリング機能を使用)、 それの [ 限] リンクをクリックします。 3. 当該ナレッジオブジェクトの [ 限] ページで、オブジェクトの 限の 更方法に じて、以下のサブセクションで 明 している作業を行います。 す べ て の App の ユ ー ザ ー に し て オ ブ ジ ェ ク ト を 利 用 で き る よ う に す る オブジェクトを Splunk 環境内のすべての App のユーザーにグローバルに利用させるには： 1. ナレッジオブジェクトの [ 限] ページに移動します (上記の 明を参照)。 2. [(ナレッジオブジェクトタイプ) の表示先：] から、[すべての App] を選 します。 3. [ 限] セクションの [全員] で、[読み取り] または [書き込み] 限を選 します。 [読み取り] を選 した場合、ユーザーはオブジェクトを表示、使用することができますが、その定義を更新す ることはできません。たとえば、ユーザーが特定の保存 みサーチに して読み取り 限のみを保有している場 合、トップレベルのナビゲーション (例：[サーチとレポート] ドロップダウン) にそれが表示され、それを実 行することができます。たただし、サーチ文字列の更新、時間範 の 更、および 更内容の保存などの作業を 行うことはできません。 [書き込み] 限の場合、ユーザーはオブジェクトの表示、使用、および必要に じてその定義情報を 更すること ができます。 [読み取り] または [書き込み] のどちらも選 されていない場合、ユーザーはナレッジオブジェクトを参照する ことも使用することもできません。 4. 限の 更を保存します。 特 定 の App の ユ ー ザ ー に オ ブ ジ ェ ク ト を 利 用 さ せ る ナレッジオブジェクトの使用を特定の App に制限するには、まずその App のコンテキストに移動する必要があり ます。このためには、画面右上の [App] ドロップダウンリストから、ナレッジオブジェクトを利用させる App を 選 します。 ナレッジオブジェクトがプライベート、またはグローバルに共有されている場合は、単純にそのオブジェク トの [ 限] ページに移動して、[(ナレッジオブジェクトタイプ) の表示先] から [この App] を選 します。次 に、[全員] に して [読み取り] または [書き込み] 限を選 します。 ナレッジオブジェクトがすでに特定の App に制限されており、そのコンテキストを別の App に 更する場 合は、[移動] リンク (移動するために十分な 限がある場合にのみ表示されます) をクリックします。これによ り、素早く手 にナレッジオブジェクトを使用させる他の App を選 することができます。 ただし、ナレッジオブジェクトの App コンテキストを切り替えると、それに関連付けられている下流のオブ ジェクトに影響する可能性があることに注意してください。詳細は、「ナレッジオブジェクトの無効化また は削除」を参照してください。 ロールによるナレッジオブジェクトアクセスの制限 この方法を使って、各種ナレッジオブジェクトの 更を特定のロールに限定することができます。特定のロールが 13 ナレッジオブジェクトを使用できるけれどもそれを更新できないように設定することができます。また、あるロー ルを持つユーザーにオブジェクトを表示しないように設定することもできます。後者の場合、そのようなユーザー には Splunk 管理にオブジェクトは表示されず、それに してサーチを実行しても結果は表示されません。 ロール別にナレッジオブジェクトの表示、更新を制限するには、オブジェクトの [ 限] ページに移動してくださ い。ロールのメンバーを以下のように設定したい場合： オブジェクトを使用し、その定義を更新できるようにする場合、そのロールに読み取りおよび書き込みアク セスを割り当てます。 オブジェクトを使用できるけれども、更新できないようにする場合は、そのロールに読み取りアクセスのみ を割り当てます ([全員] ロールの [書き込み] の選 が解除されていることを確認してください)。 ナレッジオブジェクトを表示せず、使用できないようにする場合は、そのロールの [読み取り] と [書き込み] の選 を解除します (また、[全員] ロールでもこれらの 限の選 を解除してください)。 Splunk のロールベースの 限の詳細は、『セキュリティマニュアル』の「ロールベースのユーザーアクセスについ て」を参照してください。 Power と Admin 以 外 の ロ ー ル の 限 の 設 定 と オ ブ ジ ェ ク ト の 共 有 を 有 効 に す る Splunk をそのままの状態で使用している場合、ナレッジオブジェクトに 限を設定できるロールは Power と Admin のみです。他のロールにナレッジオブジェクトに する 限の設定を行わせる場合は、[管理] > [App] に移動 して、特定の App の [ 限] をクリックして、[ 限] ページに移動します。このページでは、その App に含まれるナ レッジオブジェクトに読み取り/書き込みアクセスができるロールを設定することができます。ロールに、サー チ、アラート、およびダッシュボードの共有を含めて、完全なナレッジオブジェクト 限の設定能力を与えるに は、Splunk Web での作成時にロールに 書き込みアクセス を割り当てます。 ナレッジオブジェクトを共有するための 限の設定は、App レベルで制御されています。サーチのスケジュールや デフォルトの入力設定の 更などのロール 限とは接続されていません。 App 内でのナレッジオブジェクトに する 限の設定をロールに許可する方法の詳細は、『Developing Dashboards, Forms, and Views for Splunk Web』マニュアルの「Step 5: Set Permissions」を参照してください。 共有されていないオブジェクトを持つユーザーとロールの削除に関する注意事項 Splunk ユーザーが所属しているチームから離脱して、そのユーザーまたはロールを Splunk から削除する必要があ る場合は、ユーザーまたはロールに所属している、ステータスが「プライベート」のナレッジオブジェクトが失わ れないように注意する必要があります。これらのナレッジオブジェクトを保持したい場合は、ユーザーまたはロー ルを削除する前に、App またはグローバルレベルでそれを共有してください。 ナレッジオブジェクトの無 効 化または削除 ナレッジオブジェクトを無効化または削除する場合の、簡単な例を考えてみましょう (十分な 限がある場 合)。Splunk 管理でナレッジオブジェクトを削除できるかどうかは、一連の要素によって決まります。 Splunk 管理で、Splunk に最初から用意されている (または App で提供されている) デフォルトのナレッジ 14 オブジェクトを削除することはできません。ナレッジオブジェクト定義が App のデフォルトディレクトリに 存在している場合、Splunk 管理を使ってそれを削除することはできません。[無効] をクリックして無効化す ることしかできません。App の「local」ディレクトリに存在するオブジェクトのみを削除できます。 あなたが作成し、共有されていないオブジェクトは削除することができます。自分が作成したナレッジオブ ジェクトが共有されると、その App の書き込み 限がない限りそれを削除することはできなくなります (後 述)。 他のすべてのナレッジオブジェクトを削除するには、それが所属する App の書き込み 限が必要です。この ことは、グローバルに共有されているオブジェクトや、App 内でのみ共有されているオブジェクトにも適用 されます。特定の App に所属するすべてのナレッジオブジェクトは、その共有方法に関係なく書き込み 限 がないと削除できません。 一般的に App レベルの書き込み 限は、管理者レベルのユーザーにのみ与えられます。 ここまでをまとめると、ナレッジオブジェクトを編集できても、削除できない場合があります。特定のナレッジオ ブジェクトを削除できないような場合でも、無効にすることは可能です。無効にすると、システムから削除されな いことを除いては、ナレッジオブジェクトを削除したのとほぼ同じ効果を発揮します。 下流と依存関係があるナレッジオブジェクトの削除 影響を与える可能性があるため、下流のオブジェクトと依存関係のあるナレッジオブジェクトの削除には注意を 払う必要があります。 たとえば、ある一般的なタグと重複しているタグが存在している場合を考えてみましょう。表面上はその重複する タグを削除しても問題はないように思えます。しかし、とても良く利用されるイベントタイプがベースにしている サーチに、その重複しているタグが使われていることもあります。そのようなイベントタイプが、ダッシュボード パネルのベースサーチ、およびさまざまな他のダッシュボードパネルを実行するサーチが使用するサマリーイン デックスへのデータ追加サーチの、2 つの重要な保存 みサーチで使用されている場合はどうなるでしょうか。この ようなタグを削除すると、イベントタイプが無効になるため、それに関連して下流で使われている他の保存 み サーチなどにも影響してしまいます。 このような問題を回避するためにも、分かりにくい名前または不適切な定義のナレッジオブジェクトがデプロイ環 境に大きな影響を与える前に、早期段階で発見して取り除くことが重要になります。特定のナレッジオブジェクト の下流の依存関係を判別する唯一の手段は、それがどこで使用されているのかを地道に探し出すことです。ナレッ ジオブジェクトの下流の依存関係を手 に探し出す方法はありません。 ナレッジオブジェクトを本当に削除する必要がある場合に、その下流の依存関係を徹底的に調査して、 処できた かどうか自信がない場合は、まずそれを無効にして影響があるかどうかを確認してください。数日たっても問題が ないようなら、削除しても構いません。 設定ファイルでナレッジオブジェクトを削除 Splunk 管理を使用する場合、一度に 1 つのナレッジオブジェクトしか無効化/削除できません。大量のオブジェク トを無効にする場合は、設定ファイルのナレッジオブジェクトに関するスタンザを直接削除するのが効率的です。 システム内には、設定ファイルが何種類か存在する場合もあることに注意してください。たいていの場合 は、$SPLUNK_HOME/etc/system/local/ の設定ファイルを編集してサイト全体に するローカル 更を行うだけで十分 です。また、特定の App に してのみ 更を行う場合は、$SPLUNK_HOME/etc/apps/<App_name>/local/ の設定ファイ ルを編集します。 『管理マニュアル』の以下のトピックを読んで内容を理解しない限り、設定ファイルを編集しないでください。 設定ファイルについて 設定ファイルの優先度 ナレッジオブジェクトの命名規則の策定 ナレッジオブジェクトの命名規則を策定しておくことをお勧めします。社内の全ユーザーが策定した命名規則を遵 守すれば、それらの違いや目的を一目で把握でき、より使いやすくなることでしょう。 Splunk のあらゆる種類のナレッジオブジェクトに して命名規則を策定できます。命名規則はオブジェクトの編成 管理に役立つだけでなく、似たような用途を持つ保存 みサーチ、イベントタイプ、およびタグのグループを区別 するためにも役立ちます。また、オブジェクトを使用するチームや場所、利用している技術、使用目的などの、オ ブジェクトに関するさまざまな事項を判断するためにも役立ちます。 Splunk 環境に早めに命名規則を導入すれば、将来的な混乱を回避することができます。 共通の情報モデルの使用 Splunk の共通情報モデルは、フィールド名の抽出、イベントタイプのタグ付け、ホストのタグ付けを標準化する 15 手段を提供しています。以下のような事項が含まれます。 標準のカスタムフィールドのリスト イベントタイプタグ付けシステム 標準のホストタグのリスト 詳細は、このマニュアルの「共通の情報モデルの理解と使用」を参照してください。 例 - 保存 みサ ー チの命名規則の設定 あなたは会社のシステムエンジニアグループで働いています。また、Splunk 環境のナレッジ管理者として、保存 みサーチの命名規則を策定しようとしています。 いろいろと考慮した結果、以下のような命名規則を作成することに決定しました。 グループ：サーチを保存したユーザーが所属するグループ。 サーチタイプ：サーチのタイプ (アラート、レポート、サマリーインデックス設定) を示します。 プラットフォーム：サーチのプラットフォームを示します。 カテゴリ：プラットフォームの関連するエリアを表します。 時間間隔：サーチの実行間隔 (スケジュールサーチの場合は、サーチの実行時刻)。 明：サーチの 明と目的、可能な限り 1 2 つの単語に限定。サーチ名の一意性を保証します。 グループ サーチタイプ： プラットフォーム SEG NEG OPS NOC Alert Report Summary Windows iSeries Network カテゴリ 時間間隔 明 Disk <arbitrary> <arbitrary> Exchange SQL Event log CPU Jobs Subsystems Services Security この命名規則を使った保存 みサーチの例： SEG_Alert_Windows_Eventlog_15m_Failures SEG_Report_iSeries_Jobs_12hr_Failed_Batch NOC_Summary_Network_Security_24hr_Top_src_ip 共通の情報モデルの理解と使用 共通情報モデルは、ほとんどのログファイルが 3 つのコンポーネントに分類できるというアイディアをベースにし ています。 フィールド イベントタイプタグ ホストタグ 験豊富なナレッジ管理者は、これらの 3 つのコンポーネントに基づいてログファイルを Splunk で利用しやすいよ うに設定し、また適していないログを同 のスキーマを採用するように正規化できるでしょう。共通情報モデル は、Splunk が大半の IT データを処理する際に使用する標準フィールド、イベントタイプタグ、およびホストタグ を記述しています。 標準イベントフォ ー マットの正規化 イベントの生成およびシステムの書き込み時に使用を推 するフォーマットを以下に示します。 <timestamp> name="<name>" event_id=<event_id> <key>=<value> 任意の数のフィールドキー/値のペアを使用できます。例： 2008-11-06 22:29:04 name="Failed Login" event_id=sshd:failure src_ip=10.2.3.4 src_port=12355 dest_ip=192.168.1.35 dest_port=22 キー (key) は、「標準フィールド」に記載されているもので、名前 (name) とイベント ID (event_id) は必須です。 16 CISCO PIX ログのイベントが共通情報モデルのフォーマットに準 している場合、以下の PIX イベントは： Sep 2 15:14:11 10.235.224.193 local4:warn|warning fw07 %PIX-4-106023: Deny icmp src internet:213.208.19.33 dst eservices-test-ses-public:193.8.50.70 (type 8, code 0) by access-group "internet_access_in" 次のようになります： 2009-09-02 15:14:11 name="Deny icmp" event_id=106023 vendor=CISCO product=PIX log_level=4 dvc_ip=10.235.224.193 dv_host=fw07 syslog_facility=local4 syslog_priority=warn src_ip=213.208.19.33 dest_ip=193.8.50.70 src_network=internet dest_network=eservices-test-sespublic icmp_type=8 icmp_code=0 proto=icmp rule_number="internet_access_in" 標準フィ ー ルド ここには、カスタムのサーチ時フィールド抽出としてイベントデータから抽出できる標準フィールドを記載してい ます。 これらのフィールド抽出はサーチ時に行うことを強くお勧めします。これらのフィールドを、Splunk がインデッ クス時に抽出するデフォルトフィールドのセットに追加する必要はありません。 インデックス時/サーチ時の違いについては、『インデクサーとクラスタの管理』マニュアルの「インデックス時 とサーチ時」を参照してください。サーチ時のフィールド抽出の実行については、このマニュアルの「サーチ時 フィールド抽出の作成」を参照してください。 これらのフィールド抽出の一部は、可能な値を限定的に定義したフィールドセットであることに注意してくださ い。たとえば、たいていの場合 action フィールドは、2 つの値 success またはは failure のみを取ります。ただ し、大部分のフィールドは幅広い値を取ります。たとえば、affected_user_id は 6 桁のユーザー ID で、可能な値 が多数存在しています。6 桁のユーザー ID の可能な値には限界がありますが、そのすべてのリストを取得しよう とは思わないでしょう。 フィールドはイベントカテゴリにグループ化しています。一部のフィールドが複数のカテゴリに記載されている場 合もあります。これは、フィールドが所属しているイベントタイプの内容に じて、その値や意味が 化するためで す。たとえば、認証イベントの dest は、認証に関与するターゲットを表しています。しかし、マルウェア 出イベ ントの場合、通常 dest はマルウェアの影響を受けたまたは感染したターゲットを表します。 アカウント管理 フィールド名 データ タイプ dest_nt_domain 文字列 アカウント管理イベントの影響を受けたユーザーが存在するドメイン。 signature 文字列 実施されたアカウント管理 更の 明。 src_nt_domain 文字列 宛先の NT ソース。アカウント管理イベントの場合、これはイベントが生成 されたユーザーが存在するドメインになります。 明 可能 な 値： 認証 - アクセス保護 デー フィール タタ ド名 イプ 明 可能な 値： success, action 文字 リソースで実施されたアクション。 列 app 文字 イベントに関与したアプリケーション (ssh、splunk、win:local など)。 列 dest 認証に関与したターゲット。フィールド名が dest_host、dest_ip、または 文字 dest_nt_host の場合、CIM に準 させるためにエイリアス dest を設定することができ 列 ます。 failure 認証に関与したソース。エンドポイント保護認証の場合、src はクライアントです。 フィールド名が src_host、src_ip、または src_nt_host の場合、CIM に準 させるた めにエイリアス src を設定することができます。これは、エンドポイント保護を取り 17 文字 扱うすべてのイベントに して必要です (認証、 更分析、マルウェア、システムセン 列 ター、および更新)。 src 注意：これをイベント source または sourcetype フィールドと混同しないでくださ い。 src_user 文字 限エスカレーションイベントで、src_user はエスカレーションを開始したユーザー 列 を表しています。 user イベントに関与したまたはイベントを開始したユーザー名。認証 限エスカレーショ 文字 ンイベントの場合、これはエスカレーションのターゲットとなるユーザーを表しま 列 す。 更分析 - エンドポイント保護 フィールド名 デー タタ イプ 明 可能な値： action 文字 リソースで実施されたアクション。 列 data 文字 列 dest 更の影響を受けたホスト。フィールド名が dest_host、dest_ip、また 文字 は dest_nt_host の場合、CIM に準 させるためにエイリアス dest を設 列 定することができます。 msg 文字 イベントに関連するメッセージ。 列 object 文字 影響するオブジェクト名。 列 object_attrs MV 文字 オブジェクトで 更された属性 (ある場合)。 列。 更イベントに関連告げられたデータ。 directory, 文字 object_category 列 file, 更されたオブジェクトのクラスの汎用名。 registry, unknown object_id システムで利用されている、影響を受けた一意のオブジェクト ID (ある 文字 場合)。 列 (Windows では SID、UNIXでは UUID) object_path 文字 オブジェクトへのフルパス (ある場合)。 列 severity 文字 列 更の重大度 (ある場合)。 status 文字 列 更のステータス。 user 文字 列 更を実施したユーザーまたはエンティティ (UID または PID が可能) user_type 文字 列 更を実施したユーザータイプ。 更分析 - ネットワーク保護 フィールド名 データタイプ 明 action 文字列 察された 更のタイプ。 command 文字列 更を開始したコマンド。 dvc 文字列 直接 更の影響を受けたデバイス。 user 文字列 更を開始したユーザー。 18 可能な値： 共通のイベントフィールド フィールド名 データタ イプ 明 可能な値： category 文字列 イベントの一部として提供されている、デバイス固有の分類。 count 文字列 イベントの一部として提供されている、デバイス固有の分類。 desc 文字列 自由形式の、特定のイベントの 明。 dest_tos 整数 イベントの宛先 IP の ToS (サービスタイプ)。この表の tos も参照 してください。 dest_vlan 整数 イベントの宛先仮想 LAN。この表の vlan も参照してください。 dhcp_pool 文字列 DHCP サーバー上の指定された DHCP プール名。 duration int イベントの 続時間。 dvc_host 文字列 ログレコードを伝送または記 しているデバイスの、完全修飾ドメイ ン名。 dvc_ip 文字列 イベントを報告したデバイスの IPv4 または IPv6 アドレス。 dvc_location 文字列 デバイスの物理的な場所に関する、自由形式の 明。 dvc_mac 文字列 イベントを報告したデバイスの MAC (レイヤー 2) アドレス。 dvc_nt_domain 文字列 イベントを記 または伝送したデバイスの Windows NT ドメイン。 dvc_nt_host 文字列 イベントを記 または伝送したデバイスの Windows NT ホスト名。 dvc_time timestamp デバイスがイベントを記 した時刻。 end_time timestamp イベントの指定終了時刻。 event_id int イベントを識別するための一意の ID。これは、報告したデバイスに とって一意です。 first_time 日時 イベントの初回時刻。 flow_count 整数 特定のイベントが表すネットフロー数。 last_time 日時 イベントの最終時刻。 length int データグラム、イベント、メッセージ、またはパケットの長さ。 log_level 文字列 デバイスに設定されイベントに記 されたログレベル。 name 文字列 デバイスが報告したイベント名。名前には、他のフィールドに分類 されたイベントからの情報 (IP アドレスなど) が含まれてはいけませ ん。 pid int デバイスの OS がレコードを作成したプロセスに割り当てた整数。 priority int 環境固有のイベントの重要度評価。イベントの重大度、影響を受け るシステムのビジネス機能、または他のローカルに定義された 数な どに基づいて算出されます。 product 文字列 イベントを生成した製品。 product_version int イベントを生成した製品のバージョン。 reason 文字列 connection refused、timeout、crash result 文字列 アクションの結果。しばしば、succeeded と failed、allowed と denied などの二 。 severity 文字列 ソースデバイスから報告されたイベントの重大度 (または優先度)。 src_tos 整数 ソース IP の ToS (サービスタイプ)。この表の tos も参照してくだ さい。 src_vlan 整数 4, 5, 6, ま たは 7 などの、結果の主要因。 イベントのソース仮想 LAN。この表の vlan も参照してください。 19 0, 1, 2, 3, 0, 1, 2, 3, 4, 5, 6, たは 7 ま start_time timestamp イベントの指定開始時刻。 tos 整数、複 数値 イベントのソース/宛先 IP ToS (サービスタイプ) 値の組み合わせ。 詳細は、この表の dest_tos と src_tos を参照してください。 transaction_id 文字列 トランザクション ID。 url 文字列 レコードに含まれている均一のレコードロケーター (Web アドレ ス)。 vendor 文字列 イベントを生成した製品のメーカー。 vlan 整数、複 数値 ソース/宛先仮想 LAN 値の組み合わせ。詳細は、この表の dest_vlan と src_vlan を参照してください。 DNS プロトコル フィールド名 データタ イプ record_class 文字列 明 可能な値： DNS リソースレコード IN (インターネット - デフォルト)、HS (Hesiod - 履歴)、また クラス。 は CH (Chaos - 履歴)。 DNS プロトコル フィールド名 デー タタ イプ 明 可能な値： dest_domain 文字 列 照会された DNS ドメイン。 dest_record 文字 列 処理中のリモート DNS リソースレコード。 dest_zone 文字 列 ゾーン転送の一環としてスレーブが受信中の DNS ゾーン。 record_class 文字 列 DNS リソースレコードクラス。 record_type 文字 列 DNS リソースレコードタイプ (DNS レコード タイプに関する Wikipedia の記事を参照)。 src_domain 文字 列 照会中のローカル DNS ドメイン。 src_record 文字 列 処理中のローカル DNS リソースレコード。 src_zone 文字 列 ゾーン転送の一環としてマスターが転送中の DNS ゾーン。 (インターネット - デフォルト)、HS (Hesiod - 履歴)、または CH (Chaos - 履 歴)。 IN メール追跡 フィールド名 データタイプ 明 recipient 文字列 メールの送信先 (受信者)。 sender 文字列 メールの送信者。 subject 文字列 メールの件名。 ファイル管理 20 可能な値： フィールド名 データタ イプ 可能 な 値： 明 file_access_time timestamp ファイル (イベントのオブジェクト) のアクセス時刻。 file_create_time timestamp ファイル (イベントのオブジェクト) の作成時刻。 file_hash 文字列 file_modify_time timestamp ファイル (イベントのオブジェクト) の 更時刻。 file_name 文字列 イベントのオブジェクトであるファイルの名前 (ローカルファイルまた はディレクトリ構造に関連する場所情報なし)。 file_path 文字列 ローカルファイルまたはディレクトリ構造の 点からの、イベントのオブ ジェクトであるファイルの場所。 file_permission 文字列 イベントの影響を受けたファイルに関連付けられたアクセス制御。 file_size int イベントのオブジェクトであるファイルのサイズ。バイト、KB、MB、 または GB を示します。 イベントが影響を与えたファイルオブジェクトに割り当てられている暗 号化 ID。 侵入 知 フィール ド名 デー タタ イプ 明 category 文字 トリガーされた署名のカテゴリ。 列 dest 侵入 知システム (IDS) が 出した攻 の宛先。フィールド名が 文字 dest_host、dest_ip、または dest_nt_host の場合、CIM に準 させるためにエ 列 イリアス dest を設定することができます。 dvc 文字 侵入イベントを 出したデバイス。 列 ids_type 文字 イベントを生成した IDS のタイプ。 列 IDP、 Proventia、ASA product severity 文字 列 文字 列 network, host, application などの、ネットワーク保護データを生成したベンダーテ クノロジーの製品名。 注意：ネットワーク保護が処理するすべてのイベントに必要 ( 更分析、プロキ シ、マルウェア、侵入 知、パケットフィルタリング、脆弱性)。 ネットワーク保護イベントの重大度 (critical、high、medium、low、informational など)。 注意：このフィールドは文字列です。データタイプが整数の重大度 ID フィール ドに しては、severity_id フィールドを使用してください。 signature 文字 PlugAndPlay_BO や JavaScript_Obfuscation_Fre などの、クライアント (src) で 列 出された侵入名。 src IDS が 出した攻 に関与したソース。フィールド名が src_host、src_ip、または 文字 src_nt_host の場合、CIM に準 させるためにエイリアス src を設定することが 列 できます。 user 文字 侵入 知イベントに関与したユーザー。 列 vendor 文字 列 IDP、 Proventia、ASA 可能な値： などの、ネットワーク保護データの生成に用いられたベ ンダーテクノロジー。 注意：ネットワーク保護が処理するすべてのイベントに必要 ( 更分析、プロキ シ、マルウェア、侵入 知、パケットフィルタリング、脆弱性)。 21 マルウェア - エンドポイント保護 フィールド名 デー タタ イプ 可能な 値： 明 allowed, 文字 感染の結果。 列 action blocked, deferred dest_nt_domain 文字 宛先の NT ドメイン (dest_bestmatch)。 列 file_hash 文字 マルウェアイベントに関連するファイルの暗号ハッシュ ( 意のあるまたは 列 感染したファイルなど)。 file_name 文字 マルウェアイベントに関与したファイル名 ( 意のあるまたは感染したファ 列 イルなど)。 file_path 文字 マルウェアイベントに関与したファイルのパス ( 意のあるまたは感染した 列 ファイルなど)。 product 文字 マルウェアデータを生成したベンダーテクノロジー (vendor フィールド) 列 の製品名 (Antivirus や EPO など)。 product_version 文字 クライアントにインストールされている vendor テクノロジーの製品バー 列 ジョン番号 (10.4.3 や 11.0.2 など)。 Trojan.Vundo、Spyware.Gaobot、W32.Nimbda 文字 列 signature などの、クライアント (src) で 出されたマルウェア感染名。 注意：このフィールドは文字列です。データタイプが整数の署名 ID フィールドに しては、signature_id フィールドを使用してください。 signature_version 文字 11hsvx などの、現在クライアント上で動作している署名定義セット。 列 dest マルウェアによる影響を受けた、または感染したターゲット。フィールド 文字 名が dest_host、dest_ip、または dest_nt_host の場合、CIM に準 させる 列 ためにエイリアス dest を設定することができます。 src_nt_domain 文字 ソースの NT ドメイン (src)。 列 user 文字 マルウェアイベントに関与したユーザー名。 列 vendor 文字 Symantec や McAfee などの、マルウェアデータを生成したベンダーテクノ 列 ロジー名。 マルウェア - ネットワーク保護 フィール データ ド名 タイプ 明 IDP、Proventia、ASA などの、ネットワーク保護データを生成したベンダーテクノロ ジーの製品名。 product 文字列 注意：ネットワーク保護が処理するすべてのイベントに必要 ( 更分析、プロキシ、マ ルウェア、侵入 知、パケットフィルタリング、脆弱性)。 ネットワーク保護イベントの重大度 (critical、high、medium、low、informational など)。 severity 文字列 注意：このフィールドは文字列です。データタイプが整数の重大度 ID フィールドに しては、severity_id フィールドを使用してください。 IDP、Proventia、ASA などの、ネットワーク保護データの生成に用いられたベンダー テクノロジー。 vendor 文字列 22 可能 な 値： 注意：ネットワーク保護が処理するすべてのイベントに必要 ( 更分析、プロキシ、マ ルウェア、侵入 知、パケットフィルタリング、脆弱性)。 ネットワークトラフィック - エンタープライズセキュリティ フィール ド名 データ タイプ 可能な 値： 明 action 文字列 ネットワークトラフィックのアクション。 bytes 整数 このデバイス/インターフェイスが処理した合計バイト数 (bytes_in + bytes_out)。 bytes_in 整数 このデバイス/インターフェイスが受信したバイト数。 bytes_out int このデバイス/インターフェイスが送信したバイト数。 dest_port int ネットワークトラフィックの宛先ポート。 allowed、 blocked IDP、Proventia、ASA などの、NetworkProtection データを生成したベンダーテ クノロジーの製品名。 product 文字列 注意：ネットワーク保護が処理するすべてのイベントに必要 ( 更分析、プロキ シ、マルウェア、侵入 知、パケットフィルタリング、脆弱性)。 src_port int ネットワークトラフィックのソースポート。 IDP、Proventia、ASA などの、NetworkProtection データの生成に用いられたベ ンダーテクノロジー。 vendor 文字列 注意：ネットワーク保護が処理するすべてのイベントに必要 ( 更分析、プロキ シ、マルウェア、侵入 知、パケットフィルタリング、脆弱性)。 ネットワークトラフィック - 汎用 フィールド名 デー タタ イプ 明 app_layer 文字 HTTP、HTTPS、SSH、および IMAP などの ISO レイ 列 ヤー 7 (アプリケーション層) プロトコル。 bytes int このデバイス/インターフェイスが処理した合計バイ ト数 (bytes_in + bytes_out)。 bytes_in int このデバイス/インターフェイスが受信したバイト 数。 bytes_out int このデバイス/インターフェイスが送信したバイト 数。 channel 文字 無線ネットワークが使用した 802.11 チャネル番 列 号。 cve 文字 共通脆弱性識別子 (CVE) 参照値。 列 dest_app 文字 ターゲットとなっている宛先アプリケーション。 列 dest_cnc_channel 文字 宛先コマンドと制御サービスチャネル。 列 dest_cnc_name 文字 宛先コマンドと制御サービス名。 列 dest_cnc_port 文字 宛先コマンドと制御サービスポート。 列 dest_country 文字 パケットの受信者に関連付けられた国。 列 23 可能な値： dest_host 文字 パケットの受信者の完全修飾ホスト名。HTTP セッ 列 ションの場合は、ホストのヘッダーになります。 dest_int 文字 リモートに待機している、またはローカルにパケッ 列 トを受信しているインターフェイス。 dest_ip 文字 パケットの受信者の IPv4 または IPv6 アドレス。 列 dest_lat int パケットの宛先の (物理的な) 緯度。 dest_long int パケットの宛先の (物理的な) 度。 dest_mac 文字 パケットの宛先の TCP/IP レイヤー 2 メディアアク 列 セス制御 (MAC) アドレス。 dest_nt_domain 文字 パケットの宛先が存在する Windows NT ドメイン。 列 dest_nt_host 文字 パケットの宛先の Windows NT ホスト名。 列 dest_port int dest_translated_ip 文字 パケットが送信された、NAT が適用された IPv4 ま 列 たは IPv6 アドレス。 dest_translated_port int NAT が適用されたパケットの送信先ポート。 ip_version int 番号が付けられたインターネットプロトコルバー ジョン。 outbound_interface 文字 パケットが伝送されたネットワークインターフェイ 列 ス。 packets_in int このデバイス/インターフェイスが受信したパケット 数。 packets_out int このデバイス/インターフェイスが送信したパケット 数。 パケットの送信先 TCP/IP ポート。 IPv4/IPv6、ICMP、IPsec、IGMP、およびRIP protocol などの OSI レイヤー 3 (ネットワーク層) プロトコル。エイ 文字 リアス transport を使用したり、その逆も可能です 列 (この表の transport フィールドを参照してくださ い)。 session_id 文字 セッションID。複数のトランザクションがセッショ 列 ンを構築します。 ssid 文字 無線セッションに割り当てられた、802.11 サービス 列 セット ID (SSID)。 src_country 文字 パケットの送信元の国。 列 src_host 文字 パケットを伝送したシステムの完全修飾ホスト名。 列 Web ログの場合、HTTP クライアントになります。 src_int 文字 ローカルに待機している、またはリモートにパケッ 列 トを送信しているインターフェイス。 src_ip 文字 パケットのソースの IPv4 または IPv6 アドレス。 列 Web ログの場合、HTTP クライアントになります。 src_lat int パケットのソースの (物理的な) 緯度。 src_long int パケットのソースの (物理的な) 度。 src_mac 文字 パケットの伝送元メディアアクセス制御 (MAC) アド 列 レス。 src_nt_domain 文字 イベントを生成したマシンが存在している Windows 列 NT ドメイン。 src_nt_host 文字 イベントを生成したシステムの Windows NT ホスト 列 名。 src_port int パケットのソースとなるネットワークポート。 24 4, 6 src_translated_ip 文字 パケットの送信元の、NAT が適用された IPv4 また 列 は IPv6 アドレス。 src_translated_port int syslog_id 文字 イベントを生成したアプリケーション、プロセス、 列 または OS サブシステム。 syslog_priority 文字 UNIX syslog に記 された、イベントの重大度。 列 tcp_flag 文字 イベントに指定されている TCP フラグ。 列 tos TCP の ToS を示す 16 進ビット 文字 (http://en.wikipedia.org/wiki/Type_of_Service を参 列 照)。 transport 伝送プロトコル。エイリアス protocol を使用した 文字 り、その逆も可能です (この表の protocol フィール 列 ドを参照してください)。 ttl int パケットまたはデータグラムの有効期限 (TTL)。 vlan_id int レコードに指定されている、仮想 LAN (VLAN) に割 り当てられた数値 ID。 vlan_name 文字 レコードに指定されている、仮想 LAN (VLAN) に割 列 り当てられた名前。 NAT が適用されたパケットの送信元ポート。 1 つまたは複数の SYN、ACK、FIN、RST、URG、 または PSH になります。 TCP, UDP パケットのフィルタリング フィール ド名 デー タタ イプ 可能な 値： 明 action 文字 列 通信時に実行されたフィルタリングデバイスのアクション (dvc_bestmatch フィー ルド)。 dest_port int 22 direction 文字 列 パケットの伝送方向。 dvc 文字 列 パケットのフィルタリングデバイス名。フィールド名が dvc_host、dvc_ip、また は dvc_nt_host の場合、CIM に準 させるためにエイリアス dvc を設定することが できます。 rule 文字 列 143 svc_port int 34541 allowed, blocked のような、パケットの宛先 IP ポート。 inbound, outbound などの、パケットにアクションを行ったルール。 のような、パケットのソース IP ポート。 プロキシ フィールド名 データ タイプ 明 action 文字列 プロキシが実行したアクション。 dest 文字列 ネットワークトラフィックの宛先 (リモートホスト)。 http_content_type 文字列 要求された HTTP リソースのコンテンツタイプ。 http_method 文字列 リソースのリクエストに使われた HTTP メソッド。 http_refer 文字列 HTTP リソースのリクエストに使われた HTTP リファラー。 http_response int HTTP 答コード。 http_user_agent 文字列 HTTP リソースのリクエストに使われたユーザーエージェン ト。 25 可能な値： GET、POST、DELETE など。 IDP、Providentia、ASA などの、ネットワーク保護データを 生成したベンダーテクノロジーの製品名。 product 文字列 src 文字列 ネットワークトラフィックのソース (接続を要求しているクラ イアント)。 status int プロキシリクエストのステータスを含めた HTTP 答コード。 user 文字列 HTTP リソースを要求したユーザー。 url 文字列 要求された HTTP リソースの URL。 vendor 文字列 404、302、500 な ど。 IDP、Providentia、ASA などの、ネットワーク保護データを 生成したベンダーテクノロジー。 システムセンター フィールド名 データタイプ 明 可能な値： selinux 文字列 SE Linux設定ファイルからの値。 disabled, enforcing Startmode 文字列 当該サービスの開始モード。 disabled, enabled, auto システムセンター フィールド名 デー タタ イプ 明 や sshd などの、システム (src) 上で稼働しているア プリケーションまたはサービス。 app 文字 列 FreeMBytes int kernel_release 文字 列 label 文字 列 人が認識できる形式の SystemUptime 値。 mount 文字 列 システム (src フィールド) 上の利用可能なディスクスペース ( FreeMBytes フィールド) を報告しているドライブまたはマウント。 os 文字 列 Microsoft Windows Server 2003 PercentProcessorTime int プロセッサ使用率。 setlocaldefs int SE Linux 設定からの setlocaldefs の設定。 selinux 文字 列 SE Linux設定ファイルからの値。 selinuxtype 文字 列 SE Linux タイプ (targeted など)。 shell 文字 列 システムログイン (src フィールド) 時にユーザーアカウント (user フィールド) に提供されたシェル。 src_port int システム (src フィールド) 上の TCP/UDP ソースポート。 sshd_protocol 文字 列 sshd プロトコルのバージョン。 Startmode 文字 列 当該サービスの開始モード。 int システム (src) が起動してからの秒数。 SystemUptime 可能な値 explorer.exe システム (src フィールド) 上のドライブまたはマウント (mount フィールド) 当たりの利用可能なディスクスペース。 や 2.6.27.30-170.2.82.fc10.x86_64 などの、ホスト (src フィールド) にインストールされている OS のバージョン。 6.0.1.4 や GNU/Linux などの、ホスト (src フィールド) にインストールされている OS の名前。 disabled, enforcing disabled, enabled, auto 26 TotalMBytes int システム (src) の利用可能メモリー合計。 UsedMBytes int システム (src) の使用メモリー合計。 user 文字 列 システム (src) に存在しているユーザーアカウント。 updates int システム (src) の失われている更新数。 トラフィック フィール ド名 デー タタ イプ 可 能 な 値 明 bytes int このデバイス/インターフェイスが処理した合計バイト数 (bytes_in + bytes_out)。 bytes_in int このデバイス/インターフェイスが受信したバイト数。 bytes_out int このデバイス/インターフェイスが送信したバイト数。 dest 文字 列 ネットワークトラフィックの宛先。フィールド名が dest_host、dest_ip、または dest_nt_host の場合、CIM に準 させるためにエイリアス dest を設定することができま す。 dvc 文字 列 パケットのフィルタリングデバイス名。フィールド名が dvc_host、dvc_ip、または dvc_nt_host の場合、CIM に準 させるためにエイリアス dvc を設定することができま す。 src 文字 列 ネットワークトラフィックのソース。フィールド名が src_host、src_ip、または src_nt_host の場合、CIM に準 させるためにエイリアス src を設定することができま す。 更新 フィールド名 package データタイプ 文字列 明 可能な値 インストールされているアップデート名。 ユーザー情報の更新 フィールド名 デー タタ イプ 明 affected_user 更の影響を受けたユーザー。たとえば、ユーザー fflanda 文字 がユーザー rhallen の名前を 更する 列 と、affected_user=rhallen になります。 affected_user_group 文字 列 更の影響を受けるユーザーグループ。 affected_user_group_id int 更の影響を受けるユーザーグループの ID。 affected_user_id int 更の影響を受けるユーザーの ID。 affected_user_privilege 列 更の影響を受けたユーザーに関連するセキュリティコンテ キスト。 user 文字 記 されたイベントの影響を受けたユーザー名。 列 user_group 文字 人が認識できる形式の、イベントのオブジェクトである 列 ユーザーグループ。 user_group_id int ユーザーグループイベントオブジェクトに割り当てられた 数値 ID。 27 可能な値 administrator, user, guest/anonymous user_id int システムが割り当てた、イベントの影響を受けたユーザー の ID。 user_privilege 列 イベントのオブジェクト (影響を受けたユーザー) に関連付 けられたセキュリティコンテキスト。 user_subject 文字 イベントの主体となるユーザー名 (アクションを実行した 列 ユーザー)。 user_subject_id int イベントの主体となるユーザーの ID 番号。 user_subject_privilege 列 イベントのオブジェクト (影響を受けたユーザー) に関連付 けられたセキュリティコンテキスト。 administrator, user, guest/anonymous administrator, user, guest/anonymous 脆弱性 デー タタ イプ フィール ド名 可 能 な 値 明 category 文字 列 出された脆弱性のカテゴリ。 dest 文字 列 出された脆弱性のホスト。フィールド名が dest_host、dest_ip、または dest_nt_host の場合、CIM に準 させるためにエイリアス dest を設定することができます。 os 文字 列 SuSE Security Update severity 文字 列 signature 文字 列 や cups security update などの、クライアント (src) 上で 出さ れた脆弱性を含むホストの OS。 出された脆弱性の重大度。 SuSE Security Update や cups security update などの、クライアント (src) で 出され た脆弱名。 Windows 管理 フィールド名 データタイプ 明 object_name 文字列 オブジェクト名 (Windows にのみ関係)。 object_type 文字列 オブジェクトタイプ (Windows にのみ関係)。 object_handle 文字列 オブジェクトハンドル (Windows にのみ関係)。 可能な値 イベントタイプタグの標準化 共通情報モデルは、イベントタイプのタグ付け時には特定の規則を採用することを提案しています。この規則で は、2 種類のタグカテゴリを設定し、システム内の各イベントタイプに してこれらの両方のカテゴリから 1 つの タグを割り当てる必要があります。カテゴリは、オブジェクト (object) とステータス (status) です。 このような方法をとることで、イベントタイプを正確に分類できます。オブジェクトタグは、イベントがどのよう なものかを表します。ターゲットにしているオブジェクトは何なのか？イベントが表しているのはホスト、リソー ス、ファイル、またはその他の何を表しているのか？などを示しています。ステータスタグは、アクションのス テータスを表します。成功したか？失敗したか？または、単なる試みか？などを示します。これらの 2 つの標準タ グに加えて、他のタグを利用することもできます。 ここで取り上げる 2 種類のタグを以下に示します。 <objecttag> <statustag> 標準タグの使用例： ファイアウォール拒否イベントタイプの場合： host failure 28 ファイアウォール承認イベントの場合： host success 正常なデータベースログインの場合： database success オブジェクトイベントタイプタグ 前述のように、ここに記載されているいずれかのオブジェクトタグを使用してください。 タグ 明 application アプリケーションレベルのイベント。 application av ウィルス 策イベント。 application backdoor アプリケーションのバックドアを使ったイベント。 application database データベースイベント。 application database data データベースデータに関連するイベント。 application dosclient DOS クライアントが関与するイベント。 application firewall ファイアウォールが関与するイベント。 application im インスタンスメッセージ関連イベント。 application peertopeer ピアツーピア関連イベント。 host ホストレベルイベント。 group グループレベルイベント。 resource システムリソースが関与するイベント。 resource cpu CPU が関与するイベント。 resource file ファイルが関与するイベント。 resources interface ネットワークインターフェイスが関与するイベント。 resource memory メモリーが関与するイベント。 resource registry システムレジストリが関与するイベント。 os OS レベルのイベント。 os process OS 関連プロセスが関与するイベント。 os service OS サービスが関与するイベント。 user ユーザーレベルイベント。 ステータスイベントタイプタグ 前述のように、ここに記載されているいずれかのステータスタグを使用してください。 タグ 明 attempt 何かの試行を試みたイベント。 deferred 延イベント。 failure 失敗したイベント。 inprogress 何かを処理中のイベント。 report ステータスのレポート。 success 成功したイベント。 オプションのタグ 29 標準のタグに加えて追加のタグを使用したい方向けに、いくつかの提案事項を以下に示します。 タグ 明 attack 攻 をマークしているイベント。 attack exploit 用のマークがあるイベント。 attack bruteforce ブルートフォース攻 のマークがあるイベント。 attack dos サービス拒否攻 のマークがあるイベント。 attack escalation 特 の 大攻 を示すイベント。 infoleak 情報漏洩を示すイベント。 malware マルウェアアクションを示すイベント。 malware dosclient DOS クライアントを利用するマルウェアを示すイベント。 malware spyware スパイウェアを示すイベント。 malware trojan トロイの木馬を示すイベント。 malware virus ウィルスを示すイベント。 malware worm ワームを示すイベント。 recon 偵察プローブを示すイベント。 suspicious 疑わしいアクティビティを示すイベント。 ホストタグの標準化 すでにご存じかも知れませんが、ホストの名前を直接 更することが問題につながることも良くあります。ホスト はイベントデータのインデックスが作成される前に識別されるため、すでにインデックスが作成されたデータに は、ホスト名の 更が適用されません。タグを使って特定のホストからのイベントをグループ化する方が簡単で す。 標準化されたタグを使って特定のホスト、およびそれの動作を定義することができます。ホストのタグ設定にはさ まざまな方法が存在しており、必要に じて適切な方法を使い分けられます。方法の一例を以下に示します。 ホストが実行しているサービスは何か。 ホストが実行している OS は何か。 ホストが所属している部門。 ホストに含まれているデータは何か。 ホストが所属しているクラスタ/ラウンドロビンは何か。 全般ホストタグ これらのタグは、あらゆる場面で役立ちます。特定の App に させる一連のホストタグを作成することもできま す。 タグ 明 db このホストはデータベース。 development このホストは開発用。 dmz ホストは DMZ 内。 dns このホストは DNS サーバー。 email このホストはメールサーバー。 finance ホストに財務情報が含まれている。 firewall このホストはファイアウォール。 highly_critical ホストはビジネス上の目的で非常に重大。 web このホストは Web サーバー。 デ ー タの解 釈 ：フィ ー ルドとフィ ー ルドの抽出 30 フィ ー ルドについて フィールドは、イベントデータ内のサーチ可能な名前と値のペアです。すべてのフィールドには名前があり、それ らの名前でサーチできます。(「名前と値のペア」は「キーと値のペア」と呼ばれることもあります。) たとえば、以下のサーチを考えてみましょう。 host=foo このサーチで host=foo は、値が foo の host フィールドを持つイベントをサーチすることを示しています。この サーチを実行すると、host フィールドの値が異なるイベントは探されません。また、値が foo の他のフィールド を持つイベントも探されません。つまり、このサーチはサーチバーに単に foo を指定した場合よりも、より絞り込 まれたサーチ結果が返されることを意味しています。 Splunk によるイベントデータの処理時には、フィールドが抽出されて、定義されます。フィールドの抽出はまず インデックス時に行われ、サーチ時に再び行われます。これらのフィールドは、サーチの実行後フィールドサイド バーに表示されます。 インデックス時には、各イベントに して host、source、sourcetype などの、デフォルトのフィールドセットが抽 出されます。デフォルトのフィールドは、すべてのイベントに共通なイベントです。インデックス時にインデック ス作成されたカスタムフィールドを抽出することも可能です。カスタムフィールドは、ユーザーによりインデック ス時の抽出が設定されたフィールドです。 サーチ時には、サーチモードの設定および実行中のサーチのタイプに してフィールド 出が有効になっているかど うかに じて、追加のフィールドが自動的に抽出されます。 フィールド 出が無効になっている場合、サーチに明示的に指定されているフィールドと前述のデフォルト フィールドおよびインデックスが作成されたフィールドが抽出されます。 フィールド 出が有効になっている場合は、以下の処理が自動的に行われます。 user_id=jdoe や client_ip=192.168.1.1 (user_id および client_ip フィールドの例) などの、名前の値 とペアが一致する、イベントデータ内に見つかった最初の 50 件のフィールドを識別、抽出します。(こ の 50 件のフィールドはデフォルト値で、limits.conf の [kv] スタンザを編集して 更することができ ます。) 自動抽出で見つけられる場合もある、サーチに明示的に指定されている任意のフィールドを抽出しま す (これは最初に識別された 50 件のフィールドには含まれません)。 話式フィールド抽出、Splunk 管理の [フィールドの抽出] ページ、設定ファイルの編集、またはrex な どのサーチコマンドを利用して定義されているカスタムフィールドを抽出します。 次の場合、Splunk はデフォルトフィールド以外のフィールド、および当該サーチを完了するために必要なフィー ルドのみを 出します。 スマートサーチモードで非 換サーチを実行する 詳細サーチモードでサーチを実行する サーチモードの設定とフィールド 出の詳細は、『サーチマニュアル』の「サーチに合わせたサーチモードの設 定」を参照してください。 インデックス時/サーチ時の違いについては、『インデクサーとクラスタの管理』マニュアルの「インデックス時 とサーチ時」を参照してください。 自動フィールド抽出の例 この例は、Splunk がユーザーの助けを借りることなく自動的にフィールドを抽出する仕組みを表しています (逆に カスタムフィールド抽出では、ユーザーが定義したイベント抽出ルールに従って抽出が行われます)。 インデックス時に各イベントから自動的に抽出される、デフォルトの sourcetype フィールドに するサーチを考え てみましょう。以下のサーチの場合 sourcetype=veeblefetzer これを過去 24 時間に してサーチを実行すると、その時間範 の sourcetype が veeblefetzer のイベントが返されま す。このイベントセットから、Splunk は自身で識別した最初の 50 件のフィールドを自動的に抽出します。また、 設定ファイルに基づいてカスタムフィールドの抽出が行われます。サーチの完了後に、これらのフィールドはすべ てフィールドサイドバーに表示されます。 ここで、サーチされた 25,000 件目のイベントに userlogin=fail のような名前/値のペアが最初に登場 し、userlogin が事前設定されているカスタムフィールドではない場合、Splunk が自身で識別した最初の 50 フィールドにはおそらく入りません。 ただし、サーチを以下のように 更すると 31 sourcetype=veeblefetzer userlogin=* そうすると、userlogin フィールドと値が veeblefetzer の sourcetype フィールドが返されて、Splunk が抽出し たフィールドと他のフィールドと一緒にフィールドサイドバーに表示されます。 カスタムサ ー チフィ ー ルドの追加と管理 Splunk のサーチ能力を最大限に活用するためには、カスタムフィールド抽出の作成、管理方法を理解しておく必 要があります。カスタムフィールドにより、Splunk により自動抽出されない、自分のニーズに合わせた情報を取 得、追跡することができます。 ナレッジ管理者は、Splunk 環境でユーザーが作成する一連のカスタムフィールド抽出を監督し、また必要に じて 自分で専用のカスタムサーチフィールドのグループを定義します。このセクションでは、さまざまなフィールドの 作成と管理方法 (「サーチ時フィールド抽出の概要」を参照) およびこの機能の使用方法の例を 明していきます。 以下の事項について学習していきます。 Splunk 管理を使ったサーチ時フィールド抽出の作成と管理 Splunk 管理を使ったサーチ時フィールド 換の設計と管理 props.conf および transforms.conf 設定ファイルを使ったサーチ時抽出の追加と管理 複数値フィールドを解析するための Splunk の設定 デフォルトフィ ー ルドの使用 デフォルトフィ ー ルドの使用 フィールドは、イベントデータ内のサーチ可能な名前と値のペアです。サーチを実行する場合、サーチ単語をイベ ントデータのセグメントと照合することになります。フィールドを使用すれば、より正確にサーチを実行できま す。フィールドはインデックス時またはサーチ時にイベントデータから抽出されます。Splunk がインデックス時 に自動抽出するフィールドは、デフォルトフィールドと呼ばれます。 デフォルトのフィールドは、さまざまな目的に利用されます。たとえば、index はイベントが存在しているイン デックスを示します。デフォルトフィールド linecount はイベントに含まれる行数を、timestamp はイベントの発 生時刻を示します。Splunk はデータのインデックス作成時に、一部のフィールドの値、特に sourcetype の値を利 用して、正しくイベントを作成します。データのインデックスが作成されたら、サーチにデフォルトフィールドを 使用できます。 サーチコマンドでのデフォルトフィールドの使用の詳細は、『サーチマニュアル』の「サーチ言語について」を参 照してください。デフォルトフィールドの設定方法の詳細は、『Getting Data In』の「About default fields」を参 照してください。 フィー フィールドのリス ルドの ト タイプ 内部 _raw, _time, フィー _indextime, _cd ルド 明 これらのフィールドには、Splunk 内のイベントに関する全般的な情報が含まれて います。 host, index, デフォ ルト フィー ルド linecount, punct, source, sourcetype, splunk_server, これらのフィールドには、イベントのソース、存在しているインデックス、そのタ イプ、行数、発生時刻などの情報が含まれています。これらのフィールドはデフォ ルトでインデックスが作成され、[フィールド] メニューに追加されます。 timestamp date_hour, デフォ ルトの 日時 フィー ルド これらのフィールドは、イベントのタイムスタンプに するサーチをさらに細かく制 御するために用いられます。 date_mday, date_minute, date_month, date_second, date_wday, date_year, date_zone 注意：各システムで生成されたタイムスタンプ情報を持つイベントのみが、date_* フィールドを持っています。イベントに date_* フィールドがある場合、それはイ ベント自体からの直接の時間/日付値を表しています。インデックス時/入力時にタ イムゾーン 換や時間/日付値の 更をを行った場合 (例：タイムスタンプがインデック ス時または入力時になるように設定した)、これらのフィールドはそれを表さないよ うになります。 32 フィールドは複数の値を持つことができます。そのようなフィールドと値の処理方法の詳細は、この章の「複数値 フィールドの操作と評価」を参照してください。 Splunk Web または抽出サーチコマンドを使用して、追加のフィールド (デフォルト以外のフィールド) を抽出でき ます。詳細は、このマニュアルの「フィールドについて」を参照してください。 フィールド名を 更したり、類似のフィールドをグループ化することができます。このような操作は、フィールド およびフィールド値のタグやエイリアスを使って簡単に行えます。詳細は、このマニュアルの「フィールド値のタ グ/エイリアス設定」を参照してください。 ここでは、データのインデックスを作成する際に Splunk が自動的に追加する内部フィールドやその他のフィール ドについて取り上げていきます。 内 部フィ ー ルド アンダースコアで始まるフィールドは内部フィールドです。 注意：自分が何を行っているのかを確実に理解している場合を除き、内部フィールドを上書きすることはお勧めで きません。 _raw フィールドには、イベントのオリジナルの raw データが含まれています。サーチおよびデータ抽出の実行時 に、Splunk の search コマンドは、_raw 内のデータを使用します。 _raw 常に _raw の値を直接サーチすることはできません。regex や sort などのコマンドでフィルタリングすることがで きます。 例：IP アドレスの値が「10」で始まる sendmail イベントを返します。 eventtype=sendmail | regex _raw=*10.\d\d\d\.\d\d\d\.\d\d\d\* _time フィールドには、UNIX 時で表されるイベントのタイムスタンプが含まれています。Splunk はこのフィール ドを使って、Splunk Web のイベントタイムラインを作成します。 _time 注意：_time フィールドは、内部的に UTC 形式で保管されます。Splunk がサーチ結果を表示する際 (サーチ時の 最後の方のステップ) に、人が理解できる UNIX 時間形式に 換されます。 例：タイプが「mail」のソースに して、ユーザー「[email protected]」宛のメールアドレスをサーチし て、サーチ結果をタイムスタンプでソートします。 sourcetype=mail [email protected] | sort _time _indextime フィールドには、UNIX 時間で表された、イベントのインデックスが作成された時刻が保管されていま す。このフィールドを使って、特定の期間内にインデックスが作成されたイベントに絞り込む (フィルタリングす る) ことができます。 _indextime _cd 基本的に _cd フィールドは、インデックス内のイベントの「アドレス」を表しています。短い数字と長い数字の 2 種類の数字で構成されています。短い数字は、イベントが存在している特定のインデックスバケツを示していま す。長い数字は、インデックスバケツのオフセットを表しています。これにより、バケツ内の正確なイベントの位 置が提供されます。_cd は内部参照のためにのみ用いられるため、サーチにこれを使用することはお勧めいたしま せん。 その他のデフォルトフィ ー ルド ホスト フィールドには、イベントを生成したネットワークデバイスのホスト名または IP アドレスが含まれていま す。. host フィールドを使ってサーチを絞り込むことができます。host に照合する値を指定してください。ワイル ドカードを使って、単一の式内に複数のホストを指定することができます (例：host=corp*)。 host を使ってデータ生成コマンドの結果をフィルタリングしたり、データ処理コマンドの引数として使用したり することができます。 host 33 例 1：ユーザー「strawsky」によるすべての「corp」サーバーへのアクセスイベントをサーチします。その中で最 新の 20 件のイベントのレポートを作成します。 host=corp* eventtype=access user=strawsky | head 20 例 2：「192」から始まるホストからの、用語「404」を含むイベントをサーチします。 404 | regex host=*192.\d\d\d\.\d\d\d\.\d\d\d\* index フィールドには、イベントのインデックスが作成されたインデックス名が含まれていま す。index="name_of_index" のように、サーチで使用するインデックスを指定できます。デフォルトでは、すべて のイベントが main インデックスにインデックスされます (index="main")。 _index 例：myweb インデックスの 張子「.php」を持つイベントをサーチします。 index="myweb" *.php linecount フィールドには、イベントに含まれている行数が保管されています。これは、インデックスが作成され る前にイベントに含まれていた行数です。linecount は、特定の行数を持つイベントのサーチに、またはデータ処 理コマンドの引数として用いられます。照合する範 を指定するには、不等号を使用します (例：linecount>10 linecount<20)。 linecount 例：corp1 に して「40」および 40 行を持つイベントをサーチして、「400」を含むイベントを除外します。 40 linecount=40 host=corp1 NOT 400 punct フィールドには、イベントから抽出された句読点パターンが保管されています。句読点パターンは、イベン トのタイプによって一意です。サーチで punct を使ってイベントをフィルタリングしたり、データ処理コマンドの 引数として使用したりできます。 punct フィールドにワイルドカードを使って、共通の特性を持つ複数の句読点パターンをサーチすることができま す。punct フィールドの句読点パターンを定義する際には、引用符を使用する必要があります。 punct 例 1：: で開始、終了するすべての句読点パターンをサーチします。 punct=":*:" 例 2：php_error.log に して、句読点パターン「[--_::]__:___:____/-..-///.___」を持つ php エラーイベントをサーチ します。 source="/var/www/log/php_error.log" punct="[--_::]__:___:____''/-..-''///.___" ソース フィールドには、イベントのソースとなるファイル、ストリーム、または他の入力名が保管されます。 サーチ時に source を使ってイベントをフィルタリングしたり、データ処理コマンドの引数として使用したりでき ます。ワイルドカードを使って、単一の式内に複数のソースを指定することができます (例：source=*php.log*)。 source を使ってデータ生成コマンドの結果をフィルタリングしたり、データ処理コマンドの引数として使用した りすることができます。 source 例：ソース「/var/www/log/php_error.log」からのイベントをサーチします。 source="/var/www/log/php_error.log" sourcetype フィールドは、access_combined や cisco_syslog などのイベントのソースからの、データ入力フォー マットを示します。サーチ時に sourcetype を使ってイベントをフィルタリングしたり、データ処理コマンドの引 数として使用したりできます。ワイルドカードを使って、単一の式内に複数のソースを指定することができます (例：sourcetype=access*)。 sourcetype 例：ソースタイプが「access log」のイベントをサーチします。 34 sourcetype=access_log splunk-server splunk-server フィールドには、イベントを含む Splunk サーバー名が含まれています。分散 Splunk 環境で役立ち ます。 例：サーチを名前が「remote」 サーバー上の main インデックスに制限します。 splunk-server=remote index=main 404 timestamp フィールドには、イベントのタイムスタンプ値が含まれています。Splunk によるタイムスタンプの抽 出方法は設定することができます。timestamp を search コマンドの引数として使用して、サーチをフィルタリン グできます。 timestamp たとえば、サーチに timestamp=none を指定して、認識できるタイムスタンプ値がないイベントのみを含めるよう にサーチ結果をフィルタリングできます。 例：データ内の認識できるタイムスタンプがないイベント数を返します。 timestamp=none | stats count(_raw) as count デフォルトの日時フィ ー ルド サーチで datetime を使ってイベントをフィルタリングしたり、データ処理コマンドの引数として使用したりでき ます。 Splunk サーバーとは別のタイムゾーンで作業を行っている場合、時間ベースのサーチでは、イベントのインデッ クスが作成されたサーバーからのイベントのタイムスタンプが用いられます。日時値は、そのタイムゾーンに関係 なく、インデックス作成時にイベントから解析されるリテラル値です。そのため、「05:22:21」のような文字列が 解析されると、「date_hour::5 date_minute::22 date_second::21」のようなインデックスフィールドが作成されま す。 date_hour フィールドには、イベントが発生した時間の値が含まれます (範 ：0 23)。この値は、イベントのタイム スタンプから抽出されます (_time 内の値)。 date_hour 例：現在の日の午後 10 時から午前 0 時までに発生した、用語「apache」を含むイベントをサーチします。 apache (date_hour >= 22 AND date_hour <= 24) date_mday フィールドには、イベントが発生したその月の日付値が含まれます (範 ：1 31)。この値は、イベントの タイムスタンプから抽出されます (_time 内の値)。 date_mday 例：今月の 1 日 15 日の間に発生した、用語「apache」を含むイベントをサーチします。 apache (date_mday >= 1 AND date_mday <= 15) date_minute フィールドには、イベントが発生した分の値が含まれます (範 ：0 59)。この値は、イベントのタイム スタンプから抽出されます (_time 内の値)。 date_minute 例：現在の時間の 15 分 20 分の間に発生した、用語「apache」を含むイベントをサーチします。 apache (date_minute >= 15 AND date_minute <= 20) date_month フィールドには、イベントが発生した月の値が含まれます。この値は、イベントのタイムスタンプか ら抽出されます (_time 内の値)。 date_month 例： 1 月に発生した用語「apache」を含むイベントをサーチします。 35 apache date_month=1 date_second フィールドには、イベントのタイムスタンプの秒の値が含まれます (範 ：1 59)。この値は、イベント のタイムスタンプから抽出されます (_time 内の値)。 date_second 例：現在の分の 1 15 秒の間に発生した、用語「apache」を含むイベントをサーチします。 apache (date_second >= 1 AND date_second <= 15) date_wday フィールドには、イベントが発生した曜日が含まれています (Sunday、Monday など)。Splunk はイベ ントのタイムスタンプ (_time 内の値) から日付を抽出して、その日付の曜日を判断します。この曜日値 は、date_wday フィールドに保管されます。 date_wday 例： 日曜日に発生した用語「apache」を含むイベントをサーチします。 apache date_wday="sunday" date_year フィールドには、イベントが発生した年の値が含まれます。この値は、イベントのタイムスタンプから 抽出されます (_time 内の値)。 date_year 例： 2008 年に発生した用語「apache」を含むイベントをサーチします。 apache date_year=2008 date_zone フィールドには、UNIX 時間 (時間) で表される、イベントのローカルタイムゾーンの時間値が含まれて います。この値は、イベントのタイムスタンプから抽出されます (_time 内の値)。イベントのタイムゾーンのオフ セットを使用するには、date_zone を使ってオフセットを分で指定します (範 ：-720 720)。 date_zone 例： 現在のタイムゾーン (ローカル) で発生した用語「apache」を含むイベントをサーチします。 apache date_zone=local サ ー チ時フィ ー ルド抽出の 概 要 ここでは、Splunk Web のフィールド抽出方法の概要を簡単に 明しています。 Splunk を使用するにつれて、Splunk がインデックス時およびサーチ時に自動抽出するフィールドセットに加え て、他の新しいフィールドを作成する必要が出てきます。 ナレッジ管理者は、チームのフィールド抽出を管理します。多くの場合、サーチ、レポート、ダッシュボードの役 に立つイベントデータにするために、Splunk が識別しないさまざまなフィールドを定義していきます。ただし、 イベントデータ正規化の一環としてフィールドの抽出を定義することもあります。この場合、冗長性を減らして、 他の Splunk ユーザーが利用できるフィールドの総合的なユーザビリティを向上する目的で、既存のフィールドを 再定義して、新しいフィールドを作成します。 (詳細は、このマニュアルの「共通の情報モデルの理解と使用」を 参照してください。) さまざまなサーチ時フィールド抽出を追加する必要がある場合、それを実現するためにさまざまな方法を利用でき ます。Splunk Web には、さまざまなサーチ時のフィールド抽出手法が用意されています。サーチ言語を利用し て、一時的なフィールド抽出を作成することもできます。設定ファイルを編集して、フィールド抽出を追加、管理 することもできます。 Splunk Web を使ったサーチ時のフィールド抽出の詳細は、このマニュアルの「フィールドの抽出について」を参 照してください。ここでは方法の概要を 明して、それらの詳細な 明と例へのリンクを記載しています。 話式フィ ー ルド抽出を使った新規フィ ー ルドの作成 Splunk Web の 話式フィールド抽出 (IFX) を使って、動的にカスタムフィールドを作成することができます。IFX により、任意のサーチをフィールド抽出の正規表現に 換できます。IFX は、ローカルインデクサー上で使用しま す。IFX の使用方法の詳細は、このマニュアルの「IFX を使った 話式のフィールド抽出」を参照してください。 36 注意： IFX はフィールド抽出用の正規表現を生成するため (またそれをテストできるため)、特に正規表現の構文や 使用方法に詳しくない方に役立ちます。 IFX を利用するには、サーチを実行してから、次にフィールド結果のタイムスタンプの下にあるドロップダウンか ら [フィールドの抽出] を選 します。IFX では、一度に 1 つのフィールドを抽出することができます (後ほど正規表 現を 更して、複数のフィールドを抽出することもできます)。 Splunk 管理を使ったフィ ー ルド抽出の追加と管理 Splunk 管理の [フィールドの抽出] および [フィールド 換] ページを使用して、抽出されたフィールドを確認、編 集、作成することができます。 [フ ィ ー ル ド の 抽 出 ] ペ ー ジ [フィールドの抽出] ページには、props.conf 内のサーチ時フィールド抽出が表示されます。既存の抽出を編集し て、新しい抽出を作成することができます。[フィールドの抽出] ページでは、フィールドの抽出を確認、更新、作 成することができます。これを使って、基本的な「インライン」サーチ時抽出 (全体が props.conf 内で定義された 抽出) および transforms.conf 内のフィールド 換コンポーネントを参照する高度なサーチ時抽出の両方を作成、管理 することができます。フィールド 換は、Splunk 管理の [フィールド 換] ページ (後述) で定義できます。 Splunk Web で、[フィールドの抽出] ページに移動するには [管理] > [フィールド] > [フィールドの抽出] を選 しま す。 詳細は、「Splunk 管理の [フィールドの抽出] ページの使用」を参照してください。 [フ ィ ー ル ド の 抽 出 ] ペ ー ジ Splunk 管理を使って、より複 なサーチ時フィールド抽出を作成することもできます。 [フィールド 換] ページには、transforms.conf に定義されているサーチ時フィールド 換が表示されます。フィール ド 換は、props.conf に設定されているフィールド抽出と連携して、高度なフィールド抽出を行うことができま す。 換により、以下のようなフィールド抽出を定義することができます。 複数のソース、ソースタイプ、またはホストにまたがって同じフィールド抽出正規表現を再利用する (複数 のフィールド抽出用に 1 つのフィールド 換を設定する)。 同じソース、ソースタイプ、またはホストに して複数のフィールド抽出正規表現を適用する (同じフィール ド抽出に複数のフィールド 換を適用する)。 他のフィールドの値 (ソースキー) からフィールドを抽出する正規表現を使用する。 Splunk Web で、[フィールド 換] ページに移動するには [管理] > [フィールド] > [フィールド 換] を選 します。 詳細は、「Splunk 管理の [フィールド 換] ページの使用」を参照してください。 props.conf および transforms.conf のフィ ー ルド抽出の設定 および transforms.conf を直接編集して、フィールド抽出を作成、管理することもできます。このよ うな 験がある古い Splunk ユーザーの方や設定ファイルを編集する方が便利なユーザーの方は、このマニュアルの 「設定ファイルを使ったサーチ時抽出の作成と管理」を参照してください。 props.conf 設定ファイルの編集は、現在 Splunk 管理で行えるサーチ時のフィールド抽出よりも、さらに豊富できめ細かな作 業を行えることに注意してください。たとえば、設定ファイルを利用すれば、以下の事項を設定できます。 区切り文字ベースのフィールド抽出。 複数値フィールドの抽出。 数値やアンダースコア始まる名前のフィールドを抽出する (通常はキーのクリーニングが無効になっていな い限り禁止されています)。 抽出されたフィールドのフォーマット。 サ ー チコマンドを使ったフィ ー ルド抽出の作成 Splunk には、さまざまな方法でフィールドの抽出を行うための、多彩なサーチコマンドが用意されています。こ のようなコマンドの一覧を以下に示します。 rex サーチコマンドは、サーチ文字列に指定した名前付きグループを使った Perl 正規表現を使ってフィール ドの抽出を実行します。 extract (「キー/値」の場合は kv) サーチコマンドは、サーチ結果からフィールド/値のペアを抽出しま す。extract に引数を指定しないで使用すると、props.conf に追加されている field extraction スタンザを 使ってフィールド抽出が行われます。extract を使って、.conf ファイル 由で手動追加するフィールド抽出を 37 テストして、予定通りのフィールド/値のペアを抽出するかどうかを確認できます。 複数行、表形式イベントのフィールド/値の抽出を強制するには、multikv を使用します。この場合、各テー ブル行に して新しいイベントが作成され、テーブルのタイトルからフィールド名が取得されます。 xmlkv により、Web ページのイベントなどの XML 形式のイベントデータからフィールド/値のペアを抽出で きます。 kvform は、値の抽出方法を記述した、事前定義のフォームテンプレートに基づいて、イベントからフィール ド/値のペアを抽出します。これらのテンプレートは $SPLUNK_HOME/etc/system/form/、または $SPLUNK_HOME/etc/apps/.../form 内の独自のカスタムアプリケーションディレクトリに保管されています。 たとえば、form=sales_order の場合、Splunk は値を抽出するために、処理するすべてのイベントをフォー ムに して照合します。Splunk が error_code=404 を持つイベントに遭遇したら、sales_order.form ファイル を参照します。 これらのコマンドの使用方法と使用例については、『サーチリファレンス』または『サーチマニュアル』の「サー チコマンドによるフィールド抽出」を参照してください。 IFX による 話式のフィ ー ルド抽出 ローカル Splunk インスタンスで動的にカスタムフィールドを作成するには、 話式フィールド抽出 (IFX) を使用し ます。IFX により、1 つまたは複数のフィールドを認識する任意のパターンを定義することができます。 IFX は フィールド抽出用の正規表現を生成するため (またそれをテストできるため)、特に正規表現の構文や使用方法に詳 しくない方に役立ちます。また、正規表現を手動で編集しない限り、IFX は一度に 1 つのフィールドのみを抽出し ます。 Splunk は Web アクセスログの処理を得意としており、ほぼすべてのフィールドを抽出することができます。ここ の例では、単純にイベントから IP アドレスを抽出します。 1. IFX に移動するには、抽出するフィールド値を含むイベントを生成するサーチを実行します。 IP アドレスの抽出を目的にしているため、以下のように Apache アクセスログをサーチします。 sourcetype=access_combined 2. サーチ結果から、フィールド値を含むイベント探します (この例では IP アドレス)。イベントのタイムスタンプ の左にある矢印をクリックして、[フィールドの抽出] を選 します。 新しい [フィールドの抽出] ウィンドウに IFX が表示されます。 38 3. [フィールドの抽出を制限] メニューから、「sourcetype="access_combined"」を選 します。 このドロップダウンには、ステップ 2 で選 したイベントからのフィールド値が事前設定されます。別のホスト、 ソース、またはソースタイプ値を選 したい場合は、ウィンドウを閉じてからサーチ結果の別のイベントを選 する か、または新たなサーチを実行してください。 4. [値の例] テキストボックスに、結果からの IP アドレスの値を入力またはコピーして貼り付けます。最良の結果 を得るためには、複数の例を指定してください。 このサンプルイベントのリストは、サーチ結果で選 されたイベントと指定されたフィールド制限に基づいていま す。フィールド制限を 更すると、このリストも 更されますが、引き続き選 された元のイベントに基づいていま す。 5. 十分なサンプル値が集まったら、[生成] をクリックします。Splunk はフィールドの正規表現パターンを、指定 したイベントとイベントの一般フォーマットに基づいて生成します。 39 6. [サンプル抽出] および [サンプルイベント] をチェックして、不要な値やリストに表示したくない値がないかどう かを確認します。 不要な値がある場合は、値の隣にある [X] をクリックして、それを削除してください。欠落している値がある場合 は、それを [サンプルイベント] リストに追加してください。IFX はその 更を反映して、生成されたパターンを更 新します。正規表現をリセットした値を再追加するには、その隣にある [+] アイコンをクリックします。 7. 新しいフィールドを保存する前に、大きなデータセットに して正規表現をテストしたり、パターンを手動で編 集することができます。 [フィールドの抽出] ページで [テスト] をクリックすると、サーチビューに移動してサーチが実行されます。 ホスト、ソース、またはソースタイプの制限に基づいて、最初の 10,000 件の結果が返されます。 FIELDNAME に して Splunk が生成した regex を使った rex コマンドを使用して、フィールド値の任意の重 複値を削除します。 テストウィンドウで手動でサーチ式を編集した場合は、その 更を IFX ページにコピー/貼り付けする必要がありま す。 正規表現の使用方法を理解している方は、Splunk のパターン生成後に IFX ウィンドウの [編集] をクリックして、 パターンを編集することができます。 また、サーチまたは編集ウィンドウの抽出されたフィールドが「FIELDNAME」になっていることにお気づきで しょう。抽出を保存する際に入力した名前が設定されるため、この値を 更する必要はありません。 正規表現をテスト、編集したら、IFX ウィンドウに ります。 8. 式が正常に機能しているならば、[保存] をクリックします。 [フィールドの抽出の保存] ウィンドウが表示されます。 9. 抽出に名前 clientip を指定して、[保存] をクリックします。 Splunk では、フィールド名に英数字とアンダースコアのみを使用できます。 フィールド名に使用できる文字は、a-z、A-Z、0-9、、_ です。 40 フィールド名の先頭に、0-9 または _ を使用することはできません。(先頭のアンダースコアは、Splunk の内 部 数用に予約されています。) 重要：ユーザーが作成した抽出は $SPLUNK_HOME/etc/users に保管され、ユーザーが保有するロールの機能とし て、App と関連して利用できます。 Splunk 管理での [フィ ー ルドの抽出 ] ペ ー ジの使用 Splunk 管理の [フィールドの抽出] ページを使って、props.conf に追加したサーチ時のフィールド抽出を管理する ことができます。props.conf にサーチ時フィールド抽出を追加するには、3 種類の方法があります。以下の作業を 行えます。 話式フィールド抽出 (IFX) を使用して抽出を作成する。 を直接編集する。 [] ページで新しいフィールド抽出を追加する (以下を参照)。 props.conf [フィールドの抽出] ページでは、以下の作業を行えます。 自分が作成した、またはSplunk 環境内のすべての App に して自分が参照できる 限を持つ、サーチ時抽出を レビューする。 新しいサーチ時フィールド抽出を作成する。 フィールド抽出の 限を更新する。 話式フィールド抽出および [フィールドの抽出] ページを使って作成された フィールド抽出は、作成者が他のユーザーと共有しない限りその作成者のみが利用できます。 フィールドの抽出を削除する (App レベルの 限が許可しており、製品に同梱されているデフォルトの抽出で はない場合)。デフォルトのナレッジオブジェクトを削除することはできません。ナレッジオブジェクト削除 の詳細は、このマニュアルの「Splunk ナレッジの管理」を参照してください。 特定のサーチ時フィールド抽出に して「書き込み」 限がある場合、[フィールドの抽出] ページで以下の作業を行 えます。 インライントランザクションの場合、正規表現を更新する。 トランザクションを使用している場合に、transforms.conf または [フィールドの抽出] ページで定義された 名前付き抽出を追加、削除する。 注意：Splunk 管理では、インデックス時フィールド抽出を管理することはできません。インデックス時フィール ド抽出を 更することはお勧めできません。どうしても 更する必要がある場合は、props.conf または transforms.conf 設定ファイルを手動で編集してください。インデックス時フィールド抽出の設定の詳細は、 『Getting Data In Manual』の「Configure index-time field extractions」を参照してください。 [フィールドの抽出] ページに移動するには [管理] > [フィールド] > [フィールドの抽出] を選 します。 Splunk 管理でのサ ー チ時フィ ー ルド抽出のレビュ ー Splunk 管理の [フィールドの抽出] ページへのフィールド抽出の表示方法を理解するために、props.conf および transforms.conf ファイル内にフィールド抽出がどのように設定されているのかを理解することが役立ちます。 フィールドの抽出全体を props.conf に設定することができます。この場合、それらの設定は [フィールドの抽出] ページに「インライン」フィールド抽出として表示されます。一部のフィールド抽出には、「フィールド 換」と 呼ばれる transforms.conf のコンポーネントが含まれています。Splunk Web でこのようなフィールドの抽出のコ ンポーネントを作成/編集するには、[フィールド 換] ページを使用します。 [フィールド 換] ページの詳細は、「フィールド 換の管理」を参照してください。 props.conf および transforms.conf ファイルに直接フィールド抽出を設定する方法については、このマニュアルの 「サーチ時のフィールドの追加」を参照してください。 ［名前］ 列 [フィールドの抽出] ページの ［名前］ 列には、props.conf に指定されているフィールド抽出の総合的な名前 (また は「クラス」) が表示されます。props.conf でのフィールド抽出の形式を以下に示します。 <spec> : [EXTRACT-<class> | REPORT-<class>] <spec> には、以下の値を使用できます。 <sourcetype>、イベントのソースタイプ。 host::<host>、<host> はイベントのホストを表します。 はイベントのソースを表します。 source::<source>、<source> EXTRACT-<class> フィールド抽出は、props.conf に全体が定義された抽出です (transforms.conf 内の 換を参照しな 41 い)。これらは、IFX および特定のサーチコマンドで行われたフィールド抽出により、自動的に作成されま す。props.conf ファイルを直接更新して、追加することもできます。この種類の抽出は、常にフィールド抽出正 規表現と関連付けられます。[フィールドの抽出] ページで、この正規表現は ［抽出/ 換］ 列に表示されます。 フィールド抽出は、transforms.conf 内のフィールド 換スタンザを参照します。これは、その フィールド抽出正規表現が存在している場所です。[フィールドの抽出] ページで、参照されているフィールド 換ス タンザは ［抽出/ 換］ 列に表示されます。 REPORT-<class> 換に関する作業は、Splunk 管理の [フィールド 換] ページで行います。詳細は、このマニュアルの「Splunk 管理 の [フィールド 換] ページの使用」を参照してください。 ［タイプ］ 列 フィールド抽出には、インラインと transforms.conf の 2 種類のタイプが存在しています。 インライン抽出には、常に EXTRACT-<class> 設定があります。これらは全体が props.conf に定義され、外部 のフィールド 換は参照しません。 換を使用する抽出には、常に REPORT-<class> 名前設定があります。そのため、transforms.conf 内のフィー ルド 換が参照されます。Splunk 管理の [フィールド 換] ページを使って、直接 transforms.conf 内にフィー ルド 換を定義することができます。 ［抽出/ 換］ 列 ［抽出/ 換］ 列には、フィールド抽出タイプに じて異なる事項が表示されます。 インライン抽出タイプの場合、Splunk がフィールドの抽出に使用する正規表現式が表示されます。正規表現 内の名前付きグループ (複数の場合もある) は、どのようなフィールドを抽出するのかを示しています。 正規表現の構文と使用方法の概要については、Regular-Expressions.info を参照してください。正規表現をテ ストするには、サーチコマンドの rex を使用します。正規表現式を作成、テストするために役立つサード パーティ製ツールのリストも用意されています。 transform を使用する 換タイプの場合、props.conf 由でフィールド抽出にリンクされてい る、transforms.conf のフィールド 換スタンザ名が表示されます。同じソース、ソースタイプ、またはホス トに複数のフィールド抽出正規表現を適用したい場合は、フィールドの抽出に複数のフィールド 換を参照さ せることができます。これは、抽出するフィールドが、複数の異なるイベントパターンに登場するような場 合に必要になります。 たとえば、［式］ 列に「transform を使用」抽出の 2 つの値「 access-extractions」および「ip-extractions」が表 示されることがあります。これらは、たとえば props.conf に以下のように指定されています。 [access_combined] REPORT-access = access-extractions, ip-extractions この例で、access-extractions および ip-extractions は、transforms.conf 内のフィールド 換スタンザ名 です。Splunk 管理を使ったフィールド 換に関する作業については、[フィールド 換] ページに移動してくだ さい。 新しいフィ ー ルド抽出の追加 新しいフィールド抽出を追加するには、[フィールドの抽出] ページの上部にある [新規] ボタンをクリックします。 [新規追加] ページが表示されます。 props.conf 内でのフィールド抽出の設定方法を知っている方にとって、この作業は単純に感じられることでしょ う。 以下のすべてのフィールドが必要です。 1. フィールド抽出の [宛先 App] コンテキストを定義します。デフォルトでは、現在あなたがいる App コンテキス トになります。 2. フィールド抽出の名前を指定します。複数の単語を指定する場合、間はスペースの代わりにアンダースコアを使 用してください。props.conf で、これは EXTRACT または REPORT フィールド抽出タイプの <class> 値になり ます。注意： <class> の値は、フィールド名構文の制限 (下の「重要」を参照) に従う必要はありません。a-z、AZ、および 0-9 以外の文字を使用でき、またスペースも利用できます。また、<class> の値はキークリーニングに も従いません。 3. 抽出を適用するソースタイプ、ソース、またはホストを定義します。sourcetype、source、または host を選 し て、値を入力してください。これは、props.conf 内の <spec> の値にマップされます。 42 4. 抽出タイプを定義します。 [transform を使用] を選 した場合は、関与する 換を [抽出/ 換] フィールドにカンマで区切って入力します。 換は、[フィールド 換] ページで作成、更新できます。 [インライン] を選 した場合、[抽出/ 換] フィールドにフィールドの抽出に使用する正規表現式を入力しま す。正規表現の構文と使用方法の概要については、Regular-Expressions.info を参照してください。正規表現 をテストするには、サーチコマンドの rex を使用します。正規表現式を作成、テストするために役立つサー ドパーティ製ツールのリストも用意されています。 重要：正規表現で複数のグループを取得する場合は、英数字またはアンダースコアのみを使用したフィールド名を 指定する必要があります。 フィールド名に使用できる文字は、a-z、A-Z、0-9、、_ です。 フィールド名の先頭に、0-9 または _ を使用することはできません。先頭のアンダースコアは、Splunk の内 部 数用に予約されています。 国際文字は使用できません。 Splunk は、すべての抽出されたフィールド (デフォルトおよびカスタム設定による抽出フィールド) に以下の 「キークリーニング」ルールを適用します。 a-z、A-Z、および 0-9 以外のすべての文字は、アンダースコア (_) に置換されます。 先頭のアンダースコアと 0-9 は、すべて削除されます。 特定のフィールド抽出でこの動作を無効にするには、props.conf および transforms.conf の両方を手動で 更する 必要があります。詳細は、このマニュアルの「設定ファイルを使ったサーチ時フィールド抽出の作成と管理」を参 照してください。 注意：インラインフィールド抽出 (フィールド 換コンポーネントが不要なフィールド抽出) のキークリーニング は、props.conf スタンド内の抽出スタンザを編集しない限りオフにすることはできません。 例 - 新しいエラーコードフィールドの追加 ここでは、新しい err_code フィールドの抽出の定義方法について 明していきます。フィールドは、device_id= に 続けて括弧に まれた単語、およびコロンで終了するテキスト文字列で識別できます。このフィールドを testlog ソースタイプに関連するイベントから抽出する必要があります。 props.conf で、この抽出は以下のようになります。 [testlog] EXTRACT-errors = device_id=\[w+\](?<err_code>[^:]+) [新しいフィールド抽出の追加] ページを使った設定を以下に示します。 注意：この例の別バージョンがこのマニュアルの「サーチ時フィールド抽出の作成と管理」に記載されています。 その例では、props.conf ファイルを使ったフィールド抽出の設定方法を取り上げています。 既 存のフィ ー ルド抽出の更新 既存のフィールド抽出を編集するには、［名前］ 列の名前をクリックします。 43 フィールド抽出の詳細ページが表示されます。[抽出/ 換] フィールドでできる作業は、その抽出のタイプによって 異なります。 インライン抽出の場合、フィールド抽出に使用する正規表現式を編集できます。 1 つまたは複数の 換を使用するフィールド抽出の場合は、関与している 換を更新できます (複数指定する場 合はカンマで区切って入力)。 換は、[フィールド 換] ページで作成、更新できます。 上記のフィールド抽出は、3 つの 換 wel-message、wel-eq-kv、および wel-col-kv を使用しています。これらの 換 の設定を確認するには、[管理] > [フィールド] > [フィールド 換] に移動するか、または直接 transforms.conf を参 照します。 注意： [transform を使用] フィールドには、最低 1 つの transforms.conf フィールド抽出スタンザ名を指定する必 要があります。 フィ ー ルドの抽出 限の更新 インラインのフィールド抽出を作成する場合 (IFX やサーチコマンドで)、当初はその作成者のみが使用できます。 他のユーザーにも利用させる場合は、その 限を更新する必要があります。そのためには、[フィールドの抽出] ページ内の目的のフィールド抽出の [ 限] リンクを選 します。ナレッジオブジェクトの標準の 限管理用ページが 表示されます。 このページでは、フィールド抽出のロールベースの 限の設定、および特定の App のユーザーに使用させるか、ま たはすべての App のユーザーにグローバルに使用させるかを指定することができます。Splunk 管理を使った 限の 管理の詳細は、このマニュアルの「Splunk ナレッジの管理」を参照してください。 フィ ー ルド抽出の削除 [フィールドの抽出] ページでは、必要な 限があればフィールド抽出を削除することができます。デフォルトの フィールド抽出 (製品に用意されている抽出で App の default ディレクトリに保管) を削除することはできません。 削除するフィールド抽出の [削除] をクリックします。 注意：下流の依存関係があるオブジェクトの削除時には注意する必要があります。たとえば、フィールド抽出があ るサーチで使用されており、そのサーチが他の 5 種類の保存 みサーチ (その中の 2 つはダッシュボードパネルに利 用されている) が使用しているイベントタイプの基盤となっている場合、フィールド抽出を削除するとそれらのす べてのナレッジオブジェクトに 影響を与えてしまいます。ナレッジオブジェクト削除の詳細は、このマニュアル の「Splunk ナレッジの管理」を参照してください。 Splunk 管理での [フィ ー ルド 換 ] ペ ー ジの使用 [フィールド 換] ページでは、transforms.conf に存在しているサーチ時フィールド抽出のフィールド 換コンポー ネントを管理することができます。フィールド 換は、transforms.conf を直接 換して、または [フィールド 換] ページに追加することで作成できます。 注意：各フィールド 換には、最低 1 つのフィールド抽出コンポーネントが必要です。ただし、インラインの フィールド抽出には、フィールド 換コンポーネントは必要ありません。 [フィールド 換] ページでは、以下の作業を行えます。 自分が作成した、またはSplunk 環境内のすべての App に して自分が参照できる 限を持つ、フィールド 換を レビューする。 新しいフィールド 換を作成する。フィールド 換を使用する必要がある状況については、下の「[フィールド 換] ページを使用する場合」を参照してください。 44 フィールド 換の 限を更新する。[フィールド 換] ページで作成されたフィールド 換は、他のユーザーと共有 しない限り、当初は作成者のみが利用できます。フィールド 換の 限は、自分がそのフィールド 換を保有し ているか、またはロールが適切な 限を持っている場合にのみ更新できます。 フィールド 換を削除する (App レベルの 限が許可しており、製品に同梱されているデフォルトのフィールド 換ではない場合)。デフォルトのナレッジオブジェクトを削除することはできません。ナレッジオブジェクト 削除の詳細は、このマニュアルの「Splunk ナレッジの監督」を参照してください。 特定のフィールド 換に して「書き込み」 限がある場合、[フィールド 換] ページで以下の作業を行えます。 正規表現の更新および正規表現の適用先キーの 更。 フィールド 換フォーマットを定義または更新する。 [フィールド 換] ページに移動するには [管理] > [フィールド] > [フィールド 換] を選 します。 フィ ー ルド抽出のフィ ー ルド 換を設定する理由 大半のサーチ時フィールド抽出は props.conf (または Splunk 管理の [フィールドの抽出] ページ) で全体を定義する ことができますが、一部の高度なサーチ時フィールド抽出を使用する場合は、「フィールド 換」と呼ばれる transforms.conf コンポーネントが必要になります。このコンポーネントは、[フィールド 換] ページで定義、管理 することができます。 以下のような場合に、フィールド 換コンポーネントを持つサーチ時フィールド抽出を設定します。 複数のソース、ソースタイプ、またはホストにまたがって同じフィールド抽出正規表現を再利用する (複数 のフィールド抽出が参照する 1 つのフィールド 換を設定する)。異なるソース、ソースタイプ、およびホス トに するフィールドの抽出に同じ正規表現を使用している場合は、それを 換として設定することができま す。そうすることで、正規表現を更新する必要がある場合は、複数のフィールド抽出が使用しているような 場合でも、1 回の 更で作業が完了します。 同じソース、ソースタイプ、またはホストに して複数のフィールド抽出正規表現を適用する (同じフィール ド抽出に複数のフィールド 換を適用する)。これは、特定のソース/ソースタイプ/ホストから抽出するフィー ルドが、複数の異なるイベントパターンで登場するような場合に必要になります。 他のフィールドの値 (ソースキー) からフィールドを抽出する正規表現を使用する。たとえば、url フィール ドの値から文字列を取得して、それを新しいフィールドの値にします。 サーチ時フィールド 換を transforms.conf に直接設定することで、ほかにもさまざまな処理を行えます (区切り文 字ベースのフィールド抽出や複数値フィールドの抽出の設定など)。詳細は、このマニュアルの「設定ファイルを 使ったサーチ時フィールド抽出の作成と管理」を参照してください。 注意： すべてのインデックス時フィールド抽出は、1 つまたは複数のフィールド 換と組み合わされています。 Splunk 管理では、インデックス時のフィールド抽出を管理できません。ただし、props.conf および transforms.conf 設定ファイルを使用することは可能です。通常の環境下では、インデックス時のフィールド抽出 を 更することはお勧めできません。どうしても編集する必要がある場合は、先に『Getting Data In』マニュアルの 「Create custom fields at index-time」を参照してください。 Splunk 管理でのサ ー チ時フィ ー ルド 換のレビュ ー と更新 Splunk 管理の [フィールド 換] ページへのフィールド 換の表示方法を理解するために、props.conf および transforms.conf ファイル内にフィールド抽出がどのように設定されているのかを学習することが役立ちます。 transforms.conf 内の一般的なフィールド 換は、以下のようになっています。 [banner] REGEX = /js/(?<license_type>[^/]*)/(?<version>[^/]*)/login/(?<login>[^/]*) SOURCE_KEY = uri この 換は正規表現を uri フィールドの値と照合し、3 つのフィールドを 名前付きグループ license_type、version、login として抽出します。 props.conf では、この 換がソースの .../banner_access_log* と照合されます。 [source::.../banner_access_log*] REPORT-banner = banner この場合、正規表現は .../banner_access_log ソースのイベント内にある uri フィールドとのみ照合されます。 ただし、必要に じて他のソース、ソースタイプ、およびホストと照合することができます。このような処理は、 インラインのフィールド抽出 (props.conf に全体が設定されているフィールド抽出) では実現できません。 注意：デフォルトでは、 換は_raw の SOURCE_KEY の値と照合されます。この場合、そのイベント内のフィールドの 45 みではなく、イベント全体に して正規表現が適用されます。 ［名前］ 列 [フィールド 換] ページの ［名前］ 列には、ご自分の 限で参照できるサーチ時フィールド 換の名前が表示されま す。これらの名前は、transforms.conf 内の実際のフィールド 換スタンザ名です。上記の 換例の場合は、banner として表示されます。 換名をクリックすると、その 換に関する詳細情報が表示されます。 換の詳細のレビューと編集 フィールド 換の詳細ページでは、正規表現、キー、およびイベントフォーマットを表示、更新することができま す。このサブトピックの最初に 明した banner 換の詳細ページを以下に示します。 適切な 限があれば、正規表現、キー、およびイベントフォーマットを編集することができます。 換を複数のソー ス、ソースタイプ、またはホストに適用している場合、それを編集すると、props.conf および [フィールドの抽出] ページに定義されている、複数のフィールド抽出に影響する可能性があることに注意してください。 新しいフィ ー ルド 換の作成 新しいフィールド 換を作成するには： 1. [フィールド 換] ページに移動して、[新規] ボタンをクリックします。 2. 現在の App 用のフィールド 換ではない場合、その宛先 App を指定します。 3. フィールド 換の名前 を指定します。これは、transforms.conf 内の 換スタンザ名になります。この 換を保存す ると、[フィールド 換] ページの ［名前］ 列にこれが表示されます。(これは必須フィールドです。) 4. 換の正規表現を入力します。(これは必須フィールドです。) 5. 必要に じて、 換のキーを定義します。これは、transforms.conf 内の SOURCE_KEY オプションに しています。 デフォルトでは _raw が設定されています。この場合、正規表現がイベント全体に適用されます。正規表現を特定 のフィールドの値に適用する場合は、_raw を目的のフィールド名に 更してください。フィールド 換実行時に存在 しているフィールドのみを使用できます。 6. 必要に じて、イベントのフォーマットを指定します。これは、transforms.conf 内の FORMAT オプションに して います。正規表現が捕捉したグループを指定する場合は、$n を使用します。たとえば、作成した正規表現が 2 つ のグループを捕捉する場合、[フォーマット] には「$1::$2」のように設定します。ここで、最初のグループは フィールド名、2 番目のグループはフィールド値になります。または、[フォーマット] を「username::$1 userid::$2」のように指定します。この場合、正規表現は username および userid フィールドの値を抽出します。 [フォーマット] フィールドのデフォルトは、「< 換スタンザ名>::$1」になります。 正規表現の構文と使用法 正規表現の構文と使用方法の概要については、Regular-Expressions.info を参照してください。正規表現をテスト するには、サーチコマンドの rex を使用します。正規表現式を作成、テストするために役立つサードパーティ製 ツールのリストも用意されています。 重要：正規表現で複数のグループを取得する場合は、英数字とアンダースコアを使用したフィールド名を指定する 46 必要があります。 フィールド名に使用できる文字は、a-z、A-Z、0-9、、_ です。 フィールド名の先頭に、0-9 または _ を使用することはできません。先頭のアンダースコアは、Splunk の内 部 数用に予約されています。 国際文字は使用できません。 Splunk は、サーチ時に抽出されたすべてのフィールド (デフォルトおよびカスタム設定による抽出フィールド) に、以下の「キークリーニング」ルールを適用します。 1. a-z、A-Z、および 0-9 以外のすべての文字は、アンダースコア (_) に置換されます。 2. キークリーニングが有効になっている場合 (デフォルトで有効)、抽出されたフィールドから先頭のアンダースコ アまたは数字 (0-9) がすべて削除されます。 内のスタンザに CLEAN_KEYS=false を設定することで、特定のフィールド 換のキークリーニング を無効にすることができます。 transforms.conf 注意：インラインフィールド抽出 (フィールド 換コンポーネントが不要なフィールド抽出) のキークリーニングを オフにすることはできません。 例 - イベントからのフィールド名と する値の抽出 イベントのフォーマット属性と適切に設計された正規表現式を使って、一致する各イベントからフィールド名と する値の両方を抽出するフィールド 換を設定できます。 ここでは、Splunk に同梱されている 換を使った例を 明していきます。 フィールド 換には、イベントデータの角括弧内にあるフィールド名/値のペアを 索する正規表現式 があります。これは、イベント内のすべての一致するフィールド/値のペアを抽出するまで、この正規表現を適用 していきます。 bracket-space このトピックの最初の方で 明したように、フィールド 換は常にフィールド抽出と関連付けられます。Splunk 管理 の [フィールドの抽出] ページで、osx-asl:REPORT-asl 抽出に bracket-space フィールド 換が関連付けられている ことを確認できます。 フィ ー ルド 換 限の更新 デフォルトでフィールド 換の作成当初は、作成者のみがそれを利用できます。他のユーザーにもフィールド 換を 利用させる場合は、その 限を更新する必要があります。そのためには、[フィールド 換] ページ内の目的のフィー ルド 換の [ 限] リンクを選 します。ナレッジオブジェクトの標準の 限管理用ページが表示されます。 このページでは、フィールド 換のロールベースの 限の設定、および特定の App のユーザーに使用させるか、また はすべての App のユーザーにグローバルに使用させるかを指定することができます。Splunk 管理を使った 限の管 理の詳細は、このマニュアルの「Splunk ナレッジの管理」を参照してください。 フィ ー ルド 換の削除 [フィールド 換] ページでは、必要な 限があればフィールド 換を削除することができます。 削除するフィールド抽出の [削除] をクリックします。 注意：下流の依存関係があるナレッジオブジェクトの削除時には注意する必要があります。たとえば、フィールド 47 換で抽出されたフィールドが、あるサーチで使用されており、そのサーチが他の 5 種類の保存 みサーチ (その中 の 2 つはダッシュボードパネルに利用されている) が使用しているイベントタイプの基盤となっている場合、 フィールド 換を削除するとそれらのすべてのナレッジオブジェクトに 影響を与えてしまいます。ナレッジオブ ジェクト削除の詳細は、このマニュアルの「Splunk ナレッジの監督」を参照してください。 設定ファイルを使ったサ ー チ時フィ ー ルド抽出の 作成と管理 Splunk 管理を使ってサーチ時フィールド抽出を設定、管理することができますが、それが props.conf および transforms.conf のレベルでどのように扱われているのかを理解することが重要です。これらの設定ファイルは、 Splunk 管理の [フィールドの抽出] ページおよび [フィールド 換] ページでの作業時に読み書きされるファイルで す。 多くのナレッジ管理者、特に Splunk の利用 験が長い方は、設定ファイルを使ってカスタムフィールドの追加、編 集、レビューなどの管理作業を行う方が簡単と感じる場合が多いでしょう。 ここでは、以下の作業について 明していきます。 props.conf props.conf の編集による、基本的な「インライン」サーチ時フィールド抽出の設定。 と transforms.conf の編集による、より複 なサーチ時フィールド抽出の作成。 正規表現とフィ ー ルド名の構文 Splunk は正規表現正規表現を使って、イベントデータからフィールドを抽出します。 話式フィールド抽出 (IFX) を使用して、指定内容に じたフィールド抽出用正規表現を生成できますが、一度に 1 つのフィールドを抽出する 正規表現しか作成できません。 設定ファイルを使って手動でフィールドの抽出を設定する場合は、正規表現を自分で指定する必要がありますが、 必要に じてイベントから複数のフィールドを抽出する正規表現を作成することができます。 正規表現の構文と使用方法の概要については、Regular-Expressions.info を参照してください。正規表現をテスト するには、サーチコマンドの rex を使用します。正規表現式を作成、テストするために役立つサードパーティ製 ツールのリストも用意されています。 重要：正規表現で複数のグループを取得する場合は、英数字とアンダースコアを使用したフィールド名を指定する 必要があります。前述の「Splunk がフィールド名を作成する場合」を参照してください。 適切なフィールド名構文の使用 Splunk では、フィールド名に英数字とアンダースコアのみを使用できます。 フィールド名に使用できる文字は、a-z、A-Z、0-9、、_ です。 フィールド名の先頭に、0-9 または _ を使用することはできません。先頭のアンダースコアは、Splunk の内 部 数用に予約されています。 国際文字は使用できません。 Splunk は、サーチ時に抽出されたすべてのフィールド (デフォルトおよびカスタム設定による抽出フィールド) に、以下の「キークリーニング」ルールを適用します。 1. a-z、A-Z、および 0-9 以外のすべての文字は、アンダースコア (_) に置換されます。 2. キークリーニングが有効になっている場合 (デフォルトで有効)、抽出されたフィールドから先頭のアンダースコ アまたは数字 (0-9) がすべて削除されます。 特定のサーチ時フィールド抽出のキークリーニングを無効にすることができます。そうするには、その抽出を高度 な REPORT 抽出タイプとして設定し、参照フィールド 換スタンザに CLEAN_KEYS=false を設定します。REPORT 抽出設定の詳細は、後述の 明を参照してください。 注意：基本的な EXTRACT (props.conf のみ) フィールド抽出設定では、キークリーニングをオフにすることはで きません。 props.conf の編集による基本的なサ ー チ時フィ ー ルド抽出の作成 を編集して、基本的なサーチ時フィールド抽出 (transforms.conf 内のフィールド 換を参照しな い、props.conf 内に全体が定義されるフィールド抽出)を作成できます。props.conf は $SPLUNK_HOME/etc/system/local/、または $SPLUNK_HOME/etc/apps/ 内の独自のカスタムアプリケーションディレ クトリにあります。(カスタムデータを他のサーチサーバーに手 に転送したいような場合は、後者のディレクトリ props.conf 48 を使用することをお勧めします。) 注意： $SPLUNK_HOME/etc/system/default/ 内のファイルは編集しないでください。 設定ファイルの一般情報については、『管理マニュアル』の「設定ファイルについて」を参照してください。 props.conf を 使 っ た 基 本 的 な サ ー チ 時 フ ィ ー ル ド 抽 出 の 定 義 手 順 基本的なサーチ時フィールド抽出は、props.conf 内の EXTRACT 抽出設定を使用します。各 EXTRACT 抽出スタ ンザには、サーチ時に Splunk が 1 つまたは複数のフィールドの抽出に使用する正規表現、およびフィールドの抽 出方法を示すその他の属性が含まれています。 基本的なサーチ時フィールド抽出を作成するには、以下の手順に従ってください。 1. props.conf 内のすべての抽出設定は、特定のソース、ソースタイプ、またはホストに制限されています。ま ず、フィールドを抽出するイベントを提供するソースタイプ、ソース、またはホストを判別します。 注意：ホスト、ソース、およびソースタイプの詳細は、『Getting Data In』マニュアルの「About default fields (host, source, source type, and more)」を参照してください。 2. イベント内のフィールドを識別する正規表現を作成します。抽出した値のフィールド名を指定するには、名前付 きグループを使用します。前のセクションで 明しているフィールド名構文を使用してください。 3. EXTRACT フィールド抽出タイプ (次のセクションで 明) のフォーマットに従って、props.conf 内にホスト/ソー ス/ソースタイプと正規表現を指定したフィールド抽出スタンザを作成します。$SPLUNK_HOME/etc/system/local/ 内、またはカスタムアプリケーションディレクトリ $SPLUNK_HOME/etc/apps/ 内にある props.conf ファイルを編集 してください。 注意： $SPLUNK_HOME/etc/system/default/ 内のファイルは編集しないでください。 4. フィールド値が単語の一部である場合は、fields.conf にもエントリを追加する必要があります。下の例「サブ トークンからのフィールドの作成」を参照してください。 5. 更内容を有効にするために、Splunk を再起動します。 props.conf へ の EXTRACT フ ィ ー ル ド 抽 出 ス タ ン ザ の 追 加 props.conf に EXTRACTフィールド抽出スタンザを追加するには、以下のフォーマットに従ってください。 [<spec>] EXTRACT-<class> = [<regular_expression>|<regular_expression> in <source_field>] <spec> には、以下の値を使用できます。 <source type>、イベントのソースタイプ。 host::<host>、<host> はイベントのホストを表します。 はイベントのソースを表します。 rule::<rulename>、ここで <rulename> はソースタイプ分類ルールの一意の名前です。 delayedrule::<rulename>、ここで <rulename> は 延ソースタイプ分類ルールの一意の名前です。 source::<source>、<source> 注意： rule と delayedrule は、ソースに基づいて新しいソースタイプを生成する前の、最終手段としてのみ考慮 されます。 は、抽出するフィールド (キー) の名前空間を識別する一意のリテラル文字列です。 注意： <class> の値は、フィールド名構文の制限 (前述) に従う必要はありません。a-z、A-Z、および 0-9 以外の文字を使用でき、またスペースも利用できます。<class> の値は、キークリーニングには従 いません。 名前付きグループを使用するには <regular_expression> が必要です。各グループが、異なる抽出フィールド を表します。<regular_expression> がイベントに一致すると、名前付きグループとその値がイベントに追加 されます。 正規表現を特定のフィールドの値と照合する場合は、<regular_expression> in <source_field> を使用しま す。それ以外の場合は、_raw に して照合されます (すべての raw イベントデータ)。 注意： <src_field> はフィールド名なので、フィールド名構文に従う必要があります。英数字 (a-z、AZ、および 0-9) のみを使用できます。 正規表現を in <string> で終了する必要がある場合 (ここで <string> はフィールド名ではない)、<string> がフィールド名と照合されないように、[i]n <string> で正規表現を終了するように 更してください。 <class> EXTRACT フィールド抽出タイプの優先ルール： 各フィールド抽出に して、Splunk は優先度がもっとも高い設定スタンザの設定を使用します。 複数のカテゴリの一致する [<spec>] スタンザがある場合、[host::<host>] 設定が [<sourcetype>] 設定に優 49 先します。 設定は、[host::<host>] と [<sourcetype>] の両方の設定に優先します。 同 に、<spec> に して ../local/ に特定のフィールド抽出が指定されている場合、それが ../default/ のクラス に優先します。 [source::<source>] 他にも [<spec>] スタンザの優先順位が存在しています。詳細は、props.conf.spec を参照してください。 注意：Splunk がインデックス時に抽出するデフォルトのフィールドセットの設定手順とは違い、サーチ時フィー ルド抽出中は何もインデックスに書き込まれないため、transforms.conf には DEST_KEY は必要ありません。サー チ時に抽出されるフィールドは、インデックス中にキーとしては保持されません。 サーチ時フィールド抽出の実行時、Splunk は優先ルールに従って処理を行います。まずインラインのフィールド 抽出 (EXTRACT-<class>) が実施され、次にツールバー 換を参照するフィールド抽出 (REPORT-<class>) が行われま す。 サ ー チ 時 デ ー タ の KV_MODE の 設 定 属性を使って、データのフィールド/値の抽出モードを指定できます。KV_MODE は EXTRACT または スタンザに追加できます。フォーマットを以下に示します。 KV_MODE REPORT KV_MODE = [none|auto|multi|json|xml] none：スタンザ名が示すソース、ソースタイプ、またはホストのフィールド抽出を無効にします。この設定 を使って、作成した他の正規表現が、特定のソース、ソースタイプ、またはホストのフィールド/値の自動抽 出により優先されないようにすることができます。また、この設定を使って共通の必須ではないフィールド の抽出を無効にすることにより、サーチのパフォーマンスを向上することができます。このトピックの最後 には、異なる環境下でフィールド抽出を無効にする例が記載されています。 auto：フィールド/値のペアを抽出して、それらを等号で区切ります。フィールド抽出スタンザにこの属性を 指定していない場合は、これがデフォルト値になります。 auto_escaped：フィールド/値のペアを抽出して、それらを等号で区切ります。また、この設定では引用符で まれた値内の「\"」と「\\」が、エスケープされた文字列として処理されます。例： field="value with \"nested\" quotes". multi：表形式のイベントからフィールド値を抽出する、multikv コマンドを起動します。 xml：フィールド抽出スタンザを使って XML データからフィールドを抽出する場合は、この設定を使用しま す。 json：フィールド抽出スタンザを使って JSON データからフィールドを抽出する場合は、この設定を使用し ます。 xml および json モードを、指定したフォーマット (XML または JSON) 以外のデータに使用すると、フィー ルドは抽出されません。 インライン (props.conf のみ ) サ ー チ時フィ ー ルド抽出の例 ここには、props.conf のみを使った、いくつかのサーチ時フィールド抽出の例を記載しています。 新しいエラーコードフィールドの追加 この例では、props.conf にフィールド抽出を設定することで、新しいフィールド「error code」を作成する方法を 表しています。フィールドは、device_id= に続けて括弧に まれた単語、およびコロンで終了するテキスト文字列 で識別できます。このフィールドを testlog ソースタイプに関連するイベントから抽出する必要があります。 props.conf に以下の項目を追加します。 [testlog] EXTRACT-errors = device_id=\[w+\](?<err_code>[^:]+) 1 つの正規表現を使った複数のフィールドの抽出 これは、5 つの個別のフィールドを抽出する例です。次にこれらのフィールドとイベントタイプを使って、ポート フラッピングイベントを 索、レポートします。 フィールドを抽出するイベントデータの例を以下に示します。 #%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet9/16, changed state to down 抽出するための props.conf のスタンザは以下のようになります。 [syslog] EXTRACT-port_flapping = Interface\s(?<interface>(?<media>[^\d]+)(?<slot>\d+)\/(?<port>\d+))\,\schanged 50 \sstate\sto\s(?<port_status>up|down) 5 つの個別のフィールドは、名前付きグループ interface、media、slot、port、および port_status として抽出され ることに注意してください。 以下の 2 つのステップはフィールド抽出には必要ありません。これらのステップは、抽出したフィールドを使っ た、ポートフラッピングイベントの 索と、それのレポート方法を表しています。 eventtypes.conf に、タグを使って一連のイベントタイプを定義します。 [cisco_ios_port_down] search = "changed state to down" [cisco_ios_port_up] search = "changed state to up" 最後に savedsearches.conf に、上記の事項を合わせてポートフラッピングの 索と結果のレポートを作成する、保 存 みサーチを作成します。 [port flapping] search = eventtype=cisco_ios_port_down OR eventtype=cisco_ios_port_up starthoursago=3 | stats count by interface,host,port_status | sort -count サブトークンからのフィールドの作成 大きなトークンの一部となるサブトークンのフィールド値を抽出する場合、問題が発生する可能性があります。 トークンは、インデックス作成前のイベント処理が行われた、イベントデータのチャンクです。イベント処理時に イベントはセグメントに分割され、トークンが作成されます。作成された各セグメントがトークンになります。 トークンは、1 つの完全な単語または数字より細かくはなりません。たとえば、イベント内に foo123 と言う単語 がある場合を考えてみましょう。イベントの処理が行われてインデックスが作成されると、これがトークンとな り、あるフィールドの値となります。しかし、抽出でフィールドの値として foo を取得する場合、これはサブトー クンを抽出することになります。ここで問題となるのは、インデックスに存在しているのが foo123 で foo ではな いことです。そのため、正常にサーチ結果が抽出されるように見えても、そのサブトークンに してサーチを実行 すると、ほとんど結果は得られません。 トークンは文字列内の個別の単語よりも細かくはなりません。そこで、サブトークン (単語の一部) のフィールド 抽出を実行しても、それがインデックスには存在しない (それが所属しているより大きな単語のみがインデックス にある) ため、問題が発生する可能性があります。 フィールド値が細かなトークンの一部である場合は、上記の 明に従って props.conf を設定する必要があります。 次に、以下のエントリを fields.conf に追加します。 [<fieldname>] INDEXED = False INDEXED_VALUE = False <fieldname> には、フィールド名を指定します。 たとえば、名前が「url」のフィールドを設定した場合は、[url] のように指定します。 INDEXED と INDEXED_VALUE に false を設定します。 こう指定することで、サーチしているのがインデックス内のトークンではないことを Splunk に知らせ ます。 注意：リリース 4.3 以降では、インデックスが作成されていない (トークン化されていない) デフォルトのフィール ド (host、source、sourcetype、timestamp など) の値からフィールドの値を抽出する場合、fields.conf にこのエ ントリを追加する必要がなくなりました。 イベントデータのトークン化の詳細は、『Getting Data In』マニュアルの「About segmentation」を参照してくだ さい。 フィ ー ルド 換を使った高度なサ ー チ時フィ ー ルド抽出の作成 大半のサーチ時フィールド抽出は props.conf に定義できますが、一部の高度なサーチ時フィールド抽出で は、フィールド 換と呼ばれる追加コンポーネントを参照します。ここでは、transforms.conf へのフィールド 換 の設定方法を 明していきます。 フィールド 換には、フィールド抽出正規表現と、抽出フィールドの 換方法を示すその他の属性が含まれていま す。フィールド 換は、常に props.conf 内のフィールド抽出スタンザと一緒に作成されます。単独で作成すること はできません。 以下のような場合に、サーチ時フィールド抽出にフィールド 換コンポーネントが必要になります。 51 以下のような場合に、サーチ時フィールド抽出にフィールド 換コンポーネントが必要になります。 複数のソース、ソースタイプ、またはホストにまたがって同じフィールド抽出正規表現を再利用する (複数 のフィールド抽出用に 1 つのフィールド 換を設定する)。異なるソース、ソースタイプ、およびホストに す るフィールドの抽出に同じ正規表現を使用している場合は、それを 換として設定することができます。そう することで、正規表現を更新する必要がある場合は、複数のフィールド抽出が使用しているような場合で も、1 回の 更で作業が完了します。 同じソース、ソースタイプ、またはホストに して複数のフィールド抽出正規表現を適用する (同じフィール ド抽出に複数のフィールド 換を適用する)。これは、特定のソース/ソースタイプ/ホストから抽出するフィー ルドが、複数の異なるイベントパターンで登場するような場合に必要になります。 区切り文字ベースのフィールド抽出を設定する。区切り文字ベースの抽出は、カンマ、コロン、ハイフン、 改行、タブ、スペースなどの区切り文字で区切られたフィールド/値のペア (または単なるフィールド値) がイ ベントデータに存在している場合に役立ちます。 複数値フィールドから設定を抽出する。この場合、イベントデータ内で見つかったフィールドに、追加の フィールド値が追加されます。 数字またはアンダースコアで始まる名前を持つフィールドを抽出する。通常のキークリーニングでは、 フィールド名の先頭にある数字とアンダースコアが削除されますが、必要に じてこの機能をオフにするよう にフィールド 換を設定することができます。 フィールド 換には、以下のような設定を行うこともできます。 属性を使って、他のフィールド (raw_ 以外) の値からフィールドを抽出する。 複数のフィールドを抽出するまたはフィールド名とフィールド値の両方を抽出する場合に、FORMAT 属性を 使って抽出されたフィールドのフォーマットを管理する。 SOURCE_KEY これらの両方の設定を、正規表現に直接設定することができます。方法の詳細は、後述する「フィールド 換の定 義」を参照してください。 注意：一連の正規表現抽出を単一のフィールド値に連結する場合は、FORMAT 属性を使用します。ただし、イン デックス時抽出として設定した場合にのみ使用することができます。たとえば、イベントデータ内に 192(x)0(y)2(z)1 のような文字列が存在する場合、それをインデックス時に ip address フィールド値とし て、192.0.2.1 のフォーマットで抽出することができます。詳細は、『Getting Data In Manual』の「Configure index-time field extractions」を参照してください。ただし、インデックス作成されたフィールドセットに大幅な 更 を加えることはお勧めできません。 更する必要がある場合でも慎重に作業を行ってください。 フィールド 換を参照するカスタムサーチ時フィールド抽出の定義手順 高度なサーチ時フィールド抽出は、props.conf 内の REPORT 抽出設定を使用します。各 REPORT 抽出スタンザ が、transforms.conf に個別に定義されているフィールド 換を参照します。フィールド 換には、サーチ時に Splunk がフィールドの抽出に使用する正規表現、およびそれらのフィールド抽出の 換方法を示す他の属性が含ま れます。 高度なサーチ時フィールド抽出を作成するには、以下の手順に従ってください。 1. props.conf 内のすべての抽出設定は、特定のソース、ソースタイプ、またはホストに制限されています。ま ず、フィールドを抽出するイベントを提供するソースタイプ、ソース、またはホストを判別します。(まだ props.conf は更新しないでください。) 注意：ホスト、ソース、およびソースタイプの詳細は、『Getting Data In』マニュアルの「About default fields (host, source, source type, and more)」を参照してください。 2. イベント内のフィールドを識別する正規表現を作成します。抽出した値のフィールド名を指定するには、名前付 きグループを使用します。前のセクションで 明しているフィールド名構文を使用してください。 注意：イベントにフィールド/値のペアまたは単にフィールド値のリストがある場合、正規表現を使わない区切り 文字ベースのフィールド抽出を作成できます。詳細は後述する DELIMS 属性の 明を参照してください。 3. transforms.conf 内に、この正規表現 (または区切り文字設定) を利用するフィールド 換を作成します。この 換 には、ソースキーやイベント値のフォーマットを定義することもできます。 内、またはカスタムアプリケーションディレクトリ $SPLUNK_HOME/etc/apps/ 内 にある transforms.conf ファイルを編集してください。 $SPLUNK_HOME/etc/system/local/ 注意： $SPLUNK_HOME/etc/system/default/ 内のファイルは編集しないでください。 4. REPORT フィールド抽出タイプのフォーマット (後述) に従って、props.conf 内にステップ 1 で判別したホス ト、ソース、またはソースタイプを使用するフィールド抽出スタンザを作成します。必要に じて、同じフィール ド 換を参照する他のホスト、ソース、ソースタイプ用のフィールド抽出スタンザを作成することもできます。 内、またはカスタムアプリケーションディレクトリ $SPLUNK_HOME/etc/apps/ 内 にある props.conf ファイルを編集してください。 $SPLUNK_HOME/etc/system/local/ 52 注意： $SPLUNK_HOME/etc/system/default/ 内のファイルは編集しないでください。 5. 更内容を有効にするために、Splunk を再起動します。 まず、フィールド 換を定義します transforms.conf にサーチ時フィールド 換を定義する場合は、以下のフォーマットに従ってください。 [<unique_transform_stanza_name>] REGEX = <regular expression> FORMAT = <string> SOURCE_KEY = <string> DELIMS = <quoted string list> FIELDS = <quoted string list> MV_ADD = [true|false] CLEAN_KEYS = [true|false] KEEP_EMPTY_VALS = [true|false] CAN_OPTIMIZE = [true|false] すべてのサーチ時 換に、<unique_transform_stanza_name> が必要です。注意： <unique_transform_stanza_name> の値は、フィールド名構文の制限 (前述) に従う必要はありません。a-z、 A-Z、および 0-9 以外の文字を使用でき、またスペースも利用できます。これらはキークリーニングの影響 を受けません。 REGEX は、データからフィールドを抽出するための正規表現です。区切り文字ベースのトランザクションを 設定する場合を除き、すべてのサーチ時フィールド 換に必要です。区切り文字ベースの場合は、DELIMS 属性 を使用します (後述する DELIMS 属性の 明を参照)。 デフォルトは空文字列です。 REGEX および FORMAT 属性。 REGEX の名前付きグループは、直接フィールドに抽出されます。単純なフィールド抽出の場合 は、FORMAT を指定する必要はありません。 REGEX でフィールド名と する値の両方を抽出する場合、以下の特殊グループを使って FORMAT のマッピ ング指定をスキップすることができます。 <_KEY_><string>, <_VAL_><string>. たとえば、以下の事項は同じ意味を持っています。 FORMAT の使用： REGEX = ([a-z]+)=([a-z]+) FORMAT = $1::$2 FORMAT を不使用： REGEX = (?<_KEY_1>[a-z]+)=(?<_VAL_1>[a-z]+) どちらの場合でも、イベントのソーステキストに正規表現が繰り返し適用されて、一致するすべてのフィー ルド/値のペアが抽出されます。 の指定はオプションです。これは、抽出するフィールド/値のペアのフォーマットを指定するために使 用します。単純な名前付きグループを持つ REGEX の場合、FORMAT を指定する必要はありません。 サーチ時抽出の場合、FORMAT のパターンは以下のようになります。 FORMAT FORMAT = <field-name>::<field-value>(<field-name>::<field-value>)* ここで： field-name = [<string>|$<extracting-group-number>] field-value = [<string>|$<extracting-group-number>] サーチ時 FORMAT の使用例： 1. FORMAT = firstfield::$1 secondfield::$2 thirdfield::other-value 2. FORMAT = $1::$2 に 数フィールド名を設定した場合 (上記の例 2 のように、フィールド名を表す $1 など)、ソースイベ ントテキストに して正規表現が繰り返し適用され、一致するフィールド/値のペアがすべて抽出されます。 注意：サーチ時に FORMAT を使って連結フィールドを作成することはできません。この機能は、イン デックス時のフィールド 換でのみ利用できます。 FORMAT のデフォルトは空文字列です。 FORMAT の指定はオプションです。これは、他のフィールド値から 1 つまたは複数の値を抽出するために 使用します。このフィールド抽出の実行時に利用できる、任意のフィールドを使用できます。 SOURCE_KEY 53 を設定する場合、 換の REGEX を適用するフィールドを指定します。 デフォルトでは、SOURCE_KEY には _raw が設定されます。この場合、すべてのイベントの raw (未処理 の) テキストに適用されます。 SOURCE_KEY の指定はオプションです。フィールド値またはフィールド/値のペアが、カンマ、コロン、スペース、 タブ、改行などで区切られている場合に、区切り文字ベースのフィールド抽出を使用するには、REGEX の代 わりにこれを使用します。 区切り文字は " " で む必要があります。必要に じて円記号 (バックスラッシュ) を使って、二重引用符 をエスケープ処理することができます (\")。 重要：値にエスケープ処理が行われていない二重引用符が含まれている場合 (例："foo"bar") は、 DELIMS ではなく REGEX を使用することをお勧めします。 区切り文字列内の各文字が、区切り文字として使用され、イベントが分割されます。 イベントに完全に区切り文字で区切られたフィールド/値のペアが含まれている場合は、DELIMS に して 2 つのセットの引用符で んだ区切り文字を指定します。最初のセットの引用符で んだ区切り文字は、 フィールド/値のペアを区切ります。2 番目のセットは、フィールド名とそれに する値を区切ります。 イベントに、区切り文字で区切られた値のみが含まれている場合 (フィールド名がない) は、引用符で んだ区切り文字の単一セットを指定して、各値を区切ります。次に FIELDS 属性を使って、フィールド 名を抽出された値に適用します (後述する FIELDS を参照)。代わりに、Splunk は偶数のトークンを フィールド名として、奇数のトークンをフィールド値として読み取ります。 Splunk は、フィールド名のリストを指定しない限り、連続する区切り文字を処理します。 デフォルトは空文字列です。 フィールド/値のペアが「|」記号で区切られ、フィールド名と する値は「=」記号で区切られているイ ベントに適用する、DELIMS の使用例を以下に示します。 DELIMS [pipe_eq] DELIMS = "|", "=" 区切り文字のフィールド抽出を実行する際に、FIELDS と DELIMS を一緒に使用していますが、フィールド値 のみを抽出しています。値が抽出された順序によるリスト形式で、抽出したフィールド値に するフィールド 名を指定するには、FIELDS を使用します。 注意：フィールド名にスペースまたはカンマが含まれている場合は、それを引用符で む必要がありま す (エスケープ処理するには \ を使用します)。 デフォルトは空文字列です。 イベント内に 3 つのフィールド値が登場する、区切り文字ベースの抽出例を以下に示します。これら のフィールドは、カンマとスペースで区切られています。 [commalist] DELIMS = ", " FIELDS = field1, field2, field3 の指定はオプションです。同じフィールドが異なる値で複数回登場するイベントで、それらのフィー ルド値を保持したい場合などに使用します。 MV_ADD = true の場合、イベント内に異なる値で複数回登場するフィールドが、複数値フィールド (フィールド名は 1 つ、「=」記号に続けてフィールドの複数の値が登場) に 換されます。 MV_ADD=false の場合、フィールドに してイベント内で最初に見つかった値が保持され、同じイベント 内でそのフィールドに して見つかった残りの値は破棄されます。 デフォルトは false です。 MV_ADD の指定はオプションです。これは、システムがキーから先頭のアンダースコアまたは 0-9 の数字 を除去するかどうかを示します (詳細は前述の「適切なフィールド名構文の使用」を参照)。「キークリーニ ング」とは、フィールド名内の英数字 (a-z、A-Z、および 0-9) 以外の文字をアンダースコアに置換し、また 先頭のアンダースコアと 0-9 文字をフィールド名から削除する処理です。 フィールド名をそのまま保持する (先頭のアンダースコアや 0-9 文字を削除しない) 場合は、 換に CLEAN_KEYS = false を追加してください。 デフォルトでは、 換の CLEAN_KEYS には常に true が設定されます。 CLEAN_KEYS の指定はオプションです。値が空文字列の場合に、フィールド/値のペアを保持するかどう かを示します。 このオプションは、Splunk の autokv 抽出 (自動フィールド抽出) 処理で生成されたフィールド/値のペ アには適用されません。Autokv は、空文字列のフィールド/値のペアを無視します。 デフォルトは false です。 KEEP_EMPTY_VALS の指定はオプションです。Splunk が抽出を最適化できるかどうか (抽出を無効化できるかどう か) を示します。 フィールドの 出を無効にするサーチモード設定でサーチを実行するような場合などに、これを使用し ます。これにより、Splunk は常に特定のフィールドを 出します。 抽出で識別されたすべてのフィールドが、サーチの評価に不要だと判断できた場合にのみ、抽出が無 効化されます。 注意：この属性に false が設定されることはほとんどありません。 デフォルトは true です。 CAN_OPTIMIZE 54 次に、フィールド抽出と関連するフィールド 換を設定します フィールド 換に関連付けるサーチ時フィールド抽出を props.conf に設定する場合は、REPORT フィールド抽出クラ スを使用します。以下のフォーマットに従ってください。 単一のフィールド抽出に複数のフィールド 換スタンザを関連付ける場合は、最初の <unique_transform_stanza_name> の後にカンマで区切って指定します。(詳細は、このトピックの後半にある例を 参照してください。) [<spec>] REPORT-<class> = <unique_transform_stanza_name1>, <unique_transform_stanza_name2>,... <spec> には、以下の値を使用できます。 <sourcetype>、イベントのソースタイプ。 host::<host>、<host> はイベントのホストを表します。 はイベントのソースを表します。 <class> は、抽出するフィールド (キー) の名前空間を識別する一意のリテラル文字列です。注意： <class> の値は、フィールド名構文の制限 (前述) に従う必要はありません。a-z、A-Z、および 0-9 以外の文字を使用 でき、またスペースも利用できます。<class> の値は、キークリーニングには従いません。 <unique_transform_stanza_name> は、transforms.conf からのフィールド 換スタンザ名です。 source::<source>、<source> REPORT フィールド抽出クラスの優先ルール： 各クラスに して、Splunk は優先度がもっとも高い設定ブロックの設定を使用します。 source および sourcetype に して特定のクラスが指定されている場合、source のクラスが優先されま す。 同 に、<spec> に して ../local/ に特定のクラスが指定されている場合、それが ../default/ のクラスに 優先します。 特定の順序で実行する必要がある一連の 換があり、それらが同じホスト、ソース、またはソースタイプに所属し ている場合、それらを同じ props.conf のスタンザ内にカンマ区切り形式のリストとして指定することができま す。Splunk は指定された順序に処理を行います。たとえば、以下のように指定すると、まず [yellow] フィールド 換が適用され、次に [blue] が、次に [red] が適用されます。 [source::color_logs] REPORT-colorchange = yellow, blue, red 実行順序を 更する必要がある場合は、リスト内の項目の指定順序を 更します。 フィ ー ルド 換を使ったカスタムサ ー チ時フィ ー ルド抽出の例 これらの例は、transforms.conf 内に 1 つまたは複数のフィールド 換スタンザを設定し、次に props.conf 内の フィールド抽出スタンザでそれらを参照する必要がある、カスタムフィールド抽出の使用事例を表しています。 複数のフィールド 換を利用するフィールド抽出の設定 このサーチ時フィールド 換設定例では、以下の方法について見ていきます。 イベントのさまざまなフィールド名/値のペアを取得する 換を作成する。 複数のフィールド 換を参照するフィールド抽出を作成する 複数のフィールド名/値のペアが含まれているログがある場合を考えてみましょう。イベントによってフィールド は異なりますが、ペアは常に 2 種類のいずれかの形式で登場します。 ログにはしばしば以下のようなフォーマットが登場します。 [fieldName1=fieldValue1] [fieldName2=fieldValue2] ただし、より複 な複数の名前/値のペアのリストとして、以下のような形式で記 されている場合もあります。 [headerName=fieldName1] [headerValue=fieldValue1], [headerName=fieldName2] [headerValue=fieldValue2] リスト項目はカンマで区切られており、各 fieldName は する fieldValue と照合されることに注意してください。 この 2 番目の場合でも、サーチ結果が以下のようになるように、フィールド名と値を取得したいと考えています。 fieldName1=fieldValue1 fieldName2=fieldValue2 (以降も同 ) 55 より明確になるように、ここでは上記の両方のフォーマットを持つ HTTP リクエストイベントの例を使用しま す。 [method=GET] [IP=10.1.1.1] [headerName=Host] [headerValue=www.example.com], [headerName=User-Agent] [headerValue=Mozilla], [headerName=Connection] [headerValue=close] [byteCount=255] イベントから以下のフィールド/値のペアを取得する、単一のフィールド抽出を作成したいと考えています。 method=GET IP=10.1.1.1 Host=www.example.com User-Agent=Mozilla Connection=close byteCount=255 解決策 両方のフォーマットのフィールド/値のペアを効率的かつ高信頼に取得するために、各フォーマットに して最適化 された 2 つの異なる正規表現を作成します。片方の正規表現は、最初のフォーマットのイベントを識別して、一致 するすべてのフィールド/値のペアを取得します。もう一方の正規表現は、別のフォーマットのイベントを識別し て、それらのイベントのフィールド/値のペアを取得します。 次に、transforms.conf 内に各正規表現に した、2 つの独自の 換を作成します。その後、props.conf 内の する フィールド抽出スタンザで、両方を統合します。 transforms.conf に追加する最初の 換は、一般的な [fieldName1=fieldValue1] [fieldName2=fieldValue2] を収集 します。 [myplaintransform] REGEX=\[(?!(?:headerName|headerValue))([^\s\=]+)\=([^\]]+)\] FORMAT=$1::$2 2 番目の 換 (同 に transforms.conf に追加) は、やや複 な [headerName=fieldName1] [headerValue=fieldValue1], [headerName=fieldName2] [headerValue=fieldValue2] を収集します。 [mytransform] REGEX= \[headerName\=(\w+)\],\s\[headerValue=([^\]]+)\] FORMAT= $1::$2 どちらの 換も <fieldName>::<fieldValue> FORMAT を使って、イベント内の各フィールド名と する値を照合しま す。この FORMAT の設定により、すべての一致するフィールド/値のペアが抽出されるまで、正規表現によるイベ ントの照合が 続されます。 最後に、props.conf 内に作成する以下のフィールド抽出スタンザで、両方のフィールド 換を参照します。 [mysourcetype] KV_MODE=none REPORT-a = mytransform, myplaintransform 複数のフィールド 換を使用するだけではなく、フィールド抽出スタンザには KV_MODE=none も設定されていること に注意してください。これにより、識別されたソースタイプに するフィールド/値の抽出が無効化されます (手動で 定義された抽出は 続)。この設定により、自動フィールド抽出がこれらの新しい正規表現に優先されることを防止 でき、またサーチパフォーマンスの向上にも役立ちます。(キー/値の抽出の、無効化の詳細については後述しま す。) 区切り文字ベースのフィールド抽出の設定 フィールド 換で DELIMS 属性を使用して、フィールド値またはフィールド/値のペアがカンマ、コロン、タブ、ス ペースなどの区切り文字で区切られているイベントの、フィールド抽出を設定することができます。 たとえば、異なるフィールド/値のペアが個別の行に配置され、各ペアがコロンとタブで区切られている、複数行 イベントを考えてみましょう。イベントの例を以下に示します。 ComponentId: Application Server ProcessId: 5316 ThreadId: 00000000 ThreadName: P=901265:O=0:CT SourceId: com.ibm.ws.runtime.WsServerImpl ClassName: MethodName: Manufacturer: IBM Product: WebSphere 56 Version: Platform 7.0.0.7 [BASE 7.0.0.7 cf070942.55] ServerName: sfeserv36Node01Cell\sfeserv36Node01\server1 TimeStamp: 2010-04-27 09:15:57.671000000 UnitOfWork: Severity: 3 Category: AUDIT PrimaryMessage: WSVR0001I: Server server1 open for e-business ExtendedMessage: 内に、これらのすべてのフィールドを処理する、長くて冗長なサーチ時フィールド抽出スタンザを設 定することができます。 props.conf [activityLog] LINE_BREAKER = [-]{8,}([\r\n]+) SHOULD_LINEMERGE = false EXTRACT-ComponentId = ComponentId:\t(?.*) EXTRACT-ProcessId = ProcessId:\t(?.*) EXTRACT-ThreadId = ThreadId:\t(?.*) EXTRACT-ThreadName = ThreadName:\t(?.*) EXTRACT-SourceId = SourceId:\t(?.*) EXTRACT-ClassName = ClassName:\t(?.*) EXTRACT-MethodName = MethodName:\t(?.*) EXTRACT-Manufacturer = Manufacturer:\t(?.*) EXTRACT-Product = Product:\t(?.*) EXTRACT-Version = Version:\t(?.*) EXTRACT-ServerName = ServerName:\t(?.*) EXTRACT-TimeStamp = TimeStamp:\t(?.*) EXTRACT-UnitOfWork = UnitOfWork:\t(?.*) EXTRACT-Severity = Severity:\t(?.*) EXTRACT-Category = Category:\t(?.*) EXTRACT-PrimaryMessage = PrimaryMessage:\t(?.*) EXTRACT-ExtendedMessage = ExtendedMessage:\t(?.*) ただ、このような設定は実用的ではありません。これらの EXTRACT 行を使わない、もっとうまいやり方はないで しょうか？もちろん、存在しています！ transforms.conf に以下のスタンザを設定してください。 [activity_report] DELIMS = "\n", ":\t" これは、イベント内のフィールド/値のペアが個別の行に存在しており ("\n")、次に各行のフィールド名とフィー ルド値がコロンとタブで区切られていること (":\t") を記述しています。 この設定を完成するには、props.conf のスタンザにある上記の冗長な設定を、以下のように書き直します。 [activitylog] LINE_BREAKER = [-]{8,}([\r\n]+) SHOULD_LINEMERGE = false REPORT-activity = activity_report これら 2 つの簡単な設定で、前と同じセットのフィールドを抽出できます。ただし、こちらの方がエラーが発生す る可能性も少なく、より柔軟性に優れています。 複数値フィールドを持つイベントの処理 あるイベント内に同じフィールドが複数回登場し、 回別の値を保有しているような場合に、MV_ADD 属性を使っ て、フィールドを抽出することができます。通常 Splunk では、イベント内の最初のフィールド値のみが抽出さ れ。残りの値は破棄されます。ただし、transforms.conf で MV_ADD に true を設定すると、フィールドが複数値 フィールドのように処理されて、イベント内の各一意のフィールド/値のペアが抽出されます。 以下のような一連のイベントがある場合を考えてみましょう。 event1.epochtime=1282182111 type=type1 value=value1 type=type3 value=value3 event2.epochtime=1282182111 type=type2 value=value4 type=type3 value=value5 type=type4 value=value6 各イベント内に type および value フィールドが複数回登場しているのがお分かりでしょうか？ここで は、type=type3 のサーチを実行して、これらの両方のイベントを返します。また、5 を返したイベントの count(type) レポートを実行します。 そのためには、これらのイベントの type の複数値抽出を作成します。そのための、transforms.conf と props.conf ファイルの設定方法を 明していきます。 まず、transforms.conf を設定します。 57 [mv-type] REGEX = type=(?<type>\s+) MV_ADD = true 次に、props.conf で、ソースタイプまたはソースに して、以下のように設定します。 REPORT-type = mv-type 特定のソ ー ス、ソ ー スタイプ、またはホストに する、サ ー チ時自 動フィ ー ルド抽出の無 効 化 を編集して、特定のソース、ソースタイプ、またはホストに する、サーチ時自動フィールド抽出を無 効にすることができます。props.conf の適切な [<spec>] に、KV_MODE = none を追加してください。 props.conf 注意：Splunk 管理で設定ファイルに手動設定されたカスタムフィールド抽出は、 象のソース、ソースタイプ、ま たはホストに KV_MODE = none が設定されている場合でも、引き続き処理が行われます。 [<spec>] KV_MODE = none <spec> には、以下の値を使用できます。 - イベントのソースタイプ。 はイベントのホストを表します。 source::<source>、<source> はイベントのソースを表します。 <sourcetype> host::<host>、<host> 複 数 値フィ ー ルドの設定 複数値フィールドは、イベント内に複数回登場するフィールドで、それぞれが異なる値を保有しています。複数値 フィールドの一般的な例として、メールアドレスフィールドが げられます。一般的にこのフィールドは単一の sendmail イベント内に 2 3 回登場します (送信者用、一連の受信者用、そして CC アドレスが指定されている場合 はそのリスト用)。これらのすべてのフィールドに同一のラベルが設定されている場合 (例：AddressList) は、個別 のラベルが設定されている場合 (例：「From」、「To」、および「Cc」) と違い、その意味が失われてしまいま す。 Splunk はサーチ時に複数値フィールドを解析します。これにより、値をサーチパイプライン内で処理することが できます。複数値フィールドを利用できるサーチコマンドには、makemv、mvcombine、mvexpand、および nomv があります。これらのコマンドおよび他のコマンドの詳細は、『ユーザーマニュアル』と『サーチリファレ ンスマニュアル』の、複数値フィールドに関するトピックを参照してください。 fields.conf 内に複数値フィールドを設定するには、TOKENIZER キーを使用します。TOKENIZER は、正規表現を使っ てイベント内の反復フィールドのフィールド値の認識/抽出方法を Splunk に指示しま す。$SPLUNK_HOME/etc/system/local/、または $SPLUNK_HOME/etc/apps/ 内の独自のカスタムアプリケーション ディレクトリ内にある fields.conf を編集してください。 設定ファイルの一般情報については、『管理マニュアル』の「設定ファイルについて」を参照してください。 正規表現の構文と使用方法の概要については、Regular-Expressions.info を参照してください。正規表現をテスト するには、rex サーチコマンドのを使用します。正規表現式を作成、テストするために役立つサードパーティ製 ツールのリストも用意されています。 fields.conf を使った複 数 値フィ ー ルドの設定 複数値フィールドを定義するには、fields.conf にスタンザを追加します。次に、TOKENIZER キーに する正規表現 を指定した行を追加します。この正規表現は、フィールドの複数値の抽出方法を表しています。 注意：複数値フィールド用に他の属性を設定する場合は、同じスタンザ内の TOKENIZER 行の下に設定してくださ い。詳細は、『管理マニュアル』の fields.conf に関するトピックを参照してください。 [<field name 1>] TOKENIZER = <regular expression> [<field name 2>] TOKENIZER = <regular expression> <regular expression> には、目的のフィールドがどのように複数の値を取るのかを指定する必要がありま 58 には、目的のフィールドがどのように複数の値を取るのかを指定する必要がありま す。 のデフォルトは空です。TOKENIZER が空の場合、フィールドは 1 つの値のみを取ることができま す。 そうでない場合は、各一致項目から最初のグループが取得され、一連のフィールド値が形成されます。 TOKENIZER キーは、where、timeline、および stats コマンドが使用します。また、非同期サーチ API のサマ リーと XML 出力も提供しています。 TOKENIZER 注意：インデックスフィールド (インデックス時に抽出されたフィールド) のトークン化はサポートされていませ ん。フィールドに して INDEXED=true を設定した場合、そのフィールドに TOKENIZER を使用することはできませ ん。インデックスフィールドを複数の値に分割するには、props.conf および transforms.conf に定義されている サーチ時フィールド抽出を使用します。 例 以下の $SPLUNK_HOME/etc/system/README/fields.conf.example からの例は、メールフィールド To、From、CC を複 数値に分割します。 [To] TOKENIZER = (\w[\w\.\-]*@[\w\.\-]*\w) [From] TOKENIZER = (\w[\w\.\-]*@[\w\.\-]*\w) [Cc] TOKENIZER = (\w[\w\.\-]*@[\w\.\-]*\w) 計算 みフィ ー ルドの定義 Splunk でのサーチ作成 験が長い方ならば、eval コマンドの使用方法をかなり理解していることでしょう。このコ マンドを利用すれば、自動的に抽出されたフィールドを含む式を作成し、式の評価結果となる値を取る新たな フィールドを生成することができます。(eval コマンドの詳細とさまざまな使用例については、『サーチリファレ ンスマニュアル』のコマンドに関する記事を参照してください。) コマンドは、多彩な機能を持ちとても有用です。eval 式は比較的単純ですが、しばしば非常に複 になる場合 もあります。かなり長くて複 な eval 式を定期的に使用する必要があるような場合、 回のサーチにそれをいちいち 入力するのは非常に大 な作業です。 eval このような場合に役に立つのが、計算 みフィールドです。計算 みフィールドにより、eval 式を持つフィールドを props.conf に定義することができます。次に、サーチを作成する場合には、eval 式を全体を省略し、抽出された 他のフィールドを参照するように、このフィールドを参照します。サーチを実行すると、サーチ時にフィールドが 抽出され、eval 式内のフィールドを含むイベントに追加されます。 たとえば、『サーチリファレンス』からの eval コマンドのサーチ例を考えてみましょう。この例は、地震データ を調査して、新しい Description フィールドを作成して、深度によって地震を分類しています。 source=eqs7day-M1.csv | eval Description=case(Depth<=70, "Shallow", Depth>70 AND Depth<=300, "Mid", Depth>300 AND Depth<=700, "Deep") | table Datetime, Region, Depth, Description 計算 みフィールドを使用して、props.conf 内に Description フィールド用の eval 式を定義することで、以下のよ うなサーチを実行することができます。 source=eqs7day-M1.csv | table Datetime, Region, Depth, Description これで、Description フィールドを、他の抽出されたフィールドと同 にサーチできるようになりました。Splunk は props.conf 内の計算 みフィールドキーを探して、Depth フィールドを持つ各イベントを評価します。以下のよ うなサーチを実行することもできます。 source=eqs7day-M1.csv Description=Deep 注意： 次のセクションでは、props.conf 内に Description 計算 みフィールドがどのように設定されているのかを 明しています。 props.conf の編集による計算 みフィ ー ルドの作成 計算 みフィールドを作成するには、新しいまたは既存の props.conf スタンザに、計算 みフィールドキーを追加し ます。props.conf は $SPLUNK_HOME/etc/system/local/、または $SPLUNK_HOME/etc/apps/ 内の独自のカスタムアプ リケーションディレクトリにあります。(カスタムデータを他のサーチサーバーに手 に転送したいような場合は、 59 後者のディレクトリを使用することをお勧めします。) 注意： $SPLUNK_HOME/etc/system/default/ 内のファイルは編集しないでください。 設定ファイルの一般情報については、『管理マニュアル』の「設定ファイルについて」を参照してください。 props.conf 内に指定する、計算 みフィールドキーのフォーマットを以下に示します。 [<stanza>] EVAL-<field_name> = <eval statement> <stanza> には、以下の値を使用できます。 <source type>、イベントのソースタイプ。 host::<host>、<host> はイベントのホストを表します。 はイベントのソースを表します。 source::<source>、<source> 計算 みフィールドキーは、「EVAL-」 (ハイフンを含む) で開始する必要があります。「EVAL」の大文字と 小文字は区別されません (たとえば、「eVaL」も可能です)。 <field_name> ただし、is は大文字と小文字が区別されます。このルールは、Splunk 内の他のフィールド名 でも一貫しています。 <eval_statement> は、eval コマンドと同 に自由かつ柔軟に指定することができます。複数値、論理値、ま たは NULL も含めて任意の値タイプを評価することができます。 そこで、Description 計算 みフィールド (このトピックの先頭にある例を参照) を設定するには、props.conf 内に 以下のスタンザを作成します。 <Stanza> Eval-Description = case(Depth<=70, "Shallow", Depth>70 AND Depth<=300, "Mid", Depth>300 AND Depth<=700, "Deep") 計算 みフィールドキーを適切に定義したら、eval ステートメントに登場する抽出されたフィールドを持つイベン トに して、サーチ時にフィールドが計算されます。計算 みフィールドの評価は、サーチ時フィールド抽出およ びフィールドのエイリアス設定の後で、ルックアップフィールドの生成前に行われます。 注意：計算 みフィールドをサーチする場合、パフォーマンスの点でこの操作はフィルタリングと同等の効果を発 揮します。フィールド値がインデックスには見つからないため、実際のサーチにインデックスが使用されることは ありません。 既存のフィールドの上書きの防止 計算 みフィールドが通常の手段で抽出されたフィールドと同じ名前を持つ場合、eval ステートメントの評価が NULL の場合でも、計算 みフィールドで抽出されたフィールドが上書きされてしまいます。この上書きを解除す るには、eval 式と一緒に eval 用の coalesce 関数を使用します。coalesce は、任意の数の引数を取得して、NULL ではない最初の値を返します。 eval ステートメントが値を返した場合に、計算 みフィールドで既存のフィールドを上書きしたくない場合は、以 下のように設定します。 EVAL-field = coalesce(field, <eval expression>) eval ステートメントが値を返した場合に、計算 みフィールドで既存のフィールドを上書きしたくない場合は、以 下のように設定します。 EVAL-field = coalesce(<eval expression>, field) および他の eval 関数の詳細は、『サーチリファレンスマニュアル』の「eval と where の関数」を参照 してください。 coalesce すべての計算 みフィ ー ルドが相互に 独 立して判 断 されることを示 す例 Splunk が計算 みフィールドを評価する場合、それぞれの式が他の式と無関係なものとして評価されます。つま り、ある計算 みフィールドの評価を別の計算 みフィールドの式内に使用することはできません。 以下の例では、各任意のイベントに して、x の値が計算 みフィールド y の値と同じになります。これらの 2 つの 計算は相互に独立して実行され、x*2 の計算時には両方の式がオリジナルの x の値を使用します。 [<foo>] EVAL-x = x * 2 60 EVAL-y = x * 2 特定のイベントが x=4 の場合は、これらの計算 みフィールドは x の値を 8 に置換して、イベントに y=8 を追加し ます。 抽出されたフィールド response_time を含む、他の多少現実的な例を見てみましょう。最初に抽出された時の response_time の値はミリ秒で表されています。ここでは、個別の方法で response_time を利用する、2 つの計算 みフィールドを定義しました。 [<access_common>] EVAL-response_time = response_time/1000 EVAL-bitrate = bytes*1000/response_time この例では、access_common ソースタイプを持つすべてのデータに して、2 つの処理が行われています。 最初の EVAL は、すべての sourcetype=access_common イベント内の response_time の値を、ミリ秒ではな く秒で表示するように 更しています。新しい「in seconds」の値は、古い「in milliseconds」の値に上書き されます。 2 番目の EVAl は、すべての sourcetype=access_common イベントに して、bitrate と呼ばれる新たなフィー ルドを算出します。これは、秒当たりの bytes で表されます。(bytes は別の抽出されたフィールドです。) どちらの計算でも、response_time は当初ミリ秒で表されており、両方の EVAL が相互に独立して算出されます。 ルックアップフィ ー ルドと計算 みフィ ー ルド 計算 みフィールドをルックアップフィールドのベースにすることはできません。試しても正常に利用することは できません。前述のように、計算 みフィールドの評価は、サーチ時フィールド抽出およびフィールドのエイリア ス設定の後で、ルックアップフィールドの生成前に行われます。 Splunk の正規表現について このページは現在作業中で、まもなく更新される予定です。 ここでは、Splunk で有効な正規表現を作成するために役立つ、基本的な情報を取り上げています。 正規表現は、テキスト内の文字パターンを照合するための手段です。Splunk は、自動的なデフォルトフィールド の抽出、バイナリファイルタイプの認識、ソースタイプの割り当てに正規表現を使用しています。また、ユーザー によるカスタムフィールド抽出の定義、イベントのフィルタリング、データのルーティング、およびサーチの相関 に正規表現を使用することもできます。正規表現を使用するサーチコマンドには、rex、regex、および eval 関数 の match() や replace() などが含まれています。 Splunk の正規表現は Perl 互換の正規表現 (PCRE) で、特に PCRE C ライブラリを使用しています。 用語と構文 用語 明 リテラル 正規表現を使って照合する文字テキスト。 正規表現または regex リテラルに して照合するために用いられるパターンを定義するメタ文字。 グループ 正規表現では、正規表現文字を むために用いられる括弧のタイプで示す、さまざま なグループ化を利用できます。一般的には、グループ、アトミックグループ、およ びルックアラウンドを照合または捕捉するために括弧を使用します。角括弧は文字 クラスの定義に、中括弧は反復の定義に、山括弧は名前付きグループの定義に、二 重括弧は Splunk 固有のモジュール正規表現の定義に使用されます。次に括弧に ま れたグループに量指定子を適用して、グループ内でオルタネーションを使用するこ とができます。 文字クラス 角括弧で まれた正規表現文字で、文字列の照合に用いられます。範 は、たとえば任 意の大文字と一致させる場合は [A-Z] のように範 で指定します。否定一致を定義す るには、文字クラスの先頭にキャレット (^) を指定します。たとえば、[^A-Z] のよ うに指定すると、大文字ではない任意の文字と一致します。 文字タイプ ワイルドカードと同 に、文字タイプは特定のリテラル一致の省略形を表していま す。たとえば、ピリオド . は、任意の文字に、\w はアンダースコアを含む任意の単 語または英数字に一致します。 アンカー これらは、復 \r や改行 \n などの、テキストフォーマット位置に一致する文字タイ 61 アンカー プです。 オルタネーション オルタネーションは、正規表現内の代替一致パターンを提供することを表していま す。代替パターンを区別するために、垂直バーまたはパイプ文字 ( | ) が用いられま す。このパターンには、完全な正規表現を指定することができます。たとえ ば、grey|gray は「grey」または「gray」と一致します。 量指定子または反復 量指定子 (*、+、?) は、グループをリテラルパターンと照合する方法を定義するた めに用いられます。たとえば、* は 0 件以上、+ は 1 件以上、? は 0 または 1 件に一 致します。 後方参照 後方参照は、後ほどの使用のために呼び すことができるリテラルグループです。 Splunk の場合は、ドル記号 ($) を持つ値の数値 (0 以外) への逆参照を表していま す。 ルックアラウンド ルックアラウンドは、文字列内の位置を判断するための、グループの定義方法の 1 つです。この定義はグループ内の正規表現と照合されますが、結果を保持するため の照合には利用されません。たとえば、ルックアラウンドを使用せずに、x の後に 続く y と照合せずに、x を照合することができます。 文字タイプ 文字タイプは、リテラル一致の簡略的表現です。 用語 明 . 任意の文字に一致 \w 単語に一致 (英数字文字列とアンダースコア「_」) \W 非単語文字と一致 \s 空白文字に一致 \S 非空白文字と一致 \d 数字に一致 \D 非数字と一致 グループと量指定子 正規表現では、正規表現文字を むために用いられる括弧のタイプで示す、さまざまなグループ化を利用できま す。次に括弧に まれたグループに量指定子 (*、+、?) を適用して、グループ内でオルタネーションを使用すること ができます。 用語 明 ( ) 括弧は、一致または捕捉グループ、アトミックグループ、およびルックアラウンド を定義するために用いられます。 [ ] 角括弧は、文字クラスを定義するために用いられます。 { } 中括弧は反復を定義するために用いられます。 < > 山括弧は、名前付き捕捉グループを定義するために用いられます。 [[ ]] 二重括弧は、Splunk 固有のモジュール正規表現を定義するために用いられます。 * グループと 0 回以上一致。 + グループと 1 回以上一致。 ? グループと 0 または 1 回一致。 正規表現の例 例 1：この例では、「to」または「too」と照合する 2 種類の方法を表しています。最初の正規表現は、? を使って 最初に登場した後もう 1 文字までの「o」を照合します。2 番目の正規表現はオルタネーションを使って、パター ンを指定しています。 62 to(o)? (to|too) モジュ ー ル正規表現 デ ー タ分類：イベントタイプとトランザクション イベントタイプについて イベントタイプは、データを把握するために役立つ分類システムです。イベントタイプにより大量のデータを調査 して、類似パターンを探し、アラートやレポートを作成することができます。 イベントとイベントタイプ イベントはログファイル内の単一のアクティビティレコードです。一般的にイベントにはタイムスタンプが含まれ ており、監視/記 されているシステムに何が発生したかに関する情報を提供します。 イベントタイプはイベントを分類することで、サーチを容易にするための、ユーザーが定義するフィールドです。 イベントタイプを使って、共通の特徴を持つイベントを分類することができます。サーチ結果が返されると、それ が既知のイベントタイプに してチェックされます。サーチ時にイベントが eventtypes.conf に定義されているイベ ントタイプに一致すると、そのイベントタイプがイベントに適用されます。データのインデックス作成後に、イベ ントタイプをタグ付けまたは保存してください。 イベントタイプの分類 独自のイベントタイプを作成するには、さまざまな方法が存在しています。Splunk Web を使用したり、設定ファ イルを編集したり、さらには任意のサーチをイベントタイプとして保存したりすることができます。サーチをイベ ントタイプとして保存する場合、punct フィールドを使ってサーチを調整することができます。punct フィールド は、イベントの構造に基づいてサーチを絞り込むために役立ちます。 punct フ ィ ー ル ド を 使 っ た 類 似 イ ベ ン ト の サ ー チ イベントのフォーマットはしばしばイベントタイプ特有のため、Splunk はイベントの句読点文字を punct. フィー ルドとしてインデックスを作成します。punct フィールドは、イベントの最初の行の最初の 30 文字の句読点を保 管しています。このフィールドは、類似イベントを素早く探すために役立ちます。 punct を使用する場合、以下の事項に注意してください。 引用符と円記号 (バックスラッシュ) はエスケープ処理されます。 スペースは、アンダースコア (_) で置換されます。 タブは「t」で置換されます。 英数字に続くダッシュは無視されます。 注目される句読点文字を以下に示します。 ",;-#$%&+./:=?@\\'|*\n\r\"(){}<>[]^!" punct フィールドは、_audit インデックス内のイベントには利用できません。これらのイベントは生成時に PKI で署名されています。 punct フィールドの概要と、他のイベント分類方法については、このマニュアルの「類似イベントの分類とグルー プ化」を参照してください。 Punct の例 このイベントは： ####<Jun 3, 2005 5:38:22 PM MDT> <Notice> <WebLogicServer> <bea03> <asiAdminServer> <WrapperStartStopAppMain> <>WLS Kernel<> <> <BEA-000360> <Server started in RUNNING mode> 以下の punct フィールドを生成します。 ####<_,__::__>_<>_<>_<>_<>_<>_ このイベントは： 172.26.34.223 - - [01/Jul/2005:12:05:27 -0700] "GET /trade/app?action=logout HTTP/1.1" 200 2953 63 以下の punct フィールドを生成します。 ..._-_-_[:::_-]_\"_?=_/.\"__ イベントタイプの 出 任意のサーチをパイプ文字を使って typelearner コマンドに渡し、Splunk Web から直接イベントタイプを作成で きます。eventdiscoverer.conf ファイルはほぼ 止状態ですが、引き続き Splunk Web で新たなイベントタイプを学 習する際に無視する単語を指定するこは可能です。 新たなイベントタイプの作成 新しいイベントタイプを作成するもっとも手 な方法は、Splunk Web を使用することです。イベントタイプは、 サーチを保存する場合と同じ方法で保存できます。詳細は、このマニュアルの「Splunk Web を使ったイベントタ イプの定義と管理」を参照してください。 新たなイベントタイプを作成するには、eventtypes.conf を 更します。サーチをイベントタイプとして保存する方 法の詳細は、このマニュアルの「類似イベントの分類とグループ化」を参照してください。 イベントタイプタグ データをカテゴリに分類するには、イベントタイプにタグを設定します。イベントに複数のタグを設定することも できます。イベントタイプのタグ設定の詳細は、このマニュアルの「イベントタイプのタグ設定」を参照してくだ さい。 イベントタイプの設定ファイル イベントタイプは eventtypes.conf に保存されます。 イベントタイプ 出用の用語は eventdiscoverer.conf に設定されます。 類似イベントの分類とグル ー プ化 イベントはイベントタイプとは異なります。イベントは、データの単一のインスタンスです。たとえば、1 つのロ グエントリがイベントになります。イベントタイプは、イベントにラベルを付けてグループ化するために用いられ る分類方法です。 イベントに するイベントタイプ名は、イベントの eventtype と呼ばれる複数値フィールドに設定されます。これ らのイベントグループ (例：SSH ログイン) は、任意のフィールド値と同じ方法でサーチできます。 ここでは、イベントタイプの保存とサーチでの使用方法について 明していきます。イベントの詳細、Splunk のイ ベントの認識方法、インデックス作成時のイベントの処理方法などについては、『Getting Data In Manual』の 「Overview of event processing」を参照してください。 サ ー チの新規イベントタイプとしての保存 基本的に、イベントデータをサーチする場合、不要なイベントをすべて除去することになります。サーチ結果は類 似の特徴を持つイベントの集合になり、それらに総称名を指定することができます。 たとえば、異なるホストマシン上の失敗したログインを頻繁にサーチする場合、サーチで見つかったイベントに するイベントタイプを作成して、failed_login と言う名前を付けられます。 "failed login" OR "FAILED LOGIN" OR "Authentication failure" OR "Failed to authenticate user" このサーチをイベントタイプとして保存するには： 1. サーチを実行します。サーチの実行中に、[作成] をクリックして、[イベントタイプ] を選 します。サーチが完了 するまで待たずにこの作業を行えます。 2. [イベントタイプとして保存] で、サーチに名前を指定します。このサーチ例では、「failed_login」と名付けま す。 64 必要に じて、[サーチ文字列] フィールドを 更することができます。このフィールドには、先ほど実行したサーチ が自動的に入力されています。 また、必要に じて [タグ] フィールドに、イベントタイプに適用するタグのリストを追加することもできます。詳 細は、後述のイベントタイプへのタグ設定に関する 明を参照してください。 3. [保存] をクリックするとイベントタイプ名が保存されます。 これで、任意のフィールドをサーチするのと同じ方法で、イベントタイプにマッチするすべてのイベントを手 に サーチできるようになります。 たとえば、特定のホストマシン上の失敗したログインを調査することができます。 host=target eventtype=failed_login また、疑わしいユーザーのアクティビティを調査することもできます。 user=suspicious eventtype=failed_login 重要なイベントタイプ定義の制限事項 パイプ演算子またはサブサーチを含むサーチに基づいたイベントタイプを作成することはできません。 また、保存 みサーチを参照するサーチに基づいてイベントタイプを作成することはできません。たとえば、前の 例のサーチを実行してそれを failed_login_search という名前で保存しても、そのサーチ savedsearch=failed_login_search が定義するイベントタイプを作成することはできません。このような場合は、 保存 みサーチと同じサーチ文字列にイベントタイプを指定する必要があります。 punct による類似イベントの識別 イベントの句読点文字はイベントタイプに して一意であることが多いため、Splunk はイベントの句読点文字を punct フィールドにインデックスしています。このフィールドの値は暗号のように見えますが、類似イベントの特 性を把握するための効果的な手段を提供しています。 サーチ結果に punct フィールドを適用するには、Splunk チュートリアルの「フィールドを使ったサーチ」で 明さ れているフィールドポップアップを使用します。SSH ログインイベントの punct 値を選 します。これにより、 サーチバーのサーチに punct が入れられます。句読点文字にワイルドカードを使用して、さまざまなバリエーショ ンを照合することができます (例："punct=::[]*/*")。 typelearner を使った新規イベントタイプの 出 任意のサーチを typelearner コマンドに渡すと、Splunk が提案するイベントタイプを確認できます。デフォルト で、typelearner はサーチ結果となるイベントの句読点を比較し、類似の句読点や単語を持つイベントをグループ 化します。 イベントをグループ化するために、異なるフィールドを指定することができます。typelearner は任意のフィール ドと同じように機能します。結果は、このフィールドとフレーズを共通に保有する、一連のイベント (サーチ結果 からの) になります。 65 詳細と例については、『サーチリファレンスマニュアル』の「typelearner」を参照してください。 タグを使った類似イベントのグル ー プ化と 索 イベントタイプには、それに関連する 1 つまたは複数のタグを割り当てられます。サーチをイベントタイプとして 保存する際に、またはイベントタイプ管理 ([管理] > [イベントタイプ])から、これらのタグを追加できます。この ウィンドウのイベントタイプリストから、編集するイベントタイプを選 します。 イベントタイプにタグを追加したら、任意のタグのサーチと同じ方法でサーチを実施することができます。ファイ アウォールイベントのサーチをイベントタイプ firewall_allowed として保存し、ログインイベントのサーチをイ ベントタイプ login_successful として保存した場合を考えてみましょう。これらのイベントタイプにタグ 「allow」を設定しておけば、サーチを使って両方のイベントタイプのイベントを取得できます。 tag::eventtype="allow" タグの使用方法の詳細は、このマニュアルの「フィールド値のタグ/エイリアス設定」を参照してください。 Splunk Web でのイベントタイプの定義と管理 有益なイベントを結果として得るために、イベントタイプに基づいてサーチを実行します。単一のイベントは、複 数のイベントタイプに一致することができます。 Splunk Web で作成したイベントタイプは、$SPLUNK_HOME/etc/users/<your-username>/<app>/local/ の eventtypes.conf に自動的に追加されます。ここば、<app> はイベントタイプ作成時にあなたがいた App を表しま す。イベントタイプの 限を 更してすべてのユーザーが利用できるようにした場合 (App 内で、またはすべての App でグローバルに)、そのイベントタイプは $SPLUNK_HOME/etc/apps/<App>/local/ に移動されます。 重要なイベントタイプ定義の制限事項 パイプ演算子またはサブサーチを含むサーチに基づいたイベントタイプを作成することはできません。 また、保存 みサーチを参照するサーチに基づいてイベントタイプを作成することはできません。たとえ ば、failed_login_search という名前の保存 みサーチがある場合に、サーチ savedsearch=failed_login_search が 定義するイベントタイプを作成することはできません。このような場合は、保存 みサーチと同じサーチ文字列に イベントタイプを指定する必要があります。 サ ー チのイベントタイプとしての保存 サーチをイベントタイプとして保存するには： サーチを入力して実行します。 [作成] をクリックして、[イベントタイプ...] を選 します。 サーチ文字列が記載された、[イベントタイプの保存] ダイアログボックスが表示されます。 イベントタイプ名を指定します。 必要に じて、イベントタイプに 1 つまたは複数のカンマで区切ったタグを設定します。 [保存] をクリックします。 これでイベントタイプをサーチに利用できるようになりました。イベントタイプに foo という名前を指定した場 合、サーチでは以下のようにイベントタイプを使用します。 eventtype=foo イベントタイプの自動 索 /作成 IT データ内に有益なイベントタイプがあるかどうか分からないことがありませんか？Splunk には、役に立つイベ ントタイプを賢く動的に 出、作成するユーティリティが用意されています。 イベントタイプの 索：findtypes サーチコマンドは、指定されたイベントセットを分析して、有用なイベン トタイプに 換できる共通パターンを判別します。 イベントタイプの作成：イベントタイプの作成ユーティリティにより、サーチから返されたイベントに基づ いて動的にイベントタイプを作成することができます。このユーティリティでは、イベントタイプに特定の 色を割り当てることもできます。たとえば、「sendmail error」イベントタイプに赤を割り当てた場合、次回 のサーチ実行時にこのイベントタイプに該当するイベントが赤色で表示され、一目で把握できるようになり ます。 66 イベントタイプの 索 イベントタイプを 索するには、サーチの最後に以下の項目を追加します。 ...| findtypes findtypes コマンドを使用するサーチは、サーチ結果内のもっとも共通なイベントグループの明細を返します。こ れは： 頻度の 点から階層的に並べられています。これにより、大きなイベントグループのサブセットとなるイベン トを手 に把握することができます。 類似のイベントを探すために役立つイベントタイプの基盤として利用できるサーチが記載されています。 デフォルトで、findtypes は、サンプルから見つかったイベント数の 点から上位 10 件のイベントタイプ候補を返 します。max 引数を追加して、返される値を やすことができます。 findtypes max=30 また、findtypes で見つかったイベントグループが、すでに他のイベントタイプに関連付けられているかどうかも 表示されます。 注意：findtypes コマンドは、これらの結果を返すために最高で 5000 件のイベントを分析します。サーチの効率 性を向上するために、head コマンドを使ってこの値を減らすことができます。 ...| head 1000 | findtypes イベントタイプ候補のサーチを保存する前のテスト 役に立つイベントグループ候補を識別する際に、それに関連するサーチをテストして、目的の結果が返されるかど うかをテストすることができます。注目しているイベントグループの [テスト] をクリックして、関連するサーチ を別のウィンドウで実行することができます。サーチの実行後、返された結果を見て、目的の情報が表示されるか どうかを確認することができます。 テストしたサーチのイベントタイプとしての保存 目的の結果を返すサーチが見つかったら、 するイベントグループの [保存] をクリックして、それをイベントタイ プとして保存します。[イベントタイプの保存] ダイアログが表示されます。イベントタイプ名を入力して、必要に じてタグを設定します (複数設定する場合はカンマで区切る)。必要に じてサーチを編集することもできます。 イベントタイプの作成 イベントタイプのベースにする、目的の結果を返すサーチが見つかったら、イベントのタイムスタンプの横にある ドロップダウンメニューの下矢印をクリックして、[イベントタイプの作成] をクリックします。 イベントタイプの作成ユーティリティ (イベントタイプビルダー) が表示されます。このユーティリティを使って 目的のセットを返すサーチを作成し、それに基づいたイベントタイプを作成します。 イベントタイプの作成ユーティリティは、サーチ結果から選 した場合と同 な、サンプルイベントセットを 索しま 67 す。[イベントタイプの特徴] サイドバーには、イベントタイプをさらに絞り込むためのフィールド/値のペアが表 示されます。 このユーティリティのページ上部の [生成されたイベントタイプ] には、サーチ文字列が表示されます。これは、 作成しているイベントタイプのベースとなるサーチです。[イベントタイプの特徴] サイドバーでフィールド/値のペ アを選 すると、[生成されたイベントタイプ] がそれらを含むように更新されます。サンプルイベントのリスト も、 更されたサーチに じて更新されます。 サーチを直接編集する場合は、[編集] をクリックします。[イベントタイプの編集] ダイアログが表示されます。こ こでは、サーチ文字列を編集することができます。 イベントタイプ候補のサーチを保存する前のテスト 有用なイベントタイプになるサーチを作成したら、それをテストしてください。[テスト] をクリックすると、サー チが別のウィンドウで実行されます。 テストしたサーチのイベントタイプとしての保存 サーチをテストして、目的のイベントセットが得られることを確認したら、[保存] をクリックして、それをイベン トタイプとして保存します。[イベントタイプの保存] ダイアログが表示されます。 イベントタイプ名を入力してください。次に、必要に じて [スタイル] リストでイベントタイプに割り当てる色を 選 します。保存した後は、そのイベントタイプに該当するイベントは、割り当てた色で表示されます。たとえ ば、イベントタイプ sendmail_bounce を作成して、それの [スタイル] に赤を設定して保存します。そうすると、 サーチを実行してこのイベントタイプに該当するイベントは赤で表示されるため、手 に特定することができま す。 [優先度] リストを使って、[スタイル] が設定されている複数のイベントタイプに該当するイベントの処理方法を指 定することができます。たとえば、優先度が「高」のイベントタイプのスタイルに赤を設定し、優先度が「平均」 のイベントタイプのスタイルに を設定した場合を考えてみましょう。返されたイベントが両方のイベントタイプ に該当する場合、「高」優先度のイベントタイプが「平均」のイベントタイプに優先されて、そのイベントはサー チ結果内に赤で表示されます。 Splunk 管理を使ったイベントタイプの追加と管理 Splunk 管理の [イベントタイプ] ページでは、作成したイベントタイプや編集 限のあるイベントタイプの詳細を表 示、管理することができます。[イベントタイプ] ページでは、新しいイベントタイプを追加することもできます。 [イベントタイプ] ページに表示されるイベントタイプは、グローバルにシステム全体で利用できる場合も、App 固 有の場合もあります。 Splunk 管 理 で の イ ベ ン ト タ イ プ の 追 加 Splunk 管理でイベントタイプを追加するには、[イベントタイプ] ページで [新規] をクリックします。[新しいイベ ントタイプの追加] ページが表示されます。 68 このページでは、イベントタイプを定義する [宛先 App]、[名前]、および [サーチ文字列] を入力します (上記の 「サーチのイベントタイプとしての保存」を参照)。 注意：作成したイベントタイプはすべて、当初は特定の App で利用できます。イベントタイプをすべてのユー ザーにグローバルに利用させるには、[イベントタイプ] ページで目的のイベントタイプを探して [ 限] リンクをク リックし、[この App のみ] を [すべての App] に 更しますイベントタイプ (および他のナレッジオブジェクトタイ プ) の 限の設定方法については、このマニュアルの「Splunk ナレッジの管理」を参照してください。 必要に じて、イベントタイプにタグを設定することもできます。イベントタイプおよび他の Splunk ナレッジへの タグの設定については、このマニュアルの「タグとエイリアスについて」を参照してください。 必要に じてイベントタイプの優先度を設定することもできます。1 が最高優先度、10 が最低優先度になりま す。[優先度] の設定は、イベントが複数のイベントタイプに該当する場合に重要になります。サーチ結果にイベン トを表示する場合、イベントに関連するイベントタイプが特定の順序で表示されます。[優先度] の設定により、こ の表示順序においてあるイベントタイプを他のイベントタイプに優先させることができます。 多数のオーバーラップするイベントタイプがある場合、または大きなイベントタイプのサブセットとなるイベント タイプがある場合、 密に絞り込まれているイベントタイプに高い優先度を割り当てる方が分かりやすいことがあ ります。たとえば、幅広い system_error イベントタイプの一部となるイベントセットを、手 に把握できるように することができます。そのような巨大なイベントセットに して、より絞り込んだイベントタイプ critical_disc_error や bad_external_resource_error を作成することができます。 このような状況で、たとえば system_error に優先度 10 を、他の 2 つのエラーコードには優先度に 1 5 の範 の値 を割り当てます。これにより、サーチ結果でイベントが system_error と critical_disc_error の両方に該当する 場合、critical_disc_error イベントタイプが常に system_error イベントタイプよりも先に表示されます。 Splunk 管 理 で の イ ベ ン ト タ イ プ の 管 理 イベントタイプの詳細を更新するには、Splunk 管理の [イベントタイプ] ページで、目的のイベントタイプの名前 をクリックします。イベントタイプの詳細ページが表示されます。ここでは、[サーチ文字列]、[タグ]、および [優 先度] を編集できます (適切な 限がある場合)。また [イベントタイプ] ページでは、イベントタイプの 限を 更した り、イベントタイプを削除したりすることもできます (編集 限がある場合)。 eventtypes.conf を使ったイベントタイプの設定 eventtypes.conf を編集して新たなイベントタイプを追加したり、既存のイベントタイプを 更することができま す。$SPLUNK_HOME/etc/system/default/eventtypes.conf には、いくつかのデフォルトのイベントタイプが定義さ れています。Splunk 管理で作成したイベントタイプは、自動的に $SPLUNK_HOME/etc/system/local/eventtypes.conf に追加されます。 重要なイベントタイプ定義の制限事項 パイプ演算子またはサブサーチを含むサーチに基づいたイベントタイプを作成することはできません。 また、保存 みサーチを参照するサーチに基づいてイベントタイプを作成することはできません。たとえ ば、failed_login_search という名前の保存 みサーチがある場合に、サーチ savedsearch=failed_login_search が 定義するイベントタイプを作成することはできません。このような場合は、保存 みサーチと同じサーチ文字列に イベントタイプを指定する必要があります。 設定 69 でイベントタイプを 更します。$SPLUNK_HOME/etc/system/README/eventtypes.conf.example を 例として使用することも、独自の eventtypes.conf を作成することも可能です。 eventtypes.conf 内の独自のカスタムアプリケーションディレ クトリ内にある eventtypes.conf を編集してください。設定ファイルの一般情報については、『管理マニュアル』 の「設定ファイルについて」を参照してください。 $SPLUNK_HOME/etc/system/local/、または $SPLUNK_HOME/etc/apps/ [$EVENTTYPE] イベントタイプのヘッダー。 $EVENTTYPE はイベントタイプ名です。 任意の数のイベントタイプを指定できます。それぞれのイベントタイプをスタンザとして定義して、 以下の属性/値のペアを指定できます。 注意：イベントタイプ名にパーセント記号で んだフィールド名が含まれている場合 (例：%$FIELD%)、サーチ時に $FIELD の値がイベントタイプ名に代入されます。たとえば、ヘッダーが [cisco-%code%] のイベントタイプ で、code=432 の場合は [cisco-432] のように表示されます。 disabled = <1 or 0> イベントタイプをオン/オフにします。 無効にする場合は 1 を設定します。 search = <string> このイベントタイプのサーチ用語。 例：error OR warn。 tags = <string> イベントタイプのタグとなる、スペースで区切られた単語。 description = <string> イベントタイプの 明 (省略可)。 priority = <integer> Splunk はこの値を使って、イベントに該当するイベントタイプの表示順序を決定します。1 が最高、10 が 最低を表します。 注意：eventtype のフィールド値は、他のフィールド/値の組み合わせへのタグ設定と同じようにタグ付けすること ができます。詳細は、tags.conf ファイルを参照してください。 例 2 種類のイベントタイプ web および fatal があります。 [web] search = html OR http OR https OR css OR htm OR html OR shtml OR xls OR cgi [fatal] search = FATAL イベントタイプの無 効 化 イベントタイプを無効にするには、eventtypes.conf の該当するイベントタイプスタンザに disabled = 1 を追加 します。 [$EVENTTYPE] disabled = 1 $EVENTTYPE web は無効にするイベントタイプ名を表しています。 イベントタイプを無効にする場合は、以下のエントリを該当するスタンザに追加します。 [web] disabled = 1 70 イベントタイプテンプレ ー トの設定 イベントタイプテンプレートは、サーチ時にイベントタイプを作成します。イベントタイプテンプレートは、 eventtypes.conf に定義します。$SPLUNK_HOME/etc/system/local/、または $SPLUNK_HOME/etc/apps/ 内の独自の App ディレクトリにある eventtypes.conf を編集してください。 設定ファイルの一般情報については、『管理マニュアル』の「設定ファイルについて」を参照してください。 イベントタイプテンプレ ー トの設定 イベントタイプテンプレートは、フィールド名をパーセント記号で んだものを使って、サーチ時にイベントタイ プを作成します。この時、%$FIELD% の値がイベントタイプ名に代入されます。 [$NAME-%$FIELD%] $SEARCH_QUERY テンプレートのサーチが %$FIELD%=bar のイベントを返した場合、そのイベントに して $NAME-bar と言う名前のイ ベントタイプが生成されます。 例 [cisco-%code%] search = cisco 「cisco」のサーチでイベント code=432 が返された場合、「cisco-432」と言う名前のイベントタイプが作成され ます。 トランザクションについて トランザクションは、一定期間にまたがる任意の関連イベントのグループです。トランザクションタイプは、設定 されたトランザクションで、Splunk にフィールドとして保存されています。任意の数のデータソースが、複数の ログエントリにまたがってトランザクションを生成できます。 たとえば、オンラインストアで買い物をしている顧客が、複数のソースにまたがってトランザクションを形成する 場合があります。Web アクセスイベントが、アプリケーションサーバーログ内のイベントとセッション ID を共有 しています。アプリケーションサーバーログには、アカウント ID、トランザクション ID、製品 ID などが含まれて います。トランザクション ID は、メッセージキュー内にメッセージ ID を使って保管されます。アプリケーション の完了時には、メッセージ ID と出荷ステータスがログに記 されます。このデータがすべて、単一のユーザーのト ランザクションを表しています。 他のいくつかのトランザクション例を以下に示します。 Web アクセスイベント アプリケーションサーバーイベント ビジネストランザクション メール セキュリティ違反 システム障害 トランザクションサ ー チ トランザクションサーチは、ログに記 された複数のイベントにまたがる任意の物理イベントに注目する場合に役 立ちます。transaction コマンドを使って、トランザクションを定義したり、transactiontypes.conf に設定されて いるトランザクションオプションに優先する設定を使用したりすることができます。 詳細は、このマニュアルの「トランザクションのサーチ」を参照してください。 トランザクションタイプの設定 作成したトランザクションサーチを保持したいような場合もあるでしょう。または、 続的なトランザクションタ イプを作成したい場合もあるでしょう。transactiontypes.conf を編集して、トランザクションを保存することが 71 イプを作成したい場合もあるでしょう。 を編集して、トランザクションを保存することが できます。トランザクションを定義するには、スタンザを作成して必要な項目を指定します。 トランザクションタイプの設定方法の詳細は、「トランザクションの定義」を参照してください。 トランザクションの代わりに stats を使用する場合 トランザクションは、トランザクションデータの総統計を算出するためのもっとも効率的な手段と言う訳ではあり ません。単一フィールド内のデータにより定義されているトランザクションの総統計を算出する場合は、stats コ マンドを使用します。 たとえば、session_id フィールドが定義する、トランザクションの期間の統計を算出する場合は、以下のコマン ドを使用します。 * | stats min(_time) AS earliest max(_time) AS latest by session_id | eval duration=latest-earliest | stats min(duration) max(duration) avg(duration) median(duration) perc95(duration) 同 に、アクセスログ内の clientip 当たりのヒット数を算出する場合は、以下のコマンドを使用します。 sourcetype=access_combined | stats count by clientip | sort -count また、アクセスログ内の clientip 当たりの一意のセッション (cookie でパラメータ化) 数を算出する場合は、以下 のコマンドを使用します。 sourcetype=access_combined | stats dc(cookie) as sessions by clientip | sort -sessions stats コマンドの使用方法の詳細は、リファレンスマニュアルの stats コマンドに関する 明を参照してください。 トランザクションのサ ー チ トランザクションのサーチは、Splunk Web または CLI で transaction サーチコマンドを使って行いま す。transaction コマンドは、グループ化されたイベントを生成します。これをレポートに使用することができま す。transaction を使用するには、トランザクションタイプ (transactiontypes.conf で設定) を呼び出すか、または transaction にサーチオプションを設定して、サーチ内にトランザクション制約を定義します。 サ ー チオプション サーチ時に返されるトランザクションは、各イベントの raw テキスト、共有イベントタイプ、およびフィールド 値から成り立っています。トランザクションには、duration および transactiontype フィールドに保存される追 加データも存在しています。 には、トランザクションの期間が含まれています (トランザクション内の最初と最後のイベントの タイムスタンプの差)。 transactiontype はトランザクション名です (transactiontypes.conf にトランザクションのスタンザ名で定 義)。 duration は任意のサーチに追加できます。最良のサーチパフォーマンスを確保するために、適切なサーチを作 成して、それをパイプ文字で transaction コマンドに渡してください。詳細は、『Search Reference Manual』の 「transaction」を参照してください。 transaction コマンドに続けて、以下のオプションを指定できます。注意：一部の transaction オプションは、他 のオプションと一緒に指定することはできません。 transaction [field-list] のように、フィールドのカンマ区切りリストです。 設定した場合、同じトランザクション内にあるイベントと判断するには、各イベントに同じフィールドがな ければなりません。 共通のフィールド名で異なる値を持つフィールドはグループ化されません。 たとえば、...|transaction host を追加した場合、host=mylaptop を持つサーチ結果が host=myserver を持つサーチ結果と同じトランザクションになることはありません。 host の値を持たないサーチ結果は、host=mylaptop を持つ結果と同じトランザクションになる可能性 があります。 ...|transaction host,cookie match=closest トランザクション定義で使用するマッチタイプを指定します。 現在のところ、値は closest のみをサポートしています。 maxspan=[<integer> s|m|h|d] 72 トランザクション内のイベントにまたがる最大期間を設定します。 秒、分、時間、または日単位で指定できます。 例：5s、6m、12h、または 30d。 デフォルトは、maxspan=-1 で、時間範 は「全時間」となっています。 maxpause=[<integer> s|m|h|d] トランザクション間の最大一時停止期間を指定します。 トランザクション内のイベント間の一時停止期間は maxpause 未 でなければなりません。 負の値を指定した場合、maxspause 制約は無効になります。 デフォルトは maxpause=-1 です。 startswith=<string> サーチまたは eval フィルタリング式。あるイベントがこの条件を たすと、新しいトランザクションの開始 としてマークされます。 例： startswith="login" startswith=(username=foobar) startswith=eval(speed_field < max_speed_field) startswith=eval(speed_field < max_speed_field/12) デフォルトは "" です。 endswith=<transam-filter-string> サーチまたは eval フィルタリング式。あるイベントがこの条件を たすと、新しいトランザクションの終了 としてマークされます。 例： endswith="logout" endswith=(username=foobar) endswith=eval(speed_field < max_speed_field) endswith=eval(speed_field < max_speed_field/12) デフォルトは "" です。 startswith および endswith の場合、<transam-filter-string> は次の構文で定義されます： "<search- expression>" | (<quoted-search-expression>) | eval(<eval-expression> は、引用符を含まない有効なサーチ式です。 は、引用符を含む有効なサーチ式です。 <eval-expression> は、論理演算式を評価する有効な eval 式です。 <search-expression> <quoted-search-expression> 例： サーチ式： (name="foo bar") サーチ式： "user=mildred" サーチ式： ("search literal") eval 論理演算式： eval(distance/time < max_speed) トランザクションおよびマクロサ ー チ トランザクションおよびマクロサーチは強力な組み合わせで、トランザクションサーチ内で代替を行うことができ ます。代替を行うには、トランザクションサーチを実行して、それを $field$ で保存します。 マクロサーチとトランザクションの使用例については、『サーチマニュアル』の「サーチマクロの作成と使用」を 参照してください。マクロサーチの詳細は、このマニュアルの「マクロサーチの設計」を参照してください。 トランザクションサ ー チの例 単一のユーザー (またはクライアント IP アドレス) が一定期間に参照したすべての Web ページをグループ化する サーチを実行します。 このサーチはアクセスログからイベントを作成し、同じ clientip 値を共有し、相互の発生間隔が 5 分以内のイベ ントからトランザクションを作成します (3 時間の期間内で)。 sourcetype=access_combined | transaction clientip maxpause=5m maxspan=3h トランザクションの設定 73 任意のイベントシリーズをトランザクションタイプに 換することができます。使用事例については、このマニュ アルの「トランザクションについて」を参照してください。 transactiontypes.conf を使ってトランザクションタイプを作成することができます。設定の詳細については、後述 します。 設定ファイルの一般情報については、『管理マニュアル』の「設定ファイルについて」を参照してください。 transactiontypes.conf へのトランザクションタイプの設定 1. $SPLUNK_HOME/etc/system/local/ 内、またはカスタムアプリケーションディレクトリの $SPLUNK_HOME/etc/apps/ 内にある transactiontypes.conf ファイルを編集します。 2. スタンザを作成して、各トランザクションの属性を定義します。以下の属性を使用してください。 [<transactiontype>] maxspan = [<integer> s|m|h|d|-1] maxpause = [<integer> s|m|h|d|-1] fields = <comma-separated list of fields> startswith = <transam-filter-string> endswith=<transam-filter-string> [<TRANSACTIONTYPE>] 任意の数のトランザクションタイプを作成できます。それぞれのトランザクションタイプ名はスタンザ名で 表します。以下の属性/値のペアを指定できます。 スタンザ名 [<TRANSACTIONTYPE>] を使って、Splunk Web 内のトランザクションをサーチします。 以下の属性にエントリを指定しない場合は、デフォルト値が使用されます。 maxspan = [<integer> s|m|h|d|-1] トランザクションの最大期間を設定します。 秒、分、時間、日で指定できます。-1 を設定すると無制限になります。 例：5s、6m、12h、または 30d。 デフォルトは -1 です。 maxpause = [<integer> s|m|h|d|-1] トランザクション内のイベント間の最大一時停止期間を設定します。 秒、分、時間、日で指定できます。-1 を設定すると無制限になります。 例：5s、6m、12h、または 30d。 デフォルトは -1 です。 maxevents = <integer> 1 つのトランザクション内の最大イベント数。値が負の整数の場合、制約は無効になります。 デフォルトは 1000 です。 fields = <comma-separated list of fields> 設定した場合、同じトランザクション内にあるイベントと判断するには、各イベントに同じフィールドがな ければなりません。 例： fields = host,cookie デフォルトは " " です。 connected= [true|false] が空でない場合にのみ関係しています。トランザクションのフィールドと整合性のあるまたは整合性 のないイベントを、新しいトランザクションで開く (connected=true) か、またはトランザクションに追加す るかを指定します。 トランザクションが必要とするフィールドを持つけれども、トランザクション内でこれらのフィールドがど れもインスタンス化されていない (前のイベント追加により) 場合、イベントは非不整合および非整合にでき ます。 デフォルトは connected = true です。 fields startswith = <transam-filter-string> サーチまたは eval フィルタリング式。あるイベントがこの条件を たすと、新しいトランザクションの開始 としてマークされます。 例： 74 startswith="login" startswith=(username=foobar) startswith=eval(speed_field < max_speed_field) startswith=eval(speed_field < max_speed_field/12) デフォルトは " " です。 endswith=<transam-filter-string> サーチまたは eval フィルタリング式。あるイベントがこの条件を たすと、新しいトランザクションの終了 としてマークされます。 例： endswith="logout" endswith=(username=foobar) endswith=eval(speed_field > max_speed_field) endswith=eval(speed_field > max_speed_field/12) デフォルトは " " です。 startswith と endswith の両方に して、<transam-filter-string> の構文は以下のようになります。 "<search-expression>" | (<quoted-search-expression> | eval(<eval-expression>) ここで： は、引用符を含まない有効なサーチ式です。 は、引用符を含む有効なサーチ式です。 <eval-expression> は、論理演算式を評価する有効な eval 式です。たとえば、startswith=eval(foo<bar*2) は、foo が 2 x bar 未 のイベントに一致します。 <search-expression> <quoted-search-expression> 例： "<search-expression>": startswith="foo bar" <quoted-search-expression>: startswith=(name="foo bar") <quoted-search-expression>: startswith=("search literal") eval(<eval-expression>): eval(distance/time < max_speed) 3. Splunk Web で transaction コマンドを使って、定義したトランザクション (定義したトランザクションタイプ名 を使用) を呼び出します。サーチ時の指定に優先させることができます。 トランザクションの詳細は、このマニュアルの「トランザクションのサーチ」を参照してください。 その他のトランザクション設定 属 性 transactions.conf には、複数値フィールドやメモリー制限上の問題などに 処する目的で用意されている属性があ ります。 メモリー制限に関する問題用のトランザクションオプション maxopentxn=<int> LRU (least-recently-used memory cache) ポリシーを使って、トランザクションの削除を開始するまでに、開 いているプール内に保持する未終了トランザクションの最大数を指定します。 この属性のデフォルト値は、limits.conf の transactions スタンザから読み込まれます。 maxopenevents=<int> LRU (least-recently-used memory cache) ポリシーを使って、トランザクションの削除を開始する前に、開か れているトランザクションの一部となるイベントの最大数を指定します。 この属性のデフォルト値は、limits.conf の transactions スタンザから読み込まれます。 keepevicted=[true|false] 削除したトランザクションを出力するかどうかを指定します。evicted フィールドの値を確認すれば、削除 されたトランザクションと削除されていないトランザクションを判別することができます。削除されたトラ ンザクションの場合、フィールドには 1 が設定されます。 デフォルトは keepevicted=false です。 複数値フィールド表示用トランザクションオプション mvlist=[true|false]|<field-list> mvlist 属性には、トランザクションの複数値フィールドを、元のイベントのリストの到着順に並べるか、ま 75 たは一連の一意のフィールド値を辞書式に並べるかを指定します。フィールドのカンマまたはスペース区切 りリストを指定した場合、それらのフィールドのみをリストとして表示します。 デフォルトは mvlist=false です。. delim=<string> トランザクションのイベントフィールドにある元のイベント値を区切るために使用する文字列。 デフォルトは delim=" " です。 nullstr=<string> 欠損フィールド値を、トランザクション内の複数値フィールドの一部として表示する際に使用する文字列 値。 このオプションは、リストとして表示されるフィールドにのみ適用されます。 デフォルトは nullstr=NULL です。 デ ー タの 強 化：ルックアップとワ ー クフロ ー アク ション ルックアップとワ ー クフロ ー アクションについて ルックアップとワークフローアクションにより、外部リソースを活用してイベントデータの有益性を強化すること ができます。 テ ー ブルのルックアップ テーブルのルックアップは、イベント内の情報を使って、静的テーブル (CSV ファイル) や Python ベースのコマ ンドなどの外部データソースからの、他のフィールドの追加方法を判断します。また、時間情報に基づいてフィー ルドを追加するルックアップを作成することもできます。 この機能の基本的な例として、イベント内の http_status 値を使用する静的ルックアップが げられます。この値 を CSV ファイル内の定義と照合して、イベントにその定義を新たな status_description フィールドの値として 追加します。イベントが http_status = 503 の場合、ルックアップによりイベントに status_description = Service Unavailable, Server Error が追加されます。 ルックアップには他にもさまざまな利用法があります。たとえば、以下のような作業を行えます。 静的ルックアップテーブルに、保存 みサーチの結果を設定する。 ルックアップテーブルの代わりに、外部 Python スクリプトに基づくフィールドルックアップを定義する。 たとえば、与えられたホスト名に して IP アドレスを、与えられた IP アドレスに してホスト名を返す Python スクリプトを使ったルックアップを作成することができます。 時間を表すフィールド値を持つルックアップテーブルを利用して、時間ベースのルックアップを作成する。 たとえば、DHCP ログから、IP アドレスとイベントのタイムスタンプに基づいて、ネットワークのユーザー を識別する場合などに役立ちます。 詳細は、このマニュアルの「フィールドルックアップの設定」を参照してください。 ワ ー クフロ ー アクション ワークフローアクションを使って、データ内の特定のフィールドと他のアプリケーションや Web リソース間のや り取りを設定することができます。とても単純なワークフローアクションとして、たとえば IP_address フィール ドにワークフローアクションを関連付け、起動時に IP_address の値に基づいて、外部の WHOIS サーチを別のブ ラウザウィンドウに表示することができます。 また、以下のようなワークフローアクションを設定することもできます。 特定のフィールドのみに適用する (イベント内のすべてのフィールドではない)。 特定のイベントタイプまたはイベントタイプのグループに属するイベントにのみ適用する。 イベントドロップダウンメニュー、フィールドドロップダウンメニュー、またはその両方からアクセスされ たかを判断する。 HTTP GET リクエストを実行して、情報を外部 索エンジンや IP ルックアップサービスに渡す。 フィールド値を外部リソースに送信できる、HTTP POST リクエストを実行する。たとえば、ステータス値 を外部の問題追跡アプリケーションに送信するワークフローアクションを作成することができます。 選 したイベントからフィールド値を取得して、それらの値を設定した二次サーチを別のブラウザウィンドウ で実行する。 76 Splunk 管理を使ったワークフローアクションの設定については、この章の「Splunk Web を使ったワークフローア クションの作成と管理」を参照してください。 フィ ー ルドルックアップを使ったイベントへの情 報の追加 Splunk のルックアップ機能では、イベントデータ内のフィールドとマッチする外部 CSV ファイル内のフィールド を参照することができます。このマッチを使用して、他のサーチ可フィールドをイベントデータに追加すること で、データの価値をさらに高められます。一時フィールドや Python スクリプトの出力などを含め、任意のフィー ルドをベースにしたフィールドルックアップを実行することができます。 ここでは、Splunk Web の [管理] > [ルックアップ] にある、ルックアップ管理用ページの使用方法について 明して いきます。 既存のルックアップテーブルの表示または新しいファイルのアップロードを行います。 既存のルックアップ定義を編集、または新たにファイルベースのルックアップまたは外部ルックアップを定 義します。 既存の自動ルックアップの編集または新しい自動実行ルックアップの設定を行います。 ルックアップの詳細は、このマニュアルの「フィールドルックアップの設定」を参照してください。 既 存のルックアップテ ー ブルの表示または新しいファイルのアップ ロード [管理] > [ルックアップ] > [ルックアップテーブルファイル] で既存のルックアップテーブルを表示するか、または [新規] をクリックして、ファイルベースのルックアップに使用する CSV ファイルをアップロードします。 注意：改行コードが Macintosh 形式の CSV ファイルはサポートされていません。 新しいファイルをアップロードするには： 1. [宛先 App] を選 します。 これにより、ルックアップテーブルファイルが App のディレクトリに保存されます。 $SPLUNK_HOME/etc/users/<username>/<app_name>/lookups/. 2. ルックアップテーブルファイルの名前を指定します。 この名前を使ってルックアップ定義内でファイルを参照します。 3. アップロードする CSV ファイルを参照して、選 します。 4. [保存] をクリックします。 既 存のルックアップ定義の編集または新たなファイルベ ー スのルッ クアップまたは外部ルックアップの定義 [管理] > [ルックアップ] > [ルックアップ定義] ページを使って、ルックアップテーブルを定義したり、既存のルッ クアップ定義を編集することができます。ルックアップのタイプ (ファイルベースまたは外部)、および時間ベース かどうかを指定できます。ルックアップテーブルを定義したら、サーチ内でルックアップを実行 (lookup コマンド を使用)、またはルックアップを自動的に実施するように設定することができます。 注意：この作業は transforms.conf にルックアップを定義する場合と同じ意味を持っています。 時間ベースのルックアップの設定 フィールドの照合が時間情報 (ルックアップテーブル内のタイムスタンプを表すフィールド) に基づいている場合 は、フィールドベース/外部ルックアップを時間ベース (または一時) にすることもできます。 時間ベースのルックアップを設定するには、時間フィールド名を指定します。また、この時間情報の strptime フォーマットと時間照合用のオフセットを指定することもできます。 詳細オプションの設定 [詳細オプション] では、以下の事項を指定できます。 77 各入力ルックアップ値の最低一致数。 各入力ルックアップ値の最大一致数。 入力からの最低一致項目数未 の場合に出力するデフォルト値。 既 存の自動ルックアップの編集または新たなルックアップの設定 イベントにフィールドルックアップを適用する際に、lookup コマンドを実行する代わりに、ルックアップを自動 実行するように設定することができます。[管理] > [ルックアップ] > [自動ルックアップ] ページから、自動ルック アップを編集、設定することができます。 1. フィールドのルックアップに使用する、ルックアップテーブルファイルを選 します。 2. ルックアップを適用するホスト、ソース、ソースタイプ値を選 します。 3. ルックアップ入力フィールドに、1 つまたは複数のルックアップフィールド名とローカルフィールド名のペアを 指定します。 4. ルックアップ出力フィールドに、1 つまたは複数のルックアップフィールド名とローカルフィールド名のペアを 指定します。 5. 回ルックアップ実行時にフィールド値を上書きするかどうかを選 することもできます。 注意：この作業は、props.conf にフィールドルックアップを設定するのと同じ意味を持ちます。 HTTP ステ ー タスルックアップの例 この例では、Web アクセスイベントに 2 つの情報フィールド status_description と status_type を追加する、静 的ルックアップの定義方法を見ていきます。これにより、特定のエラーコードが分からないような場合に、目的の イベントをサーチすることができます。たとえば、すべてのサーバーエラーコードをサーチする代わり に、status="Server Error" を使用することができます。 Splunk へ の ル ッ ク ア ッ プ テ ー ブ ル の ア ッ プ ロ ー ド 1. http_status.csv ファイルをダウンロードします。 http_status.csv ファイルの例を以下に示します。 status,status_description,status_type 100,Continue,Informational 101,Switching Protocols,Informational 200,OK,Successful 201,Created,Successful 202,Accepted,Successful 203,Non-Authoritative Information,Successful ... 2. サーチ App に って、右上のナビゲーションメニューから [管理] を選 します。 3. [管理] > [ルックアップ] ビューで、[ルックアップテーブルファイル] の [新規追加] を選 します。 4. [管理] > [ルックアップ] > [ルックアップテーブルファイル] > [新規追加] で、以下の作業を行います。 宛先 App の [サーチ] を選 します。 78 先ほどダウンロードした CSV ファイルを選 します。 ルックアップテーブルに名前 http_status を指定します。 [保存] をクリックします。 Splunk がファイルを保存したら、次のビューが表示されます。 [管理] > [ルックアップ] ビューに ります。そのためには、ページのブレッドクラムにある [ルックアップ] リンクを クリックします。前のビューに るために、いつでもこれを利用することができます。 ルックアップの定義 1. [管理] > [ルックアップ] で、[ルックアップ定義] の [新規追加] を選 します。 [管理] > [ルックアップ] > [ルックアップ定義] > [新規追加] ビューで、以下の作業を行います。 2. [宛先 App] の [サーチ] を選 します。 3. ルックアップ定義に名前 http_status を指定します。 79 4. [タイプ] で、[ファイルベース] を選 します。 5. [保存] をクリックします。 Splunk がルックアップ定義を保存したら、次のビューが表示されます。 ルックアップ定義でいくつかのアクションを利用できることにお気づきでしょうか。[ 限] では、ルックアップ テーブルへのアクセス を 更することができます。ルックアップ定義を [無効]、[複製]、および別の App に [移動] することができます。また、定義を [削除] することができます。 ルックアップを定義したら、サーチに lookup コマンドを指定して実行したり、ルックアップを自動実行するよう に設定することができます。 ルックアップの自動実行の設定 1. [管理] > [ルックアップ] ビューで、[自動ルックアップ] の [新規追加] を選 します。 [管理] > [ルックアップ] > [自動ルックアップ] ビューで、以下の作業を行います。 2. [宛先 App] の [サーチ] を選 します。 3. ルックアップに名前 http_status を指定します。 4. [ルックアップテーブル] ドロップダウンから [http_status] を選 します。 5. ルックアップを access_combined と言う名前の sourcetype に適用します。 80 6. [ルックアップ入力フィールド] は、ルックアップテーブルと照合する、イベント内のフィールドです。ここで は、両方とも名前が status になっています (CSV 列名が左、照合するフィールドが右)。 7. [ルックアップ出力フィールド] は、イベントに追加するルックアップテーブルからのフィールドです (status_description と status_type)。CSV 列名が左、照合するフィールドが右になります。 8. [保存] をクリックします。 フィ ー ルドルックアップの設定 動的フィールドルックアップ機能を使用して、静的テーブル (CSV ファイル) や外部コマンド (Python) などの外部 ソースからの情報を持つフィールドを、イベントに追加することができます。また、時間情報の照合に基づいて、 フィールドを追加することもできます。 注意：改行コードが Macintosh 形式の CSV ファイルはサポートされていません。 たとえば、Splunk を使ってログインを監視しており、Splunk インデックス内にそれらのログインのタイムスタン プが存在している場合、動的フィールドルックアップを使って IP アドレスとタイムスタンプを、DHCP ログ内に 存在する一致する IP とタイムスタンプデータを使用して、MAC アドレスとユーザー情報にマップすることができ ます。 ルックアップは Splunk Web の [ルックアップ管理] ページを使って、または props.conf と transforms.conf 内に スタンザを指定して、設定することができます。ルックアップ管理の使用方法の詳細は、Splunk チュートリアル のルックアップに関するトピックを参照してください。ここでは、props.conf および transforms.conf を使った ルックアップの設定方法について 明していきます。 設定ファイルを使ってルックアップを設定するには： 重要：$SPLUNK_HOME/etc/system/default 内の設定ファイルは編集しないでください。代わり に、$SPLUNK_HOME/etc/system/local/ または $SPLUNK_HOME/etc/apps/<app_name>/local/ にあるファイルを編集 してください。ファイルが存在しない場合は、作成してください。 1. transforms.conf を編集して、ルックアップテーブルを定義します。 現在の所、静的ルックアップ (CSV ファイルを使用) と外部ルックアップ (Python スクリプトを使用) の 2 種類の ルックアップテーブルを定義できます。transforms スタンザに、引数を使って定義するルックアップテーブルのタ イプを指定します。静的ルックアップの場合は filename を、外部ルックアップの場合は external_cmd を使用しま す。 81 注意：ルックアップテーブルには、最低でも 2 列が必要です。各列には、同じ値の複数のインスタンスが存在する ことができます (複数値フィールド)。UTF8 以外の文字を入れることはできません (プレーン ASCII テキスト、お よび UTF8 で有効な任意の文字セットを使用できます)。 2. props.conf を編集して、ルックアップテーブルを適用します。 このステップは、静的ルックアップと外部ルックアップのどちらでも同じです。この設定ファイル に、transforms.conf で定義したルックアップテーブルからの、照合するフィールド (match) と出力フィールド (output、出力フィールドを上書きしない場合は outputnew) を指定します。 単一のソーススタンザに、複数のフィールドルックアップを定義することができます。各ルックアップには、一意 のルックアップ名を使用する必要があります (例：複数のテーブルがある場合に、LOOKUP-table1、LOOKUP-table2 のように命名するか、または他の一意の 明的な名前を指定できます)。 props.conf にルックアップを追加すると、ルックアップは自動実行されます。自動ルックアップが非常に低速な場 合、サーチ速度にも影響が出てしまいます。 3. 設定ファイルへの 更を反映するために、Splunk を再起動します。 再起動すると、フィールドサイドバーに、ルックアップテーブルからの output フィールドが表示されます。ここ から、一致するサーチ結果に表示するフィールドを選 することができます。 静 的ファイルに基づくフィ ー ルドルックアップの設定 もっとも単純なフィールドルックアップは、CSV ファイルなどの静的テーブルをベースにしています。CSV ファ イルは、以下のいずれかの場所に保管する必要があります。 $SPLUNK_HOME/etc/system/lookups/ $SPLUNK_HOME/etc/apps/<app_name>/lookups/ ルックアップディレクトリが存在していない場合は作成してください。 1. transforms.conf を編集して、ルックアップテーブルを定義します。 に、ルックアップテーブルを定義するスタンザを追加します。スタンザ名が、ルックアップテー ブル名になります。この 換は、props.conf で使用します。 transforms.conf このスタンザで、CSV ファイルの名前を参照します。 [myLookup] filename = <filename> max_matches = <integer> 必要に じて、イベントに適用する一致エントリ数を指定することができます。max_matches は、最初の <integer> 件のエントリを使用することを表しています (ファイルの順序で)。タイムスタンプフィールドに基づかないルック アップでは、max_matches のデフォルトは 100 になっています。 2. props.conf を編集して、ルックアップテーブルを適用します。 に lookup キーを指定したスタンザを追加します。このスタンザには、transforms.conf に定義した ルックアップテーブル、およびテーブルのイベントへの適用方法を設定します。 props.conf [<stanza name>] LOOKUP-<class> = $TRANSFORM <match_field_in_table> OUTPUT|OUTPUTNEW <output_field_in_table> は、props.conf に指定されている、このルックアップを適用するソースタイプ、ホスト、また はソースになります。 stanza name に正規表現構文を使用することはできません。 $TRANSFORM は、ルックアップテーブルを定義した transforms.conf 内のスタンザを参照します。 match_field_in_table は、値の照合に使用するルックアップテーブルの列です。 output_field_in_table は、イベントに追加するルックアップテーブルの列です。出力フィールドの既存の 値を上書きしない場合は、OUTPUTNEW を使用します。 ルックアップのどちら側にも、複数の列を使用できます。たとえば、$TRANSFORM <match_field1>, <match_field2> OUTPUT|OUTPUTNEW <match_field3>, <match_field4> と指定できます。また、1 つのフィー ルドが 2 つのフィールドを返したり、3 つのフィールドが 1 つのフィールドを返すように指定することもで きます。 stanza name ルックアップテーブル内のフィールド名とイベント内のフィールド名が一致しない、またはイベント内のフィール ド名を 更したい場合は、AS 句を使用します。 82 [<stanza name>] LOOKUP-<class> = $TRANSFORM <match_field_in_table> AS <match_field_in_event> OUTPUT|OUTPUTNEW <output_field_in_table> AS <output_field_in_event> 句の後に、複数のフィールドを指定することができます。OUTPUT|OUTPUTNEW を使用しない場 合、ルックアップテーブルからイベントにすべてのフィールド名と値が追加されます。 OUTPUT|OUTPUTNEW 3. Splunk を再起動します。 静的フィールドのルックアップ例 ここでは、access_combined ログの HTTP ステータスコードに するルックアップを設定する方法を見ていきま す。この例で、ルックアップテーブル (http_status.csv) 内の status フィールドを、イベント内のフィールドと 照合します。次に、イベントにステータスの 明とステータスタイプフィールドを追加します。 ファイルは以下のようになっています。このファイルを に保管します。サーチ App を使用している場合は、ファイルを $SPLUNK_HOME/etc/apps/search/lookups/ に保管してください。 http_status.csv $SPLUNK_HOME/etc/apps/<app_name>/lookups/ status,status_description,status_type 100,Continue,Informational 101,Switching Protocols,Informational 200,OK,Successful 201,Created,Successful 202,Accepted,Successful 203,Non-Authoritative Information,Successful 204,No Content,Successful 205,Reset Content,Successful 206,Partial Content,Successful 300,Multiple Choices,Redirection 301,Moved Permanently,Redirection 302,Found,Redirection 303,See Other,Redirection 304,Not Modified,Redirection 305,Use Proxy,Redirection 307,Temporary Redirect,Redirection 400,Bad Request,Client Error 401,Unauthorized,Client Error 402,Payment Required,Client Error 403,Forbidden,Client Error 404,Not Found,Client Error 405,Method Not Allowed,Client Error 406,Not Acceptable,Client Error 407,Proxy Authentication Required,Client Error 408,Request Timeout,Client Error 409,Conflict,Client Error 410,Gone,Client Error 411,Length Required,Client Error 412,Precondition Failed,Client Error 413,Request Entity Too Large,Client Error 414,Request-URI Too Long,Client Error 415,Unsupported Media Type,Client Error 416,Requested Range Not Satisfiable,Client Error 417,Expectation Failed,Client Error 500,Internal Server Error,Server Error 501,Not Implemented,Server Error 502,Bad Gateway,Server Error 503,Service Unavailable,Server Error 504,Gateway Timeout,Server Error 505,HTTP Version Not Supported,Server Error 1. $SPLUNK_HOME/etc/system/local/ または $SPLUNK_HOME/etc/apps/<app_name>/local にある transforms.conf ファ イルに、以下の項目を指定します。 [http_status] filename = http_status.csv 2. $SPLUNK_HOME/etc/system/local/ または $SPLUNK_HOME/etc/apps/<app_name>/local/ にある props.conf ファイ ルに、以下の項目を指定します。 [access_combined] LOOKUP-http = http_status status OUTPUT status_description, status_type 3. Splunk を再起動します。 これで、Web アクセス情報を返すサーチを実行すると、フィールドサイドバーメニューに status_description お よび status_type が表示されるようになります。 83 サ ー チ結果を使ったルックアップテ ー ブルの設定 ローカルまたは App 固有の savedsearches.conf を編集して、保存 みサーチの結果をルックアップテーブルに設定 することができます。 サーチが結果を返す保存 みサーチのスタンザで、以下の作業を行います。 1. ルックアップ設定アクションを有効にするために、以下の行を追加します。 action.populate_lookup = 1 これにより、結果テーブルが CSV ファイルに保存されます。 2. ルックアップテーブルのコピー場所を指示するために、以下の行を追加します。 action.populate_lookup.dest = <string> の値は transforms.conf のルックアップ名、またはサーチ結果をコピーした CSV ファイルへのパスになります。CSV ファイルへのパスを指定する場合、パスは$SPLUNK_HOME からの相 パス で指定します。 action.populate_lookup.dest たとえば、グローバルルックアップテーブルに結果を保存する場合は、以下のように指定します。 action.populate_lookup.dest = etc/system/lookups/myTable.csv 宛先ディレクトリ $SPLUNK_HOME/etc/system/lookups または $SPLUNK_HOME/etc/<app_name>/lookups は、すでに存 在していなければなりません。 3. Splunk 起動時にこのサーチを実行する場合は、以下の行を追加します。 run_on_startup = true 起動時に実行しない場合は、次回のスケジュール時刻に実行されます。一般的に、ルックアップテーブルを設定す るスケジュール みサーチに しては、true を設定することをお勧めします。 保存 みサーチの結果は CSV ファイルにコピーされるため、フィールドルックアップは静的ファイルと同じ方法で 設定することができます。 外部コマンドまたはスクリプトに基づくフィ ー ルドルックアップの 設定 動的または外部ルックアップの場合、transforms.conf のスタンザでは実行するコマンドまたはスクリプトと引数 を参照します。これは、スクリプト化/外部ルックアップと呼ばれることもあります。 実行するコマンドやスクリプトのタイプを指定することもできます。 [myLookup] external_cmd = <string> external_type = python fields_list = <string> max_matches = <integer> 外部コマンドがサポートするすべてのフィールドを記載するには、fields_list をカンマで区切って指定します。 注意：現在外部ルックアップでは、Python スクリプトのみがサポートされています。ルックアップに使用する Python スクリプトは、以下のいずれかの場所または両方に保管する必要があります。 $SPLUNK_HOME/etc/apps/<app_name>/bin $SPLUNK_HOME/etc/searchscripts 注意： Python スクリプトを作成する際に、外部リソース (ファイルなど) を参照する場合は、スクリプトが存在す るディレクトリからの相 パスで指定する必要があります。 外部フィールドのルックアップ例 この例では、外部ルックアップを使った DNS サーバーからの情報の照合方法について見ていきます。Splunk に は、$SPLUNK_HOME/etc/system/bin/ に DNS ルックアップスクリプト external_lookup.py が用意されています。 84 ホスト名を渡すと IP アドレスが返されます。 IP アドレスを渡すとホスト名が返されます。 1. transforms.conf ファイルに、以下の項目を指定します。 [dnsLookup] external_cmd = external_lookup.py host ip fields_list = host, ip 2. props.conf ファイルに、以下の項目を指定します。 [access_combined] LOOKUP-dns = dnsLookup host OUTPUT ip AS clientip ルックアップテーブル内のフィールド名は ip ですが、Splunk は Web アクセスログから自動的に IP アドレスを抽 出して、clientip フィールドに書き込みます。つまり、「OUTPUT ip AS clientip」は、ルックアップテーブルの ip フィールドの値を、イベント内の clientip フィールドに追加することを表しています。ルックアップテーブル とイベント内で host フィールド名は同じなので、フィールド名を 更する必要はありません。 逆引き DNS ルックアップに して、props.conf スタンザは以下のようになります。 [access_combined] LOOKUP-rdns = dnsLookup ip AS clientip OUTPUTNEW host AS hostname この例では、host フィールド値を上書きせずに、返されたホスト値を新たなフィールド hostname に書き込みま す。 3. Splunk を再起動します。 外部ルックアップスクリプトの詳細 外部ルックアップスクリプトを設計する場合、そのスクリプトは一部が空の CSV ファイルを受け取り、それに記 入した CSV ファイルを出力する必要があることを忘れないようにしてください。スクリプトに渡す引数は、これ らの入出力ファイルのヘッダーになります。 上記の DNS ルックアップの例では、CSV ファイルには 2 つのフィールド「host」と「ip」が含まれています。こ のスクリプトに渡すフィールドは、transforms.conf に指定したフィールドです。 external_cmd = external_lookup.py host ip 注意：これらの引数を渡さないと、スクリプトからはエラーが返されます。 以下のサーチコマンドを実行した場合： ... | lookup dnsLookup host これは transforms.conf に [dnsLookup] として定義されているルックアップテーブルを使用して、外部コマンドス クリプトに「host」フィールドの値を CSV ファイルとして渡すことを表しています。以下に例を示します。 host,ip work.com home.net 基本的に、これはヘッダーが「host」と「ip」の CSVファイルですが、ip の値がありません。これらの 2 つの ヘッダーが含まれているのは、それが transforms.conf の fields_list パラメータに指定されているフィールドだ からです。 スクリプトは、以下のような CSV ファイルを出力し、それを Splunk に返します。Splunk は、結果に ip フィール ドを設定します。 host,ip work.com,127.0.0.1 home.net,127.0.0.2 時間ベ ー スのフィ ー ルドルックアップの設定 静的/外部ルックアップテーブルに、時間を表すフィールド値がある場合、その時間フィールドを使用するフィー ルドルックアップを設定できます。時間ベースのルックアップの場合は、transforms.conf のルックアップスタン ザに以下の行を追加します。 85 time_field = <field_name> time_format = <string> が存在している場合、デフォルトの max_matches は 1 になります。また、最初に一致したエントリが 降順に適用されます。 time_field strptime フォーマットの time_field を指定するには、time_format を使用します。デフォルトでは、time_format は UTC になります。 時間ベースのルックアップで照合を行うためには、最小/最大時間量のオフセットも指定する必要があります。こ のためには、スタンザに以下の行を追加します。 max_offset_secs = <integer> min_offset_secs = <integer> デフォルトでは、最大オフセットは設定されておらず、最小オフセットは 0 になります。 時間ベースのフィールドルックアップの例 この例では、DHCP ログを使って、IP アドレスとタイムスタンプに基づいて、ネットワーク上のユーザーを識別 する方法を見ていきます。DHCP ログがファイル dhcp.csv に保存されている場合を考えてみましょう。このファ イルには、タイムスタンプ、IP アドレス、およびユーザー名と MAC アドレスが含まれています。 1. transforms.conf ファイルに、以下の項目を指定します。 [dhcpLookup] filename = dhcp.csv time_field = timestamp time_format = %d/%m/%y %H:%M:%S 2. props.conf ファイルに、以下の項目を指定します。 [dhcp] LOOKUP-table = dhcpLookup ip mac OUTPUT user 3. Splunk を再起動します。 ルックアップのトラブルシュ ー ティング - ルックアップスタンザで 同一の名前を使用 ルックアップテーブルは、LOOKUP-<name> 属性に指定します。一般的には、問題が発生しないように、すべての ルックアップスタンザに別の名前を使用することが理想です。複数のルックアップに同じ名前を指定すると、自分 が行っていることの仕組みを理解していない限り問題が発生する可能性があります。 同名の複数のルックアップが同じスタンザを共有している場合 (同じホスト、ソース、またはソースタイ プ)、fields.conf のそのスタンザ内の最初のルックアップが、他のルックアップに優先されます。同じホス ト、ソース、またはソースタイプを持つルックアップには、異なる名前を使用する必要があります。 異なるスタンザを持つ (ホスト、ソース、またはソースタイプが異なる) 同じ名前を共有するルックアップが ある場合、その時点でそれらのいずれか 1 つのみが適用されることになります。故意にそのような設定を行 う場合もありますが、たいていの場合そのような設定は不便です。 たとえば、名前「table」を共有する以下の 2 つのルックアップがある場合を考えてみましょう。 [host::machine_name] LOOKUP-table = logs_per_day host OUTPUTNEW average_logs AS logs_per_day [sendmail] LOOKUP-table = location host OUTPUTNEW building AS location これらの 2 つのルックアップがオーバーラップするイベントでは、片方のみが有効になります。別の言い方をする と： ホストが一致したイベントは、ホスト (host) ルックアップが適用されます。 ソースタイプが一致したイベントは、ホスト (sourcetype) ルックアップが適用されます。 両方が一致したイベントは、ホスト (host) ルックアップのみが適用されます。 ルックアップ LOOKUP-table に名前を指定する場合、それは「table」により記述されている、目的またはアクショ ンを実行するルックアップであることを表しています。この例で、これらのルックアップには異なる用途が想定さ 86 れています。片方は、日当たりのログに関する事項を判断し、もう一方は場所に関する処理を行う目的で用意され ています。これらを以下のような名前に 更することができます。 [host::machine_name] LOOKUP-table = logs_per_day host OUTPUTNEW average_logs AS logs_per_day [sendmail] LOOKUP-location = location host OUTPUTNEW building AS location これで、競合しない 2 つの異なる設定が完成しました。 Splunk 管理を使ったワ ー クフロ ー アクションの作 成と管理 ワークフローアクションを使って、インデックスフィールドと他の Web リソース間のやり取りを有効にすること ができます。ワークフローアクションは多彩な用途に用いられます。たとえば、以下のようなワークフローを定義 することができます。 イベント内に見つかった IP アドレスに基づいて、外部 WHOIS ルックアップを実行する。 HTTP エラーイベント内のフィールド値を使って、外部問題管理システム内に新しいエントリを作成する。 イベント内に見つかった特定のフィールドの値で、外部 索 (Google など) を実行する。 選 したイベントの 1 つまたは複数のフィールド値を使用して、二次サーチを実行する。 他にも、以下のようなワークフローアクションを定義できます。 特定のフィールドまたはフィールドセットを含む、または特定のイベントタイプに所属するイベントをター ゲットにする。 サーチ結果のフィールドメニューまたはイベントメニューに表示する。特定のフィールドのメニュー、また は特定のイベントのすべてのフィールドメニューに表示するように設定することもできます。 選 した場合に、現在のウィンドウまたは新たなウィンドウに表示する。 Splunk 管理を使ったワ ー クフロ ー アクションの定義 この章の始めに記載したようなワークフローアクションやその他のワークフローアクションはすべて、Splunk 管 理を使って設定することができます。まず、[管理] > [フィールド] > [ワークフローアクション] に移動します。 [ワークフローアクション] ページでその名前をクリックすると、既存のワークフローアクションをレビュー、更新 することができます。[新規追加] をクリックして、新しいワークフローアクションを作成することもできます。ど ちらの場合も、ワークフローアクションの詳細ページが表示されます。このページでは、個別のワークフローアク ションを定義することができます。 新たなワークフローアクションを作成する場合は、[名前] と [宛先 App] を指定する必要があります。 3 種類のワークフローアクションを設定することができます。 GET ワークフローアクション：特定の値の Google 索の実行、外部 WHOIS データベースへのドメイン名の 照会などを実行するための、一般的な HTML リンクを作成します。 POST ワークフローアクション：指定した URI への HTTP POST リクエストを生成します。このタイプで は、一連の関連するフィールド値を使って、外部問題管理システム内のエントリを作成するなどの作業を行 えます。 サーチワークフローアクション：指定した時間範 の、インデックス内の特定の ipaddress と http_status の 組み合わせを探すサーチなど、イベントの特定のフィールド値を使って二次サーチを実行します。 特定のイベントグル ー プへのワ ー クフロ ー アクションのタ ー ゲット 設定 Splunk 管理でワークフローアクションを作成する場合、必要に じて特定のイベントグループをワークフローアク ションのターゲットにすることができます。ワークフローアクションの適用範 は、フィールド、イベントタイ プ、または両者を組み合わせて制限することができます。 フィールドによるワークフローアクション適用範 の制限 特定のフィールドまたは一連のフィールドを持つイベントにのみ、ワークフローを適用することができます。たと えば、http_status フィールドを持つイベントにのみワークフローアクションを適用したい場合は、[次のフィール ドにのみ適用] 設定に http_status を指定します。 87 一連のフィールドセットを持つイベントにのみワークフローアクションを適用する場合は、[次のフィールドにの み適用]にそれらのフィールドをカンマで区切って指定します。 複数のフィールドが指定されている場合は、イベ ント内にすべてのフィールドが存在する場合にのみ、ワークフローアクションが表示されます。 たとえば、ip_client および ip_server フィールドを持つイベントにのみ、ワークフローアクションを定義する場 合を考えてみましょう。そのためには、[次のフィールドにのみ適用] に「ip_client, ip_server」と入力します。 ワークフローアクションのフィールド指定による適用制限には、ワイルドカードのアスタリスクを使用することも できます。たとえば、単純に「ip_*」と指定すると、ip_client または ip_server、またはその両方を持つイベン ト (および他の ip_* に一致するフィールドを持つ任意のイベント) に してワークフローアクションが適用されま す。 デフォルトでは * が指定されていると仮定されます。この場合、すべてのフィールドが一致になります。 より複 な設定を行う必要がある場合は、フィールドの代わりに、またはフィールドと組み合わせて、イベントタ イプによる適用制限を設定します。 イベントタイプによるワークフローアクション適用範 の制限 イベントタイプによる適用範 の制限は、フィールドの場合と同じように機能します。[次のイベントタイプにのみ 適用] には、単一のイベントタイプまたはカンマで区切って複数のイベントタイプを指定して、指定した 1 つまた は複数のイベントタイプに所属するイベントにのみ、ワークフローアクションを適用することができます。また、 ワイルドカードを使って、それに該当するイベントタイプに所属するイベントにのみ適用することもできます。 フィールドとイベントタイプを組み合わせて適用範 を制限することもできます。たとえば、http_status が 500 以上の場合にのみ、http_status フィールドを含むイベントにワークフローアクションを表示することができま す。このためには、まず目的のイベントに するサーチを持つ以下のようなイベントタイプ errors_in_500_range を設定します。 http_status >= 500 次に、[次のフィールドにのみ適用] に「http_status」を、[次のイベントタイプにのみ適用] に 「errors_in_500_range」を設定します。 イベントタイプの詳細は、このマニュアルの「イベントタイプについて」を参照してください。 フィ ー ルドおよびイベントメニュ ー へのワ ー クフロ ー アクションの 表示設定 ワークフローアクションを正しく設定すると、サーチ結果のフィールドやイベントに関連するドロップダウンメ ニューにそれが表示されます。たとえば、イベント内の topic フィールドの値を Google で 索するワークフローア クションを定義することができます。(topic フィールドには、Splunk マニュアルのトピックへのアクセスに関連 する Web サーバーイベントに登場します。これの値には、特定の Splunk マニュアルのトピック名が保管されて います。) Splunk 管理での Google サーチワークフローの定義方法によっては、topic フィールドを含むイベントのフィール ドメニューにそれを表示することができます。 代わりに、ワークフローアクションを、イベントのイベントメニューに表示することもできます。 88 また、topic を持つイベントの、イベントメニューとフィールドメニューの両方に表示することも可能です。 上記のイベントでは、topic フィールドの値は「LicenseManagement」であることに注意してください。このイベ ントのメニューには、ワークフローアクション「Google LicenseManagement」が表示されます。このワークフ ローアクションをクリックすると、用語「LicenseManagement」の Google 索が実行されます。これは、GET リ ンクワークフローアクションの例です。これは、Splunk に用意されている 3 種類のワークフローアクションの 1 つにしか過ぎません。3 種類すべてを利用するには、該当する 明を参照してください。 GET ワ ー クフロ ー アクションの設定 GET リンクワークフローは、HTML リンクに 1 つまたは複数の値を渡します。リンクをクリックすると、ブラウ ザで HTTP GET リクエストが実行され、情報が外部 索エンジンや IP ルックアップサービスなどの外部 Web リ ソースに渡されます。 GET ワークフローアクションを定義するには、詳細ページで [アクションタイプ] に「リンク」を、[リンク方法] に「GET」を設定します。次に、適切な [ラベル] と [URI] を定義します。 注意：URI 由で GET アクションに渡される 数は、伝送時に自動的に URL にエンコードされます。この場合、単 語や区切り文字の間にスペースがある値を含めることができます。ただし、HTTP アドレスを値として持つフィー ルドを使用し、フィールド値全体を URI として渡す場合は、フィールド値がエスケープ処理されないように、$! プリフィックスを使用する必要があります。詳細は、後述する「URL または HTTP フォームフィールド値のエス ケープ処理を防止するための $! プリフィックスの使用」を参照してください。 サーチ結果の topic フィールドの値に基づいて、Google 索を実行する GET リンクワークフローの設定例を以下 に示します。 [ラベル] フィールドには、フィールド/イベントメニューに表示するテキストを指定します。静的なラベル、また は関連フィールドの値を入れることができます。たとえば、イベント内に topic フィールドが存在しており、その 値を Google ワークフローアクションに入れたい場合は、[ラベル] に Google $topic$ を設定します。 上記の例で、イベント内の topic が CreatefieldactionsinSplunkWeb の場合、topic フィールドメニューにワーク フローアクションが「Google CreatefieldactionsinSplunkWeb」と表示されます。 [URI] フィールドには、フィールド値を送信する外部リソースの場所を指定します。[ラベル] 設定と同 に、フィー ルドの値を指定する場合は、フィールド名をドル記号で みます。上記の例で、この URI は GET メソッドを使って topic の値を Google に渡して 索を行います。 ワークフローアクションをイベントメニューに表示するか、フィールドメニューに表示するか、または両方に表示 するかを指定することができます。また、リンクを現在のウィンドウに表示するか、または新しいウィンドウに表 示するかを指定することもできます。 また、特定のイベントセットにのみワークフローアクションを適用することも可能です。ワークフローアクション を、特定のフィールドセットを持っているイベントのみに表示することも、特定のイベントタイプ (または複数の 89 イベントタイプ) に所属するイベントに表示することも可能です。 例 - 外 部 IP ル ッ ク ア ッ プ の 設 定 あなたは Web サービスログ内のドメイン名を抽出して、それを domain フィールドに指定するように Splunk App を設定しました。外部の WHOIS データベースをサーチして、それらのドメインの詳細な情報を取得したいと考え ています。 ここでは、これを実現するための GET ワークフローアクションの設定方法について見ていきます。 ワークフローアクションの詳細ページで [アクションタイプ] に「リンク」を、[リンク方法] に「GET」を設定しま す。 次に、[ラベル] および [URI] フィールドを使って、目的のフィールドを指定します。[ラベル] に、「WHOIS: $domain$」を設定します。[URI] に「http://whois.net/whois/$domain$」を設定します。 その後、以下の事項を決定します。 リンクをフィールドメニューに表示するか、イベントメニューに表示するか、または両方に表示するか。 リンクをクリックした時に WHOIS サーチを同じウィンドウに表示するか、または新たなウィンドウに表示 するか。 ワークフローアクションリンクを表示するイベントを制限するかどうか。ワークフローアクションのター ゲットを、特定のフィールドを持つイベント、特定のイベントタイプに属するイベント、または両者の組み 合わせなどで制限することができます。 POST ワ ー クフロ ー アクションの設定 POST ワークフローアクションは、GET リンクアクションと同じように設定することができます。ワークフロー アクションの詳細ページで、[アクションタイプ] に「リンク」を、[リンク方法] に「POST」を、[ラベル] と [URI] にはそれぞれ適切な値を指定します。 ただし、一般的に POST リクエストは HTML 内の form エレメントとして定義され、一部の入力が POST の引数 に 換されます。そのため、指定した URI に送信する POST 引数を指定する必要があります。 注意：URI 由で POST アクションに渡される 数は、伝送時に自動的に HTTP 形式 にエンコードされます。この 場合、単語や区切り文字の間にスペースがある値を含めることができます。ただし、HTTP アドレスを値として持 つフィールドを使用し、フィールド値全体を URI として渡す場合は、フィールド値がエスケープ処理されないよ うに、$! プリフィックスを使用する必要があります。詳細は、後述する「URL または HTTP フォームフィールド 値のエスケープ処理を防止するための $! プリフィックスの使用」を参照してください。 これらの引数は、POST リクエストに 答する Web リソースに送信されるキーと値の組み合わせです。引数のキー と値の両方に して、フィールド名をドル記号で んで、リソースに送信するイベントのフィールド値を指定するこ とができます。1 つの POST ワークフローアクション内に複数のキー/値のペアを定義することができます。 例 - http エ ラ ー を 使 っ た 問 題 追 跡 ア プ リ ケ ー シ ョ ン 内 の エ ン ト リ の 作 成 Web サービスログの HTTP ステータスコードを抽出して、http_status フィールドに設定することができます。 一般的にイベントには、http_status とともに、標準の 1 行の記述リクエスト、またはエラーを生成する python プロセスからの複数行の python スタックトレースが含まれます。 ここでは、http_status が 500 番台のエラーイベントに してのみ表示されるワークフローアクションを作成しま す。ワークフローアクションには、関連する python スタックトレースと HTTP ステータスコードを、外部問題管 理システムに送信して、新たなバグレポートを生成させます。ただし、問題管理システムは、特定のエンドポイン トへの POST リクエストしか受け付けません。 ここでは、以上の要件を たす POST ワークフローアクションの設定方法を以下に示します。 90 最初の POST 引数は、server error $http_status$ を外部問題追跡システムの title フィールドに送信しま す。http_staus が 500 のイベントに してこのワークフローアクションを設定した場合、問題追跡システムに server error 500 と言うタイトルの問題が設定されます。 2 番目の POST 引数は、_raw フィールドを使って新しい問題の description フィールドに、複数行の python ス タックトレースを設定します。 最後に、ワークフローアクションは、errors_in_500_range イベントタイプに所属するイベントに してのみ適用さ れるように設定されていることに注意してください。これは、典型的な HTTP エラー 500 番台以上の http_error 値を保有しているイベントにのみ適用されるイベントタイプです。500 番台未 の HTTP エラーコードを持つイベ ントのイベント/フィールドメニューには、「submit error report」ワークフローアクションは表示されません。 イベントからのフィ ー ルド値を動的に記入する二次サ ー チの設定 動的に設定した二次サーチを起動するワークフローアクションを設定するには、まずワークフローアクションの詳 細ページで [アクションタイプ] に「サーチ」を設定します。これにより、特定の二次サーチの定義に使用できる 一連のサーチ設定フィールドが表示されます。 [サーチ文字列] に、フィールド値のプレースホルダを含む 1 つまたは複数のサーチ文字列をドル記号で んで指定 します。たとえば、イベントに登場するクライアント IP をサーチするワークフローアクションを設定する場合、 そのフィールドには単に clientip=$clientip$ と入力します。 サーチを実行する App を指定します。現在のビュー以外の App でサーチを実行する場合は、そのビューを選 しま す。すべてのワークフローアクションと同 に、現在のウィンドウに表示するか、または新たなウインドウに表示 するかを指定することもできます。 [もっとも早い時間] および [もっとも い時間] フィールドに相 時間範 を指定して、サーチの時間範 を忘れずに設定 (またはフィールドリストを作成したのと同じ時間範 を使用) してください。これらのフィールドが空欄の場合 は、デフォルトではすべての時間に してサーチが実行されます。 最後に、他のワークフローアクションタイプと同 に、ワークフローアクションを特定のフィールドセットを持 つ、または特定のイベントタイプに属するイベントにのみ適用することができます。 例 - 特 定 の Ruby On Rails コ ン ト ロ ー ラ に 起 因 す る エ ラ ー を 探 す サ ー チ の 実 行 Ruby On Rails を利用した Web インフラを使用している場合を考えてみましょう。Ruby コントローラに関するエ ラーのみを分類するイベントタイプを設定しましたが (controller_error)、特定のコントローラに関連するエラー のみを表示したい場合もあります。ここでは、以下の処理を行うワークフローアクションの設定方法を見ていきま す。 1. ワークフローアクションの詳細ページで、[ラベル] に See other errors for controller $controller$ over past 24h を指定したアクションを設定します。 91 2. [アクションタイプ] に「サーチ」を設定します。 3. [サーチ文字列] に sourcetype=rails controller=$controller$ error=* を入力します。 4. [もっとも早い時間] に「-24h」を設定します。[もっとも い時間] は空欄のままにしてください。 5. [次の にのみ適用] 設定を使用して、error および controller フィールドのみを保有する、controller_error イ ベントタイプに所属するイベントにのみワークフローアクションを表示するように設定します。 これらは基本事項です。ワークフローアクションを実行する App やビューを設定したり (たとえば、この情報につ いて ruby_errors と言うタイトルの専用のビューを用意できます)、現在のウィンドウでアクションを実行する か、または新たなウィンドウを開いて実行するかを指定することができます。 ワ ー クフロ ー アクションでの特別なパラメ ー タの使用 Splunk には、「@」で始まるワークフローアクション用の特殊パラメータが用意されています。これらの特殊パ ラメータの中の 2 つはフィールドメニュー専用です。それらを利用して、 象イベント内のすべてのフィールドに 適用するワークフローアクションを設定できます。 @field_name - クリックされたフィールド名を参照します。 @field_value - クリックされたフィールドの値を参照します。 その他の特殊パラメータを以下に示します。 @sid - イベントを返したサーチジョブの SID を参照します。 @offset - サーチジョブのイベントのオフセットを参照します。 @namespace - サーチジョブがディスパッチされた名前空間を参照します。 @latest_time - 最後にイベントが発生した時金を参照します。類似のイベントを区別するために用いられま す。すべてのフィールドで常に利用できる訳ではありません。 例 - イベント内のすべてのフィールドに適用するワークフローアクションの作成 92 上記の Google 索例 (GET リンクワークフローアクション) を更新して、適用するイベントの各フィールドの フィールド名とフィールド値を 索できるようにすることができます。この場合は、タイトルを Google this field and value に 更して、アクションの URI を http://www.google.com/search?q=$@field_name$+$@field_value$ に 置換します。 このワークフローアクションは、フィールドメニューに表示される任意のフィールド/値のペアを 索しま す。topic=WhatisSplunkknowledge のフィールドメニューを参照して、「Google this field and value」フィール ドアクションを選 すると、Google で「topic WhatisSplunkknowledge」が 索されます。 注意： @field_name や @field_value パラメータを使用するワークフローアクションは、イベントレベルのメ ニューとは互換性がありません。 例 - イベントのソースの表示 このワークフローアクションは、他の特殊パラメータを使って raw データ内のイベントのソースを表示します。 [アクションタイプ] は [リンク]、[リンク方法] は [GET] を指定します。[タイトル] には、「Show source」を指定 します。[URI] は /app/$@namespace$/show_source?sid=$@sid$&offset=$@offset$&latest_time=$@latest_time$ です。_cd, source, host, index フィールドを持つイベントを 象にします。. ご利用の App にワークフローアクションを設定し (まだインストールしていない場合)、どのように動作するのか をご確認ください。 URL または HTTP フォ ー ムフィ ー ルド値のエスケ ー プ 処 理を防止す るための $! プリフィックスの使用 ワークフローアクションで使用するフィールドを定義する場合、しばしば安全に HTTP で外部エンドポイントに 渡すために、フィールドをエスケープ処理しなければならないことがあります。このエスケープ処理が望ましくな い場合もあります。このような場合、$! プリフィックスを使用して、Splunk によるフィールド値の自動エスケー プ処理を防止することができます。GET ワークフローアクションの場合は、これで URL のエスケープ処理を防止 できます。POST ワークフローアクションの場合は、HTTP のエスケープ処理が防止されます。 例 - HTTP ア ド レ ス を 別 の ブ ラ ウ ザ ウ ィ ン ド ウ に 渡 す 完全な HTTP アドレスを値に持つ、http フィールドを処理する GET ワークフローアクションを考えてみましょ う。このワークフローアクションは単純に、http フィールドの HTTP アドレスを指す新しいブラウザウィンドウ を開くようになっています。HTTP アドレスがエスケープ処理されていると、これは機能しません。そのため、プ リフィックス $! を使用します。通常このワークフローアクションのために、Splunk 管理で [URI] に $http$ を設 定しますが、HTTP アドレスのエスケープ処理を防止するために今回は $!http$ を設定します。 actions.conf を使ったワ ー クフロ ー アクションの設 定 まもなく 載予定。それまでの間は、Splunk 管理を使ったワークフローアクションの設定と管理方法を参照してく ださい。 デ ー タの正規化：タグとエイリアス タグとエイリアスについて データ内で、関連するフィールド値でイベントをグループ化している場合があります。特定のイベントデータグ ループを効率的にサーチするために、フィールド値にタグを割り当てることができます。任意のフィールド/値の 組み合わせに、1 つまたは複数のタグを割り当てられます (イベントタイプ、ホスト、ソース、またはソースタイ プを含む)。 以下の目的でタグを利用できます。 IP アドレスや ID 番号などの、抽象型フィールド値を追跡する。たとえば、メインオフィスで 192.168.1.2 の IP アドレスを使用している場合があります。IPaddress の値にタグ「mainoffice」を設定すれば、そのタグを 使ってその IP アドレスを持つイベントをサーチできます。 1 つのタグを使って一連のフィールド値をグループ化することで、簡単なコマンド 1 つでそれらのサーチを 行えます。たとえば、同じコンピュータに関連する 2 つのホスト名が存在していることがあります。このよ うな場合に、両方の値に同じタグを設定できます。そのタグをサーチすれば、両方のホスト名を持つイベン 93 トが返されます。 特定の抽出されたフィールドに、それらの特徴をさまざまな 点から表した複数のタグを付けることで、タグ に基づくサーチを実行し、素早く目的の結果を探し出すことができます。これを理解するために、以下の例 をご覧ください。 例： 社内イントラネットのデータソースの IP アドレスを表す抽出されたフィールド IPaddress を考えてみましょう。 各 IP アドレスにその職務や場所に じたタグを設定することで、IPaddress を有効活用することができます。ルー ターの IP アドレスにタグ「router」を設定できます。また、各 IP アドレスに「SF」や「Building1」のような場所 に基づいたタグを設定することもできます。サンフランシスコ (San Francisco) の建物 1 に存在するルーターの IP アドレスには、タグ「router」、「SF」、および「Building1」が設定されます。 サンフランシスコの Building1 以外にあるすべてのルーターをサーチするには、以下のように指定します。 tag=router tag=SF NOT (tag=Building1) Splunk Web でのフィ ー ルド値のタグとエイリアス 設定 データ内で、関連するフィールド値でイベントをグループ化している場合があります。これらのフィールドのグ ループを効率的にサーチするために、フィールド値にタグを割り当てることができます。抽出された任意のフィー ルドに、1 つまたは複数のタグを割り当てられます (イベントタイプ、ホスト、ソース、またはソースタイプを含 む)。 詳細は、『ナレッジ管理』の「タグとエイリアスについて」を参照してください。 フィ ー ルド値のタグとエイリアスの設定方法 フィールド/値のペアにタグを設定することができます。また、フィールド名のエイリアスを設定することもでき ます。 フィールド値のペアのタグ設定 Splunk Web を使って、サーチ結果から任意のフィールド値のペアに直接タグを設定できます。タグを設定する任 意のフィールド値のペアを持つイベントで、目的のフィールド値の隣にある矢印をクリックしてください。ドロッ プダウンメニューに値のタグを設定するオプションが表示されます。たとえば、syslog ソースタイプを選 する と、以下のように表示されます。 フィールド値のペアに して [タグ] を選 したら、1 つまたは複数のタグを [このフィールドにタグ付け] ウィンドウ に追加できます。 注意： [タグ] に指定する値は、二重引用符で まないでください。 フィールド名のエイリアス設定 フィールド名に複数のエイリアスを設定したり、フィールドのエイリアスを使用して異なるフィールド名を正規化 したりできます。エイリアスを設定しても、元のフィールド名が 更されたり、削除されることはありません。 フィールドにエイリアスを設定したら、そのエイリアスを使ってサーチを実行することができます。フィールド名 94 にエイリアスを設定するには、props.conf にアクセスする必要があります。詳細は、『ナレッジ管理マニュアル』 の「フィールドのエイリアスの作成」を参照してください。 タグ設定した値のサ ー チ タグのサーチには 2 種類の方法があります。任意のフィールドの値に関連するタグをサーチする場合は、以下の構 文を使用できます。 tag=<tagname> 特定のフィールドの値に関連するタグをサーチする場合は、以下の構文を使用できます。 tag::<field>=<tagname> ワイルドカードを使用したタグのサーチ イベントタイプやタグを含め、キーワードやフィールド値をサーチする場合、ワイルドカード文字のアスタリスク (*) を使用することができます。 たとえば、各種 IP アドレスに して複数のイベントタイプタグがある場合 (IP-src や IP-dst など)、以下のように 指定してそれらのすべてをサーチすることができます。 tag::eventtype=IP-* タグに「local」を含むすべてのホストを探す場合は、以下のようにタグをサーチします。 tag::host=*local* タグのないイベントタイプを持つイベントをサーチする場合は、論理演算式を使用します。 NOT tag::eventtype=* タグの無 効 化と削除 不要なタグがある場合、または特定のフィールドにタグを関連付けたい場合、タグを無効化または削除することが できます。以下の作業を行えます。 サーチ App を使って、特定のフィールド値のタグ関連付けを削除する。 Splunk 管理を使って、複数のフィールド値に関連付けられている場合でも、タグを無効化または削除する。 Splunk 管理を使ったタグの管理方法の詳細は、『ナレッジ管理』マニュアルの「タグの定義と管理」を参照して ください。 サーチ結果内の特定のフィールド値のタグ関連付けの削除 サーチ結果内の特定のフィールド値へのタグの関連付けが不要な場合は、そのフィールド/値のぺふの隣にある矢 印をクリックして、ドロップダウンメニューを表示します。[[フィールド名]=[値] タグ] を選 すると、[このフィー ルドにタグ付け] ウィンドウが表示されます。 [タグ] フィールドから無効にするタグを削除して、[保存] をクリックします。システムから特定のタグとフィール ドの関連付けが削除されます。タグがそのフィールド値にのみ関連付けられていた場合は、システムからタグが削 除されます。 ソ ー スタイプ名の 更 props.conf でソースタイプを設定する場合、ソースタイプ名を 更することができます。複数のソースタイプが同 じ名前を共有することができます。このことは、サーチ目的で一連のソースタイプをグループ化する場合に役立ち ます。たとえば、分類子を削除するために、「-too_small」を含むソースタイプ名を正規化することができます。 詳細は、『Getting Data In』マニュアルの「Rename source types」を参照してください。 タグの定義と管理 Splunk は、タグを作成、管理するための一連の手段を提供しています。多くのユーザーがもっとも単純な、サー チ結果からフィールド/値のペアに直接タグを設定する方法を利用しています。詳細は、このマニュアルの 「フィールド値のタグとエイリアス設定」を参照してください。 ただし、ナレッジ管理者の方は、Splunk 管理の [タグ] ページを使ってユーザーが作成したさまざまなタグを管理 95 していることでしょう。ここでは、以下の作業について 明していきます。 Splunk 管理の [タグ] ページを使って、環境内のタグを管理する。 Splunk 管理を使って新しいタグを作成する。 Splunk 管理を使ってタグを無効化/削除する。 [管理] > [タグ] を選 して [タグ] ページに移動する。 Splunk 管理の [タグ ] ペ ー ジの使用 Splunk 管理の [タグ] ページには、タグに関する 3 種類のビューが用意されています。 フィールド値のペアのタグ設定：[フィールド値のペア別表示] ページの [] をクリックして表示します。 タグ名別表示 一意の ID によるタグ：[タグ] ページで [一意のすべてのタグオブジェクト] をクリックします。 これらのページを利用して、タグを異なる方法で管理することができます。タグとフィールド/値のペアの関連付 けを手 に把握することができます。また、関連付けを作成、削除することもできます。 特定のフィールド値ペアに関連付けられているタグセットの管理 タグが関連付けられているすべてのフィールド/値のペアを表示することができます。また、特定のフィールド/値 のペアに関連付けられている一連のタグを確認、更新することができます。特定のフィールド/値のペアに一連の タグを定義することができます。 このような作業を行うには、Splunk 管理の [フィールド値のペアのタグ設定] ページを利用します。ここでは、特 定のフィールド/値のペアに関連付けられている一連のタグを確認、編集することができます。 また、特定のフィールド/値の組み合わせをタグで管理するための、 限を管理することもできます。 特定のフィールド/値のペアに するタグのリストを表示するには、［フィールド::値］ 列にある目的のペアをク リックします。そのフィールド/値のペアの詳細ページが表示されます。 eventtype=auditd_create フィールド/値のペアに定義されているタグの例を以下に示します。 必要に じて他のタグを追加したり、既存のタグを削除することができます (適切な 限がある場合)。 [フィールド値のペアのタグ設定] ページで [新規] をクリックすると、新しいフィールド/値のペアにタグを設定す ることができます。 フィールド/値のペアのタグを作成または更新する場合は、当初の目的とは異なる種類のフィールド/値のペアにタ グを作成/関連付ける可能性があることに注意してください。ナレッジ管理者は、一連のタグのデザインや管理を 注意深く確認するようにしてください。そうすることにより、データの正規化が容易になり、ユーザーの混乱を最 小限に抑えることができます。(詳細は、このマニュアルの「ナレッジオブジェクトの編成と管理」を参照してく ださい。) 注意：[フィールド/値のペアのタグ設定] ページに追加するフィールド/値のペアが存在しているかどうかを確認す 96 ることもできます。システムには、存在しないフィールド/値のペアに するタグの定義を防止する機能はありませ ん。 特 定 の タ グ に 関 連 付 け ら れ た フ ィ ー ル ド /値 ペ ア の 確 認 と 更 新 システム内の 1 つまたは複数のタグに関連付けられているすべてのタグを表示することができます。また、特定の タグに関連付けられている一連のフィールド/値のペアを確認、更新することができます。さらに、新しいタグに してフィールド/値のペアを定義できます。 これらの作業は、Splunk 管理の [タグ名別表示] ページで行います。ここでは、特定のタグに関連付けられている 一連のフィールド/値のペアを確認、編集することができます。 ただし、このページでは、タグに関連付けられている一連のフィールド/値ペアの 限を管理することはできませ ん。 特定のタグに するフィールド/値のペアを表示するには、このページの ［タグ］ 列から目的のタグの名前をクリッ クします。タグの詳細ページが表示されます。 modify タグに関連付けられている、フィールド/値ペアの表示例を以下に示します。 必要に じて他のフィールド/値ペアを追加したり、既存のフィールド/値ペアを削除することができます (適切な 限 がある場合)。 [タグ名別表示] ページで [新規] をクリックすると、新しいタグに するフィールド/値のペアを設定することができ ます。 タグの一連のフィールド/値のペアを作成または更新する場合は、新しいフィールド/値のペアを作成している可能 性もあることに注意してください。タグに関連付けるフィールド/値のペアが存在しているのかを確認することも できます。システムには、存在しないフィールド/値の関連付けの追加を防止する機能はありません。 新しいタグの作成には注意を払うようにしてください。同じ目的のタグがすでに存在している可能性もあります。 ナレッジ管理者は、一連のタグのデザインや管理を注意深く確認するようにしてください。そうすることにより、 データの正規化が容易になり、ユーザーの混乱を最小限に抑えることができます。(詳細は、このマニュアルの 「ナレッジオブジェクトの編成と管理」を参照してください。) 一 意 の フ ィ ー ル ド /値 の ペ ア と タ グ の 組 み 合 わ せ の 確 認 [一意の ID によるタグ] ページには、システム内のすべての一意のタグ名とフィールド/値ペアが表示されます。前 述の 2 つのページとは違い、このページではタグとフィールド/値ペアの 1 1 の関係のみを編集することができま す。 特定のタグをサーチして、関連付けられているフィールド/値のペアを手 に表示したり、その逆の作業を行うこと ができます。このページは、特に特定のタグとフィールド/値ペアの関連付けを無効化/複製したり、そのようなレ ベルで 限を管理したりする場合に役立ちます。 97 タグの無 効 化と削除 不要なタグがある場合、または特定のフィールド/値のペアにタグを関連付けたい場合、タグを無効化または削除 することができます。適切な 限がある場合、以下のような作業を行えます。 サーチ結果内の特定のフィールド/値ペアのタグ関連付けを削除する。 [タグ名別表示] ページで、複数のフィールド/値ペアに削除されている場合でも、タグを一括して無効化/削除 する。 [フィールド値のペアのタグ設定] ページで、あるフィールド/値ペアと一連のタグとの関連付けを一括して無 効化/削除する。 サーチ結果内の特定のフィールド/値のペアとの関連付けを削除する方法については、このマニュアルの「フィー ルド値のタグとエイリアス設定」を参照してください。 複 数 の フ ィ ー ル ド /値 ペ ア と の 関 連 付 け が あ る タ グ の 削 除 Splunk 管理を使って、タグが多数のフィールド/値のペアと関連付けられている場合でも、システムから完全に削 除することができます。ここで 明する方法では、すべての関連付けを一度に削除します。 [管理] > [タグ] > [タグ名別表示] に移動します。タグを削除します。そのタグの削除 限がない場合、タグを削除す るためのリンクは表示されません。タグを削除する場合は、それが下流の依存関係に与える影響を考慮するように してください。詳細は、このマニュアルの「Splunk ナレッジの管理」を参照してください。 注意：特定のタグの編集ビューから、フィールド/値ペアとの関連付けを削除することもできます。 フ ィ ー ル ド /値 の ペ ア と 一 連 の タ グ 間 の 関 連 付 け の 無 効 化 /削 除 あるフィールド/値のペアに関連付けられている一連のタグを一括削除する場合に、ここで 明する方法を使用しま す。この方法では、すべての関連付けを一括削除できます。データからフィールド/値のペアが削除されることは ありません。 [管理] > [タグ] > [フィールド値のペアのタグ設定] に移動します。フィールド/値のペアを削除します。そのフィー ルド/値のペアの削除 限がない場合、フィールド/値のペアを削除するためのリンクは表示されません。関連付けを 削除する場合は、削除により下流の依存関係に 影響がでないかどうかを考慮するようにしてください。詳細は、 このマニュアルの「Splunk ナレッジの監督」を参照してください。 注意：特定のフィールド/値のペアの編集ビューから、タグとの関連付けを削除することもできます。 タグの無効化 十分な 限がある場合は、上記の 3 つのページを利用して、タグとフィールド/値ペアの関連付けを無効化すること もできます。タグとフィールド/値ペアの関連付けを無効にすると、関連付け自体は残りますが再び有効にならな い限り機能することはありません。 フィ ー ルドのエイリアスの作成 フィールドに して複数のエイリアスを作成できます。元のフィールドは削除されません。作成した任意のエイリ アスを使って元のフィールドをサーチすることができます。 重要：フィールドのエイリアス設定は、キー/値の抽出後、フィールドルックアップの前に行われます。そのた め、エイリアスを使ってルックアップテーブルを指定することができます。このことは、ルックアップテーブル内 の 1 つまたは複数のフィールドがデータ内のフィールドと同一だけれども、名前が異なっているような場合に役立 ちます。詳細は、このマニュアルの「フィールドルックアップの設定」を参照してください。 幾筋に抽出されたフィールドにも、サーチ時に抽出されたフィールドにも、エイリアスを設定することができま す。 フィールドエイリアスを追加するには、$SPLUNK_HOME/etc/system/local/ または独自の App ディレクトリ $SPLUNK_HOME/etc/apps/ にある props.conf を編集します。(カスタムデータを他のインデックスサーバーに手 に転 送したいような場合は、後者のディレクトリを使用することをお勧めします。) 注意：Splunk のエイリアス機能は、現在の所複数値フィールドをサポートしていません。 フィールドにエイリアスを設定するには： 1. props.conf 内のスタンザに、次の行を追加します。 FIELDALIAS-<class> = <orig_field_name> AS <new_field_name> 98 <orig_field_name> は、オリジナルのフィールドの名前です。 <new_field_name> は、フィールドに設定するエイリアスです。 1 つのスタンザ内に複数のエイリアスを設定することができます。 2. 更内容を有効にするために、Splunk を再起動します。 ルックアップ用のフィ ー ルドエイリアスの追加例 外部の静的CSV ファイルのルックアップを作成する場合を考えてみましょう。サーチ時に抽出した「ip」フィー ルドを、「ipaddress」として参照します。抽出を定義した props.conf ファイルで、「ipaddress」を「ip」のエイ リアスとして設定するために、以下の行を追加します。 [accesslog] EXTRACT-extract_ip = (?<ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) FIELDALIAS-extract_ip = ip AS ipaddress props.conf にルックアップを設定したら、ip の代わりに ipaddress を使用できます。 [dns] lookup_ip = dnsLookup ipaddress OUTPUT host サーチ時のフィールド抽出の詳細は、このマニュアルの「サーチ時フィールド抽出の追加」を参照してください。 フィールドルックアップの詳細は、このマニュアルの「フィールドルックアップの設定」を参照してください。 ホストフィ ー ルドのタグ設定 ホストフィールドにタグを設定すると、ナレッジの収集と共有や 密なサーチの作成に役立ちます。ホストフィー ルドに複数のタグを設定することができます。タグを使って、機能やタイプ別にグループ化しておけば、ユーザー は類似のサーバーグループのアクティビティを手 にサーチできます。特定の入力のホストフィールドの値を 更し た場合は、すでにインデックスが作成されているイベントに新しいホスト名でタグを設定すれば、データセット全 体を手 にサーチすることができます。 Splunk Web を使ったホストフィ ー ルドへのタグの追加 Splunk Web でホストフィールド/値ペアにタグを追加するには： 1. タグを設定するホストからデータをサーチします。 2. サーチ結果の、目的のホストフィールドの値の隣にあるドロップダウンメニューから、[ホストタグ=<現在のホ スト値>] を選 します。 3. [このフィールドにタグ付け] ダイアログボックスが表示されます。1 つまたは複数のタグをカンマかスペースで 区切って入力し、[OK] をクリックします。 ホスト名 vs. ホストフィ ー ルドのタグ設定 ホストフィールドの値は、イベントのインデックス作成時に設定されます。Splunk サーバーのホスト名、特定の 入力、または各イベントのデータからの抽出などによって設定されます。ホストフィールドに代わりの名前となる タグを設定しても、実際のホストフィールドの値は わりません。ただし、ホストフィールドの値ではなく、指定 したタグを使ってサーチできるようになります。各イベントには、1 つのホスト名しかありませんが、複数のホス トタグを設定することができます。 たとえば、Splunk サーバーが特定のホストからコンプライアンスデータを受信している場合、そのホストにタグ 「compliance」を設定しておけば、コンプライアンス関連のサーチを手 に実施できます。ホストタグを利用すれ ば、実際のホスト名を 更することなく、データのグループ化を行えます。 99 ある入力ソースから取り込んだデータのインデックスを作成後、その入力のホストフィールドの値を 更した場合 に、インデックスデータのホストフィールドに新たなホスト名でタグを設定します。その入力から今後取り込まれ るデータのホストフィールドには新しいホスト値が含まれていますが、すでにインデックス内にあるデータのホス トフィールドの値は古いホスト名になっています。既存のデータのホストフィールドにタグを設定したことによ り、新しいデータだけではなく、既存のデータもまとめてサーチすることができます。 イベントタイプのタグ設定 イベントタイプにタグを設定することで、データに新たな情報を追加することができます。イベントタイプに複数 のタグを設定することもできます。たとえば、すべてのファイアウォール関連イベントタイプに「firewall」タグ を、ファイアウォールイベントタイプの一部に「deny」タグを、残りのファイアウォールイベントタイプに 「allow」を設定しておくことができます。イベントタイプにタグを設定すると、そのパターンに一致する任意の イベントタイプにタグが設定されます。 注意：Splunk Web でイベントタイプを作成または eventtypes.conf に設定する時に、イベントタイプにタグを設 定できます。 Splunk 管理でのイベントタイプへのタグの追加 Splunk 管理により、イベントタイプのリストを表示、編集することができます。 [管理] > [イベントタイプ] を選 します。 タグを設定するイベントタイプの名前をクリックして、詳細ページに移動します。 注意： イベントタイプは特定の Splunk App と関連付けられていることが多いことに注意してくださ い。また、表示/編集を防止するロールベースの 限が割り当てられている可能性もあります。 イベントタイプの詳細ページの、[タグ] フィールドでタグを追加、編集します。 更内容を確認して、[保存] をクリックします。 イベントタイプにタグを設定すると、tag::<field>=<tagname> または tag=<tagname> の形式で、サーチバーから タグを指定したサーチを実行できます。 tag=foo tag::host=*local* サ ー チとサ ー チジョブの保存、共有、管理 サ ー チの保存とサ ー チ結果の共有 有用な結果を返すサーチの実行後、そのサーチを保存することができます。これにより、再びサーチ文字列を入力 することなく、同じサーチを手 に実行することができます。また、サーチの実行結果を保存して、後ほどその結 果を確認したり、他のユーザーに参照させたりすることができます。ここでは、以下の事項を取り上げていきま す。 Splunk Web UI を使ったサーチの手動保存。 savedsearches.conf の更新によるサーチの保存。 Splunk がサーチを自動保存するアクション。 他のユーザーとのサーチ結果の共有。 保存 みサーチのナビゲーションの管理。 サ ー チの手動保存 有用な結果を返すサーチを作成して、それを保存したい場合は、サーチの実行完了後 Splunk Web で手 に保存す ることができます。savedsearches.conf に新しい保存 みサーチを手動定義することもできます。詳細は以降の 明 を参照してください。 保存 みサーチには最低でもサーチ文字列とサーチに関連する時間範 (相 時間修飾子で指定) が含まれています。ま た、サーチ名も含まれています。この名前が、[サーチとレポート] ドロップダウンに表示されます。 注意：[サーチとレポート] 以外のトップレベルナビゲーションに、サーチを保存するように App を設定すること もできます。詳細は、「保存 みサーチのナビゲーションの管理」を参照してください。 100 実行中または完了したサーチのタイムラインビューからの保存 タイムラインビューでサーチを実行した場合、Splunk Web のサーチバー上部にある [保存...] ボタンをクリックし て、次に [サーチの保存...] を選 してサーチを保存することができます。この操作を行うと、[サーチの保存] ダイア ログボックスが表示されます。 [サーチの保存] ダイアログボックスが表示された時に、保存するサーチの [サーチ文字列] と [時間範 ] (相 時間修 飾子で指定) は自動設定されています。保存前にこれらの情報を 更することができます。保存 みサーチ には一意 の名前を指定する必要があります。この名前が、App のナビゲーション バー上部の [サーチとレポート] リストに 表示されます。 保存 みサーチの他のユーザーとの共有 デフォルトでは、保存したサーチはプライベートで自分のみが利用できます。適切な 限がある場合は、[サーチの 保存] ダイアログでサーチの 限を 更して「読み取り専用」アクセスを設定し (ユーザーは [サーチとレポート] から サーチを実行できるけれども、編集や 限の 更はできない)、App の各ユーザーに利用させることができます。 管理者レベルのロールをお持ちの場合は、[管理] > [サーチとレポート] に移動して、保存 みサーチの利用者をさら に 大または制限することができます。たとえば、Splunk 環境内のすべてのユーザーに「グローバル」に利用させ ることができます。また、現在の App 内の特定のロールを持つユーザーにのみ、保存 みサーチを利用させること も可能です。さらに、特定のロールまたはユーザーに「書き込み」アクセス を与えて、定義を編集できるように することも可能です。 サーチの高速化 サーチに大量のイベントが存在しており、完了までに時間がかかる場合、将来的にそのサーチを再実行する際によ り早く完了するようにサーチを高速化できることがあります。このためには、[サーチの保存] ダイアログ ボックス の [Acceleration] (高速化) にある [Turn on acceleration] (高速化をオンにする) を選 します。 注意：以下の場合は [高速化] セクションは表示されません。 サーチを高速化する 限がない。ロールに適切な schedule_search 限がない場合、サーチを高速化できませ ん。 サーチが高速化の適さない。詳細は、後述する「レポート高速化に適したサーチ」を参照してください。 Splunk はどのようにしてサーチを高速化するのでしょうか？[Turn on acceleration] を選 してサーチを保存した 場合、Splunk はサーチに基づいてデータのサマリーを作成するバックグラウンドプロセスを実行します。次回の サーチ実行時には、インデックス全体ではなくこのサマリーに してサーチが実行されます。このサマリーはイン デックス全体よりも小さく、サーチに関連して事前に算出されたサマリーデータが含まれているため、初回実行時 よりも大幅に短い時間でサーチが完了します。 サーチの高速化機能をオンにした場合、[サマリー範 ] に「7 日」や「3 ヶ月」のような値を選 する必要がありま 101 す。この範 が、サマリー作成後の任意の時点でそのサマリーがカバーする概算期間になります。サマリーが作成 された後にそのサーチを実行した時に、高速化の恩恵を最大限に得るために、このサマリー範 には適切な時間範 を指定する必要があります。詳細は、後述する「サマリー時間範 の選 」を参照してください。 注意：ここで取り上げているデータサマリーは、従来のサマリーインデックスと似たような原理で動作しますが、 それだけで内容は異なっています。サーチ高速化目的で作成されるデータサマリーは、サマリーインデックスでは ありません。サーチの高速化とサマリーインデックスの詳細、および両者の違いについては、『ナレッジ管理』マ ニュアルの「レポート高速化とサマリーインデックスについて」を参照してください。 サーチモードとレポート高速化：レポート高速化は、サーチモードが [スマート] または [高速]に設定されている サーチに してのみ機能します。レポート高速化を設定したサーチに [詳細] サーチモードを選 すると、高速化され ていない場合と同じ速度でしかサーチは実行されません。サーチモード設定の詳細は、『サーチマニュアル』の 「サーチに合わせたサーチモードの設定」を参照してください。 レポート高速化に適したサーチ 高速化を使用するサーチは、レポートコマンド (chart、timechart、stats、top など) を使用する必要がありま す。また、サーチ文字列内の最初のレポートコマンドの前の任意のサーチコマンドは、ストリーミングコマンドで なければなりません。(最初のレポートコマンドの後には非ストリーミングコマンドを指定できます。) 高速化に適したサーチと適さないサーチの例については、このマニュアルの「レポート高速化の管理」を参照して ください。 サマリー時間範 の選 [Turn on acceleration] を選 した場合、作成されるサマリーの適切なサマリー範 を選 する必要があります。この 項目は、サマリーがカバーする概算時間範 を表しています。今後実行されるサーチが高速化の恩恵を受けるに は、それらのサーチの範 がサマリー範 内でなければなりません。 たとえば、[サマリー範 ] に [7 日] を指定すると、Splunk は常に最低過去 7 日間を常にカバーするサマリーを作 成、管理します。時間の 過に伴い、過去 7 日間よりも古くなったデータはサマリーから削除され、新しく到着し たデータのサマリーが追加されます。 サマリーが作成された後、過去 7 日以内の時間範 でサーチを実行した場合は、比較的速くサーチが完了します。 過去 10 日間に してサーチを実行すると、過去 7 日間に しては高速化の恩恵を受けられますが、残り 3 日間に し ては raw データに してサーチが実行されるため、高速化されることはありません。 他のサマリー範 の設定でも同じことが言えます。過去 30 日間の時間範 でサーチを実行する予定がある場合は、 [1 ヶ月] を選 してください。過去 1 年間のサーチを実行する必要がある場合は、[1 年] を選 します。サマリー範 が 大きいほど、最初のサマリーデータの生成までに時間がかかり、より多くのストレージリソースを消費することに 注意してください。 注意：サーチ実行時の時間範 の制約をなくし、高速化の恩恵を常に受けたい場合は、[全時間] を選 します。 ;レポート高速化サマリーの管理 この機能を管理するためのページが、[管理] > [レポート高速化サマリー] に用意されています。このページでは、 自分がアクセスできるレポートサマリーを確認することができます。適用されているサーチや作成の進捗状況の表 示、整合性の 証、損傷した場合の再構築、古いサマリーの削除、スペースを消費しているサマリーなど、さまざ まな情報を確認することができます。 注意：レポートを高速化できるロールを保有している場合にのみ (ロールに schedule_search 限が必要)、[レポー ト高速化サマリー] ページにアクセスすることができます。 環境内でサマリー数が 加するにつれて、ストレージやパフォーマンス上の問題が発生する可能性があることに注 意してください。サーチ高速化サマリーデータを保管するストレージスペースが必要で、またデータを最新の状態 に保つために Splunk は 10 分間隔で新しいデータのサーチをバックグラウンドで実行する必要があるためです。 [レポート高速化サマリー] ページでは、使用頻度とその消費スペースから、価値に値しないサマリーを素早く認識 することができます。 サーチ高速化の詳細とその処理内容、ストレージとパフォーマンスの 討事項、その他のヒントについては、この マニュアルの「サーチ高速化の管理」を参照してください。 Splunk 管 理 で の 新 し い 保 存 み サ ー チ の 作 成 新しいサーチを保存する場合、サーチを実行した後、[サーチの保存] ダイアログボックスを使って保存するのが もっとも簡単な方法です。この方法を利用すれば、保存前にサーチをテストすることができます。 また、Splunk 管理で新しい保存 みサーチを手動作成することもできます。[管理] > [サーチとレポート] に移動し 102 て、[新規] をクリックし、新しい保存 みサーチを定義します。サーチを定義するには、[サーチの保存] ダイアログ を利用する場合に必要な情報と同じ情報を指定する必要があります。サーチ名、サーチ文字列 ([サーチ] フィール ド)、時間範 (相 時間修飾子で指定) は必須項目です。必要に じて、サーチの内容や使用方法を 明するテキストを 入力することもできます。 適切な 限があり、サーチが自動サーチ高速化に適している場合は、[高速化] オプションを利用できます。これら のオプションを使って、2 回目以降のサーチ実行を高速化することができます。この機能は、[サーチの保存] ダイ アログの [高速化] と同じです。詳細は、前述のサーチ高速化に関するセクションを参照してください。 注意：このトピックの前半で 明しているように、レポート高速化に適さないまたは利用できないサーチも存在し ています。最低でも、サーチにレポートコマンドが含まれていなければなりません。詳細は、『Knowledge 管理 マニュアル』の「レポート高速化の管理」を参照してください。 必要に じて、[このサーチをスケジュール] を選 できます。. このオプションを選 すると、サーチの定期実行のス ケジュール、サーチに基づいたアラート生成条件の定義、アラートアクション (アラート生成時の動作) の設定な どを行うための各種フィールドが表示されます。これらの機能を使ってサーチを、アラートやスケジュール み サーチにすることができます。 アラートの作成方法の詳細は、『アラートマニュアル』の「アラートについて」を参照してください。このトピッ クには、Splunk 管理のサーチとレポートの詳細ページでのみ利用できる、アラート管理のアラートレコードの有 効期限や「RSS フィードに追加」アラート条件などの、アラートオプションに関する情報も記載されています。 スケジュール みサーチ (スケジュールに従って実行され、実行時に 回メールまたすスクリプトでサーチ結果を通知 するサーチ) の定義の詳細は、『アラートマニュアル』の「スケジュール みサーチの作成」を参照してください。 Splunk 管理にあるサーチとレポートの詳細ページは、Splunk Web 内で保存 みサーチのサマリーインデックスを 有効にできる唯一の場所でもあります (savedsearches.conf を編集してサーチのサマリーインデックスを設定する こともできます)。サマリーインデックスの詳細は、『ナレッジ管理』の「サーチのサマリーインデックスを有効 にする」を参照してください。 サーチに する書き込み 限がある場合は、[サーチとレポート] ページに記載されているサーチを編集、更新するこ とができます。詳細は、『ナレッジ管理マニュアル』の「Splunk ナレッジの管理」を参照してください。 savedsearches.conf へ の 保 存 み サ ー チ の 設 定 103 Splunk Web の UI または Splunk 管理でサーチを保存すると、そのサーチのスタンザが savedsearches.conf に自 動的に追加されます。UI は 更内容を 証します。また、UI でサーチを作成した場合、システムを再起動する必要は ありません。設定ファイルに直接保存 みサーチを設定することも可能です。 での保存 みサーチとアラートの設定方法については、savedsearches.conf 設定ファイルおよ び『アラートマニュアル』の「savedsearches.conf でのアラートの設定」を参照してください。 savedsearches.conf Splunk がサ ー チを自動保存する場合 前のセクションでは、実行したサーチの手動による保存方法を 明しました。しかし、実行する操作によっては、 Splunk が自動的にサーチを保存する場合もあります。 Splunk Web UI を使ってアラート、ダッシュボードパネル、レポート、およびスケジュール みサーチを作成した 場合 (これらは、実行中または完了したサーチで [作成] をクリックすると表示されるオプションです)、サーチは自 動的に保存されます。 注意：アラート、ダッシュボード、レポート、またはスケジュール みサーチの作成により Splunk が自動的にサー チを保存する場合、サーチが保存されてもページ上部のナビゲーションバー近くにある [サーチとレポート] リス トには、そのサーチ名は追加されません。 ダッシュボードパネルの作成 すべてのダッシュボードパネルは、サーチをベースにしています。サーチを実行した後、[ダッシュボードパネル の作成] ダイアログで新しいまたは既存のダッシュボード用のパネルを作成した場合、パネルのベースとなるサー チも自動的に保存されます。パネルの作成後は、ダッシュボードの [サーチの編集] ダイアログを使ってパネル用 に別の保存 みサーチを選 したり、単純に現在のサーチをインライン編集したりすることができます。パネルの サーチをインライン編集した場合、元の保存 みサーチにそれらの 更は適用されません。 注意：[ダッシュボードに追加] ダイアログで、保存 みサーチの 限はダッシュボードレベルで管理されます (ダイア ログの [ダッシュボード] ステップ)。 作成しているダッシュボードパネルを既存のダッシュボードに配置する場合、それに関連付けるサーチはそ のダッシュボードと同じ 限になります。 管理者レベルの 限を保有しており、作成しているダッシュボードパネルを新しいダッシュボードに配置する 場合、ダッシュボードをプライベートのまま保持することも、現在の App のすべてのユーザーと読み取り専 用で共有することもできます。(管理者レベルの 限を持っていない場合、デフォルトでその新たなダッシュ ボードはプライベートになり、自分のみが参照できます。ダッシュボードパネルに関連付けるサーチは、新 たなダッシュボードの 限を引き ぎます。) ダッシュボードパネルの作成方法の詳細は、このマニュアルの「UI を使ったダッシュボードの作成と編集」を参 照してください。 アラートとスケジュール みサーチの作成 アラートは保存 みサーチをベースにしており、定義するアラートのタイプに じてリアルタイムサーチまたはスケ ジュール みサーチになります。Splunk はサーチを保存して、アラートをリアルタイムに実行するか、または履歴 的なスケジュールサーチかを判断します。 基本的にスケジュール みサーチは、 回の実行時に生成されるように設定されたスケジュール みアラートです。 一連の受信者にメール 由で定期的 (「 日午前 0 時に」、「 週月、水、金に」など)にレポートを送信する場合など に役立ちます。 注意：[管理] > [サーチとレポート] で、既存の保存 みサーチをアラートまたはスケジュール みサーチとして手動設 定することもできます。 レポートの定義 レポートビルダーを使ってサーチをベースにしたレポートを作成する場合、Splunk はベースサーチを自動的に保 存します。 104 注意：これは、グラフフォーマットパラメータを含むサーチを保存する唯一の方法です。サーチにレポートコマン ドが含まれており、サーチが生成するグラフに独自の書式設定 (例：デフォルトの横棒グラフの代わりに円グラフ で表示、特定のタイトルの設定、X 軸、Y 軸の指定など) を行いたいような場合は、レポートビルダーを使ってそ れをレポートとして保存してください。このようなサーチをサーチとして保存すると、レポートビルダーのグラフ の書式設定が失われてしまいます。ダッシュボードに特別な方法でグラフを表示するような場合に、このことが重 要になります。 レポートビルダーを塚ツタレポートの定義と保存の詳細は、『データのビジュアル化マニュアル』の「レポートビ ルダーによるレポートの定義」および「レポートの保存と他のユーザーとの共有」を参照してください。 サ ー チ結果の保存： サーチ結果を保存することは、サーチ自体を保存することとは異なります。サーチを保存する場合は、今後も手 に実行できるように、サーチ文字列と時間範 (およびそれに関連付けられているグラフ/テーブル書式) を保存して います。サーチ結果を保存する場合は、特定のサーチジョブの成果物を保存します。 単純にサーチの結果を保存する場合は、[保存] をクリックして、次に [結果の保存] を選 します。 [結果の保存] を選 すると、サーチジョブが保存されます。「サーチジョブの保存」とは、サーチジョブの失効を一 定期間停止することを意味します。デフォルトでは、すべてのサーチジョブが一定期間の 過後に失効 (自己削除) するように設定されています。履歴サーチおよび実行中のリアルタイムサーチのどちらの結果も保存することがで きます。結果は後ほど [ジョブ] ページで参照することができます。[ジョブ] ページに移動するには、Splunk イン ターフェイスの右上にある [ジョブ] リンクをクリックします。 ジョブ管理を使ったサーチジョブの管理については、このマニュアルの「ジョブ管理によるサーチジョブの管理」 を参照してください。 サ ー チ結果の共有 サーチ結果の共有と保存 みサーチの共有は異なっています。サーチ結果を共有する場合は、特定のサーチジョブ の結果を、他のユーザーにも利用できるようにしています。サーチ結果を共有する場合は、サーチジョブを保存し てそれを共有するか、または結果をファイルにエクスポートして、そのファイルを他の人々に送信します。 結果の保存と共有：[保存] をクリックして、[結果の保存と共有] を選 します。この場合は、[結果の保存] を選 した 場合と同 に、単にサーチジョブが保存されます。また、URL が表示されます。この URL を他のユーザーと共有 してください。共有したユーザーは、この URL からジョブのサーチ結果を参照することができます (ユーザーが 当該 Splunk 環境にアクセスでき、システム内に当該ジョブが存在している限り)。 イベントデータをファイルにエクスポート：サーチジョブのイベントデータを CSV、XML、JSON、または raw データファイルにエクスポートして、それをアーカイブしたり、サードパーティのアプリケーションで使用したり することができます。そのためにはサーチの実行後、サーチ結果の上部に表示される [エクスポート] リンクを選 します。 エクスポートするイベント数の制限値を設定したり、サーチジョブ内のすべてのイベントをエクスポートしたりす ることができます。サーチによっては膨大な数のイベントが返されることがあります。ご自分の環境の状況に じ て注意を払うようにしてください。 105 保存 みサ ー チのナビゲ ー ションの管理 サーチを保存する場合、それがトップレベルのナビゲーションメニューの、いずれかのドロップダウンリストに表 示されなければなりません。たとえば、サーチ App のデフォルトで、新しいサーチは [サーチとレポート] メ ニューに表示されます。 App に する書き込み 限がある場合、このデフォルトの場所を 更することができます。また、名前内に特定のキー ワードを持つサーチを、ナビゲーションメニュー内の特定のカテゴリに自動配置するように設定することも可能で す。たとえば、名前に「website」が含まれる保存 みサーチを、ナビゲーションメニューの Web サイト関連サー チのリストに自動的に配置するように設定することができます。また、サーチをデフォルトのリストから、トップ レベルのナビゲーションメニューの別の場所に移動することもできます。 保存 みサーチとレポートに して利用できるナビゲーション設定オプションの概要は、『ナレッジ管理マニュア ル』の「保存 みサーチとレポートのナビゲーションの定義」を参照してください。App のナビゲーション設定方 法の詳細は、『Developer manual』の「Build navigation for your app」を参照してください。 Answers 何か質問がありますか？「Splunk Answers」から、Splunk コミュニティに寄せられた、保存 みサーチに関する質 問と回答をご覧ください。 保存 みサ ー チの管理 まもなく 載予定 保存 みサーチおよびその共有方法の概要は、このマニュアルの「サーチの保存とサーチ結果の共有」を参照して ください。 このトピックでは、Splunk 管理の保存 みサーチページの使用方法も含めた、ナレッジ管理の 点からの保存 み サーチについて 明していきます。 スケジュ ー ル みサ ー チの優先度の設定 ここでは、同時に行われるスケジュール みサーチの優先度を設定するための、2 種類の方法について 明していき ます。方法には、「リアルタイムスケジューリング」と「連続スケジューリング」があります。 リアルタイムスケジューリングでは、多数のサーチがほぼ同時刻に実行するようにスケジュールされてお り、スケジューラーが一度に 1 つのサーチしか同時実行できない場合でも、常に最新の時間範 に該当するス ケジュール みサーチが実行されます。その性質のため、リアルタイムスケジューリングのサーチにより、他 のスケジュールされている実行がスキップされる可能性があります。ただし、連続スケジューリングでは、 常にサーチに優先度が与えられます。 連続スケジューリングでは、サーチ結果の通知が れるような場合でも、各スケジュールが順次実行されてい きます。これらの設定は、savedsearches.conf 由で保存 みサーチレベルで管理されます。Splunk のデフォ ルトでは、すべてのスケジュール みサーチをリアルタイムスケジューリングで管理します。ただし、サマ リーインデックスに してスケジュール みサーチを有効にすると、自動的に連続スケジューリングに切り替え られます。 これらの 2 つのオプションの必要性を理解するには、サーチスケジューラによる同時サーチの処理方法を理解する 必要があります。 106 保存 みサーチのスケジュールの詳細は、『管理マニュアル』の「スケジュール みアラートの定義」と「スケ ジュール みサーチの作成」を参照してください。 このトピックでは、レポート高速化のために Splunk が自動的に行う、「自動サマリー作成」サーチがどのように 処理されるかについても 明されています。詳細はこのトピックの最後にあるサブトピックを参照してください。 サ ー チスケジュ ー ラによる同時サ ー チの 処 理方法 Splunk サーチスケジューラーは、同時に実行できるスケジュール みサーチ数を制限しています。デフォルト で、limits.conf に設定されている max_searches_perc 設定により、スケジューラーが処理できる最大同時サーチ 数は、max_searches_per_cpu の値の 25% になります。デフォルトで、max_searches_per_cpu は「システム内の各 CPU に して 4 件のサーチ + 2」になっています。そのため、システムに CPU が 1 つある場合、スケジューラー は 1 つのサーチのみを安全に実行することができます (1.5 = 6 の 25%)。 注意：自分が何を行っているのかをきちんと理解していない限りは、limits.conf を 更することはお勧めできませ ん。 スケジューラーで一度に 1 件のサーチしか実行できない場合に、複数のサーチが時間ごとに過去 1 時間のデータ に して実行するようにスケジュールされている場合、どうなるでしょうか？スケジューラーは、その期間のサー チを順番に実行し、スケジュールされている時間を基準に時間範 の情報が返されます。 リアルタイムスケジュ ー リングと連 続 スケジュ ー リングの例 スケジューラーの処理方法を学習したら、リアルタイムスケジューリングと連続スケジューリングの違い、および 状況によってどちらを利用した方が良いかを見ていきましょう。 まず、2 つの保存してあるスケジュール みサーチ A と B を例に考えてみましょう。 サーチ A は 分ごとに実行され、完了までには 30 秒かかります。 サーチ B は 5 分ごとに実行され、完了までには 2 分かかります。 また、利用する Splunk 環境では、一度に 1 つのサーチしか実行できないものと仮定します。 両方のサーチは午後 1 時 5 分に実行するようにスケジュールされています。 時間 スケジューラーのアクション 1:05:00pm スケジューラーは A を 1:04 1:05 の期間に実行し、次回実行を午後 1:06 にスケジュールします。 サーチ A は午後 1:05:30 に完了します。 1:05:30pm スケジューラーはサーチ B を実行します。サーチ B を実行します。このサーチは実行が完了するま でに 2 分かかるため、このサーチは 1:07:30 まで完了しません。 1:06:00pm スケジューラーはサーチ A の実行時間に実行しようとしますが、サーチ B が処理中のため実行する ことはできません。 1:06:59pm スケジューラーは、1:06:59 までサーチ A の実行を試みます。この時点で行われる処理は、サーチ A がリアルタイムスケジューリングを使用しているか、または連続スケジューリングを使用している かによって異なります (後述)。 サーチ A の設定： リアルタイムスケジューリング：スケジューラーは 1:05-1:06 のサーチ実行をスキップして、次回のサーチ A の実行を午後 1:07:00 にスケジュールします (1:06 1:07 の期間)。新たなサーチの実行時間は、現在スケ ジュールされている実行時間に基づきます (午後 1:06:00)。 連続スケジューリング：スケジューラーはスケジュールをスキップすることなく、午後 1:05 1:06 の期間に 予定されているサーチを実行するために無制限に待機します。そして、結果的にそのサーチが実際に実行さ れた時間に関係なく、次に実行されるサーチ A は午後 1:06 1:07 に してのものになります。 すべてのスケジュール みサーチに して、リアルタイムスケジューリングがデフォルトになっています。これは、 サーチが現在のデータを返すことを目的に設計されています。これは、一部のスケジュール みサーチがスキップ されても、最新のサーチ実行で最新の結果が返される限り問題はないことを前提にしています。 連続スケジューリングは、サーチデータにギャップができると問題が発生するような状況に使用されます。一般的 には、サマリーインデックスにデータを追加するサーチの場合にのみこのことが影響しますが、他のサーチでもこ れが重要になることがあります。サマリーインデックスに するサーチを有効にした場合は、自動的に連続スケ ジューリングに切り替えられます。 注意：サマリーインデックスのサーチに関する詳細は、『ナレッジ管理マニュアル』の「レポート効率を向上する サマリーインデックスの使用」を参照してください。 107 リアルタイムスケジュ ー ルオプションの設定 システムは、savedsearches.conf 内の realtime_schedule オプションを使って、スケジュール みサーチの次回実 行を判断しています。これは、各保存 みサーチ/スケジュール みサーチ個別に設定されます。 realtime_schedule= 0 | 1 リアルタイムスケジューリングを使用する場合は、realtime_schedule に 1 を設定します。この設定では、 常に時間範 がもっとも近いサーチが実行されます。サーチは他のサーチと同時実行できない場合もあるた め、このことは一部のサーチ実行がスキップされる可能性があることを意味しています。これは、スケ ジュール みサーチのデフォルトです。 連続スケジューリングを使用する場合は、realtime_schedule に 0 を設定します。この設定では、スケ ジュール みサーチがスキップされることはありません。サマリーインデックスが有効になっているスケ ジュール みサーチに しては、自動的にこの値が 0 に設定されます。 スケジューラーは、リアルタイムスケジューリングのサーチを連続スケジューリングのサーチよりも優先するよう に設計されているため、常にリアルタイムのスケジューリングが先に実行されるように試みます。 注意：サマリーインデックスを設定するサーチに realtime_schedule=1 を設定してはいけません。設定すると、 サーチがスキップされてしまう可能性があります。それが原因でサマリーインデックスにギャップが発生すると、 サマリーインデックスの信頼性が損なわれてしまいます。 レポ ー ト高速化とサ ー チサ ー チスケジュ ー ラ ー 完了までに時間がかかるようなサーチにレポート高速化を使用している場合、その過程でスケジュール みサーチ を活用していることに注意してください。新たなレポート高速化サマリーを生成するためにサーチがバックグラウ ンドで実行され、それ以降サマリーデータが更新されていきます。 デフォルトでは、サーチスケジューラーには、レポートを高速化するためのサマリーデータの作成と更新のため に、合計サーチ帯域幅の 25% までの利用が許可されています。この値を 更することはお勧めできませんが、 更す る必要がある場合は、limits.conf で auto_summary_perc 属性の値を適切な値に 更してください。 サーチスケジューラーは、レポート高速化サマリーのデータを作成するためのサーチを最低優先度で実行します。 これらの「自動サマリーデータ作成」サーチがユーザーが定義したアラート、サマリーインデックスサーチ、およ び通常のスケジュール みサーチと競合している場合、ユーザー定義のサーチが常に最初に実行されます。つま り、Splunk が他の優先するサーチを実行するために、サマリーが作成/更新されない可能性があります。 レポート高速化の詳細は、このマニュアルの「レポート高速化の管理」を参照してください。 サ ー チジョブとサ ー チジョブ管理について サーチの実行またはレポートの生成時には、 回サーチジョブが作成されます。このジョブには、サーチまたはレ ポートから返されたイベントデータが含まれています。ジョブ管理では、最近使用したジョブや以前に保存した ジョブを確認することができます。また、Admin または同等の 限を持つロールを保有している場合、ジョブ管理 を使ってシステム内のすべてのユーザーのジョブを管理することができます。 ジョブ管理を表示するには、画面右上にある [ジョブ] リンクをクリックします。 ジョブ管理の使用方法の詳細は、『ナレッジ管理マニュアル』の「ジョブ管理によるサーチジョブの管理」を参照 してください。 OS のコマンドラインからジョブを管理することもできます。詳細は、このマニュアルの「OS からのサーチジョ ブの管理」を参照してください。 注意：サーチジョブと保存 みサーチや保存 みレポートは違う物だということに注意してください。保存 みサーチ と保存 みレポートには、サーチ文字列や時間引数などの、サーチやレポートの実行に必要なデータが含まれてい ます。ジョブは、以前に実行したサーチやレポートなどの成果物 (結果) です。特定のサーチ/レポート実行の結果 が含まれています。ジョブは、スケジュール みサーチまたはサーチの手動実行により生成されます。 保存 みサーチの詳細は、このマニュアルの「サーチの保存と他のユーザーとの共有」を参照してください。レ ポートの保存については、『データのビジュアル化』の「レポートの保存と他のユーザーとの共有」を参照してく ださい。 ユ ー ザ ー が 実 行できるジョブの制限 108 あるユーザーが実行できるジョブおよび保管できるジョブ成果物の量を制限するには、そのようにロールを制限し てそれを目的のユーザーに割り当てます。このような設定はきめ細かく行え、システム内の各ユーザーに独自の ロールを割り当てることも可能です。 $SPLUNK_HOME/etc/system/local 内の authorize.conf のコピーに 限を作成して、適切な値を指定してください。 srchDiskQuota：このロールに所属するユーザーのサーチジョブが利用できる最大ディスクスペース (MB)。 srchJobsQuota：このロールが利用できる同時実行サーチの最大数。 詳細は、『Splunk のセキュリティ』の「ロールの追加と編集」を参照してください。 長期 実 行しているジョブの自動停止 予期せずに長期間実行されているサーチジョブに 処するために、Splunk には自動停止機能が用意されています。 デフォルトでこの機能は、ユーザーがうっかりと「全時間」サーチを実行してしまった場合に 処するために、サ マリーダッシュボードのクリックに してのみ有効になっています。 特定のサーチビューの自動停止を有効にすると、サーチ中にビューに自動停止のカウントダウンフィールドが表示 されます。サーチの時間制限に達すると、ユーザーにサーチが停止されたことを知らせる情報ウィンドウが表示さ れます。このウィンドウから、実行を再開したり、サーチを終了することができます。デフォルトでは、30 秒で 自動停止されます。 自動停止は、ビューの開発者のみが設定可能です。システム全体に して設定したり、ロールに して設定したりす ることはできません。自動停止機能を有効/無効にするには、目的のビューを編集します。『Developer manual』 の「How to turn off autopause」を参照してください。また、自動停止の実装例として、サマリーダッシュボード の host, source, および sourcetypes リンクを参照してください。[[[Category:V:Splunk:5.0]] ジョブ管理によるサ ー チジョブの管理 ジョブ管理を使って、自分が保有している任意のサーチをレビュー、管理することができます。Admin または同 等の 限を持つロールを保有している場合、すべてのユーザーが実行したサーチジョブを管理することができま す。これらのジョブを参照するには、Splunk Web のジョブ管理に移動します。ページの右上にある [ジョブ] リン クをクリックしてください。 ジョブ管理を表示するには、画面右上にある [ジョブ] リンクをクリックします。 [ジョブ] をクリックすると、新たなウィンドウにジョブ管理が表示されます。ジョブ管理には、サーチジョブの一 覧が表示されています。ジョブ管理に記載されているサーチジョブには、以下のものが含まれます。 最近手動実行したサーチの結果となるジョブ。 ダッシュボード読み込み時に実行されたサーチの成果物となるジョブ。 スケジュール みサーチ (定期的に実行されるサーチ) 実行の成果物となるジョブ。 保存されたジョブ。 サーチジョブは、ジョブ管理で保存することができます。 サーチをバックグラウンドに移動した場合も、サーチが完了する前にジョブが自動保存されます。 注意：ジョブ管理ウィンドウの表示時にあるジョブがキャンセルされた場合、ウィンドウにそのジョブは引き続き 表示されますが、結果を参照することはできません。ジョブ管理を閉じてから再表示すると、キャンセルされた ジョブは表示されなくなります。 サ ー チジョブの 寿 命 サーチジョブは Splunk が自動削除するまでの間、ジョブ管理に表示されます。サーチジョブのデフォルトの寿命 は、それがサーチの手動実行の結果か、またはスケジュール みサーチの結果なのかによって異なります。 手動実行またはダッシュボードの読み込みによるサーチジョブ 109 サーチを手動実行して完了した場合、結果となるサーチジョブのデフォルトの寿命は 10 分です。ダッシュボード パネルの読み込み時に実行されるサーチの成果物の寿命も 10 分です。 サーチジョブを保存することで、寿命を 7 日間に延ばすことができます。サーチジョブは 2 種類の方法で保存で きます。ジョブ管理を開いてサーチジョブを手動保存するか、またはサーチの実行中にバックグラウンドにサーチ を移動してください。 注意：保存したジョブの保持期間を延長/短縮したい場合は、limits.conf で [search] スタンザの default_save_ttl の値を適切な値に 更してください。(「ttl」は「有効期間」を表す略語です。) サーチジョブの結果を表示した場合 (ジョブ管理でジョブをクリックして結果を別のウィンドウに表示した場合)、 ジョブの有効期限 (寿命) がリセットされ、表示した時点からさらに 7 日間保持されます。 スケジュール みサーチの結果となるサーチジョブ スケジュール みサーチは定期的に実行されます。デフォルトでは、スケジュール みサーチの実行間隔の 2 倍の期 間サーチジョブが保存されます。つまり、サーチが 6 時間ごとに実行される場合は、サーチジョブは 12 時間保持 されます。 注意：特定のスケジュール みサーチの結果となるジョブのデフォルトの寿命は 更することができます。そうする には、savedsearches.conf に移動して目的のスケジュール みサーチを探し、dispatch.ttl の値を 更してください (倍数で指定、スケジュール間隔にこの値を乗じた時間だけ保持されます)。 ジョブ管理のコントロ ー ル ジョブ管理のコントロールを使って以下の作業を行えます。 最近実行または保存したジョブの一覧の表示、およびそれを使ったジョブ統計 (実行時間、一致イベント 数、サイズなど) の比較。Admin ロールまたはそれと同等の 限を保有している場合、最近生成されたすべて のジョブを表示することができます。 処理中のバックグラウンドジョブ (リアルタイムサーチおよび長期間実行されている履歴サーチを含む) また はスケジュール みサーチによるジョブの進捗状況の表示。 サーチジョブの保存、一時停止、再開、完了、削除 (個別にまたは一括)。目的のジョブの左側にあるチェッ クボックスを選 して、ページ下部にある目的の操作に するボタンをクリックしてください。 サーチ名またはサーチ文字列をクリックして、特定のジョブに する結果を表示する。結果は別のブラウザウ インドウに表示されます。 ジョブがサーチに関連している場合、サーチビューに結果が表示されます。別個のウィンドウに表示 されます。 ジョブがレポートに関連している場合、レポートビルダーの [レポートの書式設定] ページに結果が表 示されます。 ［失効］ 列には、各ジョブがシステムから削除されるまでの時間を表しています。失効の時点以降にサーチ ジョブを表示または他のユーザーと共有したい場合は、ジョブを保存してください。ただし、ジョブを保存 しても 7 日後には失効することに注意してください (期間内にジョブを表示した場合は、その時点から 7 日 間に有効期間が延長されます)。詳細は、上記の「サーチジョブの寿命」を参照してください。 110 たいていのビューでは、ジョブ管理に移動しないでも、自分が最後に実行したサーチまたはレポートを保存するこ とができます (ジョブが失効していない場合)。 サーチビューでサーチを実行した後にサーチジョブを保存したい場合は、[保存] をクリックして、[結果の保 存] を選 します。特定のサーチの結果を保存して、それを他のユーザーと共有する場合は、[結果の保存と共 有] を選 します (結果へのリンクが表示されます、これを他のユーザーに知らせてください)。 手動実行したサーチジョブは、サーチの実行中に [バックグラウンドに送信] アイコンをクリックして保存す ることもできます。この操作は、[保存] をクリックして、[結果の保存] を選 した場合と同じ効果がありま す。サーチのバックグラウンドへの移動の詳細は、『サーチマニュアル』の「実行中のサーチへのアクショ ン」を参照してください。 レポートビルダーでレポートジョブを保存する場合は、[レポートの書式設定] ページで [保存] をクリックし て、[結果の保存] または [結果の保存と共有] を選 します。サーチジョブは、ジョブ管理からアクセスするこ とができます。結果を共有した場合は、結果へのリンクが表示されます。このリンクを他のユーザーに知ら せてください。 詳細は、このマニュアルの「サーチジョブとサーチジョブの管理について」を参照してください。 OS からのサ ー チジョブの管理 ここでは、OS からのサーチジョブの管理方法について 明していきます。以下の 2 種類のプラットフォームを 象 にしています。 *nix Windows Splunk Web を使ったサーチジョブの管理方法については、『ナレッジ管理マニュアル』の「ジョブ管理による サーチジョブの管理」を参照してください。 *nix でのジョブの管理 Splunk がジョブを実行している間、それが OS に splunkd search プロセスとして表示されます。このジョブプロ セスは、OS のコマンドラインで管理することができます。 ジョブのプロセスとその引数を表示するには、以下のコマンドを入力します。 > top > c 実行中のすべてのプロセスとその引数が表示されます。 ps -ef | grep "search" と入力すると、このリスト内の Splunk サーチプロセスのみが表示されます。以下のよう な情報が表示されます。 [pie@fflanda ~]$ ps -ef | grep 'search' 530369338 71126 59262 0 11:19AM ?? 530369338 71127 71126 0 11:19AM ?? 0:01.65 [splunkd pid=59261] search --id=rt_1344449989.64 --maxbuckets=300 --ttl= 0:00.00 [splunkd pid=59261] search --id=rt_1344449989.64 --maxbuckets=300 --ttl= 各サーチジョブに して 2 つのプロセスが存在しています。2 番目のプロセスは、splunkd が必要に じて他の作業 を手伝わせる「ヘルパー」プロセスです。メインジョブは、システムリソースを使用しています。メインプロセス を kill すると、ヘルパープロセスも終了されます。 プロセス情報には以下の内容が含まれます。 サーチ文字列 (search=) ジョブ ID (id=) ディスク上に保持されるジョブの成果物 (出力) の ttl または有効期間 (ttl=) ジョブを実行しているユーザー (user=) ユーザーが所属しているロール (roles=) ジョブの実行中、データは $SPLUNK_HOME/var/run/splunk/dispatch/<job_id>/ に書き込まれます。スケジュール みジョブ (スケジュールされた保存 みサーチ) には、ディレクトリ名の一部として保存 みサーチ名が含まれます。 プロセスの ttl の値により、ここへのデータの保持期間が決まります。OS でジョブを kill する場合、その成果物 も削除するには、実施する前にジョブ ID を確認してください。 Windows でのジョブの管理 Windows の場合も、各サーチジョブに して別個のプロセスが生成されます。Windows には、*nix の top コマンド 111 に するコマンドはありませんが、実行中のサーチジョブのコマンドライン引数を表示するさまざまな方法があり ます。 Process Explorer (http://technet.microsoft.com/ja-jp/scriptcenter/dd742419.aspx) ユーティリティを使って、 サーチを実行しているプロセスのコマンドラインを 索する。 Powershell (http://technet.microsoft.com/ja-jp/scriptcenter/dd742419.aspx) の TASKLIST と Get-WMIObj コマン ドを使って、サーチジョブの ProcessID と CommandLine 引数を取得する。 Splunk がサーチを実行する場合、そのサーチのデータは に書き込まれま す。保存 みサーチも命名規則「admin__admin__search_」とエポック時に加えて無作為に生成されたハッシュを使 用した、似たようなディレクトリに書き込まれます。 %SPLUNK_HOME\var\run\splunk\dispatch\<epoch_time_at_start_of_search>.<number_separator> ファイルシステムを使ったジョブの管理 Splunk では、ジョブの成果物ディレクトリでの項目の作成/削除によりジョブを管理することができます。 ジョブをキャンセルするには、ジョブの成果物ディレクトリに移動して、そこに「cancel」という名前の ファイルを作成します。 ジョブの成果物を保持するには (ttl 設定を無視する)、「save」ファイルを作成します。 ジョブを一時停止するには、「pause」ファイルを作成します。一時停止を解除するには、「pause」ファイ ルを削除します。 マクロサ ー チの設計 サーチの管理を簡素化するために、マクロを含めた保存 みサーチを作成することができます。これらのサーチマ クロは、eval ステートメントやサーチ単語など、サーチの任意の部分に利用でき、また完全なコマンドである必 要はありません。マクロを利用すれば、サーチの一部を保存 みサーチやアドホックサーチなど、複数の場所で利 用できます。サーチマクロが任意の引数x\a を取るかどうかを指定することも可能です。 注意： フォームサーチもサーチマクロを使用しますが、GUI コンポーネントが含まれています。 サ ー チマクロの設定と管理 サーチマクロの表示、編集、削除は、Splunk Web の [管理] > [詳細サーチ] > [サーチマクロ] ページおよび macros.conf を使って行えます。詳細は、『サーチマニュアル』の「サーチマクロの作成と使用」および『管理マ ニュアル』の macros.conf に関する 明を参照してください。 フォ ー ムサ ー チの設計 フォームサーチは、ユーザーに特定の種類のサーチの作成を支援する簡単なサーチインターフェイスです。これに は、以下のような項目を含めることができます。 特定のフィールド値 (ユーザー名または ID 番号など) を取るフィールドやデフォルト値を表示するフィール ドを開く。 動的に定義されたサーチ用語の集まりを含むドロップダウンリスト。 特定のフィールド値 (例：エラーコード「404」、「500」、または「503」など) の選 を強制するラジオボタ ン。 あるフォームから受け取った値を取り、それを他のサーチに結合して各種グラフやレポートを生成する複数 の結果パネル。 フォームサーチは、Splunk のダッシュボードの作成に用いられるのと似たような XML コードで作成されます。詳 細は、『データのビジュアル化マニュアル』の「シンプル XML でのフォームの作成と編集」を参照してくださ い。 保存 みサ ー チやレポ ー トへのナビゲ ー ションの定 義 ナレッジ管理者は、保存 みサーチとレポートを、App のトップレベルのナビゲーションメニューに、目的の項目 を簡単に見つけられるような論理的な方法で配置する必要があります。そのためには、App のナビゲーションメ ニューをカスタマイズする必要があります。ナビゲーションメニューを適切に管理しないと、時間の 過とともに 保存 みサーチやレポートが分類されることなく適当に追加され、冗長で分かりにくく非効率的になってしまいま す。 112 サーチの保存とトップレベルナビゲーションメニューへの編成方法を管理するためには、ナビゲーションメニュー の基盤となるコードに して作業する必要があります。作業を行う場合は、コードはサーチやレポートを「コレク ション」として参照していることに注意してください。 重要：以降のサブトピックでは、保存 みサーチとレポートをトップレベルのナビゲーションメニューに編成/配置 するための、さまざまな作業について 明しています。ただし、実際の手順については 明していません。 保存 みサーチ/レポートの独自のナビゲーションを定義するには、メニューを構成している XML コードに関する専 門知識が必要です。詳細は、『Developing Views and Apps for Splunk Web』の「Build navigation for your app」 を参照してください。 デフォルトコレクションの設定 各 App には「未分類」サーチ用のデフォルトコレクションを設定する必要があります。未分類サーチは、明示的 にナビゲーションメニューコードが指定されていないサーチです。このコレクションに、新たに保存されたすべて のサーチが表示されます。たとえば、サーチ App のデフォルトコレクションは、[サーチとレポート] になりま す。 デフォルトのコレクションを設定しない場合、保存 みサーチにナビゲーションコードを手動で追加しないと、App のトップレベルナビゲーションメニューには表示されません。 注意：未分類のビューとダッシュボード用のデフォルトコレクションも設定する必要があります。 ナビゲーション XML を編集したデフォルトコレクションの設定については、『Developing Views and Apps for Splunk Web』の「Build navigation for your app」を参照してください。 保存 みサ ー チのネスト化したコレクションへの編成 App で作成された保存 みサーチ/レポート数が 加するにつれて、それらのサーチを論理的な手段で編成する必要が 出てきます。関数を使って、リストをグループ化するコレクションを手動で作成することができます。さらに、大 きなコレクションを小さなコレクショングループに分割する、ネスト化コレクションを設定することもできます。 サーチ App で、ネスト化コレクションは似たような種類のサーチをグループ化するために用いられています。 ナビゲーション XML を編集して、ネスト化コレクションに保存 みサーチ/レポートを編成する方法については、 『Developing Views and Apps for Splunk Web』の「Build navigation for your app」を参照してください。 保存 みサ ー チの動的なグル ー プ化 名前の一部の文字列が一致する保存 みサーチを動的にグループ化するように、コレクションを設定できます。た とえば、上記のサーチ App の例で、ネスト化コレクションは未分類のすべてのサーチを、タイトルの文字列 「admin」でグループ化しています。 保存 みサーチを一致するサブ文字列で動的にグループ化するには、2 種類の方法があります。 「未分類」のサブ文字列が一致するサーチのコレクション、コレクションには手動で他のコレクションに追 加されていないサーチのみが表示されます。 「すべて」のサブ文字列が一致するコレクション、この場合サブ文字列が一致するすべてのサーチが表示さ れます (ナビゲーションメニューの他の場所にある場合でも)。 注意：どちらの場合でも、ナビゲーションメニューが関連付けられている App で利用できる、保存 みサーチ/レ ポートのみが表示されます。 113 類似の保存 みサーチを動的にグループ化するための、ナビゲーション XML の設定については、『Developing Views and Apps for Splunk Web』の「Build navigation for your app」を参照してください。 デ ー タサマリ ー を使ったサ ー チの高速化 レポ ー トの高速化とサマリ ー インデックスについ て Splunk では、大量のデータに するレポートを生成することができます。ただし、そのようなレポートを生成する までに要する時間は、処理するイベント数に比例します。つまり、大量のデータセットに するレポートを生成す る場合は、長時間かかってしまいます。そのようなレポートをたまにしか生成しない場合は、生成までに要する時 間は問題にならないかもしれません。しかし、そのようなレポートを定期的に実行する (またはよく使われるダッ シュボードパネルの基盤として使用される) ことは実用的ではありません。さらに、Splunk 環境内でそのようなレ ポートを実行するユーザーが 加するにつれて、指数関数的にかかる時間が長くなっていきます。 大量のデータに するレポート生成を効率化するには、サーチのバックグラウンド実行により生成したデータサマ リーを作成する必要があります。この方法で要約されたサマリーデータに してサーチを実行すれば、大幅に処理 時間を短縮することができます (元の大量のイベントよりもサマリーは大幅に小さいため)。 Splunk には、レポートの高速化とサマリーインデックスの、2 種類のデータサマリー作成手段が用意されていま す。 レポ ー トの高速化 レポートの高速化は、単純なバックグラウンドでのデータサマリーサーチによる高速化で、チェックボックスを選 して時間範 を設定するだけで、手 にサマリーデータを生成することができます。以降のサーチをこの時間範 内に 実行した場合 (最低でも部分的に実行)、それらのサーチはより高速に実行されます。レポートの高速化は、以下の ような理由でサマリーインデックスよりも好まれます。 レポートの高速化は、チェックボックスを選 して時間範 を設定するだけの手 な作業。それ以降は何も面倒 な作業を行う必要はありません。サマリーインデックスの場合、それを使用するために特別なサーチコマン ドを指定したサーチを設計する必要があり、またサマリーインデックスの作成作業も必要です。 レポート高速化サマリーのデータは、類似のサーチと自動的に共有される。社員 Mary が、あるサーチのレ ポート高速化を有効にした場合を考えてみましょう。この場合、Splunk によりサーチのサマリーデータが作 成されます。数日後に、Joe が Mary といくつかの点が異なるだけで、ほぼ同じサーチを作成しました。Joe がサーチのレポート高速化をオンにして、それを保存すると、そのサーチにはすでに Mary のサーチで構築 されているサマリーデータが割り当てられます。つまり、Joe はサマリーデータが作成されるまで待つ必要 がありません。 レポート高速化機能の自動バックフィル。何らかの理由でデータの欠損が発生した場合、Splunk はそれを 出して、必要に じて自動的にサマリーを更新/再構築します。 レポート高速化サマリーは、インデックスのバケツと一緒に保管される。サマリーインデックスは、サーチ ヘッドに保管されます。サマリーデータをインデックスのバケツレベルで保管することにより、サマリーイ ンデックスの完全再構築の原因になりかねない、イベントの到着 延による問題に簡単に 処することができま す。Splunk サマリーはホットバケツとウォームバケツにまたがって同時に存在できるため、到着 延データ も簡単に要約することができます。 延データは単純にホットバケツに追加されます。 すべてのサーチにレポート高速化を使用できる訳ではないことに注意してください。レポートコマンドを使用する サーチ (テーブルやグラフ形式のレポートを生成するサーチ) にのみ利用することができます。また、サーチ内の 最初のレポートコマンドの前にあるコマンドはすべて、ストリーミングコマンドでなければなりません。この制限 は、サマリーがサーチヘッドではなくインデックスレベルで構築されることに関連しています。 このような条件を たすサーチの保存時または Splunk Web でダッシュボードへの追加時に、レポート高速化を有 効にすることができます。また、[管理] > [サーチとレポート] で、条件を たすサーチのレポート高速化を有効にす ることもできます。詳細は、このマニュアルの「サーチの保存とサーチ結果の共有」を参照してください。 Splunk 管理の [レポート高速化サマリー] ページで、レポート高速化で作成されたサマリーデータを管理すること ができます。詳細は、このマニュアルの「レポート高速化の管理」を参照してください。このトピックには、要約 の仕組みと利用できるサーチ/利用できないサーチの例も記載されています。 レポート高速化を使用する場合 レポート高速化は、10 万件以上のホットバケツイベントを持ち、前述の条件を たしている、処理に時間がかかる サーチに して有効です。 この機能の利用に適したサーチと適さないサーチの詳細は、このマニュアルの「レポート高速化の管理」を参照し 114 てください。 サマリ ー インデックス サマリーインデックスは、レポートコマンドの前に非ストリーミングコマンドが使われているサーチなどの、レ ポート高速化に適さない、処理に時間がかかるサーチの高速化に利用できます。サーチの結果を持つデータサマ リーの構築が関与するという点ではレポート高速化と似ていますが、この場合データサマリーは実際に特別なサマ リーインデックスで、サーチヘッド上で構築、保管されます。このサマリーインデックスは、目的のサーチに基づ くスケジュール みサーチにより構築されます。サマリーインデックスを使用する場合は、[管理] > [サーチとレ ポート] で、サマリーインデックスに [有効] を設定します。 たとえば、高速化するサーチがレポートコマンドを使用している場合、そのレポートコマンドの代わりに先頭が 「si」で始まる、サマリーインデックス用レポートコマンド (sichart、sitimechart、sistats、sitop、および sirare) を使用したサーチで、サマリーインデックスを構築することができます。 このマニュアルには、サマリーインデックスの設定に関する 2 つのトピックが用意されています。 「サマリーインデックスを使ったレポート効率の向上」には、si- コマンドを使用するスケジュール みサー チによる、サマリーインデックスの簡単な設定方法について 明しています。 「サマリーインデックスの設定」では、addinfo、collect、および overlap コマンドを使った、少し複 で困 難なサマリーインデックスの設定方法について 明しています。後者の方法は、総統計を考慮するサーチを設 定する場合にのみ使用します。 サマリーインデックスを使用する場合 使用しているサーチがレポート高速化に適している場合は、そちらを使用して大量のデータに するサーチを高速 化することをお勧めします。 以下のような場合に、レポート高速化の代わりにサマリーインデックスを使用します。 高速化したいサーチで、レポートコマンドの前に非ストリーミングコマンドが使用されている (レポート高 速化と同 に、サマリーインデックスを構築するサーチにはレポートコマンドが関与します)。 特定のサマリーインデックスに してサーチを実行したい (サーチ文字列に index=<summary_index_name> を指 定)。(レポート高速化の場合、特定のデータサマリーに してサーチを実行するかどうかは Splunk が判断しま す。) レポ ー ト高速化の管理 レポート高速化は、大量のデータを処理するために時間がかかるレポート作成サーチを高速化する、もっとも簡単 な手段です。レポートの高速化は、サーチの保存時または Splunk Web でのダッシュボードパネルの作成時に有効 にします。 ここでは、レポート高速化の詳細を 明していきます。以下のような事項が取り上げられています。 レポートサーチの自動高速化を有効にする方法。 適したサーチと適さないサーチの例 (レポート高速化は一定の条件を たすサーチにのみ適用できます)。 Splunk によるレポート高速化サマリーの作成と管理。 自動レポート高速化に使用するデータサマリーのレビューと管理を行うための、Splunk 管理の [レポート高 速化サマリー] ページの概要。 レポ ー ト高速化を有 効 にする 時間がかかるサーチでレポート高速化を使用するには： 1. サーチ App でサーチを実行します。 2. [保存] をクリックして、[サーチの保存...] を選 します。または、[作成] をクリックして、[ダッシュボードパネ ル...] を選 します。 3. [Turn on acceleration] (高速化をオンにする) が表示されている場合は、それをクリックします。([ダッシュ ボードパネルの作成] ダイアログボックスでは、[Turn on acceleration] は [パネル] ステップに表示されます。) 注意：以下の場合は [Turn on acceleration] は表示されません。 レポートを高速化する 限がない。ロールにサーチのスケジュール 限が必要です。 サーチがレポート高速化の条件を たしていない。詳細は、後述する「レポート高速化に適したサーチ」を参 照してください。 115 4. [サマリー範 ] フィールドが表示されます。サーチの実行 象期間に じて、[1 日]、[7 日]、[1 ヶ月]、[3 ヶ月]、[1 年]、または [全時間] を選 します。たとえば、過去 7 日間に してサーチを実行予定の場合は、[7 日] を選 します。 5. その他適切な設定を行ったら、サーチまたはパネルを保存します。 サーチを保存すると、サマリーの構築が開始されます (Splunk が、サマリーの作成がそのサーチに役立つと判断し た場合)。サーチを保存してもサマリーが作成されない場合は、「Splunk がサマリーを構築しない場合」を参照し てください ([管理] > [レポート高速化サマリー] に移動して、[サマリーステータス] が 0% のまま 化しない場合)。 サマリーの構築が完了したら、それ以降のサーチは前よりも高速に完了します。サマリーの詳細と仕組みについて は、後続のサブトピックを参照してください。 注意：タイムラインビューでサーチを実行している場合、レポート高速化はサーチモードが [スマート] または [高 速] に設定されているサーチでのみ機能することに注意してください。レポート高速化を設定したサーチに [詳細] サーチモードを選 すると、高速化されていない場合と同じ速度でしかサーチは実行されません。('ダッシュボード パネルのベースとなるサーチの場合、サーチモードは影響しません。)サーチモード設定の詳細は、『サーチマ ニュアル』の「サーチに合わせたサーチモードの設定」を参照してください。 代わりに、[管理] > [サーチとレポート] で、既存のサーチのレポート高速化を有効にすることもできます。 詳細は、このマニュアルの「サーチの保存とサーチ結果の共有」を参照してください。 レポ ー ト高速化に適したサ ー チ 高速化を使用するサーチは、レポートコマンド (chart、timechart、stats、top など) を使用している必要があり ます (これが、この機能が「レポート高速化」と呼ばれている理由です)。 また、最初のレポートコマンドの前に指定されているコマンドはすべて、ストリーミングコマンド (サーチが返す 各イベントに 換を適用しないコマンド) でなければなりません。たとえば、rex コマンドはストリーミングコマン ドで、サーチが返す各イベントに適用され、コマンドに指定されている正規表現に一致するフィールドを抽出しま す。他の一般的に使用されるストリーミングコマンドとしては、search、where、eval、regex、bin (明示的な期間 を指定しない場合)、および lookup (local=t を除く) が げられます。 注意：最初のレポートコマンドの後に非ストリーミングコマンドを指定しても、そのサーチは自動高速化の 象に なります (適している)。最初のレポートコマンドより前に非ストリーミングコマンドがある場合に、サーチが不適 格となります。 高速化を利用できるサーチの例 レポート高速化に適したサーチ文字列の例を以下に示します。 index=_internal | stats count by sourcetype index=_audit search=* | rex field=search "'(?.*)'" | chart count by user search test foo bar | bin _time span=1d | stats count by _time x y index=_audit | lookup usertogroup user OUTPUT group | top searches by group 高速化を利用できないサーチの例 レポート高速化に適さないサーチ文字列の例を以下に示します。 以下のサーチが適さない理由：これは単純なサーチでレポートコマンドがありません。 index=_internal metrics group=per_source_thruput 以下のサーチが適さない理由： eventstats はレポートコマンドではありません。 index=_internal | eventstats avg(x) by y 以下のサーチが適さない理由： transaction はストリーミングコマンドではありません。他の非ストリーミングコ マンドとしては、dedup、head、tail、および他のストリーミングコマンドのリストにないサーチコマンドなどが げられます。 index=_internal | transaction user maxspan=30m | timechart avg(duration) by user レポート高速化を利用できるけれどもあまり効果がないサーチ 技術的にはレポート高速化の要件を たすけれども、あまり効果がないサーチも存在しています。たとえば、サー チに複数のレポートコマンドが指定されており、最初のレポートコマンドが大量の出力行 (50000 行以上) を生成 するような、データ濃度が高いサーチが げられます。例： 116 index=* | stats count by id | stats avg(count) as avg, count as distinct_ids レポ ー ト高速化サマリ ー の理解 レポートサマリーの仕組みをより理解するために、以降のトピックではサマリーのさまざまな側面を取り上げてい ます。 レポート高速化サマリーの時間範 の設定 サーチのレポート高速化を有効にすると、特定の期間 (過去 1 日、過去 7 日、過去 1 ヶ月、過去 1 年など) に する サマリーの生成を開始します。この時間範 は、[サマリー範 ] リストで選 します。 たとえば、サマリー範 に「1 週間」を選 すると、任意の時点で過去 7 日間 (概算) の範 をカバーするデータサマ リーが作成されます。サマリーが完全に構築されたら、レポートの要約プロセスが 続され、常に設定されている 期間をカバーするように、期限が過ぎた古いサマリーデータは削除され、要約された新しいデータが追加されま す。 注意：サマリー範 は、 象とする範 の概算期間を表しています。わずかにサマリー範 を超えたデータが保管され ている場合もありますが、最初のサマリー作成中の時点を除いては、それが一致するイベントとして表示されるこ とはありません。 将来的に、過去 1 週間などのサマリー範 内の期間に してサーチを実行すると、サーチはソースインデックス (当 初のサーチ実行 象インデックス) ではなく、サマリーに して実行されます。たいていの場合、サマリーにはソース インデックスよりも大幅に少ないデータしか存在しておらず、事前に算出されたサーチパイプライン内の一部の結 果が含まれているため、初回実行時よりもサーチが大幅に短時間で完了します。 サマリーが一部の範 しかカバーしていないサーチを実行する場合、サーチはさほど速くは完了しません。これ は、Splunk が最低でもサーチの一部を、Splunk インデックス内の raw データに して実行する必要があるからで す。たとえば、サーチの [サマリー範 ] 設定が 1 週間の場合に、過去 9 日間を 象にサーチを実行した場合、過去 7 日間の部分に してのみサーチの高速化の恩恵が受けられます。残りの 8 日前と 9 日前のデータは、通常の速度で サーチが実行されます。 サーチ範 の値を設定する際には、このことを考慮するようにしてください。過去 7 日間を超えるけれども過去 30 日は超えないサーチを実行する予定の場合は、高速化の設定時にサマリー範 を 1 ヶ月に指定してください。 注意：通常 Splunk は、設定されているサマリー範 がカバーする、ホットバケツ内のイベント数が、10 万件以上 の場合にのみサマリーを生成します。詳細は、「Splunk がサマリーを構築/更新しない場合」を参照してくださ い。 Splunk の サ マ リ ー の 構 築 方 法 適性のあるサーチの高速化を有効にし、Splunk がサーチのサマリーの構築が妥当と判断した場合、サマリーを構 築するためのサーチが開始されます。構築が完了しても、10 分間隔でサーチの実行が 続され、サマリーが最新の 状態に保たれます。各更新により、サマリーデータは設定されている時間範 を常にカバーしています。この方法 によるサマリー構築により、最後に到着したデータも複 化することなく要約されます。 レポートサマリーの構築までには、少し時間がかかります。作成する時間は 象となるイベント数、総合的なサマ リー範 、およびサマリー内のタイムスパン長 (チャンク) によって異なります。 サマリー構築の進捗状況は、Splunk 管理の [レポート高速化サマリー] ページで確認できます。メインページの [サ マリーステータス] では、完了した割合を確認できます。 注意：通常のスケジュール みサーチと同 に、定期的にレポート高速化サマリーに自動的にデータを追加していく サーチも、サーチスケジューラーにより管理されます。サーチスケジューラーには、レポートを高速化するサマ リーデータの作成と更新のために、合計サーチ帯域幅の 25% までの利用が許可されています。 サーチスケジューラーは、レポート高速化サマリーにデータを追加するサーチを、最低の優先度で実行します。こ れらの「自動サマリーデータ作成」サーチがユーザーが定義したアラート、サマリーインデックスサーチ、および 通常のスケジュール みサーチにと競合している場合、ユーザー定義のサーチが常に最初に実行されます。この場 合、Splunk が他の優先するサーチを実行するために、サマリーが作成/更新されない可能性があります。 サーチスケジューラーの詳細は、このマニュアルの「スケジュール みサーチの優先度の設定」を参照してくださ い。 サマリーデータは、標準のタイムスパンでチャンクに分割される Splunk がサマリーを構築、管理する場合、統計的な精度を確保するために、全体的なサマリー範 に基づいて Splunk が自動的に判断する「タイムスパン」に従って、データをチャンクに分割します。たとえば、サーチのサ マリー範 が 1 ヶ月の場合、1d (1 日) のタイムスパンで分割されます。 117 サマリーのタイムスパンは、サマリーが統計的に正確なデータを含む最小の時間範 を表しています。1 時間のタイ ムスパンを持つサマリーに してサーチを実行する場合、サーチにサマリーデータを使用させるには、サーチに指 定する時間範 が、そのタイムスパンで割り切れなければなりません。タイムスパンが 1h の場合、過去 24 時間に するサーチは正常に機能しますが、過去 90 分を指定すると、サマリーデータを利用できない可能性があります。 サマリーには複数のタイムスパンが存在できる Splunk は、サマリーをできる限りサーチ可能にするために、必要に じてサマリーに複数のタイムスパンを割り当 てます。たとえば、3 ヶ月のサマリー範 に して、1mon と 1d のタイムスパンを利用できます。また、サマリーが 複数のインデックスバケツにまたがっており、バケツがそれぞれ非常に異なる時間量をカバーしている場合には、 Splunk が追加のタイムスパンを割り当てることがあります。たとえば、サマリーが 2 つのバケツにまたがってお り、最初のバケツのスパンが 2 ヶ月で、次のバケツのスパンが 40 分の場合、サマリーには 1d と 1m のタイムス パンが使用されます。 サマリーのタイムスパンは手動設定できる (非推 ) 前述のように、サマリーのタイムスタンプが自動的に判断します。ただし、savedsearches.conf でサーチレベル にタイムスパンを 更することができます (auto_summarize.timespan パラメータ)。サマリーのタイムスパンを手動 設定する場合は、極めて小さなタイムスパンを設定すると、サマリーの作成が極端に くなることに注意してくだ さい (特にサマリー範 が長い場合)。一方タイムスパンが大きすぎると、サマリー構築は素早く完了するけれど も、短い時間範 のサーチには利用できません。ほぼすべての場合において、最適なパフォーマンスとユーザビリ ティを確保するために、Splunk が決定したタイムスパンを使用するのが最良です。 レ ポ ー ト 高 速 化 サ マ リ ー の 作 成 /保 管 場 所 高速化レポートサマリーはインデクサー上で作成され、サマリー範 をカバーするバケツと一緒に保管されます。 レポートサマリーはインデックスではないことに注意する必要があります。クラスタリングはレポートサマリーを 象にしていません。クラスタリングを使用している場合に、プライマリバケツが利用できなくなると、次回のサ マリー更新サーチでサマリーがないことが 出され、再生成されるまでの間、サマリーは利用できません。 注意：Splunk がサマリーを再生成するまでの間、高速化レポートの結果は正常に返されますが、実行速度が くな ります。 単一のサマリーに する複数サーチ 複数のサーチが類似しており、類似の結果を返すような場合、単一のレポートサマリーをそれらのサーチに関連付 けることができます。すでにレポートサマリーが関連付けられているサーチと類似のサーチにレポート高速化を設 定する際に、Splunk がそれを 出して自動的にそのサーチに既存のサマリーを関連付けます。 たとえば、以下の 2 つの保存 みサーチは同じサマリーを使用します。 sourcetype=access_* | stats count by price sourcetype=access_* | stats count by price | eval discount = price/2 保存していないサーチをサマリーに して実行することもできます (基本的なサーチがサマリーを構築する保存 み サーチと一致して、時間範 もサマリー範 に適合する場合)。 [管理] > [レポート高速化サマリー] に移動して、サマリーに関連付けられているサーチを確認することができま す。 Splunk が サ マ リ ー を 構 築 /更 新 し な い 場 合 通常 Splunk は、要約するデータが以下の条件を たす場合にのみ、サーチのサマリーを生成/更新します。 サマリー範 の 象となるホットバケツ内のイベント数が、10 万件以上でなければなりません。この条件を た さない場合、[サマリーステータス] に警告メッセージ「Not enough data to summarize」が表示されます。 Splunk は、完成したサマリーがデプロイ環境内の合計バケツサイズの 10% を超えないことを前提にしてい ます。推定値がこの値を超えた場合、サマリー生成は 24 時間の間停止されます ([サマリーステータス] に 「Suspended」が表示)。 サマリーの [サマリーステータス] を表示するには、[管理] > [レポート高速化サマリー] に移動します。 サマリーを定義したのにこれらの条件を たさないためサマリーが作成されない場合でも、Splunk は定期的にこれ らの条件を たしているかどうかを確認します。Splunk が、サマリー範 が 象とするホットバケツ内のイベントが 10 万件以上でおり、完成後のサマリーが大きすぎないと判断した場合は、サマリーの作成/更新が開始されます。 サーチがサマリーを使用しているかどうかを判断する方法 サーチを実行して、サーチパフォーマンスが向上したならば (以前よりも速く完了する)、サマリーを利用している 118 ことは明白です。 それだけでは十分でない場合、またはパフォーマンスが向上したかどうか分からないような場合は、サーチジョブ 調査のデバッグメッセージで、サーチが特定のレポート高速化サマリーを使用しているかどうかを確認することが できます。以下に例を示します。 DEBUG: [thething] Using summaries for search, summary_id=246B0E5B-A8A2-484E-840C-78CB43595A84_search_admin_b7a7b033b6a72b45, この例では、最後の数字を含む文字列 b7a7b033b6a72b45 が、[レポート高速化サマリー] ページに表示されるサマ リー ID に しています。 [レポ ー ト高速化サマリ ー ] ペ ー ジの使用 Splunk 管理の [レポート高速化サマリー] ページで、レポート高速化サマリーをレビューしたり、サマリーのさま ざまな側面を管理することができます。[管理] > [レポート高速化サマリー] に移動してください。 [レポート高速化サマリー] ページでは、自分が表示 限を持っているサマリーに関する基本情報を参照することがで きます。 [サマリー ID] は、Splunk が各サマリーに割り当てる一意の数字と文字で構成される文字列です。サーチ文字列か ら生成され、サマリーファイル用に作成されるディレクトリ名の一部に使用されています。サマリー ID をクリッ クすると、サマリーの詳細が表示され、サマリー管理作業を行うことができます。この詳細ビューについては、 「サマリー詳細のレビュー」を参照してください。 ［サマリーを使っているレポート］ 列には、各サマリーに関連付けられている保存 みレポートが一覧表示されて います。特定のサマリーに関連付けられている各サーチが、そのサマリーによる高速化の恩恵を受けます。レポー トのタイトルをクリックすると、そのレポートの詳細ページが表示されます。 Splunk がサマリーの更新に費やしている労力を確認するには、[サマリー作成負荷] をチェックします。この値 は、データを追加するサーチの実行時間 (秒) を、サーチの実行間隔で除算したものです。サーチが 10 分 (600 秒) ごとに実行され、実行時間が 30 秒の場合、サマリー作成負荷は 0.05 になります。サマリー作成負荷が高く、サマ リーの [アクセスカウント] からサマリーがほとんど使用されていない、または長期に渡って使用されていないと 判断できるような場合は、システムへの負荷を減らすためにそれを削除することを 討してください。 ［サマリーステータス］ 列には、サマリーの全般的な状態、および前回の新規データによる更新時期が表示され ます。「Complete」、「Pending」、「Suspended」、「Not enough data to summarize」、またはその時点での サマリー構築完了割合が表示されます。現時点のデータでサマリーを更新する場合は、サマリー ID をクリックし て詳細ページに移動して、[更新] をクリックして、サマリー更新サーチを実行してください。 [サマリーステータス] が「Pending」の場合、関連付けられているサマリーが更新されたのが 10 分以上前で、再 更新する時期になっていることを表しています。この状態は、サマリーはわずかに古くなっているけれども、じき に更新されることを意味しています。 [サマリーステータス] が「Suspended」の場合、作成するサマリーが大きすぎるため、サマリーを作成するに値し ないと Splunk が判断したことを表しています。Splunk はサーチにより作成されるサマリーのサイズを予測し、そ れが するインデックスバケツサイズの 10% を超えると判断した場合、サマリーの作成を 24 時間停止します。た とえば、サマリーにインデックス全体の 90% のデータが含まれるような場合、サマリーを作成しても意味はあり ません。 サマリー停止を手動再開させることはできませんが、savedsearches.conf, にある auto_summarize.suspend_period の値を 更して停止期間を 更することは可能です。 [サマリーステータス] に「Not enough data to summarize」が表示されている場合、サマリー範 に するホットバ ケツ内の、サーチによって返されるイベント数が 10 万件未 のため、現在サマリーを生成または更新していないこ とを表しています。詳細は、前述の「Splunk がサマリーを構築/更新しない場合」を参照してください。 サマリ ー 詳細のレビュ ー サマリー詳細ページでは、特定のサマリーの詳細情報を表示したり、サマリーに する操作を行ったりすることが 119 できます。このページに移動するには、Splunk 管理の [レポート高速化サマリー] に表示されているサマリー ID を クリックします。 サマリーステータス [サマリーステータス] には、サマリーの基本的なステータス情報が表示されます。ここには、[レポート高速化サ マリー] ページ (前述) の [サマリーステータス] と同じ情報が表示されますが、それに加えてサマリーの 証ステータ スに関する情報も記載されています。 サマリーを現時点の情報で更新する場合は、[アクション] の下にある [更新] ボタンをクリックして、新たなサマ リー更新サーチを実行します。 サマリーの 証を行っていない場合、ここに 証ステータスは表示されません。 証を開始すると、ここに 証の完了割 合が表示されます。それ以外の場合は、前回のサマリー 証結果が表示されます。「Verified」または「Failed to verify」と一緒に、実行時間が表示されます。 サマリーの 証の詳細は、後述する「サマリーの 証」を参照してください。 サマリーを使っているレポート [このサマリーを使っているレポート] には、サマリーに関連付けられているレポート、およびその所有者とホーム App が表示されます。サーチのタイトルをクリックすると、そのサーチの詳細ページが表示されます。類似のサー チ (例：同じルートサーチを異なるレポートコマンドで 換するサーチ) は、同じサマリーを使用することができま す。 サマリー詳細 [詳細] セクションには、サマリーに関する一連の測定基準が表示されます。 [サマリー作成負荷] および [アクセスカウント] は、[レポート高速化サマリー] ページから複写されています。詳細 は、「[レポート高速化サマリー] ページの使用」を参照してください。 [ディスクサイズ] には、サマリーがディスクの 点から消費しているスペースを表しています。この測定基準 と、[サマリー作成負荷] および [アクセスカウント] を参考に、削除した方が良いサマリーを判断することができま す。 注意：[サイズ] の値が 0.00MB から 化しない場合は、サマリーに関連付けられているサーチに十分な数のイベント がないか (最低 10 万件のホットバケツイベントが必要)、または予測されるサマリーサイズがサーチに関連するバ ケツの 10% を超えているために、このサマリーが現在は生成されていないことを表しています。Splunk は定期的 にこのようなサーチをチェックして、サマリー作成の条件を たしたら自動的にサマリーの作成を開始します。 120 [サマリー範 ] は、サマリーが 象としている期間で、常に現在からの相 的な期間になります。この値は、サマリー を構築するサーチの定義時に設定します。詳細は、上記の「レポート高速化サマリーの時間範 の設定」を参照し てください。 [期間] には、サマリーを構成するデータチャンクのサイズ (タイムスパン) が表示されます。サマリーのタイムスパ ンは、サマリーが統計的に正確なデータを含む最小の時間範 を表しています。1 時間のタイムスパンを持つサマ リーに してサーチを実行する場合、サーチで良好な結果を取得するには、サーチに指定する時間範 が、そのタイ ムスパンで割り切れなければなりません。タイムスパンが 1h の場合、過去 24 時間に するサーチは正常に機能し ますが、過去 90 分を指定すると、問題が発生する可能性があります。詳細は、「Splunk のサマリーの構築方法」 を参照してください。 [バケツ] は、サマリーがいくつのインデックスバケツにまたがっているかを、[チャンク] はサマリーを構成してい るデータチャンク数を表しています。両方の測定基準はほぼ情報提供目的で用意されていますが、サマリーに関す るトラブルシューティングにも役立つ場合があります。 サマリーの 証 場合によっては、高速化されたレポートサーチが返す結果が、作成当時に返されていたサーチ結果と違っているこ とに気が付くこともあるでしょう。これは、タグ、イベントタイプ、またはサーチが使用する抽出ルールの定義の 更などにより、サーチのある側面が 化したような場合に、発生する可能性があります。 高速化レポートでこのような状態が発生したと考えられるような場合は、サーチに関連付けられているサマリーの 詳細ページに移動して 証プロセスを実行し、サマリーのサブセットを調査して、調査したすべてのデータの整合 性を 証することができます。データに不整合があった場合、 証が失敗したことを知らせるメッセージが表示され ます。 たとえば、特定の種類のネットワークセキュリティイベントに関連付けられた、イベントタイプ netsecurity を使 用するサーチを考えてみましょう。このサーチで高速化を有効にし、Splunk がサマリーを構築しました。その後 しばらくして、イベントタイプ netsecurity の定義が 更され、まったく別のイベントセットを指すようになりま した。そのためサマリーには、従来とは異なるデータセットが追加されることになります。この時点であなたは、 高速化サーチから返される結果が異なっているとこに気が付きました。そこで、Splunk 管理の [レポート高速化サ マリー] ページで 証プロセスを実行しました。サマリーの 証が失敗したため、ルートサーチの調査を開始して原因 を探します。 サマリー全体の 証には、サマリーの構築の完了と同じ位の時間がかかってしまうため、時間を節約するために も、 証プロセスではサマリーデータのサブセットのみを調査できれば理想的です。ただし、場合によっては 密な 証が必要なこともあります。 [ 証] をクリックすると [ 証サマリー] ダイアログボックスが表示されます。ここには、2 種類の 証オプションが用 意されています。 「高速 証」は、 密さを犠牲にして、サマリーデータの小さなサブセットを素早く 証します。 「徹底 証」では、速度を犠牲にしてサマリーデータを徹底的に 証します。 どちらの場合でも、予想 証時間が表示されます。 [開始] をクリックして 証プロセスを開始すると、サマリーの詳細ページの [サマリーステータス] で、 証の進捗状 況を確認することができます。 証プロセスが完了すると、 証が成功したか、または失敗したかが表示されます。 どちらの場合でも、 証ステータスをクリックして詳細を確認することができます。 証が失敗した場合、[ 証失敗] ダイアログに理由が表示されます。 121 証プロセス中、ホットバケツと構築中のバケツはスキップされます。 サマリーの 証が失敗した場合、ルートサーチ (または複数のサーチ) を確認して、修正して正しい結果を得られる かどうかを調査することができます。サーチが正しく機能するようになったら、[再構築] をクリックし、サマリー を再構築して整合性を回復することができます。現在のサーチをそのまま使用しても構わない場合は、単純にサー チを再構築してください。また、最初から新たなサーチを作成する場合は、サマリーを削除して新しいサーチを作 成してください。 サマリーの更新、再構築、削除 [サマリーステータス] が、サマリーがしばらく更新されていないことを示しており、サマリーを最新の状態に更新 したい場合は、[更新] をクリックします。[更新] をクリックすると、標準のサマリー更新サーチによりイベントの 追加が開始され、たとえば過去数時間の欠損データが補われます。 注意：サマリーの [サマリーステータス] が「Suspended」の場合、[更新] を使って最新の状態にすることはでき ません。 最初からインデックスを再構築する場合は、[再構築] をクリックします。この操作は、システムクラッシュやその 他の障害により欠損データがある場合、または 証失敗の原因を修復した、または現在の状態でサマリーをそのま ま使用しても構わない場合に行います。 システムからサマリーを削除する (そして今後サマリーを再生成しない) 場合は、[削除] をクリックします。サマ リーがあまり使用されておらず、占有しているスペースを他の目的で使用したいような場合にこの操作を行いま す。Splunk 管理の [サーチとレポート] ページを使って、サマリーに関連付けられているサーチのレポート高速化 を、再度有効化することができます。 サマリ ー インデックスを使ったレポ ー ト 効 率の向 上 大量のデータのレポートを効率的に生成するには、サマリーインデックスを使用します。サマリーインデックスで は、定期的に目的の情報を正確に抽出するサーチを設定します。Splunk がこのサーチを実行すると 回、指定した サマリーインデックスに結果が保存されます。次にこの大幅に小さな (そして「高速な」) サマリーインデックス に して、サーチやレポートを実行します。さらに、これらのレポートは、サマリーインデックスにデータを追加 するサーチの頻度を やすにより、統計的に正確になります (たとえば、過去 7 日間を 象とするサーチを手動実行 する場合、1 時間ごとにサマリーインデックスに してデータを追加するサーチを実行します)。 サマリーインデックスでは、コンピュータ的にコストが高いレポートを、時間の 過に じて分散させることができ ます。先ほどから取り上げている例では、サマリーインデックスに過去 1 時間のデータを追加するために、 時間 実行されるサーチは 1 分もかかりません。サマリーインデックスを利用せずに完全なレポートを生成しようとすれ ば、その 168 倍 (7日 * 24 時間/日) もの時間がかかってしまいます。 サマリーインデックスのさらに重要な特長として、異なるレポートまたは時間範 は違うけれども重なっている部 分がある同一のレポートに、コストを分配できることが げられます。火曜日に生成された同じサマリーデータ を、水曜、木曜、または翌週の月曜に実行される過去 7 日間のレポートに利用することができます。また、日当た りの平均 答サイズが必要な月次レポートに使用することもできます。 サマリ ー インデックスの使用事例 例 1 - 長期間の大量のデータセットに するレポート実行の効率化：ある会社で、Splunk を使って 日数千万件を超 えるイベントのインデックスが作成されている場合を考えてみましょう。各 Web サイトの過去 30 日間のページ ビューと訪問者数のレポートを表示するダッシュボードを、社員用に開発したいと考えています。 122 このレポートをプライマリデータボリュームに して実行することも可能ですが、目的のデータを抽出するため に、Web トラフィックとは無関係のデータも存在し、膨大な数のイベントを処理する必要があるため、実行が完 了するまでには非常に時間がかかってしまいます。それだけではありません。よく利用されるダッシュボードにレ ポートを表示すると言うことは、頻繁にサーチが実行されることを意味しており、そのせいで平均実行時間がさら に長くなり、多くのユーザーの不 につながる可能性があります。 サマリーインデックスを利用して週単位、日単位、または時間単位に、特定のサマリーインデックスにWeb サイ トのページビューとビジター数に関する情報を収集して追加する保存 みサーチを設定することができます。次に 月末に、この大幅に小さく必要なデータが集約されたサマリーインデックスに してサーチを実行すれば、レポー ト生成を素早く完了することができます。 例 2：ローリングレポートの作成：長期間に渡る総統計の連続カウントを表示するレポートを実行する場合を考え てみましょう。ここでは、たとえば管理している Web サイトからのファイルのダウンロード数をカウントしてい ます。 まず、指定した期間の合計ダウンロード数を返す保存 みサーチをスケジュールします。次にサマリーインデック スを使って、そのサーチ結果をサマリーインデックスに保管するように設定します。次に、サマリーインデックス 内のデータに してレポートを実行すれば、最新の合計ダウンロード数を取得することができます。 Splunk 開発者向けのビデオを参照して、サマリーインデックスの理論や実例を学習することも可能です。 サマリ ー インデックス用レポ ー トコマンドの使用 サマリーインデックスを初めて使用する場合、サマリーインデックスにデータを追加するサーチを定義するには、 サマリーインデックス用レポートコマンド (sichart、sitimechart、sistats、sitop、およびsirare) を使用して ください。これらのコマンドを使用すれば、その後サマリーインデックスに して実行するサーチと同じサーチ文 字列を使用することができます (ただし、後で実行するサーチでは、通常のレポートコマンドを使用します)。 注意：伝統的なサマリーインデックス作成サーチの作成方法に熟達している場合は、これらの「si」で始まるサマ リーインデックス用サーチコマンドを使用する必要はありません。そのような方法でサマリーインデックスを作成 し、それが適切に機能している場合は、更新する必要はありません。実際に、そちらの方法の方がより効率的な場 合があります。「si」で始まるコマンドを使用すると、手動で作成する場合と比べて作成されるインデックスがわ ずかに大きくなるため、パフォーマンスに影響が出てしまいます。 たいていの場合はさほど影響は出ませんが、作成するサマリーインデックスが比較的大きい場合は違いに気が付く こともあります。また、「si」で始まるコマンドで作成されたサマリーインデックスに して、複数のレポート生成 サーチを設定した場合にも、パフォーマンスに影響が出る場合があります。 「si」で始まるサーチコマンドを使用しないでサマリーインデックスを作成したい場合は、以降のセクションを参 照してください。 特別なコマンドを使わないインデックス生成の定義 以前のバージョンの Splunk では、サマリーインデックスを生成してデータを追加するためのサーチの設計に、入 念な注意を払う必要がありました。特に完成したサマリーインデックスに して実行するサーチに総統計が含まれ ている場合は、不正な結果を生み出さないように、インデックス設定サーチを入念に 討する必要がありました。 たとえば、完成したサマリーインデックスに して、平均 答時間をサーバー別に表示するサーチを実行する場合、 サマリーインデックス生成サーチを以下のようには設定することをお勧めします。 サマリーインデックスに して将来的に実行する予定のサーチよりも、より頻繁に実行するようにスケジュー ルされている。 サマリーインデックスに して将来的に実行を予定しているサーチよりも、多くの標本を抽出している。 インデックス生成サーチが加重平均を生成するようなサーチコマンドが含まれている (最初の段階で平均を 探している場合にのみ必要)。 サマリーインデックス用レポートコマンドは、最後の 2 点に注意しています。サマリーインデックスに追加される データが統計的に不正確な結果を産出しないように、調整する必要がある事項を自動的に判断しています。ただ し、それでもサマリーインデックス生成サーチは、サマリーインデックスに して実行されるサーチよりも頻繁に 実行する必要があります。 「si」で始まるコマンドを使わずにサマリーインデックスを設定しますか？addinfo、collect、overlap コマンド の詳細、重み付け平均を提供するサーチの策定方法、およびsavedsearches.conf を使ったサマリーインデックス 設定例については、このマニュアルの「サマリーインデックスの設定」を参照してください。 サマリーインデックスレポートコマンドの使用例 過去 1 年間の時間範 に して、以下のサーチを実行している場合を考えてみましょう。 eventtype=firewall | top src_ip 123 このサーチは、過去 1 年間の上位にあるソース IP を返しますが、 回インデックス全体をサーチするため完了まで に膨大な時間がかかっています。 そこで必要になるのが、「firewall」イベントタイプからの上位のソース IP データから成り立っているサマリーイ ンデックスを作成することです。以下のサーチを利用して、サマリーインデックスを構築することができます。こ のサーチを日単位で実行するようにスケジュールして、 回過去 24 時間の上位による src_ip 値のみを収集しま す。各日次サーチの結果は、「summary」と言う名前のインデックスに追加します。 eventtype=firewall | sitop src_ip 注意：サマリーインデックスデータ追加サーチは、完成したサーチに して実行する予定のサーチよりもより頻繁 に実行して標本を抽出するようにスケジュールすると、より統計的に精度が向上します。そこで、この例では 1 年 の期間をカバーするサーチの実行を予定しているため、情報を日単位でサンプリングするサマリーインデックス データ追加サーチを設定しています。 重要：サマリーインデックスデータ追加サーチを実行する場合、メインのサマリーインデックスレポートコマンド の後に、他のサーチ演算子にパイプしないようにしてください。つまり、| eval などのコマンドを追加しないよ うにしてください。サマリーインデックスにデータを追加するサーチではなく、サマリーインデックスに して実 行するサーチにサーチ演算子を使用してください。 重要：サマリーインデックス向けに最適化されたサーチ結果は、特別なフォーマットで保存されるため、最終的な 換が行われるまでの間 更することはできません。つまり、... | sistats <args> を使ってサマリーインデックス にデータを追加した場合、有効なデータ取得は index=<summary> source=<saved search name> | stats <args> の みになります。| stats <args> コマンドの前の、サマリーインデックスに するサーチでは、フィールドを作成、 更することはできません。 さて、このサーチを「Summary - firewall top src_ip」と言う名前で保存した場合を考えてみましょう (すべての保 存 みサマリーインデックスデータ追加サーチには、それらを識別するための名前を付ける必要があります)。サマ リーインデックスに結果が追加されたら、サマリーインデックスと情報を追加するために使用したサーチ名を使用 して、サマリーインデックスに するサーチやレポートを実行します。たとえば、過去 1 年間の上位の source_ips を取得するために使用するサーチは以下のようになります。 index=summary search_name="summary - firewall top src_ip" |top src_ip このサーチはサーチ名を指定しているため、他のサマリーインデックス追加サーチを使って保管された他のデータ はフィルタリングされます。このサーチは、時間範 が 1 年以上の場合でも、比較的素早く実行が完了します。 注意：サマリーインデックスに して特定の sourcetype 値を持つイベントを照会するサーチを実行する場合、代わ りに orig_sourcetype を使用する必要があることに注意してください。つまり、サマリーインデックスに して ...|stats timechart avg(ip) by sourcetype のようなサーチを実行する代わりに、...|stats timechart avg(ip) by orig_sourcetype を使用します。 なぜそうしなければならないのでしょうか？イベントをサマリーインデックスに追加すると、Splunk はその sourcetype の値を「stash」に 更し、元のソースタイプ値を orig_sourcetype に移動します。 Splunk Web でのサマリ ー インデックスサ ー チの設定 Splunk Web インターフェイスを使ってサマリーインデックスに するサーチを設定できます。サマリーインデック ス は、保存 み、スケジュール みサーチのアラートオプションになっています。サマリーインデックスの生成に使 用するサーチを決定したら、以下の手順に従ってください。 1. [管理] > [サーチとレポート] に移動します。保存 みサーチを選 します (新たに作成する場合は [新規] をクリッ ク)。 2. サーチをまだスケジュールしていない場合は、[スケジュールとアラート] で [このサーチをスケジュール] を選 します。サーチを適切な間隔で実行するようにスケジュールします。統計的に正確な最終レポートを作成するため に、サマリーインデックスにデータを追加 (生成) するサーチは比較的頻繁に実行する必要があることに注意して ください。将来的にサマリーインデックスに して実行するサーチが過去 1 週間の情報を収集する場合、サマリー データ追加サーチは時間単位に実行して時間ごとの情報を収集するようにしてください。過去 1 年間のデータに してサーチを実行する場合は、日単位に過去 1 日のデータをサマリーインデックスに追加します。 注意：データの取りこぼし (ギャップ) やオーバーラップがないようにサーチをスケジュールするようにしてくだ さい。詳細は、後述するこの問題に関するサブトピックを参照してください。 3. [アラート] の [条件] で、[常時] を選 します。 4. [アラートモード] で [サーチ当たり 1 回] を選 します。 124 5. [サマリーインデックス] で、[有効] を選 します。 6. [サマリーインデックスを選 ] リストで、サーチがデータを追加するサマリーインデックス名を選 します。デ フォルトのサマリーインデックス名は、「summary」になります。書き込み 限を持っているインデックスのみが 表示されます。さまざまなサマリーインデックスを利用する場合は、個別のサマリーインデックスを作成しなけれ ばならないこともあります。新たなインデックスの作成の詳細は、『インデクサーとクラスタの管理マニュアル』 の「複数のインデックスの設定」を参照してください。サマリーデータ収集専用のインデックスを作成することも お勧めできます。 注意：存在しないインデックス名を入力した場合、Splunk は設定したスケジュールに従ってサーチを実行します が、データはサマリーインデックスには保存されません。 7. (オプション) [フィールドの追加] で、サマリーインデックス定義にフィールド/値のペアを追加することができま す。これらのキー/値のペアは、サマリーインデックスに格納された各イベントに して設定され、後ほどのサーチ で簡単に探すことができます。たとえば、サマリーインデックスにデータを追加する保存 みサーチ名 (report=summary_firewall_top_src_ip) または サーチがデータを追加するインデックス名 (index=summary) を追加 して、後ほどそれらに してサーチを実行することができます。 注意：また、savedsearches.conf 内のサマリーインデックス設定にフィールド/値のペアを追加することもできま す。詳細は、『ナレッジ管理マニュアル』の「サマリーインデックスの設定」を参照してください。 サーチの保存とそれらのサーチに基づくアラートの定義については、「サーチの保存とサーチ結果の共有」 (ナ レッジの管理マニュアル) および「アラートの作成」 (アラートマニュアル) を参照してください。 デ ー タ ギ ャ ッ プ と オ ー バ ー ラ ッ プ を 回 避 す る デ ー タ 生 成 (追 加 ) サ ー チ の ス ケ ジ ュ ー ル データのギャップやオーバーラップを最低限に抑えるために、サマリーインデックスの生成とデータ追加に使用す るサーチのスケジュールには、適切な間隔と期間を設定する必要があります。 サマリーインデックス内のギャップは、サマリーインデックスがイベントを作成できなかった期間です。以下のよ うな場合にギャップが発生します。 サマリーインデックスにデータを追加するサーチの実行に時間がかかりすぎて、次回に予定されている実行 時間を過ぎてしまった。たとえば、一般的にサーチの実行完了までに 7 分ほどかかるサーチを、サマリーに データを追加するサーチとして 5 分間隔で実行する場合、先に実行されているサーチが完了するまで後続の サーチは実行されません。 サマリーインデックス追加サーチに してリアルタイムスケジューリングが使用された。たとえば誤って savedsearches.conf 内のサーチ定義を編集して、realtime_schedule 属性に 1 を設定し、リアルタイムスケ ジューリングが有効になっている可能性があります。この設定では、複数のサーチを同時実行している場 合、データコレクションにギャップが発生してしまう可能性があります。Splunk Web でサマリーインデッ クス追加サーチを定義する場合、サマリーインデックスオプションを [有効] にして、サーチを保存します。 これにより、Splunk は realtime_schedule に 0 を設定し、サーチの定期実行がスキップされないようにして います。詳細は、このマニュアルの「スケジュール みサーチの優先度の設定」を参照してください。 splunkd が停止している。Splunk がイベントのインデックスを作成できないと、インデックスサマリーデー タにギャップが生じてしまいます。 オーバーラップとは、同じタイムスタンプを共有している (同じサーチからの) イベントです。イベントのオー バーラップにより、サマリーインデックスから作成されるレポートや統計が歪曲されてしまいます。保存 みサー チの時間範 を、サーチのスケジュール間隔よりも長く設定した場合に、オーバーラップが発生する可能性があり ます。そのため、たとえば 1 時間ごとに実行するサーチで、過去 90 分のデータを収集するようなことは避けるよ うにしてください。 注意：サマリーインデックスデータにギャップまたはオーバーラップが存在していると考えられる場合に備えて、 Splunk にはそれを 出してバックフィル (ギャップの場合) またはオーバーラップを削除する手段が用意されていま す。詳細は、『ナレッジ管理マニュアル』の「サマリーインデックスのギャップとオーバーラップの管理」を参照 してください。 125 サマリ ー インデックスの仕組み サマリーインデックス は、保存されたスケジュール みサーチ用のアラートオプションです。サマリーインデック スを有効にした保存 みサーチを実行すると、サーチ結果は一時的にファイル ($SPLUNK_HOME/var/spool/splunk/<savedsearch_name>_<random-number>.stash) に保管されます。このファイルか ら、Splunk は addinfo コマンドを使って、各結果の設定中に現在のサーチに関する全般情報と指定フィールドを 追加します。次にできあがったサマリーインデックス内のイベントデータのインデックスを作成します (デフォル トは index=summary)。 注意：現在のサーチに関する全般情報を含むフィールドを、サマリーインデックスに入れるサーチ結果に追加する には、addinfo コマンドを使用します。サーチの全般情報を追加することで、サマリーインデックスに保管する結 果のレポートを手 に実行することができます。 タイムスタンプを持たないデ ー タのサマリ ー インデックス サマリーインデックスイベントの時間を設定するために、Splunk は以下の情報を順番に使用していきます (優先度 順)。 1. 要約されるイベントの _time 値 2. サーチのもっとも早い (または最小) 時刻 3. 現在のシステム時刻 (「もっとも早い」の値が指定されていない「全時間」サーチ) たいていの場合、イベントにはタイムスタンプがあります。そのため、最初の手段でサマリーインデックスにタイ ムスタンプが保持されます。しかし、_time フィールドが含まれていないデータを要約する場合 (ルックアップか らのデータなど)、結果となるイベントのタイムスタンプはサーチのもっとも早い時間になります。 たとえば、 晩午前 0 時にルックアップ「asset_table」を要約しており、このテーブルに _time 列がない場合、そ のサマリーの _time 値はサーチのもっとも早い時間になります。サーチの時間範 を -24h +0sに設定した場合、要 約されたイベントの _time 値は now()-86400 になります (サーチ開始時刻 - 86,400 秒 (24 時間))。つまり、このサ マリーインデックス追加サーチで見つかった、_time フィールド値をもたない各イベントに して、同一の _time 値 (サーチのもっとも早い時間である) が与えられます。 タイムスタンプを持たないデータのサマリーインデックスを作成する際には、サーチの一部として _time 値を手動 作成することをお勧めします。先ほどの例で作業を続行します。 |inputlookup asset_table | eval _time=now() 「 si」で始まるサマリ ー インデックスコマンドで追加されたフィ ー ルド サマリーインデックスにデータを追加するために、si* コマンドを使ってサーチを実行すると、サマリーインデッ クスデータには一連の特殊フィールドが追加されます。これらのフィールドはすべて psrsvd で始まります (例：psrsvd_ct_bytes や psrsvd_v)。chart、timechart、stats などのレポートコマンドを使って、サマリーイン デックスに してサーチを実行すると、psrsvd* フィールドを使ってテーブルやグラフ用の統計的に正しい結果が算 出されます (psrsvd は、「prestats reserved」を表しています)。 大部分の psrsvd フィールドは、データ セット内の元の (サマリーインデックス作成前の) ファイルにある、特定の フィールドに関する情報を表しています。ただし、一部の psrsvd フィールドは、単一のフィールドの情報を表す のではありません。一般的なパターンとしては、psrsvd_[type]_[fieldname] が げられます。たとえ ば、psrsvd_ct_bytes は bytes フィールドのカウント情報を表しています。 このような psrsvd フィールドの一覧を以下に示します。 = カウント = グループカウント (統計の「集 」カウントで単一フィールドを 象にしているのではありません) nc = 数値カウント (数値の数) sm = 和 ss = 平方和 v = バージョン (単一のフィールドではない) vt = 値タイプ (関連フィールドの精度を含む) ct gc サマリ ー インデックスのギャップとオ ー バ ー ラッ プの管理 126 サマリーインデックスに収集されたデータに、ギャップやオーバーラップが存在していると、サマリーインデック スサーチの精度が低下する可能性があります。 サマリーインデックスデータ内のギャップはさまざまな理由で発生します。 当初サマリーインデックスには、データの収集を開始した時点からのデータのみが含まれている：独自に バックフィルスクリプトを使ってサマリーインデックスに追加しない限り、サマリーインデックスにはデー タの収集開始日以前のデータは存在しないことを忘れないでください。 splunkd 機能停止：splunkd が長時間停止すると、サマリーインデックスにデータを追加するサーチの実行ス ケジュールによっては、データにギャップが生じる可能性があります。 サーチの実行時間がスケジュール間隔よりも長かった：データ追加サーチの実行時間が次回の実行予定時間 を超過した場合、前のサーチの動作中は予定されている次のサーチは実行されないため、データのギャップ が発生してしまいます。たとえば、5 分間隔でデータ追加サーチを実行するようにスケジュールしている場 合に、あるサーチの実行が 5 分以上かかってしまうと、データコレクションにギャップが発生します。 オーバーラップは、同じタイムスタンプを共有している (同じデータ追加サーチからの) サマリーインデックス内 のイベントです。オーバーラッピングイベントにより、サマリーインデックスから作成されるレポートや統計が歪 曲されてしまいます。保存 みサーチの時間範 を、サーチのスケジュール間隔よりも長く設定した場合に、オー バーラップが発生する可能性があります。そのため、たとえば 1 時間ごとに実行するサーチで、過去 90 分のデー タを収集するようなことは避けるようにしてください。 注意：サマリーインデックスの作成と管理に関する一般情報については、『ナレッジ管理マニュアル』の「サマ リーインデックスを使ったレポート効率の向上」を参照してください。 バックフィルスクリプトを使った他のデ ー タの追加 /ギャップの埋め し スクリプトは、サマリーインデックスのギャップをバックフィルするスクリプトで、サマ リーインデックスにデータを追加する保存 みサーチを、その予定時刻に 象時間範 に して実行されたかのように実 行することで、ギャップを埋め します。つまり、新しいサマリーインデックスが今週初めからデータの収集を開 始した場合でも、必要に じて fill_summary_index.py を使って、サマリーインデックスにたとえば過去 1 ヶ月の データを追加することができます。 fill_summary_index.py また、fill_summary_index.py の実行時に、App とその App に関連付けたサマリーインデックスサーチのリスト に するバックフィルアクションをスケジュールしたり、単純に App に関連するすべての保存 みサーチをバック フィルしたりできます。 CLI から fill_summary_index.py コマンドを入力する場合、バックフィル操作の「もっとも早い時刻」と「もっと も い時刻」を指定して、バックフィルの時間範 を設定する必要があります。相 時間識別子 (例：「3 日前の午前 0 時」なら -3d@d) や UTC エポック数値を使って、正確な時間を指定することができます。スクリプトは、サマリー インデックスを実行するはずだった時点の、 象時間範 を自動的に算出します。 注意：fill_summary_index.py スクリプトが欠損データに する時点のデータ追加サーチのみを実行するように、 実行時には -dedup true を指定する必要があります。 スクリプトには、必要な認証情報 (ユーザー名とパスワード) を指定する必要があります。 スクリプト実行時に有効な Splunk キーが分かっている場合は、-sk オプションを利用して情報を指定することが できます。 fill_summary_index.py このスクリプトは、コマンドラインに指定されていない任意の必要な情報 (サマリーインデックスサーチ名、認証 情報、時間範 など) の入力を要求するように設計されています。 fill_summary_index.py の 実 行 例 以下のような状況の場合： splunkdotcom App のすべてのサマリーインデックスサーチをバックフィルする必要があります。ただし、すでに サマリーインデックス内にデータが存在しているサーチはスキップする必要があります。 このような場合は、以下のコマンドを CLI に入力します： ./splunk cmd python fill_summary_index.py -app splunkdotcom -name "*" -et -mon@mon -lt @mon -dedup true -auth admin:changeme 以下のような状況の場合： 過去 1 年の my_daily_search サマリーインデックスサーチをバックフィルする必要がありますが、任意の時点の同 127 時実行サーチ数を 8 件以下にする必要があります (バックフィルデータの収集が Splunk のパフォーマンスに与え る影響を減らすため)。すでにサマリーインデックス内にデータが存在しているサーチでも、スキップせずに実行 します。my_daily_search サマリーインデックスサーチは、「admin」ロールが所有しています。 このような場合は、以下のコマンドを CLI に入力します： ./splunk cmd python fill_summary_index.py -app search -name my_daily_search -et -y -lt now -j 8 -owner admin -auth admin:changeme 注意：特定のユーザーまたはロールが所有しているサーチの場合は、-owner オプションを指定する必要がありま す。 fill_summary_index.py が 実 行 中 に 中 断 さ れ た 場 合 fill_summary_index.py を起動する App (デフォルトはサーチ (search)) 内に、ログ (log) ディレクトリがあります。 このディレクトリには、空の一時ファイル「fsidx*lock」があります。 「fsidx*lock」ファイルを削除すれば、fill_summary_index.py を再起動できます。 fill_summary_index.py の 使 用 例 と コ マ ン ド CLI から、開始するために以下のように入力します。 python fill_summary_index.py 次に、以下の表を参考に必要なオプションとフィールドを追加してください。 注意： <boolean> オプションに指定できる値は、真 (True) の場合 1、t、true、または yes、偽 (False) の場合 0、f、false、no です。 フィールド 値 -et <string> もっとも早い時間 (必須)。UTC または相 時刻識別子。 -lt <string> もっとも い時間 (必須)。UTC または相 時刻識別子。 -app 使用する App コンテキスト (デフォルトは None)。 <string> -name <string> -names <string> -namefile <filename> -owner <string> -index <string> -auth <string> -sleep <float> -j <int> -dedup <boolean> showprogress <boolean> 単一の保存 みサーチ名を指定します。複数回指定して、複数の名前を設定することもできます。 サマリーインデックスアクションを持つすべての保存 みサーチすべてを有効にする場合は、ワイ ルドカード (*) を使用します。 保存 みサーチ名のカンマ区切りリストを指定します。 保存 みサーチを 1 行に 1 つずつ記載したファイルを指定します。# から始まる行は注釈とみなさ れて、無視されます。 使用するユーザーコンテキスト (デフォルトは「None」)。 保存 みサーチがデータを追加するサマリーインデックス。インデックスを指定しない場合、バッ クフィルスクリプトが自動的に判断を試みます。判断できなかった場合は、デフォルトの 「summary」が使用されます。 認証文字列は、<username> または <username>:<password> で指定します。ユーザー名のみを指定 した場合、パスワードを要求するプロンプトが表示されます。 各サーチ間に待機する秒数。デフォルトは、5 秒です。 最大同時実行可能サーチ数 (デフォルトは 1)。 このオプションに真 (True) を設定すると、すでにサマリーインデックス内にデータが存在してい る場合、それに する保存 みサーチは実行されません。このオプションを省略した場合、デフォ ルトの偽 (False) が仮定されます。 このオプションに真 (True) を設定すると、実行中の各サーチの進捗状況が定期的に表示されま す。このオプションを省略した場合、デフォルトの偽 (False) が仮定されます。 詳細オプション：大部分の場合、これらは使用しないでください。 -trigger このオプションに偽 (False) を設定すると、各サーチは実行されますが、サマリーインデックス 128 <boolean> 処理は行われません。このオプションを省略した場合、デフォルトの真 (True) が仮定されます。 -dedupsearch 特定のスケジュール時刻の特定の保存 みサーチに するデータが存在する場合の、判断に使用す るサーチを指定します。 <string> -namefield <string> -timefield <string> データを生成した保存 みサーチの名前を含む、サマリーインデックスデータ内のフィールドを示 します。 データを生成した保存 みサーチのスケジュール時刻を含む、サマリーインデックスデータ内の フィールドを示します。 サマリ ー インデックスの設定 サマリーインデックスの概要および Splunk Web を使ったサマリーインデックスの設定方法については、『ナレッ ジ管理マニュアル』の「サマリーインデックスを使ったレポート効率の向上」を参照してください。 サーチが定期的に実行されるアラートとして設定され、実行時に 回アラートを生成するように設定され、[サマ リーインデックスを有効にする] アラートを有効にしないと、savedsearches.conf でサマリーインデックスの手動 設定を行えません。 また、データを追加するサマリーインデックスサーチの名前を入力する必要があります。この作業は、[サマリー インデックスを有効にする] を選 した後に、保存 みサーチダイアログから行います。デフォルトのサマリーイン デックスは、「summary」です (何も指定しない場合に Splunk が使用するサマリーインデックス)。 さまざまなサマリーインデックスサーチを実行する予定の場合は、必要に じて他のサマリーインデックスを作成 します。新たなインデックスの作成の詳細は、『インデクサーとクラスタの管理マニュアル』の「複数のインデッ クスの設定」を参照してください。サマリーデータ収集専用のインデックスを作成することもお勧めできます。 注意：存在しないインデックス名を入力した場合、設定したスケジュールに従ってサーチは実行されますが、サマ リーインデックスにデータは保存されません。 保存 みサーチの詳細は、このマニュアルの「サーチの保存とサーチ結果の共有」を参照してください。 サマリーインデックスにデータを追加するサーチ (定期的に実行される「スケジュール みサーチ」で、[管理] > [サーチとレポート] の、アラートの詳細ページで [サマリーインデックスを有効にする] オプションが選 されてい る必要があります) の定義方法の詳細は、このマニュアルの「サマリーインデックスを使ったレポート効率の向 上」を参照してください。 注意：サマリーインデックスの構築に使用するサーチを定義する場合、大部分の場合は、そのサーチでサマリーイ ンデックス用レポートコマンドを使用する必要があります。これらのコマンドの先頭は「si」で始まってお り、sichart、sitimechart、sistats、sitop、および sirare が存在しています。これらのコマンドを使って作成 するサーチは、将来的に完成したサマリーインデックスに するサーチとほぼ同じになります (使用するレポートコ マンドが違う)。 このサマリーインデックス用レポートコマンドは、「サマリーインデックスサーチ定義の 討事項」に 明されてい る問題 (例：データ追加サーチに短い時間範 を設定、多数の標本を取得するような設定など) を自動的に考慮しま す。これらの問題は、サマリーインデックスの作成に使用するサーチに、サマリーインデックス用レポートコマン ドを使用しない場合にのみ考慮する必要があります。 サマリーインデックス用レポートコマンドを使用しない場合は、addinfo および collect コマンドを使って保存 み スケジュールサーチを作成し、それを使ってあらかじめ作成したサマリーインデックスにデータを追加します。詳 細は、このトピックの「サマリーインデックスへのデータの手動追加」を参照してください。 保存 みスケジュ ー ルサ ー チのサマリ ー インデックスのカスタマイ ズ Splunk Web を使って、データ追加用の保存 みスケジュールサーチのサマリーインデックスオプションを有効にす ると、$SPLUNK_HOME/etc/system/local/savedsearches.conf 内に自動的にスタンザが生成されます。このスタン ザを編集して、サーチのサマリーインデックスをカスタマイズすることができます。 Splunk Web を使ってサーチの保存とスケジュールをしたけれども、Splunk Web を使ってサーチのサマリーイン デックスを有効にしていない場合、savedsearches.conf を編集して、その保存 みサーチのサマリーインデックス を有効にすることができます (データを追加するサマリーインデックスが存在している場合)。インデックスの手動 設定の詳細は、『インデクサーとクラスタの管理マニュアル』の「インデックスの管理について」を参照してくだ さい。 [ <name> ] action.summary_index = 0 | 1 129 action.summary_index._name = <index> action.summary_index.<field> = <value> [<name>]：スタンザ名は、サマリーインデックスを有効にした保存 みスケジュールサーチ名に基づいて指定 されます。 action.summary_index = 0 | 1：1 を設定すると、サマリーインデックスが有効になります。サマリーイン デックスを無効にする場合は、0 を設定します。 action.summary_index._name = <index>：サーチがデータを追加する、サマリーインデックス名を示しま す。このサーチに して特定のサマリーインデックスを作成した場合は、その名前を <index> に入力します。 デフォルトは summary です。 action.summary_index.<field> = <value>：このサーチでサマリーインデックスに追加する各イベントの、 フィールド/値のペアを指定します。複数のフィールド/値のペアを定義できます。 このフィールド/値のペアは一種の「タグ」として機能し、サーチ実行時に追加される大量のイベントデータか ら、特定のイベントを識別するために役立ちます。このキーは省略できますが、最低 1 つのフィールド/値のペア を指定することをお勧めします。 たとえば、サマリーインデックス (action.summary_index.report = summary_firewall_top_src_ip) にデータを追 加する保存 みサーチ名、またはサーチがデータを追加するインデックス名 (action.summary_index.index = search) を追加します。 サマリ ー インデックスに役立つサ ー チコマンド サマリーインデックスは、一連の特別なレポートコマンドを活用しています。Splunk Web またはサマリーイン デックス用レポートコマンドを使用せずに、サマリーインデックスを手動で作成する場合は、これらの特別なコマ ンドを使用する必要があります。 addinfo：addinfo を使って、現在のサーチに関する全般情報を含むフィールドを、サマリーインデックスに 入れるサーチ結果に追加します。任意のサーチに | addinfo を追加して、サマリーインデックスに追加され た結果がどのようになるかを確認してください。 collect：collect を使って、サーチ結果をサマリーインデックスに追加します。他のインデックスにサーチ 結果を追加する場合は、| collect を使用します (collect コマンドのコマンドラインオプションを使用)。 overlap：overlap を使って、サマリーインデックス内のギャップやオーバーラップを判別します。overlap は、サマリーインデックス内でタイムスタンプ値がオーバーラップしている、同じ query_id を持つイベント を 出、またはイベントが欠損している期間を識別します。 サマリ ー インデックスにデ ー タを追加するサ ー チの手動設定 Splunk Web のサーチオプションダイアログまたはサマリーインデックス用レポートコマンドを使用せずに、サマ リーインデックスを設定する場合は、まず他のインデックスを設定する場合と同 に、indexes.conf を使ってサマ リーインデックスを設定する必要があります。インデックスの手動設定の詳細は、『インデクサーとクラスタの管 理マニュアル』の「インデックスの管理について」を参照してください。 重要：indexes.conf の 更内容を有効にするには、Splunk を再起動する必要があります。 1. Splunk Web のサーチバーで、結果を要約するサーチを実行します。 サーチには、適切な時間範 を指定してください。サーチが生成する結果数は、サーチに設定した最大サーチ 結果数の制限内でなければなりません。 10 分、2 時間、1 日などの、データに して適切な時間間隔を選 してください。(Splunk Web を使ったサーチ の実行間隔のスケジュールについては、『アラートマニュアル』の「スケジュール みアラートの定義」を参 照してください。) 2. addinfo サーチコマンドを使用します。サーチの最後に | addinfo を追加します。 このコマンドは、collect コマンドがサマリーインデックスにイベントを追加するために必要な、サーチに関 する情報をイベントに追加します。 | addinfo を任意のサーチに追加して、サマリーインデックス内のサーチ結果がどうなるのかを、プレ ビューすることができます。 3. collect サーチコマンドを追加します。サーチの最後に |collect index=<index_name> addtime=t marker="info_search_name=\"<summary_search_name>\"" を追加します。 を、サマリーインデックス名に置換してください。 は、インデックス内のこのサーチの結果を 索するためのキーに置換してください。 生成されたイベントに して、overlap サーチコマンドを使用する場合は、summary_search_name を設定する 必要があります。 index_name summary_search_name 注意：一般的には、用意されている summary_index アラートアクションを使用することをお勧めします。addinfo と collect を使った設定には、スケジュール みサーチからサマリーインデックスイベントを生成する場合には不 130 要な、いくつかの追加作業を行う必要があります。すでに 過した時間範 に してサマリーインデックスをバック フィルするためには、手動設定が必要です。 サマリ ー インデックスサ ー チ定義の 討事項 何らかの理由で、サマリーインデックス用レポートコマンドを使用せずに、サマリーインデックスにデータを追加 するサーチを設定する場合は、いくつかの事項を 討しておく必要があります。サマリーインデックスの場合、鶏 よりも卵が先に登場します。実際に将来使用するサーチを使って、利用するサマリーインデックスにデータを追加 します。 多くのサマリーサーチに総統計情報が含まれています (例：メインインデックスが 1 日当たり数百万件のイベント を生成する環境での、昨日のファイアウォール攻 に関連する上位 10 件の IP アドレスのサーチ)。 将来的にサマリーインデックスに して実行するサーチと、同じサーチから得られる結果をそのサマリーインデッ クスに追加すると、統計的に不正確な結果になる可能性があります。サマリーインデックスサーチから生成される 総統計の精度を向上するために、サマリーインデックスにデータを定義する場合には、以下のルールに従ってくだ さい。 データ追加サーチに短い時間範 を指定 サマリーインデックスにデータを追加するサーチは、将来的にそれに して実行するサーチよりも、短い間隔 (より 頻繁に) 実行する必要があります。できる限り小さな時間範 を使用してください。たとえば、 日の「トップ」レ ポートを生成する必要がある場合、サマリーインデックスにデータを追加するサーチでは、標本を 1 時間ごとに取 得します。 データ追加サーチが多くの標本を取得するように設定 サマリーインデックスにデータを追加するサーチは、将来的にサマリーインデックスに して実行するサーチより も、より多数の標本を取得する必要があります。たとえば、将来的にサマリーインデックスに して「 日上位 10 件」の攻 が多い IP アドレスをサーチする予定の場合は、サマリーインデックスにデータを追加するサーチでは、 「時間ごとの上位 100 件」の攻 が多い IP アドレスをサーチしてサマリーインデックスに追加します。 このようなアプローチには 2 つの利点があります。まず、上位 10 件レポートの高い統計的精度が保証されます (総合的な標本数が多く、頻繁に取得されているため)。また、レポートの報告数を 20 件や 30 件に 更したいよう な場合でも、ある程度はそれに 処できる柔軟性が確保されます。 サマリーインデックス用レポートコマンドでは、完成したサマリーインデックスに して実行するサーチよりも多 くの標本を自動的に抽出するため、作成するサマリーインデックスのイベントデータが不正に歪曲されることはあ りません。これらのコマンドを使用しない場合、head コマンドを使って、将来的にサマリーインデックスに して 実行するサーチよりも多数の標本を抽出するように、サマリーインデックスデータ追加サーチを設定することがで きます。時間ごとのサマリーインデックスデータ追加サーチには | head=100 を使用し、完成したサマリーイン デックスに する日次サーチには | head=10 を使用します。 加重平均を取得するためのサーチ設定 サマリーインデックスデータ追加サーチに平均が関与しており、サマリーインデックス用統計コマンドを使用して いない場合は、サーチが加重平均を取得するように設定する必要があります。 たとえば、時間ごと、日ごと、または週ごとの平均 答時間に関するレポートを作成する必要がある場合を考えて みましょう。あなたはそのために、「時間ごとの平均」を平均化して「日ごとの平均」を生成しました。残念なが ら、それぞれの「時間ごとの平均」のイベント数が同じではないと、日ごとの平均は歪曲された値になってしまい ます。正しい「日ごとの平均」を取得するには、加重平均関数を使用します。 以下の式は、stats コマンドと eval コマンド、および sum 統計集計子を併用して、加重平均から日ごとの平均 答 時間を正確に算出します。この例では、eval コマンドが daily_average フィールドを作成します。このフィール ドには、平均 答時間の合計を平均 答時間数で除算した値が格納されます。 | stats sum(hourly_resp_time_sum) as resp_time_sum, sum(hourly_resp_time_count) as resp_time_count | eval daily_average= resp_time_sum/resp_time_count | ..... デ ー タ ギ ャ ッ プ と 重 複 を 回 避 す る デ ー タ 生 成 (追 加 ) サ ー チ の ス ケ ジ ュ ー ル 上記の 2 つのルールの他にも、データのギャップや重複を最低限に抑えるために、サマリーインデックスの生成と データ追加に使用するサーチのスケジュールには、適切な間隔と 延を設定する必要があります。 サマリーインデックス内のギャップは、サマリーインデックスがイベントのインデックスを作成できなかった期間 です。以下のような場合にギャップが発生します。 splunkd が停止している。 131 サマリーインデックスにデータを追加する保存 みスケジュールサーチの実行に時間がかかりすぎて、次回に 予定されている実行時刻を過ぎてしまった。たとえば、一般的にサーチの実行完了までに 7 分ほどかかる サーチを、サマリーにデータを追加するサーチとして 5 分間隔で実行した場合、前のサーチが完了するまで 後続のサーチは実行されません。 オーバーラップとは、同じタイムスタンプを共有している (同じサーチからの) イベントです。イベントのオー バーラップにより、サマリーインデックスから作成されるレポートや統計が歪曲されてしまいます。保存 みサー チの時間範 を、サーチのスケジュール間隔よりも長く設定した場合、または collect コマンドを使って手動でサマ リーインデックスを作成した場合に、オーバーラップが発生する可能性があります。 サマリ ー インデックス設定の例 この例は、Apache サーバー統計情報のサマリーインデックスの、savedsearches.conf への設定例を表していま す。以下に記載されているキーで、保存 みサーチ「Apache Method Summary」のサマリーインデックスが有効に なります。 注意：action_summary.index=1 を設定した場合、サーチ内に addinfo または collect コマンドを使用する必要は ありません。 #name of the saved search = Apache Method Summary [Apache Method Summary] # sets the search to run at each search interval counttype = always # enable the search schedule enableSched = 1 # search interval in cron notation (this means "every 5 minutes") schedule = */5**** # id of user for saved search userid = jsmith # search string for summary index search = index=apache_raw startminutesago=30 endminutesago=25 | extract auto=false | stats count by method # enable summary indexing action.summary_index = 1 #name of summary index to which search results are added action.summary_index._name = summary # add these keys to each event action.summary_index.report = "count by method" サマリ ー インデックスの影響を受けるその他の設定ファイル savedsearches.conf 内の設定の他にも、indexes.conf および alert_actions.conf にサマリーインデックス用の設定 が存在しています。 Indexes.conf には、サマリーインデックスのインデックス設定を指定します。Alert_actions.conf は、保存 みサー チに関連するアラートアクション (サマリーインデックスを含む) を示しています。 警告：Splunk スタッフからの明確な指示がない限り、alert_actions.conf 内の設定を 更しないでください。 132
© Copyright 2024 Paperzz
