AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Docs Menu
Docs Home
/ /
トラブルシューティング
Docs Home
/
管理
/
Cloud Manager
/
トラブルシューティング
Docs Home
/
管理
/
Cloud Manager
/
トラブルシューティング

オートメーション

Cloud Manager Automation を使用すると、Cloud Manager UI を使用して MongoDB 配置を配置、構成、および管理できます。 Cloud Manager Automation は MongoDB Agent に依存します。このエージェントは、配置内のすべてのサーバーにインストールする必要があります。 MongoDB エージェントは定期的に Cloud Manager サービスをポーリングして現在のターゲットを決定し、そのステータスを Cloud Manager に継続的に報告します。

オートメーションは 64 ビットのアーキテクチャでのみ実行

Cloud Manager では、MongoDB Agent の 64 ビットのダウンロードのみを提供します。

独自のハードウェアの使用

  • オートメーションを手動で配置する場合は、すべてのサーバー上に 1 つの MongoDB Agent があることを確認してください。

  • エージェントを手動で配置する場合は、MongoDB のdbPathと MongoDB バイナリ用の ディレクトリを作成し、エージェントを実行するユーザーがこれらのディレクトリを所有するようにする必要があります。

    rpmパッケージを使用してインストールすると、エージェントはmongodユーザーとして実行されます。 debパッケージを使用する場合、エージェントはmongodbユーザーとして実行されます。 tar.gzアーカイブ ファイルを使用してインストールする場合は、任意のユーザーとしてエージェントを実行できます。

ネットワーキング

MongoDB ポートへの接続

すべてのホストは MongoDB ポート間の通信を許可できる必要があります。 デフォルトは27017ですが、Cloud Manager インターフェースで代替のポート範囲を構成できます。

MongoDB Agent はポート443でcloud.mongodb.comに接続できる必要があります（ HTTPS ）。 ポートと IP アドレスへのアクセスの詳細については、「セキュリティの概要 」を参照してください。

クラスター内接続の問題

ローリング更新を実行する場合、MongoDB Agent はダウンタイムを回避しようとします。 クラスターの他のノードから状態を収集する必要があります。 ホスト名の解決やファイアウォールの設定の誤りなど、接続の問題（ mongodからmongosの間）により、MongoDB Agent がリモート プロセスの状態を決定し、変更を完了できない可能性があります。

クラスターのすべてのノードが相互に通信できるようにするには、次の操作を実行します。

  1. シャーディングされていないクラスターの場合：

    1. 各mongodにログインします。

    2. そのmongodホストから、レプリカセットの他のすべてのメンバーにログインします。

  2. シャーディングされたクラスターの場合：

    1. 各mongodにログインします。

    2. そのmongodホストから、シャードの他のすべてのノードにログインします。

    3. 各mongosにログインします。

    4. そのmongosホストは、次の操作を実行します。

      1. 他のmongosホストにログインします。

      2. 各シャードの他のすべてのノードにログインします。

頻繁にオートメーション接続を行う

MongoDB Agent は、クラスターの各ノードから 10 秒ごとに状態を収集し、環境が期待どおりの状態になることを確認します。 この評価の一部として、MongoDB Agent は接続を作成し、特定のファイルをチェックして状態を判断し、接続を閉じます。 このような頻繁で短時間の接続は MongoDB Agent のルーチン アクティビティの一部であり、パフォーマンスには影響しません。

オートメーション構成

自動化構成が完了したら、配置プランが配置のニーズを満たしていることを確認します。 配置を確認する前に、ホスト名とポートを確認してください。

サイズ設定

  • MongoDB を実行し、データセットの要件をサポートするのに十分なスペースのあるホストをプロビジョニングすることを確認します。

  • 配置を実行するのに十分な数のホストをプロビジョニングしたことを確認します。 各mongodは独自のホスト上で実行する必要があります。

頻繁に接続タイムアウトを行う

MongoDB Agent は、次の 1 つ以上の理由で、接続を頻繁にタイムアウトすることがあります。

  • 接続タイムアウト

  • 高ネットワーク レイテンシ

  • 高負荷

  • 大きな SSL キー

  • CPU 速度が不十分

デフォルトでは、接続は 40 秒後にタイムアウトします。 MongoDB では、接続タイムアウトが頻繁に発生するのを防ぐために、 dialTimeoutSeconds MongoDB Agent の構成設定の値を徐々に増やしていくことをお勧めします。 ただし、この値を増やすと、将来の構成変更の配置に必要な時間も長くなります。 配置に最適な値を決定するまで、小さなインクリメンタル 増加 を試してください。

