📚 クラシックダッシュボード【覚えるべきSPL集】
実務で即使える！インデックス制御パターン
🎯 クラシック vs スタジオの違い
┌─────────────────────────────────────────┐
│ Classic Dashboard（旧型） │
├─────────────────────────────────────────┤
│ ✅ シンプルなXML設定 │
│ ✅ 動作が軽い │
│ ✅ 古いSplunkバージョンでも使える │
│ ❌ 細かいデザイン制御が難しい │
│ ❌ UI設定が限定的 │
└─────────────────────────────────────────┘
┌─────────────────────────────────────────┐
│ Dashboard Studio（新型） │
├─────────────────────────────────────────┤
│ ✅ UI設定が豊富 │
│ ✅ 細かいデザイン制御 │
│ ✅ ドラッグ&ドロップ │
│ ❌ 重い │
│ ❌ 新しいバージョンのみ │
└─────────────────────────────────────────┘
📋 覚えるべきSPL【5つの基本パターン】
パターン1: インデックスからデータ取得（最重要）
index="インデックス名" sourcetype="ソースタイプ"
| timechart span=30m avg(フィールド名) as データ値
具体例:
index="server_logs" sourcetype="linux:syslog"
| timechart span=30m avg(cpu_usage) as CPU使用率
解説:
-
index="server_logs"→ server_logsインデックスから検索 -
sourcetype="linux:syslog"→ linux:syslogタイプだけ取得 -
timechart span=30m→ 30分間隔で集計 -
avg(cpu_usage)→ cpu_usageフィールドの平均値 -
as CPU使用率→ 結果に「CPU使用率」という名前を付ける
パターン2: 絶対値の基準線（固定値）
index="server_logs" sourcetype="linux:syslog"
| timechart span=30m avg(cpu_usage) as CPU使用率
| eval 警告線=80
| eval 危険線=90
結果:
時刻 CPU使用率 警告線 危険線
10:00 65 80 90
10:30 75 80 90
11:00 85 80 90
11:30 95 80 90
グラフ:
100│ ━━━━━━━━━━━━ 危険線(90)
90│━━━━━━━━━━━━━━━━━━━━━━━━━━ 警告線(80)
│ ╱╲ ╱╲
50│ ╱ ╲ ╱ ╲
└─────────────────────→
パターン3: 動的に色が変わる基準線
index="server_logs" sourcetype="linux:syslog"
| timechart span=30m avg(cpu_usage) as CPU使用率
| eval 通常線=if(CPU使用率<80, 90, null())
| eval 警告線=if(CPU使用率>=80 AND CPU使用率<90, 90, null())
| eval 危険線=if(CPU使用率>=90, 90, null())
結果:
時刻 CPU使用率 通常線 警告線 危険線
10:00 65 90 null null ← 通常
10:30 75 90 null null ← 通常
11:00 85 null 90 null ← 警告
11:30 95 null null 90 ← 危険
パターン4: 複数フィールドの集計
index="server_logs" sourcetype="linux:syslog"
| timechart span=30m
avg(cpu_usage) as CPU使用率
avg(memory_usage) as メモリ使用率
avg(disk_usage) as ディスク使用率
結果:
時刻 CPU使用率 メモリ使用率 ディスク使用率
10:00 65 72 55
10:30 75 78 58
11:00 85 82 60
パターン5: 条件フィルタ＋集計
index="server_logs" sourcetype="linux:syslog" host="server01"
| timechart span=30m avg(cpu_usage) as CPU使用率
| eval 基準線=80
解説:
-
host="server01"→ server01のデータだけ取得 - 特定のサーバーだけを監視したい時に使う
🎓 実務パターン【レベル別】
【初級】基本の基準線（1本）
index="main" sourcetype="access_combined"
| timechart span=1h count as アクセス数
| eval 目標線=1000
用途: アクセス数の目標値を表示
【中級】2色切替の基準線
index="main" sourcetype="access_combined"
| timechart span=1h count as アクセス数
| eval 通常線=if(アクセス数<1000, 1200, null())
| eval 達成線=if(アクセス数>=1000, 1200, null())
用途: 目標達成時に線の色が変わる
【上級】3段階の基準線＋複数メトリクス
index="server_logs" sourcetype="linux:syslog"
| timechart span=30m
avg(cpu_usage) as CPU
avg(memory_usage) as メモリ
| eval 緑基準=if(CPU<70, 100, null())
| eval 黄基準=if(CPU>=70 AND CPU<90, 100, null())
| eval 赤基準=if(CPU>=90, 100, null())
用途: CPUとメモリを同時監視、3段階で色分け
📊 実務でよく使うSPLコマンド【チートシート】
検索コマンド
# 基本検索
index="インデックス名"
# 複数インデックス
index="logs1" OR index="logs2"
# 除外
index="logs" NOT sourcetype="error"
# ワイルドカード
index="server_*" host="web*"
# 時間指定
earliest=-7d latest=now
集計コマンド（timechart）
# 平均値
| timechart span=30m avg(field) as 平均
# 合計
| timechart span=1h sum(field) as 合計
# カウント
| timechart span=1d count as 件数
# 最大値
| timechart span=1h max(field) as 最大
# 最小値
| timechart span=1h min(field) as 最小
# 複数集計
| timechart span=1h
avg(field1) as 平均1
max(field2) as 最大2
count as 件数
計算コマンド（eval）
# 固定値
| eval 基準線=1000
# 計算
| eval 合計=A+B
| eval 差=A-B
| eval 積=A*B
| eval 商=A/B
# 条件分岐
| eval 結果=if(条件, 真, 偽)
# 複数条件
| eval 結果=if(A>10 AND B<20, "OK", "NG")
# null（非表示）
| eval 線=if(条件, 1000, null())
フィルタコマンド（where）
# 数値フィルタ
| where cpu_usage > 80
# 文字列フィルタ
| where status="error"
# 複数条件
| where cpu_usage > 80 AND memory > 90
# 範囲指定
| where cpu_usage >= 70 AND cpu_usage < 90
🎯 実践例【コピペで使える】
例1: CPU監視（3段階）
index="server_logs" sourcetype="linux:syslog"
| timechart span=30m avg(cpu_usage) as CPU使用率
| eval 通常基準=if(CPU使用率<70, 100, null())
| eval 注意基準=if(CPU使用率>=70 AND CPU使用率<90, 100, null())
| eval 警告基準=if(CPU使用率>=90, 100, null())
クラシックダッシュボードXML:
<panel>
<chart>
<search>
<query>
index="server_logs" sourcetype="linux:syslog"
| timechart span=30m avg(cpu_usage) as CPU使用率
| eval 通常基準=if(CPU使用率<70, 100, null())
| eval 注意基準=if(CPU使用率>=70 AND CPU使用率<90, 100, null())
| eval 警告基準=if(CPU使用率>=90, 100, null())
</query>
</search>
<option name="charting.chart">line</option>
<option name="charting.seriesColors">[0x000000,0x00FF00,0xFFFF00,0xFF0000]</option>
</chart>
</panel>
例2: アクセス数監視（目標達成）
index="web_logs" sourcetype="access_combined"
| timechart span=1h count as アクセス数
| eval 目標線=1000
| eval 未達成=if(アクセス数<1000, 1200, null())
| eval 達成=if(アクセス数>=1000, 1200, null())
用途:
- 未達成: 赤い基準線
- 達成: 緑の基準線
- 1000アクセスが目標
例3: エラー率監視
index="app_logs"
| timechart span=10m
count(eval(status="error")) as エラー数
count as 総リクエスト数
| eval エラー率=(エラー数/総リクエスト数)*100
| eval 正常線=if(エラー率<1, 5, null())
| eval 警告線=if(エラー率>=1 AND エラー率<3, 5, null())
| eval 危険線=if(エラー率>=3, 5, null())
解説:
count(eval(status="error"))
-
eval(status="error")→ statusが"error"の時だけカウント - エラー数を計算
| eval エラー率=(エラー数/総リクエスト数)*100
- エラー率を％で計算
例4: ディスク使用率（複数サーバー）
index="server_logs" sourcetype="df"
| timechart span=1h avg(percent_used) as ディスク使用率 by host
| eval 警告線=80
| eval 危険線=90
結果:
時刻 server01 server02 server03 警告線 危険線
10:00 65 72 55 80 90
11:00 70 75 60 80 90
12:00 75 82 65 80 90
グラフ:
100│ ━━━━━━━━ 危険線(90)
90│━━━━━━━━━━━━━━━━━━━━━━━━━━ 警告線(80)
│ ━ server01
│ ━ server02
│ ━ server03
50│
└─────────────────────→
🔧 よく使う組み合わせパターン
パターンA: 時間帯フィルタ
index="logs"
| eval 時刻=tonumber(strftime(_time, "%H"))
| where 時刻>=9 AND 時刻<18
| timechart span=1h count as 営業時間アクセス
| eval 目標=500
解説:
- 9時～18時のデータだけを集計
- 営業時間のみの監視
パターンB: 曜日フィルタ
index="logs"
| eval 曜日=tonumber(strftime(_time, "%w"))
| where 曜日>=1 AND 曜日<=5
| timechart span=1d count as 平日アクセス
| eval 目標=10000
解説:
-
%w= 曜日（0=日曜、6=土曜） - 1～5（月～金）のデータだけ
パターンC: 比率計算
index="logs"
| timechart span=1h
count(eval(status=200)) as 成功
count as 合計
| eval 成功率=(成功/合計)*100
| eval 目標線=95
解説:
- HTTP 200（成功）の比率を計算
- 95%以上が目標
パターンD: 複数条件の組み合わせ
index="logs" (status="error" OR status="warning")
| timechart span=30m count as 異常数 by status
| eval 基準線=10
解説:
- errorとwarningだけを抽出
- statusごとに集計
- 10件以上で警告
📝 クラシックダッシュボード専用テクニック
テクニック1: 色の指定（XML）
<option name="charting.seriesColors">
[0x00FF00,0xFFFF00,0xFF0000]
</option>
色の順番:
- 1番目のフィールド: 緑
0x00FF00 - 2番目のフィールド: 黄
0xFFFF00 - 3番目のフィールド: 赤
0xFF0000
テクニック2: 線のスタイル（XML）
<option name="charting.chart.showDataLabels">none</option>
<option name="charting.legend.placement">bottom</option>
<option name="charting.lineWidth">2</option>
テクニック3: 凡例の非表示（XML）
<option name="charting.legend.mode">seriesCompare</option>
<option name="charting.legend.labels">
["データ値","通常","警告","危険"]
</option>
🎯 現場で使える実践SPL【5選】
実践1: リアルタイムCPU監視
index="server_logs" host="prod-*"
| timechart span=5m avg(cpu_usage) as CPU by host
| eval 警告=80
| eval 危険=95
特徴:
- 本番サーバー（prod-*）を監視
- 5分間隔でリアルタイム
- サーバーごとに表示
実践2: アプリケーションエラー監視
index="app_logs" log_level="ERROR"
| timechart span=10m count as エラー数
| eval 注意線=if(エラー数<10, 20, null())
| eval 警告線=if(エラー数>=10 AND エラー数<50, 20, null())
| eval 緊急線=if(エラー数>=50, 20, null())
特徴:
- エラーログだけを監視
- 3段階のアラート
- 50件以上で緊急
実践3: メモリリーク検知
index="server_logs"
| timechart span=1h avg(memory_used) as メモリ使用量
| eval 通常線=if(メモリ使用量<8000, 10000, null())
| eval 要調査線=if(メモリ使用量>=8000, 10000, null())
特徴:
- メモリ使用量の増加傾向を監視
- 8GB以上で要調査
実践4: レスポンスタイム監視
index="web_logs" sourcetype="access_combined"
| timechart span=10m avg(response_time) as レスポンスタイム
| eval 快適線=if(レスポンスタイム<200, 500, null())
| eval 遅延線=if(レスポンスタイム>=200 AND レスポンスタイム<500, 500, null())
| eval 問題線=if(レスポンスタイム>=500, 500, null())
特徴:
- レスポンスタイム（ms）を監視
- 200ms未満: 快適（緑）
- 200-500ms: 遅延（黄）
- 500ms以上: 問題（赤）
実践5: ディスク容量アラート
index="server_logs" sourcetype="df" mount="/"
| timechart span=1h latest(percent_used) as ディスク使用率 by host
| eval 安全線=if(ディスク使用率<80, 100, null())
| eval 警告線=if(ディスク使用率>=80 AND ディスク使用率<90, 100, null())
| eval 危険線=if(ディスク使用率>=90, 100, null())
特徴:
- ルートパーティション（/）を監視
- 80%以上で警告
- 90%以上で危険
📋 最重要SPL【これだけは覚える】
必須パターン1: 基本構文
index="xxx" sourcetype="yyy"
| timechart span=30m avg(field) as データ値
| eval 基準線=1000
必須パターン2: 条件分岐
| eval 線=if(データ値<閾値, 位置, null())
必須パターン3: 複数条件
| eval 線=if(A>=X AND A<Y, 位置, null())
必須パターン4: 複数フィールド
| timechart span=1h
avg(field1) as データ1
avg(field2) as データ2
必須パターン5: フィルタ＋集計
index="xxx" host="server01"
| where field > 100
| timechart span=30m avg(field) as データ値
🎓 段階的学習パス
STEP 1: 基本の検索（1日目）
index="main"
| timechart span=1h count
STEP 2: フィールド集計（2日目）
index="main"
| timechart span=1h avg(cpu) as CPU使用率
STEP 3: 固定基準線（3日目）
index="main"
| timechart span=1h avg(cpu) as CPU使用率
| eval 基準線=80
STEP 4: 条件付き基準線（4日目）
index="main"
| timechart span=1h avg(cpu) as CPU使用率
| eval 線=if(CPU使用率>=80, 100, null())
STEP 5: 複数条件（5日目）
index="main"
| timechart span=1h avg(cpu) as CPU使用率
| eval 緑線=if(CPU使用率<70, 100, null())
| eval 黄線=if(CPU使用率>=70 AND CPU使用率<90, 100, null())
| eval 赤線=if(CPU使用率>=90, 100, null())
これで実務で使えるSPLは完璧です！🎉
📚 SPL完全分解【1行ずつ超詳しく】
うさぎさんでもわかる！検索の仕組み
🔍 全体像
index="server_logs" sourcetype="linux:syslog"
| timechart span=30m avg(cpu_usage) as CPU使用率
これを料理で例えると:
┌─────────────────────────────────────┐
│ うさうさラーメン店の売上分析 │
└─────────────────────────────────────┘
index="server_logs"
↓
「渋谷店の伝票」から探す
（新宿店や池袋店の伝票は見ない）
sourcetype="linux:syslog"
↓
「ラーメンの注文」だけを見る
（餃子や唐揚げは見ない）
timechart span=30m
↓
「30分ごとに」集計する
（10:00-10:30、10:30-11:00...）
avg(cpu_usage)
↓
「売上金額の平均」を計算
（30分間の平均値）
as CPU使用率
↓
計算結果に「平均売上」という名前を付ける
📖 パート1: index="server_logs"
🎯 indexとは？
Splunkのデータ保管庫
┌─────────────────────────────────────┐
│ Splunk全体 │
│ ┌───────────┐ ┌───────────┐ │
│ │index= │ │index= │ │
│ │web_logs │ │server_logs│ │
│ │ │ │ │ │
│ │・アクセス │ │・CPU │ │
│ │・エラー │ │・メモリ │ │
│ │・セッション│ │・ディスク │ │
│ └───────────┘ └───────────┘ │
│ ┌───────────┐ ┌───────────┐ │
│ │index= │ │index= │ │
│ │app_logs │ │security │ │
│ └───────────┘ └───────────┘ │
└─────────────────────────────────────┘
indexは「本棚」のようなもの:
図書館の例
┌─────────────────────────────────────┐
│ 文学の棚（index="literature"） │
│ ├─ 小説 │
│ ├─ 詩集 │
│ └─ エッセイ │
│ │
│ 技術書の棚（index="tech"） │
│ ├─ プログラミング │
│ ├─ ネットワーク │
│ └─ データベース │
└─────────────────────────────────────┘
「技術書の棚から本を探す」
= index="tech"
📝 index指定の例
# 1つのindexから検索
index="server_logs"
# 複数のindexから検索
index="server_logs" OR index="web_logs"
# ワイルドカード（*）を使う
index="server_*"
# server_logs, server_metrics, server_errors など
# server_で始まる全てのindex
# 除外
index="logs" NOT index="test_logs"
🎯 なぜindex指定が重要？
index指定なし（遅い）
┌─────────────────────────────────────┐
│ 全てのindexを探す │
│ 📚📚📚📚📚📚📚📚📚📚 │
│ 100万件のデータから検索 │
│ ⏱️ 検索時間: 30秒 │
└─────────────────────────────────────┘
index指定あり（速い）
┌─────────────────────────────────────┐
│ 特定のindexだけ探す │
│ 📚 │
│ 1万件のデータから検索 │
│ ⏱️ 検索時間: 3秒 │
└─────────────────────────────────────┘
検索が100倍速くなる！
📖 パート2: sourcetype="linux:syslog"
🎯 sourcetypeとは？
indexの中のデータの「種類」
┌─────────────────────────────────────┐
│ index="server_logs" │
│ ┌─────────────────────────────┐ │
│ │ sourcetype="linux:syslog" │ │
│ │ ・システムログ │ │
│ │ ・起動/停止 │ │
│ │ ・エラーメッセージ │ │
│ └─────────────────────────────┘ │
│ ┌─────────────────────────────┐ │
│ │ sourcetype="apache:access" │ │
│ │ ・アクセスログ │ │
│ │ ・HTTPリクエスト │ │
│ └─────────────────────────────┘ │
│ ┌─────────────────────────────┐ │
│ │ sourcetype="mysql:query" │ │
│ │ ・SQLログ │ │
│ │ ・クエリ実行時間 │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────────┘
レストランで例えると:
レストランの注文伝票（index="orders"）
┌─────────────────────────────────────┐
│ sourcetype="ramen"（ラーメン伝票） │
│ ・味噌ラーメン 800円 │
│ ・醤油ラーメン 750円 │
│ │
│ sourcetype="gyoza"（餃子伝票） │
│ ・焼き餃子 400円 │
│ ・水餃子 450円 │
│ │
│ sourcetype="drink"（ドリンク伝票） │
│ ・ビール 500円 │
│ ・ウーロン茶 200円 │
└─────────────────────────────────────┘
「ラーメンの注文だけ見たい」
= sourcetype="ramen"
📝 sourcetype指定の例
# 特定のsourcetype
sourcetype="linux:syslog"
# 複数のsourcetype
sourcetype="linux:syslog" OR sourcetype="windows:event"
# ワイルドカード
sourcetype="apache:*"
# apache:access, apache:error など
# 除外
sourcetype="*" NOT sourcetype="test:*"
🎯 よく使うsourcetype一覧
| sourcetype | 内容 | 例 |
|---|---|---|
linux:syslog |
Linuxシステムログ | 起動/停止、エラー |
apache:access |
Apacheアクセスログ | HTTPリクエスト |
apache:error |
Apacheエラーログ | サーバーエラー |
mysql:query |
MySQLクエリログ | SQL実行履歴 |
windows:event |
Windowsイベントログ | システムイベント |
syslog |
一般的なsyslog | 汎用ログ |
📖 パート3: timechart span=30m
🎯 timechartとは？
時間軸でデータを集計するコマンド
元のデータ（バラバラ）
┌─────────────────────────────────────┐
│ 時刻 CPU │
│ 10:05 65% │
│ 10:12 70% │
│ 10:23 68% │
│ 10:35 75% │
│ 10:48 72% │
│ 10:55 78% │
└─────────────────────────────────────┘
↓ timechart span=30m で集計
┌─────────────────────────────────────┐
│ 時刻 CPU平均 │
│ 10:00 67.7% ← 10:00-10:30の平均│
│ 10:30 75.0% ← 10:30-11:00の平均│
└─────────────────────────────────────┘
📝 spanの指定方法
# 秒単位
span=30s # 30秒
span=1s # 1秒
# 分単位
span=1m # 1分
span=5m # 5分
span=15m # 15分
span=30m # 30分
# 時間単位
span=1h # 1時間
span=2h # 2時間
span=6h # 6時間
# 日単位
span=1d # 1日
span=7d # 7日
# 週・月単位
span=1w # 1週間
span=1mon # 1ヶ月
🎯 span選択の目安
監視する期間に応じて選ぶ
┌─────────────────────────────────────┐
│ 直近1時間を見る │
│ → span=1m または span=5m │
│ │
│ 直近24時間を見る │
│ → span=30m または span=1h │
│ │
│ 直近7日間を見る │
│ → span=1h または span=6h │
│ │
│ 直近1ヶ月を見る │
│ → span=1d │
│ │
│ 直近1年を見る │
│ → span=1w または span=1mon │
└─────────────────────────────────────┘
🎨 グラフの見え方
span=5m（細かい）
┌─────────────────────────────────────┐
│ ╱╲╱╲╱╲╱╲╱╲ │
│ ╱ ╲ │
│╱ ╲ │
└─────────────────────────────────────┘
詳細だが、長期間を見ると重い
span=1h（標準）
┌─────────────────────────────────────┐
│ ╱╲ ╱╲ │
│ ╱ ╲ ╱ ╲ │
│╱ ╲╱ ╲ │
└─────────────────────────────────────┘
バランスが良い
span=1d（粗い）
┌─────────────────────────────────────┐
│ ╱‾‾╲ │
│ ╱ ╲ │
│╱ ╲ │
└─────────────────────────────────────┘
傾向把握に適している
📖 パート4: avg(cpu_usage)
🎯 avgとは？
平均値を計算する関数
元データ
┌─────────────────────────────────────┐
│ 10:05 cpu_usage=60 │
│ 10:12 cpu_usage=70 │
│ 10:23 cpu_usage=80 │
└─────────────────────────────────────┘
↓ avg(cpu_usage)
平均値 = (60 + 70 + 80) ÷ 3 = 70
📝 よく使う集計関数
# 平均値
avg(field)
例: avg(cpu_usage) → 65.5
# 合計
sum(field)
例: sum(sales) → 15000
# 件数
count
例: count → 120件
# 最大値
max(field)
例: max(temperature) → 35.8
# 最小値
min(field)
例: min(temperature) → 18.2
# 最新値
latest(field)
例: latest(stock) → 50
# 最古値
earliest(field)
例: earliest(stock) → 100
🎯 集計関数の使い分け
┌─────────────────────────────────────┐
│ CPU使用率を監視 │
│ → avg(cpu_usage) │
│ 平均的な負荷を知りたい │
│ │
│ ピーク負荷を知りたい │
│ → max(cpu_usage) │
│ 最大でどこまで上がったか │
│ │
│ アクセス数を集計 │
│ → count │
│ 何回アクセスされたか │
│ │
│ 売上金額を集計 │
│ → sum(amount) │
│ 合計いくら売れたか │
└─────────────────────────────────────┘
🎨 実例
# CPU使用率の平均（推奨）
| timechart span=30m avg(cpu_usage)
# CPU使用率の最大値（ピーク監視）
| timechart span=30m max(cpu_usage)
# アクセス数（回数）
| timechart span=1h count
# エラー数（条件付きカウント）
| timechart span=10m count(eval(status="error"))
# 売上合計
| timechart span=1d sum(sales_amount)
📖 パート5: as CPU使用率
🎯 asとは？
計算結果に「名前」を付ける
名前を付けない場合
┌─────────────────────────────────────┐
│ _time avg(cpu_usage) │
│ 10:00 67.5 │
│ 10:30 72.3 │
└─────────────────────────────────────┘
↑
わかりにくい名前
名前を付けた場合
┌─────────────────────────────────────┐
│ _time CPU使用率 │
│ 10:00 67.5 │
│ 10:30 72.3 │
└─────────────────────────────────────┘
↑
わかりやすい名前！
📝 as の使い方
# 基本形
| timechart span=30m avg(cpu_usage) as CPU使用率
# 複数のフィールドに名前を付ける
| timechart span=30m
avg(cpu_usage) as CPU使用率
avg(memory_usage) as メモリ使用率
avg(disk_usage) as ディスク使用率
# 日本語も使える
| timechart span=1h count as アクセス数
# 英語でもOK
| timechart span=1h count as access_count
🎯 なぜasが必要？
理由1: グラフの凡例がわかりやすくなる
┌─────────────────────────────────────┐
│ グラフのタイトル │
│ ━ avg(cpu_usage) ← わかりにくい │
│ ━ CPU使用率 ← わかりやすい！ │
└─────────────────────────────────────┘
理由2: 後続の処理で使いやすい
| timechart span=30m avg(cpu_usage) as CPU使用率
| eval 警告=if(CPU使用率>80, "警告", "正常")
↑
この名前を使える
理由3: ダッシュボードで表示される
🎯 全体を通して理解
ステップ1: データを絞り込む
index="server_logs" sourcetype="linux:syslog"
イメージ:
全データ（100万件）
┌─────────────────────────────────────┐
│ 🗄️ 全てのindex │
│ └─ 📁 server_logs（選択） │
│ └─ 📄 linux:syslog（選択） │
│ └─ 📄 apache:access │
│ └─ 📄 mysql:query │
└─────────────────────────────────────┘
↓
絞り込み後（1万件）
┌─────────────────────────────────────┐
│ 📄 linux:syslogだけ │
│ 10:05 cpu=65 │
│ 10:12 cpu=70 │
│ 10:23 cpu=68 │
│ ... │
└─────────────────────────────────────┘
ステップ2: 時間で集計
| timechart span=30m
イメージ:
バラバラのデータ
┌─────────────────────────────────────┐
│ 10:05 cpu=65 │
│ 10:12 cpu=70 │
│ 10:23 cpu=68 │
│ 10:35 cpu=75 │
│ 10:48 cpu=72 │
└─────────────────────────────────────┘
↓ 30分ごとにまとめる
┌─────────────────────────────────────┐
│ 10:00-10:30 グループ │
│ 65, 70, 68 │
│ │
│ 10:30-11:00 グループ │
│ 75, 72 │
└─────────────────────────────────────┘
ステップ3: 平均を計算
avg(cpu_usage)
イメージ:
10:00-10:30 グループ
┌─────────────────────────────────────┐
│ 65, 70, 68 │
│ 平均 = (65+70+68)÷3 = 67.7 │
└─────────────────────────────────────┘
10:30-11:00 グループ
┌─────────────────────────────────────┐
│ 75, 72 │
│ 平均 = (75+72)÷2 = 73.5 │
└─────────────────────────────────────┘
ステップ4: 名前を付ける
as CPU使用率
イメージ:
最終結果
┌─────────────────────────────────────┐
│ 時刻 CPU使用率 │
│ 10:00 67.7 │
│ 10:30 73.5 │
└─────────────────────────────────────┘
↑
わかりやすい名前で表示
🎓 実践練習
練習1: 基本の検索
index="server_logs" sourcetype="linux:syslog"
| timechart span=1h avg(cpu_usage) as CPU使用率
何が起きる？
- server_logsインデックスから
- linux:syslogタイプのデータを取得
- 1時間ごとに
- cpu_usageの平均値を計算
- 「CPU使用率」という名前で表示
練習2: 複数フィールド
index="server_logs" sourcetype="linux:syslog"
| timechart span=30m
avg(cpu_usage) as CPU使用率
avg(memory_usage) as メモリ使用率
結果:
┌───────────────────────────────────┐
│ 時刻 CPU使用率 メモリ使用率 │
│ 10:00 67.7 72.3 │
│ 10:30 73.5 78.1 │
└───────────────────────────────────┘
練習3: 異なる集計
index="web_logs" sourcetype="access_combined"
| timechart span=10m
count as アクセス数
avg(response_time) as 平均応答時間
結果:
┌─────────────────────────────────────┐
│ 時刻 アクセス数 平均応答時間 │
│ 10:00 1250 185ms │
│ 10:10 1380 192ms │
└─────────────────────────────────────┘
📋 まとめ【5つの要素】
┌─────────────────────────────────────┐
│ 1️⃣ index="server_logs" │
│ どの本棚から探すか │
│ │
│ 2️⃣ sourcetype="linux:syslog" │
│ どの種類のデータか │
│ │
│ 3️⃣ timechart span=30m │
│ 何分ごとに集計するか │
│ │
│ 4️⃣ avg(cpu_usage) │
│ どう計算するか（平均） │
│ │
│ 5️⃣ as CPU使用率 │
│ 結果に何という名前を付けるか │
└─────────────────────────────────────┘
🎯 即使えるテンプレート
index="あなたのindex" sourcetype="あなたのsourcetype"
| timechart span=30m avg(あなたのフィールド) as わかりやすい名前
実例:
# CPU監視
index="server_logs" sourcetype="linux:syslog"
| timechart span=30m avg(cpu_usage) as CPU使用率
# アクセス数監視
index="web_logs" sourcetype="access_combined"
| timechart span=1h count as アクセス数
# エラー監視
index="app_logs" sourcetype="application"
| timechart span=10m count(eval(level="ERROR")) as エラー数
# メモリ監視
index="server_logs" sourcetype="vmstat"
| timechart span=1h avg(memory_used) as メモリ使用量
🎓 原理原則【sourcetypeとasの本質】
なぜ必要？どう使う？完全理解
📌 原理原則とは？
表面的な理解:
「こう書けば動く」「こうすればいい」
原理原則の理解:
「なぜそうなのか」「どういう仕組みか」
「応用できる本質的な理解」
🎯 パート1: sourcetypeの原理原則
原則1: データには「形」がある
現実世界の例
┌─────────────────────────────────────┐
│ 同じ「文書」でも種類がある │
│ │
│ 📄 契約書 │
│ ・署名欄がある │
│ ・印鑑欄がある │
│ ・条項が並んでいる │
│ │
│ 📄 請求書 │
│ ・金額欄がある │
│ ・品目が並んでいる │
│ ・合計欄がある │
│ │
│ 📄 日記 │
│ ・日付がある │
│ ・本文が自由形式 │
└─────────────────────────────────────┘
「契約書を読む方法」と「請求書を読む方法」は違う
→ それぞれの「形」に合わせて読む必要がある
Splunkでも同じ
Splunkのログデータ
┌─────────────────────────────────────┐
│ sourcetype="linux:syslog" │
│ Jan 22 10:15:30 server01 kernel: CPU usage 75%
│ ↑ ↑ ↑ ↑ ↑
│ 月日 時刻 ホスト名 プログラム メッセージ
│ │
│ sourcetype="apache:access" │
│ 192.168.1.1 - - [22/Jan/2026:10:15:30] "GET /index.html" 200
│ ↑ ↑ ↑ ↑
│ IPアドレス 日時 リクエスト ステータス
└─────────────────────────────────────┘
「形」が違う → 読み方も違う
原則2: Splunkはsourcetypeで「読み方」を決める
うさうさラーメン店の伝票
🎫 ラーメン伝票（sourcetype="ramen"）
┌─────────────────────────────────────┐
│ 注文番号: 001 │
│ 品名: 味噌ラーメン │
│ 価格: 800円 │
│ トッピング: チャーシュー │
└─────────────────────────────────────┘
読み方のルール:
・1行目は注文番号
・2行目は品名
・3行目は価格
・4行目以降はトッピング
🎫 餃子伝票（sourcetype="gyoza"）
┌─────────────────────────────────────┐
│ G-001 焼き餃子 5個 400円 │
└─────────────────────────────────────┘
読み方のルール:
・全て1行
・スペース区切り
・G-で始まるのが注文番号
→ 伝票の種類によって読み方が違う！
Splunkの実例
sourcetype="linux:syslog"
Splunkが内部でやっていること:
ステップ1: sourcetypeを見る
「これはlinux:syslogだな」
ステップ2: 読み方のルールを適用
「linux:syslogは...
・最初が月日
・次が時刻
・その次がホスト名
・キーワード: で区切られる」
ステップ3: フィールドを抽出
Jan 22 10:15:30 server01 kernel: CPU usage 75%
↓
month=Jan
day=22
time=10:15:30
host=server01
program=kernel
message=CPU usage 75%
ステップ4: 検索可能にする
host="server01" が検索できる
program="kernel" が検索できる
原則3: なぜsourcetypeが必要か？
理由1: 正しく読むため
┌─────────────────────────────────────┐
│ sourcetype指定なし │
│ 「これは何の形式？わからない」 │
│ → フィールド抽出できない │
│ → 検索できない │
│ │
│ sourcetype指定あり │
│ 「これはlinux:syslogだ！」 │
│ → 正しいルールで読める │
│ → フィールド抽出できる │
│ → 検索できる！ │
└─────────────────────────────────────┘
理由2: 速く検索するため
┌─────────────────────────────────────┐
│ 全データから探す │
│ 📄📄📄📄📄📄📄📄📄📄 │
│ 100万行全部見る │
│ ⏱️ 遅い │
│ │
│ sourcetypeを指定して探す │
│ 📄📄 │
│ 10万行だけ見る │
│ ⏱️ 速い！ │
└─────────────────────────────────────┘
理由3: 正確に分析するため
┌─────────────────────────────────────┐
│ 混ざったデータ │
│ ・サーバーログ │
│ ・アクセスログ │
│ ・エラーログ │
│ → 平均を取っても意味不明 │
│ │
│ 純粋なデータ │
│ ・サーバーログだけ │
│ → 正しい平均が出る │
└─────────────────────────────────────┘
原則4: sourcetypeの命名ルール
一般的なパターン: システム名:ログ種類
例:
linux:syslog → Linuxのシステムログ
apache:access → Apacheのアクセスログ
apache:error → Apacheのエラーログ
mysql:query → MySQLのクエリログ
windows:event → Windowsのイベントログ
カスタム:
myapp:api → 自作アプリのAPIログ
myapp:db → 自作アプリのDBログ
命名の本質:
sourcetype名は「データの形式」を表す
┌─────────────────────────────────────┐
│ 良い命名 │
│ sourcetype="web:access" │
│ → 見ただけで「Webのアクセスログ」 │
│ だとわかる │
│ │
│ 悪い命名 │
│ sourcetype="data1" │
│ → 何のデータかわからない │
└─────────────────────────────────────┘
原則5: sourcetypeの応用
# パターン1: 複数のsourcetypeを同時に検索
sourcetype="apache:access" OR sourcetype="nginx:access"
意味: ApacheとNginxのアクセスログ両方見る
# パターン2: ワイルドカード
sourcetype="apache:*"
意味: apacheで始まる全てのsourcetype
（apache:access, apache:error など）
# パターン3: 除外
sourcetype="*" NOT sourcetype="test:*"
意味: testで始まるもの以外全て
# パターン4: 特定の条件と組み合わせ
sourcetype="linux:syslog" error
意味: linux:syslogの中で"error"という文字を含むもの
🎯 パート2: asの原理原則
原則1: コンピューターは「名前」で物を管理する
人間の世界
┌─────────────────────────────────────┐
│ 「あの人」で通じる │
│ 「これ」「それ」で通じる │
│ → 文脈で判断できる │
└─────────────────────────────────────┘
コンピューターの世界
┌─────────────────────────────────────┐
│ 「あの人」は誰？わからない │
│ 「これ」は何？わからない │
│ → 明確な「名前」が必要 │
└─────────────────────────────────────┘
うさうさラーメン店で例える
人間の注文（曖昧でもOK）
┌─────────────────────────────────────┐
│ 店員「ご注文は？」 │
│ 客「いつもの」 │
│ 店員「味噌ラーメンですね」 │
│ → 人間は文脈で理解できる │
└─────────────────────────────────────┘
コンピューターの注文（明確な名前が必要）
┌─────────────────────────────────────┐
│ システム「商品コードは？」 │
│ 入力「いつもの」 │
│ システム「エラー: 不明な商品」 │
│ │
│ 入力「R001」 │
│ システム「味噌ラーメンですね」 │
│ → コンピューターは正確な名前が必要 │
└─────────────────────────────────────┘
原則2: 計算結果にも名前が必要
Excelで考える
┌─────────────────────────────────────┐
│ A列 B列 │
│ 1 100 200 │
│ 2 150 250 │
│ 3 =A1+B1 ← この計算結果は？ │
└─────────────────────────────────────┘
人間:「A1とB1を足した値」とわかる
コンピューター:「C1セルの値」としか認識できない
名前を付ける:
C1に「合計」という名前を付ける
→ 「合計を参照する」と明確になる
Splunkでの実例
# 名前なし（わかりにくい）
| timechart span=30m avg(cpu_usage)
結果:
┌─────────────────────────────────────┐
│ _time avg(cpu_usage) │
│ 10:00 67.5 │
└─────────────────────────────────────┘
↑
何の数値？関数名だけでは不明
# 名前あり（わかりやすい）
| timechart span=30m avg(cpu_usage) as CPU使用率
結果:
┌─────────────────────────────────────┐
│ _time CPU使用率 │
│ 10:00 67.5 │
└─────────────────────────────────────┘
↑
CPU使用率だと一目でわかる！
原則3: なぜasが必要か？
理由1: グラフで見やすくするため
┌─────────────────────────────────────┐
│ 凡例: │
│ ━ avg(cpu_usage) ← 技術的で難しい │
│ ━ CPU使用率 ← 誰でもわかる │
└─────────────────────────────────────┘
理由2: 後続の処理で使いやすくするため
| timechart span=30m avg(cpu_usage) as CPU使用率
| eval 警告=if(CPU使用率>80, "高い", "正常")
↑
この名前を使って条件判定
理由3: 複数の計算結果を区別するため
| timechart span=30m
avg(cpu_usage) as CPU平均
max(cpu_usage) as CPU最大
↑ ↑
異なる名前で区別
原則4: 名前の付け方のルール
良い名前の条件
┌─────────────────────────────────────┐
│ ✅ 内容が一目でわかる │
│ CPU使用率、メモリ使用量 │
│ │
│ ✅ 短すぎず長すぎない │
│ CPU使用率 ○ │
│ CPU ✗（短すぎ） │
│ サーバーのCPU使用率の平均値 ✗ │
│ （長すぎ） │
│ │
│ ✅ 日本語でも英語でもOK │
│ CPU使用率 ○ │
│ cpu_usage ○ │
└─────────────────────────────────────┘
悪い名前の例
┌─────────────────────────────────────┐
│ ❌ 曖昧な名前 │
│ data1, value, 数値 │
│ → 何のデータ？ │
│ │
│ ❌ 記号だけ │
│ a, b, c │
│ → 意味不明 │
│ │
│ ❌ 長すぎる │
│ サーバー01の過去30分間の... │
│ → 見づらい │
└─────────────────────────────────────┘
原則5: asの応用パターン
# パターン1: 複数の計算結果に名前
| timechart span=30m
avg(cpu_usage) as CPU平均
max(cpu_usage) as CPUピーク
min(cpu_usage) as CPU最小
# パターン2: 計算式に名前
| eval 合計金額=ラーメン代+餃子代+ドリンク代
| eval 値引き後=合計金額*0.9 as 支払額
# パターン3: 条件判定に名前
| eval 判定=if(点数>=60, "合格", "不合格") as 結果
🎓 原理原則の統合理解
sourcetypeとasの関係
データの流れ
┌─────────────────────────────────────┐
│ ステップ1: データを取得 │
│ index="server_logs" │
│ sourcetype="linux:syslog" │
│ ↓ │
│ 「正しい形式のデータ」が得られる │
│ │
│ ステップ2: 集計・計算 │
│ | timechart span=30m avg(cpu) │
│ ↓ │
│ 「計算結果」ができる │
│ │
│ ステップ3: 名前を付ける │
│ as CPU使用率 │
│ ↓ │
│ 「わかりやすい結果」になる │
└─────────────────────────────────────┘
料理で例える完全版
うさうさラーメン店の売上分析
┌─────────────────────────────────────┐
│ ステップ1: 材料を選ぶ（sourcetype）│
│ 「ラーメン伝票だけ持ってきて」 │
│ sourcetype="ramen" │
│ ↓ │
│ 🎫🎫🎫 ラーメン伝票だけ集まる │
│ │
│ ステップ2: 調理する（timechart） │
│ 「30分ごとに平均価格を計算して」 │
│ | timechart span=30m avg(price) │
│ ↓ │
│ 10:00 → 785円 │
│ 10:30 → 820円 │
│ │
│ ステップ3: 盛り付ける（as） │
│ 「お皿に『平均単価』って書いて」 │
│ as 平均単価 │
│ ↓ │
│ 🍜「平均単価」 │
│ 10:00 → 785円 │
│ 10:30 → 820円 │
└─────────────────────────────────────┘
📊 実践で理解を深める
練習1: sourcetypeの重要性を体感
# ❌ 間違い: sourcetype指定なし
index="server_logs"
| timechart span=30m avg(cpu_usage)
問題点:
・複数のsourcetypeが混ざる
・データの形式がバラバラ
・正しい平均が出ない
# ✅ 正しい: sourcetype指定あり
index="server_logs" sourcetype="linux:syslog"
| timechart span=30m avg(cpu_usage)
メリット:
・純粋なlinux:syslogだけ
・データの形式が統一
・正しい平均が出る
練習2: asの重要性を体感
# ❌ 名前なし
| timechart span=30m avg(cpu_usage)
結果のグラフ:
凡例: avg(cpu_usage)
→ 技術者以外には不明
# ✅ 名前あり
| timechart span=30m avg(cpu_usage) as CPU使用率
結果のグラフ:
凡例: CPU使用率
→ 誰でも理解できる
練習3: 組み合わせて理解
index="server_logs" sourcetype="linux:syslog"
| timechart span=30m avg(cpu_usage) as CPU使用率
| eval 状態=if(CPU使用率>=80, "高負荷", "正常")
データの流れ:
ステップ1: sourcetypeで絞り込み
┌─────────────────────────────────────┐
│ 全データ（100種類） │
│ ↓ sourcetype="linux:syslog" │
│ linux:syslogだけ（1種類） │
└─────────────────────────────────────┘
ステップ2: 集計
┌─────────────────────────────────────┐
│ 10:00のデータ: 65,70,68 │
│ ↓ avg() │
│ 10:00の平均: 67.7 │
└─────────────────────────────────────┘
ステップ3: 名前を付ける
┌─────────────────────────────────────┐
│ 67.7 │
│ ↓ as CPU使用率 │
│ CPU使用率: 67.7 │
└─────────────────────────────────────┘
ステップ4: 判定（名前を使う）
┌─────────────────────────────────────┐
│ CPU使用率: 67.7 │
│ ↓ if(CPU使用率>=80, ...) │
│ 状態: 正常 │
└─────────────────────────────────────┘
🎯 原理原則まとめ
sourcetypeの原理原則
┌─────────────────────────────────────┐
│ 本質: データの「形式」を表す │
│ │
│ なぜ必要？ │
│ 1. データを正しく読むため │
│ 2. 検索を速くするため │
│ 3. 分析を正確にするため │
│ │
│ どう使う？ │
│ ・データの種類ごとに指定 │
│ ・システム名:ログ種類の形式 │
│ ・ワイルドカードも使える │
└─────────────────────────────────────┘
asの原理原則
┌─────────────────────────────────────┐
│ 本質: 計算結果に「名前」を付ける │
│ │
│ なぜ必要？ │
│ 1. 人間が理解しやすくするため │
│ 2. 後続処理で使いやすくするため │
│ 3. 複数の結果を区別するため │
│ │
│ どう使う？ │
│ ・わかりやすい名前を付ける │
│ ・日本語でも英語でもOK │
│ ・短すぎず長すぎない │
└─────────────────────────────────────┘
💡 応用: 原理原則から考える
質問1: なぜこう書くの？
index="logs" sourcetype="access"
原理原則で考える:
index → どの本棚から探すか（範囲を絞る）
sourcetype → どの形式のデータか（正しく読む）
両方指定することで:
・範囲が絞られる → 速い
・形式が明確 → 正確
質問2: なぜasが後ろ？
| timechart span=30m avg(cpu_usage) as CPU使用率
↑
後ろに書く
原理原則で考える:
処理の順番:
1. timechart span=30m → 30分ごとに区切る
2. avg(cpu_usage) → 平均を計算する
3. as CPU使用率 → 計算結果に名前を付ける
「計算してから名前を付ける」
だから後ろに書く
質問3: 複数のsourcetypeをまとめて扱いたい
sourcetype="apache:access" OR sourcetype="nginx:access"
| timechart span=1h count as Webアクセス数
原理原則で考える:
目的: Webサーバーのアクセスログをまとめたい
手段:
・ApacheもNginxも「Webアクセスログ」という点で同じ
・ORで複数指定できる
・まとめて集計できる
結果:
・Apache + Nginx の合計アクセス数
📊 図解【index と sourcetype の完全理解】
視覚で理解！データの構造
🏢 全体像【Splunkのデータ構造】
Splunk全体
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌────────────┐ │
│ │ index= │ │ index= │ │ index= │ │
│ │ "web_logs" │ │ "server_logs" │ │ "app_logs"│ │
│ │ │ │ │ │ │ │
│ │ 📚 Webログ倉庫 │ │ 📚 サーバー倉庫│ │ 📚 アプリ倉庫│ │
│ └─────────────────┘ └─────────────────┘ └────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
index = データの「倉庫」
1つの倉庫に複数の種類のデータが入っている
📚 index の中身【1つの倉庫を詳しく見る】
index="server_logs" の中身
┌─────────────────────────────────────────────────────────────┐
│ 📚 server_logs 倉庫 │
│ │
│ ┌─────────────────────┐ │
│ │ sourcetype= │ ← 棚1 │
│ │ "linux:syslog" │ │
│ │ │ │
│ │ 📦 システムログ箱 │ │
│ │ ・起動ログ │ │
│ │ ・エラーログ │ │
│ │ ・CPUログ │ │
│ └─────────────────────┘ │
│ │
│ ┌─────────────────────┐ │
│ │ sourcetype= │ ← 棚2 │
│ │ "vmstat" │ │
│ │ │ │
│ │ 📦 メモリログ箱 │ │
│ │ ・メモリ使用量 │ │
│ │ ・スワップ │ │
│ └─────────────────────┘ │
│ │
│ ┌─────────────────────┐ │
│ │ sourcetype= │ ← 棚3 │
│ │ "df" │ │
│ │ │ │
│ │ 📦 ディスクログ箱 │ │
│ │ ・使用率 │ │
│ │ ・空き容量 │ │
│ └─────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
sourcetype = 倉庫の中の「棚」「箱」
同じ種類のデータをまとめて保管
🎯 図解1: 図書館で例える
┌─────────────────────────────────────────────────────────────┐
│ 🏛️ Splunk図書館 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 📚 本棚A（index="tech_books"） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 📖 プログラミング本（sourcetype="programming"） │ │
│ │ ・Python入門 │ │
│ │ ・Java実践 │ │
│ │ ・Go言語 │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ 📖 ネットワーク本（sourcetype="network"） │ │
│ │ ・TCP/IP詳説 │ │
│ │ ・ルーティング │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ 📖 データベース本（sourcetype="database"） │ │
│ │ ・SQL入門 │ │
│ │ ・NoSQL実践 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 📚 本棚B（index="literature"） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 📖 小説（sourcetype="novel"） │ │
│ │ 📖 詩集（sourcetype="poem"） │ │
│ │ 📖 エッセイ（sourcetype="essay"） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
検索方法:
index="tech_books"
→ 本棚Aに行く
sourcetype="programming"
→ 本棚Aのプログラミング本の棚を見る
🍜 図解2: うさうさラーメン店で例える
┌─────────────────────────────────────────────────────────────┐
│ 🐰 うさうさラーメン店 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 📋 渋谷店の伝票ファイル（index="shibuya"） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 🎫 ラーメン伝票（sourcetype="ramen"） │ │
│ │ ・味噌ラーメン 800円 │ │
│ │ ・醤油ラーメン 750円 │ │
│ │ ・塩ラーメン 750円 │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ 🎫 餃子伝票（sourcetype="gyoza"） │ │
│ │ ・焼き餃子 400円 │ │
│ │ ・水餃子 450円 │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ 🎫 ドリンク伝票（sourcetype="drink"） │ │
│ │ ・生ビール 500円 │ │
│ │ ・ウーロン茶 200円 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 📋 新宿店の伝票ファイル（index="shinjuku"） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 🎫 ラーメン伝票（sourcetype="ramen"） │ │
│ │ 🎫 餃子伝票（sourcetype="gyoza"） │ │
│ │ 🎫 ドリンク伝票（sourcetype="drink"） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
分析例:
index="shibuya" sourcetype="ramen"
→ 渋谷店のラーメン売上だけを分析
index="shibuya" OR index="shinjuku" sourcetype="ramen"
→ 両店のラーメン売上を分析
🎯 図解3: データの階層構造【詳細版】
レベル1: Splunk全体
┌─────────────────────────────────────────────────────────────┐
│ 🗄️ Splunk（全データベース） │
│ データ総量: 1TB │
└─────────────────────────────────────────────────────────────┘
↓
レベル2: index（データの大分類）
┌───────────────┬───────────────┬───────────────┬───────────┐
│ 📚 index= │ 📚 index= │ 📚 index= │ 📚 index= │
│ "web_logs" │ "server_logs" │ "app_logs" │ "security"│
│ 100GB │ 300GB │ 200GB │ 400GB │
└───────────────┴───────────────┴───────────────┴───────────┘
↓
レベル3: sourcetype（データの中分類）
┌─────────────────────────────────────────────────────────────┐
│ index="server_logs" の中身 │
├─────────────────┬─────────────────┬─────────────────────────┤
│ 📦 sourcetype= │ 📦 sourcetype= │ 📦 sourcetype= │
│ "linux:syslog" │ "vmstat" │ "df" │
│ 150GB │ 100GB │ 50GB │
└─────────────────┴─────────────────┴─────────────────────────┘
↓
レベル4: 実際のログ（個別データ）
┌─────────────────────────────────────────────────────────────┐
│ sourcetype="linux:syslog" の中身 │
├─────────────────────────────────────────────────────────────┤
│ 📄 Jan 22 10:00:00 server01 kernel: CPU usage 65% │
│ 📄 Jan 22 10:00:05 server01 kernel: CPU usage 70% │
│ 📄 Jan 22 10:00:10 server02 kernel: CPU usage 55% │
│ 📄 Jan 22 10:00:15 server01 kernel: Memory usage 75% │
│ 📄 Jan 22 10:00:20 server03 kernel: CPU usage 80% │
│ ...（数百万行） │
└─────────────────────────────────────────────────────────────┘
🔍 図解4: 検索の絞り込み過程
ステップ1: index指定なし（全体から検索）
┌─────────────────────────────────────────────────────────────┐
│ 🔍 検索対象: Splunk全体（1TB） │
│ │
│ 📚 web_logs 📚 server_logs 📚 app_logs │
│ 📚 security 📚 database 📚 network │
│ 📚 firewall 📚 email 📚 ... │
│ │
│ ⏱️ 検索時間: 60秒 │
│ 💾 メモリ使用: 大 │
└─────────────────────────────────────────────────────────────┘
ステップ2: index指定（index="server_logs"）
┌─────────────────────────────────────────────────────────────┐
│ 🔍 検索対象: server_logs だけ（300GB） │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 📚 server_logs │ │
│ │ ・linux:syslog │ │
│ │ ・vmstat │ │
│ │ ・df │ │
│ │ ・iostat │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ⏱️ 検索時間: 20秒 │
│ 💾 メモリ使用: 中 │
└─────────────────────────────────────────────────────────────┘
ステップ3: sourcetype指定（sourcetype="linux:syslog"）
┌─────────────────────────────────────────────────────────────┐
│ 🔍 検索対象: linux:syslog だけ（150GB） │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 📦 sourcetype="linux:syslog" │ │
│ │ 📄 Jan 22 10:00:00 server01 kernel: CPU 65% │ │
│ │ 📄 Jan 22 10:00:05 server01 kernel: CPU 70% │ │
│ │ 📄 Jan 22 10:00:10 server02 kernel: CPU 55% │ │
│ │ ... │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ⏱️ 検索時間: 5秒 │
│ 💾 メモリ使用: 小 │
└─────────────────────────────────────────────────────────────┘
結果: 12倍速い！
🎯 図解5: 実際のログファイルとの対応
サーバーの実際のファイル
┌─────────────────────────────────────────────────────────────┐
│ サーバー: server01 │
│ │
│ /var/log/ │
│ ├── syslog ← これが sourcetype="linux:syslog" │
│ ├── apache2/ │
│ │ ├── access.log ← これが sourcetype="apache:access" │
│ │ └── error.log ← これが sourcetype="apache:error" │
│ ├── mysql/ │
│ │ └── query.log ← これが sourcetype="mysql:query" │
│ └── app/ │
│ └── app.log ← これが sourcetype="myapp:log" │
└─────────────────────────────────────────────────────────────┘
↓ Splunkに取り込む
┌─────────────────────────────────────────────────────────────┐
│ Splunk: index="server_logs" │
│ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ sourcetype="linux:syslog" │ │
│ │ Jan 22 10:00:00 server01 kernel: ... │ │
│ └───────────────────────────────────────────────────┘ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ sourcetype="apache:access" │ │
│ │ 192.168.1.1 - - [22/Jan/2026:10:00:00] ... │ │
│ └───────────────────────────────────────────────────┘ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ sourcetype="apache:error" │ │
│ │ [Fri Jan 22 10:00:00 2026] [error] ... │ │
│ └───────────────────────────────────────────────────┘ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ sourcetype="mysql:query" │ │
│ │ SELECT * FROM users WHERE id=1; │ │
│ └───────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
1つのサーバーから複数のsourcetypeが生まれる
🎯 図解6: データフォーマットの違い
┌─────────────────────────────────────────────────────────────┐
│ sourcetype="linux:syslog" │
├─────────────────────────────────────────────────────────────┤
│ Jan 22 10:15:30 server01 kernel: CPU usage 75% │
│ ↑ ↑ ↑ ↑ ↑ ↑ │
│ 月 日 時刻 ホスト名 プログラム メッセージ │
│ │
│ Splunkが認識するフィールド: │
│ - month = "Jan" │
│ - day = 22 │
│ - time = "10:15:30" │
│ - host = "server01" │
│ - program = "kernel" │
│ - message = "CPU usage 75%" │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ sourcetype="apache:access" │
├─────────────────────────────────────────────────────────────┤
│ 192.168.1.1 - - [22/Jan/2026:10:15:30] "GET /index.html" 200│
│ ↑ ↑ ↑ ↑ ↑ │
│ IP ユーザー 日時 リクエスト ステータス│
│ │
│ Splunkが認識するフィールド: │
│ - clientip = "192.168.1.1" │
│ - timestamp = "22/Jan/2026:10:15:30" │
│ - method = "GET" │
│ - uri = "/index.html" │
│ - status = 200 │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ sourcetype="mysql:query" │
├─────────────────────────────────────────────────────────────┤
│ 2026-01-22 10:15:30 SELECT * FROM users WHERE id=1; │
│ ↑ ↑ │
│ 日時 SQLクエリ │
│ │
│ Splunkが認識するフィールド: │
│ - timestamp = "2026-01-22 10:15:30" │
│ - query = "SELECT * FROM users WHERE id=1;" │
│ - table = "users" │
└─────────────────────────────────────────────────────────────┘
sourcetypeごとに「読み方のルール」が違う
🎯 図解7: 複数index・複数sourcetypeの組み合わせ
全体構造
┌─────────────────────────────────────────────────────────────┐
│ │
│ 📚 index="web_logs" │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 📦 sourcetype="apache:access" │ │
│ │ 📦 sourcetype="nginx:access" │ │
│ │ 📦 sourcetype="tomcat:access" │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 📚 index="server_logs" │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 📦 sourcetype="linux:syslog" │ │
│ │ 📦 sourcetype="vmstat" │ │
│ │ 📦 sourcetype="df" │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 📚 index="app_logs" │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 📦 sourcetype="myapp:api" │ │
│ │ 📦 sourcetype="myapp:db" │ │
│ │ 📦 sourcetype="myapp:error" │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
検索例1: 1つのindex、1つのsourcetype
index="server_logs" sourcetype="linux:syslog"
→ 📚 server_logs > 📦 linux:syslog
検索例2: 1つのindex、複数のsourcetype
index="web_logs" (sourcetype="apache:access" OR sourcetype="nginx:access")
→ 📚 web_logs > 📦 apache:access + 📦 nginx:access
検索例3: 複数のindex、1つのsourcetype
(index="server_logs" OR index="app_logs") sourcetype="linux:syslog"
→ 📚 server_logs > 📦 linux:syslog
📚 app_logs > 📦 linux:syslog
検索例4: ワイルドカード
index="web_logs" sourcetype="*:access"
→ 📚 web_logs > 📦 apache:access + 📦 nginx:access + 📦 tomcat:access
🎯 図解8: 時系列で見るデータの流れ
STEP 1: サーバーでログが生成される
┌─────────────────────────────────────────────────────────────┐
│ サーバー: server01 │
│ 10:00:00 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━> ログファイル │
│ Jan 22 10:00:00 kernel: CPU usage 65% │
│ Jan 22 10:00:01 apache: GET /index.html 200 │
│ Jan 22 10:00:02 mysql: SELECT * FROM users; │
└─────────────────────────────────────────────────────────────┘
↓
STEP 2: Splunkがログを取り込む
┌─────────────────────────────────────────────────────────────┐
│ Splunk Forwarder（データ収集） │
│ ・ファイルを読み込む │
│ ・タイムスタンプを解析 │
│ ・ログの種類を判定 │
└─────────────────────────────────────────────────────────────┘
↓
STEP 3: indexとsourcetypeに振り分ける
┌─────────────────────────────────────────────────────────────┐
│ Splunk Indexer（データ保存） │
│ │
│ 📚 index="server_logs" │
│ ├── 📦 sourcetype="linux:syslog" │
│ │ └── Jan 22 10:00:00 kernel: CPU usage 65% │
│ │ │
│ 📚 index="web_logs" │
│ ├── 📦 sourcetype="apache:access" │
│ │ └── Jan 22 10:00:01 apache: GET /index.html 200 │
│ │ │
│ 📚 index="database_logs" │
│ └── 📦 sourcetype="mysql:query" │
│ └── Jan 22 10:00:02 mysql: SELECT * FROM users; │
└─────────────────────────────────────────────────────────────┘
↓
STEP 4: 検索・分析
┌─────────────────────────────────────────────────────────────┐
│ ユーザーが検索: │
│ index="server_logs" sourcetype="linux:syslog" │
│ │
│ 結果: │
│ 📄 Jan 22 10:00:00 kernel: CPU usage 65% │
└─────────────────────────────────────────────────────────────┘
🎯 図解9: よくある間違いと正解
❌ 間違い1: index指定なし
┌─────────────────────────────────────────────────────────────┐
│ sourcetype="linux:syslog" │
│ | timechart span=30m avg(cpu_usage) │
│ │
│ 問題点: │
│ 全indexから探すので遅い（60秒） │
│ 📚📚📚📚📚📚📚📚📚📚 すべて探す │
└─────────────────────────────────────────────────────────────┘
✅ 正解1: index指定あり
┌─────────────────────────────────────────────────────────────┐
│ index="server_logs" sourcetype="linux:syslog" │
│ | timechart span=30m avg(cpu_usage) │
│ │
│ メリット: │
│ 特定indexだけ探すので速い（5秒） │
│ 📚 1つだけ探す │
└─────────────────────────────────────────────────────────────┘
❌ 間違い2: sourcetype指定なし
┌─────────────────────────────────────────────────────────────┐
│ index="server_logs" │
│ | timechart span=30m avg(cpu_usage) │
│ │
│ 問題点: │
│ 混ざったデータが取得される │
│ 📦 syslog + 📦 vmstat + 📦 df │
│ → 正しい平均が出ない │
└─────────────────────────────────────────────────────────────┘
✅ 正解2: sourcetype指定あり
┌─────────────────────────────────────────────────────────────┐
│ index="server_logs" sourcetype="linux:syslog" │
│ | timechart span=30m avg(cpu_usage) │
│ │
│ メリット: │
│ 純粋なデータだけ取得 │
│ 📦 syslog だけ │
│ → 正しい平均が出る │
└─────────────────────────────────────────────────────────────┘
🎯 図解10: 実務での使い分け
ケース1: CPU監視（特定のサーバー）
┌─────────────────────────────────────────────────────────────┐
│ index="server_logs" sourcetype="linux:syslog" host="server01"│
│ | timechart span=30m avg(cpu_usage) as CPU使用率 │
│ │
│ 📚 server_logs > 📦 linux:syslog > 🖥️ server01 │
│ ↑ ↑ ↑ │
│ どの倉庫 どの種類 どのサーバー │
└─────────────────────────────────────────────────────────────┘
ケース2: Webアクセス監視（全Webサーバー）
┌─────────────────────────────────────────────────────────────┐
│ index="web_logs" sourcetype="*:access" │
│ | timechart span=1h count as アクセス数 │
│ │
│ 📚 web_logs > 📦 apache:access + 📦 nginx:access │
│ ↑ ↑ │
│ どの倉庫 全Webサーバーのアクセスログ │
└─────────────────────────────────────────────────────────────┘
ケース3: エラー監視（全システム）
┌─────────────────────────────────────────────────────────────┐
│ index="*" error OR failed │
│ | timechart span=10m count as エラー数 │
│ │
│ 📚📚📚 全index > 📦📦📦 全sourcetype │
│ ↑ ↑ │
│ 全倉庫 errorまたはfailedを含むログ │
└─────────────────────────────────────────────────────────────┘
ケース4: 特定アプリケーション監視
┌─────────────────────────────────────────────────────────────┐
│ index="app_logs" sourcetype="myapp:*" │
│ | timechart span=5m count(eval(level="ERROR")) as エラー数│
│ │
│ 📚 app_logs > 📦 myapp:api + 📦 myapp:db + 📦 myapp:error │
│ ↑ ↑ │
│ アプリ専用 myappの全ログ │
└─────────────────────────────────────────────────────────────┘
📋 まとめ図解
┌─────────────────────────────────────────────────────────────┐
│ Splunkのデータ構造（完全版） │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🗄️ Splunk全体 │
│ └── 📚 index="倉庫名" │
│ ├── 📦 sourcetype="データ種類1" │
│ │ ├── 📄 ログ1 │
│ │ ├── 📄 ログ2 │
│ │ └── 📄 ログ3 │
│ ├── 📦 sourcetype="データ種類2" │
│ │ ├── 📄 ログ4 │
│ │ └── 📄 ログ5 │
│ └── 📦 sourcetype="データ種類3" │
│ └── 📄 ログ6 │
│ │
│ 検索の基本形: │
│ index="倉庫" sourcetype="種類" │
│ | timechart ... │
│ │
│ なぜこの順番？ │
│ 1. index → 大まかに絞る（速度UP） │
│ 2. sourcetype → 正確に絞る（精度UP） │
│ 3. timechart → 分析する │
└─────────────────────────────────────────────────────────────┘
理解できましたか？
頑張りましょうー