Docs Menu
Docs Home
/
MongoDB Ops Manager
/

ログを表示、検索、管理する

項目一覧

  • MongoDB リアルタイム ログ
  • MongoDB リアルタイム ログの表示
  • 配置のログ収集の有効化または無効化
  • プロジェクトのログ収集の有効化または無効化
  • MongoDB ディスク上のログ
  • MongoDB ディスク上のログの表示
  • ログ ローテーションの構成
  • エージェント ログ
  • エージェント ログの表示
  • エージェントのログ ローテーションの構成
  • MongoDB Ops Managerログ

MongoDB Ops Managerは、 MongoDBプロセスとそのエージェントの両方のログ情報を収集します。 MongoDB プロセスでは、リアルタイム ログとディスク上のログの両方にアクセスできます。

MongoDB Agent は、モニタリング ping ごとにgetLogコマンドを発行します。 このコマンドは、各 MongoDB プロセスの RAM キャッシュからログ エントリを収集します。

MongoDB Ops Managerでは、デフォルトでリアルタイム ログ収集が有効になります。 プロジェクト内の すべてのMongoDB 配置 MongoDB Ops Managerまたは 個々のMongoDB 配置 のログ収集を無効にできます。ログ収集を無効にすると、 MongoDB Ops Managerは以前に収集されたログ エントリを引き続き表示します。

この機能にアクセスするには、次のいずれかのロールによって付与される特権が必要です。

  • Project Automation Admin

  • Project Backup Admin

  • Project Monitoring Admin

  • Project Owner

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

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

  3. まだ表示されていない場合は、サイドバーの [Deployment] をクリックします。

  1. [Clusters] ビューをクリックします。

2

4 つのボタンは、左から右に ShardsConfigsMongosBIs の順に並んでいます。

プロセス
表示
Shards
データをホストするmongodプロセス。
Configs
シャーディングされたクラスターのメタデータを保存するためのコンフィギュレーション サーバー として実行される mongod プロセス。
Mongos
シャーディングされたクラスターでデータをルーティングするmongosプロセス。
BIs
シャーディングされたクラスター内のデータにアクセスする BI プロセス。
3
4

タブにはログ情報が表示されます。

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

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

  3. まだ表示されていない場合は、サイドバーの [Deployment] をクリックします。

  1. [Clusters] ビューをクリックします。

2
3
  1. [Logs] タブをクリックします。

  2. 必要に応じて、 Collect Logs For HostOffまたはOnに切り替えます。

4

ログ収集をオフにすると、既存のログエントリはLogsタブに残りますが、MongoDB Ops Manager は新しいエントリを収集しません。

1

MongoDB Ops Managerは、 MongoDBインスタンスが実行されていない場合でも、ディスク上のログを収集します。 MongoDB Agent は、 MongoDB systemLog.path構成オプションで指定したロケーションからログを収集します。 MongoDB ディスク上のログは、リアルタイム ログのサブセットであるため、冗長性は低くなります。

ディスク上のログのログ ローテーションを構成できます。 MongoDB Ops Managerはデフォルトでログをローテーションします。

この手順では、 MongoDB Ops Managerのシステム ログと 監査 ログの両方をローテーションします。

この機能にアクセスするには、次のいずれかのロールによって付与される特権が必要です。

1

プロジェクト内の任意のプロセス、レプリカセット、またはシャーディングされたクラスターの行にある省略記号...アイコンをクリックし、 Request Logsをクリックします。

2

ダウンロードするログを選択するには、次のアクションを実行します。

アクション
目的
クリック MongoDB Logs

デプロイされた MongoDB プロセスからログを収集します。

systemLog.d destinationプロパティがsyslogに設定されている場合、このオプションは配置された MongoDB プロセスでは使用できません。

クリック FTDC Data
サーバー統計やステータス メッセージなど、( FTDC )コレクション メカニズムから診断データ ファイルを収集します。
クリック Automation Agent Logs
配置されたオートメーションエージェントからログを収集します。
クリック Backup Agent Logs

配置されたすべてのバックアップエージェントからログを収集します。

これは他のログとは異なります。 収集されるログは、選択したホストに限定されず、配置内のすべてのバックアップエージェントのログが含まれます。

クリック Monitoring Agent Logs

配置されたすべてのモニタリングエージェントからログを収集します。

これは他のログとは異なります。 収集されるログは、選択したホストに限定されず、配置内のすべてのモニタリングエージェントのログが含まれます。

