Upgrade to Pro — share decks privately, control downloads, hide ads and more …

事例で学ぶSplunkの活用方法

 事例で学ぶSplunkの活用方法

[APC勉強会8a1 #42 登壇資料]
長谷川 脩(ハセガワ オサム)

<概要>
高額なツールであるSplunk。
導入してみたい、してみたはいいけれど......
 何を実現すればいいのか分からない!
 チームに普及できない!
 他のツールとの違いが分からない!
など、課題がたくさんでてきますよね。
本セッションでは、登壇者が業務で直面した課題と、それをどのように解決して、どのような活用をしているのかについてお伝えできればと思います。

<動画>
https://youtu.be/LifaDb7L2S0

AP Communications Co., Ltd.

November 27, 2024
Tweet

More Decks by AP Communications Co., Ltd.

Other Decks in Technology

Transcript

  1. 初めに:タイムスケジュール 本日のスケジュールです ※切りの良い所で 5分間の休憩🍵を入れます • 1章: Splunk って何? 簡単に説明 •

    2章: 苦労話 しくじり体験~成功体験 • 休憩予定 • 3章: 成功!活用事例 最終的にどうなった? • 4章: 他との使い分け 使ってみて分かった違い • 5章: 質疑応答 なんでもどうぞ! 3
  2. 初めに: 本登壇でお話する内容 1. 本登壇でお話する(扱う)内容 ・Splunk の概要 ・Splunk の普及までの苦労話 ・Splunk の業務での活用事例

    1. 扱わない内容 ・技術面、インフラ周り ご要望があれば別途開催可能 ・具体的な料金体系など 4
  3. 初めに:講師の自己紹介 長谷川 脩 Hasegawa Osamu 2014年入社。昭和生まれ。 前職の運用・保守を経て、開発に転向。 Web 開発をメインに、Splunk、Elasticsearch、Ansible などやってます。

    ❏ 絵を描くのが好きです この資料の製品アイコン以外のイラストは自作 ❏ 神田カレースタンプラリーのグランドマイスター(149店舗制覇)取りました カレー大好き。でもスイーツも好き ❏ 江戸城と世界遺産が好きです ❏ スイーツ作れます ❏ TRPG やってます ❏ 妻は中国出身&息子が2人います 5
  4. [事前アンケート結果共有] Splunkを使ったことはありますか? みなさん、 Splunk を使ったこと、ありますか? 7 1. 業務で使ったことがある 2. 個人で触ったことはある

    3. 使ったことはない 4. そもそも Splunk ってなに? 今まで弊社の社内登壇で聞いた中では、 2名の方が活用経験がありました
  5. ログ収集、およびその可視化には、 大きく3つのプロセスがあります (1)ログ収集 > (2)ログ蓄積 > (3)ログ可視化 11 散らばったログ を集めて

    データとして 格納し データを集計したり 可視化する ログ蓄積 ホスト ログ収集とはなにか? 3/3
  6. Splunk とはなにか? Splunk 社曰く、総合ログ管理プラットフォーム とのこと つまり、 ログ収集 ~ 可視化 がまとめてできるツール群のこと

    12 (1)ログ収集 > (2)ログ蓄積 > (3)ログ可視化 Universal Forwarder Indexer Search Head それぞれのプロセスにおける機能の名前です
  7. 導入するには? Splunk は 有 償 のツールです 無料トライアル(Splunk Free)は、制限がきついけれど利用可能 導入方法は大きく2つ •

    Splunk Cloud Platform ◦ クラウド上でサービスを利用できる ◦ もちろんインフラは不要 • Splunk Enterprise ◦ オンプレでサービスを利用できる ◦ インフラは必要 13 長谷川(話者)は この方法で使っています
  8. 特徴:データ投入が楽 投入時にデータの整形が不要です ログ収集ツールでの整形が基本不要! 投入後に正規表現でデータを定義します ログ分割の定義やタイムスタンプの定義は必要 14 そのままデータを 入れて フィールド(データの項目)を 正規表現で定義する

    May 25 19:00:00 splk.test xxxx: [httpd] 192.168.56.100 - - [25/May/2022:19:00:00 +0900] "GET /index.php HTTP/1.1" 200 May 25 19:00:00 splk.test xxxx: [httpd] 192.168.56.100 - - [25/May/2022:19:00:00 +0900] "GET /index.php HTTP/1.1" 200 フィールド: method "(?<method>¥w+)¥s フィールド: url "¥w+¥s(?<url>)¥s
  9. 特徴:検索クエリ(SPL) がワンライナー 検索クエリがワンライナーで書けます 見やすく改行してもOK • 検索クエリのことを SPL と呼びます • UNIXコマンドの様にパイプでコマンドを繋ぎます

    書き方は SQL に近いです 15 index=test_idx sourcetype=test | stats count(url) as count by url | sort - count このコマンドでやっていること: index が test_idx、sourcetype が test のデータを検索し、 url 毎の件数をカウントし、 カウント数の降順で並び替える。
  10. 特徴:アラート機能 アラート機能が便利! • SPL による複雑な判定が可能 • Teams やメールにも通知できる ◦ 通知処理をアクションと呼ぶ

    ◦ 夜間やリモートワーク中でも気づきやすい ◦ 閾値をちゃんと決めて、アラートがノイズにならないように注意 16 Workflows Teamsやメール アラート発生! 前は Webhook だ ったけど、 Workflows に 対応した アクションも あるよ MS Teams publish to channel アクションを使用した例
  11. Universal Forwarder 1/2 Splunk に特化したログ収集ツール Universal Forwarder 収集処理は自分で書いても良し、App を使うも良し 収集処理の記述がシンプル!

    • monitor:よくあるファイルの追従監視 • script:自前の Script でデータを出力する • app:用途に応じた収集処理のセット(一部課金制) ◦ 例:Splunk_TA_nix App ディスク・メモリ使用率、load average など、 UNIX サーバの監視に必要な情報をまとめて収集、 フィールド定義までしてくれる App 18
  12. Universal Forwarder 2/2 収集定義は管理ホストで一元管理できる 各ホストへの収集定義ファイルの配布が不要! Universal Forwarder が収集定義を管理ホストから 自動的に取ってくれる 19

    収集定義 ファイル 管理ホスト 各ホストの Universal Forwarder が、 自分の収集定義ファイルを判別し、 取ってくる Splunk Forwarder を入 れたホスト群
  13. マトリクス分析にかけてみた どれか1つ選ぶ 初心に帰って、マトリクス分析 31 見たいログがない 見たいダッシュボードがない クエリ(SPL)が分からない UIの使い方が分からない 手順書にSplunkが書かれていない どれだけ楽になるのか

    実感がわかない Splunk のドキュメントが 英語で読みたくない Splunk のドキュメントがない ダッシュボードの説明が分かりにくい スキル 意欲・ニーズ 利用者 提供側 データが無いと 始まらない! まずはここから
  14. 問題2: どんな情報が見たい? ~ ヒアリング 41 長谷川 見たいダッシュボードがない メールとかExcelに出している情報かな (日次、月次報告書とかで読むから) 手順書で見ている情報ですね

    (サポート部隊は手順化されてたら助かります) 突発作業が多いので 断定するのは難しいですね・・・ マネージャー サポート部隊 運用作業者
  15. 問題2: どんな情報が見たい? ~ 一部はできた 要望が明確だったものはダッシュボード化できた 42 長谷川 見たいダッシュボードがない メールとかExcelに出している情報 手順書で見ている情報

    生成に必要な情報(ログ)と、生成方法が分かればダ ッシュボード化は容易 ・手順自体をダッシュボードにできる場合も ・ドリルダウンなどで一元化し、作業時間も短縮! ・「手順書にSplunkが書かれていない」も解消! マネージャー サポート部隊
  16. チームへの普及 ~ やりやすいものから まずは、普及しやすいものから 47 長谷川 メールとかExcelに出している情報 手順書で見ている情報 ・Splunk の

    URL を書いておき、誘導する ・利用者が Splunk に慣れるまでは併用 ・しばらくしたらメールなどは廃止 ・手順にあるので半強制的に使う ・やっていくうちに慣れる マネージャー サポート部隊
  17. アドホック作業は難しい ~ どうやって普及させた? 49 必要な情報が固定ではないもの アクション1 1. 作業の度に Splunk で再現して周知

    =>ログさえ入れてあれば、再現はすぐできる! 2. 手動よりも Splunk のほうが見やすい、便利だと体験してもらう 3. ついでに使い方も伝える 4. 次回から、利用者が自分で Splunk を使えるようになる =>ここまできたら1つのゴール 長谷川 運用作業者 おお、本当だ! ダッシュボードの作り方 教えてください この作業なら Splunk でこうやると見られますよ
  18. アドホック作業は難しい ~ どうやって普及させた? 50 必要な情報が固定ではないもの アクション2 1. 多発する or 似たようなアラートは、Splunk

    アラートを使ってみる 2. アラートからダッシュボードにリンクすれば、 Splunk で調査フェーズを完結できる 3. アラート~ダッシュボードまでを、1つの運用フローにする =>ここまできたら1つのゴール ダッシュボードで確認 SPLでログを調査 python xxxx アラート発生 対処は別サービスか ツールで
  19. その3.普段と違う振る舞いの検知 ~ いままでは 55 必要な情報が固定でないもの 検知 この本文は黒! (経験則) 職人の勘! 閾値超過で気づく

    お客様の問い合わせ サービスが 使えません n台もあるサーバから 地道に探す これはね あのホストだな 有識者に頼る python xxxx 対処 ここにくるまで 時間がかかる 調査
  20. その3.普段と違う振る舞いの検知 ~ 問題が多かった 56 必要な情報が固定でないもの 検知 この本文は黒! (経験則) 職人の勘! 閾値超過で気づく

    お客様の問い合わせ サービスが 使えません n台もあるサーバから 地道に探す これはね あのホストだな 有識者に頼る python xxxx 対処 ここにくるまで 時間がかかる 調査 属人化 発見が 遅い 対応が 遅い
  21. その3.普段と違う振る舞いの検知 ~ でも今は 57 必要な情報が固定でないもの 普段と違う振る舞いを検知したら、 アラートを Teams に通知 アラートを受信したら、

    リンクから Splunk のダッシュボードを開く 運用者 ・ユーザの利用状況が普段と違う ・急に流量が多くなった ・怪しい文言がある ・MLTK(機械学習)を使う ダッシュボードで調査 python xxxx 別サービス またはツールで 検知 調査 対処 検知
  22. その3.普段と違う振る舞いの検知 ~ でも今は 58 必要な情報が固定でないもの 普段と違う振る舞いを検知したら、 アラートを Teams に通知 アラートを受信したら、

    リンクから Splunk のダッシュボードを開く 運用者 ダッシュボードで調査 python xxxx 別サービス またはツールで 検知 調査 対処 検知が 早い! 個人に 依存しない 調査も 早い! 検知
  23. ちょっと息抜き:アンケート ここからは Splunk と 他のログ管理プラットフォーム Elasticsearch と Prometheus との比較について お話しします

    Splunk 以外のツールをお使いの方、 どちらを使おうか迷われている方の 参考なれれば幸いです 60
  24. まず、Elasticsearch について軽く説明 Elasticsearch(Elastic Stack)には Splunk のように、 収集、蓄積、可視化のツールがあります 63 (1)ログ収集 >

    (2)ログ蓄積 > (3)ログ可視化 散らばったログ を集めて データとして 格納し データを集計したり 可視化する
  25. クエリの違い • Elasticsearch ◦ ★UI 上では、KQL という key value の簡単な検索クエリ

    ◦ ▲高度な処理(詳細検索や登録)には、 JSON で構造化した複雑なクエリと、データ定義が必要。 まず覚えられない(忘れる) • Splunk ◦ ★クエリはUNIXライクなSPL。シンプルで覚えやすい ◦ ★クエリだけで、データの整形や複雑な集計が可能 ◦ ▲検索時に必要なステップ数が多い ▪ クエリは簡単だが、パイプで複数のコマンドをつなぐ必要あり 64
  26. UI の違い • Elasticsearch ◦ ★UI での簡易検索は容易で早い(前述の通り) ◦ ▲ダッシュボードが使いにくい ▪

    UI の操作が直観的ではない ▪ ダッシュボード間の連携ができない (Kibana8.1.1 からは可能) • Splunk ◦ ★クラシックダッシュボードが高機能で使いやすい ▪ ドリルダウンで別のダッシュボードと連携 ▪ コードの編集で柔軟な UI に変更可能 ◦ ▲検索時に必要なステップ数が多い(前述の通り) 65
  27. データ投入、データ整形方法の違い • Elasticsearch ◦ ★Python との親和性が高い(クエリがJSONなので) ◦ ▲事前に、データ型(template)を定義する必要がある ◦ ▲既定のログ収集ツール(Logstash)の

    Plugin が少ない ◦ ▲データ定義の変更があると再投入やリプレースが必要 • Splunk ◦ ★事前のデータ定義、整形は基本不要 ▪ 投入後に正規表現ベースの定義、整形を行う ◦ ★データ定義を変更しても再投入が不要 ▪ 「とりあえずログを入れておこう」 ができる ◦ ▲ログの分割方法は定義が必要で、投入後は直せない ▪ スタックトレースを1行にする、などの定義 66
  28. データ保存の違い • Elasticsearch ◦ ★データの保存期間を柔軟に変更可能 ◦ ★データ格納量はデータの整形次第 ▪ なので、不要なデータを削れば少なくなる ◦

    ▲データの保存領域は自前で用意する ▪ または有償プランで購入する • Splunk ◦ ★データの保存期間を柔軟に変更可能 ◦ ★データの保存領域は Splunk サーバ側で保持 ◦ ▲生のログを保存するので、データ格納量は大きい ◦ ▲データ格納量に応じて課金される ▪ 1日のデータ格納量に応じて課金されます 67
  29. データのエクスポート、通知方法の違い • Elasticsearch ◦ ★CSV形式でダウンロードできる ◦ ★権限の設定が柔軟にできる ▪ UI 自体をエンドユーザに提供することも可能

    (Kibana 7系以降) ◦ ▲PDF、メールや Teams での連携は有償オプション ▪ 無償でも一部使えるが、制限される • Splunk ◦ ★CSV、PDF 形式でダウンロードできる ◦ ★メールや Teams で連携可能 68
  30. 導入の敷居の違い • Elasticsearch ◦ ★基本無償なので、提案・導入しやすい ◦ ★OSSなので、手元で試しやすい • Splunk ◦

    ▲基本有償で高価なので導入し辛い ◦ ▲無料体験版も制約や使用期限があり、手元で試しにくい 69 パッケージ管理ツールや コンテナでも 導入できるよ
  31. Prometheus との違い 同じくログ収集・可視化ツールである Prometheus と Grafana Splunk との違いは なんでしょうか?? 71

    What is the difference between Splunk and Prometheus. Grafana は独立したOSSですが Prometheus との 親和性が高いです
  32. まず、Prometheus について軽く説明 Prometheus はログ蓄積がメインの機能です 収集は Exporter、可視化は Grafana を使うことが多いです 72 (1)ログ収集

    > (2)ログ蓄積 > (3)ログ可視化 散らばったログ を集めて データとして 格納し データを集計したり 可視化する Exporter ・専用の収集ツール
  33. クエリの違い • Prometheus + Grafana ◦ ★PromQL という独自の検索クエリ ▪ ワンライナーなのでシンプル

    ◦ ▲複雑な処理は苦手 ▪ データ自体が数値とラベルなので、 複雑なデータの格納には向かない • Splunk (先ほどと同じ内容) ◦ ★クエリはUNIXライクなSPL。シンプルで覚えやすい ◦ ★クエリだけで、データの整形や複雑な集計が可能 ◦ ▲検索時に必要なステップ数が多い 73 生成AI にクエリを書いてもらう というのもアリですね
  34. UI の違い • Prometheus + Grafana ◦ ★UI での簡易検索は容易で早い ◦

    ▲ダッシュボードには慣れが必要 ▪ Grafana は英語 ▪ 作成には慣れが必要 • Splunk (先ほどと同じ内容) ◦ ★クラシックダッシュボードが高機能で使いやすい ◦ ▲検索時に必要なステップ数が多い(前述の通り) 74
  35. データ投入、データ整形方法の違い • Prometheus + Grafana ◦ ★数値とラベルだけのデータなので定義がシンプル ▪ 時系列データを扱う ◦

    ★データ投入の敷居が低い ▪ Exporter で様々なデータの投入を自動化できる ◦ ▲複雑なデータの格納には向かない(できない) • Splunk (先ほどと同じ内容) ◦ ★事前のデータ定義、整形は基本不要 ◦ ★データ定義を変更しても再投入が不要 ◦ ▲ログの分割方法は定義が必要で、投入後は直せない 75
  36. データ保存の違い • Prometheus + Grafana ◦ ★数値とラベルだけなので、データ格納量は軽量 ◦ ▲データの保存領域は自前で用意する ▪

    データの削除も自前で行う • Splunk (先ほどと同じ内容) ◦ ★データの保存期間を柔軟に変更可能 ◦ ★データの保存領域は Splunk サーバ側で保持 ◦ ▲生のログを保存するので、データ格納量は大きい ◦ ▲データ量に応じて課金される 76
  37. データのエクスポート、通知方法の違い • Prometheus + Grafana ◦ ★CSV形式でダウンロードできる(グラフは画像で) ◦ ★権限の設定が柔軟にできる ◦

    ▲ただし、UI の操作が直観的ではなく難しいので、 慣れた運用者以外が扱うのは不向き • Splunk (先ほどと同じ内容) ◦ ★CSV、PDF 形式でダウンロードできる ◦ ★メールや Teams で連携可能 77
  38. 導入の敷居の違い • Prometheus + Grafana ◦ ★基本無償なので、提案・導入しやすい ◦ ★OSSなので、手元で試しやすい •

    Splunk (先ほどと同じ内容) ◦ ▲基本有償で高価なので導入し辛い ◦ ▲無料体験版も制約や使用期限があり、手元で試しにくい 78
  39. 付録: 検索性能の違い Splunk のデータの保存 83 20241125 20241126 20241127 access_log error_log

    同じところに 保存するよ 厳密には、この中でさらに細かく分かれていま すが、いったんそこは割愛します
  40. 付録: 検索性能の違い Elasticsearch のデータの保存 84 20240901 20241001 20241101 access_log error_log

    ピンポイントでの 検索・集計は早い! 長いスパンでの 検索・集計は遅い
  41. 付録: 検索性能の違い Splunk のデータの保存 85 access_log error_log 検索・集計時に 日付、データの種類を ちゃんと指定すると

    早い 20240901 20241001 20241101 適切にクエリを組めば データを跨いだ 検索・集計も可能
  42. サマリ: Splunk とは? • Splunk は 有償 の総合ログ管理プラットフォーム • 収集は

    Universal Forwarder ◦ 投入時に整形不要 • 蓄積は Indexer • 可視化は Search Head ◦ クエリは SPL と呼ぶ ◦ ダッシュボードとアラートが高機能 88
  43. サマリ: 普及するときの問題点 と 解消方法2 • 問題点: 見たいダッシュボードがない • 解消方法: 見たい情報をヒアリングする

    ◦ メールとかExcelに出している統計情報を自動生成する ◦ 手順書で見ている情報を Splunk に置き換える ◦ 障害作業のたびに Splunk で再現・宣伝し、 利用者自ら Splunk を使えるようにする ◦ アラートに組み込んで作業のトリガーにする 90
  44. サマリ: Elasticsearch との比較 91 比較項目 Splunk Elasticsearch クエリ ★シンプルなクエリで複雑な整形も可能 ▲検索時のステップ数が多い

    ▲JSON形式の複雑なクエリ UI ★ダッシュボードが高機能 ★簡易検索は容易で早い ▲ダッシュボードが微妙 データ投入 ★データ定義不要 ★Python との親和性が高い ▲データ定義が必要 保存 ★Splunkサーバで保存 ▲データ格納量は大きい(課金コスト↑) ▲基本自前のストレージに保存 エクスポート ★CSV、PDFダウンロード可能 ★メールや Teams で通知可能 ★CSVダウンロード可能 ▲PDF、メール、Teams 連携は有償 導入の敷居 ▲有償 ★基本無償(OSS)
  45. サマリ: Prometheus との比較 92 比較項目 Splunk Prometheus + Grafana クエリ

    ★シンプルなクエリで複雑な整形も可能 ▲検索時のステップ数が多い ★シンプルなクエリ ▲複雑な処理は苦手 UI ★ダッシュボードが高機能 ★簡易検索は容易で早い ▲ダッシュボード作成は慣れが必要 データ投入 ★データ定義不要 ★時系列データで定義が容易 ▲複雑なデータの格納には不向き 保存 ★Splunkサーバで保存 ▲データ格納量は大きい(課金コスト↑) ★データ格納量は軽量 ▲基本自前のストレージに保存 エクスポート ★CSV、PDFダウンロード可能 ★メールや Teams で通知可能 ★無償で各種ダウンロードも通知も可能 ▲操作と通知の定義には慣れが必要 導入の敷居 ▲有償 ★基本無償(OSS)