詳しくは、MongoDB Agent 接続設定のdialTimeoutSecondsを参照してください。

配置

特定の条件が当てはまる場合、 We have detected a potential problem while deploying...を表示するバナーが表示されます。 以下はその例です。

配置の変更が完了できない、または進行しない

配置を追加または再起動し、配置が数分間In Progress状態のままの場合、バナーが表示されます。

この時点で、次の 4 つのオプションがあります。

  1. [View Diagnostics] をクリックします。

    View Diagnosticsモーダルには、デプロイ中に発生した可能性のあるエラーが表示されます。

  2. [View Status] をクリックします。

    Automation Statusモーダルには、配置プロセス、配置ステータス、完了しようとするタスク、配置ステータスが最後に報告された日時の配置プロセスが表示されます。 次の方法で結果をフィルタリングできます。

    • Filter processes検索バーにホスト名を入力します。

    • Process Typeドロップダウンから 1 つ以上のプロセスタイプを選択します。

    • Automation Stateドロップダウンから 1 つ以上のオートメーション状態を選択します。

    個々のプロセスのステータスの詳細については、省略記号アイコンをクリックし、 View DetailsまたはView Agent Logsのいずれかを選択します。

    • View Details は、プロセスのどの配置プランであり、MongoDB Agent が現在そのプランのどのステージにあるかを示します。

    • View Agent Logs 新しいブラウザ ウィンドウが開きますDeployment > Agents > Agent Logs画面が表示され、MongoDB Agent ログの内容がデフォルトで表示されます。 別のエージェント ログを選択するには、 Viewメニューをクリックします。

  3. [View Agent Logs] をクリックします。

    新しいブラウザ ウィンドウが開き、 Deployment > Agents > Agent Logs画面が表示され、MongoDB Agent ログの内容がデフォルトで表示されます。 別のエージェント ログを選択するには、 Viewメニューをクリックします。

  4. [Allow Override & Edit Configuration] をクリックします。

    エラーを診断し、配置構成を修正する必要がある場合は、配置を編集する手順に従ってください。

配置をシャットダウンしても解決策が見つからない場合は、Cloud Manager から配置を削除してください。

MongoDB エージェントがダウンしているか通信していない

If Automation Module of MongoDB Agent can't communicate with the Cloud Manager API endpoint or the MongoDB Server processes, Cloud Manager displays a warning banner in the Project. これは、MongoDB エージェントが通信することが予想されているかどうかに応じて、2 つの方法のいずれかで解決できます。

MongoDB エージェントは通信する必要があります

MongoDB Agent が Cloud Manager ホストまたは MongoDB インスタンスと通信する必要がある場合は、各 MongoDB Agent について次の点を確認してください。

  1. エージェントが各ホスト上で稼働中であること。

  2. エージェントと Cloud Manager API エンドポイントは通信できます。

MongoDB エージェントは通信する必要はありません

MongoDB Agentのオートメーション モジュールがCloud Manager API endpointまたはMongoDB Serverプロセスと通信する必要がある場合は、 MongoDB Serverの自動配置ごとに次の点を確認します。

  1. 警告バナー内のAllow Editing & Override Current Configurationリンクをクリックします。

  2. 不要な MongoDB エージェントを提供するホストで実行されているすべてのプロセス（ mongodとmongos ）を削除します。

MongoDB Agent の権限

権限の問題により、オートメーションによる変更が完了しない可能性があります。 または View StatusView Diagnosticsが権限関連のエラー（open /data/db/mongod.lock: permission denied など）を報告した場合は、MongoDB Agent ユーザーが ファイルとdbpathlogpath ファイルを所有し、読み取りおよび書込み権限があることを確認します。

問題のある MongoDB ホストの排除

コンソールまたはAPIを使用して、古くなった、壊れた、または問題のあるホストをオートメーションから排除できます。 これには、 MongoDB Agent にアクセスできない環境が含まれる場合があります。

コンソールを使用して問題のあるホストを削除するには、以下の手順に従います。

1

MongoDB Cloud Managerで、プロジェクトのProcesses ページに移動します。

  1. まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. サイドバーで、 Database見出しの下のProcessesをクリックします。

[プロセス ]ページが表示されます。

2

