4.2. ユーザーワークロードモニタリングのパフォーマンスとスケーラビリティーの設定

手順

1. まだの場合は、モニタリングコンポーネントを実行するノードにラベルを追加します。

   $ oc label nodes <node_name> <node_label> 

   1

   Copy to Clipboard Toggle word wrap

   1

   <node_name> は、ラベルを追加するノードの名前に置き換えます。<node_label> は、必要なラベルの名前に置き換えます。

2. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   Copy to Clipboard Toggle word wrap

3. data/config.yaml でコンポーネントの nodeSelector 制約のノードラベルを指定します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       # ...
       <component>: 

   1

   
         nodeSelector:
           <node_label_1> 

   2

   
           <node_label_2> 

   3

   
       # ...

   Copy to Clipboard Toggle word wrap

   1

   <component> を適切なモニタリングスタックコンポーネント名に置き換えます。

   2

   <node_label_1> は、ノードに追加したラベルに置き換えます。

   3

   オプション: 追加のラベルを指定します。追加のラベルを指定すると、コンポーネントの Pod は、指定されたすべてのラベルを含むノード上でのみスケジュールされます。

   注記

   nodeSelector の制約を設定した後もモニタリングコンポーネントが Pending 状態のままになっている場合は、Pod イベントで taint および toleration に関連するエラーの有無を確認します。

4. 変更を適用するためにファイルを保存します。新しい設定で指定されたコンポーネントは自動的に新しいノードに移動され、新しい設定の影響を受ける Pod は再デプロイされます。

手順

1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config config map を編集します。

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   Copy to Clipboard Toggle word wrap

2. コンポーネントの tolerations を指定します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       <component>:
         tolerations:
           <toleration_specification>

   Copy to Clipboard Toggle word wrap

   <component> および <toleration_specification> を随時置き換えます。

   たとえば、oc adm taint nodes node1 key1=value1:NoSchedule は、キーが key1 で、値が value1 の node1 に taint を追加します。これにより、モニタリングコンポーネントが node1 に Pod をデプロイするのを防ぎます。ただし、その taint に対して toleration が設定されている場合を除きます。以下の例では、サンプルの taint を容認するように thanosRuler コンポーネントを設定します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       thanosRuler:
         tolerations:
         - key: "key1"
           operator: "Equal"
           value: "value1"
           effect: "NoSchedule"

   Copy to Clipboard Toggle word wrap
3. 変更を適用するためにファイルを保存します。新しい設定の影響を受ける Pod は自動的に再デプロイされます。

手順

1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config config map を編集します。

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   Copy to Clipboard Toggle word wrap

2. 値を追加して、設定する各コンポーネントのリソース制限および要求を定義します。

   重要

   制限に設定した値が常に要求に設定された値よりも大きくなることを確認してください。そうでない場合、エラーが発生し、コンテナーは実行されません。

   リソース制限とリクエストの設定例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       alertmanager:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       prometheus:
         resources:
           limits:
             cpu: 500m
             memory: 3Gi
           requests:
             cpu: 200m
             memory: 500Mi
       thanosRuler:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi

   Copy to Clipboard Toggle word wrap

3. 変更を適用するためにファイルを保存します。新しい設定の影響を受ける Pod は自動的に再デプロイされます。

手順

1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   Copy to Clipboard Toggle word wrap

2. enforcedSampleLimit 設定を data/config.yaml に追加し、ユーザー定義プロジェクトのターゲットの収集ごとに受け入れ可能なサンプルの数を制限できます。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         enforcedSampleLimit: 50000 

   1

   Copy to Clipboard Toggle word wrap

   1

   このパラメーターが指定されている場合は、値が必要です。この enforcedSampleLimit の例では、ユーザー定義プロジェクトのターゲット収集ごとに受け入れ可能なサンプル数を 50,000 に制限します。

