サポートコンソール開発者トライアルの開始お問い合わせ

16.3. Observability

16.3.1. OpenShift Container Platform の可観測性

OpenShift Container Platform は、プラットフォームとそれで実行されているワークロードの両方からパフォーマンスメトリックやログなどの大量のデータを生成します。管理者は、さまざまなツールを使用して、利用可能なすべてのデータを収集および分析できます。以下では、可観測性スタックを設定するシステムエンジニア、アーキテクト、および管理者のベストプラクティスの概要を説明します。

明示的に記載がない限り、このドキュメントの資料は、エッジデプロイメントとコアデプロイメントの両方を参照します。

16.3.1.1. モニタリングスタックについて

モニタリングスタックは、以下のコンポーネントを使用します。

  • Prometheus は、これを実行するように設定されている場合、OpenShift Container Platform コンポーネントとワークロードからメトリックを収集して分析します。
  • Alertmanager は、アラートのルーティング、グループ化、およびサイレントを処理する Prometheus のコンポーネントです。
  • Thanos はメトリクスの長期ストレージを処理します。

図16.2 OpenShift Container Platform モニタリングアーキテクチャー

OpenShift Container Platform モニタリングアーキテクチャー
注記

シングルノードの OpenShift クラスターでは、Alertmanager と Thanos を無効にする必要があります。これは、クラスターが分析と保持のためにすべてのメトリクスをハブクラスターに送信するためです。

関連情報

16.3.1.2. 主なパフォーマンスのメトリクス

システムによっては、数百もの測定が可能です。

以下は、注意すべき重要なメトリクスです。

  • etcd の応答時間
  • API の応答時間
  • Pod の再起動およびスケジューリング
  • リソースの使用状況
  • OVN health
  • クラスター Operator の全体的な健全性

従うべき適切なルールは、メトリックが重要であると判断した場合は、その警告が存在するべきです。

注記

以下のコマンドを実行することで、利用可能なメトリクスを確認できます。 

$ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -qsk http://localhost:9090/api/v1/metadata | jq '.data
16.3.1.2.1. PromQL のクエリー例

以下の表は、OpenShift Container Platform コンソールを使用してメトリクスクエリーブラウザーで確認できるクエリーを示しています。

注記

コンソールの URL は https://<OpenShift Console FQDN>/monitoring/query-browser です。次のコマンドを実行し、Openshift コンソールの FQDN を取得できます。 

$ oc get routes -n openshift-console console -o jsonpath='{.status.ingress[0].host}'
表16.1 ノードメモリーと CPU の使用率
メトリクスクエリー

cpu % requests by node

合計(node) (sum_over_time (kube_pod_container_resource_requests{resource="cpu"}[60m]))/sum by (node) (sum_over_time (kube_node_status_allocatable{resource="cpu"}[60m]))*100

全体的なクラスターの CPU % 使用率

sum by (managed_cluster) (sum_over_time (kube_pod_container_resource_requests{resource="memory"}[60m]))）/sum by (managed_cluster) (sum_over_time (kube_node_status_allocatable{resource="cpu"}[60m]))*100

ノード別のメモリー％要求

合計(node) (sum_over_time (kube_pod_container_resource_requests{resource="memory"}[60m]))/sum by (node) (sum_over_time (kube_node_status_allocatable{resource="memory"}[60m]))*100

全体的なクラスターのメモリー％使用率