MB でSize per Log Typeを設定

選択されたすべてのログ ファイルの最大累積非圧縮サイズをメガバイト単位で入力します。

  • この制限は累積です。

    • MongoDB またはFTDCログの場合、これによりプロセスごとに収集されるログのサイズが制限されます。

    • エージェントの場合、これによりエージェントごとの関連ログのサイズが制限されます。

  • これらのログファイルはその後アーカイブされ、圧縮されます。

    例、この値を50 MB に設定すると、 は、ダウンロードを選択したすべてのログのすべてのプロセスと各エージェントから合計{MongoDB Ops Manager 501} MBmongod mongosの非圧縮ログファイルを収集します。

  • 現在のログファイルが指定されたサイズより小さい場合、 MongoDB Ops Managerは最新のローテーションされた ファイルも収集します。

  • ログファイルの合計サイズがログファイルの途中で指定されたサイズに達した場合、このログファイルは指定されたサイズに収まる最新の行に切り捨てられます。

  • 収集できるログファイルの最大量は 20 GB です。 この最大数には、有効期限が切れていないすべての収集されたログファイルが含まれます。 追加のログを要求し、それらのログを収集すると 20 GBを超えるログが収集されると、 MongoDB Ops Managerはエラーを生成します。 制限と比較したログの合計量はEstimated Total Sizeとして表示されます。

レプリカセット内のすべてのプロセスから20 MB のログを収集することを選択します。 このレプリカセットには、2 つのホスト上に 3 つのmongodプロセスがあります。

  • host1:27017

  • host2:27017

  • host2:27018

配置では、次のエージェントが実行されます。

オートメーションエージェント
host1, host2, host4, host5
バックアップエージェント
host4
モニタリングエージェント
host4, host5

このレプリカセットのすべてのログタイプを選択し、プロセスあたり 20 MB に制限すると、 MongoDB Ops Managerは Estimated Total Size が 20 GBのうち 220 MB(11 プロセス * 20 MB)であることを示します。

ログ収集が開始されると、 MongoDB Ops Managerは、最新のログエントリから 20 MB のログファイルまたは最後のログの末尾まで、mongod プロセスとそれに関連付けられたFTDCのログディレクトリをスキャンします。 配置内のすべてのモニタリングエージェントとバックアップエージェントもスキャンされます。

  • バックアップエージェントのログは 60 MB で、

  • 各 MongoDB プロセス (3) には、7 MB のログとプロセスあたり 15 MB のFTDCデータが含まれます。

  • 各モニタリングエージェント (2) のログは 30 MB で、

  • 各オートメーションエージェント(2)のログは 12 MB です。

収集されたログの合計サイズは150 MBです。

(20 + (3 * (7 + 15)) + (2 * 20) + (2 * 12)) = 150

  • バックアップエージェントから最大 20 MB のログが収集されます。

  • 各 MongoDB プロセスのすべてのログが収集されます(MongoDB 7 MB + FTDCデータ 15 MB)。

  • 各モニタリングエージェントから最大 20 MB のログが収集されます。

  • host1host2からのすべてのオートメーションエージェント ログが収集されます。 host4host5レプリカセット内のプロセスをホストしません。

ダウンロードしたアーカイブ内のアーカイブ構造は次のとおりです。

host1/27017/mongodb
host1/27017/ftdc
host1/automation_agent
host2/27017/mongodb
host2/27017/ftdc
host2/27018/mongodb
host2/27018/ftdc
host2/automation_agent
host4/backup_agent
host4/monitoring_agent
host5/monitoring_agent
3

ログを匿名化するには、 Replace IP addresses, hostnames, namespaces, strings with randomized valuesを選択します。

このオプションは、IP アドレスをプライベート範囲(192.168.x)に置き換えます。 ホスト名の場合、このオプションはFQDNのみを置き換えます。 その他のホスト名は変更されません。 置換は予測可能なパターンに従います。 たとえば、 blue.strawberryFQDN test.internalの 1 つのインスタンスを置き換える場合、 blue.strawberrytest.internalの他のすべてのインスタンスも置き換えます。

注意

これでは、 $redact集計パイプラインは使用されません。 これは、より幅広い機能セットを持つ別の機能です。

4
5

