第5章 Report
5.1. Report について
メータリングは非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。
OpenShift Container Platform で非推奨となったか、または削除された主な機能の最新の一覧については、OpenShift Container Platform リリースノートの 非推奨および削除された機能セクションを参照してください。
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
の値によって、hourly
、daily
、weekly
、および monthly
フィールドでレポートが実行されるタイミングをさらに調整できます。
たとえば、period
が weekly
に設定されている場合、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
-
通常、hour
、minute
、second
フィールドは 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. expiration
expiration
フィールドを追加して、スケジュールされるメータリングレポートに保持期間を設定します。expiration
期間の値を設定すると、レポートを手動で削除することを避けることができます。保持期間はレポートの Report
オブジェクトの creationDate
に expiration
を加えた期間と等しくなります。レポートまたはレポートクエリーが期限切れのレポートに依存しない場合、レポートが保持期間の終了時にクラスターから削除されます。レポートをクラスターから削除するには数分の時間がかかる場合があります。
ロールアップまたは集計レポートに expiration
フィールドを設定することは推奨されません。他のレポートまたはレポートクエリーがレポートに依存する場合、そのレポートは保持期間の終了時に削除されません。レポート保持の決定に関連したタイミングの出力についてデバッグレベルで report-operator
ログを表示できます。
たとえば、以下のスケジュールされたレポートは、レポートの creationDate
の 30 秒後に削除されます。
apiVersion: metering.openshift.io/v1
kind: Report
metadata:
name: pod-cpu-request-hourly
spec:
query: "pod-cpu-request"
schedule:
period: "weekly"
reportingStart: "2020-09-01T00:00:00Z"
expiration: "30m" 1
- 1
expiration
期間の有効な時間単位は、ns
、us
(またはµs
)、ms
、s
、m
、およびh
です。
Report
オブジェクトの expiration
保持期間は厳密ではなく、(ナノ秒ではなく) 数分間隔の順序で機能します。
5.1.1.8. runImmediately
runImmediately
を true
に設定すると、レポートは即座に実行されます。この動作により、追加のスケジューリングパラメーターなしにレポートが即座に処理され、キューに入れられます。
runImmediately
が true
に設定されている場合、reportingEnd
および reportingStart
の値を設定する必要があります。
5.1.1.9. inputs
Report
オブジェクトの spec.inputs
フィールドは、 ReportQuery
リソースの spec.inputs
フィールドで定義された値を上書きまたは設定するために使用できます。
spec.inputs
は名前と値のペアの一覧です。
spec: inputs: - name: "NamespaceCPUUsageReportName" 1 value: "namespace-cpu-usage-hourly" 2
5.1.1.10. ロールアップレポート
レポートデータはメトリクス自体と同様にデータベースに保存されるため、集計またはロールアップレポートで使用できます。ロールアップレポートの単純なユースケースとして、レポートの作成に必要な時間をより長い期間にわたって分散します。これにより、クエリーし、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.10.1. レポートのステータス
スケジュールされたレポートの実行は、status フィールドを使用して追跡できます。レポートの作成中に発生したエラーはここに記録されます。
現時点で Report
オブジェクトの status
フィールドには 2 つのフィールドがあります。
-
conditions
: これは、それぞれにtype
、status
、reason
、およびmessage
フィールドのある状態についての一覧です。状態のtype
フィールドに使用できる値はRunning
およびFailure
であり、スケジュールされたレポートの現在の状態を示します。reason
は、condition
がtrue
、false
または、unknown
のいずれかのstatus
で示される現在の状態にある理由を示します。message
は、condition が現在の状態にある理由についての人が判別できる情報を提供します。reason
の値の詳細情報については、pkg/apis/metering/v1/util/report_util.go
を参照してください。 -
lastReportTime
: メータリングが最後にデータを収集した時を示します。