Service Telemetry Framework 1.4
Service Telemetry Framework 1.4 설치 및 배포
OpenStack Documentation Team
rhos-docs@redhat.com초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견을 보내 주십시오. 우리가 어떻게 그것을 더 잘 만들 수 있는지 알려주십시오.
Direct Documentation feedback(DDF) 함수 사용
특정 문장, 단락 또는 코드 블록에 대한 직접 코멘트를 위해서는 DDF 함수 추가 를 사용하십시오.
- Multi-page HTML 형식으로 설명서를 확인합니다.
- 문서의 오른쪽 위에 사용자 지정 단추가 표시되는지 확인합니다.Ensure that you see the Feedback button in the upper right corner of the document.
- 주석하려는 텍스트 부분을 강조 표시합니다.
- 피드백 추가를 클릭합니다.
- 코멘트와 함께 피드백 추가 필드를 완료합니다.
- 선택 사항: 문서 팀에서 문제 해결을 위해 연락할 수 있도록 이메일 주소를 추가하십시오.
- 제출을 클릭합니다.
1장. Service Telemetry Framework {TargetVersion} 소개
Service Telemetry Framework(STF)는 RHOSP(Red Hat OpenStack Platform) 또는 타사 노드에서 모니터링 데이터를 수집합니다. STF를 사용하여 다음 작업을 수행할 수 있습니다.
- 기록 정보를 위해 모니터링 데이터를 저장하거나 보관합니다.
- 대시보드에서 그래픽으로 모니터링 데이터를 확인합니다.
- 모니터링 데이터를 사용하여 경고 또는 경고를 트리거합니다.
모니터링 데이터는 메트릭 또는 이벤트일 수 있습니다.
- 메트릭
- 애플리케이션 또는 시스템의 숫자 측정입니다.
- event
- 시스템에서 발생하는 열렬 및 개별 이벤트입니다.
STF 구성 요소는 데이터 전송을 위해 메시지 버스를 사용합니다. 데이터를 수신하고 저장하는 기타 모듈식 구성 요소는 Red Hat OpenShift Container Platform에 컨테이너로 배포됩니다.
STF(Service Telemetry Framework)는 Red Hat OpenShift Container Platform 버전 4.10~4.10과 호환됩니다.
추가 리소스
- Red Hat OpenShift Container Platform 배포 방법에 대한 자세한 내용은 Red Hat OpenShift Container Platform 제품 설명서를 참조하십시오.
- 클라우드 플랫폼 또는 베어 메탈에 Red Hat OpenShift Container Platform을 설치할 수 있습니다. STF 성능 및 스케일링에 대한 자세한 내용은 https://access.redhat.com/articles/4907241 을 참조하십시오.
- 베어메탈 또는 기타 지원되는 클라우드 플랫폼에 Red Hat OpenShift Container Platform을 설치할 수 있습니다. Red Hat OpenShift Container Platform 설치에 대한 자세한 내용은 OpenShift Container Platform 4.10 문서를 참조하십시오.
1.1. Service Telemetry Framework 지원
Red Hat은 두 가지 최신 버전의 Service Telemetry Framework(STF)를 지원합니다. 이전 버전은 지원되지 않습니다. 자세한 내용은 Service Telemetry Framework 지원 버전 매트릭스 를 참조하십시오.
Red Hat은 AMQ Interconnect, AMQ Certificate Manager, Service Telemetry Operator 및 Smart Gateway Operator를 비롯한 핵심 Operator 및 워크로드를 지원합니다. Red Hat은 Elasticsearch, Prometheus, Alertmanager, Grafana 및 해당 Operator와 같은 커뮤니티 Operator 또는 워크로드 구성 요소를 지원하지 않습니다.
완전히 연결된 네트워크 환경에서 STF만 배포할 수 있습니다. Red Hat OpenShift Container Platform이 연결되지 않은 환경 또는 네트워크 프록시 환경에 STF를 배포할 수 없습니다.
1.2. Service Telemetry Framework 아키텍처
Service Telemetry Framework(STF)는 클라이언트-서버 아키텍처를 사용하며 이 아키텍처는 RHOSP(Red Hat OpenStack Platform)가 클라이언트이고 Red Hat OpenShift Container Platform은 서버입니다.
STF는 다음 구성 요소로 구성됩니다.
데이터 수집
- collectd: 인프라 지표 및 이벤트를 수집합니다.
- Ceilometer: RHOSP 지표 및 이벤트를 수집합니다.
전송
- AMQ Interconnect: 스토리지를 위해 메트릭을 STF로 전송하기 위해 빠르고 안정적인 데이터 전송을 제공하는 AMQP 1.x 호환 메시징 버스.
- 스마트 게이트웨이: AMQP 1.x 버스에서 지표 및 이벤트를 가져와서 ElasticSearch 또는 Prometheus에 제공하는 Golang 애플리케이션입니다.
데이터 스토리지
- Prometheus: Smart Gateway에서 수신한 STF 지표를 저장하는 시계열 데이터 스토리지입니다.
- ElasticSearch: Smart Gateway에서 수신한 STF 이벤트를 저장하는 이벤트 데이터 스토리지입니다.
정체제
- Alertmanager: Prometheus 경고 규칙을 사용하여 경고를 관리하는 경고 툴입니다.
- Grafana: 데이터를 쿼리, 시각화 및 탐색하는 데 사용할 수 있는 시각화 및 분석 애플리케이션입니다.
다음 표에서는 클라이언트 및 서버 구성 요소의 애플리케이션을 설명합니다.
표 1.1. STF의 클라이언트 및 서버 구성 요소
| 구성 요소 | 클라이언트 | 서버 |
|---|---|---|
| AMQP 1.x 호환 메시징 버스 | 제공됨 | 제공됨 |
| 스마트 게이트웨이 | 제공되지 않음 | 제공됨 |
| Prometheus | 제공되지 않음 | 제공됨 |
| ElasticSearch | 제공되지 않음 | 제공됨 |
| collectd | 제공됨 | 제공되지 않음 |
| Ceilometer | 제공됨 | 제공되지 않음 |
모니터링 플랫폼이 클라우드의 운영 문제를 보고할 수 있도록 모니터링 중인 인프라와 동일한 인프라에 STF를 설치하지 마십시오.
그림 1.1. Service Telemetry Framework 아키텍처 개요

클라이언트 측 메트릭의 경우 collectd는 프로젝트 데이터 없이 인프라 지표를 제공하며, Ceilometer에서는 프로젝트 또는 사용자 워크로드를 기반으로 RHOSP 플랫폼 데이터를 제공합니다. Ceilometer 및 collectd 둘 다 AMQ Interconnect 전송을 사용하여 Prometheus에 데이터를 제공하여 메시지 버스를 통해 데이터를 전달합니다. 서버 측에서 Smart Gateway라는 Golang 애플리케이션은 버스의 데이터 스트림을 가져와서 Prometheus의 로컬 스크랩 끝점으로 노출합니다.
이벤트를 수집하고 저장하려는 경우 collectd 및 Ceilometer는 AMQ Interconnect 전송을 사용하여 서버 측에 이벤트 데이터를 전달합니다. 또 다른 Smart Gateway는 데이터를 ElasticSearch 데이터 저장소에 씁니다.
서버 측 STF 모니터링 인프라는 다음 계층으로 구성됩니다.
- 서비스 원격 분석 프레임워크 1.5
- Red Hat OpenShift Container Platform 4.10 ~ 4.10
- 인프라 플랫폼
그림 1.2. 서버 측 STF 모니터링 인프라

