第5章 Report

5.1. Report について

Report カスタムリソースは、SQL クエリーを使用して定期的な ETL (Extract Transform および Load) ジョブを管理する方法を提供します。レポートは、実行する実際の SQL クエリーを提供する ReportQuery リソースや、ReportQuery および Report リソースで利用できるデータを定義する ReportDataSource リソースなどの他のメータリングリソースで設定されます。

多くのユースケースは、メータリングと共にインストールされる事前に定義された ReportQuery および ReportDataSource リソースで対応されます。したがって、これらの事前定義済みのリソースで対応されないユースケースがない場合、独自の定義は必要ありません。

5.1.1. Report

Report カスタムリソースは、レポートの実行およびステータスを管理するために使用されます。メータリングは、使用状況のデータソースから派生するレポートを生成します。これは、詳細な分析およびフィルターで使用できます。単一の Report リソースは、データベーステーブルを管理するジョブを示し、これをスケジュールに応じて新しい情報で更新します。レポートは、テーブルのデータをレポート Operator HTTP API 経由で公開します。

spec.schedule フィールドが設定された Report は常に実行された状態となり、データの収集期間を追跡します。メータリングが長期間シャットダウンするか、または使用できない状態になる場合、データの停止時点からデータをバックフィルします。スケジュールが設定されていない場合、レポートは reportingStart および reportingEnd で指定された期間に 1 回実行されます。デフォルトで、レポートは ReportDataSource リソースがレポート期間内のデータを完全にインポートするのを待機します。レポートにスケジュールがある場合、現在処理されている期間内のデータのインポートがすべて完了するまで待機します。

5.1.1.1. スケジュールが設定されたレポートの例

以下のサンプル Report にはすべての Pod の CPU 要求についての情報が含まれ、1 時間に 1 回実行され、レポートが実行されるごとにその 1 時間前からの関連データが追加されます。

apiVersion: metering.openshift.io/v1
kind: Report
metadata:
  name: pod-cpu-request-hourly
spec:
  query: "pod-cpu-request"
  reportingStart: "2019-07-01T00:00:00Z"
  schedule:
    period: "hourly"
    hourly:
      minute: 0
      second: 0

5.1.1.2. スケジュールなしのサンプルレポート (1 回のみ実行)

以下のサンプル Report オブジェクトには、7 月中のすべての Pod の CPU 要求についての情報が含まれます。完了後に再度実行されることはありません。

apiVersion: metering.openshift.io/v1
kind: Report
metadata:
  name: pod-cpu-request-hourly
spec:
  query: "pod-cpu-request"
  reportingStart: "2019-07-01T00:00:00Z"
  reportingEnd: "2019-07-31T00:00:00Z"

5.1.1.3. query

query フィールドは、レポートを生成するために使用される ReportQuery リソースに名前を指定します。レポートクエリーは、結果の処理方法と共にレポートのスキーマを制御します。

query は必須フィールドです。

利用可能な ReportQuery リソースを一覧表示するには、以下のコマンドを使用します。

$ oc -n openshift-metering get reportqueries

出力例

NAME                                         AGE
cluster-cpu-capacity                         23m
cluster-cpu-capacity-raw                     23m
cluster-cpu-usage                            23m
cluster-cpu-usage-raw                        23m
cluster-cpu-utilization                      23m
cluster-memory-capacity                      23m
cluster-memory-capacity-raw                  23m
cluster-memory-usage                         23m
cluster-memory-usage-raw                     23m
cluster-memory-utilization                   23m
cluster-persistentvolumeclaim-request        23m
namespace-cpu-request                        23m
namespace-cpu-usage                          23m
namespace-cpu-utilization                    23m
namespace-memory-request                     23m
namespace-memory-usage                       23m
namespace-memory-utilization                 23m
namespace-persistentvolumeclaim-request      23m
namespace-persistentvolumeclaim-usage        23m
node-cpu-allocatable                         23m
node-cpu-allocatable-raw                     23m
node-cpu-capacity                            23m
node-cpu-capacity-raw                        23m
node-cpu-utilization                         23m
node-memory-allocatable                      23m
node-memory-allocatable-raw                  23m
node-memory-capacity                         23m
node-memory-capacity-raw                     23m
node-memory-utilization                      23m
persistentvolumeclaim-capacity               23m
persistentvolumeclaim-capacity-raw           23m
persistentvolumeclaim-phase-raw              23m
persistentvolumeclaim-request                23m
persistentvolumeclaim-request-raw            23m
persistentvolumeclaim-usage                  23m
persistentvolumeclaim-usage-raw              23m
persistentvolumeclaim-usage-with-phase-raw   23m
pod-cpu-request                              23m
pod-cpu-request-raw                          23m
pod-cpu-usage                                23m
pod-cpu-usage-raw                            23m
pod-memory-request                           23m
pod-memory-request-raw                       23m
pod-memory-usage                             23m
pod-memory-usage-raw                         23m

