[Golden Kubestronaut] PCA 実践練習問題80問 - Prometheus Certified Associate

A) Metrics B) Logs C) Traces D) Alerts

正解: D

解説: オブザーバビリティの3つの柱はMetrics、Logs、Tracesです。Alertsはモニタリングの出力であり、コアシグナルには含まれません。Metricsは数値データ、Logsはイベント記録、Tracesは分散システムのリクエストパスを追跡します。

A) エージェントが中央サーバーにメトリクスをプッシュ B) 中央サーバーがターゲットからメトリクスをプル（pull） C) メッセージキューによる非同期収集 D) ストリーミング方式のリアルタイム収集

正解: B

解説: PrometheusはPullベースのアーキテクチャを使用します。Prometheusサーバーが設定された間隔（scrape_interval）ごとに各ターゲットのHTTPエンドポイントからメトリクスを取得します。この方式はターゲットの状態を自然に確認でき、サーバー側で収集頻度を制御できる利点があります。

A) Utilization, Saturation, Errors B) Uptime, Scalability, Efficiency C) Usage, Speed, Execution D) Utilization, Speed, Errors

正解: A

解説: USE方法論はBrendan Greggが提案したシステム性能分析方法論で、すべてのリソース（CPU、Memory、Disk、Network）についてUtilization（使用率）、Saturation（飽和度）、Errors（エラー）を確認します。

A) Rate, Errors, Duration B) Requests, Endpoints, Delays C) Resources, Events, Data D) Reads, Executions, Drops

正解: A

解説: RED方法論はTom Wilkieが提案したマイクロサービスモニタリング方法論です。Rate（秒あたりのリクエスト数）、Errors（失敗したリクエストの割合）、Duration（リクエスト処理時間）を測定します。USEがインフラリソースに焦点を当てるのに対し、REDはサービスレベルの性能に焦点を当てます。

A) サービス提供者が顧客に保証する契約書 B) サービス性能を測定する定量的な指標 C) 障害発生時に許容される最大復旧時間 D) サービス可用性の目標値

正解: B

解説: SLIはサービスレベルを定量的に測定する指標です。例えばリクエスト遅延時間、エラー率、スループットなどがSLIになります。SLO（Service Level Objective）はSLIの目標値、SLA（Service Level Agreement）は法的契約です。

A) CNCFインキュベーティングプロジェクトである B) テレメトリデータの生成、収集、管理のためのフレームワークである C) Prometheusを完全に置き換えるために作られた D) Metrics、Logs、Tracesを統合管理する

正解: C

解説: OpenTelemetryはテレメトリデータの標準化された収集フレームワークであり、Prometheusの置き換えを目的としたものではありません。Prometheusと相互補完的に使用され、OTLPプロトコルでPrometheusにメトリクスを送信できます。現在はGraduatedプロジェクトです。

A) ターゲットの状態を自動的に確認できる B) ファイアウォール背後の短期バッチジョブメトリクスの収集が容易 C) 中央で収集頻度を制御しやすい D) ターゲット設定がより簡単

正解: B

解説: Push方式はファイアウォール背後のターゲットや、非常に短時間しか実行されないバッチジョブからメトリクスを収集する際に有利です。PrometheusではこのケースのためにPushgatewayを提供しています。Pull方式の利点はターゲット状態の自動確認と中央集中式収集頻度制御です。

A) オブザーバビリティは事前定義されたメトリクスのみ確認するもの B) モニタリングは未知の問題を探索的に分析するもの C) オブザーバビリティはシステム内部状態を外部出力から把握できる能力である D) モニタリングはオブザーバビリティの上位概念である

正解: C

解説: オブザーバビリティはシステムの外部出力（メトリクス、ログ、トレース）を通じて内部状態を理解できるシステムの特性です。モニタリングは事前定義された指標を監視する行為であるのに対し、オブザーバビリティは予期しない問題も探索的に分析できる能力を意味します。

A) JSON形式のキーバリューペア B) メトリクス名とラベル、値が1行で表現されるテキスト形式 C) XMLベースの構造化形式 D) Protocol Buffers専用バイナリ形式

正解: B

解説: Prometheusの基本Exposition Formatは人間が読めるテキスト形式です。各行にメトリクス名、ラベル（中括弧内）、値がスペースで区切られて表現されます。TYPEとHELPのコメント行も含まれます。Protocol Buffers形式もサポートされますが、テキスト形式がデフォルトです。

A) メトリクスデータの圧縮保存 B) メトリクスからトレースへの接続リンクを提供する C) アラートルールのサンプルクエリを保存する D) ヒストグラムバケットのサンプル値を保存する

正解: B

