> For the complete documentation index, see [llms.txt](https://atomoh.gitbook.io/kubernetes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atomoh.gitbook.io/kubernetes/jp/kuizu/gaido/09-observability-stack-quiz.md).
# 可観測性スタッククイズ
> **関連ドキュメント**: [Observability Stack](/kubernetes/jp/gaido/ops/09-observability-stack.md)
## 選択問題
### 1. LGTM observability stack のコンポーネントは何ですか？
* A) Linux, Git, Terminal, Make
* B) Loki (logs), Grafana (visualization), Tempo (traces), Mimir/Prometheus (metrics)
* C) Lambda, Gateway, Transit, Monitor
* D) Load balancer, Gateway, TLS, Mesh
答えを表示
**回答: B) Loki (logs), Grafana (visualization), Tempo (traces), Mimir/Prometheus (metrics)**
**解説:** LGTM は Grafana Labs の observability stack で、log aggregation のための Loki、visualization と dashboard のための Grafana、distributed tracing のための Tempo、metrics のための Mimir（または Prometheus）で構成されます。これらのコンポーネントはシームレスに統合されます。
### 2. Loki の SimpleScalable と Distributed deployment modes の違いは何ですか？
* A) SimpleScalable はテスト専用である
* B) SimpleScalable は read/write paths を分離し、Distributed はより細かな component separation を追加する
* C) Distributed は非推奨である
* D) これらは同一である
答えを表示
**回答: B) SimpleScalable は read/write paths を分離し、Distributed はより細かな component separation を追加する**
**解説:** SimpleScalable mode は Loki を、独立してスケールできる read paths と write paths に分割します。Distributed mode は、大規模環境で最大限の scalability と operational flexibility を実現するために、components（ingesters、distributors、queriers など）をさらに分離します。
### 3. Tempo における tail-based sampling の目的は何ですか？
* A) log files の末尾をサンプリングするため
* B) 完全な trace を確認した後に sampling decisions を行うため
* C) query latency を削減するため
* D) trace data を圧縮するため
答えを表示
**回答: B) 完全な trace を確認した後に sampling decisions を行うため**
**解説:** Tail-based sampling は、trace が完了するまで待ってから保存するかどうかを決定します。これにより、normal traces はサンプリングしつつ、すべての error traces や slow traces を保持できます。head-based sampling は trace の開始時に判断するため、これは実現できません。
### 4. observability stack において OTEL Collector はどのような役割を果たしますか？
* A) metrics を長期保存する
* B) applications から telemetry data を受信、処理、export する
* C) Grafana dashboards を作成する
* D) user authentication を管理する
答えを表示
**回答: B) applications から telemetry data を受信、処理、export する**
**解説:** OpenTelemetry Collector は telemetry pipeline として機能し、applications から traces、metrics、logs を受信し、それらを処理（batching、filtering、enriching）して、Tempo、Prometheus、Loki などの backends に export します。
### 5. Amazon Managed Prometheus (AMP) は Prometheus とどのように統合されますか？
* A) Prometheus を完全に置き換える
* B) Prometheus が remote\_write を使用して storage のために metrics を AMP に送信する
* C) AMP が Prometheus sidecar として実行される
* D) AMP は CloudWatch でのみ動作する
答えを表示
**回答: B) Prometheus が remote\_write を使用して storage のために metrics を AMP に送信する**
**解説:** AMP は Prometheus metrics のための managed で scalable な storage backend を提供します。Prometheus は引き続き local で scrape と rule evaluation を行いますが、`remote_write` を使用して metrics を AMP に送信します。その後、Grafana が PromQL を使用して AMP に query します。
### 6. 推奨される Loki label design strategy は何ですか？
* A) flexibility のためにできるだけ多くの labels を使用する
* B) index explosion を避けるために、bounded で low-cardinality な labels を使用する
* C) labels を一切使用しない
* D) timestamp labels のみを使用する
答えを表示
**回答: B) index explosion を避けるために、bounded で low-cardinality な labels を使用する**
**解説:** High-cardinality labels（user IDs や request IDs など）は過剰な streams を作成し、index を肥大化させます。Labels は low-cardinality（namespace、app、environment）にし、high-cardinality data は LogQL で filtering できるように log content に含めるべきです。
### 7. log collection における Promtail と Grafana Alloy の違いは何ですか？
* A) Promtail は metrics のみを収集する
* B) Alloy は logs、metrics、traces をサポートする unified agent であり、Promtail は Loki 専用である
* C) Promtail は Alloy より新しい
* D) Alloy は Kubernetes をサポートしていない
答えを表示
**回答: B) Alloy は logs、metrics、traces をサポートする unified agent であり、Promtail は Loki 専用である**
**解説:** Promtail は logs を Loki に送信するために特化して作られています。Grafana Alloy（旧 Agent）は、OpenTelemetry と native receivers を使用して logs、metrics、traces を扱う unified collector であり、必要な agents の数を減らします。
### 8. Loki と Tempo の間で Grafana datasource linking をどのように設定しますか？
* A) 設定なしで自動的に link される
* B) Tempo datasource を指す derived fields を Loki datasource に設定する
* C) 別の linking plugin をインストールする
* D) 共通の database に data を export する
答えを表示
**回答: B) Tempo datasource を指す derived fields を Loki datasource に設定する**
**解説:** Grafana の Loki datasource settings で、logs から trace IDs を抽出して Tempo datasource に link するための regex を持つ derived fields を設定します。これにより、log lines から関連する traces へのクリック可能な links が作成されます。
### 9. Tempo の compactor component の目的は何ですか？
* A) network traffic を圧縮するため
* B) trace blocks を merge し、retention を管理するため
* C) TraceQL queries をコンパイルするため
* D) dashboard loading time を短縮するため
答えを表示
**回答: B) trace blocks を merge し、retention を管理するため**
**解説:** Compactor は storage efficiency のために小さな trace blocks を大きなものに merge し、期限切れ data を削除することで retention policies を適用します。Distributed mode では別の process として、または monolithic binary 内で実行されます。
### 10. OTEL Collector processors を設定するとき、batch processor は何をしますか？
* A) traces に batch IDs を割り当てる
* B) efficiency を向上させるため、export 前に telemetry を batches にグループ化する
* C) database batch operations を処理する
* D) Kubernetes で batch jobs を作成する
答えを表示
**回答: B) efficiency を向上させるため、export 前に telemetry を batches にグループ化する**
**解説:** Batch processor は telemetry data を蓄積し、size または timeout thresholds に基づいて batches で送信します。これにより outgoing requests の数が減り、compression が向上し、receiving backends への load が低減されます。