Splunkを勉強し始めた時に浮かんでくる疑問

8530 ワード
Splunk Splunk テキストリンク

インフラ寄り。綾波風に。

インデックスって、何？

Splunkに取り込まれたイベントを蓄積するリポジトリである。
イベントの論理的なグルーピングの単位。
実体となるディレクトリは、インデクサとなるSplunkインスタンス内の

$SPLUNK_HOME/var/lib/splunk/\<インデックス名\>

である(デフォルトインストールの場合は、$SPLUNK_HOMEは/opt/splunkになる)

尚、インデックスは以下2種類に大別される。
・イベントインデックス（デフォルトのインデックスタイプ。どんな型のデータでも格納できる）
・メトリクスインデックス（メトリックデータしか格納できない）

バケットって？HOTとかWARMって何？

インデックス内のイベントを、データの鮮度ごとに分割した単位。これも実体はディレクトリ。

バケット種別 ディレクトリ(default) 説明
HOT db/hot_v1_X 取り込まれたデータが最初に格納されるバケット。最大サイズに達する、インデクサが再起動される等のトリガーを機に、HOTバケットはWARMバケットに移行する。
WARM db/db_unixtime_unixtime_... HOTから移行してきたバケット。HOTと異なるのは、ディレクトリ名にバケット内のイベントの期間を示すタイムスタンプが付与されている点と、読み取り専用となっている点。HOTと同様に、特定の条件を満たすとCOLDに移行する。
COLD colddb WARMから移行してきたバケット。上記のバケットと異なり、インデックス全体のデータ量が閾値に達したり、バケットとして最大サイズ/保存期間に達した時は、別バケットに移行することなく削除される(Splunkの世代用語でいうとFrozenに移行する)。
インデックス作成時にFrozenPathという属性を指定しておくと、COLDバケットの削除時にそのパスにデータをアーカイブすることができる（ただし、このデータはサーチ不可）。
THAWED thaweddb FrozenPathにアーカイブしたデータをサーチしたい場合、このバケットにリストアする必要がある。そのためのリストア先バケット。

細かい話になるけど、インデックスディレクトリの中身は以下(Windowsの例)。

HOTバケットとWARMバケットはdbディレクトリ内に同居している（HOT→WARMの移行のみ同じディレクトリ内で行われる）

バケットがデータの鮮度ごとに分かれてると何が嬉しいかというと、バケットの場所はHOT/WARM・COLD・THAWEDで個別に変更できるので、以下のような性能・コストを考慮した設計ができる。

  • HOT/WARMバケットの場所（ホームパス）はローカルのSSDにする（新しいデータは利用頻度も高いので速度重視）
  • COLD・THAWEDの場所は外部大容量ストレージにする（古くて利用頻度も低いからとりあえず安く大量に置けるところに）

例えば、鮮度が高くてサーチされる頻度も高そうなHOT/WARMバケットはローカルのSSDドライブに置いて、鮮度が低くてあんまりサーチされなさそうなCOLD以下バケットは、外部HDD等の低速安価ストレージに置く、みたいなことができる。

インデックスを分ける・・・なぜ？

個人利用とか、データ量が大して多くないのであれば、「とりあえずmain」で問題ない。
だけど、エンタープライズ環境でデータ量や利用ユーザ数が増えてくるといろいろ問題が出てくることもある。そういう時にインデックスを分けていると嬉しい。

問題 解決策
全部mainインデックスに突っ込んでたけど、データ量が増えてくるにつれてサーチに時間がかかるようになっちゃったヨ・・・ データの種類ごとにindexを分けて、SPLで"index="を指定すれば、サーチ処理の対象をそのインデックスだけに絞ることができるヨ
取り込んでるデータの中に、特定の人にしか見せたくないデータがあるヨ・・・ 参照範囲を制御したいデータ用のインデックスと、そこに参照権限を持つロールを作成して、そのロールを対象ユーザだけに紐づければ、データ参照範囲を制御できるヨ
データごとに保存期間をわけたくなったヨ・・・ インデックス毎に別々の保存期間を設定できるので、保存要件単位でインデックスを別にすればいいヨ

Admin/Power/Userって、何が違うの？

Splunkのデフォルトロールと代表的なオペレーションの対応は大まかには以下のような感じ。

権限 データ投入 サーチ レポート作成 ソースタイプ作成 アラート作成
admin 〇 〇 〇 〇 〇
power × 〇 〇 〇 〇
user × 〇(参照可能indexのみ) 〇 × ×

SplunkWebの設定メニューをadmin/power/userそれぞれで比較すると、使えるメニューが違うことがわかる。