解説: Exemplarは特定のメトリクスサンプルにtrace IDなどの追加ラベルを付与して、メトリクスからトレースへの直接的な接続を可能にします。これにより、高遅延のヒストグラムバケットから該当リクエストの分散トレースに直接移動できます。

A) Latency B) Traffic C) Throughput D) Saturation

正解: C

解説: Google SREが定義した4つのゴールデンシグナルはLatency（レイテンシ）、Traffic（トラフィック）、Errors（エラー率）、Saturation（飽和度）です。ThroughputはTrafficと関連がありますが、正確なゴールデンシグナル用語ではありません。

A) メトリクス名のみ B) メトリクス名とラベルセットの組み合わせ C) タイムスタンプと値の組み合わせ D) メトリクス名とタイムスタンプ

正解: B

解説: Prometheusの多次元データモデルでは、時系列はメトリクス名とラベルのキーバリューペアの一意な組み合わせで識別されます。同じメトリクス名でもラベルが異なれば別の時系列として保存されます。

A) スクレイピング間隔が短すぎる場合 B) ラベル値の種類が無限に増加する場合 C) アラートルールが多すぎる場合 D) リテンション期間が長すぎる場合

正解: B

解説: カーディナリティ爆発はuser_id、request_id、IPアドレスなど一意な値が非常に多いラベルを使用する際に発生します。ラベル値ごとに別の時系列が作成されるため、TSDBのメモリとディスク使用量が急激に増加します。

A) Prometheusとは無関係な独自のメトリクス標準である B) Prometheus Exposition Formatを基に標準化したCNCFプロジェクトである C) JSON専用メトリクスフォーマットである D) バイナリ専用プロトコルである

正解: B

解説: OpenMetricsはPrometheus Exposition Formatを基に標準化されたメトリクス伝送形式です。CNCFプロジェクトとして、テキストとProtocol Buffersの2つの形式をサポートします。Exemplarサポート、Createdタイムスタンプなど追加機能を含みます。

A) クエリ性能の向上 B) クラッシュ復旧時のデータ損失防止 C) メトリクスの圧縮保存 D) リモートストレージの同期

正解: B

解説: WALはデータがメモリのHead Blockに書き込まれる前に、まずディスクに順次記録されます。Prometheusが異常終了してもWALをリプレイしてHead Blockのデータを復旧できます。WALセグメントファイルはデフォルト128MBサイズです。

A) 最新のデータをメモリに保持する B) デフォルトで最新2時間のデータを含む C) ディスクに永続的に保存されている D) スクレイピングされた新しいサンプルが最初に記録される場所

正解: C

解説: Head Blockはメモリ上に存在するインメモリブロックです。最新のデータ（デフォルト2時間）を保持し、新しいサンプルはまずWALに記録された後、Head Blockに追加されます。Head Blockのデータは定期的にディスクの永続ブロックにコンパクションされます。

A) SIGHUPシグナルの送信 B) /-/reload HTTPエンドポイントの呼び出し C) prometheus.ymlファイル編集後の自動検知 D) --web.enable-lifecycleフラグ有効化後のAPI呼び出し

正解: C

解説: Prometheusは設定ファイルの変更を自動検知しません。SIGHUPシグナルを送るか、--web.enable-lifecycleフラグが有効な状態で/-/reload POSTエンドポイントを呼び出す必要があります。Prometheus Operator環境ではconfig-reloaderサイドカーがこれを自動化します。

A) 古いブロックを削除するプロセスである B) 複数の小さなブロックを一つの大きなブロックにマージするプロセスである C) ブロックデータをリモートストレージに転送するプロセスである D) WALファイルをクリーンアップするプロセスである

正解: B

解説: コンパクションは複数の小さなブロックを一つの大きなブロックにマージしてクエリ効率を高めるプロセスです。レベルベースのコンパクション方式を使用し、マージ過程で削除マーキング（tombstone）されたデータが実際に削除されます。

A) prometheus.ymlファイルでretention設定 B) --storage.tsdb.retention.timeコマンドラインフラグ C) TSDB APIによる動的設定 D) 環境変数PROMETHEUS_RETENTION

正解: B

解説: Prometheusのリテンションはコマンドラインフラグで設定します。--storage.tsdb.retention.timeで時間ベースのリテンション（デフォルト15日）を、--storage.tsdb.retention.sizeでサイズベースのリテンションを設定できます。両方を設定すると先に到達する条件が適用されます。

A) どちらもメトリクス収集間隔である B) scrape_intervalはメトリクス収集間隔、evaluation_intervalはルール評価間隔である C) scrape_intervalはグローバル設定、evaluation_intervalはジョブ別設定である D) 2つの値は常に同一でなければならない

正解: B

