5장. Reports
5.1. 보고서 정보
미터링은 더 이상 사용되지 않는 기능입니다. 더 이상 사용되지 않는 기능은 여전히 OpenShift Container Platform에 포함되어 있으며 계속 지원됩니다. 그러나 이 기능은 향후 릴리스에서 제거될 예정이므로 새로운 배포에는 사용하지 않는 것이 좋습니다.
OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.
Report
사용자 정의 리소스는 SQL 쿼리를 사용하여 주기적인 ETL(Extract Transform and Load) 작업을 관리하는 방법을 제공합니다. Report는 실행할 실제 SQL 쿼리를 제공하는 ReportQuery
리소스와 ReportQuery
및 Report
리소스에 사용할 수 있는 데이터를 정의하는 ReportDataSource
리소스 등의 기타 미터링 리소스로 구성됩니다.
많은 사용 사례는 미터링과 함께 설치된 사전 정의된 ReportQuery
및 ReportDataSource
리소스에서 처리합니다. 따라서 이러한 사전 정의된 리소스에서 다루지 않는 사용 사례가 없는 한 자체를 정의할 필요가 없습니다.
5.1.1. Reports
Report
사용자 정의 리소스는 보고서 실행 및 상태를 관리하는 데 사용됩니다. 미터링은 사용 데이터 소스에서 파생되며 추가 분석 및 필터링에 사용될 수 있습니다. 단일 Report
리소스는 데이터베이스 테이블을 관리하고 스케줄에 따라 새 정보로 업데이트하는 작업을 나타냅니다. Report는 Reporting Operator HTTP API를 통해 해당 테이블에 데이터를 노출합니다.
spec.schedule
필드 집합을 사용하는 Report는 항상 실행 중이고 데이터 수집 기간을 추적합니다. 이를 통해 미터링이 종료되거나 연장된 기간에 사용할 수 없는 경우 데이터가 해제된 위치에서 백필링됩니다. 일정이 설정되지 않으면 reportingStart
및 reportingEnd
에서 지정한 시간 동안 보고서가 한 번 실행됩니다. 기본적으로 보고서는 ReportDataSource
리소스가 보고 기간에 적용되는 모든 데이터를 완전히 가져올 때까지 기다립니다. 보고서에 일정이 있는 경우 현재 처리 중인 기간에 데이터의 가져오기가 완료될 때까지 실행을 기다립니다.
5.1.1.1. 일정이 있는 보고서의 예
다음 예제 Report
오브젝트에는 모든 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" schedule: period: "hourly" hourly: minute: 0 second: 0
5.1.1.2. 일정이 없는 보고서의 예(한 번 실행)
다음 예제 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
접미사가 있는 Report 쿼리는 다른 ReportQuery
리소스에서 더 복잡한 쿼리를 빌드하기 위해 사용되며 보고서에는 직접 사용해서는 안 됩니다.
namespace-
접두사가 지정된 쿼리에서는 네임스페이스별 Pod CPU 및 메모리 요청을 집계하여 네임스페이스 목록과 리소스 요청에 따른 전체 사용량을 제공합니다.
pod-
접두사가 지정된 쿼리는 namespace-
접두사가 지정된 쿼리와 유사하지만 네임스페이스가 아닌 Pod별 정보를 집계합니다. 이러한 쿼리에는 Pod의 네임스페이스와 노드가 포함됩니다.
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. 일정
spec.schedule
설정 블록은 보고서 실행 시기를 정의합니다. schedule
섹션의 주요 필드는 period
이며 period
의 값에 따라 hourly
, daily
, weekly
, monthly
필드를 통해 보고서 실행 시기를 미세 조정할 수 있습니다.
예를 들어 period
이 weekly
으로 설정되어 있으면 spec.schedule
블록에 weekly
필드를 추가할 수 있습니다. 다음 예는 수요일 오후 1시(하루 중 13시)에 일주일에 한 번 실행됩니다.
... schedule: period: "weekly" weekly: dayOfWeek: "wednesday" hour: 13 ...
5.1.1.4.1. 기간
schedule.period
의 유효한 값은 아래에 나열되며, 지정된 기간에 설정할 수 있는 옵션도 나열됩니다.
hourly
-
minute
-
second
-
daily
-
hour
-
minute
-
second
-
weekly
-
dayOfWeek
-
hour
-
minute
-
second
-
monthly
-
dayOfMonth
-
hour
-
minute
-
second
-
cron
-
expression
-
일반적으로 hour
, minute
, second
필드는 보고서를 실행한 날을 제어하며 주간 또는 월간 보고 기간인 경우 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.reportingstartt
필드를 RFC3339 타임 스탬프로 설정하여 현재 시간 대신 reportingStart
에서 시작되는 schedule
에 따라 Report가 실행되도록 지시할 수 있습니다.
spec.reportingStart
필드를 특정 시간으로 설정하면 Reporting Operator가 reportingStart
시간과 현재 시간 사이에 있는 일정의 각 간격에 대해 많은 쿼리가 연속으로 실행됩니다. 이는 기간이 일별보다 적고 보고 reportingStart
가 몇 개월 전보다 많은 경우 수천 개의 쿼리가 될 수 있습니다. reportingStart
가 설정되지 않은 경우 보고서가 생성된 후 Report가 다음 전체 reportingPeriod
에서 실행됩니다.
이 필드를 사용하는 방법의 예로서, Report
오브젝트에 포함하려는 2019년 1월 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
기간 값을 설정하여 보고서를 수동으로 제거하는 것을 방지할 수 있습니다. 보존 기간은 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. 입력
Report
오브젝트의 spec.inputs
필드를 사용하여 ReportQuery
리소스의 spec.inputs
필드에 정의된 값을 덮어쓰거나 설정할 수 있습니다.
spec.inputs
는 이름-값 쌍의 목록입니다.
spec: inputs: - name: "NamespaceCPUUsageReportName" 1 value: "namespace-cpu-usage-hourly" 2
5.1.1.10. 롤업 보고서
보고서 데이터는 메트릭 자체와 마찬가지로 데이터베이스에 저장되므로 집계 또는 롤업 보고서에 사용할 수 있습니다. 롤업 보고서의 간단한 사용 사례는 장기간에 걸쳐 보고서를 생성하는 데 필요한 시간을 분산하는 것입니다. 이는 월별 보고서를 사용하여 한 달에 걸쳐 모든 데이터를 쿼리하고 추가하는 대신 사용됩니다. 예를 들어, 작업은 각각 데이터의 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. 보고서 상태
예약된 보고서의 실행은 상태 필드를 사용하여 추적할 수 있습니다. 보고서를 준비하는 동안 발생한 오류는 여기에 기록됩니다.
현재 Report
오브젝트의 status
필드에는 두 개의 필드가 있습니다.
-
조건
: conditions는 조건 목록으로, 각각type
,status
,reason
및message
필드가 있습니다. 조건type
필드의 가능한 값은Running
및Failure
이며 예약된 보고서의 현재 상태를 나타냅니다.reason
은 해당condition
이true
,false
또는unknown
인 상태와 함께 현재status
에 있는 이유를 나타냅니다.message
는 해당 조건이 현재 상태에 있는 이유를 나타내는, 사람이 읽을 수 있는 정보를 제공합니다.reason
값에 대한 자세한 정보는pkg/apis/metering/v1/util/report_util.go
를 참조하십시오. -
lastReportTime
: 미터링이 최대 데이터를 수집한 시간을 나타냅니다.