データ入力＝ログの取り込み

今回記事として扱うのはデータ入力という機能で、所謂ログの取り込みです。ログの取り込み方法は様々あるんですが、導入先サーバがログサーバであるため、基本的にはローカルログを取り込みます。

執筆中についでに書いちゃえと思い、フィールド抽出の手順も併せて書きました。正規表現書くのが得意な人は、コレを見るよりも正規表現の書き方を押さえた上で手動で定義したほうが早いかもしれません。

ログの取り込み手順

ダッシュボード画面で「データの追加」を選択します。

「モニター」をクリックします。オプション選択で、「ファイルとディレクトリ」を指定します。「ファイルまたはディレクトリ」にて対象となるディレクトリを指定します。指定を終えたら「次へ」をクリックします。「参照」をクリックすると、このようにファイルを参照指定することが可能になります。ソースタイプの指定を行います。今回は「オペレーティングシステム」⇒「syslog」を指定しました。カスタムソースタイプを作ることも出来るようで、文字コードの変更などが求められる場合はそうした対応が必要になると思います。指定が完了したら「次へ」をクリックします。入力設定の画面が表示されるんですが、ここで「ホストフィールドの値」を変更しました。基本的に転送されたログサーバ直下のデータを参照するため、デフォルト値ではSplunkサーバ自身のFQDNが入ってるんですが、それだと検索時意味が無いので、ホストフィールドは実機のホスト名を指定しています。今回の例では「kaede(SEIL/x86)」を指定しています。「確認」をクリックします。確認画面が出てくるので、「実行」をクリックすると、データ取り込み設定は完了です。作成完了の画面が以下の通りになります。「サーチ開始」をクリックすると、ログの検索が開始されます。検索を開始するとこのように、ログが取り込まれ、どんどんフィールド上に出てくるようになります。こうした操作を必要なログ分繰り返し実施する感じになります。

フィールドの抽出

この時点で、ログは単純なsyslogとして扱っているため、Splunkが認識している「要素」と言うのはほとんどありません。日付とホスト名とログファイル名ぐらいしかなく、コレではログの総量ぐらいしか取れる統計がありません。

そこで、フィールド抽出を行って「そのログの某のパラメータは何の項目であるか」を検出させるのが「フィールドの抽出」です。ここからは難易度がいきなり上がりまして、かなり苦労しました。まだ完全に理解してるわけではないので、取り敢えず取った手順について記載します。あくまで参考までに。

先程のサーチ画面で出力させたログの左端にある「>」をクリックすると、以下のような詳細画面が表示されます。「イベントアクション」から「フィールドの抽出」を選択します。抽出方法を選択します。「正規表現」と「区切り文字」が選択できます。今回対象にしたログ(ネットワーク機器のSyslog)は区切り文字での分割は非常に難しいものがあったので、「正規表現」を選択しました。フィールドの選択画面が表示されます。最初に選択したログが表示されているので、フィールドに指定したいパラメータをドラッグします。すると、「フィールド名の設定」をする画面が表示されるので、そのフィールド名を指定して「Add Extraction」をクリックします。

また、「必須」と言うボタンをクリックすることで、フィルタ検出条件の適用対象を絞ることが可能になります。この場合は、フィールド名の指定は不要になります。

認識されたフィールド及び値はその下にあるプレビュー画面に反映されます。この時、例えば検出されなかったフィールドサンプルがあれば、それをクリックすることでサンプルを追加し、文字列の一致するフィールドを指定し、ログを適合させます。

こうすることで、どうやらSplunkに機械学習をさせるようです。その学習の際にPythonを動かしてるようで、CPU使用率が1コア100%状態になってました。しかし、これがなかなかうまく行かず、よく以下のエラーが出てました。

これが出た場合は、基本的に追加サンプルのフィールドを削除し、別のパラメータを探すしかありませんが、なかなか他のパラメータを適合させようとしてもうまく行かず。加えて、うまくいくときもあればうまくいかなかったりで、その挙動が読めない・・・・と言う状況になりました。

もしかしたら、正規表現は手動で作成したほうが良いのかもしれません・・・ぐぬぬ。でも私正規表現大の苦手で・・・・Orz

設定が完了したら「次へ」をクリックします。

今度は、過剰に検出してないか、それをチェックします。私が今回実施た時は特にそうした部分はなかったため、そのまま「次へ」をクリックしてますが、余計に検出された箇所は各箇所についてる「☓」をクリックすることで、検出対象から外すことが出来るようです。その後、保存をクリックすることで設定が完了します（スクリーンショット撮り損ねた)。これで、ログの検出条件に、この機能を使って定義したフィールドを指定することが出来るようになります。例えば、フィールド検出で「dst_addr」と言うフィールドを定義し、そのカウントを取ることで、そのネットワーク機器の宛先として最も多くパケットのやり取りをしてるのはどのアドレスか？といったことがわかるようになります。

別途ダッシュボードと言う機能があるのですが、コレを使ってこんなグラフを作ってます。

これはHomenoc回線とやり取りしているルーターを対象として、ログ中のIPv6宛先アドレスのカウントを取ったものです。そのトップ10をグラフとして表しています。他のルーターにもこのような形でカウントした値を取ってみた所、結構アクセス傾向がはっきりしていて面白かったです。

サーバが使用したリソース量

取り敢えず今のところ、ライセンス上500MB/日という上限があるのに対して、およそ30%ぐらいの容量が解析対象になっています。ログは1日単位でローテーションしているため、おそらくは大丈夫だと思うんですが・・・・

CPUはフィールド抽出時の負荷が最も重く、1コアフル稼働状態になりました。この時使用していたプロセスはpythonでした。メモリ使用量については、およそ3GB弱使われてる感じで、思ったほど使用量は多くなかったです。今回4vCPU/4GB RAMにしていますが、2vCPU/3GB RAMにダウンサイジングしても良いかもしれないな～とか思ってます。

今後やりたいこと

今後やってみたいこととしては、Webオリジンサーバのログ分析をしてみたいなと思っています。ソースIPはCDNやロードバランサによって実質隠蔽された状態になりますが、ユーザエージェントの情報などから、CDNがどんなタイミングでクロールしてんのかとか、サーバのロードバランシング傾向がある程度見えるようになるんじゃないかなーとか思っています。

とは言え、これやっぱり業務で一度触らないことには理解進まないですね。この分析結果として何が得たいのか、それはやっぱりリアルな業務・運用知識が必要なんだろうなと感じています。技術観点だけからはいるには少し敷居が高いのかなーと言う印象です。

というわけで、当面書籍(流石にわからなくて買いました。)なんかもにらめっこしつつ勉強はしていくんですが、続きものとして書くのはここまで。また気が向いたらなんか書きます。

有償版だと

メール通知機能や監視関係の機能が使えるようになり、当然日次最大ログサイズも大きくなるので、使い方がガラッと変わります。つまりは、単なるログ分析サーバが機械学習機能付きの監視サーバになるわけで、有償版のメリットは相当なもんだろうと思います。

私自身はこういう所特に苦手とするところで、中々理解が進まないんですが、少しでも良いから、理解を深めて話についていけるぐらいにはなりたいなーなんて思ったりしています。