解説: scrape_intervalはPrometheusがターゲットからメトリクスを収集する周期（デフォルト1分）、evaluation_intervalはrecording ruleとalerting ruleを評価する周期（デフォルト1分）です。独立して設定可能ですが、一般的に同じ値に設定することが推奨されます。

A) タイムスタンプと値の両方を生の値で保存 B) タイムスタンプはdelta-of-delta、値はXORエンコーディング C) 両方ともgzip圧縮 D) LZ4ブロック圧縮

正解: B

解説: Prometheus TSDBはFacebookのGorilla論文に基づく圧縮方式を使用します。タイムスタンプはdelta-of-deltaエンコーディングでほとんど非常に少ないビットで表現され、値（float64）はXORエンコーディングで前の値との差分のみ保存します。これによりサンプルあたり約1.37バイトの高圧縮率を達成します。

A) Prometheusサーバー間でデータを自動的にレプリケートする B) 上位Prometheusが下位Prometheusの特定メトリクスをスクレイピングする C) すべてのPrometheusインスタンスが同じTSDBを共有する D) Alertmanagerを通じてメトリクスを伝播する

正解: B

解説: Federationは上位（global）Prometheusサーバーが下位（local）Prometheusサーバーの/federateエンドポイントから選択された時系列をスクレイピングする階層構造です。matchパラメータで必要なメトリクスのみ選択的に収集します。

A) 収集されたサンプルをリモートエンドポイントに送信する B) snappy圧縮されたProtocol Buffers形式を使用する C) リモートストレージに書き込むとローカルTSDB保存をスキップする D) キューベースで動作しリトライロジックが含まれている

正解: C

解説: remote_writeはローカルTSDB保存と並行して動作します。収集されたサンプルはローカルTSDBにも保存され、同時にリモートエンドポイントにも送信されます。snappy圧縮されたprotobuf形式を使用し、内部キューとリトライメカニズムで一時的な障害を処理します。

A) ターゲットが消失すると該当時系列データが即座に削除される B) スクレイピングに失敗するとstale markerが追加されて時系列がstale状態になる C) 時系列は永久に維持されstale処理されない D) 5分間新しいサンプルがなければ自動的にstale処理される

正解: B

解説: Prometheus 2.x以降staleness処理が改善されました。ターゲットがスクレイピングから消失すると、該当時系列にstale marker（特殊NaN値）が追加されます。クエリ時にlookback delta（デフォルト5分）内にstale markerがあれば、その時系列は結果から除外されます。

A) Kubernetes Serviceを自動的に作成する B) Prometheusがスクレイピングするターゲットを宣言的に定義する C) Alertmanagerのルーティングルールを定義する D) Grafanaダッシュボードを自動生成する

正解: B

解説: ServiceMonitorはPrometheus Operatorが提供するCRDで、Kubernetes Serviceを基にPrometheusスクレイピングターゲットを宣言的に定義します。namespaceSelectorとselectorで対象Serviceを選択し、endpointsフィールドでポート、パス、間隔などを設定します。

A) Prometheusを完全に置き換える B) Prometheusの長期ストレージと水平スケーリングを提供する C) PromQLを置き換える新しいクエリ言語を提供する D) Alertmanagerを置き換える

正解: B

解説: ThanosとCortex（現在のMimir）はどちらもPrometheusの長期ストレージ、グローバルビュー、高可用性を提供するソリューションです。Thanosはサイドカーパターンとオブジェクトストレージを、Cortex/Mimirは完全分散アーキテクチャを使用します。

A) 時系列データの時系列順ソート B) ラベルベースの時系列検索を高速に実行する C) メトリクス値の圧縮保存 D) WALファイルの位置追跡

正解: B

解説: TSDBの転置インデックスはラベル名-値ペアから、そのラベルを持つ時系列ID一覧（posting list）へのマッピングです。PromQLクエリでラベルマッチング条件が指定されると、転置インデックスを通じて該当する時系列を高速に検索できます。

A) 従来のヒストグラムと同じ保存方式を使用する B) バケット境界を事前定義する必要なく指数分布バケットを自動生成する C) Summaryタイプを置き換えるために導入された D) PromQLで特別な関数なしに使用可能

正解: B

解説: Native Histogram（Exponential Histogram）はPrometheus 2.40から導入された新しいヒストグラム形式です。事前にバケット境界を定義する必要なく、指数分布方式で自動バケットを生成します。これによりカーディナリティを大幅に削減しながら正確な分位数計算が可能です。

A) スクレイピングされたメトリクスのラベルがPrometheusが自動追加するラベルより優先される B) ラベル名を自動的に正規化する C) 競合するラベルをすべて削除する D) 外部ラベルのみ保持する