ホストを削除します。

  1. 問題が発生しているホストを見つけます。

  2. をクリックします、次にRemove Server 。

    Cloud Manager にAre you sure you want to remove this server>モーダルが表示されます。

  3. このサーバーを削除する場合は、指定されたホスト名をEnter the host nameフィールドに入力し、 Removeをクリックします。

    警告

    Removeをクリックすると、Cloud Manager はこのホストのすべてのモニタリング データを削除します。 Cloud Manager は、このアクションの確認またはキャンセルを提供しません。

    サーバーを削除しない場合は、 Cancelをクリックします。

  4. 変更内容を確認するには、 Review & Deployをクリックします。

    Cloud Manager に推奨される変更が表示されます。

    • 問題がなければ、[ Confirm & Deploy ] をクリックします。

      Cloud Manager はこの時点ですべてのプロセスとエージェントを削除します。

    • さらに設定変更を行う場合は、[ Cancel ] をクリックします。

APIを使用して問題のあるホストを削除するには、次の手順に従います。

  1. 現在のオートメーション構成を取得します。

  2. オートメーション構成のJSONファイルを編集します。

  3. プロセスとレプリカセットから古いノードを削除します。

  4. オートメーション構成ファイルを更新します。

  5. 数分間待ちます。

  6. MongoDB Cloud Managerで、プロジェクトの Agents ページにGoします。

    1. まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー

    2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

    3. サイドバーで、 Database見出しの下のAgentsをクリックします。

    [エージェント ]ページが表示されます。

  7. ホストがエージェントのリストに表示されなくなったことを確認します。

TLS 証明書にサブジェクト代替名が含まれていることを確認する

警告

バージョン 11.11.0.7349-1からの MongoDB Agent では、 サブジェクト代替名 フィールドに値を含めるためにTLS証明書が必要です。 MongoDB Agent 11.11.0.7355以降にアップグレードする前に、MongoDB 配置で使用されているすべてのTLS証明書にSANが含まれていることを確認してください。 [1]

[1]

MongoDB は Go 言語で MongoDB Agent を書き込みました。Go 1.17 では、X.509 コモンネームフィールドをホスト名として使用する能力が削除されました。SAN が存在しない場合です。

クライアントが TLS 証明書を検証するとき、クライアントは証明書の SAN または識別名 (DN) フィールドの値から証明書が適用されるホスト名またはホスト名をチェックします。TLS 証明書を作成する際、ホスト名を保存するために主題コモン名 (CN) フィールドを使用する人もいます。CN には制限があるため、ホスト名を保存するのには適していません。これらの制限には、64 文字の最大長さと名前制約の非対応が含まれます。RFC 2818 は 2000 年 5 月にホスト名を保存するための CN の使用を非推奨にしました。この RFC では、証明書の SAN フィールドに値がない場合、クライアントは CN にフォールバックする必要がありました。RFC 6125 は 2011 年に要件を削除しました。

Go は1.15 RFC2818 6125への準拠を無効にします。また、CN を任意にする RFC の実践を使用します。実際には、この変更により、SAN 値を追加するか、CN の使用を有効にする必要があります。

Go 1.17 では、SAN が存在しない場合に CN を使用するための回避策を除くことになります。

現行バージョンのMongoDB Agentでは、 SAN を使用する必要があります。

詳細を学ぶには、Fraser Tweedale のこのトピックに関するブログ記事を参照してください。

既存のクラスターのメモリに構成ファイルを保存する

Cloud Manager バージョン 4.2 またはバージョン 4.4.0 - 4.4.6 を使用する場合、 enableLocalConfigurationServerをtrueに設定して MongoDB Agent を再起動すると、 エラーが発生する可能性があります。

この問題は、クラスターの作成後にenableLocalConfigurationServerがtrueに設定されている既存のクラスターにのみ影響します。 クラスターを作成する前にこの値を設定しても、この問題はtriggerされません。

既存のクラスターのこの設定を安全に変更するには、次の手順に従います。

  1. MongoDB Agent の構成ファイルの末尾に、次のコマンドを追加します。

    enableLocalConfigurationServer=true

  2. MongoDB Agent によって管理されている各プロセスをシャットダウンします。

  3. 次のコマンドを実行して MongoDB Agent を再起動します。

    service mongodb-mms-automation-agent restart

  4. シャットダウンした MongoDB プロセスを再起動します。

  5. automation-mongod.confファイルに__rest展開ディレクティブがあることを確認します。

メモリに構成ファイルを保存する方法の詳細については、「 MongoDB Agent が構成ファイルとパスワードを管理する方法を構成する 」を参照してください。

戻る

認証

次へ

モニタリング

項目一覧