(1-(sum by (managed_cluster)(avg_over_timenode_memory_MemAvailable_bytes[60m]）/sum by (managed_cluster) (avg_over_time (kube_node_status_allocatable{resource="memory"}[60m]))）*100

表16.2 動詞による API レイテンシー
メトリクスクエリー

GET

histogram_quantile (0.99、sum by （le、managed_cluster) (sum_over_time (apiserver_request_duration_seconds_bucket{apiserver=~"kube-apiserver|openshift-apiserver", verb="GET"}[60m]))）

PATCH

histogram_quantile (0.99、sum by （le、managed_cluster) (sum_over_time (apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver|openshift-apiserver", verb="PATCH"}[60m]))）

POST

histogram_quantile (0.99、sum by （le、managed_cluster) (sum_over_time (apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver|openshift-apiserver", verb="POST"}[60m]))）

LIST

histogram_quantile (0.99、sum by （le、managed_cluster) (sum_over_time (apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver|openshift-apiserver", verb="LIST"}[60m]))）

PUT

histogram_quantile (0.99、sum by （le、managed_cluster) (sum_over_time (apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver|openshift-apiserver", verb="PUT"}[60m]))）

DELETE

histogram_quantile (0.99、sum by （le、managed_cluster) (sum_over_time (apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver|openshift-apiserver", verb="DELETE"}[60m]))）

combined

histogram_quantile (0.99, sum by (le,managed_cluster) （sum_over_time （apiserver_request_duration_seconds_bucket{apiserver=~" (openshift-apiserver|kube-apiserver) ", verb!="WATCH"}[60m])））

表16.3 etcd
メトリクスクエリー

fsync 99 パーセンタイルレイテンシー（インスタンスごと）

histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[2m]))

fsync 99 パーセンタイルレイテンシー（クラスターあたり）

合計(managed_cluster) (histtogram_quantile （0.99, rate (etcd_disk_wal_fsync_duration_seconds_bucket[60m]))）

リーダーの選択

sum(rate(etcd_server_leader_changes_seen_total[1440m]))

ネットワークレイテンシー

histogram_quantile(0.99, rate(etcd_network_peer_round_trip_time_seconds_bucket[5m]))

表16.4 Operator の正常性
メトリクスクエリー

低下した Operator

sum by (managed_cluster, name) (avg_over_time (cluster_operator_conditions{condition="Degraded", name!="version"}[60m]))

クラスターごとの劣化した Operator の合計

sum by (managed_cluster) (avg_over_time (cluster_operator_conditions{condition="Degraded", name!="version"}[60m]))

16.3.1.2.2. メトリクスのストレージに関する推奨事項

追加設定なしで、Prometheus は永続ストレージと共に保存されたメトリクスをバックアップしません。Prometheus Pod を再起動すると、すべてのメトリクスデータが失われます。プラットフォームで利用可能なバックエンドストレージを使用するようにモニタリングスタックを設定する必要があります。Prometheus の高 IO 要求を満たすには、ローカルストレージを使用する必要があります。

Telco コアクラスターの場合、Prometheus の永続ストレージにローカルストレージ Operator を使用できます。

ブロック、ファイル、およびオブジェクトストレージ用の ceph クラスターをデプロイする Red Hat OpenShift Data Foundation (ODF)も、Telco コアクラスターに適した候補です。

RAN シングルノード OpenShift または遠端クラスターでシステム要件を低く抑えるには、モニタリングスタックのバックエンドストレージをプロビジョニングしないでください。このようなクラスターは、すべてのメトリクスをハブクラスターに転送し、サードパーティーのモニタリングプラットフォームをプロビジョニングできます。

関連情報

16.3.1.3. エッジのモニタリング

エッジでの単一ノード OpenShift は、プラットフォームコンポーネントのフットプリントを最小限に抑えるように維持します。以下の手順は、小規模なモニタリングフットプリントで単一ノードの OpenShift ノードを設定する方法の例です。

前提条件

  • Red Hat Advanced Cluster Management (RHACM)を使用する環境では、可観測性サービスを有効にしている。
  • ハブクラスターは Red Hat OpenShift Data Foundation (ODF)を実行している。

手順

  1. ConfigMap CR を作成し、これを monitoringConfigMap.yaml として保存します。 

    apiVersion: v1
kind: ConfigMap
metadata:
 name: cluster-monitoring-config
 namespace: openshift-monitoring
 data:
 config.yaml: |
   alertmanagerMain:
     enabled: false
   telemeterClient:
     enabled: false
   prometheusK8s:
      retention: 24h

  2. シングルノード OpenShift で、次のコマンドを実行して ConfigMap CR を適用します。 

    $ oc apply -f monitoringConfigMap.yaml

  3. 次の例のように NameSpace CR を作成し、これを monitoringNamespace.yaml として保存します。 

    apiVersion: v1
kind: Namespace
metadata:
  name: open-cluster-management-observability

  4. ハブクラスターで、次のコマンドを実行して、ハブクラスターに Namespace CR を適用します。 

    $ oc apply -f monitoringNamespace.yaml

  5. ObjectBucketClaim CR を作成し、以下の例のように monitoringObjectBucketClaim.yaml として保存します。 

    apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
  name: multi-cloud-observability
  namespace: open-cluster-management-observability
spec:
  storageClassName: openshift-storage.noobaa.io
  generateBucketName: acm-multi

  6. ハブクラスターで、以下のコマンドを実行して ObjectBucketClaim CR を適用します。 

    $ oc apply -f monitoringObjectBucketClaim.yaml

  7. Secret CR を作成し、これを monitoringSecret.yaml として保存します。 

    apiVersion: v1
kind: Secret
metadata:
  name: multiclusterhub-operator-pull-secret
  namespace: open-cluster-management-observability
stringData:
  .dockerconfigjson: 'PULL_SECRET'

  8. ハブクラスターで、次のコマンドを実行して Secret CR を適用します。 

    $ oc apply -f monitoringSecret.yaml

  9. 次のコマンドを実行して、NooBaa サービスのキーとハブクラスターからバックエンドバケット名を取得します。 

    $ NOOBAA_ACCESS_KEY=$(oc get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_ACCESS_KEY_ID|@base64d')
    $ NOOBAA_SECRET_KEY=$(oc get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_SECRET_ACCESS_KEY|@base64d')
    $ OBJECT_BUCKET=$(oc get objectbucketclaim -n open-cluster-management-observability multi-cloud-observability -o json | jq -r .spec.bucketName)

  10. 次の例のように、バケットストレージの Secret CR を作成し、これを monitoringBucketSecret.yaml として保存します。 

    apiVersion: v1
kind: Secret
metadata:
  name: thanos-object-storage
  namespace: open-cluster-management-observability
type: Opaque
stringData:
  thanos.yaml: |
    type: s3
    config:
      bucket: ${OBJECT_BUCKET}
      endpoint: s3.openshift-storage.svc
      insecure: true
      access_key: ${NOOBAA_ACCESS_KEY}
      secret_key: ${NOOBAA_SECRET_KEY}

  11. ハブクラスターで、次のコマンドを実行して Secret CR を適用します。 

    $ oc apply -f monitoringBucketSecret.yaml

  12. 以下の例のように MultiClusterObservability CR を作成し、これを monitoringMultiClusterObservability.yaml として保存します。 

    apiVersion: observability.open-cluster-management.io/v1beta2
kind: MultiClusterObservability
metadata:
  name: observability
spec:
  advanced:
    retentionConfig:
      blockDuration: 2h
      deleteDelay: 48h
      retentionInLocal: 24h
      retentionResolutionRaw: 3d
  enableDownsampling: false
  observabilityAddonSpec:
    enableMetrics: true
    interval: 300
  storageConfig:
    alertmanagerStorageSize: 10Gi
    compactStorageSize: 100Gi
    metricObjectStorage:
      key: thanos.yaml
      name: thanos-object-storage
    receiveStorageSize: 25Gi
    ruleStorageSize: 10Gi
    storeStorageSize: 25Gi

  13. ハブクラスターで、次のコマンドを実行して MultiClusterObservability CR を適用します。 

    $ oc apply -f monitoringMultiClusterObservability.yaml

検証

  1. 次のコマンドを実行して、namespace 内のルートと Pod を確認し、サービスがハブクラスターにデプロイされたことを確認します。 

    $ oc get routes,pods -n open-cluster-management-observability

    出力例

    NAME                                         HOST/PORT                                                                                        PATH      SERVICES                          PORT          TERMINATION          WILDCARD
route.route.openshift.io/alertmanager        alertmanager-open-cluster-management-observability.cloud.example.com        /api/v2   alertmanager                      oauth-proxy   reencrypt/Redirect   None
route.route.openshift.io/grafana             grafana-open-cluster-management-observability.cloud.example.com                       grafana                           oauth-proxy   reencrypt/Redirect   None 1
route.route.openshift.io/observatorium-api   observatorium-api-open-cluster-management-observability.cloud.example.com             observability-observatorium-api   public        passthrough/None     None
route.route.openshift.io/rbac-query-proxy    rbac-query-proxy-open-cluster-management-observability.cloud.example.com              rbac-query-proxy                  https         reencrypt/Redirect   None

NAME                                                           READY   STATUS    RESTARTS   AGE
pod/observability-alertmanager-0                               3/3     Running   0          1d
pod/observability-alertmanager-1                               3/3     Running   0          1d
pod/observability-alertmanager-2                               3/3     Running   0          1d
pod/observability-grafana-685b47bb47-dq4cw                     3/3     Running   0          1d
<...snip…>
pod/observability-thanos-store-shard-0-0                       1/1     Running   0          1d
pod/observability-thanos-store-shard-1-0                       1/1     Running   0          1d
pod/observability-thanos-store-shard-2-0                       1/1     Running   0          1d

    1
    ダッシュボードは、grafana ルートの一覧でアクセスできます。これを使用して、すべてのマネージドクラスターのメトリックを表示できます。

{rh-rhacm-title} の可観測性の詳細は、可 観測性 を参照してください。

16.3.1.4. アラート

OpenShift Container Platform には多数のアラートルールが含まれており、これはリリースごとに変更される可能性があります。

16.3.1.4.1. デフォルトのアラートの表示

以下の手順を使用して、クラスター内のすべてのアラートルールを確認します。

手順

  • クラスター内のすべてのアラートルールを確認するには、以下のコマンドを実行します。 

    $ oc get cm -n openshift-monitoring prometheus-k8s-rulefiles-0 -o yaml

    ルールには説明を含め、追加情報と軽減策へのリンクを提供できます。たとえば、これは etcdHighFsyncDurations のルールです。 

          - alert: etcdHighFsyncDurations
        annotations:
          description: 'etcd cluster "{{ $labels.job }}": 99th percentile fsync durations
            are {{ $value }}s on etcd instance {{ $labels.instance }}.'
          runbook_url: https://github.com/openshift/runbooks/blob/master/alerts/cluster-etcd-operator/etcdHighFsyncDurations.md
          summary: etcd cluster 99th percentile fsync durations are too high.
        expr: |
          histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket{job=~".*etcd.*"}[5m]))
          > 1
        for: 10m
        labels:
          severity: critical
16.3.1.4.2. アラート通知

OpenShift Container Platform コンソールでアラートを表示できますが、管理者はアラートを転送するように外部レシーバーを設定する必要があります。OpenShift Container Platform は以下のレシーバータイプをサポートします。

  • PagerDuty: サードパーティーのインシデント応答プラットフォーム
  • Webhook: POST リクエスト経由でアラートを受信し、必要なアクションを実行する任意の API エンドポイント。
  • Email: 指定されたアドレスにメールを送信します
  • Slack: 通知を slack チャネルまたは個別ユーザーのいずれかに送信します。

関連情報

16.3.1.5. ワークロードの監視

デフォルトで、OpenShift Container Platform はアプリケーションワークロードのメトリクスを収集しません。ワークロードメトリックを収集するようにクラスターを設定できます。

前提条件

  • クラスターでワークロードメトリクスを収集するためのエンドポイントを定義しました。

手順

  1. 以下の例のように ConfigMap CR を作成し、これを monitoringConfigMap.yaml として保存します。 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    enableUserWorkload: true 1
    1
    ワークロードの監視を有効にするには、true に設定します。

  2. 以下のコマンドを実行して ConfigMap CR を適用します。 

    $ oc apply -f monitoringConfigMap.yaml

  3. 次の例のように、ServiceMonitor CR を作成し、これを monitoringServiceMonitor.yaml として保存します。 

    apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app: ui
  name: myapp
  namespace: myns
spec:
  endpoints: 1
  - interval: 30s
    port: ui-http
    scheme: http
    path: /healthz 2
  selector:
    matchLabels:
      app: ui
    1
    エンドポイントを使用してワークロードメトリクスを定義します。
    2
    Prometheus はデフォルトでパス /metrics を収集します。ここでカスタムパスを定義できます。

  4. 次のコマンドを実行して、ServiceMonitor CR を適用します。 

    $ oc apply -f monitoringServiceMonitor.yaml

Prometheus はデフォルトでパス /metrics をスクレープしますが、カスタムパスを定義できます。関連するメトリクスを使用して、このエンドポイントをスクレイピング用に公開するのは、アプリケーションのベンダー次第です。

16.3.1.5.1. ワークロードアラートの作成

クラスターでユーザーワークロードのアラートを有効にできます。

手順

  1. ConfigMap CR を作成し、これを monitoringConfigMap.yaml として保存します。 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    enableUserWorkload: true 1
# ...
    1
    ワークロードの監視を有効にするには、true に設定します。

  2. 以下のコマンドを実行して ConfigMap CR を適用します。 

    $ oc apply -f monitoringConfigMap.yaml

  3. 以下の例のように、アラートルールの YAML ファイル monitoringAlertRule.yaml を作成します。 

    apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: myapp-alert
  namespace: myns
spec:
  groups:
  - name: example
    rules:
    - alert: InternalErrorsAlert
      expr: flask_http_request_total{status="500"} > 0
# ...

  4. 以下のコマンドを実行してアラートルールを適用します。 

    $ oc apply -f monitoringAlertRule.yaml

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.