正解: A

解説: honor_labelsをtrueに設定すると、スクレイピングされたメトリクスに既に存在するラベルがPrometheusのサーバー側ラベル（job、instanceなど）と競合する場合、元のラベルが維持されます。FederationやPushgatewayで元のラベルを保存する必要がある場合に使用されます。

A) ターゲット検索に要する最大時間 B) 個別スクレイピングリクエストのタイムアウト C) アラート送信のタイムアウト D) PromQLクエリ実行のタイムアウト

正解: B

解説: scrape_timeoutは個別スクレイピングHTTPリクエストのタイムアウトです。デフォルト値は10秒で、scrape_interval以下でなければなりません。ターゲットがこの時間内に応答しないとスクレイピングが失敗として記録され、upメトリクスが0になります。

A) Scalar B) Instant Vector C) Range Vector D) String

正解: B

解説: rate()関数はRange Vectorを入力として受け取り、Instant Vectorを返します。各時系列について5分範囲内のサンプルを使用して秒あたりの平均増加率を計算し、その結果は単一タイムスタンプの値（Instant Vector）として返されます。

A) rate()はGaugeに、irate()はCounterに使用する B) rate()は全区間の平均増加率、irate()は最後の2サンプル間の瞬間増加率である C) irate()はrate()より常に正確である D) 2つの関数は同一の結果を返す

正解: B

解説: rate()は範囲内の最初と最後のサンプル間の平均秒あたり増加率を計算します。irate()は範囲内の最後の2サンプルのみ使用して瞬間変化率を計算します。rate()はアラートとrecording ruleに、irate()は変動性の高いグラフに適しています。

A) 正確な95パーセンタイルを計算する B) バケット境界間の線形補間で95パーセンタイルを推定する C) クライアント側で計算された分位数を取得する D) 最後の5分間の最大値を返す

正解: B

解説: histogram_quantile()はヒストグラムバケットの累積カウントに基づいて分位数を推定します。バケット境界間で線形補間を使用するため、実際の値と差がある場合があります。特にバケット境界が実際の分布と合わないと不正確になります。

A) クエリ結果の時間を未来に移動 B) 現在時点の代わりに過去の特定時点のデータを照会 C) スクレイピング間隔を調整 D) ラベル値を変換

正解: B

解説: offset修飾子はクエリの評価時点を過去に移動させます。例えば http_requests_total offset 1h は1時間前のデータを照会します。@修飾子は特定のエポックタイムスタンプを指定します。

A) sum B) avg C) rate D) topk

正解: C

解説: rate()は関数（function）であり、集約演算子（aggregation operator）ではありません。Prometheusの集約演算子にはsum、avg、min、max、count、stddev、stdvar、topk、bottomk、quantile、count_values、groupなどがあります。

A) byは指定したラベルのみ保持、withoutは指定したラベルを除去 B) byはフィルタリング、withoutは集約に使用 C) 両者は同一機能である D) byはinstant query、withoutはrange queryに使用

正解: A

解説: by句は指定されたラベルのみ保持し残りを除去して集約します。without句は指定されたラベルを除去し残りを保持して集約します。例えば sum by (job)(metric) はjobラベル別に合算し、sum without (instance)(metric) はinstanceラベルを除いて合算します。

A) TSDBに保存されたラベルを永久的に変更 B) クエリ結果で正規表現によりラベル値を変換して新しいラベルを生成 C) relabel_configsと同一の機能 D) ラベルを削除する関数

正解: B

解説: label_replaceはクエリ時点で正規表現を使用して既存ラベル値の一部をキャプチャし、新しいラベルを生成したり既存ラベル値を変更します。クエリ結果にのみ影響し、保存されたデータは変更しません。

A) rate(http_requests_total[5m])[30m:1m] B) rate(http_requests_total[5m]) subquery 30m C) subquery(rate(http_requests_total[5m]), 30m, 1m) D) rate(http_requests_total[5m]).range(30m, 1m)

正解: A

解説: サブクエリはinstant vectorを返す式の後に[range:resolution]の形式で記述します。この例ではrate()の結果を30分範囲で1分間隔で評価します。resolutionを省略するとグローバルevaluation_intervalが使用されます。サブクエリはmax_over_timeなどrange vector関数の入力として活用されます。

A) http_requests_totalからhttp_errors_totalの値を引く B) http_requests_totalのうちhttp_errors_totalにマッチしない時系列のみ返す C) 2つのメトリクスの共通部分を返す D) 条件付きでhttp_requests_totalを返す

正解: B

解説: unlessは集合演算子で、左のベクターから右のベクターとラベルがマッチする時系列を除去します。つまり、http_requests_totalの時系列のうち、同じラベルセットを持つhttp_errors_totalがない時系列のみ返します。