3. enforcedLabelLimit、enforcedLabelNameLengthLimit、および enforcedLabelValueLengthLimit 設定を data/config.yaml に追加し、収集されるラベルの数、ラベル名の長さ、およびユーザー定義プロジェクトでのラベル値の長さを制限します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         enforcedLabelLimit: 500 

   1

   
         enforcedLabelNameLengthLimit: 50 

   2

   
         enforcedLabelValueLengthLimit: 600 

   3

   Copy to Clipboard Toggle word wrap

   1

   収集ごとのラベルの最大数を指定します。デフォルト値は 0 で、制限なしを指定します。

   2

   ラベル名の最大長を指定します。デフォルト値は 0 で、制限なしを指定します。

   3

   ラベル値の最大長を指定します。デフォルト値は 0 で、制限なしを指定します。

4. 変更を適用するためにファイルを保存します。制限は自動的に適用されます。

手順

1. ターゲットがダウンし、実行されたサンプル制限に近づく際に通知するアラートを指定して YAML ファイルを作成します。この例のファイルは monitoring-stack-alerts.yaml という名前です。

   apiVersion: monitoring.coreos.com/v1
   kind: PrometheusRule
   metadata:
     labels:
       prometheus: k8s
       role: alert-rules
     name: monitoring-stack-alerts 

   1

   
     namespace: ns1 

   2

   
   spec:
     groups:
     - name: general.rules
       rules:
       - alert: TargetDown 

   3

   
         annotations:
           message: '{{ printf "%.4g" $value }}% of the {{ $labels.job }}/{{ $labels.service
             }} targets in {{ $labels.namespace }} namespace are down.' 

   4

   
         expr: 100 * (count(up == 0) BY (job, namespace, service) / count(up) BY (job,
           namespace, service)) > 10
         for: 10m 

   5

   
         labels:
           severity: warning 

   6

   
       - alert: ApproachingEnforcedSamplesLimit 

   7

   
         annotations:
           message: '{{ $labels.container }} container of the {{ $labels.pod }} pod in the {{ $labels.namespace }} namespace consumes {{ $value | humanizePercentage }} of the samples limit budget.' 

   8

   
         expr: scrape_samples_scraped/50000 > 0.8 

   9

   
         for: 10m 

   10

   
         labels:
           severity: warning 

   11

   Copy to Clipboard Toggle word wrap

   1

   アラートルールの名前を定義します。

   2

   アラートルールをデプロイするユーザー定義のプロジェクトを指定します。

   3

   TargetDown アラートは、 for の期間にターゲットを収集できないか、利用できない場合に実行されます。

   4

   TargetDown アラートが実行される場合に出力されるメッセージ。

   5

   アラートが実行される前に、TargetDown アラートの条件がこの期間中 true である必要があります。

   6

   TargetDown アラートの重大度を定義します。

   7

   ApproachingEnforcedSamplesLimit アラートは、指定された for の期間に定義された収集サンプルのしきい値に達するか、この値を上回る場合に実行されます。

   8

   ApproachingEnforcedSamplesLimit アラートの実行時に出力されるメッセージ。

   9

   ApproachingEnforcedSamplesLimit アラートのしきい値。この例では、ターゲット収集ごとのサンプル数が実行されたサンプル制限 50000 の 80% を超えるとアラートが実行されます。アラートが実行される前に、for の期間も経過している必要があります。式 scrape_samples_scraped/<number> > <threshold> の <number> は user-workload-monitoring-config ConfigMap オブジェクトで定義される enforcedSampleLimit 値に一致する必要があります。

   10

   アラートが実行される前に、ApproachingEnforcedSamplesLimit アラートの条件がこの期間中 true である必要があります。

   11

   ApproachingEnforcedSamplesLimit アラートの重大度を定義します。

2. 設定をユーザー定義プロジェクトに適用します。

   $ oc apply -f monitoring-stack-alerts.yaml

   Copy to Clipboard Toggle word wrap