1.3. Red Hat OpenShift Container Platform의 설치 크기
Red Hat OpenShift Container Platform 설치 크기는 다음과 같은 요인에 따라 달라집니다.
- 선택한 인프라입니다.
- 모니터링할 노드 수입니다.
- 수집할 메트릭 수입니다.
- 지표의 해상도입니다.
- 데이터를 저장할 시간입니다.
Service Telemetry Framework(STF) 설치는 기존 Red Hat OpenShift Container Platform 환경에 따라 다릅니다.
baremetal에 Red Hat OpenShift Container Platform을 설치할 때 최소 리소스 요구 사항에 대한 자세한 내용은 베어 메탈에 클러스터 설치 가이드의 최소 리소스 요구 사항을 참조하십시오. 설치할 수 있는 다양한 퍼블릭 및 프라이빗 클라우드 플랫폼의 설치 요구 사항은 클라우드 플랫폼의 해당 설치 설명서를 참조하십시오.
2장. Service Telemetry Framework를 위한 Red Hat OpenShift Container Platform 환경 준비
STF(Service Telemetry Framework)를 위한 Red Hat OpenShift Container Platform 환경을 준비하려면 영구 스토리지, 적절한 리소스, 이벤트 스토리지 및 네트워크 고려 사항을 계획해야 합니다.
- 프로덕션 등급 배포를 위해 Red Hat OpenShift Container Platform 클러스터에서 사용 가능한 영구 스토리지가 있는지 확인합니다. 자세한 내용은 2.2절. “PV(영구 볼륨)”의 내용을 참조하십시오.
- Operator 및 애플리케이션 컨테이너를 실행하는 데 사용할 수 있는 충분한 리소스가 있는지 확인합니다. 자세한 내용은 2.3절. “리소스 할당”의 내용을 참조하십시오.
- 완전히 연결된 네트워크 환경이 있는지 확인합니다. 자세한 내용은 2.4절. “Service Telemetry Framework에 대한 네트워크 고려 사항”의 내용을 참조하십시오.
2.1. Service Telemetry Framework의 관찰 전략
Service Telemetry Framework (STF)에는 스토리지 백엔드 및 경고 도구가 포함되어 있지 않습니다. STF는 커뮤니티 운영자를 사용하여 Prometheus, Alertmanager, Grafana 및 Elasticsearch를 배포합니다. STF는 이러한 커뮤니티 운영자에 요청하여 STF와 함께 작동하도록 구성된 각 애플리케이션의 인스턴스를 만듭니다.
Service Telemetry Operator가 사용자 정의 리소스 요청을 생성하는 대신 이러한 애플리케이션 또는 기타 호환 애플리케이션의 자체 배포를 사용하고 Telemetry 스토리지를 위해 자체 Prometheus 호환 시스템으로 제공하기 위해 지표 Smart Gateway를 스크랩할 수 있습니다. 대신 대체 백엔드를 사용하도록 관찰 기능을 설정하는 경우 STF에 영구 또는 임시 스토리지가 필요하지 않습니다.
2.2. PV(영구 볼륨)
Service Telemetry Framework(STF)는 Red Hat OpenShift Container Platform의 영구 스토리지를 사용하여 Prometheus 및 ElasticSearch가 메트릭 및 이벤트를 저장할 수 있도록 영구 볼륨을 요청합니다.
Service Telemetry Operator를 통해 영구 스토리지를 활성화하면 STF 배포에 요청된 PVC(영구 볼륨 클레임)가 있으면 RWO(ReadWriteOnce)의 액세스 모드가 됩니다. 환경에 사전 프로비저닝된 영구 볼륨이 포함된 경우 Red Hat OpenShift Container Platform 기본 구성된 storageClass 에서 RWO 볼륨을 사용할 수 있는지 확인하십시오.
추가 리소스
- Red Hat OpenShift Container Platform의 영구 스토리지 구성에 대한 자세한 내용은 영구 스토리지 이해를 참조하십시오.
- Red Hat OpenShift Container Platform에서 권장되는 구성 가능한 스토리지 기술에 대한 자세한 내용은 권장 설정 가능한 스토리지 기술을 참조하십시오.
- STF에서 Prometheus의 영구 스토리지 구성에 대한 자세한 내용은 “Prometheus의 영구 스토리지 구성” 을 참조하십시오.
- STF에서 ElasticSearch에 대한 영구 스토리지 구성에 대한 자세한 내용은 “ElasticSearch의 영구 스토리지 구성” 을 참조하십시오.
2.2.1. 임시 스토리지
임시 스토리지를 사용하여 Red Hat OpenShift Container Platform 클러스터에 데이터를 지속적으로 저장하지 않고도 Service Telemetry Framework (STF)를 실행할 수 있습니다.
임시 스토리지를 사용하는 경우 Pod가 다른 노드에 다시 시작, 업데이트 또는 다시 예약되면 데이터 손실이 발생할 수 있습니다. 프로덕션 환경이 아닌 개발 또는 테스트에만 임시 스토리지를 사용합니다.
2.3. 리소스 할당
Red Hat OpenShift Container Platform 인프라 내에서 Pod 예약을 활성화하려면 실행 중인 구성 요소의 리소스가 필요합니다. 충분한 리소스를 할당하지 않으면 Pod를 예약할 수 없기 때문에 Pending 상태로 유지됩니다.
Service Telemetry Framework(STF)를 실행하는 데 필요한 리소스의 양은 환경과 모니터링할 노드 및 클라우드 수에 따라 다릅니다.
추가 리소스
- 메트릭 컬렉션의 크기 조정에 대한 권장 사항은 Service Telemetry Framework Performance and Scaling을 참조하십시오.
- ElasticSearch의 크기 조정 요구 사항에 대한 자세한 내용은 https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-managing-compute-resources.html 을 참조하십시오.
2.4. Service Telemetry Framework에 대한 네트워크 고려 사항
완전히 연결된 네트워크 환경에서 Service Telemetry Framework(STF)만 배포할 수 있습니다. Red Hat OpenShift Container Platform이 연결되지 않은 환경 또는 네트워크 프록시 환경에 STF를 배포할 수 없습니다.
3장. Service Telemetry Framework의 핵심 구성 요소 설치
Operator를 사용하여STF(Service Telemetry Framework) 구성 요소 및 오브젝트를 로드할 수 있습니다. Operator는 다음 STF 코어 및 커뮤니티 구성 요소를 각각 관리합니다.
- AMQ Interconnect
- 스마트 게이트웨이
- Prometheus 및 AlertManager
- elasticsearch
- Grafana
사전 요구 사항
- 4.10에서 4.10까지 포함된 Red Hat OpenShift Container Platform 버전이 실행 중입니다.
- Red Hat OpenShift Container Platform 환경을 준비하고 Red Hat OpenShift Container Platform 환경에서 STF 구성 요소를 실행할 수 있는 영구 스토리지와 충분한 리소스가 있는지 확인합니다. 자세한 내용은 Service Telemetry Framework Performance and Scaling을 참조하십시오.
- 환경이 완전히 연결되어 있습니다. STF는 Red Hat OpenShift Container Platform에 연결되지 않은 환경 또는 네트워크 프록시 환경에서 작동하지 않습니다.
STF는 Red Hat OpenShift Container Platform 버전 4.10에서 4.10과 호환됩니다.
추가 리소스
- Operator에 대한 자세한 내용은 Operator 이해 가이드를 참조하십시오.
- Red Hat OpenShift Container Platform 환경에서 STF를 제거하는 방법에 대한 자세한 내용은 7장. Red Hat OpenShift Container Platform 환경에서 Service Telemetry Framework 제거 을 참조하십시오.
3.1. Red Hat OpenShift Container Platform 환경에 Service Telemetry Framework 배포
Service Telemetry Framework (STF)를 배포하여 이벤트를 수집, 저장 및 모니터링합니다.
절차
STF 구성 요소(예:
service-telemetry)를 포함할 네임스페이스를 생성합니다.$ oc new-project service-telemetry
Operator Pod를 예약할 수 있도록 네임스페이스에 OperatorGroup을 생성합니다.
$ oc create -f - <<EOF apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: service-telemetry-operator-group namespace: service-telemetry spec: targetNamespaces: - service-telemetry EOF
자세한 내용은 OperatorGroups 를 참조하십시오.
OperatorHub.io 커뮤니티 카탈로그 소스를 활성화하여 데이터 스토리지 및 시각화 Operator를 설치합니다.
주의Red Hat은 AMQ Interconnect, AMQ Certificate Manager, Service Telemetry Operator 및 Smart Gateway Operator를 비롯한 핵심 Operator 및 워크로드를 지원합니다. Red Hat은 ElasticSearch, Prometheus, Alertmanager, Grafana 및 해당 Operator를 포함하여 커뮤니티 Operator 또는 워크로드 구성 요소를 지원하지 않습니다.
$ oc create -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: operatorhubio-operators namespace: openshift-marketplace spec: sourceType: grpc image: quay.io/operatorhubio/catalog:latest displayName: OperatorHub.io Operators publisher: OperatorHub.io EOF
redhat-operators CatalogSource를 사용하여 AMQ Certificate Manager Operator에 등록합니다.
참고AMQ Certificate Manager는
openshift-operators네임스페이스에 배포되고 클러스터 전체의 모든 네임스페이스에서 사용할 수 있습니다. 결과적으로 네임스페이스가 많은 클러스터에서는service-telemetry네임스페이스에서 Operator를 사용할 수 있는 데 몇 분이 걸릴 수 있습니다. AMQ Certificate Manager Operator는 다른 네임스페이스 범위 Operator와 함께 사용할 때 Operator Lifecycle Manager의 종속성 관리와 호환되지 않습니다.$ oc create -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: amq7-cert-manager-operator namespace: openshift-operators spec: channel: 1.x installPlanApproval: Automatic name: amq7-cert-manager-operator source: redhat-operators sourceNamespace: openshift-marketplace EOF
ClusterServiceVersion을 검증합니다. amq7-cert-manager.v1.0.3에
Succeeded단계가 표시되는지 확인합니다.$ oc get csv --namespace openshift-operators --selector operators.coreos.com/amq7-cert-manager-operator.openshift-operators NAME DISPLAY VERSION REPLACES PHASE amq7-cert-manager.v1.0.3 Red Hat Integration - AMQ Certificate Manager 1.0.3 amq7-cert-manager.v1.0.2 Succeeded
redhat-operators CatalogSource를 사용하여 AMQ Interconnect Operator를 구독합니다.
$ oc create -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: amq7-interconnect-operator namespace: service-telemetry spec: channel: 1.10.x installPlanApproval: Automatic name: amq7-interconnect-operator source: redhat-operators sourceNamespace: openshift-marketplace EOF
ClusterServiceVersion을 검증합니다. amq7-interconnect-operator.v1.10.4에
Succeeded단계가 표시되는지 확인합니다.$ oc get csv --selector=operators.coreos.com/amq7-interconnect-operator.service-telemetry NAME DISPLAY VERSION REPLACES PHASE amq7-interconnect-operator.v1.10.4 Red Hat Integration - AMQ Interconnect 1.10.4 amq7-interconnect-operator.v1.10.3 Succeeded
Prometheus에 지표를 저장하려면 Prometheus Operator를 활성화해야 합니다. Prometheus Operator를 활성화하려면 Red Hat OpenShift Container Platform 환경에 다음 매니페스트를 생성합니다.
$ oc create -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: prometheus namespace: service-telemetry spec: channel: beta installPlanApproval: Automatic name: prometheus source: operatorhubio-operators sourceNamespace: openshift-marketplace EOF
Prometheus
Succeeded의 ClusterServiceVersion을 확인합니다.$ oc get csv --selector=operators.coreos.com/prometheus.service-telemetry NAME DISPLAY VERSION REPLACES PHASE prometheusoperator.0.47.0 Prometheus Operator 0.47.0 prometheusoperator.0.37.0 Succeeded
이벤트를 ElasticSearch에 저장하려면 Kubernetes(ECK) Operator에서 Elastic Cloud를 활성화해야 합니다. ECK Operator를 활성화하려면 Red Hat OpenShift Container Platform 환경에 다음 매니페스트를 생성합니다.
$ oc create -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: elasticsearch-eck-operator-certified namespace: service-telemetry spec: channel: stable installPlanApproval: Automatic name: elasticsearch-eck-operator-certified source: certified-operators sourceNamespace: openshift-marketplace EOF
Kubernetes에서 Elastic Cloud의 ClusterServiceVersion이 성공했는지
확인합니다.$ oc get csv --selector=operators.coreos.com/elasticsearch-eck-operator-certified.service-telemetry NAME DISPLAY VERSION REPLACES PHASE elasticsearch-eck-operator-certified.1.9.1 Elasticsearch (ECK) Operator 1.9.1 Succeeded
STF 인스턴스를 관리하는 Service Telemetry Operator 서브스크립션을 생성합니다.
$ oc create -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: service-telemetry-operator namespace: service-telemetry spec: channel: stable-1.4 installPlanApproval: Automatic name: service-telemetry-operator source: redhat-operators sourceNamespace: openshift-marketplace EOF
Service Telemetry Operator 및 종속 Operator를 확인합니다.
$ oc get csv --namespace service-telemetry NAME DISPLAY VERSION REPLACES PHASE amq7-cert-manager.v1.0.3 Red Hat Integration - AMQ Certificate Manager 1.0.3 amq7-cert-manager.v1.0.2 Succeeded amq7-interconnect-operator.v1.10.4 Red Hat Integration - AMQ Interconnect 1.10.4 amq7-interconnect-operator.v1.10.3 Succeeded elasticsearch-eck-operator-certified.1.9.1 Elasticsearch (ECK) Operator 1.9.1 Succeeded prometheusoperator.0.47.0 Prometheus Operator 0.47.0 prometheusoperator.0.37.0 Succeeded service-telemetry-operator.v1.4.1641489191 Service Telemetry Operator 1.4.1641489191 Succeeded smart-gateway-operator.v4.0.1641489202 Smart Gateway Operator 4.0.1641489202 Succeeded
3.2. Red Hat OpenShift Container Platform에서 ServiceTelemetry 오브젝트 생성
Red Hat OpenShift Container Platform에서 ServiceTelemetry 오브젝트를 생성하여 Service Telemetry Operator가 Service Telemetry Framework (STF) 배포에 대한 지원 구성 요소를 생성합니다. 자세한 내용은 3.2.1절. “ServiceTelemetry 오브젝트의 기본 매개변수”의 내용을 참조하십시오.
절차
기본값을 사용하는 STF 배포를 생성하는
ServiceTelemetry오브젝트를 생성하려면 빈spec매개변수를 사용하여ServiceTelemetry오브젝트를 생성합니다.$ oc apply -f - <<EOF apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: {} EOF기본값을 재정의하려면 재정의할 매개변수를 정의합니다. 이 예에서는
enabled를true로 설정하여 ElasticSearch를 활성화합니다.$ oc apply -f - <<EOF apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: backends: events: elasticsearch: enabled: true EOF빈
spec매개변수를 사용하여ServiceTelemetry오브젝트를 생성하면 다음과 같은 기본 설정이 있는 STF 배포가 생성됩니다.apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: alerting: alertmanager: receivers: snmpTraps: enabled: false target: 192.168.24.254 storage: persistent: pvcStorageRequest: 20G strategy: persistent enabled: true backends: events: elasticsearch: enabled: false storage: persistent: pvcStorageRequest: 20Gi strategy: persistent version: 7.16.1 logs: loki: enabled: false flavor: 1x.extra-small replicationFactor: 1 storage: objectStorageSecret: test storageClass: standard metrics: prometheus: enabled: true scrapeInterval: 10s storage: persistent: pvcStorageRequest: 20G retention: 24h strategy: persistent clouds: - events: collectors: - collectorType: collectd debugEnabled: false subscriptionAddress: collectd/cloud1-notify - collectorType: ceilometer debugEnabled: false subscriptionAddress: anycast/ceilometer/cloud1-event.sample metrics: collectors: - collectorType: collectd debugEnabled: false subscriptionAddress: collectd/cloud1-telemetry - collectorType: ceilometer debugEnabled: false subscriptionAddress: anycast/ceilometer/cloud1-metering.sample - collectorType: sensubility debugEnabled: false subscriptionAddress: sensubility/cloud1-telemetry name: cloud1 graphing: enabled: false grafana: adminPassword: secret adminUser: root baseImage: docker.io/grafana/grafana:latest disableSignoutMenu: false ingressEnabled: false highAvailability: enabled: false observabilityStrategy: use_community transports: qdr: enabled: true web: enabled: false이러한 기본값을 재정의하려면
spec매개변수에 구성을 추가합니다.Service Telemetry Operator에서 STF 배포 로그를 확인합니다.
$ oc logs --selector name=service-telemetry-operator ... --------------------------- Ansible Task Status Event StdOut ----------------- PLAY RECAP ********************************************************************* localhost : ok=57 changed=0 unreachable=0 failed=0 skipped=20 rescued=0 ignored=0
검증
모든 워크로드가 올바르게 작동하는지 확인하려면 각 Pod의 Pod 및 상태를 확인합니다.
참고backends.events.elasticsearch.enabled매개변수를true로 설정하면 알림 스마트 게이트웨이에서 ElasticSearch가 시작되기 전 일정 기간 동안Error및CrashLoopBackOff오류 메시지를 보고합니다.$ oc get pods NAME READY STATUS RESTARTS AGE alertmanager-default-0 2/2 Running 0 17m default-cloud1-ceil-meter-smartgateway-6484b98b68-vd48z 2/2 Running 0 17m default-cloud1-coll-meter-smartgateway-799f687658-4gxpn 2/2 Running 0 17m default-cloud1-sens-meter-smartgateway-c7f4f7fc8-c57b4 2/2 Running 0 17m default-interconnect-54658f5d4-pzrpt 1/1 Running 0 17m elastic-operator-66b7bc49c4-sxkc2 1/1 Running 0 52m interconnect-operator-69df6b9cb6-7hhp9 1/1 Running 0 50m prometheus-default-0 2/2 Running 1 17m prometheus-operator-6458b74d86-wbdqp 1/1 Running 0 51m service-telemetry-operator-864646787c-hd9pm 1/1 Running 0 51m smart-gateway-operator-79778cf548-mz5z7 1/1 Running 0 51m
3.2.1. ServiceTelemetry 오브젝트의 기본 매개변수
ServiceTelemetry 오브젝트는 다음과 같은 기본 구성 매개변수로 구성됩니다.
-
경고 -
백엔드 -
클라우드 -
그래프 -
highAvailability -
전송
STF 배포의 다양한 기능을 제공하도록 이러한 각 구성 매개변수를 구성할 수 있습니다.
servicetelemetry.infra.watch/v1alpha1 에 대한 지원은 STF 1.3에서 제거되었습니다.
backends 매개변수
backends 매개변수를 사용하여 지표 및 이벤트의 스토리지에 사용할 수 있는 스토리지 백엔드를 제어하고, cloud 매개변수가 정의하는 Smart Gateways 사용을 제어합니다. 자세한 내용은 “clouds 매개변수”의 내용을 참조하십시오.
현재는 Prometheus를 지표 스토리지 백엔드로, 이벤트 스토리지 백엔드로 ElasticSearch를 사용할 수 있습니다.
지표의 스토리지 백엔드로 Prometheus를 활성화
지표의 스토리지 백엔드로 Prometheus를 활성화하려면 ServiceTelemetry 오브젝트를 구성해야 합니다.
절차
ServiceTelemetry오브젝트를 구성합니다.apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: backends: metrics: prometheus: enabled: true
Prometheus의 영구 스토리지 구성
backends.metrics.prometheus.storage.persistent 에 정의된 추가 매개 변수를 사용하여 스토리지 클래스 및 볼륨 크기와 같은 Prometheus에 대한 영구 스토리지 옵션을 구성합니다.
storageClass 를 사용하여 백엔드 스토리지 클래스를 정의합니다. 이 매개변수를 설정하지 않으면 Service Telemetry Operator는 Red Hat OpenShift Container Platform 클러스터에 기본 스토리지 클래스를 사용합니다.
pvcStorageRequest 매개변수를 사용하여 스토리지 요청을 충족하기 위해 필요한 최소 볼륨 크기를 정의합니다. 볼륨이 정적으로 정의되면 요청된 볼륨보다 큰 볼륨 크기가 사용될 수 있습니다. 기본적으로 Service Telemetry Operator는 볼륨 크기 20G (20GB)를 요청합니다.
절차
사용 가능한 스토리지 클래스를 나열합니다.
$ oc get storageclasses NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE csi-manila-ceph manila.csi.openstack.org Delete Immediate false 20h standard (default) kubernetes.io/cinder Delete WaitForFirstConsumer true 20h standard-csi cinder.csi.openstack.org Delete WaitForFirstConsumer true 20h
ServiceTelemetry오브젝트를 구성합니다.apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: backends: metrics: prometheus: enabled: true storage: strategy: persistent persistent: storageClass: standard-csi pvcStorageRequest: 50G
이벤트의 스토리지 백엔드로 ElasticSearch 활성화
이벤트의 스토리지 백엔드로 ElasticSearch를 활성화하려면 ServiceTelemetry 오브젝트를 구성해야 합니다.
절차
ServiceTelemetry오브젝트를 구성합니다.apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: backends: events: elasticsearch: enabled: true
ElasticSearch의 영구 스토리지 구성
backends.events.elasticsearch.storage.persistent 에 정의된 추가 매개변수를 사용하여 스토리지 클래스 및 볼륨 크기와 같은 ElasticSearch에 대한 영구 스토리지 옵션을 구성합니다.
storageClass 를 사용하여 백엔드 스토리지 클래스를 정의합니다. 이 매개변수를 설정하지 않으면 Service Telemetry Operator는 Red Hat OpenShift Container Platform 클러스터에 기본 스토리지 클래스를 사용합니다.
pvcStorageRequest 매개변수를 사용하여 스토리지 요청을 충족하기 위해 필요한 최소 볼륨 크기를 정의합니다. 볼륨이 정적으로 정의되면 요청된 볼륨보다 큰 볼륨 크기가 사용될 수 있습니다. 기본적으로 Service Telemetry Operator는 볼륨 크기 20Gi (20GB)를 요청합니다.
절차
사용 가능한 스토리지 클래스를 나열합니다.
$ oc get storageclasses NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE csi-manila-ceph manila.csi.openstack.org Delete Immediate false 20h standard (default) kubernetes.io/cinder Delete WaitForFirstConsumer true 20h standard-csi cinder.csi.openstack.org Delete WaitForFirstConsumer true 20h
ServiceTelemetry오브젝트를 구성합니다.apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: backends: events: elasticsearch: enabled: true version: 7.16.1 storage: strategy: persistent persistent: storageClass: standard-csi pvcStorageRequest: 50G
clouds 매개변수
clouds 매개 변수를 사용하여 어떤 Smart Gateway 개체가 배포되는지 정의하므로 여러 모니터링되는 클라우드 환경이 STF 인스턴스에 연결할 수 있는 인터페이스를 제공합니다. 지원 백엔드를 사용할 수 있는 경우 기본 클라우드 구성에 대한 지표 및 이벤트 Smart Gateway가 생성됩니다. 기본적으로 Service Telemetry Operator는 cloud1 에 대한 스마트 게이트웨이를 생성합니다.
정의된 클라우드에 대해 생성되는 Smart Gateway를 제어하기 위해 클라우드 오브젝트 목록을 생성할 수 있습니다. 각 클라우드는 데이터 유형 및 수집기로 구성됩니다. 데이터 유형은 지표 또는 이벤트입니다. 각 데이터 유형은 수집기 목록, 메시지 버스 서브스크립션 주소 및 디버깅을 활성화하는 매개변수로 구성됩니다. 메트릭에 사용 가능한 컬렉터는 collectd,ceilometer, sensubility 입니다. 이벤트에 사용 가능한 컬렉터는 collectd 및 ceilometer 입니다. 이러한 각 컬렉터의 서브스크립션 주소가 모든 클라우드, 데이터 유형 및 수집기 조합에 대해 고유해야 합니다.
기본 cloud1 구성은 특정 클라우드 인스턴스에 대한 collectd, Ceilometer 및 Sensubility 데이터 수집기에 대한 메트릭 및 이벤트에 대한 서브스크립션 및 데이터 스토리지를 제공하는 다음 ServiceTelemetry 오브젝트로 표시됩니다.
apiVersion: infra.watch/v1beta1
kind: ServiceTelemetry
metadata:
name: stf-default
namespace: service-telemetry
spec:
clouds:
- name: cloud1
metrics:
collectors:
- collectorType: collectd
subscriptionAddress: collectd/telemetry
- collectorType: ceilometer
subscriptionAddress: anycast/ceilometer/metering.sample
- collectorType: sensubility
subscriptionAddress: sensubility/telemetry
debugEnabled: false
events:
collectors:
- collectorType: collectd
subscriptionAddress: collectd/notify
- collectorType: ceilometer
subscriptionAddress: anycast/ceilometer/event.sample
clouds 매개변수의 각 항목은 클라우드 인스턴스를 나타냅니다. 클라우드 인스턴스는 name,metrics 및 events 의 세 가지 최상위 매개변수로 구성됩니다. 지표 및 이벤트 매개변수는 해당 데이터 유형의 스토리지의 해당 백엔드를 나타냅니다. collectors 매개변수는 두 개의 필수 매개변수인 collectorType 및 subscriptionAddress 로 구성된 오브젝트 목록을 지정하고 Smart Gateway의 인스턴스를 나타냅니다. collectorType 매개변수는 collectd, Ceilometer 또는 Sensubility에서 수집한 데이터를 지정합니다. subscriptionAddress 매개변수는 Smart Gateway가 서브스크립션하는 AMQ Interconnect 주소를 제공합니다.
collectors 매개변수 내에서 선택적 부울 매개변수 debugEnabled 를 사용하여 실행 중인 Smart Gateway Pod에서 추가 콘솔 디버깅을 활성화할 수 있습니다.
추가 리소스
- 기본 Smart Gateway 삭제에 대한 자세한 내용은 4.4.3절. “기본 스마트 게이트웨이 삭제” 을 참조하십시오.
- 여러 클라우드를 구성하는 방법에 대한 자세한 내용은 4.4절. “여러 클라우드 구성” 을 참조하십시오.
alert 매개변수
alert 매개변수를 사용하여 Alertmanager 인스턴스 생성 및 스토리지 백엔드 구성을 제어합니다. 기본적으로 경고 는 활성화되어 있습니다. 자세한 내용은 5.3절. “Service Telemetry Framework의 경고”의 내용을 참조하십시오.
그래프 매개변수
그래프 매개 변수를 사용하여 Grafana 인스턴스 생성을 제어합니다. 기본적으로 그래프는 비활성화되어 있습니다. 자세한 내용은 5.1절. “Service Telemetry Framework의 대시보드”의 내용을 참조하십시오.
highAvailability 매개변수
highAvailability 매개 변수를 사용하여 실패하거나 일정을 예약하는 구성 요소의 복구 시간을 줄이기 위해 STF 구성 요소의 여러 복사본 인스턴스화를 제어합니다. 기본적으로 highAvailability 는 비활성화되어 있습니다. 자세한 내용은 5.5절. “고가용성”의 내용을 참조하십시오.
transports 매개변수
transports 매개변수를 사용하여 STF 배포에 대한 메시지 버스 활성화를 제어합니다. 현재 지원되는 유일한 전송은 AMQ Interconnect입니다. 기본적으로 qdr 전송이 활성화됩니다.
3.3. STF 구성 요소의 사용자 인터페이스에 액세스
Red Hat OpenShift Container Platform에서 애플리케이션은 경로를 통해 외부 네트워크에 노출됩니다. 경로에 대한 자세한 내용은 Ingress 클러스터 트래픽 구성을 참조하십시오.
Service Telemetry Framework(STF)에서 웹 기반 인터페이스가 있는 각 서비스에 대해 HTTPS 경로가 노출됩니다. 이러한 경로는 Red Hat OpenShift Container Platform RBAC 및 Red Hat OpenShift Container Platform 네임스페이스를 볼 수 있는 ClusterRoleBinding 이 있는 모든 사용자가 보호합니다. RBAC에 대한 자세한 내용은 RBAC를 사용하여 권한 정의 및 적용을 참조하십시오.
절차
- Red Hat OpenShift Container Platform에 로그인합니다.
service-telemetry네임스페이스로 변경합니다.$ oc project service-telemetry
service-telemetry프로젝트에서 사용 가능한 웹 UI 경로를 나열합니다.$ oc get routes | grep web default-alertmanager-proxy default-alertmanager-proxy-service-telemetry.apps.infra.watch default-alertmanager-proxy web reencrypt/Redirect None default-prometheus-proxy default-prometheus-proxy-service-telemetry.apps.infra.watch default-prometheus-proxy web reencrypt/Redirect None
- 웹 브라우저에서 https://<route_address> 로 이동하여 해당 서비스의 웹 인터페이스에 액세스합니다.
3.4. 대체 관찰 전략 구성
스토리지, 시각화 및 경고 백엔드 배포를 건너뛰도록 STF를 구성하려면 ServiceTelemetry 사양에 observed abilityStrategy: none 을 추가합니다. 이 모드에서는 AMQ Interconnect 라우터 및 지표 Smart Gateway만 배포되며 STF Smart Gateway에서 메트릭을 수집하도록 외부 Prometheus 호환 시스템을 구성해야 합니다.
현재 observedability Strategy를 메트릭만 지원됩니다. 이벤트 스마트 게이트웨이는 배포되지 않습니다.
none 으로 설정하는 경우
절차
spec매개변수에서 속성 observedabilityStrategy: none을사용하여ServiceTelemetry오브젝트를 생성합니다. 매니페스트는 모든 지표 수집기 유형이 있는 단일 클라우드에서 Telemetry를 수신하는 데 적합한 STF의 기본 배포 결과를 보여줍니다.$ oc apply -f - <<EOF apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: observabilityStrategy: none EOF
모든 워크로드가 올바르게 작동하는지 확인하려면 Pod 및 각 Pod의 상태를 확인합니다.
$ oc get pods NAME READY STATUS RESTARTS AGE default-cloud1-ceil-meter-smartgateway-59c845d65b-gzhcs 3/3 Running 0 132m default-cloud1-coll-meter-smartgateway-75bbd948b9-d5phm 3/3 Running 0 132m default-cloud1-sens-meter-smartgateway-7fdbb57b6d-dh2g9 3/3 Running 0 132m default-interconnect-668d5bbcd6-57b2l 1/1 Running 0 132m interconnect-operator-b8f5bb647-tlp5t 1/1 Running 0 47h service-telemetry-operator-566b9dd695-wkvjq 1/1 Running 0 156m smart-gateway-operator-58d77dcf7-6xsq7 1/1 Running 0 47h
추가 리소스
추가 클라우드 구성 또는 지원되는 컬렉터 집합을 변경하는 방법에 대한 자세한 내용은 다음을 참조하십시오. 4.4.2절. “스마트 게이트웨이 배포”
4장. Service Telemetry Framework용 Red Hat OpenStack Platform 구성
지표, 이벤트 또는 둘 다를 수집하려면 데이터 수집 및 전송을 활성화하도록 RHOSP(Red Hat OpenStack Platform) 오버클라우드를 구성해야 합니다.
STF는 단일 및 여러 클라우드를 모두 지원할 수 있습니다. 단일 클라우드 설치를 위해 RHOSP 및 STF의 기본 구성입니다.
- 기본 구성이 있는 단일 RHOSP 오버클라우드 배포의 경우 4.1절. “Service Telemetry Framework용 Red Hat OpenStack Platform 오버클라우드 배포” 을 참조하십시오.
- 여러 클라우드의 RHOSP 설치 및 구성 STF를 계획하려면 4.4절. “여러 클라우드 구성” 을 참조하십시오.
RHOSP 오버클라우드 배포의 일부로 사용자 환경에서 추가 기능을 구성해야 할 수 있습니다.
- DCN(Distributed Compute node) 또는 스파인-리프형과 같은 라우팅된 L3 도메인을 사용하는 RHOSP 클라우드 노드의 STF에 데이터 수집 및 전송을 배포하려면 4.3절. “비표준 네트워크 토폴로지에 배포” 을 참조하십시오.
- NetNamespace 및 STF 모두에 메트릭을 보내려면 4.2절. “NetNamespace 및 Service Telemetry Framework로 메트릭 전송” 을 참조하십시오.
4.1. Service Telemetry Framework용 Red Hat OpenStack Platform 오버클라우드 배포
RHOSP(Red Hat OpenStack Platform) 오버클라우드 배포의 일부로 데이터 수집기 및 서비스 Telemetry Framework(STF)로의 데이터 전송을 구성해야 합니다.
절차
추가 리소스
- AMQ Interconnect를 통해 데이터를 수집하려면 amqp1 플러그인을 참조하십시오.
4.1.1. 오버클라우드 설정을 위해 Service Telemetry Framework에서 CA 인증서 가져오기
Red Hat OpenStack Platform 오버클라우드를 Service Telemetry Framework(STF)에 연결하려면 Service Telemetry Framework 내에서 실행되는 AMQ Interconnect의 CA 인증서를 검색하고 Red Hat OpenStack Platform 구성에서 인증서를 사용합니다.
절차
Service Telemetry Framework에서 사용 가능한 인증서 목록을 확인합니다.
$ oc get secrets
default-interconnect-selfsignedSecret의 내용을 검색하고 기록해 둡니다.$ oc get secret/default-interconnect-selfsigned -o jsonpath='{.data.ca\.crt}' | base64 -d
4.1.2. AMQ Interconnect 경로 주소 검색
STF(Service Telemetry Framework)용 RHOSP(Red Hat OpenStack Platform) 오버클라우드를 구성하는 경우 STF 연결 파일에 AMQ Interconnect 경로 주소를 제공해야 합니다.
절차
- Red Hat OpenShift Container Platform 환경에 로그인합니다.
service-telemetry프로젝트에서 AMQ Interconnect 경로 주소를 검색합니다.$ oc get routes -ogo-template='{{ range .items }}{{printf "%s\n" .spec.host }}{{ end }}' | grep "\-5671" default-interconnect-5671-service-telemetry.apps.infra.watch
4.1.3. STF에 대한 기본 구성 생성
STF(Service Telemetry Framework)의 호환 가능한 데이터 수집 및 전송을 제공하도록 기본 매개변수를 구성하려면 기본 데이터 수집 값을 정의하는 파일을 생성해야 합니다.
절차
-
stack사용자로 RHOSP(Red Hat OpenStack Platform) 언더클라우드에 로그인합니다. /home/stack디렉터리에enable-stf.yaml이라는 구성 파일을 생성합니다.중요EventPipelinePublishers및PipelinePublishers를 빈 목록으로 설정하면 RHOSP Telemetry 구성 요소(예: Gradle 또는 Panko)에 전달되는 이벤트 또는 메트릭 데이터가 없습니다. 데이터를 추가 파이프라인에 전송해야 하는 경우ExtraConfig에 지정된 대로 Ceilometer 폴링 간격이 30초인 경우 RHOSP 원격 분석 구성 요소를 덮어 쓸 수 있으며 간격을300과 같은 더 큰 값으로 늘려야 합니다. 값을 폴링 간격으로 늘리면 STF에서 Telemetry resolution이 줄어듭니다.STF 및ECDHE를 사용하여 Telemetry 컬렉션을 활성화하려면 다음을 참조하십시오. 4.2절. “NetNamespace 및 Service Telemetry Framework로 메트릭 전송”
enable-stf.yaml
parameter_defaults:
# only send to STF, not other publishers
EventPipelinePublishers: []
PipelinePublishers: []
# manage the polling and pipeline configuration files for Ceilometer agents
ManagePolling: true
ManagePipeline: true
# enable Ceilometer metrics and events
CeilometerQdrPublishMetrics: true
CeilometerQdrPublishEvents: true
# enable collection of API status
CollectdEnableSensubility: true
CollectdSensubilityTransport: amqp1
# enable collection of containerized service metrics
CollectdEnableLibpodstats: true
# set collectd overrides for higher telemetry resolution and extra plugins
# to load
CollectdConnectionType: amqp1
CollectdAmqpInterval: 5
CollectdDefaultPollingInterval: 5
CollectdExtraPlugins:
- vmem
# set standard prefixes for where metrics and events are published to QDR
MetricsQdrAddresses:
- prefix: 'collectd'
distribution: multicast
- prefix: 'anycast/ceilometer'
distribution: multicast
ExtraConfig:
ceilometer::agent::polling::polling_interval: 30
ceilometer::agent::polling::polling_meters:
- cpu
- disk.*
- ip.*
- image.*
- memory
- memory.*
- network.*
- perf.*
- port
- port.*
- switch
- switch.*
- storage.*
- volume.*
# to avoid filling the memory buffers if disconnected from the message bus
# note: this may need an adjustment if there are many metrics to be sent.
collectd::plugin::amqp1::send_queue_limit: 5000
# receive extra information about virtual memory
collectd::plugin::vmem::verbose: true
# provide name and uuid in addition to hostname for better correlation
# to ceilometer data
collectd::plugin::virt::hostname_format: "name uuid hostname"
# provide the human-friendly name of the virtual instance
collectd::plugin::virt::plugin_instance_format: metadata
# set memcached collectd plugin to report its metrics by hostname
# rather than host IP, ensuring metrics in the dashboard remain uniform
collectd::plugin::memcached::instances:
local:
host: "%{hiera('fqdn_canonical')}"
port: 11211
4.1.4. 오버클라우드의 STF 연결 구성
STF(Service Telemetry Framework) 연결을 구성하려면 오버클라우드에서 STF 배포에 대한 AMQ Interconnect의 연결 구성이 포함된 파일을 생성해야 합니다. STF에서 이벤트 및 스토리지 컬렉션을 활성화하고 오버클라우드를 배포합니다. 기본 구성은 기본 메시지 버스 항목이 있는 단일 클라우드 인스턴스에 대한 것입니다. 여러 클라우드 배포 구성은 4.4절. “여러 클라우드 구성” 을 참조하십시오.
사전 요구 사항
- STF에서 배포된 AMQ Interconnect에서 CA 인증서를 검색합니다. 자세한 내용은 4.1.1절. “오버클라우드 설정을 위해 Service Telemetry Framework에서 CA 인증서 가져오기”의 내용을 참조하십시오.
- AMQ Interconnect 경로 주소를 검색합니다. 자세한 내용은 4.1.2절. “AMQ Interconnect 경로 주소 검색”의 내용을 참조하십시오.
절차
-
stack사용자로 RHOSP 언더클라우드에 로그인합니다. -
/home/stack디렉터리에stf-connectors.yaml구성 파일을 생성합니다. stf-connectors.yaml파일에서 오버클라우드의 AMQ Interconnect를 STF 배포에 연결하도록MetricsQdrConnectors주소를 구성합니다. 이 파일에서 STF의 기본값과 일치하도록 Sensubility, Ceilometer 및 collectd의 주제 주소를 구성합니다. 주제 및 클라우드 구성 사용자 지정에 대한 자세한 내용은 4.4절. “여러 클라우드 구성” 을 참조하십시오.-
host매개 변수를 4.1.2절. “AMQ Interconnect 경로 주소 검색” 에서 검색한HOST/PORT값으로 바꿉니다. caCertFileContent매개변수를 4.1.1절. “오버클라우드 설정을 위해 Service Telemetry Framework에서 CA 인증서 가져오기” 에서 검색된 콘텐츠로 바꿉니다.STF-connectors.yaml
resource_registry: OS::TripleO::Services::Collectd: /usr/share/openstack-tripleo-heat-templates/deployment/metrics/collectd-container-puppet.yaml 1 parameter_defaults: MetricsQdrConnectors: - host: stf-default-interconnect-5671-service-telemetry.apps.infra.watch 2 port: 443 role: edge verifyHostname: false sslProfile: sslProfile MetricsQdrSSLProfiles: - name: sslProfile caCertFileContent: | ----BEGIN CERTIFICATE---- <snip> ----END CERTIFICATE---- CeilometerQdrEventsConfig: driver: amqp topic: cloud1-event 3 CeilometerQdrMetricsConfig: driver: amqp topic: cloud1-metering 4 CollectdAmqpInstances: cloud1-notify: 5 notify: true format: JSON presettle: false cloud1-telemetry: 6 format: JSON presettle: false CollectdSensubilityResultsChannel: sensubility/cloud1-telemetry 7
- 1
- 여러 클라우드 배포에 대한
collectd-write-qdr.yaml환경 파일을 포함하지 않으므로 collectd 서비스를 직접 로드합니다. - 2
- 3
- Ceilometer 이벤트에 대한 주제를 정의합니다. 이 값의 형식은
anycast/ceilometer/cloud1-event.sample입니다. - 4
- Ceilometer 메트릭에 대한 주제를 정의합니다. 이 값의 형식은'anycast/ceilometer/cloud1-metering.sample'입니다.
- 5
- collectd 이벤트에 대한 주제를 정의합니다. 이 값의 형식은
collectd/cloud1-notify입니다. - 6
- collectd 메트릭에 대한 주제를 정의합니다. 이 값의 형식은
collectd/cloud1-telemetry입니다. - 7
- collectd-sensubility 이벤트에 대한 주제를 정의합니다. 값은 정확한 문자열
sensubility/cloud1-telemetry입니다.
-
4.1.5. 오버클라우드 배포
필요한 환경 파일을 사용하여 오버클라우드를 배포하거나 업데이트하여 데이터를 Service Telemetry Framework(STF)로 수집하고 전송합니다.
절차
-
stack사용자로 RHOSP(Red Hat OpenStack Platform) 언더클라우드에 로그인합니다. 인증 파일을 소싱합니다.
[stack@undercloud-0 ~]$ source stackrc (undercloud) [stack@undercloud-0 ~]$
RHOSP director 배포에 다음 파일을 추가하여 데이터 수집 및 AMQ Interconnect를 구성합니다.
-
Ceilometer 원격 분석 및 이벤트가 STF로 전송되도록
ceilometer-write-qdr.yaml파일 -
메시지 버스가 활성화되어 있고 STF 메시지 버스 라우터에 연결할 수 있도록
qdr-edge-only.yaml파일 -
기본값이 올바르게 구성되었는지 확인하기 위한
enable-stf.yaml환경 파일 -
STF 연결을 정의하는
stf-connectors.yaml환경 파일
-
Ceilometer 원격 분석 및 이벤트가 STF로 전송되도록
RHOSP 오버클라우드를 배포합니다.
(undercloud) [stack@undercloud-0 ~]$ openstack overcloud deploy <other_arguments> --templates /usr/share/openstack-tripleo-heat-templates \ --environment-file <...other_environment_files...> \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/ceilometer-write-qdr.yaml \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/qdr-edge-only.yaml \ --environment-file /home/stack/enable-stf.yaml \ --environment-file /home/stack/stf-connectors.yaml
4.1.6. 클라이언트 측 설치 검증
STF(Service Telemetry Framework) 스토리지 도메인에서 데이터 수집을 검증하려면 전달된 데이터를 위해 데이터 소스를 쿼리합니다. RHOSP(Red Hat OpenStack Platform) 배포의 개별 노드를 확인하려면 SSH를 사용하여 콘솔에 연결합니다.
일부 Telemetry 데이터는 RHOSP에 활성 워크로드가 있는 경우에만 사용할 수 있습니다.
절차
- 오버클라우드 노드에 로그인합니다(예: controller-0).
metrics_qdr컨테이너가 노드에서 실행 중인지 확인합니다.$ sudo podman container inspect --format '{{.State.Status}}' metrics_qdr runningAMQ Interconnect가 실행 중인 내부 네트워크 주소(예: 포트
5666에서 수신 대기하는 172.17.1.44)를 반환합니다.$ sudo podman exec -it metrics_qdr cat /etc/qpid-dispatch/qdrouterd.conf listener { host: 172.17.1.44 port: 5666 authenticatePeer: no saslMechanisms: ANONYMOUS }로컬 AMQ Interconnect에 대한 연결 목록을 반환합니다.
$ sudo podman exec -it metrics_qdr qdstat --bus=172.17.1.44:5666 --connections Connections id host container role dir security authentication tenant ============================================================================================================================================================================================================================================================================================ 1 default-interconnect-5671-service-telemetry.apps.infra.watch:443 default-interconnect-7458fd4d69-bgzfb edge out TLSv1.2(DHE-RSA-AES256-GCM-SHA384) anonymous-user 12 172.17.1.44:60290 openstack.org/om/container/controller-0/ceilometer-agent-notification/25/5c02cee550f143ec9ea030db5cccba14 normal in no-security no-auth 16 172.17.1.44:36408 metrics normal in no-security anonymous-user 899 172.17.1.44:39500 10a2e99d-1b8a-4329-b48c-4335e5f75c84 normal in no-security no-auth
다음의 4개의 연결이 있습니다.
- STF에 대한 아웃 바운드 연결
- ceilometer에서 인바운드 연결
- collectd에서 인바운드 연결
qdstat클라이언트의 인바운드 연결아웃바운드 STF 연결은
MetricsQdrConnectors호스트 매개 변수에 제공되며 STF 스토리지 도메인의 경로입니다. 다른 호스트는 이 AMQ Interconnect에 대한 클라이언트 연결의 내부 네트워크 주소입니다.
메시지가 전달되도록 하려면 링크를 나열하고 메시지 전달을 위해
deliv열의_edge주소를 확인합니다.$ sudo podman exec -it metrics_qdr qdstat --bus=172.17.1.44:5666 --links Router Links type dir conn id id peer class addr phs cap pri undel unsett deliv presett psdrop acc rej rel mod delay rate =========================================================================================================================================================== endpoint out 1 5 local _edge 250 0 0 0 2979926 0 0 0 0 2979926 0 0 0 endpoint in 1 6 250 0 0 0 0 0 0 0 0 0 0 0 0 endpoint in 1 7 250 0 0 0 0 0 0 0 0 0 0 0 0 endpoint out 1 8 250 0 0 0 0 0 0 0 0 0 0 0 0 endpoint in 1 9 250 0 0 0 0 0 0 0 0 0 0 0 0 endpoint out 1 10 250 0 0 0 911 911 0 0 0 0 0 911 0 endpoint in 1 11 250 0 0 0 0 911 0 0 0 0 0 0 0 endpoint out 12 32 local temp.lSY6Mcicol4J2Kp 250 0 0 0 0 0 0 0 0 0 0 0 0 endpoint in 16 41 250 0 0 0 2979924 0 0 0 0 2979924 0 0 0 endpoint in 912 1834 mobile $management 0 250 0 0 0 1 0 0 1 0 0 0 0 0 endpoint out 912 1835 local temp.9Ok2resI9tmt+CT 250 0 0 0 0 0 0 0 0 0 0 0 0
RHOSP 노드에서 STF로 주소를 나열하려면 Red Hat OpenShift Container Platform에 연결하여 AMQ Interconnect Pod 이름을 검색하고 연결을 나열합니다. 사용 가능한 AMQ Interconnect Pod를 나열합니다.
$ oc get pods -l application=default-interconnect NAME READY STATUS RESTARTS AGE default-interconnect-7458fd4d69-bgzfb 1/1 Running 0 6d21h
포드에 연결하고 알려진 연결을 나열합니다. 이 예에서는 RHOSP 노드에서 연결 ID 22, 23 및 24가 있는
에지연결세 가지가 있습니다.$ oc exec -it default-interconnect-7458fd4d69-bgzfb -- qdstat --connections 2020-04-21 18:25:47.243852 UTC default-interconnect-7458fd4d69-bgzfb Connections id host container role dir security authentication tenant last dlv uptime =============================================================================================================================================================================================== 5 10.129.0.110:48498 bridge-3f5 edge in no-security anonymous-user 000:00:00:02 000:17:36:29 6 10.129.0.111:43254 rcv[default-cloud1-ceil-meter-smartgateway-58f885c76d-xmxwn] edge in no-security anonymous-user 000:00:00:02 000:17:36:20 7 10.130.0.109:50518 rcv[default-cloud1-coll-event-smartgateway-58fbbd4485-rl9bd] normal in no-security anonymous-user - 000:17:36:11 8 10.130.0.110:33802 rcv[default-cloud1-ceil-event-smartgateway-6cfb65478c-g5q82] normal in no-security anonymous-user 000:01:26:18 000:17:36:05 22 10.128.0.1:51948 Router.ceph-0.redhat.local edge in TLSv1/SSLv3(DHE-RSA-AES256-GCM-SHA384) anonymous-user 000:00:00:03 000:22:08:43 23 10.128.0.1:51950 Router.compute-0.redhat.local edge in TLSv1/SSLv3(DHE-RSA-AES256-GCM-SHA384) anonymous-user 000:00:00:03 000:22:08:43 24 10.128.0.1:52082 Router.controller-0.redhat.local edge in TLSv1/SSLv3(DHE-RSA-AES256-GCM-SHA384) anonymous-user 000:00:00:00 000:22:08:34 27 127.0.0.1:42202 c2f541c1-4c97-4b37-a189-a396c08fb079 normal in no-security no-auth 000:00:00:00 000:00:00:00
네트워크에서 전달한 메시지 수를 보려면
oc exec명령과 함께 각 주소를 사용합니다.$ oc exec -it default-interconnect-7458fd4d69-bgzfb -- qdstat --address 2020-04-21 18:20:10.293258 UTC default-interconnect-7458fd4d69-bgzfb Router Addresses class addr phs distrib pri local remote in out thru fallback ========================================================================================================================== mobile anycast/ceilometer/event.sample 0 balanced - 1 0 970 970 0 0 mobile anycast/ceilometer/metering.sample 0 balanced - 1 0 2,344,833 2,344,833 0 0 mobile collectd/notify 0 multicast - 1 0 70 70 0 0 mobile collectd/telemetry 0 multicast - 1 0 216,128,890 216,128,890 0 0
4.2. NetNamespace 및 Service Telemetry Framework로 메트릭 전송
지표를 Service Telemetry Framework(STF) 및 RuntimeClass에 동시에 보내려면 추가 게시자를 활성화하려면 배포에 환경 파일을 포함해야 합니다.
데이터를 추가 파이프라인에 전송해야 하는 경우 ExtraConfig 에 지정된 대로 Ceilometer 폴링 간격이 30초인 경우 RHOSP 원격 분석 구성 요소를 덮어 쓸 수 있으며 간격을 300 과 같은 더 큰 값으로 늘려야 합니다. 값을 폴링 간격으로 늘리면 STF에서 Telemetry resolution이 줄어듭니다.
사전 요구 사항
- 오버클라우드에서 STF로의 AMQ Interconnect의 연결 설정이 포함된 파일을 생성했습니다. 자세한 내용은 4.1.4절. “오버클라우드의 STF 연결 구성”의 내용을 참조하십시오.
절차
/home/stack디렉터리에gnocchi-connectors.yaml이라는 환경 파일을 생성합니다.resource_registry: OS::TripleO::Services::GnocchiApi: /usr/share/openstack-tripleo-heat-templates/deployment/gnocchi/gnocchi-api-container-puppet.yaml OS::TripleO::Services::GnocchiMetricd: /usr/share/openstack-tripleo-heat-templates/deployment/gnocchi/gnocchi-metricd-container-puppet.yaml OS::TripleO::Services::GnocchiStatsd: /usr/share/openstack-tripleo-heat-templates/deployment/gnocchi/gnocchi-statsd-container-puppet.yaml OS::TripleO::Services::AodhApi: /usr/share/openstack-tripleo-heat-templates/deployment/aodh/aodh-api-container-puppet.yaml OS::TripleO::Services::AodhEvaluator: /usr/share/openstack-tripleo-heat-templates/deployment/aodh/aodh-evaluator-container-puppet.yaml OS::TripleO::Services::AodhNotifier: /usr/share/openstack-tripleo-heat-templates/deployment/aodh/aodh-notifier-container-puppet.yaml OS::TripleO::Services::AodhListener: /usr/share/openstack-tripleo-heat-templates/deployment/aodh/aodh-listener-container-puppet.yaml parameter_defaults: CeilometerEnableGnocchi: true CeilometerEnablePanko: false GnocchiArchivePolicy: 'high' GnocchiBackend: 'rbd' GnocchiRbdPoolName: 'metrics' EventPipelinePublishers: ['gnocchi://?filter_project=service'] PipelinePublishers: ['gnocchi://?filter_project=service']환경 파일
gnocchi-connectors.yaml을 배포 명령에 추가합니다. <other_arguments> 를 사용자 환경에 적용되는 파일로 바꿉니다.$ openstack overcloud deploy <other_arguments> --templates /usr/share/openstack-tripleo-heat-templates \ --environment-file <...other_environment_files...> \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/ceilometer-write-qdr.yaml \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/collectd-write-qdr.yaml \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/qdr-edge-only.yaml \ --environment-file /home/stack/enable-stf.yaml \ --environment-file /home/stack/stf-connectors.yaml \ --environment-file /home/stack/gnocchi-connectors.yaml
설정이 성공했는지 확인하려면 컨트롤러 노드의
/var/lib/config-data/puppet-generated/ceilometer/etc/ceilometer/pipeline.yaml파일의 콘텐츠를 확인합니다. 파일의게시자섹션에notifier및Gnocchi에 대한 정보가 포함되어 있는지 확인합니다.sources: - name: meter_source meters: - "*" sinks: - meter_sink sinks: - name: meter_sink publishers: - gnocchi://?filter_project=service - notifier://172.17.1.35:5666/?driver=amqp&topic=metering
4.3. 비표준 네트워크 토폴로지에 배포
노드가 기본 InternalApi 네트워크와 별도의 네트워크에 있는 경우 AMQ Interconnect가 Service Telemetry Framework(STF) 서버 인스턴스로 데이터를 전송할 수 있도록 구성을 조정해야 합니다. 이 시나리오는 스파인-리프형 또는 DCN 토폴로지에서 일반적입니다. DCN 구성에 대한 자세한 내용은 Spine Leaf Networking 가이드를 참조하십시오.
RHOSP(Red Hat OpenStack Platform) 17.0과 함께 STF를 사용하고 Ceph, 블록 또는 오브젝트 스토리지 노드를 모니터링할 계획인 경우 스파인-리프 및 DCN 네트워크 구성과 유사한 구성을 변경해야 합니다. Ceph 노드를 모니터링하려면 CephStorageExtraConfig 매개변수를 사용하여 AMQ Interconnect 및 collectd 구성 파일에 로드할 네트워크 인터페이스를 정의합니다.
CephStorageExtraConfig:
tripleo::profile::base::metrics::collectd::amqp_host: "%{hiera('storage')}"
tripleo::profile::base::metrics::qdr::listener_addr: "%{hiera('storage')}"
tripleo::profile::base::ceilometer::agent::notification::notifier_host_addr: "%{hiera('storage')}"
마찬가지로 환경에서 Block 및 Object Storage 역할을 사용하는 경우 Block 매개변수를 지정해야 합니다.
StorageExtraConfig 및 ObjectStorageExtraConfig
스파인-리프형 토폴로지를 배포하려면 역할 및 네트워크를 생성한 다음 해당 네트워크를 사용 가능한 역할에 할당해야 합니다. RHOSP 배포를 위해 STF에 대한 데이터 수집 및 전송을 구성하면 역할의 기본 네트워크는 InternalApi 입니다. Ceph, Block 및 Object 스토리지 역할의 경우 기본 네트워크는 Storage 입니다. 스파인-리프형 구성으로 인해 서로 다른 Leaf 그룹화에 다른 네트워크가 할당되고 이러한 이름은 일반적으로 고유하므로 RHOSP 환경 파일의 parameter_defaults 섹션에 추가 구성이 필요합니다.
절차
- 각 Leaf 역할에 사용할 수 있는 네트워크를 문서화합니다. 네트워크 이름 정의의 예 는 Spine Leaf Networking 가이드의 네트워크 데이터 파일 생성 을 참조하십시오. Leaf 그룹화(roles) 생성 및 해당 그룹에 네트워크 할당에 대한 자세 한 내용은 Spine Leaf Networking 가이드의 역할 데이터 파일 만들기 를 참조하십시오.
각 leaf 역할의
ExtraConfig섹션에 다음 구성 예제를 추가합니다. 이 예에서internal_api_subnet은 네트워크 정의의name_lower매개변수(라이프 0의 이름에 추가된_subnet포함)에 정의된 값이며ComputeLeaf0leaf 역할이 연결된 네트워크입니다. 이 경우 네트워크 식별 0은 리프 0의 Compute 역할에 해당하며 기본 내부 API 네트워크 이름과 다른 값을 나타냅니다.ComputeLeaf0leaf 역할의 경우 hiera 조회를 수행하여 collectd AMQP 호스트 매개변수를 할당할 특정 네트워크의 네트워크 인터페이스를 판별하도록 추가 구성을 지정합니다. AMQ Interconnect listener address 매개변수에 대해 동일한 구성을 수행합니다.ComputeLeaf0ExtraConfig: tripleo::profile::base::metrics::collectd::amqp_host: "%{hiera('internal_api_subnet')}" tripleo::profile::base::metrics::qdr::listener_addr: "%{hiera('internal_api_subnet')}"추가 리프 역할은 일반적으로
_subnet을_leafN으로 바꿉니다.n은 리프의 고유 식별자를 나타냅니다.ComputeLeaf1ExtraConfig: tripleo::profile::base::metrics::collectd::amqp_host: "%{hiera('internal_api_leaf1')}" tripleo::profile::base::metrics::qdr::listener_addr: "%{hiera('internal_api_leaf1')}"이 예제 구성은 CephStorage leaf 역할에 있습니다.
CephStorageLeaf0ExtraConfig: tripleo::profile::base::metrics::collectd::amqp_host: "%{hiera('storage_subnet')}" tripleo::profile::base::metrics::qdr::listener_addr: "%{hiera('storage_subnet')}"
4.4. 여러 클라우드 구성
여러 개의 RHOSP(Red Hat OpenStack Platform) 클라우드를 구성하여STF(Service Telemetry Framework)의 단일 인스턴스를 대상으로 할 수 있습니다. 클라우드를 여러 개 구성할 때 모든 클라우드는 고유한 메시지 버스 주제로 메트릭과 이벤트를 보내야 합니다. STF 배포에서는 Smart Gateway 인스턴스는 공통 데이터 저장소에 정보를 저장하기 위해 이러한 항목을 수신 대기합니다. 데이터 스토리지 도메인의 Smart Gateway에 의해 저장되는 데이터는 각 Smart Gateways가 생성하는 메타데이터를 사용하여 필터링됩니다.
그림 4.1. STF에 두 개의 RHOSP 클라우드 연결