A) Gaugeの増加量を計算する B) Counterの指定期間中の総増加量を返す C) rate()と完全に異なる計算方式を使用する D) 結果は常に整数である

正解: B

解説: increase()は指定された時間範囲内でCounterの総増加量を返します。内部的にrate()に時間範囲（秒）を掛けたものと同じ計算を行います。範囲の開始と終了を外挿するため、結果が整数にならない場合があります。

A) onは指定されたラベルのみでマッチング、ignoringは指定されたラベルを無視してマッチング B) onはフィルタリング、ignoringはソートに使用 C) 両方とも集約演算でのみ使用 D) onは左ベクター、ignoringは右ベクターに適用

正解: A

解説: 二項演算でonキーワードは指定されたラベルのみを使用して両側のベクターをマッチングします。ignoringキーワードは指定されたラベルを無視して残りのラベルでマッチングします。これはby/withoutと似ていますが、集約ではなくベクター間のマッチングに使用されます。

A) 時系列をグループにまとめて表示 B) 多対一または一対多のベクターマッチングを許可 C) ラベルを左または右に移動 D) クエリ結果をソート

正解: B

解説: デフォルトのベクターマッチングは一対一（one-to-one）です。group_leftは右ベクターの一つの要素が左ベクターの複数要素とマッチング（多対一）されるように許可します。group_rightはその逆です。

A) Counterタイプにのみ使用可能 B) Gaugeの線形回帰に基づいて未来の値を予測する C) 機械学習アルゴリズムを使用する D) 範囲内の最大値を予測する

正解: B

解説: predict_linear()は単純線形回帰を使用してGauge時系列の未来の値を予測します。主にディスク容量、証明書の有効期限などのキャパシティプランニングアラートに使用されます。

A) 値が0の時系列を探す B) 存在しない時系列に対して値1を返す C) 時系列を削除する D) NaN値をフィルタリングする

正解: B

解説: absent()は入力ベクターが空の時（該当時系列が存在しない時）、値1を持つ単一要素ベクターを返します。時系列が存在すれば空のベクターを返します。主にメトリクスが消失したケースを検知するアラートに使用されます。

A) Gaugeの値が0になった回数 B) Counterのリセット（減少）回数 C) スクレイピング失敗回数 D) アラート解除回数

正解: B

解説: resets()は範囲内でCounter値が減少した（リセットされた）回数を返します。Counterリセットはアプリケーション再起動などで発生します。rate()とincrease()は内部的にCounterリセットを自動補正しますが、resets()はリセット自体の頻度を監視する際に有用です。

A) rate() B) avg_over_time() C) abs() D) delta()

正解: C

解説: abs()はinstant vectorを入力として受け取り、各サンプルの絶対値を返す関数です。rate()、avg_over_time()、delta()はすべてrange vectorを入力とする関数です。

A) 比較演算の結果をフィルタリングの代わりに0または1の値で返す B) 論理演算を有効化 C) ブーリアン型メトリクスを照会 D) 真偽アラートを生成

正解: A

解説: デフォルトでは比較演算子は条件を満たさない時系列をフィルタリングします。bool修飾子を使用するとフィルタリングの代わりに条件満足時に1、不満足時に0を返します。例えば http_requests_total > bool 100 は100超過なら1、以下なら0を返します。

A) Counterの増加回数 B) 時系列の値が変更された回数 C) ラベルが変更された回数 D) 設定が変更された回数

正解: B

解説: changes()は指定された時間範囲内で時系列の値が変更された回数を返します。主にGaugeタイプメトリクスで値の変動頻度を把握する際に使用されます。

A) Counterの微分値を計算する B) Gaugeの秒あたりの変化率を線形回帰で計算する C) rate()と同一の計算を行う D) 離散微分を計算する

正解: B

解説: deriv()は単純線形回帰を使用してGauge時系列の秒あたりの変化率（導関数）を計算します。rate()がCounter専用であるのに対し、deriv()はGaugeに使用されます。ノイズのあるデータで全体的なトレンドを把握する際に有用です。

A) rate()をsum()と共に使用できない B) ない。正しいクエリである C) by句がsumの前に来なければならない D) status_codeラベルが存在しないとエラーが発生する

正解: B

解説: このクエリは正しいです。rate()でCounterの秒あたり増加率を計算し、sum by (status_code)でステータスコード別に合算します。by句はsum()の前後どちらにも配置可能です。status_codeラベルがなくてもエラーではなく一つのグループとして合算されます。

A) less than or equal - 該当バケットの上限境界値 B) label expression - ラベルフィルタリング式 C) level - ヒストグラムの深さレベル D) length - 観測値の長さ

