2.4. ロギングデプロイメントの設定
各 Operator によって実装されたカスタムリソース (CR) YAML ファイルを使用して、ロギングサブシステムのデプロイメントを設定できます。
Red Hat Openshift Logging Operator:
-
ClusterLogging(CL) - コレクターとフォワーダーをデプロイします。現在、どちらも各ノードで実行されているデーモンセットによって実装されています。 -
ClusterLogForwarder(CLF)- ユーザー設定ごとにログを転送するためのコレクター設定を生成します。
Loki Operator:
-
LokiStack- Loki クラスターをログストアとして制御し、OpenShift Container Platform 認証統合を使用して Web プロキシーを制御して、マルチテナンシーを強制します。
OpenShift Elasticsearch Operator:
これらの CR は ClusterLogging Operator によって生成および管理され、手動で変更すると必ず Operator によって上書きされます。
-
Elasticsearch- Elasticsearch インスタンスをデフォルトのログストアとして設定し、デプロイします。 -
Kibana- ログの検索、クエリー、表示を実行するために Kibana インスタンスを設定し、デプロイします。
Red Hat OpenShift のロギングサブシステムを設定するためにサポートされている方法は、このドキュメントで説明されているオプションを使用して設定することです。サポートされていない他の設定は使用しないでください。設定のパラダイムが OpenShift Container Platform リリース間で変更される可能性があり、このような変更は、設定のすべての可能性が制御されている場合のみ適切に対応できます。このドキュメントで説明されている以外の設定を使用すると、Operator が相違点を調整するため、変更内容は失われます。Operator はデフォルトで定義された状態にすべて戻します。
OpenShift Container Platform ドキュメントで説明されていない設定を実行する必要がある場合は、Red Hat OpenShift Logging Operator を Unmanaged に設定する必要があります。マネージド外の OpenShift ロギング環境はサポートされておらず、OpenShift ロギングを Managed に戻すまで更新を受け取りません。
2.4.1. Loki でストリームベースの保持を有効にする
Logging バージョン 5.6 以降では、ログストリームに基づいて保持ポリシーを設定できます。これらのルールは、グローバル、テナントごと、またはその両方で設定できます。両方で設定すると、グローバルルールの前にテナントルールが適用されます。
-
ストリームベースの保持を有効にするには、
LokiStackカスタムリソース (CR) を作成または編集します。
oc create -f <file-name>.yaml
- 以下の例を参照して、LokiStack CR を設定できます。
グローバルなストリームベースの保持の例
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
name: logging-loki
namespace: openshift-logging
spec:
limits:
global: 1
retention: 2
days: 20
streams:
- days: 4
priority: 1
selector: '{kubernetes_namespace_name=~"test.+"}' 3
- days: 1
priority: 1
selector: '{log_type="infrastructure"}'
managementState: Managed
replicationFactor: 1
size: 1x.small
storage:
schemas:
- effectiveDate: "2020-10-11"
version: v11
secret:
name: logging-loki-s3
type: aws
storageClassName: standard
tenants:
mode: openshift-logging
- 1
- すべてのログストリームの保持ポリシーを設定します。注記: このフィールドは、オブジェクトストレージに保存されたログの保持期間には影響しません。
- 2
- このブロックが CR に追加されると、クラスターで保持が有効になります。
- 3
- ログストリームの定義に使用される LogQL クエリー が含まれています。
テナントごとのストリームベースの保持の例
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
name: logging-loki
namespace: openshift-logging
spec:
limits:
global:
retention:
days: 20
tenants: 1
application:
retention:
days: 1
streams:
- days: 4
selector: '{kubernetes_namespace_name=~"test.+"}' 2
infrastructure:
retention:
days: 5
streams:
- days: 1
selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}'
managementState: Managed
replicationFactor: 1
size: 1x.small
storage:
schemas:
- effectiveDate: "2020-10-11"
version: v11
secret:
name: logging-loki-s3
type: aws
storageClassName: standard
tenants:
mode: openshift-logging
- 1
- テナントごとの保持ポリシーを設定します。有効なテナントタイプは、
application、audit、およびinfrastructureです。 - 2
- ログストリームの定義に使用される LogQL クエリー が含まれています。
- 次に、設定を適用します。
oc apply -f <file-name>.yaml
これは、保存されたログの保持を管理するためのものではありません。保存されたログのグローバルな保持期間 (最大 30 日間までサポート) は、オブジェクトストレージで設定します。
2.4.2. 複数行の例外検出の有効化
コンテナーログの複数行のエラー検出を有効にします。
この機能を有効にすると、パフォーマンスに影響が出る可能性があり、追加のコンピューティングリソースや代替のロギングソリューションが必要になる場合があります。
ログパーサーは頻繁に、同じ例外の個別の行を別々の例外として誤って識別します。その結果、余分なログエントリーが発生し、トレースされた情報が不完全または不正確な状態で表示されます。
Java 例外の例
java.lang.NullPointerException: Cannot invoke "String.toString()" because "<param1>" is null
at testjava.Main.handle(Main.java:47)
at testjava.Main.printMe(Main.java:19)
at testjava.Main.main(Main.java:10)
-
ロギングを有効にして複数行の例外を検出し、それらを 1 つのログエントリーに再アセンブルできるようにする場合は、
ClusterLogForwarderカスタムリソース (CR) に、値がtrueのdetectMultilineErrorsフィールドが含まれていることを確認します。
ClusterLogForwarder CR の例
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
name: instance
namespace: openshift-logging
spec:
pipelines:
- name: my-app-logs
inputRefs:
- application
outputRefs:
- default
detectMultilineErrors: true
2.4.2.1. 詳細
ログメッセージが例外スタックトレースを形成する連続したシーケンスとして表示される場合、それらは単一の統合ログレコードに結合されます。最初のログメッセージの内容は、シーケンス内のすべてのメッセージフィールドの連結コンテンツに置き換えられます。
表2.2 各コレクターでサポートされている言語:
| 言語 | Fluentd | Vector |
|---|---|---|
| Java | ✓ | ✓ |
| JS | ✓ | ✓ |
| Ruby | ✓ | ✓ |
| Python | ✓ | ✓ |
| golang | ✓ | ✓ |
| PHP | ✓ | |
| Dart | ✓ | ✓ |
2.4.2.2. トラブルシューティング
有効にすると、コレクター設定には detect_exceptions タイプの新しいセクションが含まれます。
vector 設定セクションの例
[transforms.detect_exceptions_app-logs] type = "detect_exceptions" inputs = ["application"] languages = ["All"] group_by = ["kubernetes.namespace_name","kubernetes.pod_name","kubernetes.container_name"] expire_after_ms = 2000 multiline_flush_interval_ms = 1000
fluentd 設定セクションの例
<label @MULTILINE_APP_LOGS>
<match kubernetes.**>
@type detect_exceptions
remove_tag_prefix 'kubernetes'
message message
force_line_breaks true
multiline_flush_interval .2
</match>
</label>
2.4.3. Loki を使用したログベースアラートの有効化
Loki アラートルールは、LogQL を使用し、Prometheus 形式 に準拠します。AlertingRule カスタムリソース (CR) を作成して、ログベースアラートを設定できます。AlertingRule CR は、application、audit、infrastructure テナント用に作成できます。
| テナントタイプ | 有効な namespace |
|---|---|
| application | |
| audit |
|
| infrastructure |
|
ローカル Alertmanager インスタンスを無効化している場合を除き、アプリケーション、監査、およびインフラストラクチャーアラートは、デフォルトで openshift-monitoring namespace の Cluster Monitoring Operator (CMO) Alertmanager に送信されます。
別の Alertmanager インスタンスを有効化している場合を除き、アプリケーションアラートはデフォルトで openshift-user-workload-monitoring namespace の CMO Alertmanager には送信されません。
AlertingRule CR には、単一の LokiStack インスタンスのアラートルールグループを宣言するために使用する、仕様および Webhook 検証定義のセットが含まれます。Webhook 検証定義は、ルール検証条件もサポートします。
-
AlertingRuleCR に無効なinterval期間が含まれる場合、無効なアラートルールです。 -
AlertingRuleCR に無効なfor期間が含まれる場合、無効なアラートルールです。 -
AlertingRuleCR に無効な LogQLexprが含まれる場合、無効なアラートルールです。 -
AlertingRuleCR に同じ名前のグループが 2 つ含まれる場合、無効なアラートルールです。 -
上記のいずれも該当しない場合、
AlertingRuleは有効なアラートルールとみなされます。
前提条件
- Red Hat OpenShift Operator 5.7 以降のロギングサブシステム
- OpenShift Container Platform 4.13 以降
手順
AlertingRule CR を作成します。
oc create -f <file-name>.yaml
以下の該当する例を使用して、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/cluster-monitoring: "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 が作成される
namespaceには、LokiStack のspec.rules.namespaceSelector定義に一致するラベルが必要です。 - 2
labelsブロックは、LokiStack のspec.rules.selector定義と一致する必要があります。- 3
infrastructureテナントの AlertingRules は、openshift-*、kube-\*、またはdefaultnamespace でのみサポートされます。- 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/cluster-monitoring: "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 が作成される
namespaceには、LokiStack のspec.rules.namespaceSelector定義に一致するラベルが必要です。 - 2
labelsブロックは、LokiStack のspec.rules.selector定義と一致する必要があります。- 3
kubernetes_namespace_name:の値は、metadata.namespaceの値と一致する必要があります。- 4
- 必須フィールド。
critical、warning、infoのいずれかとします。 - 5
- 必須フィールド。ルールの概要。
- 6
- 必須フィールド。ルールの詳細な説明。
CR を適用します。
oc apply -f <file-name>.yaml