ストーリー
高橋アーキテクトがクイズを用意してくれた。
クイズの説明
Step 2 で学んだ内容の理解度をチェックします。
- 全8問
- 合格ライン: 80%（7問正解）
- 不合格の場合は復習してから再挑戦してください
問題
Q1. 構造化ログの最大の利点として最も適切なものはどれですか？
- A) ファイルサイズが小さくなる
- B) 人間が読みやすい
- C) 機械的な検索・分析・アラート設定が容易になる
- D) ログの出力速度が向上する
解答と解説
正解: C
構造化ログ（JSON形式等）の最大の利点は、フィールドが明確に定義されているため、機械的な検索、集計、フィルタリング、アラート設定が容易になることです。人間の可読性はむしろ低下しますが、ログ管理ツールでの活用効率が大幅に向上します。
Q2. 構造化ログに必ず含めるべきフィールドの組み合わせとして最も適切なものはどれですか？
- A) timestamp, message, username, password
- B) timestamp, level, message, service, traceId
- C) timestamp, message, CPU使用率, メモリ使用量
- D) timestamp, level, SQL文, 実行結果
解答と解説
正解: B
構造化ログの必須フィールドは、timestamp（いつ）、level（重要度）、message（何が起きたか）、service（どのサービスか）、traceId（リクエスト追跡用）です。password等の機密情報は含めてはならず、CPU使用率はメトリクスの領域です。
Q3. 本番環境でのデフォルトログレベルとして最も適切なものはどれですか？
- A) TRACE
- B) DEBUG
- C) INFO
- D) ERROR
解答と解説
正解: C
本番環境のデフォルトログレベルはINFOが推奨されます。TRACE/DEBUGは情報量が多すぎてコストとパフォーマンスに影響し、ERRORだけでは正常動作の記録が残らず障害調査に支障をきたします。INFOで正常な業務イベントを記録しつつ、必要時にDEBUGに一時変更できる仕組みが理想です。
Q4. ログの保持ポリシーにおいて、ERROR/FATALレベルのログの推奨保持期間はどれですか？
- A) 3日
- B) 14日
- C) 30日
- D) 90日
解答と解説
正解: D
ERROR/FATALレベルのログは障害調査や監査のために長期間保持する必要があり、90日が推奨されます。INFOは14日、WARNは30日、DEBUGは3日が一般的な目安です。ホットストレージに保存して即時検索可能な状態にしておくことも重要です。
Q5. ELK Stackにおいて、ログのインデックス作成と全文検索を担当するコンポーネントはどれですか？
- A) Logstash
- B) Elasticsearch
- C) Kibana
- D) Filebeat
解答と解説
正解: B
Elasticsearchがログの保存、インデックス作成、全文検索を担当します。Logstashはログの収集・変換・送信、Kibanaはログの可視化と検索UI、FilebeatはログファイルをLogstashやElasticsearchに転送するシッパーです。
Q6. ログのサンプリングを行う場合、サンプリングすべきでないログレベルはどれですか？
- A) DEBUG
- B) INFO
- C) WARN
- D) ERROR
解答と解説
正解: D
ERRORレベルのログは障害調査に不可欠であり、100%記録すべきです。INFOレベルの正常系ログ（特にヘルスチェックや高頻度アクセス）はサンプリングの候補になります。WARNも基本的には全件記録が推奨されますが、ERRORの全件記録は絶対条件です。
Q7. 障害調査でtraceIdを使ったリクエスト追跡を行う最大の利点は何ですか？
- A) ログファイルのサイズを削減できる
- B) 1つのリクエストに関する全サービスのログを横断的に取得できる
- C) ログの出力速度が向上する
- D) ログレベルを自動的に判定できる
解答と解説
正解: B
traceIdはリクエスト全体に付与される一意の識別子で、API Gateway → Order Service → Payment Serviceなど、複数サービスを横断するログを1つのリクエストとして紐づけて取得できます。これにより、分散システムでのリクエスト追跡と障害箇所の特定が格段に容易になります。
Q8. Grafana LokiとElasticsearchの比較として正しいものはどれですか？
- A) LokiはElasticsearchよりフルテキスト検索が高速である
- B) Lokiはログの中身をインデックスしないため、ストレージコストが低い
- C) ElasticsearchはLokiよりストレージコストが低い
- D) LokiはElasticsearchの完全な上位互換である
解答と解説
正解: B
Grafana Lokiはラベル（service, level等）のみをインデックスし、ログ本文はインデックスしません。そのためストレージコストが大幅に低くなります。一方、フルテキスト検索の速度はElasticsearchに劣ります。用途に応じた使い分けが重要です。
結果
7問以上正解の場合
合格です。おめでとうございます。
Step 2「構造化ログの設計」を完了しました。 次は Step 3「メトリクスとアラート設計」に進みましょう。
6問以下の場合
もう少し復習しましょう。
間違えた問題の内容を、該当するセクションで復習してください：
| 問題 | 復習セクション |
|---|---|
| Q1 | step2_1 構造化ログの基本 |
| Q2 | step2_1 構造化ログの基本 |
| Q3 | step2_2 ログレベルとフィルタリング |
| Q4 | step2_2 ログレベルとフィルタリング |
| Q5 | step2_3 集約と検索 |
| Q6 | step2_2 ログレベルとフィルタリング |
| Q7 | step2_4 ログによるデバッグとトラブルシューティング |
| Q8 | step2_3 集約と検索 |
Step 2 完了
お疲れさまでした。
学んだこと
- 構造化ログの基本とJSON形式でのスキーマ設計
- ログレベルの適切な使い分けとフィルタリング戦略
- ELK Stack、CloudWatch Logs、Grafana Lokiによるログ集約
- ログを活用した障害調査の体系的なアプローチ
次のステップ
Step 3: メトリクスとアラート設計（3時間）
ログの次は、オブザーバビリティの第2の柱「メトリクス」を深掘りします。
推定所要時間: 30分