エントリ ステータスにCollecting Logs...が表示され、ログ収集が続行されるとそのステータスが自動的に更新されます。

  • MongoDB Ops Managerによるログファイルの取得に失敗した場合は、失敗したログファイルを再度取得するには Retry をクリックします。

  • 障害が発生した場合でも、アーカイブをダウンロードできます。 リクエストされたログファイルの一部が欠落します。

6

[ Download iconをクリックします。

Log Request Historyページに表示されているアーカイブのサイズは非圧縮サイズです。 アーカイブは抽出されると、ターゲット ホスト上のその量のディスク領域を消費します。

このダウンロードは再開のみが可能で、再開はできません。 ダウンロードが失敗した場合は、ログを再度ダウンロードする必要があります。

アーカイブの名前はmongodb-logfiles_<instance_or_process>_<ISO8601_Format_Date>.tar.gzです。

抽出されたファイルは、次のディレクトリ構造を使用します。

<host>
automation_agent
automation-agent-verbose.log
automation-agent-verbose.log.<ISO8601_Format_Date>
backup_agent
backup-agent-verbose.log
backup-agent-verbose.log.<ISO8601_Format_Date>
monitoring_agent
monitoring-agent-verbose.log
monitoring-agent-verbose.log.<ISO8601_Format_Date>
<replica_set> // Sharded Cluster Only
<port>
ftdc
metrics.<ISO8601_Format_Date>
metrics.interim
mongodb
mongodb.log
mongodb.log.<ISO8601_Format_Date>
<port> // Replica Set or Standalone
ftdc
metrics.<ISO8601_Format_Date>
metrics.interim
mongodb
mongodb.log
mongodb.log.<ISO8601_Format_Date>

注意

tarMicrosoft Windows ホスト上で アーカイブを抽出する場合は、 PAX 拡張ヘッダー をサポートするアーカイブ抽出ユーティリティを使用します。 。一部の Windows アーカイブ ユーティリティでは、 tarの PX 拡張ヘッダーに問題があります。

収集されたログは期限切れとなり、7 日後に削除されます。 特定のログファイルの有効期間を延長するには、 Log Request Historyページでそのアーカイブのextendリンクをクリックします。

MongoDB Ops Managerは、 MongoDB Agentが管理するクラスターのログをローテーションおよび圧縮できます。 MongoDB Agent が クラスターのみを監視する場合、そのクラスターのログは無視されます。

重要

MongoDB Enterprise バージョン 5.0 以降、および MongoDB Agent 11.0.13.7055 以降を実行している場合は、次の操作を実行できます。

  • サーバー ログと監査ログのローテーションに個別のルールを設定します。

  • MongoDB Ops Managerを使用して 監査ログ を圧縮および削除します。 セキュリティ上の理由から、 MongoDB Ops Managerの外部で監査ログの圧縮と削除を管理することをお勧めします。

MongoDB EnterpriseまたはMongoDB Agentの以前のバージョンを実行している場合、 MongoDB Ops Managerは :

  • System Log Rotation設定を使用して、サーバーログと監査ログの両方をローテーションします。

  • 監査ログを圧縮または削除しません。 圧縮と削除を構成すると、 MongoDB Ops Managerはこれらの設定をサーバー ログにのみ適用します。

MongoDB Community ユーザーは、サーバー ログのみをローテーション、圧縮、削除できます。

注意

この機能を使用する場合は、 logrotateなどのプラットフォームベースのログ ローテーション サービスを無効にします。 プロセス構成ファイルからreopenrenameフラグを削除します。 MongoDB Agent がクラスターのみを監視する場合、そのクラスターはプラットフォームベースのサービスを使用する可能性があります。

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

  2. Moreドロップダウンリストで、[ MongoDB Log Settings ] をクリックします。

2

System Log RotationONに切り替えて、サーバーログをローテーションします。

MongoDB Enterprise バージョン 5.0 以降と MongoDB Agent 11.0.13.7055 以降を実行している MongoDB Enterprise ユーザーは、 Audit Log RotationONに切り替えて、監査ログをローテーションし、 監査ログ ローテーションを個別に構成することもできます。

MongoDB Enterprise または MongoDB Agent の以前のバージョンを実行している場合は、 System Log RotationONに設定すると、監査ログもローテーションされます。

MongoDB Ops Managerでログをローテーションしない場合は、ログ ローテーションを OFF に設定します。 ログ ローテーションはデフォルトでOFFです。

ログ ローテーションを有効にすると、 MongoDB Ops Managerに追加のログ ローテーション設定が表示されます。

3

MongoDB Ops Managerは、次の設定に従ってMongoDBホストのログをローテーションします。

フィールド
必要性
アクション
default
Size Threshold (MB)
必須
MongoDB Ops Manager は、この最大ログファイル サイズを超えるログファイルをローテーションします。
1000
Time Threshold (Hours)
必須
MongoDB Ops Manager は、この期間を超えるログをローテーションします。
24
Max Uncompressed Files
任意

ログファイルは、このファイル数を超えるまで非圧縮のままになります。 MongoDB Ops Managerは、最も古いログファイルを最初に圧縮します。

この設定を空のままにすると、MongoDB Ops Manager はデフォルトの5を使用します。

5
Max Percent of Disk
任意

ログファイルは、MongoDB ホストのログボリューム上のディスク領域のこのパーセンテージまでを消費する可能性があります。 MongoDB Ops Managerは、このディスクしきい値を超えると、最も古いログファイルを削除します。

この設定を空のままにすると、MongoDB Ops Manager はデフォルトの2%を使用します。

2%
Total Number of Files
任意
ログファイルの合計数。 数値が指定されていない場合、ログファイルの合計数はデフォルトで0になり、他のRotate Logs設定によって決まります。
0

それが完了したら、 Saveをクリックして変更を確認します。

4

そうでない場合は、 Cancelをクリックすると、追加の変更を行うことができます。

MongoDB Ops Managerは、すべてのMongoDBエージェントのログを収集します。

この機能にアクセスするには、次のいずれかのロールによって付与される特権が必要です。

1

[] ページには、 Viewドロップダウンリストで選択されたエージェントのタイプのログが表示されます。 ページでは、 で選択されたフィルターに従って、ログがフィルター処理されます 。

2

別のタイプのエージェントのログを表示するには、 Viewドロップダウン リストを使用します。

特定のホストまたは MongoDB プロセスのログを表示するには、化のアイコンをクリックして選択を行います。

フィルターをクリアするには、ツールアイコンをクリックし、 Remove Filtersをクリックします。

選択したログをダウンロードするには、鍵アイコンをクリックし、 Download as CSV Fileをクリックします。

注意

特定のエージェントのログを表示するには、 AgentsタブのAll Agentsリストをクリックし、次にエージェントのview logsをクリックします。

オートメーションを使用してクラスターを管理する場合は、この手順に従ってエージェント ログ ファイルのローテーションを構成します。

注意

オートメーションを有効にしていない場合に、エージェント構成ファイルでログ設定を手動で構成する方法については、次のドキュメントを参照してください。

1
2
3
4

モニタリングエージェントまたはバックアップエージェントのログ設定を編集するには、 pencilアイコンをクリックします。

名前
タイプ
説明
Linux Log File Path
string

条件付き: Linux ホストでログを記録します。 エージェントが Linux ホスト上でログを書込むパス。

推奨される値は次のとおりです。

/var/log/mongodb-mms-automation/monitoring-agent.log
Windows Log File Path
string

条件付き: Windows ホスト上のログ。 エージェントが Windows ホスト上でログを書込むパス。

推奨される値は次のとおりです。

%SystemDrive%\MMSAutomation\log\mongodb-mms-automation\monitoring-agent.log
Rotate Logs
切り替え
ログをローテーションするかどうかを選択するトグル。
Size Threshold (MB)
integer
ログが自動的にローテーションされるサイズ。 デフォルト値は1000です。
Time Threshold (Hours)
integer
ログが自動的にローテーションされる期間。 デフォルト値は24です。
Max Uncompressed Files
integer
任意。 現在のログファイルを含む、非圧縮にされるログファイルの最大数。 推奨値は5です。
Max Percent of Disk
integer
任意。 ログが消費する MongoDB ホスト上のディスク領域の最大パーセンテージ。 推奨値は2%です。
Total Number of Files
integer
任意。 ログファイルの合計数。 数値が指定されていない場合、ログファイルの合計数はデフォルトで0になり、他のRotate Logs設定によって決まります。

完了したら、[ Save ] をクリックします。

5
6

そうでない場合は、 Cancelをクリックすると、追加の変更を行うことができます。

MongoDB Ops Managerを使用して、さまざまなログファイルを確認できます。

MongoDB Ops Managerログの一部の 保持期間は変更できます 。会社では、法的要件のためにログ データを保持する必要がある場合があります。 ログ保持ポリシーを変更して、これらの要件に準拠できます。

戻る

Slack との統合