-raw 接尾辞のあるレポートクエリーは、より複雑なクエリーを作成するために他の ReportQuery によって使用されます。これらはレポートに直接使用できません。

namespace- の接頭辞が付けられたクエリーは namespace 別に Pod CPU およびメモリー要求を集計し、リソース要求に基づいて namespace およびそれらの全体の使用状況の一覧を提供します。

pod- の接頭辞が付けられたクエリーは namespace- の接頭辞が付けられたクエリーと同様ですが、情報を namespace 別ではなく Pod 別に集計します。これらのクエリーには、Pod の namespace およびノードが含まれます。

node- の接頭辞が付けられたクエリーは各ノードの利用可能な合計リソースについての情報を返します。

aws- の接頭辞が付けられたクエリーは AWS に固有のものです。aws の接尾辞が付けられたクエリーは、接尾辞なしの同じ名前のクエリーと同じデータを返し、使用状況を EC2 請求データに関連付けます。

aws-ec2-billing-data レポートは他のクエリーによって使用され、スタンドアロンのレポートとしては使用できません。aws-ec2-cluster-cost レポートは、クラスターに含まれるノードに基づく総コストと、レポート期間のコストの合計を提供します。

以下のコマンドを使用して ReportQuery リソースを YAML として取得し、spec.columns フィールドを確認します。たとえば、以下を実行します。

$ oc -n openshift-metering get reportqueries namespace-memory-request -o yaml

出力例

apiVersion: metering.openshift.io/v1
kind: ReportQuery
metadata:
  name: namespace-memory-request
  labels:
    operator-metering: "true"
spec:
  columns:
  - name: period_start
    type: timestamp
    unit: date
  - name: period_end
    type: timestamp
    unit: date
  - name: namespace
    type: varchar
    unit: kubernetes_namespace
  - name: pod_request_memory_byte_seconds
    type: double
    unit: byte_seconds

5.1.1.4. schedule

spec.schedule 設定ブロックは、レポートが実行される時を定義します。schedule セクションの主なフィールドは period であり、period の値によって、hourlydailyweekly、および monthly フィールドでレポートが実行されるタイミングをさらに調整できます。

たとえば、periodweekly に設定されている場合、weekly フィールドを spec.schedule ブロックに追加できます。以下の例は、週ごとに毎週水曜日の 1 pm (hour 13) に実行されます。

...
  schedule:
    period: "weekly"
    weekly:
      dayOfWeek: "wednesday"
      hour: 13
...
5.1.1.4.1. period

schedule.period の有効な値が以下に一覧表示されており、特定の期間に設定できる選択可能なオプションも一覧表示されています。

  • hourly

    • minute
    • second
  • daily

    • hour
    • minute
    • second
  • weekly

    • dayOfWeek
    • hour
    • minute
    • second
  • monthly

    • dayOfMonth
    • hour
    • minute
    • second
  • cron

    • expression

通常、hourminutesecond フィールドは 1 日のどの時間にレポートが実行されるかを制御し、dayOfWeek/dayOfMonth は、レポートの期間が週または月ごとに区切られている場合にレポートが実行される曜日または日を制御します。

上記の各フィールドには、有効な値の範囲があります。

  • hour は 0-23 の整数値です。
  • minute は 0-59 の整数値です。
  • second は 0-59 の整数値です。
  • dayOfWeek は曜日が入ることが予想される文字列の値です (略さずに入力します)。
  • dayOfMonth は 1-31 の整数値です。

cron 期間については、通常の cron 式は有効です。

  • expression: "*/5 * * * *"

5.1.1.5. reportingStart

既存データに対するレポートの実行をサポートするには、spec.reportingStart フィールドを RFC3339 タイムスタンプ に設定し、レポートが現在の時間ではなく、reportingStart から始まる schedule に基づいて実行するように指示します。

注記

spec.reportingStart フィールドを特定の時間に設定すると、レポート Operator が reportingStart の時間から現在の時間までの間のスケジュール期間に連続して多数のクエリーを実行する可能性があります。レポート期間が日次よりも短く区切られ、reportingStart が数ヶ月前に遡る場合、クエリーの数は数千に上る可能性があります。reportingStart が未設定のままの場合、レポートはレポート作成後の次の reportingPeriod 全体で実行されます。

