Splunk。本格的にさわっていこうと思い、Splunk CloudのFree trialをはじめてみました。
Splunkとは？の整理
そもそもSplunkはログファイル、システムメトリクス、ネットワークイベント、セキュリティ情報などのデータをリアルタイムで収集、インデックス付け、検索、分析、可視化するツールです。
主にIT運用、セキュリティ、およびビジネスアナリティクスのプラットフォームとして活用されています。
Splunkには大きく分けて２つのデプロイメント方法があり、オンプレミスやクラウド上のインスタンスにソフトウェアをインストールするタイプ（Splunk Enterprise）とSaaSモデル（Splunk Cloud）とがあります。
両者の違いは、デプロイメント方式により管理する責任範囲が異なり、プラットフォームのスケーラビリティとメンテナンスの柔軟性になるかなと思います。
機能面においては、Splunk Enterpriseの方がインフラOSに直接アクセスできる違いがありますが、おおよそ95%の機能がSplunk EnterpriseとSplunk Cloudは重複しているようです（だいたい同じですね）。
参考:
Splunk CloudはSaaS型のサービスとして、インフラ部分をユーザー側で持つことなく利用することができるので、リソースの準備やデプロイの手間、その後の運用メンテナンスの点で利点があります。
Splunkの製品群は、主軸にログ分析基盤であるSplunk EnterpriseとSplunk Cloudがあり、セキュリティやIT運用に特化したプレミアムAppや可観測性を目的としたSplunk APMなどがあります。
Splunk Cloudのプラットフォーム
Splunk Cloudには２種類のプラットフォーム、Free trialとPurchased（契約アカウント）があります。
２つのタイプの違いの詳細はこちらから確認できますが、大きな違いとして、Free trialは15日間の5GBまでのログインジェストができ、Purchasedは契約したデータ量に応じて契約期間利用可能なことです。
トライアルを開始する
https://www.splunk.com/ja_jp/download/splunk-cloud/cloud-trial.html
Splunkの公式ウェブページでSplunk Cloudのトライアルをはじめます。
データを取り込んで検索してみる
トライアル用のSplunk Cloudコンソールにアクセスできるようになるので、コンソールにログインしてみます。
トライアルのプラットフォームとPurchasedライセンスのプラットフォームは別れていて、現時点ではトライアルのデータなどを本番ライセンスに引き継ぎなどはできないようなので、本番稼働前のトライアルとして利用する場合は、少し注意が必要です。
チュートリアルのデータを入れてみる
初回はデータを取り込んだらどうやってデータ検索・分析できるのかを確認してみます。
公式のチュートリアルでサンプルのデータセットを試してみることができるので、やってみます。
Splunk Search Tutorial:
https://docs.splunk.com/Documentation/SplunkCloud/9.1.2308/SearchTutorial/Systemrequirements
チュートリアルを参考にデータをアップロードするところまで行い、検索してみます。
Splunkでは、データ検索はデフォルトでインストールされている「Search & Reporting」というAppを使って行うことが出来るので、クリックします。
アップロードしたファイルは、「tutorialdata.zip:」というファイル名から受け取っているのでNew Searchのところで下記のように検索することができます。
「source」はデータ元となるファイル名や入力元の名前が入っているメタデータになります。
source="tutorialdata.zip:*"
またサーチ文を入力した右側に検索するデータの時間範囲を指定することができます。
それぞれ、時間範囲の定義方法は以下が可能です。
- Presets: 15分前から現在、24時間前から現在、昨日、直近１ヶ月間、などよく使われそうな時間幅をプリセットで用意されています
- Relative: 終了時間を直近で固定して、開始時間を任意で選択することができます
- Date Range: 任意の日付の間を指定します
- Date & Time Range: 任意の日付時間の間を指定します
また、検索した画面下部には、検索結果が表示されます。
画面左側には、検索結果で抽出されたフィールドのリストが表示されます。
「i」列を展開すると、１レコード中のフィールドと値が確認することができますし、その上には生のログデータが表示されています。
それではこのフィールドの一つを使って、検索します。
Codeが「B」のものを検索したい時は、検索文でそのままスペースで区切って指定します。
source="tutorialdata.zip:*" Code=Bそうすると、生データのCodeがBになっている値（フィールドCodeがBの値）のレコードばっかりが表示されます。
ちなみに検索文ではフィールドは大文字小文字を区別して、値は区別しません。
このようなかたちで検索することができました。
検索に使われるフィールドとその抽出の仕組みを深掘ってみる
ただソースを指定して検索してみただけなのですが、たくさんのフィールドが抽出されていることに気づくことができたかと思います。
そこでフィールドと抽出の仕組みに ダイブイントゥ してみます。
Splunkでは２種類のフィールドが存在します。
一つは、host、source、sourcetypeなどのSplunk内で様々な用途で使われ、検索を便利にするためのメタデータです。
これらは、Splunkではデフォルトフィールドと呼ばれ、データを受信する時（インデックスする時）に作成されるフィールドです。
デフォルトフィールドの種類についてはこちらで確認できます。
もう一つは、ログデータのフォーマットに基づきログを分析するためにフィールドとして利用するためのもので、これはカスタムフィールドと呼ばれ、データ検索時に行われます。
特にこれはログデータ分析ツールでもSplunkのユニークな特徴で、「スキーマオンザフライ」と呼ばれています。
取り込み時に定義されたスキーマを使って構造化した上でデータを保存するのではなく、データ検索時にスキーマを動的に適用して検索時のみに構造化を行うため、空中で構造化する=スキーマオンザフライ ということです。
先程の検索例だと、sourceはデフォルトフィールドで、Codeはカスタムフィールドに当たります。
ここで疑問が湧いてきます。。
スキーマオンザフライは分かったけど、これらのフィールドはどうやって抽出されているのだろうか？
Splunkでは、検索時にフィールドディスカバリーというフィールド抽出処理が行われます。
このフィールドディスカバリーでは、まず「key=value」という形がログの中に含まれていると自動的にフィールドとして抽出されます。
ですので [01/Feb/2024:18:24:02] VendorID=5036 Code=B AcctID=6024298300471575 このようなログデータは、自動でフィールドが認識されます。
一方、下記のようなログデータではどうでしょうか。
sourcetypeは「access_combined_wcookie」です。
Apacheのアクセスログデータですが、「key=value」という形はログの中にはありません。ところがログデータはそれぞれ意味のあるものとしてフィールドとして認識されています。
そこで重要になってくるのが、「sourcetype」というデフォルトフィールドになります。
その定義を確認します。
参考:
https://docs.splunk.com/Splexicon:Sourcetype
（翻訳）sourcetype フィールドは、access_combined や cisco_syslog など、イベントの発生元となるデータ入力の形式を指定します。 sourcetype を使用して、検索中にイベントをフィルタリングするか、データ処理コマンドの引数として使用します。ワイルドカードを使用すると、単一の式で複数のソースを指定できます (例:sourcetype=access)。
（原文）The sourcetype field specifies the format of the data input from which the event originates, such as access_combined or cisco_syslog. Use sourcetype to filter events during a search, or as an argument in a data-processing command. You can use wildcards to specify multiple sources with a single expression (Example: sourcetype=access).
上記の通り、データ入力の形式を指定するのに利用され、SettingsのSource typesから確認することができます。
自分でつくることも出来ますが、多くのものがあらかじめ定義されています。
（どんなものが定義されているかはここから確認することもできます。）
Show only popularのチェックを外すと、「access_combined_wcookie」が確認できます。
sourcetypeにどのスキーマを適用させるかを、SettingsのFieldsで定義することができます。
「Field extractions」と「Field transformations」で定義されているので確認します。
最初に「Field extractions」を見ようと思うのでクリックすると下のような画面になります。
Nameのコロン（「:」）の前が対象とするソースタイプの名前になります。（ソースタイプの他にソースやホストに適用することも可能です。）
タイプにはInlineとTransformがあります。
Inlineの場合だと、Extraction/Transformの列に抽出する条件が正規表現で書かれています。
Transformの場合は、Extraction/Transformの列に記載されている名前で「Field transformations」のページ内に別途定義されています。
２つのタイプの違いとして、Transformでは、一つのソースタイプに２つ以上の全く異なる抽出条件を必要とする時などより複雑なルール適用が可能となります。
「access_combined_wcookie」はtransformなので、SettingsのFieldsに戻って、次は「Field transformations」のページに行きます。
「access-extractions」を見つけたので、クリックします。
この正規表現が検索時に調べられ、フィールド化されたことになります。
公式動画（スキーマオンザフライ）
https://www.splunk.com/ja_jp/resources/videos/log-analysis-in-splunk-cloud.html
まとめ
ログ分析において、さまざまなプラットフォームから取り込んだログを関連付けて分析することで、セキュリティやIT運用、ビジネスに活用することができます。
ログ統合プラットフォームは、一元的な管理とシステムを横断した検索を可能とすることが重要で、異なるフォーマットを持つログデータを柔軟に扱う必要があります。
Splunkでは、スキーマオンザフライという検索時に構造化する技術によって、分析の柔軟性を保つユニークな特徴を持っていますが、その仕組みについて少しではありますが知ることができました。
また、この特徴を踏まえた上で、今後Splunkの他の機能も試していきたいと思いました。
7
