自己管理型 MongoDB 配置のモニタリング

モニタリング戦略

MongoDB には、実行中の MongoDB インスタンスの状態に関するデータを収集するためのさまざまな方法が提供されています。

• MongoDB は、データベース アクティビティのリアルタイム レポートを提供するユーティリティ セットを配布します。

• MongoDB には、現在のデータベースの状態に関する統計をより忠実に返すさまざまなデータベース コマンドが提供されています。

• MongoDB Atlas は、 MongoDB の配置を実行、監視、および保守するためのクラウドでホストするサービスとしてのデータベースです。

• MongoDB Cloud Managerは、実行中の MongoDB 配置を監視してデータを収集し、そのデータに基づいて可視化とアラートを提供するホスト型サービスです。

• MongoDB Ops Manager は、MongoDB Enterprise Advanced で利用できるオンプレミス ソリューションであり、実行中の MongoDB 配置を監視してデータを収集し、そのデータに基づいて可視化とアラートを提供します。

それぞれの戦略は、いろいろな質問の答えになり、さまざまな状況で役立ちます。これらは補完的な手段です。

MongoDB レポート作成ツール

このセクションでは、MongoDB で配布されるレポート作成方法の概要について説明します。また、それぞれの方法で対処する内容に最適な質問の種類の例も紹介しています。

プロセス ログ

通常の操作中、mongod インスタンスおよび mongos インスタンスは、すべてのサーバー アクティビティと操作のライブ アカウントを標準出力またはログファイルのいずれかに報告します。以下のランタイム設定が、これらのオプションを制御します。

• quiet。ログまたは出力に書き込まれる情報の量を制限します。

• verbosity。ログまたは出力に書き込まれる情報の量を増やします。また、実行時に logLevel パラメータまたは shell での db.setLogLevel() メソッドを使用して、ログの冗長度を変更することもできます。

• path。標準出力ではなく、ファイルへのログを有効にします。この設定を調整するときは、ログファイルへの完全なパスを指定する必要があります。

• logAppend。ファイルを上書きするのではなく、ログファイルに情報を追加します。

mongod -v --logpath /var/log/mongodb/server1.log --logappend

次のデータベースコマンドもログに影響します。

• getLog。mongod プロセス ログからの最近のメッセージを表示します。

• logRotate。mongod プロセスのログファイルのみをローテーションします。「ログファイルのローテーション」を参照してください。

db.clients.insertOne( { "name" : "Joe", "PII" : "Sensitive Information" } )

{
   "t": { "$date": "2024-07-19T15:36:55.024-07:00" },
   "s": "I",
   "c": "COMMAND",
   ...
   "attr": {
      "type": "command",
      ...
      "appName": "mongosh 2.2.10",
      "command": {
         "insert": "clients",
         "documents": [
            {
               "name": "Joe",
               "PII": "Sensitive Information",
               "_id": { "$oid": "669aea8792c7fd822d3e1d8c" }
            }
         ],
         "ordered": true,
         ...
      }
      ...
   }
}

{
   "t": { "$date": "2024-07-19T15:36:55.024-07:00" },
   "s": "I",
   "c": "COMMAND",
   ...
   "attr": {
      "type": "command",
      ...
      "appName": "mongosh 2.2.10",
      "command": {
         "insert": "###",
         "documents": [
            {
               "name": "###",
               "PII": "###",
               "_id": "###"
            }
         ],
         "ordered": "###",
         ...
      }
      ...
   }
}

パフォーマンス問題の診断

MongoDB を使用してアプリケーションを開発、運用する際には、アプリケーションとしてのデータベースのパフォーマンスを分析する必要がある場合があります。MongoDB パフォーマンスでは、パフォーマンスに影響を与える可能性のあるいくつかの運用上の要因について説明します。

レプリケーションとモニタリング

どの MongoDB インスタンスでも基本的なモニタリングが必要ですが、レプリカセットの場合、管理者はレプリケーションの遅延をモニターする必要があります。"レプリケーションラグ" とは、プライマリ上の書込み (write) 操作をセカンダリにコピー（複製）するのにかかる時間を指します。多少の遅延は許容できるかもしれませんが、レプリケーションラグが大きくなると、次のような重大な問題が発生します。

• プライマリに対するキャッシュ負荷の増大。

• 遅延時間中に発生した操作が、1 つ以上のセカンダリに複製されない。データの永続性を確保するためにレプリケーションを使用している場合、例外的に長い遅延が発生すると、データセットの整合性に影響を与える可能性があります。

• レプリケーションの遅延が操作ログ（oplog）の長さを超える場合、MongoDB はセカンダリで最初の同期を実行し、プライマリからすべてのデータをコピーして、すべてのインデックスを再構築する必要があります。[1] これは通常の状況では一般的ではありませんが、oplog をデフォルトよりも小さく設定すると、問題が発生する可能性があります。

  注意

  oplog のサイズは、mongod コマンドへの --oplogSize 引数、またはできれば、MongoDB 構成ファイルの oplogSizeMB 設定を使用して、最初の実行時にのみ構成できます。--replSet オプションを指定して実行する前にコマンドラインでこれを指定しない場合、mongod はデフォルト サイズの oplog を作成します。

  デフォルトでは、oplog は、 64ビットシステムで使用可能な合計ディスク領域の5 % です。 oplog oplogの変更の詳細については、「 自己管理型レプリカセット ノードの oplog サイズの変更 」を参照してください。

rs.status()

シャーディングとモニタリング

ほとんどの場合、シャーディングされたクラスターのコンポーネントは、他のすべての MongoDB インスタンスと同じモニタリングと分析のメリットを得ます。さらにクラスターでは、データがノード間で効果的に分散され、シャーディング操作が適切に機能していることを確認するために、さらなるモニタリングが必要です。

use config
db.locks.find()

db.locks.find( { _id : "balancer" } )

Storage Node Watchdog

Storage Node Watchdog は、次の MongoDB ディレクトリをモニターして、ファイルシステムの応答なしを検出します。

• --dbpath ディレクトリ

• が有効な場合の ディレクトリ内のjournal ディレクトリ--dbpathjournaling

• --logpath ファイルのディレクトリ

• --auditPath ファイルのディレクトリ

デフォルトでは、Storage Node Watchdog は無効になっています。スタートアップ時に mongod で Storage Node Watchdog を有効にするには、watchdogPeriodSeconds パラメータを 60 以上の整数に設定する必要があります。有効にすると、実行中に Storage Node Watchdog を一時停止し、再起動できます。詳細については、watchdogPeriodSeconds パラメータを参照してください。

モニター対象ディレクトリを含むファイルシステムのいずれかが応答しなくなった場合、Storage Node Watchdog は mongod を終了し、ステータス コード 61 で閉じます。mongod がレプリカセットのプライマリである場合、終了によってフェイルオーバーが開始され、別のノードがプライマリになれます。

mongod が終了すると、同じマシン上で正常に再起動できない可能性があります。

Storage Node Watchdog が応答しないファイルシステムを検出して終了するまでの最大時間は、watchdogPeriodSeconds の値のほぼ 2 倍です。