自己管理型 MongoDB 配置のモニタリング
モニタリングは、すべてのデータベース管理において重要な要素です。MongoDB のレポート作成をしっかりと理解することで、データベースの状態を評価し、危機に陥ることなく配置を維持できます。さらに、MongoDB の通常の運用パラメータを理解することで、障害にエスカレートする前に問題を診断することができます。
このドキュメントでは、MongoDB で利用可能なモニタリング ユーティリティとレポート統計の概要について説明します。また、レプリカセットとシャーディングされたクラスターをモニタリングするための診断戦略と提案も紹介します。
モニタリング戦略
MongoDB には、実行中の MongoDB インスタンスの状態に関するデータを収集するためのさまざまな方法が提供されています。
MongoDB は、データベース アクティビティのリアルタイム レポートを提供するユーティリティ セットを配布します。
MongoDB には、現在のデータベースの状態に関する統計をより忠実に返すさまざまなデータベース コマンドが提供されています。
MongoDB Atlas は、 MongoDB の配置を実行、監視、および保守するためのクラウドでホストするサービスとしてのデータベースです。
MongoDB Cloud Managerは、実行中の MongoDB 配置を監視してデータを収集し、そのデータに基づいて可視化とアラートを提供するホスト型サービスです。
MongoDB Ops Manager は、MongoDB Enterprise Advanced で利用できるオンプレミス ソリューションであり、実行中の MongoDB 配置を監視してデータを収集し、そのデータに基づいて可視化とアラートを提供します。
それぞれの戦略は、いろいろな質問の答えになり、さまざまな状況で役立ちます。これらは補完的な手段です。
MongoDB レポート作成ツール
このセクションでは、MongoDB で配布されるレポート作成方法の概要について説明します。また、それぞれの方法で対処する内容に最適な質問の種類の例も紹介しています。
ユーティリティ
MongoDB ディストリビューションには、インスタンスのパフォーマンスやアクティビティに関する統計情報をすばやく返す多数のユーティリティがあります。通常、これらは問題を診断し、通常の操作を評価するのに最も役立ちます。
mongostat
mongostat
をキャプチャし、データベース操作のカウントをタイプ別に返します(たとえば、挿入、クエリ、更新、削除など)。これらのカウントは、サーバーの負荷分散を報告します。
mongostat
を使用して、操作タイプの分布を理解し、キャパシティー プランニングに情報を与えます。詳細については、mongostat
リファレンス ページを参照してください。
mongotop
mongotop
は、MongoDB インスタンスの現在の読み取りおよび書込み (write) アクティビティを追跡および報告し、これらの統計をコレクションごとに報告します。
mongotop
を使用して、データベースのアクティビティと使用が予想どおりであるかどうかを確認します。詳細については、mongotop
リファレンス ページを参照してください。
コマンド
MongoDB には、データベースの状態を報告するコマンドが多数含まれています。
これらのデータは、上記で説明したユーティリティよりも細かいレベルの粒度を提供する可能性があります。カスタム アラートを作成したり、インスタンスのアクティビティに応じてアプリケーションの動作を変更したりするには、その出力をスクリプトやプログラムで使用することを検討してください。db.currentOp()
メソッドは、データベース インスタンスの進行中の操作を識別するためのもう 1 つの便利なツールです。
serverStatus
serverStatus
コマンド、または shell からの db.serverStatus()
は、ディスク使用量、メモリ使用量、接続、ジャーナリング、およびインデックス アクセスの詳細を含む、データベースの状態の概要を返します。コマンドはすぐに返されるため、MongoDB のパフォーマンスには影響しません。
serverStatus
は、MongoDB インスタンスの状態のアカウントを出力します。このコマンドが直接実行されることはほぼありません。ほとんどの場合、MongoDB Cloud Manager や Ops Manager などの監視ツールを使うとわかるように、データは集約することでより意味のあるものになります。ただし、すべての管理者は serverStatus
が提供するデータに精通している必要があります。
dbStats
dbStats
コマンド、または shell から db.stats()
を行うと、ストレージの使用とデータ量に対処するドキュメントを返します。dbStats
は、使用されているストレージの量、データベースに含まれるデータの量、オブジェクト、コレクション、およびインデックス カウンターを反映します。
このデータを使用して、特定のデータベースの状態とストレージ キャパシティーをモニターします。この出力を使用すると、データベース間の使用状況を比較したり、データベース内の平均のドキュメント サイズを判別したりすることもできます。
collStats
shell から行う collStats
または db.collection.stats()
は、コレクション内のオブジェクトの数、コレクションのサイズ、コレクションで使用されるディスク領域の量、インデックスに関する情報など、コレクション レベルで dbStats
に似た統計情報を提供します。
replSetGetStatus
replSetGetStatus
コマンド(shellからは rs.status()
)は、レプリカセットのステータスの概要を返します。replSetGetStatus ドキュメントには、レプリカセットの状態と構成、およびそのノードに関する統計が詳細に記載されます。
このデータを使用して、レプリケーションが正しく構成されていることを確認し、現在のホストとレプリカセットの他のノードとの間の接続を確認します。
ホスト型(SaaS)モニタリング ツール
これらは、ホストされたサービスとして提供されるモニタリング ツールで、通常は有料のサブスクリプションを通じて提供されます。
名前 | ノート |
---|---|
MongoDB Cloud Manager は、MongoDB の配置を管理するためのクラウドベースのサービスのスイートです。 MongoDB Cloud Manager は、監視、バックアップ、自動化機能を提供します。 オンプレミス ソリューションについてはMongoDB Ops Manager 、 で利用可能なMongoDB Enterprise Advanced も参照してください。 | |
VividCortexは、MongoDB の本番データベースのワークロードとクエリパフォーマンス に関して 1 秒単位の解像度で深いインサイトを提供します。レイテンシ、スループット、エラーなどを追跡することで、MongoDB 上でアプリケーションのスケーラビリティと優れたパフォーマンスを確保します。 | |
MongoDB 用ダッシュボード 、MongoDB 固有のアラート、レプリケーション フェイルオーバー タイムライン、および Windows と Android モバイル アプリ。 | |
IBMは、MongoDB やその他のアプリケーションやミドルウェアのモニターを含むアプリケーション パフォーマンス マネジメント SaaS 製品を提供しています。 | |
New Relic は、アプリケーション パフォーマンス マネジメントの完全なサポートを提供します。さらに、New Relic Plugins と Insights を利用することで、Cloud Managerのモニタリング メトリクスを New Relic で確認することができます。 | |
MongoDB 配置のパフォーマンスを視覚化するためのインフラストラクチャ モニタリング | |
モニタリングならびに異常検知およびアラート発行を行う SPM は、MongoDB のすべての主要なメトリクスを、インフラストラクチャと共に監視します。インフラストラクチャには、Docker や他のアプリケーション指標(Node.js、Java、NGINX、Apache、HAProxy、または Elasticsearch など)が含まれます。SPM は、メトリクスとログの相関関係を提供します。 | |
Pandora FMSは、MongoDB を監視するための PandoraFMS-mongodb-monitoring プラグインを提供します。 |
プロセス ログ
通常の操作中、mongod
インスタンスおよび mongos
インスタンスは、すべてのサーバー アクティビティと操作のライブ アカウントを標準出力またはログファイルのいずれかに報告します。以下のランタイム設定が、これらのオプションを制御します。
quiet
。ログまたは出力に書き込まれる情報の量を制限します。verbosity
。ログまたは出力に書き込まれる情報の量を増やします。また、実行時にlogLevel
パラメータまたは shell でのdb.setLogLevel()
メソッドを使用して、ログの冗長度を変更することもできます。path
。標準出力ではなく、ファイルへのログを有効にします。この設定を調整するときは、ログファイルへの完全なパスを指定する必要があります。logAppend
。ファイルを上書きするのではなく、ログファイルに情報を追加します。
注意
次のデータベースコマンドもログに影響します。
logRotate
。mongod
プロセスのログファイルのみをローテーションします。「ログファイルのローテーション」を参照してください。
ログ リダクション
MongoDB Enterprise でのみ利用可能
redactClientLogData
を使用して実行中の mongod
または mongos
は、特定のログ イベントに付随するすべてのメッセージを、ログに記録する前にレダクションします。そのため、そのイベントに関連するメタデータ、ソース ファイル、行番号のみがログに記録されます。redactClientLogData
は、診断に役立つ詳細情報を犠牲にして、機密情報の可能性がある情報がシステム ログに入力されるのを防ぎます。
たとえば、次の操作は、ログ リダクションなしで実行されている mongod
にドキュメントを挿入します。mongod
では、ログの冗長レベルは 1
に設定されています。
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, ... } ... } }
ともに実行されている mongod
と redactClientLogData
が、同じ挿入操作を実行すると、次のログ イベントが生成されます。
{ "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": "###", ... } ... } }
規制要件への準拠に、redactClientLogData
をを保存時の暗号化および TLS/SSL(トランスポート暗号化)と組み合わせて使用することが役立ちます。
パフォーマンス問題の診断
MongoDB を使用してアプリケーションを開発、運用する際には、アプリケーションとしてのデータベースのパフォーマンスを分析する必要がある場合があります。MongoDB パフォーマンスでは、パフォーマンスに影響を与える可能性のあるいくつかの運用上の要因について説明します。
レプリケーションとモニタリング
どの MongoDB インスタンスでも基本的なモニタリングが必要ですが、レプリカセットの場合、管理者はレプリケーションの遅延をモニターする必要があります。"レプリケーションラグ" とは、プライマリ上の書込み (write) 操作をセカンダリにコピー(複製)するのにかかる時間を指します。多少の遅延は許容できるかもしれませんが、レプリケーションラグが大きくなると、次のような重大な問題が発生します。
プライマリに対するキャッシュ負荷の増大。
遅延時間中に発生した操作が、1 つ以上のセカンダリに複製されない。データの永続性を確保するためにレプリケーションを使用している場合、例外的に長い遅延が発生すると、データセットの整合性に影響を与える可能性があります。
レプリケーションの遅延が操作ログ(oplog)の長さを超える場合、MongoDB はセカンダリで最初の同期を実行し、プライマリからすべてのデータをコピーして、すべてのインデックスを再構築する必要があります。[1] これは通常の状況では一般的ではありませんが、oplog をデフォルトよりも小さく設定すると、問題が発生する可能性があります。
注意
oplog のサイズは、
mongod
コマンドへの--oplogSize
引数、またはできれば、MongoDB 構成ファイルのoplogSizeMB
設定を使用して、最初の実行時にのみ構成できます。--replSet
オプションを指定して実行する前にコマンドラインでこれを指定しない場合、mongod
はデフォルト サイズの oplog を作成します。デフォルトでは、oplog は、 64ビットシステムで使用可能な合計ディスク領域の5 % です。 oplog oplogの変更の詳細については、「 自己管理型レプリカセット ノードの oplog サイズの変更 」を参照してください。
フロー制御
MongoDB 4.2 以降、majority
committed
の遅延を設定可能な最大値 flowControlTargetLagSeconds
以下に抑えることを目的として、プライマリが書き込み (write) を適用する速度を管理者が制限することができます。
デフォルトのフロー制御は、enabled
です。
注意
フロー制御を有効にするには、レプリカセットとシャーディングされたシャーディングされたクラスターは、 の FCV(featureCompatibilityVersion) を有し、かつ読み取り保証( 読み取り保証4.2
(read concern)majority enabled
)が である必要があります。つまり、FCV が でない場合や、読み取り過半数( 読み取り保証 (read concern)4.2
)が無効になっている場合、フロー制御を有効にしても効果はありません。
「レプリケーションラグの確認」も参照してください。
レプリカセットの状態
レプリケーションの問題は、ほとんどの場合、ノード間のネットワーク接続の問題、またはアプリケーションとレプリケーション トラフィックをサポートするためのリソースを持たないプライマリの結果として発生します。 レプリカのステータスを確認するには、shell でreplSetGetStatus
または次のヘルパーを使用します。
rs.status()
replSetGetStatus
リファレンスは、この出力のより詳細な概要ビューを提供します。一般的には、optimeDate
の値を監視し、プライマリ ノードとセカンダリ ノード間の時間差に特に注意を払います。
[1] | oplog は、majority commit point が削除されるのを回避するために、設定されたサイズ制限を超えて大きくなることがあります。 |
Oplog エントリの低速適用
replica setのセカンダリ メンバーは、適用に低速操作しきい値よりも長い時間がかかるoplogをログに記録するようになりました。 これらの遅い oplog メッセージ:
ログは、テキスト
applied op: <oplog entry> took <num>ms
を含むREPL
コンポーネントの下にあります。ログレベルに依存しない(システムレベルでもコンポーネントレベルでも)
プロファイル レベルに依存しないでください。
slowOpSampleRate
の影響を受けます。
プロファイラーは遅い oplog エントリをキャプチャしません。
シャーディングとモニタリング
ほとんどの場合、シャーディングされたクラスターのコンポーネントは、他のすべての MongoDB インスタンスと同じモニタリングと分析のメリットを得ます。さらにクラスターでは、データがノード間で効果的に分散され、シャーディング操作が適切に機能していることを確認するために、さらなるモニタリングが必要です。
コンフィギュレーションサーバー
コンフィギュレーションデータベースは、どのドキュメントがどのシャードにあるかを識別するマップを維持しています。クラスターは、チャンクがシャード間を移動するたびにこのマップを更新します。構成サーバーにアクセスできなくなると、チャンクの移動や mongos
インスタンスの起動など、特定のシャーディング操作が利用できなくなります。ただし、すでに実行中の mongos
インスタンスからクラスターに引き続きアクセスできます。
構成サーバーにアクセスできない場合、シャーディングされたクラスターの可用性に深刻な影響を与える可能性があるため、構成サーバーをモニターしてクラスターのバランスが保たれ、mongos
インスタンスが再起動できることを確認する必要があります。
MongoDB Cloud Manager と Ops Manager はコンフィギュレーションサーバーを監視し、コンフィギュレーションサーバーにアクセスできなくなった場合に通知を作成できます。詳細については、MongoDB Cloud Manager のドキュメントと MongoDB Ops Manager のドキュメントを参照してください。
バランス調整とチャンク分散
最も効果的なシャーディングされたクラスターの配置では、シャード間でチャンクが均等に分散されます。これを容易にするために、MongoDB には、チャンクが常にシャード間で最適に分散されるようにデータを分散するバックグラウンド バランサー プロセスがあります。
mongosh
内から mongos
に db.printShardingStatus()
コマンドまたは sh.status()
コマンドを発行します。データベース名を含むクラスター全体とチャンクのリストの概要を返します。
古いロック
データベースのロック状態を確認するには、mongosh
を使用して mongos
インスタンスに接続します。次のコマンド シーケンスを実行して config
データベースに切り替え、シャード データベースのすべての未処理のロックを表示します。
use config db.locks.find()
バランシング プロセスでは、他のバランシング アクティビティの発生を防ぐ特別な "バランサー" ロックがかかります。config
データベースで、次のコマンドを使用して "バランサー" ロックを表示します。
db.locks.find( { _id : "balancer" } )
CSRS コンフィギュレーションサーバーのプライマリは、"ConfigServer" という名前のプロセス ID を使用して "バランサー" ロックを保持します。 このロックは解放されません。 バランサーが実行中かどうかを確認するには、「 バランサーが実行中かどうかを確認する 」を参照してください。
Storage Node Watchdog
注意
ストレージ ノード ウォッチドッグは、Community エディションと MongoDB Enterprise エディションの両方で利用できます。
Storage Node Watchdog は、次の MongoDB ディレクトリをモニターして、ファイルシステムの応答なしを検出します。
--dbpath
ディレクトリ--dbpath
ディレクトリ内のjournal
ディレクトリ--logpath
ファイルのディレクトリ--auditPath
ファイルのディレクトリ
注意
MongoDB 6.1 以降では、ジャーナリングは常に有効になっています。その結果、MongoDB は storage.journal.enabled
オプションと、それに対応するコマンドライン オプションの --journal
および --nojournal
を削除します。
デフォルトでは、Storage Node Watchdog は無効になっています。スタートアップ時に mongod
で Storage Node Watchdog を有効にするには、watchdogPeriodSeconds
パラメータを 60 以上の整数に設定する必要があります。有効にすると、実行中に Storage Node Watchdog を一時停止し、再起動できます。詳細については、watchdogPeriodSeconds
パラメータを参照してください。
モニター対象ディレクトリを含むファイルシステムのいずれかが応答しなくなった場合、Storage Node Watchdog は mongod
を終了し、ステータス コード 61 で閉じます。mongod
がレプリカセットのプライマリである場合、終了によってフェイルオーバーが開始され、別のノードがプライマリになれます。
mongod
が終了すると、同じマシン上で正常に再起動できない可能性があります。
注意
Symlinks
モニター対象ディレクトリの中に他のボリュームへのシンボリック リンクである場合、ストレージ ノード ウオッチドッグ はシンボリックリンクのターゲットのターゲットのモニターは行いません。
たとえば、mongod
が storage.directoryPerDB: true
(または --directoryperdb
)を使用してデータベース ディレクトリを別のボリュームにシンボリック リンクする場合、Storage Node Watchdog はシンボリック リンクに従ってターゲットを監視することはありません。
Storage Node Watchdog が応答しないファイルシステムを検出して終了するまでの最大時間は、watchdogPeriodSeconds
の値のほぼ 2 倍です。