正解: A

解説: leは「less than or equal to」の略で、ヒストグラムバケットの上限境界値を表します。例えばle="0.5"のバケットには0.5以下の観測値の累積カウントが格納されます。最上位バケットはle="+Inf"で、histogram_quantile()はこのleラベルを使用して分位数を補間します。

A) 時系列の時間範囲を制限 B) サンプル値の下限と上限を設定 C) ラベル数を制限 D) クエリ結果の時系列数を制限

正解: B

解説: clamp_min(v, min)はベクターのすべてのサンプル値を最小minに制限し、clamp_max(v, max)は最大maxに制限します。clamp(v, min, max)は両方を同時に適用します。グラフでの異常スパイクの制限やマイナス値の防止に有用です。

A) メトリクス値を該当数値に設定する B) 該当Unixタイムスタンプ時点のデータを照会する C) 秒あたりのリクエスト数を該当値と比較する D) ラベルに該当値を追加する

正解: B

解説: @修飾子はクエリを特定のUnixエポックタイムスタンプ時点で評価します。offsetが現在時点からの相対的な時間移動であるのに対し、@は絶対的な時点を指定します。1609459200は2021年1月1日00:00:00 UTCに該当します。

A) 値を減少させることができる B) マイナス値を設定できる C) Inc()とAdd()のみ使用可能で値を減少させることはできない D) 初期値を必ず設定しなければならない

正解: C

解説: Counterは単調増加するメトリクスタイプで、Inc()（1増加）とAdd(positive_value)（正の値を加算）のみ許可されます。値を減少させるとパニックが発生します。Counterリセットはプロセス再起動時にのみ発生し、rate()とincrease()がこれを自動補正します。

A) node_cpu_seconds_total B) node_memory_MemTotal_bytes C) node_disk_io_time_seconds_total D) node_container_cpu_usage_seconds_total

正解: D

解説: node_container_cpu_usage_seconds_totalはNode Exporterではなく、cAdvisorが提供するコンテナレベルのメトリクスです。Node ExporterはホストレベルのハードウェアおよびOSメトリクス（CPU、メモリ、ディスク、ネットワーク等）を提供します。

A) ブラックボックスサーバーの内部メトリクス収集 B) HTTP、TCP、ICMP、DNSなどのプローブによるエンドポイント監視 C) ファイルシステムのブラックボックステスト D) 暗号化されたメトリクスの復号

正解: B

解説: Blackbox ExporterはHTTP(S)、TCP、ICMP、DNS、gRPCプローブを通じてサービスの可用性と応答時間を外部から監視します。サービスの内部計装なしに動作状況を確認できるブラックボックスモニタリングツールです。

A) 長期実行サービスのメトリクス収集 B) 短期バッチジョブのメトリクス収集 C) すべてのメトリクス収集に汎用的に使用 D) サービスディスカバリの代替

正解: B

解説: PushgatewayはPrometheusがスクレイピングする前に終了する短期バッチジョブのメトリクスを収集するための中間ゲートウェイです。ジョブ完了時に結果メトリクスをPushgatewayにプッシュし、Prometheusがこれをスクレイピングします。

A) Collect()のみ B) Describe()のみ C) Describe()とCollect() D) Init()とCollect()

正解: C

解説: Prometheus GoクライアントのCollectorインターフェースはDescribe()とCollect()の2つのメソッドを実装する必要があります。Describe()はメトリクスディスクリプタをチャネルに送信し、Collect()は現在のメトリクス値をチャネルに送信します。

A) ダッシュ(-)を使用して単語を区切る B) CamelCaseを使用する C) snake_caseを使用し、単位をサフィックスとして含む D) プレフィックスなしで短い名前を使用する

正解: C

解説: Prometheusメトリクスの命名規則はsnake_caseを使用し、単位をサフィックスとして含みます。例: http_request_duration_seconds、node_memory_MemTotal_bytes。プレフィックスは名前空間を示し、_totalはCounterに、_bytes/_secondsなどは単位を表します。

A) http-request-duration B) HttpRequestDuration C) http_request_duration_seconds D) http.request.duration

正解: C

解説: Prometheusメトリクス名は正規表現パターン [a-zA-Z_:][a-zA-Z0-9_:]* に従います。ダッシュ(-)やドット(.)は許可されません。snake_caseを使用し、Counterは_totalサフィックス、単位は基本単位（seconds、bytesなど）をサフィックスとして使用します。

A) Summaryはサーバー側、Histogramはクライアント側で分位数を計算する B) Summaryはクライアント側で分位数を計算し、Histogramはサーバー側で分位数を推定する C) 両者は完全に同一である D) Summaryのみラベルをサポートする

