MongoDBおよびMongoDB Ops Manager CRD マニフェストで CustomResourceDefinitions のログローテーション設定を構成できます。
次の表は、MongoDB CRDマニフェストで定義できるロギング構成フィールドと、 CRDマニフェストから直接構成しないことを選択した場合に、他の場所で定義またはアクセスできるロギング構成フィールドの概要をまとめたものです。
コンポーネント | ログの種類 | CRD マニフェストの構成 | デフォルトの構成場所 |
|---|---|---|---|
MongoDB | オートメーションエージェント ログ | ||
MongoDB | モニタリングエージェント ログ | MongoDB Ops Manager API または UI | |
MongoDB | バックアップ ログ | MongoDB Ops Manager API または UI | |
MongoDB | MongoDB ログ | MongoDB Ops Manager 7.0.4、 6.0.24 、またはそれ以降は | MongoDB Ops Manager UI |
MongoDB | 監査ログ | MongoDB Ops Manager UI | |
MongoDB | 準備状況プロファイル | ||
アプリケーション データベース | MongoDB ログ | ||
アプリケーション データベース | オートメーションエージェント ログ | ||
アプリケーション データベース | モニタリングエージェント ログ |
| |
アプリケーション データベース | 監査ログ | ||
Ops Manager | MongoDB Ops Managerログ |
MongoDB のログ ローテーション
注意
MongoDB Ops Manager 6 では、バージョン 6.0.2 以降のみ、この設定で mongod ログを構成できます。 MongoDB Ops Manager 7 の場合、この設定ではバージョン 7.0.4 以降のみ mongod ログを構成できます。 以前のMongoDB Ops Managerバージョンでは、mongod ログを構成するにはMongoDB Ops Manager UI を使用する必要があります。
次のサンプルマニフェストに示すように、 MongoDB CRDでログのローテーションを構成できます。
その他の MongoDB 固有のログのローテーション構成の詳細については、前述の比較表を参照してください。
オートメーションエージェント ログ
MongoDB CRDマニフェストの MongoDB オートメーションエージェント ログはspec.agent.startupOptionsの下で構成できます。
サンプルマニフェスト
次のマニフェストの例は、 MongoDBカスタムリソースでログローテーション を構成するためのスキーマを示しています。表示されている値はデモンストレーションのためのものであり、推奨される設定ではありません。構成設定とそのデータ型と使用方法の詳細については、「 MongoDB Database リソース仕様 」を参照してください。
注意
シャーディングされたクラスターの場合、ログ ローテーションはspec.agentレベルでのみ構成できます。 spec.configsrv.agentやspec.shardsvr.agentなどのサブ仕様レベルでのログ ローテーションの構成はサポートされていません。
apiVersion: mongodb.com/v1 kind: MongoDB metadata: name: log-rotate namespace: mongodb spec: podSpec: podTemplate: spec: containers: - name: mongodb-enterprise-database env: - name: READINESS_PROBE_LOGGER_MAX_SIZE value: "50" version: 8.0.0 opsManager: configMapRef: name: my-project credentials: my-credentials type: Standalone persistent: false # https://docs.opsmanager.mongodb.com/current/reference/mongodb-agent-settings/ agent: startupOptions: maxLogFiles: "10" maxLogFileSize: "2" readinessProbe: environmentVariables: READINESS_PROBE_LOGGER_MAX_SIZE: "10" READINESS_PROBE_LOGGER_BACKUPS: "1" READINESS_PROBE_LOGGER_MAX_AGE: "3" READINESS_PROBE_LOGGER_COMPRESS: "true" MDB_WITH_AGENT_FILE_LOGGING: "false" LOG_FILE_PATH: /var/log/mongodb-mms-automation/readiness.log backupAgent: logRotate: sizeThresholdMB: 10 timeThresholdHrs: 10 monitoringAgent: logRotate: sizeThresholdMB: 10 timeThresholdHrs: 10 # For Ops Manager 6, you can only configure mongod logs with this setting starting with version 6.0.2. # For Ops Manager 7, you can only configure mongod logs with this setting starting with version 7.0.4. # For previous Ops Manager versions, you must configure mongod logs using the Ops Manager UI. mongod: logRotate: sizeThresholdMB: "10" timeThresholdHrs: 10 numUncompressed: 10 numTotal: 10 percentOfDiskspace: "0.02" auditlogRotate: sizeThresholdMB: "10" timeThresholdHrs: 10 numUncompressed: 10 numTotal: 10 percentOfDiskspace: "0.02"
アプリケーション データベースのログ ローテーション
次のマニフェストの例に示すように、 MongoDBOpsManager CRDで次のログのローテーションを構成できます。 その他のアプリケーション データベース固有のログのローテーションの構成の詳細については、前の表を参照してください。
MongoDB ログ
アプリケーション データベース MongoDB のログ ローテーションは、 spec.applicationDatabase.agent.<component>.logRotateの下のMongoDBOpsManagerマニフェストで構成できます。 MongoDB は、デフォルトで最新の 2 つのログを超えるログファイルを圧縮します。
- ログ:
/var/log/mongodb-mms-automation/mongodb.log
オートメーションエージェント ログ
アプリケーション データベース オートメーションエージェントのログ ローテーションは、 spec.applicationDatabase.agent.startupOptionsの下のMongoDBOpsManagerマニフェストで構成できます。
- ログ:
/var/log/mongodb-mms-automation/automation-agent-stderr.log/var/log/mongodb-mms-automation/automation-agent-verbose.log/var/log/mongodb-mms-automation/automation-agent.log
監査ログ
アプリケーション データベース監査のログ ローテーションは、 spec.applicationDatabase.agent.mongod.auditlogRotateの下のMongoDBOpsManagerマニフェストで構成できます。
注意
auditLogRotate 設定は logRotate 設定によって異なります。auditLogRotate を有効にするには、logRotate も構成する必要があります。
- ログ:
/var/log/mongodb-mms-automation/mongodb-audit.log
サンプルマニフェスト
次のマニフェストの例は、 カスタムリソースでアプリケーションMongoDBOpsManager データベースのログローテーションを構成するスキーマを示しています。表示されている値はデモンストレーションのためのものであり、推奨される設定ではありません。構成設定とそのデータ型と使用方法の詳細については、「 MongoDB Database リソース仕様 」を参照してください。
apiVersion: mongodb.com/v1 kind: MongoDBOpsManager metadata: name: ops-manager namespace: mongodb spec: replicas: 1 version: 8.0.0 adminCredentials: ops-manager-admin-secret applicationDatabase: version: "8.0.0" members: 3 agent: #agent.logRotate is deprecated and overwritten by agent.mongod.logRotate. logRotate: #Automation Agent log rotation startupOptions: maxLogFiles: "10" maxLogFileSize: "2" #Readiness probe log rotation readinessProbe: environmentVariables: READINESS_PROBE_LOGGER_MAX_SIZE: "10" READINESS_PROBE_LOGGER_BACKUPS: "1" READINESS_PROBE_LOGGER_MAX_AGE: "3" READINESS_PROBE_LOGGER_COMPRESS: "true" MDB_WITH_AGENT_FILE_LOGGING: "false" LOG_FILE_PATH: /var/log/mongodb-mms-automation/readiness.log #AppDB backup log rotation backupAgent: logRotate: sizeThresholdMB: 10 timeThresholdHrs: 10 #AppDB Monitoring Agent log rotation monitoringAgent: logRotate: sizeThresholdMB: 10 timeThresholdHrs: 10 #AppDB (mongod) log rotation mongod: logRotate: sizeThresholdMB: "10" timeThresholdHrs: 10 numUncompressed: 10 numTotal: 10 percentOfDiskspace: "0.02" auditlogRotate: sizeThresholdMB: "10" timeThresholdHrs: 10 numUncompressed: 10 numTotal: 10 percentOfDiskspace: "0.02"
MongoDB Ops Managerログ ローテーション
MongoDB Ops Managerを管理およびローテーションするには、StatusSet を手動で上書きするか、CRD 設定を使用します。
StateftSet を使用したMongoDB Ops Managerログの構成
MongoDB Ops Managerログを管理およびローテーションするには、 ConfigMap とステートメントを使用してデフォルトのログ構成を手動で上書きします。 このプロセスでは、カスタム logback.xml 構成ファイルを作成し、それをMongoDB Ops Managerポッドに適用します。
logback.xmlカスタム 構成ファイルを作成します。
次のコマンドを実行すると、テンプレートとして使用する既存のlogback.xmlを取得できます。
kubectl cp om-pod-spec-0:/mongodb-ops-manager/conf/logback.xml ~/Downloads/logback-confs/logback.xml
カスタム logback.xml の作成の詳細については、「 MongoDB Ops Managerのログ ローテーション ポリシーの変更 」を参照してください。
StateftSet 構成を上書きします。
StateftSet オーバーライド機能を使用して、 MongoDB Ops Managerポッドにカスタム logback.xml をマウントします。 以下を Atlas App Services 構成に追加します。
注意
次の ConfigMap のkeyは、デフォルトのファイルを同じ名前に正しく置き換えるために、デフォルトでlogback.xmlです。
spec: template: spec: volumes: - name: logback-volume configMap: name: logback-config items: - key: logback.xml path: logback.xml containers: - name: mongodb-ops-manager volumeMounts: - name: logback-volume mountPath: /mongodb-ops-manager/conf-template/logback.xml subPath: logback.xml
CRD を使用したMongoDB Ops Managerログの構成
また、MongoDB Ops Manager CRD 設定を使用して のログ ローテーションを管理することもできます。これにより、 CRD で ConfigMap に直接リンクしてログ ローテーション プロセスが簡素化されます。
logback.xmlカスタム 構成ファイルを作成します。
次のコマンドを実行すると、テンプレートとして使用する既存のlogback.xmlを取得できます。
kubectl cp om-pod-spec-0:/mongodb-ops-manager/conf/logback.xml ~/Downloads/logback-confs/logback.xml
カスタム logback.xml の作成の詳細については、「 MongoDB Ops Managerのログ ローテーション ポリシーの変更 」を参照してください。
(任意)logback-access.xml カスタム 構成ファイルを作成します。
ウェブサーバーによって処理されるような HTTP アクセス リクエストのログを構成するには、 logback-access.xmlファイルを使用します。 これらのアクセス ログの管理方法をカスタマイズするには、 logback.xmlと同様のカスタムlogback-access.xmlファイルを作成します。
次のコマンドを実行して、テンプレートとして使用する既存のlogback-access.xmlを取得します。
kubectl cp om-pod-spec-0:/mongodb-ops-manager/conf/logback-access.xml ~/Downloads/logback-confs/logback-access.xml
ログ記録要件に従ってこのファイルを変更します。
カスタムlogback.xml とlogback-access.xml から ConfigMap を作成します。
ConfigMap のキーが置き換えるファイルの名前と正確に一致していることを確認して、マウント パスとサブパスが上書きするファイルは 1 つだけで、ディレクトリ全体ではなく 1 つのファイルのみを上書きします。 次の例では、デフォルトのファイル名であるlogback.xmlとlogback-access.xmlを使用します。
kubectl create configmap logback-config --from-file=logback.xml=path/to/your/custom_logback.xml
kubectl create configmap logback-access-config --from-file=logback-access.xml=path/to/your/custom_access_logback.xml
CRD ログ プロパティを設定します。
次の設定をMongoDB Ops Manager CRDに追加します。
注意
ファイル名logback.xmlとlogback-access.xmlはデフォルトのファイル名であり、Kubernetes Operator がそれらを認識するには ConfigMap 内のキーである必要があります。
以下に例を挙げます。
apiVersion: mongodb.com/v1 kind: MongoDBOpsManager metadata: name: ops-manager namespace: mongodb spec: replicas: 1 version: 8.0.0 adminCredentials: ops-manager-admin-secret logging: LogBackAccessRef: name: logback-access-config LogBackRef: name: logback-config backup: enabled: true logging: LogBackAccessRef: name: my-logback-access-cm-backup LogBackRef: name: my-logback-cm-backup
Ops Manager カスタムリソースでボリュームを定義すると、 Kubernetes は前述の例と同様にボリューム マウントを自動的に生成し、ConfigMap ファイルを Ops Manager ポッド内の正しい場所にリンクします。