このフィールドの使い方を示す一例として、Report オブジェクトに組み込む必要のある 2019 年月 1 日まで遡ったデータをすでに収集している場合、以下の値を使用してレポートを作成できます。

apiVersion: metering.openshift.io/v1
kind: Report
metadata:
  name: pod-cpu-request-hourly
spec:
  query: "pod-cpu-request"
  schedule:
    period: "hourly"
  reportingStart: "2019-01-01T00:00:00Z"

5.1.1.6. reportingEnd

指定された時点までのみ実行されるようにレポートを設定するには、spec.reportingEnd フィールドを RFC3339 タイムスタンプ に設定できます。このフィールドの値により、レポートは開始時点から reportingEnd までの期間のレポートデータの生成の終了後にスケジュールに基づいて実行を停止します。

スケジュールと reportingEnd は連動しない場合が多いため、スケジュールの最終期間は指定の reportingEnd 時間に終了するように短縮されます。これが未設定のままの場合、レポートは永久に実行されるか、または reportingEnd がレポートに設定されるまで実行されます。

たとえば、7 月に週 1 回実行されるレポートを作成する場合は、以下のようになります。

apiVersion: metering.openshift.io/v1
kind: Report
metadata:
  name: pod-cpu-request-hourly
spec:
  query: "pod-cpu-request"
  schedule:
    period: "weekly"
  reportingStart: "2019-07-01T00:00:00Z"
  reportingEnd: "2019-07-31T00:00:00Z"

5.1.1.7. runImmediately

runImmediatelytrue に設定すると、レポートは即座に実行されます。この動作により、追加のスケジューリングパラメーターなしにレポートが即座に処理され、キューに入れられます。

注記

runImmediatelytrue に設定されている場合、reportingEnd および reportingStart の値を設定する必要があります。

5.1.1.8. inputs

Report オブジェクトの spec.inputs フィールドは、 ReportQuery リソースの spec.inputs フィールドで定義された値を上書きまたは設定するために使用できます。

spec.inputs は名前と値のペアの一覧です。

spec:
  inputs:
  - name: "NamespaceCPUUsageReportName" 1
    value: "namespace-cpu-usage-hourly" 2
1
inputs の name は ReportQuery の inputs 一覧に存在している必要があります。
2
inputs の value は inputs の type に適切なタイプである必要があります。

5.1.1.9. ロールアップレポート

レポートデータはメトリクス自体と同様にデータベースに保存されるため、集計またはロールアップレポートで使用できます。ロールアップレポートの単純なユースケースとして、レポートの作成に必要な時間をより長い期間にわたって分散します。これにより、クエリーし、1 カ月全体でのすべてのデータを追加する月次レポートは不要になります。たとえば、タスクは、それぞれがデータの 1/30 に対して実行される日次レポートに分割できます。

カスタムのロールアップレポートには、カスタムレポートクエリーが必要です。ReportQuery リソーステンプレートプロセッサーは、Report オブジェクトの metadata.name から必要なテーブル名を取得できる reportTableName 機能を提供します。

以下は、組み込みクエリーのスニペットです。

pod-cpu.yaml

spec:
...
  inputs:
  - name: ReportingStart
    type: time
  - name: ReportingEnd
    type: time
  - name: NamespaceCPUUsageReportName
    type: Report
  - name: PodCpuUsageRawDataSourceName
    type: ReportDataSource
    default: pod-cpu-usage-raw
...

  query: |
...
    {|- if .Report.Inputs.NamespaceCPUUsageReportName |}
      namespace,
      sum(pod_usage_cpu_core_seconds) as pod_usage_cpu_core_seconds
    FROM {| .Report.Inputs.NamespaceCPUUsageReportName | reportTableName |}
...

aggregated-report.yaml ロールアップレポートの例

spec:
  query: "namespace-cpu-usage"
  inputs:
  - name: "NamespaceCPUUsageReportName"
    value: "namespace-cpu-usage-hourly"

5.1.1.9.1. レポートのステータス

スケジュールされたレポートの実行は、status フィールドを使用して追跡できます。レポートの作成中に発生したエラーはここに記録されます。

現時点で Report オブジェクトの status フィールドには 2 つのフィールドがあります。

  • conditions: これは、それぞれに typestatusreason、および message フィールドのある状態についての一覧です。状態の type フィールドに使用できる値は Running および Failure であり、スケジュールされたレポートの現在の状態を示します。reason は、conditiontruefalse または、unknown のいずれかの status で示される現在の状態にある理由を示します。message は、condition が現在の状態にある理由についての人が判別できる情報を提供します。reason の値の詳細情報については、pkg/apis/metering/v1/util/report_util.go を参照してください。
  • lastReportTime: メータリングが最後にデータを収集した時を示します。