正解: B

解説: Summaryはクライアントアプリケーションで直接分位数を計算して公開します。正確ですが複数インスタンスの分位数を集約できません。Histogramはバケットカウントを公開し、サーバー側でhistogram_quantile()で分位数を推定します。Histogramの方がより柔軟で集約可能なため一般的に推奨されます。

A) カーディナリティが低いラベル値を使用 B) ユーザーIDをラベルとして追加 C) HTTPメソッド（GET、POSTなど）をラベルとして使用 D) ステータスコードをラベルとして使用

正解: B

解説: ユーザーIDは一意な値が非常に多く、高いカーディナリティを引き起こすためラベルとして使用すべきではありません。ラベルのカーディナリティが高いほど時系列数が爆発的に増加し、メモリと性能に深刻な影響を与えます。

A) /api/v1/metrics B) /metrics C) /prometheus D) /export

正解: B

解説: Prometheusエコシステムの標準メトリクスエンドポイントパスは/metricsです。Exporterと計装されたアプリケーションはこのパスでPrometheus Exposition Format形式のメトリクスを公開します。別のパスを使用する場合はscrape configでmetrics_pathを指定する必要があります。

A) 可能な限り多くのバケットを定義する B) サービスのSLOに合ったバケット境界を定義する C) すべてのサービスで同じバケットを使用する D) バケット境界をログスケールのみで定義する

正解: B

解説: ヒストグラムバケットはサービスのSLOと予想分布に合わせて定義すべきです。例えばSLOが500ms以下の応答であれば0.1、0.25、0.5、1.0などのバケットを設定します。多すぎるバケットはカーディナリティを増加させ、少なすぎると分位数の精度が低下します。

A) Node Exporter B) Prometheusクライアントライブラリのデフォルトプロセスメトリクス C) cAdvisor D) Kube-state-metrics

正解: B

解説: process_cpu_seconds_totalはPrometheusクライアントライブラリが自動的に収集するデフォルトプロセスメトリクスです。Go、Python、JavaなどほとんどのクライアントライブラリがプロセスのCPU使用時間、メモリ、オープンファイルディスクリプタ数などを自動的に公開します。

A) ノードのハードウェアリソース使用量 B) Kubernetes APIオブジェクトの状態情報 C) コンテナのCPU/メモリ使用量 D) ネットワークトラフィックメトリクス

正解: B

解説: kube-state-metricsはKubernetes APIサーバーを監視してDeployment、Pod、Node、JobなどKubernetesオブジェクトの状態をメトリクスに変換します。リソース使用量はcAdvisor/kubeletが、ハードウェアメトリクスはNode Exporterが提供します。

A) 現在のメモリ使用量 B) 現在のアクティブ接続数 C) 処理された総HTTPリクエスト数 D) CPU温度

正解: C

解説: Counterは単調増加する累積値に使用します。処理された総HTTPリクエスト数は継続的に増加するためCounterが適切です。メモリ使用量、アクティブ接続数、CPU温度は増減する値なのでGaugeを使用すべきです。

A) アラートを時系列順にソート B) 類似アラートを一つにまとめてアラート疲労を軽減 C) アラートを等級別に分類 D) アラートデータを圧縮

正解: B

解説: Alertmanagerのgroupingはgroup_byラベルに基づいて類似アラートを一つのグループにまとめます。例えば数百のインスタンスで同時に発生したアラートを一つのアラートグループとして統合して送信します。これによりアラート疲労（alert fatigue）を大幅に軽減できます。

A) すべてのアラートを一時的に停止 B) 特定のアラートが発生すると関連する下位アラートを自動的に抑制 C) アラート発生頻度を制限 D) 重複アラートをマージ

正解: B

解説: Inhibitionは特定のアラート（source）がアクティブになると、関連する他のアラート（target）を抑制するルールです。例えばクラスタ全体の障害アラートが発生すると、個別サービスの障害アラートを抑制できます。

A) アラート送信を繰り返す間隔 B) 条件が満たされた後firing状態に移行する前の待機時間 C) アラート解除までの待機時間 D) アラート評価間隔

正解: B

解説: forフィールドはアラート条件が満たされてから実際にfiring状態になるまでの待機時間（pending期間）です。この期間中条件が継続的に満たされる必要があります。一時的なスパイクによる偽陽性（false positive）アラートを防止するために使用されます。

A) メトリクスデータを外部に記録 B) 頻繁に使用される複雑なクエリを事前計算してパフォーマンス向上 C) アラート履歴を記録 D) スクレイピング結果をログに記録

正解: B