여러 클라우드 시나리오에 RHOSP 오버클라우드를 구성하려면 다음 작업을 완료합니다.
- 각 클라우드에 사용할 AMQP 주소 접두사를 계획합니다. 자세한 내용은 4.4.1절. “AMQP 주소 접두사 계획”의 내용을 참조하십시오.
- 각 클라우드에 메트릭 및 이벤트 소비자 스마트 게이트웨이를 배포하여 해당 주소 접두사에서 수신 대기합니다. 자세한 내용은 4.4.2절. “스마트 게이트웨이 배포”의 내용을 참조하십시오.
- 고유한 도메인 이름으로 각 클라우드를 구성합니다. 자세한 내용은 4.4.4절. “고유한 클라우드 도메인 설정”의 내용을 참조하십시오.
- STF에 대한 기본 구성을 생성합니다. 자세한 내용은 4.1.3절. “STF에 대한 기본 구성 생성”의 내용을 참조하십시오.
- 올바른 주소의 STF로 메트릭 및 이벤트를 전송하도록 각 클라우드를 구성합니다. 자세한 내용은 4.4.5절. “여러 클라우드를 위한 Red Hat OpenStack Platform 환경 파일 생성”의 내용을 참조하십시오.
4.4.1. AMQP 주소 접두사 계획
기본적으로 RHOSP(Red Hat OpenStack Platform) 노드는 두 개의 데이터 수집기( collectd 및 Ceilometer)를 통해 데이터를 수신합니다. collectd-sensubility 플러그인에는 고유한 주소가 필요합니다. 이러한 구성 요소는 Telemetry 데이터 또는 알림을 각 AMQP 주소로 전송합니다(예: collectd/telemetry ). STF Smart Gateway는 이러한 AMQP 주소에서 데이터를 수신 대기합니다. 여러 클라우드를 지원하고 모니터링 데이터를 생성한 클라우드를 식별하려면 데이터를 고유 주소로 전송하도록 각 클라우드를 구성합니다. 주소의 두 번째 부분에 클라우드 ID 접두사를 추가합니다. 다음 목록은 일부 주소 및 식별자를 보여줍니다.
-
collectd/cloud1-telemetry -
collectd/cloud1-notify -
sensubility/cloud1-telemetry -
anycast/ceilometer/cloud1-metering.sample -
anycast/ceilometer/cloud1-event.sample -
collectd/cloud2-telemetry -
collectd/cloud2-notify -
sensubility/cloud2-telemetry -
anycast/ceilometer/cloud2-metering.sample -
anycast/ceilometer/cloud2-event.sample -
collectd/us-east-1-telemetry -
collectd/us-west-3-telemetry
4.4.2. 스마트 게이트웨이 배포
각 클라우드의 각 데이터 수집 유형에 대해 Smart Gateway를 배포해야 합니다. collectd 지표, collectd 이벤트용 하나씩, Ceilometer 메트릭용, Ceilometer 이벤트용, collectd-sensubility 메트릭에 대한 하나씩. 해당 클라우드에 대해 정의한 AMQP 주소에서 수신 대기하도록 각 Smart Gateway를 구성합니다. 스마트 게이트웨이를 정의하려면 ServiceTelemetry 매니페스트에서 clouds 매개변수를 구성합니다.
STF를 처음 배포할 때 단일 클라우드의 초기 스마트 게이트웨이를 정의하는 Smart Gateway 매니페스트가 생성됩니다. 여러 클라우드 지원에 대한 Smart Gateway를 배포할 때 각 클라우드의 메트릭 및 이벤트 데이터를 처리하는 각 데이터 수집 유형에 대해 여러 Smart Gateway를 배포합니다. 초기 스마트 게이트웨이는 다음 서브스크립션 주소를 사용하여 cloud1 에 정의됩니다.
| 수집기 | type | 기본 서브스크립션 주소 |
| collectd | 메트릭 | collectd/telemetry |
| collectd | events | collectd/notify |
| collectd-sensubility | 메트릭 | sensubility/telemetry |
| Ceilometer | 메트릭 | anycast/ceilometer/metering.sample |
| Ceilometer | events | anycast/ceilometer/event.sample |
사전 요구 사항
- 클라우드 이름 지정 스키마를 확인했습니다. 이름 지정 스키마를 결정하는 방법에 대한 자세한 내용은 4.4.1절. “AMQP 주소 접두사 계획” 을 참조하십시오.
-
클라우드 오브젝트 목록을 생성했습니다.
clouds매개변수의 콘텐츠를 생성하는 방법에 대한 자세한 내용은 “clouds 매개변수” 을 참조하십시오.
절차
- Red Hat OpenShift Container Platform에 로그인합니다.
service-telemetry네임스페이스로 변경합니다.$ oc project service-telemetry
기본ServiceTelemetry 오브젝트를 편집하고 구성을 사용하여clouds매개변수를 추가합니다.주의긴 클라우드 이름은 63자의 최대 Pod 이름을 초과할 수 있습니다.
ServiceTelemetry이름기본값과clouds.name의 조합이 19자를 초과하지 않도록 합니다. 클라우드 이름에는-와 같은 특수 문자가 포함될 수 없습니다. 클라우드 이름을 영숫자(a-z, 0-9)로 제한합니다.주제 주소에는 문자 제한이 없으며
clouds.name값과 다를 수 있습니다.$ oc edit stf default
apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: ... spec: ... clouds: - name: cloud1 events: collectors: - collectorType: collectd subscriptionAddress: collectd/cloud1-notify - collectorType: ceilometer subscriptionAddress: anycast/ceilometer/cloud1-event.sample metrics: collectors: - collectorType: collectd subscriptionAddress: collectd/cloud1-telemetry - collectorType: sensubility subscriptionAddress: sensubility/cloud1-telemetry - collectorType: ceilometer subscriptionAddress: anycast/ceilometer/cloud1-metering.sample - name: cloud2 events: ...- ServiceTelemetry 오브젝트를 저장합니다.
각 스마트 게이트웨이가 실행 중인지 확인합니다. 스마트 게이트웨이 수에 따라 몇 분이 걸릴 수 있습니다.
$ oc get po -l app=smart-gateway NAME READY STATUS RESTARTS AGE default-cloud1-ceil-event-smartgateway-6cfb65478c-g5q82 2/2 Running 0 13h default-cloud1-ceil-meter-smartgateway-58f885c76d-xmxwn 2/2 Running 0 13h default-cloud1-coll-event-smartgateway-58fbbd4485-rl9bd 2/2 Running 0 13h default-cloud1-coll-meter-smartgateway-7c6fc495c4-jn728 2/2 Running 0 13h default-cloud1-sens-meter-smartgateway-8h4tc445a2-mm683 2/2 Running 0 13h
4.4.3. 기본 스마트 게이트웨이 삭제
여러 클라우드에 대해 Service Telemetry Framework(STF)를 구성한 후 더 이상 사용하지 않는 경우 기본 Smart Gateway를 삭제할 수 있습니다. Service Telemetry Operator는 생성된 SmartGateway 오브젝트를 제거할 수 있지만 더 이상 ServiceTelemetry 클라우드 목록에 나열되지 않습니다. clouds 매개변수로 정의되지 않은 SmartGateway 오브젝트를 제거하려면 ServiceTelemetry 매니페스트에서 cloudsRemoveOnMissing 매개변수를 true 로 설정해야 합니다.
Smart Gateway를 배포하지 않으려면 Cloud : [] 매개변수를 사용하여 빈 클라우드 목록을 정의합니다.
cloudsRemoveOnMissing 매개변수는 기본적으로 비활성화되어 있습니다. cloudsRemoveOnMissing 매개변수를 활성화하면 현재 네임스페이스에서 수동으로 생성된 SmartGateway 오브젝트를 복원할 수 없습니다.
절차
-
Service Telemetry Operator에서 관리할 클라우드 오브젝트 목록으로
clouds매개변수를 정의합니다. 자세한 내용은 “clouds 매개변수”의 내용을 참조하십시오. ServiceTelemetry 오브젝트를 편집하고
cloudsRemoveOnMissing매개변수를 추가합니다.apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: ... spec: ... cloudsRemoveOnMissing: true clouds: ...- 수정 사항을 저장합니다.
Operator가 스마트 게이트웨이를 삭제했는지 확인합니다. Operator에서 변경 사항을 조정하는 데 몇 분이 걸릴 수 있습니다.
$ oc get smartgateways
4.4.4. 고유한 클라우드 도메인 설정
AMQ Interconnect 라우터 연결을 RHOSP(Red Hat OpenStack Platform)에서 Service Telemetry Framework(STF)로의 라우터 연결이 고유하고 충돌하지 않도록 CloudDomain 매개변수를 구성합니다.
절차
-
새 환경 파일(예: hostnames
.yaml)을 생성합니다. 다음 예와 같이 환경 파일에서
CloudDomain매개변수를 설정합니다.hostnames.yaml
parameter_defaults: CloudDomain: newyork-west-04 CephStorageHostnameFormat: 'ceph-%index%' ObjectStorageHostnameFormat: 'swift-%index%' ComputeHostnameFormat: 'compute-%index%'- 새 환경 파일을 배포에 추가합니다.
4.4.5. 여러 클라우드를 위한 Red Hat OpenStack Platform 환경 파일 생성
원본 클라우드에 따라 트래픽에 레이블을 지정하려면 클라우드별 인스턴스 이름으로 구성을 생성해야 합니다. stf-connectors.yaml 파일을 만들고 AMQP 주소 접두사 스키마와 일치하도록 CeilometerQdrEventsConfig,CeilometerQdrMetricsConfig 및 CollectdAmqpInstances의 값을 조정합니다.
컨테이너 상태 및 API 상태 모니터링을 활성화한 경우 CollectdSensubilityResultsChannel 매개변수도 수정해야 합니다. 자세한 내용은 5.9절. “Red Hat OpenStack Platform API 상태 및 컨테이너화된 서비스 상태”의 내용을 참조하십시오.
사전 요구 사항
- STF가 배포한 AMQ Interconnect에서 CA 인증서를 검색했습니다. 자세한 내용은 4.1.1절. “오버클라우드 설정을 위해 Service Telemetry Framework에서 CA 인증서 가져오기”의 내용을 참조하십시오.
- 클라우드 오브젝트 목록을 생성했습니다. clouds 매개변수의 콘텐츠를 생성하는 방법에 대한 자세한 내용은 cloud 구성 매개변수 를 참조하십시오.
- AMQ Interconnect 경로 주소를 검색했습니다. 자세한 내용은 4.1.2절. “AMQ Interconnect 경로 주소 검색”의 내용을 참조하십시오.
- STF에 대한 기본 구성을 생성했습니다. 자세한 내용은 4.1.3절. “STF에 대한 기본 구성 생성”의 내용을 참조하십시오.
- 고유한 도메인 이름 환경 파일을 생성했습니다. 자세한 내용은 4.4.4절. “고유한 클라우드 도메인 설정”의 내용을 참조하십시오.
절차
-
stack사용자로 Red Hat OpenStack Platform 언더클라우드에 로그인합니다. -
/home/stack디렉터리에stf-connectors.yaml구성 파일을 생성합니다. stf-connectors.yaml파일에서 오버클라우드 배포의 AMQ Interconnect에 연결하도록MetricsQdrConnectors주소를 구성합니다. 이 클라우드 배포에 원하는 AMQP 주소와 일치하도록주제 값을 구성합니다.CeilometerQdrEventsConfig, CeilometerQdrMetricsConfig,CollectdAmqpInstances및 CollectdSensubilityResultsChannelcaCertFileContent매개변수를 4.1.1절. “오버클라우드 설정을 위해 Service Telemetry Framework에서 CA 인증서 가져오기” 에서 검색된 콘텐츠로 바꿉니다.STF-connectors.yaml
resource_registry: OS::TripleO::Services::Collectd: /usr/share/openstack-tripleo-heat-templates/deployment/metrics/collectd-container-puppet.yaml 1 parameter_defaults: MetricsQdrConnectors: - host: stf-default-interconnect-5671-service-telemetry.apps.infra.watch 2 port: 443 role: edge verifyHostname: false sslProfile: sslProfile MetricsQdrSSLProfiles: - name: sslProfile caCertFileContent: | ----BEGIN CERTIFICATE---- <snip> ----END CERTIFICATE---- CeilometerQdrEventsConfig: driver: amqp topic: cloud1-event 3 CeilometerQdrMetricsConfig: driver: amqp topic: cloud1-metering 4 CollectdAmqpInstances: cloud1-notify: 5 notify: true format: JSON presettle: false cloud1-telemetry: 6 format: JSON presettle: false CollectdSensubilityResultsChannel: sensubility/cloud1-telemetry 7
- 1
- 여러 클라우드 배포에 대한
collectd-write-qdr.yaml환경 파일을 포함하지 않으므로 collectd 서비스를 직접 로드합니다. - 2
- 3
- Ceilometer 이벤트에 대한 주제를 정의합니다. 이 값은
anycast/ceilometer/cloud1-event.sample의 주소 형식입니다. - 4
- Ceilometer 메트릭에 대한 주제를 정의합니다. 이 값은
anycast/ceilometer/cloud1-metering.sample의 주소 형식입니다. - 5
- collectd 이벤트에 대한 주제를 정의합니다. 이 값은
collectd/cloud1-notify형식입니다. - 6
- collectd 메트릭에 대한 주제를 정의합니다. 이 값은
collectd/cloud1-telemetry형식입니다. - 7
- collectd-sensubility 이벤트에 대한 주제를 정의합니다. 이 값이 정확한 문자열 형식 Sensu
bility/cloud1-telemetry인지 확인하십시오.
-
stf-connectors.yaml파일의 이름 지정 규칙이 Smart Gateway 구성의spec.bridge.amqpUrl필드와 일치하는지 확인합니다. 예를 들어CeilometerQdrEventsConfig.topic필드를cloud1-event값으로 구성합니다. 인증 파일을 소싱합니다.
[stack@undercloud-0 ~]$ source stackrc (undercloud) [stack@undercloud-0 ~]$
사용자 환경과 관련된 기타 환경 파일과 함께
openstack overcloud deployment명령에stf-connectors파일과 고유한 도메인 이름 환경 파일 hostnames.yaml을 포함합니다..yaml주의사용자 지정
CollectdAmqpInstances매개변수와 함께collectd-write-qdr.yaml파일을 사용하는 경우 사용자 지정 및 기본 항목에 데이터를 게시합니다. 여러 클라우드 환경에서stf-connectors.yaml파일의resource_registry매개변수 구성은 collectd 서비스를 로드합니다.(undercloud) [stack@undercloud-0 ~]$ openstack overcloud deploy <other_arguments> --templates /usr/share/openstack-tripleo-heat-templates \ --environment-file <...other_environment_files...> \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/ceilometer-write-qdr.yaml \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/qdr-edge-only.yaml \ --environment-file /home/stack/hostnames.yaml \ --environment-file /home/stack/enable-stf.yaml \ --environment-file /home/stack/stf-connectors.yaml
- Red Hat OpenStack Platform 오버클라우드를 배포합니다.
4.4.5.1. Ansible 기반 Service Telemetry Framework 배포
이 기능은 이번 릴리스에서 기술 프리뷰로 제공되므로 Red Hat에서 완전히 지원되지 않습니다. 테스트 용도로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.
wallaby/OSP17.0부터STF(Service Telemetry Framework) 구성 요소를 배포하는 데 Puppet 대신 Ansible 사용을 미리 볼 수 있습니다. Ansible 사용은 다음과 같은 이점이 있습니다.
- 단일 서비스별 THT 변수 아래 구성 통합 (MetricsQdrVars 및 CollectdVars)
- QDR 모드를 메시 모드에서 엣지 전용으로 전환하는 기능
- 배포 스택에 사용된 기술 수가 줄어들어 더 간단한 디버그 프로세스가 생성됩니다.
Ansible 기반 배포를 사용하려면 stf-connectors.yaml 파일의 resource_registry 섹션에 있는 "puppet" 대신 "ansible"이라는 단어를 대체합니다.
OS::TripleO::Services::Collectd: /usr/share/openstack-tripleo-heat-templates/deployment/metrics/collectd-container-ansible.yaml
OS::TripleO::Services::MetricsQdr: /usr/share/openstack-tripleo-heat-templates/deployment/metrics/qdr-container-ansible.yaml구성을 설정하려면 다음 예와 같이 새 서비스별 THT 변수를 사용합니다.
parameter_defaults:
MetricsQdrVars:
tripleo_metrics_qdr_deployment_mode: edge-only
CollectdVars:
tripleo_collectd_amqp_host: stf.mycluster.example.com지원되는 구성 매개변수의 전체 목록은 위에서 언급한 배포 파일에서 확인할 수 있습니다. https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/deployment/metrics/qdr-container-ansible.yaml#L172
추가 리소스
- 배포를 확인하는 방법에 대한 자세한 내용은 4.1.6절. “클라이언트 측 설치 검증” 을 참조하십시오.
4.4.6. 여러 클라우드에서 메트릭 데이터 쿼리
Prometheus에 저장된 데이터에는 스크랩된 Smart Gateway에 따라 서비스 레이블이 있습니다. 이 레이블을 사용하여 특정 클라우드의 데이터를 쿼리할 수 있습니다.
특정 클라우드의 데이터를 쿼리하려면 관련 서비스 레이블과 일치하는 Prometheus promql 쿼리를 사용합니다(예: collectd_uptime{service="default-cloud1-coll-meter"}).
5장. Service Telemetry Framework의 운영 기능 사용
다음 운영 기능을 사용하여 Service Telemetry Framework(STF)에 추가 기능을 제공할 수 있습니다.
5.1. Service Telemetry Framework의 대시보드
타사 애플리케이션 Grafana를 사용하여 각 개별 호스트 노드에 대해 collectd 및 Ceilometer에서 수집하는 시스템 수준 지표를 시각화합니다.
collectd 구성에 대한 자세한 내용은 4.1절. “Service Telemetry Framework용 Red Hat OpenStack Platform 오버클라우드 배포” 을 참조하십시오.
두 개의 대시보드를 사용하여 클라우드를 모니터링할 수 있습니다.
- 인프라 대시보드
- 인프라 대시보드를 사용하여 한 번에 단일 노드의 지표를 확인합니다. 대시보드의 왼쪽 상단 모서리에서 노드를 선택합니다.
- 클라우드 보기 대시보드
클라우드 보기 대시보드를 사용하여 서비스 리소스 사용량, API 통계 및 클라우드 이벤트를 모니터링하기 위한 패널을 확인합니다. 이 대시보드에 대한 데이터를 제공하기 위해 API 상태 모니터링 및 서비스 모니터링을 활성화해야 합니다. API 상태 모니터링은 STF 기본 구성에서 기본적으로 활성화됩니다. 자세한 내용은 4.1.3절. “STF에 대한 기본 구성 생성”의 내용을 참조하십시오.
- API 상태 모니터링에 대한 자세한 내용은 5.9절. “Red Hat OpenStack Platform API 상태 및 컨테이너화된 서비스 상태” 을 참조하십시오.
- RHOSP 서비스 모니터링에 대한 자세한 내용은 5.8절. “Red Hat OpenStack Platform 서비스의 리소스 사용량” 을 참조하십시오.
5.1.1. 대시보드를 호스팅하도록 Grafana 구성
Grafana는 기본 Service Telemetry Framework(STF) 배포에 포함되어 있지 않으므로 OperatorHub.io에서 Grafana Operator를 배포해야 합니다. Service Telemetry Operator를 사용하여 Grafana를 배포할 때 Grafana 인스턴스가 생성되고 로컬 STF 배포에 대한 기본 데이터 소스 구성이 생성됩니다.
절차
- Red Hat OpenShift Container Platform에 로그인합니다.
service-telemetry네임스페이스로 변경합니다.$ oc project service-telemetry
Grafana Operator를 배포합니다.
$ oc apply -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: grafana-operator namespace: service-telemetry spec: channel: alpha installPlanApproval: Automatic name: grafana-operator source: operatorhubio-operators sourceNamespace: openshift-marketplace EOF
Operator가 성공적으로 시작되었는지 확인합니다. 명령 출력에서
PHASE열의 값이Succeeded이면 Operator가 성공적으로 시작되었습니다.$ oc get csv --selector operators.coreos.com/grafana-operator.service-telemetry NAME DISPLAY VERSION REPLACES PHASE grafana-operator.v3.10.3 Grafana Operator 3.10.3 grafana-operator.v3.10.2 Succeeded
Grafana 인스턴스를 시작하려면
ServiceTelemetry오브젝트를 생성하거나 수정합니다.graphing.enabled및graphing.grafana.ingressEnabled를true로 설정합니다.$ oc edit stf default apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry ... spec: ... graphing: enabled: true grafana: ingressEnabled: trueGrafana 인스턴스가 배포되었는지 확인합니다.
$ oc get pod -l app=grafana NAME READY STATUS RESTARTS AGE grafana-deployment-7fc7848b56-sbkhv 1/1 Running 0 1m
Grafana 데이터 소스가 올바르게 설치되었는지 확인합니다.
$ oc get grafanadatasources NAME AGE default-datasources 20h
Grafana 경로가 있는지 확인합니다.
$ oc get route grafana-route NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD grafana-route grafana-route-service-telemetry.apps.infra.watch grafana-service 3000 edge None
5.1.2. 기본 Grafana 컨테이너 이미지 덮어쓰기
Service Telemetry Framework(STF)의 대시보드에는 Grafana 버전 8.1.0 이상에서만 사용할 수 있는 기능이 필요합니다. 기본적으로 Service Telemetry Operator는 호환 버전을 설치합니다. 그래프.grafana.baseImage 를 사용하여 이미지 레지스트리에 대한 이미지 경로를 지정하여 기본 Grafana 이미지를 덮어쓸 수 있습니다.
절차
Grafana의 올바른 버전이 있는지 확인합니다.
$ oc get pod -l "app=grafana" -ojsonpath='{.items[0].spec.containers[0].image}' docker.io/grafana/grafana:7.3.10실행 중인 이미지가 8.1.0보다 오래된 경우 ServiceTelemetry 오브젝트를 패치하여 이미지를 업데이트합니다. Service Telemetry Operator는 Grafana 배포를 다시 시작하는 Grafana 매니페스트를 업데이트합니다.
$ oc patch stf/default --type merge -p '{"spec":{"graphing":{"grafana":{"baseImage":"docker.io/grafana/grafana:8.1.5"}}}}'새 Grafana 포드가 존재하고
Running의STATUS값이 있는지 확인합니다.$ oc get pod -l "app=grafana" NAME READY STATUS RESTARTS AGE grafana-deployment-fb9799b58-j2hj2 1/1 Running 0 10s
새 인스턴스가 업데이트된 이미지를 실행 중인지 확인합니다.
$ oc get pod -l "app=grafana" -ojsonpath='{.items[0].spec.containers[0].image}' docker.io/grafana/grafana:8.1.0
5.1.3. 대시보드 가져오기
Grafana Operator는 GrafanaDashboard 오브젝트를 생성하여 대시보드를 가져오고 관리할 수 있습니다. https://github.com/infrawatch/dashboards 에서 예제 대시보드를 볼 수 있습니다.
절차
인프라 대시보드를 가져옵니다.
$ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/rhos-dashboard.yaml grafanadashboard.integreatly.org/rhos-dashboard-1.3 created
클라우드 대시보드를 가져옵니다.
주의클라우드 대시보드의 일부 패널의 경우 collectd
virt플러그인 매개변수hostname_format의 값을stf-connectors.yaml파일에서이름을 uuid 호스트이름으로 설정해야 합니다. 이 매개변수를 구성하지 않으면 영향을 받는 대시보드는 비어 있습니다.virt플러그인에 대한 자세한 내용은 collectd 플러그인을 참조하십시오.$ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/rhos-cloud-dashboard.yaml grafanadashboard.integreatly.org/rhos-cloud-dashboard-1.3 created
클라우드 이벤트 대시보드를 가져옵니다.
$ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/rhos-cloudevents-dashboard.yaml grafanadashboard.integreatly.org/rhos-cloudevents-dashboard created
가상 머신 대시보드를 가져옵니다.
$ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/virtual-machine-view.yaml grafanadashboard.integreatly.org/virtual-machine-view-1.3 configured
memcached 대시보드를 가져옵니다.
$ oc apply -f https://raw.githubusercontent.com/infrawatch/dashboards/master/deploy/stf-1.3/memcached-dashboard.yaml grafanadashboard.integreatly.org/memcached-dashboard-1.3 created
대시보드를 사용할 수 있는지 확인합니다.
$ oc get grafanadashboards NAME AGE memcached-dashboard-1.3 115s rhos-cloud-dashboard-1.3 2m12s rhos-cloudevents-dashboard 2m6s rhos-dashboard-1.3 2m17s virtual-machine-view-1.3 2m
Grafana 경로 주소를 검색합니다.
$ oc get route grafana-route -ojsonpath='{.spec.host}' grafana-route-service-telemetry.apps.infra.watch- 웹 브라우저에서 https://<grafana_route_address> 로 이동합니다. <grafana_route_address> 를 이전 단계에서 검색한 값으로 바꿉니다.
- 대시보드를 보려면 대시보드 및 관리를 클릭합니다.
5.1.4. Grafana 로그인 자격 증명 검색 및 설정
서비스 Telemetry Framework(STF)는 Grafana가 활성화되면 기본 로그인 자격 증명을 설정합니다. ServiceTelemetry 오브젝트에서 인증 정보를 재정의할 수 있습니다.
절차
- Red Hat OpenShift Container Platform에 로그인합니다.
service-telemetry네임스페이스로 변경합니다.$ oc project service-telemetry
STF 오브젝트에서 기본 사용자 이름과 암호를 검색합니다.
$ oc get stf default -o jsonpath="{.spec.graphing.grafana['adminUser','adminPassword']}"-
ServiceTelemetry 오브젝트를 통해 Grafana 관리자 사용자 이름 및 암호의 기본값을 수정하려면
graphing.grafana.adminUser 및매개변수를 사용합니다.graphing.grafana.adminPassword
5.2. Service Telemetry Framework의 메트릭 보존 시간
Service Telemetry Framework(STF)에 저장된 메트릭의 기본 보존 시간은 경고 목적으로 발전할 수 있는 충분한 데이터를 제공하는 24시간입니다.
장기 스토리지의 경우, 장기 데이터 보존을 위해 설계된 시스템을 사용합니다(예: Thanos).
추가 리소스
- 추가 지표 보존 시간을 위해 STF를 조정하려면 5.2.1절. “Service Telemetry Framework에서 메트릭 보존 기간 편집” 을 참조하십시오.
- Prometheus 데이터 스토리지 및 스토리지 공간에 대한 권장 사항은 https://prometheus.io/docs/prometheus/latest/storage/#operational-aspects을 참조하십시오.
- Thanos에 대한 자세한 내용은 https://thanos.io/를 참조하십시오.
5.2.1. Service Telemetry Framework에서 메트릭 보존 기간 편집
추가 지표 보존 시간을 위해 Service Telemetry Framework(STF)를 조정할 수 있습니다.
절차
- Red Hat OpenShift Container Platform에 로그인합니다.
service-telemetry 네임스페이스로 변경합니다.
$ oc project service-telemetry
ServiceTelemetry 오브젝트를 편집합니다.
$ oc edit stf default
retention을 추가합니다. 보존 기간을 7일로 늘리려면 7Dbackends.metrics.prometheus.storage의 스토리지 섹션으로 이동합니다.참고장기간 보관 기간을 설정하면 많이 채워진 Prometheus 시스템에서 데이터를 검색하면 쿼리에서 결과를 느리게 반환할 수 있습니다.
apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: stf-default namespace: service-telemetry spec: ... backends: metrics: prometheus: enabled: true storage: strategy: persistent retention: 7d ...- 변경 사항을 저장하고 오브젝트를 종료합니다.
추가 리소스
- 메트릭 보존 시간에 대한 자세한 내용은 5.2절. “Service Telemetry Framework의 메트릭 보존 시간” 을 참조하십시오.
5.3. Service Telemetry Framework의 경고
Prometheus에서 경고 규칙을 만들고 Alertmanager의 경고 경로를 생성합니다. Prometheus 서버의 경고 규칙은 경고를 관리하는 Alertmanager에 경고를 보냅니다. Alertmanager는 이메일, 전화 알림 시스템 또는 대화 플랫폼을 사용하여 경고를 음소거, 억제 또는 집계할 수 있습니다.
경고를 생성하려면 다음 작업을 완료합니다.
- Prometheus에서 경고 규칙을 만듭니다. 자세한 내용은 5.3.1절. “Prometheus에서 경고 규칙 생성”의 내용을 참조하십시오.
Alertmanager에서 경고 경로를 만듭니다. 경고 경로를 생성하는 방법은 다음 두 가지입니다.
추가 리소스
Prometheus 및 Alertmanager를 통한 경고 또는 알림에 대한 자세한 내용은 https://prometheus.io/docs/alerting/overview/을 참조하십시오.
Service Telemetry Framework(STF)와 함께 사용할 수 있는 경고 예제를 보려면 https://github.com/infrawatch/service-telemetry-operator/tree/master/deploy/alerts을 참조하십시오.
5.3.1. Prometheus에서 경고 규칙 생성
Prometheus는 알림을 트리거하기 위해 경고 규칙을 평가합니다. 규칙 조건이 빈 결과 집합을 반환하는 경우 조건이 false입니다. 그렇지 않으면 규칙이 true이고 경고가 트리거됩니다.
절차
- Red Hat OpenShift Container Platform에 로그인합니다.
service-telemetry네임스페이스로 변경합니다.$ oc project service-telemetry
경고 규칙이 포함된
PrometheusRule오브젝트를 생성합니다. Prometheus Operator는 규칙을 Prometheus로 로드합니다.$ oc apply -f - <<EOF apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: creationTimestamp: null labels: prometheus: default role: alert-rules name: prometheus-alarm-rules namespace: service-telemetry spec: groups: - name: ./openstack.rules rules: - alert: Collectd metrics receive rate is zero expr: rate(sg_total_collectd_msg_received_count[1m]) == 0 1 EOF- 1
- 규칙을 변경하려면
expr매개변수 값을 편집합니다.
Operator가 규칙을 Prometheus에 로드했는지 확인하려면 기본 인증을 사용하여 default-prometheus-proxy 경로에 대해
curl명령을 실행합니다.$ curl -k --user "internal:$(oc get secret default-prometheus-htpasswd -ogo-template='{{ .data.password | base64decode }}')" https://$(oc get route default-prometheus-proxy -ogo-template='{{ .spec.host }}')/api/v1/rules {"status":"success","data":{"groups":[{"name":"./openstack.rules","file":"/etc/prometheus/rules/prometheus-default-rulefiles-0/service-telemetry-prometheus-alarm-rules.yaml","rules":[{"state":"inactive","name":"Collectd metrics receive count is zero","query":"rate(sg_total_collectd_msg_received_count[1m]) == 0","duration":0,"labels":{},"annotations":{},"alerts":[],"health":"ok","evaluationTime":0.00034627,"lastEvaluation":"2021-12-07T17:23:22.160448028Z","type":"alerting"}],"interval":30,"evaluationTime":0.000353787,"lastEvaluation":"2021-12-07T17:23:22.160444017Z"}]}}
추가 리소스
- 경고에 대한 자세한 내용은 https://github.com/coreos/prometheus-operator/blob/master/Documentation/user-guides/alerting.md을 참조하십시오.
5.3.2. 사용자 정의 경고 구성
5.3.1절. “Prometheus에서 경고 규칙 생성” 에서 생성한 PrometheusRule 오브젝트에 사용자 정의 경고를 추가할 수 있습니다.
절차
oc edit명령을 사용합니다.$ oc edit prometheusrules prometheus-alarm-rules
-
PrometheusRules매니페스트를 편집합니다. - 매니페스트를 저장하고 종료합니다.
추가 리소스
- 경고 규칙 구성 방법에 대한 자세한 내용은 https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/ 을 참조하십시오.
- PrometheusRules 오브젝트에 대한 자세한 내용은 https://github.com/coreos/prometheus-operator/blob/master/Documentation/user-guides/alerting.md을 참조하십시오.
5.3.3. Alertmanager에서 표준 경고 경로 생성
Alertmanager를 사용하여 이메일, IRC 또는 기타 알림 채널과 같은 외부 시스템에 경고를 전달합니다. Prometheus Operator는 Alertmanager 설정을 Red Hat OpenShift Container Platform 시크릿으로 관리합니다. 기본적으로 Service Telemetry Framework(STF)는 수신자가 없는 기본 구성을 배포합니다.
alertmanager.yaml: |-
global:
resolve_timeout: 5m
route:
group_by: ['job']
group_wait: 30s
group_interval: 5m
repeat_interval: 12h
receiver: 'null'
receivers:
- name: 'null'
STF를 사용하여 사용자 정의 Alertmanager 경로를 배포하려면 Prometheus Operator에서 관리하는 업데이트된 보안을 생성하는 alertmanagerConfigManifest 매개변수를 Service Telemetry Operator에 전달해야 합니다.
alertmanagerConfigManifest 에 전송된 경고의 제목과 텍스트를 구성하는 사용자 정의 템플릿이 포함된 경우 base64 인코딩 구성을 사용하여 alertmanagerConfigManifest 의 콘텐츠를 배포합니다. 자세한 내용은 5.3.4절. “Alertmanager에서 템플릿로 경고 경로 생성”의 내용을 참조하십시오.
절차
- Red Hat OpenShift Container Platform에 로그인합니다.
service-telemetry네임스페이스로 변경합니다.$ oc project service-telemetry
STF 배포의
ServiceTelemetry오브젝트를 편집합니다.$ oc edit stf default
새 매개변수
alertmanagerConfigManifest및Secret오브젝트 콘텐츠를 추가하여 Alertmanager에 대한alertmanager.yaml구성을 정의합니다.참고이 단계에서는 Service Telemetry Operator에서 관리하는 기본 템플릿을 로드합니다. 변경 사항이 올바르게 채워지는지 확인하려면 값을 변경하고
alertmanager-default보안을 반환하고 새 값이 메모리에 로드되었는지 확인합니다. 예를 들어전역.resolve_timeout매개변수의 값을5m에서로 변경합니다.10mapiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: backends: metrics: prometheus: enabled: true alertmanagerConfigManifest: | apiVersion: v1 kind: Secret metadata: name: 'alertmanager-default' namespace: 'service-telemetry' type: Opaque stringData: alertmanager.yaml: |- global: resolve_timeout: 10m route: group_by: ['job'] group_wait: 30s group_interval: 5m repeat_interval: 12h receiver: 'null' receivers: - name: 'null'구성이 보안에 적용되었는지 확인합니다.
$ oc get secret alertmanager-default -o go-template='{{index .data "alertmanager.yaml" | base64decode }}' global: resolve_timeout: 10m route: group_by: ['job'] group_wait: 30s group_interval: 5m repeat_interval: 12h receiver: 'null' receivers: - name: 'null'alertmanager-proxy서비스에 대해curl명령을 실행하여 상태 및configYAML콘텐츠를 검색하고 제공된 구성이 Alertmanager의 구성과 일치하는지 확인합니다.$ oc run curl -it --serviceaccount=prometheus-k8s --restart='Never' --image=radial/busyboxplus:curl -- sh -c "curl -k -H \"Content-Type: application/json\" -H \"Authorization: Bearer \$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)\" https://default-alertmanager-proxy:9095/api/v1/status" {"status":"success","data":{"configYAML":"...",...}}-
configYAML필드에 예상 변경 사항이 포함되어 있는지 확인합니다. 환경을 정리하려면
curlPod를 삭제합니다.$ oc delete pod curl pod "curl" deleted
추가 리소스
- Red Hat OpenShift Container Platform 시크릿 및 Prometheus Operator에 대한 자세한 내용은 경고에 대한 Prometheus 사용자 가이드를 참조하십시오.
5.3.4. Alertmanager에서 템플릿로 경고 경로 생성
Alertmanager를 사용하여 이메일, IRC 또는 기타 알림 채널과 같은 외부 시스템에 경고를 전달합니다. Prometheus Operator는 Alertmanager 설정을 Red Hat OpenShift Container Platform 시크릿으로 관리합니다. 기본적으로 Service Telemetry Framework(STF)는 수신자가 없는 기본 구성을 배포합니다.
alertmanager.yaml: |-
global:
resolve_timeout: 5m
route:
group_by: ['job']
group_wait: 30s
group_interval: 5m
repeat_interval: 12h
receiver: 'null'
receivers:
- name: 'null'
alertmanagerConfigManifest 매개변수에 예를 들어 전송된 경고의 제목과 텍스트를 구성하는 사용자 지정 템플릿이 포함된 경우 base64로 인코딩된 구성을 사용하여 alertmanagerConfigManifest 의 콘텐츠를 배포합니다.
절차
- Red Hat OpenShift Container Platform에 로그인합니다.
service-telemetry네임스페이스로 변경합니다.$ oc project service-telemetry
STF 배포의
ServiceTelemetry오브젝트를 편집합니다.$ oc edit stf default
STF를 사용하여 사용자 정의 Alertmanager 경로를 배포하려면 Prometheus Operator에서 관리하는 업데이트된 보안을 생성하는
alertmanagerConfigManifest매개변수를 Service Telemetry Operator에 전달해야 합니다.apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: backends: metrics: prometheus: enabled: true alertmanagerConfigManifest: | apiVersion: v1 kind: Secret metadata: name: 'alertmanager-default' namespace: 'service-telemetry' type: Opaque data: alertmanager.yaml: Z2xvYmFsOgogIHJlc29sdmVfdGltZW91dDogMTBtCiAgc2xhY2tfYXBpX3VybDogPHNsYWNrX2FwaV91cmw+CnJlY2VpdmVyczoKICAtIG5hbWU6IHNsYWNrCiAgICBzbGFja19jb25maWdzOgogICAgLSBjaGFubmVsOiAjc3RmLWFsZXJ0cwogICAgICB0aXRsZTogfC0KICAgICAgICAuLi4KICAgICAgdGV4dDogPi0KICAgICAgICAuLi4Kcm91dGU6CiAgZ3JvdXBfYnk6IFsnam9iJ10KICBncm91cF93YWl0OiAzMHMKICBncm91cF9pbnRlcnZhbDogNW0KICByZXBlYXRfaW50ZXJ2YWw6IDEyaAogIHJlY2VpdmVyOiAnc2xhY2snCg==구성이 보안에 적용되었는지 확인합니다.
$ oc get secret alertmanager-default -o go-template='{{index .data "alertmanager.yaml" | base64decode }}' global: resolve_timeout: 10m slack_api_url: <slack_api_url> receivers: - name: slack slack_configs: - channel: #stf-alerts title: |- ... text: >- ... route: group_by: ['job'] group_wait: 30s group_interval: 5m repeat_interval: 12h receiver: 'slack'alertmanager-proxy서비스에 대해curl명령을 실행하여 상태 및configYAML콘텐츠를 검색하고 제공된 구성이 Alertmanager의 구성과 일치하는지 확인합니다.$ oc run curl -it --serviceaccount=prometheus-k8s --restart='Never' --image=radial/busyboxplus:curl -- sh -c "curl -k -H \"Content-Type: application/json\" -H \"Authorization: Bearer \$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)\" https://default-alertmanager-proxy:9095/api/v1/status" {"status":"success","data":{"configYAML":"...",...}}-
configYAML필드에 예상 변경 사항이 포함되어 있는지 확인합니다. 환경을 정리하려면
curlPod를 삭제합니다.$ oc delete pod curl pod "curl" deleted
추가 리소스
- Red Hat OpenShift Container Platform 시크릿 및 Prometheus Operator에 대한 자세한 내용은 경고에 대한 Prometheus 사용자 가이드를 참조하십시오.
5.4. ECDHE 트랩 구성
SNMP 트랩을 통해 알림을 수신하는 기존 인프라 모니터링 플랫폼과STF(Service Telemetry Framework)를 통합할 수 있습니다. ECDHE 트랩을 활성화하려면 ServiceTelemetry 오브젝트를 수정하고 the snmpTraps 매개변수를 구성합니다.
경고 구성에 대한 자세한 내용은 5.3절. “Service Telemetry Framework의 경고” 을 참조하십시오.
사전 요구 사항
- 알림을 보내려는 hieradata 트랩 수신자의 IP 주소 또는 호스트 이름을 알 수 있습니다.
절차
ECDHE 트랩을 활성화하려면
ServiceTelemetry오브젝트를 수정합니다.$ oc edit stf default
alert.alertmanager.receivers.snmpTraps매개변수를 설정합니다.apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry ... spec: ... alerting: alertmanager: receivers: snmpTraps: enabled: true target: 10.10.10.10-
target값을ECDHE 트랩 수신자의 IP 주소 또는 호스트 이름으로 설정해야 합니다.
5.5. 고가용성
고가용성을 통해 Service Telemetry Framework (STF)는 구성 요소 서비스의 장애로부터 신속하게 복구할 수 있습니다. Red Hat OpenShift Container Platform은 워크로드를 예약하는 데 노드를 사용할 수 있는 경우 실패한 Pod를 재시작하지만 이 복구 프로세스는 이벤트 및 메트릭이 손실되는 데 1분 이상 걸릴 수 있습니다. 고가용성 구성에는 여러 STF 구성 요소 복사본이 포함되어 있으므로 복구 시간이 약 2초로 단축됩니다. Red Hat OpenShift Container Platform 노드의 장애를 보호하려면 3개 이상의 노드가 있는 Red Hat OpenShift Container Platform 클러스터에 STF를 배포합니다.
STF는 아직 완전한 내결함성 시스템이 아닙니다. 복구 기간 동안 메트릭 및 이벤트 제공은 보장되지 않습니다.
고가용성을 활성화하면 다음과 같은 효과가 있습니다.
- 기본 Pod 대신 세 개의 ElasticSearch Pod가 실행됩니다.
다음 구성 요소는 기본 구성 요소 대신 두 개의 Pod를 실행합니다.
- AMQ Interconnect
- Alertmanager
- Prometheus
- 이벤트 스마트 게이트웨이
- 메트릭 스마트 게이트웨이
- 이러한 서비스에서 손실된 pod에서 복구 시간은 약 2초로 단축됩니다.
5.5.1. 고가용성 구성
고가용성을 위해 Service Telemetry Framework(STF)를 구성하려면 Red Hat OpenShift Container Platform의 ServiceTelemetry 오브젝트에 highAvailability.enabled: true 를 추가합니다. 설치 시 이 매개변수를 설정하거나 STF를 이미 배포한 경우 다음 단계를 완료할 수 있습니다.
절차
- Red Hat OpenShift Container Platform에 로그인합니다.
service-telemetry네임스페이스로 변경합니다.$ oc project service-telemetry
oc 명령을 사용하여 ServiceTelemetry 오브젝트를 편집합니다.
$ oc edit stf default
spec섹션에highAvailability.enabled: true를 추가합니다.apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry ... spec: ... highAvailability: enabled: true- 변경 사항을 저장하고 오브젝트를 종료합니다.
5.6. 임시 스토리지
임시 스토리지를 사용하여 Red Hat OpenShift Container Platform 클러스터에 데이터를 지속적으로 저장하지 않고도 Service Telemetry Framework (STF)를 실행할 수 있습니다.
임시 스토리지를 사용하는 경우 Pod가 다른 노드에 다시 시작, 업데이트 또는 다시 예약되면 데이터 손실이 발생할 수 있습니다. 프로덕션 환경이 아닌 개발 또는 테스트에만 임시 스토리지를 사용합니다.
5.6.1. 임시 스토리지 구성
임시 스토리지에 대한 STF 구성 요소를 구성하려면 해당 매개변수에 .storage.strategy: ephemeral 를 추가합니다. 예를 들어 Prometheus 백엔드에 임시 스토리지를 활성화하려면 backends.metrics.prometheus.storage.strategy: ephemeral 를 설정합니다. 임시 스토리지 구성을 지원하는 구성 요소에는 alert.alertmanager,backends.metrics.prometheus, backends.events.elasticsearch 가 포함됩니다. 설치 시 임시 스토리지 구성을 추가하거나 이미 STF를 배포한 경우 다음 단계를 완료할 수 있습니다.
절차
- Red Hat OpenShift Container Platform에 로그인합니다.
service-telemetry네임스페이스로 변경합니다.$ oc project service-telemetry
ServiceTelemetry 오브젝트를 편집합니다.
$ oc edit stf default
관련 구성 요소의
spec섹션에...storage.strategy: ephemeral매개변수를 추가합니다.apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: stf-default namespace: service-telemetry spec: alerting: enabled: true alertmanager: storage: strategy: ephemeral backends: metrics: prometheus: enabled: true storage: strategy: ephemeral events: elasticsearch: enabled: true storage: strategy: ephemeral- 변경 사항을 저장하고 오브젝트를 종료합니다.
5.7. Service Telemetry Framework의 관찰 전략
Service Telemetry Framework (STF)에는 스토리지 백엔드 및 경고 도구가 포함되어 있지 않습니다. STF는 커뮤니티 운영자를 사용하여 Prometheus, Alertmanager, Grafana 및 Elasticsearch를 배포합니다. STF는 이러한 커뮤니티 운영자에 요청하여 STF와 함께 작동하도록 구성된 각 애플리케이션의 인스턴스를 만듭니다.
Service Telemetry Operator가 사용자 정의 리소스 요청을 생성하는 대신 이러한 애플리케이션 또는 기타 호환 애플리케이션의 자체 배포를 사용하고 Telemetry 스토리지를 위해 자체 Prometheus 호환 시스템으로 제공하기 위해 지표 Smart Gateway를 스크랩할 수 있습니다. 대신 대체 백엔드를 사용하도록 관찰 기능을 설정하는 경우 STF에 영구 또는 임시 스토리지가 필요하지 않습니다.
5.7.1. 대체 관찰 전략 구성
스토리지, 시각화 및 경고 백엔드 배포를 건너뛰도록 STF를 구성하려면 ServiceTelemetry 사양에 observed abilityStrategy: none 을 추가합니다. 이 모드에서는 AMQ Interconnect 라우터 및 지표 Smart Gateway만 배포되며 STF Smart Gateway에서 메트릭을 수집하도록 외부 Prometheus 호환 시스템을 구성해야 합니다.
현재 observedability Strategy를 메트릭만 지원됩니다. 이벤트 스마트 게이트웨이는 배포되지 않습니다.
none 으로 설정하는 경우
절차
spec매개변수에서 속성 observedabilityStrategy: none을사용하여ServiceTelemetry오브젝트를 생성합니다. 매니페스트는 모든 지표 수집기 유형이 있는 단일 클라우드에서 Telemetry를 수신하는 데 적합한 STF의 기본 배포 결과를 보여줍니다.$ oc apply -f - <<EOF apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: name: default namespace: service-telemetry spec: observabilityStrategy: none EOF
모든 워크로드가 올바르게 작동하는지 확인하려면 Pod 및 각 Pod의 상태를 확인합니다.
$ oc get pods NAME READY STATUS RESTARTS AGE default-cloud1-ceil-meter-smartgateway-59c845d65b-gzhcs 3/3 Running 0 132m default-cloud1-coll-meter-smartgateway-75bbd948b9-d5phm 3/3 Running 0 132m default-cloud1-sens-meter-smartgateway-7fdbb57b6d-dh2g9 3/3 Running 0 132m default-interconnect-668d5bbcd6-57b2l 1/1 Running 0 132m interconnect-operator-b8f5bb647-tlp5t 1/1 Running 0 47h service-telemetry-operator-566b9dd695-wkvjq 1/1 Running 0 156m smart-gateway-operator-58d77dcf7-6xsq7 1/1 Running 0 47h
추가 리소스
추가 클라우드 구성 또는 지원되는 컬렉터 집합을 변경하는 방법에 대한 자세한 내용은 다음을 참조하십시오. 4.4.2절. “스마트 게이트웨이 배포”
5.8. Red Hat OpenStack Platform 서비스의 리소스 사용량
API 및 기타 인프라 프로세스와 같은 RHOSP(Red Hat OpenStack Platform) 서비스의 리소스 사용량을 모니터링하여 컴퓨팅 전원이 실행되는 서비스를 표시하여 오버클라우드의 병목 현상을 확인할 수 있습니다. 리소스 사용량 모니터링은 기본적으로 활성화되어 있습니다.
추가 리소스
- 리소스 사용량 모니터링을 비활성화하려면 5.8.1절. “Red Hat OpenStack Platform 서비스의 리소스 사용량 모니터링 비활성화” 를 참조하십시오.
5.8.1. Red Hat OpenStack Platform 서비스의 리소스 사용량 모니터링 비활성화
RHOSP 컨테이너화된 서비스 리소스 사용량 모니터링을 비활성화하려면 CollectdEnableLibpodstats 매개변수를 false 로 설정해야 합니다.
사전 요구 사항
-
stf-connectors.yaml파일을 생성했습니다. 자세한 내용은 4.1절. “Service Telemetry Framework용 Red Hat OpenStack Platform 오버클라우드 배포”의 내용을 참조하십시오. - 최신 버전의 RHOSP(Red Hat OpenStack Platform) 17.0을 사용하고 있습니다.
절차
stf-connectors.yaml파일을 열고CollectdEnableLibpodstats매개변수를 추가하여enable-stf.yaml의 설정을 덮어씁니다.enable-stf.yaml 후.yaml이 호출되었는지 확인합니다.openstack overcloud deploy명령에서 stf-connectorsCollectdEnableLibpodstats: false
- 오버클라우드 배포 절차를 계속합니다. 자세한 내용은 4.1.5절. “오버클라우드 배포”의 내용을 참조하십시오.
5.9. Red Hat OpenStack Platform API 상태 및 컨테이너화된 서비스 상태
OCI(Open Container Initiative) 표준을 사용하여 주기적으로 상태 점검 스크립트를 실행하여 각 RHOSP(Red Hat OpenStack Platform) 서비스의 컨테이너 상태를 평가할 수 있습니다. 대부분의 RHOSP 서비스는 문제를 기록하고 바이너리 상태를 반환하는 상태 점검을 구현합니다. RHOSP API의 경우 상태 점검에서 root 엔드포인트를 쿼리하고 응답 시간에 따라 상태를 확인합니다.
RHOSP 컨테이너 상태 및 API 상태 모니터링은 기본적으로 활성화되어 있습니다.
추가 리소스
- RHOSP 컨테이너 상태 및 API 상태 모니터링을 비활성화하려면 5.9.1절. “컨테이너 상태 및 API 상태 모니터링 비활성화” 을 참조하십시오.
5.9.1. 컨테이너 상태 및 API 상태 모니터링 비활성화
RHOSP 컨테이너화된 서비스 상태 및 API 상태 모니터링을 비활성화하려면 CollectdEnableSensubility 매개변수를 false 로 설정해야 합니다.
사전 요구 사항
-
templates 디렉터리에
stf-connectors.yaml파일을 생성했습니다. 자세한 내용은 4.1절. “Service Telemetry Framework용 Red Hat OpenStack Platform 오버클라우드 배포”의 내용을 참조하십시오. - 최신 버전의 RHOSP(Red Hat OpenStack Platform) 17.0을 사용하고 있습니다.
절차
stf-connectors.yaml을 열고CollectdEnableSensubility매개변수를 추가하여enable-stf.yaml의 설정을 덮어씁니다.enable-stf.yaml 후.yaml이 호출되었는지 확인합니다.openstack overcloud deploy명령에서 stf-connectorsCollectdEnableSensubility: false
- 오버클라우드 배포 절차를 계속합니다. 자세한 내용은 4.1.5절. “오버클라우드 배포”의 내용을 참조하십시오.
추가 리소스
- 여러 클라우드 주소에 대한 자세한 내용은 4.4절. “여러 클라우드 구성” 을 참조하십시오.
6장. Service Telemetry Framework를 버전 1.4로 업그레이드
Service Telemetry Framework(STF) v1.3에서 STF v1.4로 마이그레이션하려면 Red Hat OpenShift Container Platform 환경의 service-telemetry 네임스페이스에서 ClusterServiceVersion 및 Subscription 오브젝트를 교체해야 합니다.
사전 요구 사항
- Red Hat OpenShift Container Platform 환경을 v4.8로 업그레이드했습니다. STF v1.4는 v4.8 미만의 Red Hat OpenShift Container Platform 버전에서 실행되지 않습니다.
-
당신은 당신의 데이터를 백업했습니다. STF v1.3을 v1.4로 업그레이드하면 스마트 게이트웨이 및 기타 구성 요소가 업데이트되는 동안 잠시 중단됩니다. 또한 Operator를 교체하는 동안
ServiceTelemetry및SmartGateway오브젝트의 변경 사항에는 영향을 미치지 않습니다.
STF v1.3에서 v1.4로 업그레이드하려면 다음 절차를 완료하십시오.
6.1. STF 1.3 Smart Gateway Operator 제거
STF 1.3에서 Smart Gateway Operator를 제거합니다.
절차
- Red Hat OpenShift Container Platform에 로그인합니다.
service-telemetry네임스페이스로 변경합니다.$ oc project service-telemetry
Smart Gateway Operator의
서브스크립션이름을 검색합니다. 선택기의service-telemetry를 기본 네임스페이스와 다른 경우 STF 인스턴스를 호스팅하는 네임스페이스로 바꿉니다. 하나의 서브스크립션만 반환되는지 확인합니다.$ oc get sub --selector=operators.coreos.com/smart-gateway-operator.service-telemetry NAME PACKAGE SOURCE CHANNEL smart-gateway-operator-stable-1.3-redhat-operators-openshift-marketplace smart-gateway-operator redhat-operators stable-1.3
Smart Gateway Operator 서브스크립션을 삭제합니다.
$ oc delete sub --selector=operators.coreos.com/smart-gateway-operator.service-telemetry subscription.operators.coreos.com "smart-gateway-operator-stable-1.3-redhat-operators-openshift-marketplace" deleted
Smart Gateway Operator ClusterServiceVersion을 검색하고 하나의 ClusterServiceVersion만 반환되는지 확인합니다.
$ oc get csv --selector=operators.coreos.com/smart-gateway-operator.service-telemetry NAME DISPLAY VERSION REPLACES PHASE smart-gateway-operator.v3.0.1635451893 Smart Gateway Operator 3.0.1635451893 Succeeded
Smart Gateway Operator ClusterServiceVersion을 삭제합니다.
$ oc delete csv --selector=operators.coreos.com/smart-gateway-operator.service-telemetry clusterserviceversion.operators.coreos.com "smart-gateway-operator.v3.0.1635451893" deleted
SmartGateway CRD(Custom Resource Definition)를 삭제합니다. CRD를 제거한 후 업그레이드가 완료되고 Smart Gateway 인스턴스가 복구될 때까지 STF로 데이터 흐름이 발생하지 않습니다.
$ oc delete crd smartgateways.smartgateway.infra.watch customresourcedefinition.apiextensions.k8s.io "smartgateways.smartgateway.infra.watch" deleted
6.2. Service Telemetry Operator를 1.4로 업데이트
STF 인스턴스를 관리하는 Service Telemetry Operator의 서브스크립션 채널을 stable-1.4 채널로 변경해야 합니다.
절차
- Red Hat OpenShift Container Platform에 로그인합니다.
service-telemetry네임스페이스로 변경합니다.$ oc project service-telemetry
stable-1.4 채널을 사용하려면 Service Telemetry Operator 서브스크립션을 패치합니다. 선택기의
service-telemetry를 기본 네임스페이스와 다른 경우 STF 인스턴스를 호스팅하는 네임스페이스로 바꿉니다.$ oc patch $(oc get sub --selector=operators.coreos.com/service-telemetry-operator.service-telemetry -oname) --patch $'spec:\n channel: stable-1.4' --type=merge subscription.operators.coreos.com/service-telemetry-operator patched
Smart Gateway Operator가 설치되고 Service Telemetry Operator가 업데이트 단계를 통해 이동할 때까지
oc get csv명령의 출력을 모니터링합니다. 단계가Succeeded로 변경되면 Service Telemetry Operator가 업데이트를 완료했습니다.$ watch -n5 oc get csv NAME DISPLAY VERSION REPLACES PHASE amq7-cert-manager.v1.0.3 Red Hat Integration - AMQ Certificate Manager 1.0.3 amq7-cert-manager.v1.0.2 Succeeded amq7-interconnect-operator.v1.10.5 Red Hat Integration - AMQ Interconnect 1.10.5 amq7-interconnect-operator.v1.10.4 Succeeded elasticsearch-eck-operator-certified.1.9.1 Elasticsearch (ECK) Operator 1.9.1 Succeeded prometheusoperator.0.47.0 Prometheus Operator 0.47.0 prometheusoperator.0.37.0 Succeeded service-telemetry-operator.v1.4.1641504218 Service Telemetry Operator 1.4.1641504218 service-telemetry-operator.v1.3.1635451892 Succeeded smart-gateway-operator.v4.0.1641504216 Smart Gateway Operator 4.0.1641504216 Succeeded
모든 포드가 준비되어 실행되고 있는지 확인합니다. 해당 환경은 다음 예제 출력과 다를 수 있습니다.
$ oc get pods NAME READY STATUS RESTARTS AGE alertmanager-default-0 3/3 Running 0 162m default-cloud1-ceil-event-smartgateway-5599bcfc9d-wp48n 2/2 Running 1 160m default-cloud1-ceil-meter-smartgateway-c8fdf579c-955kt 3/3 Running 0 160m default-cloud1-coll-event-smartgateway-97b54b7dc-5zz2v 2/2 Running 0 159m default-cloud1-coll-meter-smartgateway-774b9988b8-wb5vd 3/3 Running 0 160m default-cloud1-sens-meter-smartgateway-b98966fbf-rnqwf 3/3 Running 0 159m default-interconnect-675dd97bc4-dcrzk 1/1 Running 0 171m default-snmp-webhook-7854d4889d-wgmgg 1/1 Running 0 171m elastic-operator-c54ff8cc-jcg8d 1/1 Running 6 3h55m elasticsearch-es-default-0 1/1 Running 0 160m interconnect-operator-6bf74c4ffb-hkmbq 1/1 Running 0 3h54m prometheus-default-0 3/3 Running 1 160m prometheus-operator-fc64987d-f7gx4 1/1 Running 0 3h54m service-telemetry-operator-68d888f767-s5kzh 1/1 Running 0 163m smart-gateway-operator-584df7959-llxgl 1/1 Running 0 163m
7장. Red Hat OpenShift Container Platform 환경에서 Service Telemetry Framework 제거
STF 기능이 더 이상 필요하지 않은 경우 Red Hat OpenShift Container Platform 환경에서 Service Telemetry Framework(STF)를 제거하십시오.
Red Hat OpenShift Container Platform 환경에서 STF를 제거하려면 다음 작업을 수행해야 합니다.
- 네임스페이스를 삭제합니다.
- 카탈로그 소스를 제거합니다.
- AMQ Cert Manager Operator를 제거합니다.
7.1. 네임스페이스 삭제
Red Hat OpenShift Container Platform에서 STF 운영 리소스를 제거하려면 네임스페이스를 삭제합니다.
절차
oc delete명령을 실행합니다.$ oc delete project service-telemetry
네임스페이스에서 리소스가 삭제되었는지 확인합니다.
$ oc get all No resources found.
7.2. CatalogSource 제거
Service Telemetry Framework (STF)를 다시 설치하지 않으려면 CatalogSource를 삭제합니다. CatalogSource를 제거하면 STF와 관련된 PackageManifests가 Operator Lifecycle Manager 카탈로그에서 자동으로 제거됩니다.
절차
설치 프로세스 중에 OperatorHub.io Community Catalog Source를 활성화했으며 이 카탈로그 소스가 더 이상 필요하지 않은 경우 이를 삭제합니다.
$ oc delete --namespace=openshift-marketplace catalogsource operatorhubio-operators catalogsource.operators.coreos.com "operatorhubio-operators" deleted
7.3. AMQ Certificate Manager Operator 제거
다른 애플리케이션에 AMQ Certificate Manager를 사용하지 않는 경우 서브스크립션, ClusterServiceVersion 및 CustomResourceDefinitions를 삭제합니다.
절차
설치된 ClusterServiceVersion의 버전 번호를 검색합니다.
$ oc get --namespace=openshift-operators subscription amq7-cert-manager-operator -oyaml | grep currentCSV
출력 예:
currentCSV: amq7-cert-manager.v1.0.6
openshift-operators네임스페이스에서 서브스크립션을 삭제합니다.$ oc delete --namespace=openshift-operators subscription amq7-cert-manager-operator subscription.operators.coreos.com "amq7-cert-manager-operator" deleted
Operator에서 제공하는 CustomResourceDefinitions의 현재 목록을 가져와 ClusterServiceVersion을 제거한 후 삭제할 수 있습니다.
$ oc get csv -nopenshift-operators amq7-cert-manager.v1.0.6 -oyaml | grep "kind: CustomResourceDefinition" -A2 | grep name | awk '{print $2}'출력 예:
certificates.certmanager.k8s.io challenges.certmanager.k8s.io clusterissuers.certmanager.k8s.io issuers.certmanager.k8s.io orders.certmanager.k8s.io
openshift-operators네임스페이스에서 ClusterServiceVersion을 삭제합니다.$ oc delete --namespace=openshift-operators csv amq7-cert-manager.v1.0.6
출력 예:
clusterserviceversion.operators.coreos.com "amq7-cert-manager.v1.0.6" deleted
AMQ Cert Manager Operator와 관련된 CustomResourceDefinitions를 삭제합니다.
$ oc delete crd certificates.certmanager.k8s.io challenges.certmanager.k8s.io clusterissuers.certmanager.k8s.io issuers.certmanager.k8s.io orders.certmanager.k8s.io
출력 예:
customresourcedefinition.apiextensions.k8s.io "certificates.certmanager.k8s.io" deleted customresourcedefinition.apiextensions.k8s.io "challenges.certmanager.k8s.io" deleted customresourcedefinition.apiextensions.k8s.io "clusterissuers.certmanager.k8s.io" deleted customresourcedefinition.apiextensions.k8s.io "issuers.certmanager.k8s.io" deleted customresourcedefinition.apiextensions.k8s.io "orders.certmanager.k8s.io" deleted
추가 정보
Red Hat OpenShift Container Platform에서 Operator를 제거하는 방법에 대한 자세한 내용은 https://docs.openshift.com/container-platform/4.10/operators/admin/olm-deleting-operators-from-cluster.html을 참조하십시오.