ITの窓辺から

三流IT技術者の日常

Splunkのソースタイプとフィールド

今週は仕事が忙しかったのに加えて飲みに行くことが多かったのであまり更新ができませんでした。今回もSplunkです。

Splunkバージョン7.1.1です。
Splunkにはソースタイプという言葉があります。色々なサーバや機器からSplunkにログを送ることになりますが、当然ながらSplunkは全ての機器のログフォーマットを把握していないので、取り込むログがどのようなものなのか教えてやる必要があります。この分類がソースタイプです。

前回の記事でもIAPとFortigateのために新たにソースタイプを定義して割り当てています。ソースタイプの指定はログの入力単位ごとに設定をします。

realizeznsg.hatenablog.com

 前回は2種類UDPポートでSyslogを受け付けるようにSplunkを設定しています。UDP514でソースタイプ「Aruba IAP」、UDP20001で「Fortigate_OS5.2」を指定しました。命名規則がバラバラなのは気にしないでください。

ソースタイプの新規作成

ソースタイプの指定だけであれば大して設定するものはありません。基本的には名前だけ決めれば大丈夫です。他にも設定できる内容はありますが、とりあえずSplunkを使っていくレベルでは不要そうな気がします。

ソースタイプを作成したらデータ入力設定で作成したソースタイプを指定します。

f:id:ReaLiZeZNSG:20180624234253p:plain

しかし、IAPもFortigate(我が家の構成だと)もキャッチーなログが大して取れないんですよね。そこでやっつけでSquidを構成しHTTPプロキシサーバのログを取ることにしました。Squidaccess.logの一部をローカルに移し(実際は移す必要はないようです。リモートホストのログを監視する仕組みがSplunkにあります)、そのテキストファイルをSplunkで監視する構成にします。

データ入力設定で新しくソースタイプを設定します。今回はとりあえずSquid-Test-01という名前のソースタイプを作成します。以下のような設定があります。

f:id:ReaLiZeZNSG:20180630093143p:plain

イベント改行

ログが複数行で構成されるような場合に設定が必要になることがあります。

タイムスタンプ

ログ調査なので時刻は最重要要素です。ログに含まれる時刻部分を認識させるための設定です。とはいえ最近のログであれば概ね自動認識してくれるはずです。よほど時刻表記フォーマットが独特な場合に指定するくらいに思えます。Squidのデフォルトログ表記の1970年1月1日からの累積秒もちゃんと認識してくれました。

詳細

とりあえずデフォルトで良いと思いますが、ログの取り込みに失敗するとか表示がおかしいとかであればCHARSETを疑ってみるのが良さそうです。

ソースタイプの設定が終わったので、Squidのログをインデックス「main」に送ります。

フィールド

ソースタイプを決めた後のフィールド設定がSplunkにログの意味を理解させる部分の本番です。今回はSquidにおけるアクセス先URLと応答のあったHTTPステータスコードを理解させます。これによりSplunkの検索からピンポイントで宛先URLの値を検索することができます。

以下はSquidのログの一部です。

f:id:ReaLiZeZNSG:20180630095911p:plain

左側の「>」をクリックするとフィールド抽出というメニューが表示されるのでこれを選択します。

f:id:ReaLiZeZNSG:20180630100226p:plain

ログが抜き出され、以下のような画面が表示されます。

f:id:ReaLiZeZNSG:20180630100339p:plain

ちょっと分かりづらいですが、今回は区切り文字の方をクリックし、画面右上(画像にはない)の「次へ」をクリックします。

解析対象のログがSquidのHTTPアクセスログなのでログのフォーマットがスペースで区切られ正確に定義されています。

ただし、Squidでは転送バイト数等の桁数が決められているようで、単にスペースで区切ってしまうとログによってSplunkから見たフォーマットに差が出てしまうことに気が付き、Squidのログのログフィールド間のスペースを桁数問わずでカンマ1個に置き換えました。

f:id:ReaLiZeZNSG:20180630101135p:plain

カンマで区切られたログに「fieldx」と名前がつきます。今回はステータスコードに「Squid_HTTP_STCode」、宛先URLに「Squid_HTTP_DstURL」というフィールド名を指定します。これでフィールドの定義が終了です。

尚、フィールドはソースタイプに紐づきます。今回はソースタイプ「Squid-Test-01」のみ使用できるフィールドを作成しました。

検索してみる

例えばこんな検索ができます。

f:id:ReaLiZeZNSG:20180630105737p:plain

今回はHTTPステータスコードもフィールドとしてSplunkに理解させているので連携した調査を簡単に行うことができます。

例えば調査シナリオとして、Bingにアクセスした時にHTTPステータスコード500番台が出ていなかったか調べたい、というような時があった場合、以下のような検索をすることですぐに調べられます。

f:id:ReaLiZeZNSG:20180630110302p:plain

0件なので500番代はなかったようです。

200番代はどうでしょう?

f:id:ReaLiZeZNSG:20180630110446p:plain

Bingへのアクセス件数と一致しているので全て200番代だったことがわかります。さらに以下のようにSquid_HTTP_STCodeの種類数が1と分かるので異なる結果が返ってきているということもないと確定しました。

f:id:ReaLiZeZNSG:20180630110641p:plain

何が嬉しい?

今回はSplunkにログを理解させる方法を調べました。SIerさんのアナタ、こう思いませんでした?「製品のログを普通に終えば良いじゃない。確かに調べるのは早くなるかもしれないけどそんなに差ある?そもそもフィールド名をちゃんとと整理して覚えるか記録しておかないとダメじゃん」って。今回の記事だけでそう考えるのは間違っていません。しかし情シス目線で考えるとこうした調査作業の工数削減は大きな意味があります。もちろん今回の記事だけでは大した工数削減になりません。今後、便利じゃんって思えるような使い方を記事にしていきますので乞うご期待。

情シスがやらないといけないことをどこかで定義してそれに沿って道具の使い方を書いて行くほうがキレイなのですが、道具の使い方を私も勉強している最中なのでそこまでうまくやれません。しばらく泥臭い記事の並びになりそうです。