解説: Recording Ruleは頻繁に使用されるPromQL式を定期的に事前計算して新しい時系列として保存します。これによりダッシュボードのロード時間を短縮し、複雑なクエリの繰り返し実行コストを削減します。命名規則はlevel:metric:operations形式です。

A) 両者は同一の機能である B) silenceは手動で特定アラートを一時停止し、inhibitionはルールベースの自動抑制である C) silenceは永久的で、inhibitionは一時的である D) silenceは設定ファイルに、inhibitionはUIでのみ設定する

正解: B

解説: Silenceは管理者が手動で特定のラベルマッチング条件のアラートを一定期間停止させる機能です（例: メンテナンス作業中）。Inhibitionは設定ファイルに定義されたルールに従って自動的にアラートを抑制します。SilenceはAlertmanager UIやAPIで管理します。

A) すべてアラート送信頻度を制御する B) group_waitは最初のアラート待機、group_intervalはグループ更新間隔、repeat_intervalは再送間隔である C) 3つの値は常に同一でなければならない D) group_waitのみ必須設定である

正解: B

解説: group_waitは新しいアラートグループの最初のアラート送信前に追加アラートを収集するための待機時間（デフォルト30秒）です。group_intervalは既に送信されたグループに新しいアラートが追加された際の送信間隔（デフォルト5分）です。repeat_intervalは同一アラートの再送間隔（デフォルト4時間）です。

A) SQL B) PromQL C) LogQL D) InfluxQL

正解: B

解説: GrafanaでPrometheusデータソースを使用する際はPromQLでクエリを作成します。Grafanaのクエリエディタで直接PromQLを入力するか、ビルダーモードでGUIでクエリを構成できます。LogQLはLoki用、InfluxQLはInfluxDB用のクエリ言語です。

A) すべてのアラートがすべてのレシーバーに送信される B) アラートがラベルベースのマッチングで適切なレシーバーにルーティングされる C) ルーティングは時間ベースでのみ動作する D) ルーティングツリーの深さは2段階に制限される

正解: B

解説: Alertmanagerのルーティングツリーは階層構造で、ルートルートからアラートのラベルとmatch/match_re条件を比較しながら子ルートに分岐します。continueオプションがなければ最初のマッチングルートで停止し、continue: trueの場合は次の兄弟ルートも検査します。

A) 症状（symptom）ベースのアラート作成 B) すべてのメトリクスに対してアラートを生成 C) 実行可能な（actionable）アラートのみ生成 D) for句を使用して一時的なスパイクをフィルタリング

正解: B

解説: すべてのメトリクスに対してアラートを生成するとアラート疲労が極度に高くなります。良いアラートは症状ベース（原因ではなくユーザーへの影響）、実行可能（受信者が対処できる）、適切な閾値とfor句を持つべきです。

A) リーダー選出ベースで一つのインスタンスのみアクティブ化 B) Gossipプロトコルでアラート状態を同期して重複送信を防止 C) 外部データベースに状態を共有 D) ロードバランサーがリクエストを分配

正解: B

解説: Alertmanager HAクラスタはHashicorpのMemberlistライブラリを使用したGossipプロトコルで構成されます。各インスタンスはアラート状態（notification log）とsilenceを同期します。すべてのインスタンスがアラートを受信しますが、同期により同一アラートが一度だけ送信されるよう保証します。

A) record_metric_operation B) level:metric:operations C) metric.level.operation D) METRIC_LEVEL_OPERATION

正解: B

解説: Recording Ruleの推奨命名規則はlevel:metric:operations形式です。levelは集約レベル（job、instanceなど）、metricは元のメトリクス名、operationsは適用された関数と集約です。例: job:http_requests_total:rate5m。コロン(:)はrecording rule専用です。

A) 両者は完全に同一である B) PrometheusアラートはPrometheusサーバーで、GrafanaアラートはGrafanaサーバーで評価される C) GrafanaアラートのみAlertmanagerを使用する D) Prometheusアラートは可視化専用である

正解: B

解説: Prometheusアラートルールはprometheusサーバーのrule managerで定期的にPromQLを評価し、条件充足時にAlertmanagerに送信します。GrafanaアラートはGrafanaサーバーでデータソースにクエリを送って評価します。Prometheusアラートはデータに近い場所で評価されるためより安定的で推奨されます。

A) .Status（firing/resolved） B) .Labels（アラートラベル） C) .Annotations（アラートアノテーション） D) .Query（元のPromQLクエリ全文）

正解: D

解説: Alertmanagerテンプレートでは.Status、.Labels、.Annotations、.StartsAt、.EndsAt、.GeneratorURLなどのフィールドを使用できます。元のPromQLクエリ全文は直接提供されません。.GeneratorURLにPrometheusのクエリリンクが含まれているため間接的に確認できます。