使い方としては、
- 検索のみ行わせたいユーザにはuserロールを付与し、適切にインデックスロール設計をした上で公開する。
- データ投入やAdd-Onインストールまではやらせたくないけど、アラート作成やソースタイプ作成、それを他ユーザに共有するような作業をさせたいユーザにはpowerロールを付与する
といった具合。

サーチヘッドとかインデクサって、なに？

Splunk Enterpriseのインスタンスの機能に関連付いた呼称。
サーチもデータのインデキシングも1つのインスタンスで実施できる、ハンズオン等で使う学習用導入構成は「Single-Instance Deployment」と呼ばれ、PoCや開発・学習用途として推奨されている。

一方、本格的な業務利用をする（例えば、取り込むデータ量が増えてきた、利用ユーザが増えてきた、データの可用性要件が出てきた）ようになった場合には、Single-Instance Deploymentには限界があるため、下記図の役割毎にインスタンスを複数構成し、分散構成にすることで様々なエンタープライズ要件を満たすことができるようになる。

役割 説明
サーチヘッド サーチはするけどインデキシングは行わないインスタンス。
サーチ処理リクエストをインデクサに投げ、返されたイベントデータから必要に応じてフィールドの抽出・変換を行い、ユーザへ結果を返す。
クラスタリングする際は最低3台必要。
インデクサ 入力されたデータをイベントとしてインデックスに蓄積するインスタンス。クラスタリングする際は最低2台必要。
分散構成全体の中では"サーチピア"、インデクサクラスタの中では"ピアノード"、というように呼び方がいくつかある。
フォワーダ 主にデータの源泉となるサーバ上で動作し、ログをインデクサや他のフォワーダに転送するインスタンス。乱暴な言い方をすればエージェントみたいなもの。
Universal Forwarder ... データ転送に特化した軽量インスタンス
Heavy Forwarder ... Splunk Enterpriseをフォワーダ専用機として構成したもので、ログのParsingやRouting等、Universal Forwarderに出来ないことができるが、その分高負荷。
ライセンスマスタ インデキシングされたイベント量をもとにSplunkのライセンス使用量を管理するインスタンス。
デプロイヤ ForwarderやサーチヘッドへのApp/Add-On展開や設定の統合管理ができるインスタンス。他の機能を持ったインスタンスに同居させることが可能（ライセンスマスタ兼デプロイヤ、みたいな）。
マスターノード インデクサクラスタを管理するインスタンス。"クラスタマスタ"とか"マネージャノード"とか、呼称が複数ある。クラスタ内のインデクサ（ピアノード）への設定ファイル配信はマスターノードから行う

App/Add-Onって何？

　Splunk社、各ソフトウェアベンダー、開発者などが開発し、Splunk Baseと呼ばれるリポジトリサイト上で公開されている、あらかじめ用意されたSplunkのconfigurationのセット。
Add-OnはTA(Technology Add-On)と表記されるケースもある。

Splunkはそれ単体だけ構築しても当然意味がなく、ログの源泉となるサーバやSaaSサービスがログデータを出力できて、かつそれをSplunkにインデキシングして解析でき、その上で目的の形式で可視化できた時に、初めてビジネス活用のスタートラインに立てる。

こうした目的を考えた時にまず浮かんでくるのは、「Windowsの代表的なログ・メトリクスを取得する入力設定とかソースタイプの設定って、誰かがもう作ってないかな？」とか「Office365のテナントにAPI飛ばして、監査ログとか取れないのかな？それを可視化するダッシュボードとかないかな？」という考えである。
Add-OnやAppには、あらかじめいろんな製品やサービスのログ取得用APIやソースタイプが定義されているので、導入するだけですぐに分析が監視できるという、とても嬉しいもの。

モノ 説明
App 基本的にサーチヘッドにインストールする。
ダッシュボードやレポート等、データのVisualizeに関する機能を中心としたConfigurationのセット。
Add-On(TA) サーチヘッド、インデクサ、ユニバーサルフォワーダの中で必要なコンポーネントにインストールする(どこにインストールする必要があるかは、Add-Onの種類による)。監視対象ログやそのログのログ構造設定が含まれている。

App/Add-Onはものによって構成が異なるので、マニュアルを読んで必要なもの、インストールするべきコンポーネントを理解する必要がある。ほぼ英語のものしかないので、英語が読めないとキツイ。

・Appのみが公開されていて、Appのみインストールすればいいもの
・AppしかSplunk Baseにはないが、解凍すると中にAppとAdd-Onが同梱されていて、それぞれ別の場所にインストールするべきもの
・AppとAdd-OnがSplunk Base上別々になっていて、それぞれダウンロード・インストールしなければならないもの

といったように、お作法はモノによる。

やや調査力が要るけれど、「Windowsイベントログを正しく解析してフィールド抽出できるソースタイプ定義を1から作る」みたいなめんどくさいことをしなくていいので、とても便利。ぜひ活用すべし。