11.2. カスタムロギングアラート
Logging 5.7 以降のバージョンでは、ユーザーは、カスタマイズされたアラートと記録されたメトリクスを生成するように LokiStack デプロイメントを設定できます。カスタマイズされた アラートおよび記録ルール を使用する場合は、LokiStack ルーラーコンポーネントを有効にする必要があります。
LokiStack のログベースのアラートと記録されたメトリクスは、LogQL 式をルーラーコンポーネントに提供することによってトリガーされます。Loki Operator は、選択した LokiStack サイズ (1x.extra-small
、1x.small
、または 1x.medium
) に最適化されたルーラーを管理します。
これらの式を提供するには、Prometheus 互換の アラートルール を含む AlertingRule
カスタムリソース (CR)、または Prometheus 互換の 記録ルール を含む RecordingRule
CR を作成する必要があります。
管理者は、application
、audit
、または infrastructure
テナントのログベースのアラートまたは記録されたメトリクスを設定できます。管理者権限のないユーザーは、アクセス権のあるアプリケーションの application
テナントに対してログベースのアラートまたは記録されたメトリクスを設定できます。
アプリケーション、監査、およびインフラストラクチャーのアラートは、ローカルの Alertmanager インスタンスを無効にしていない限り、デフォルトで openshift-monitoring
namespace の Red Hat OpenShift Service on AWS モニタリングスタック Alertmanager に送信されます。openshift-user-workload-monitoring
namespace でユーザー定義プロジェクトの監視に使用される Alertmanager が有効になっている場合、アプリケーションアラートはデフォルトでこの namespace の Alertmanager に送信されます。
11.2.1. ルーラーの設定
LokiStack ルーラーコンポーネントが有効になっている場合、ユーザーはログアラートや記録されたメトリクスをトリガーする LogQL 式のグループを定義できます。
管理者は、LokiStack
カスタムリソース (CR) を変更することでルーラーを有効にできます。
前提条件
- Red Hat OpenShift Logging Operator と Loki Operator がインストールされている。
-
LokiStack
CR が作成されている。 - 管理者権限がある。
手順
LokiStack
CR に次の仕様設定が含まれていることを確認して、ルーラーを有効にします。apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: <name> namespace: <namespace> spec: # ... rules: enabled: true 1 selector: matchLabels: openshift.io/<label_name>: "true" 2 namespaceSelector: matchLabels: openshift.io/<label_name>: "true" 3
11.2.2. LokiStack ルールの RBAC 権限の認可
管理者は、クラスターロールをユーザー名にバインドすることで、ユーザーが独自のアラートおよび記録ルールを作成および管理できるようにすることができます。クラスターロールは、ユーザーに必要なロールベースのアクセス制御 (RBAC) 権限を含む ClusterRole
オブジェクトとして定義されます。
Logging 5.8 以降では、アラートおよび記録ルール用の次のクラスターロールを LokiStack で使用できます。
ルール名 | 説明 |
---|---|
|
このロールを持つユーザーは、アラートルールを管理する管理レベルのアクセス権を持ちます。このクラスターロールは、 |
|
このロールを持つユーザーは、 |
|
このロールを持つユーザーは、 |
|
このロールを持つユーザーは、 |
|
このロールを持つユーザーは、記録ルールを管理する管理レベルのアクセス権を持ちます。このクラスターロールは、 |
|
このロールを持つユーザーは、 |
|
このロールを持つユーザーは、 |
|
このロールを持つユーザーは、 |
11.2.2.1. 例
ユーザーにクラスターロールを適用するには、既存のクラスターロールを特定のユーザー名にバインドする必要があります。
クラスターロールは、使用するロールバインディングの種類に応じて、クラスタースコープまたは namespace スコープにすることができます。RoleBinding
オブジェクトを使用する場合は、oc adm policy add-role-to-user
コマンドを使用する場合と同様に、クラスターロールが指定した namespace にのみ適用されます。ClusterRoleBinding
オブジェクトを使用する場合は、oc adm policy add-cluster-role-to-user
コマンドを使用する場合と同様に、クラスターロールがクラスター内のすべての namespace に適用されます。
次のコマンド例では、指定したユーザーに、クラスター内の特定の namespace のアラートルールに対する作成、読み取り、更新、および削除 (CRUD) 権限を付与します。
特定の namespace のアラートルールに対する CRUD 権限を付与するクラスターロールバインディングコマンドの例
$ oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>
次のコマンドは、指定したユーザーに、すべての namespace のアラートルールに対する管理者権限を付与します。
管理者権限を付与するクラスターロールバインディングコマンドの例
$ oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>
11.2.3. Loki を使用したログベースのアラートルールの作成
AlertingRule
CR には、単一の LokiStack
インスタンスのアラートルールグループを宣言するために使用する、仕様および Webhook 検証定義のセットが含まれます。Webhook 検証定義は、ルール検証条件もサポートします。
-
AlertingRule
CR に無効なinterval
期間が含まれる場合、無効なアラートルールです。 -
AlertingRule
CR に無効なfor
期間が含まれる場合、無効なアラートルールです。 -
AlertingRule
CR に無効な LogQLexpr
が含まれる場合、無効なアラートルールです。 -
AlertingRule
CR に同じ名前のグループが 2 つ含まれる場合、無効なアラートルールです。 - 上記のいずれにも当てはまらない場合、アラートルールは有効であるとみなされます。
テナントタイプ | AlertingRule CR の有効な namespace |
---|---|
application | |
audit |
|
infrastructure |
|
前提条件
- Red Hat OpenShift Logging Operator 5.7 以降
- Red Hat OpenShift Service on AWS 4.13 以降
手順
AlertingRule
カスタムリソース (CR) を作成します。インフラストラクチャー AlertingRule CR の例
apiVersion: loki.grafana.com/v1 kind: AlertingRule metadata: name: loki-operator-alerts namespace: openshift-operators-redhat 1 labels: 2 openshift.io/<label_name>: "true" spec: tenantID: "infrastructure" 3 groups: - name: LokiOperatorHighReconciliationError rules: - alert: HighPercentageError expr: | 4 sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"} |= "error" [1m])) by (job) / sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"}[1m])) by (job) > 0.01 for: 10s labels: severity: critical 5 annotations: summary: High Loki Operator Reconciliation Errors 6 description: High Loki Operator Reconciliation Errors 7
- 1
- この
AlertingRule
CR が作成される namespace には、LokiStackspec.rules.namespaceSelector
定義に一致するラベルが必要です。 - 2
labels
ブロックは、LokiStack のspec.rules.selector
定義と一致する必要があります。- 3
infrastructure
テナントのAlertingRule
CR は、openshift-*
、kube-\*
、またはdefault
namespaces でのみサポートされます。- 4
kubernetes_namespace_name:
の値は、metadata.namespace
の値と一致する必要があります。- 5
- この必須フィールドの値は、
critical
、warning
、またはinfo
である必要があります。 - 6
- このフィールドは必須です。
- 7
- このフィールドは必須です。
アプリケーション AlertingRule CR の例
apiVersion: loki.grafana.com/v1 kind: AlertingRule metadata: name: app-user-workload namespace: app-ns 1 labels: 2 openshift.io/<label_name>: "true" spec: tenantID: "application" groups: - name: AppUserWorkloadHighError rules: - alert: expr: | 3 sum(rate({kubernetes_namespace_name="app-ns", kubernetes_pod_name=~"podName.*"} |= "error" [1m])) by (job) for: 10s labels: severity: critical 4 annotations: summary: 5 description: 6
- 1
- この
AlertingRule
CR が作成される namespace には、LokiStackspec.rules.namespaceSelector
定義に一致するラベルが必要です。 - 2
labels
ブロックは、LokiStack のspec.rules.selector
定義と一致する必要があります。- 3
kubernetes_namespace_name:
の値は、metadata.namespace
の値と一致する必要があります。- 4
- この必須フィールドの値は、
critical
、warning
、またはinfo
である必要があります。 - 5
- この必須フィールドの値は、ルールの概要です。
- 6
- この必須フィールドの値は、ルールの詳細な説明です。
AlertingRule
CR を適用します。$ oc apply -f <filename>.yaml