M10+ Atlas クラスターは、システム ログをAWS S3バケットにエクスポートするように構成できます。
この統合により、次のことが可能になります。
S3バケットにエクスポートするMongoDBログファイルを指定します。Atlas は次のログタイプのエクスポートをサポートしています。
mongodmongosmongod-auditmongos-audit
最大 10 エクスポート パスを設定すると、複数のAWS S3 バケットにログを同時にエクスポートできます。
S3 MRAP ARN との統合を構成して、マルチリージョン アクセス ポイント（MRAP）にログを送信します。現在、Atlas 管理APIを使用してのみ CRAP ARN を構成できます。CRAP エイリアスはサポートされていません。
重要
ログには機密情報が含まれる場合があります（ PII など）。AWS S3バケット内のログのストレージと処理はユーザーがする必要があります。ログをエクスポートする前に Atlas が特定の情報をリダクションするには、MongoDBサポートにお問い合わせください。
必要なアクセス権
AWS S3バケットにログをエクスポートするには、Atlas に対する Project Owner または Organization Owner アクセス権が必要です。
Considerations
各 Atlas ホストは通常、1 日あたり 1 GBのログを生成します。ログをエクスポートするには、 データ転送コストが発生します。具体的なデータ転送コストは、 宛先、リージョン、クラウドプロバイダーによって異なります。
ネットワークの問題または再試行により、 AWS S3バケットに重複するログエントリが発生する可能性があります。
AWS IAM ロールと S3バケットは同じAWSアカウントに属している必要があります。
前提条件
次のものが必要です。
sts:AssumeRole を持つAWS IAM ロール。これにより、Atlas はAWSリソースにアクセスでき、最大セッション期間は 12時間に設定されます。
既存のAWS S3バケット。
MongoDB 7.0 以降を実行中
M10+Atlas クラスター。
手順
AWS S3 バケットにログをエクスポートするには、次の手順を実行します。
Atlas で、Project Settings ページに移動します。
まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーで、 アイコンを Project Overview の横にあるをクリックします。
[ Project Settings ]ページが表示されます。
Atlas にAWSアカウントへのアクセスを許可します。
Authorize an AWS IAM Role ドロップダウンから ARN を選択します。ARN を追加するには、「 統合AWSアクセスのセットアップ 」を参照してください。
[Next] をクリックします。
Atlas をAWS S3 バケットに接続します。
Bucket Nameフィールドに、 AWS アカウントに表示される S3 バケットの名前を入力します。
Prefixフィールドにディレクトリ名を入力して、S3バケットの内容を整理します。例、
logs/と入力すると、エクスポートされたログを保存するための S3バケットにlogsディレクトリが作成されます。[Log Type で、エクスポートするログのタイプを選択します。
MongoDB Logs 各
mongodサーバープロセスによって書き込まれた診断ログ。サーバーのスタートアップとシャットダウン、構成、接続、低速クエリ、レプリケーション、シャーディングアクティビティ、およびその他の運用イベントがレコード。MongoDB Audit Logs 認証試行、承認チェック、ロールの変更、その他のセキュリティ関連操作などのシステムイベントアクションを追跡する
mongodによって発行される監査ログ。これらのログは、メインのMongoDBログとは別です。MongoDB Router Logs シャーディングされたクラスター内の各
mongosルーター プロセスによって書き込まれた診断ログ。シャードへのクエリのルーティング、シャーディングメタデータの更新、一般的なプロセス診断など、ルーター固有の動作をキャプチャします。MongoDB Router Audit Logs
mongosルーター プロセスによって発行される監査ログ。同じ種類の監査されたシステム イベントを記録しますが、シャーディングされた配置では ルーターの観点から見たものを記録します。
詳しくは、MongoDBログの表示とダウンロードを参照してください。
（任意）S3バケット内のログを暗号化する場合は、KMS KeyフィールドにAWS Key Management Service（KMS）キー ARN を入力します。詳細については、 AWS KMS によるカスタマー キーの管理 を参照してください。
[Next] をクリックします。
ログのエクスポート形式
Atlas は、構造化されたメタデータを含む JSON オブジェクトとしてログをS3バケットにエクスポートします。各ログエントリには、元の MongoDB ログ メッセージとともに、ソースクラスター、ホストする、ログ タイプを識別する追加のコンテキスト フィールドが含まれます。
エクスポートされたログは、レガシーの Push-Based Log Export (PBLE) システムとは異なる構造化された形式を使用します。この新しい形式により、ログインフラストラクチャ内でのログのルーティング、フィルター、分析のためのメタデータが強化されます。
ログエントリ構造
エクスポートされた各ログエントリは、次のトップレベルフィールドを持つ JSON オブジェクトです。
フィールド | 説明 |
|---|---|
| サービスの種類を識別する string。デフォルトは |
| JSON エンコードされた string としての元の MongoDB ログ メッセージ。これには、MongoDB からの構造化されたログ データが含まれています。これには、 |
| ログエントリを生成したMongoDBホストの完全修飾ドメイン名（例： |
| クラスターを含む Atlas プロジェクト ID（グループ ID とも呼ばれる）。 |
| Atlas が使用する内部クラスター識別子。 |
| Atlas UI に表示されるユーザー定義のクラスター名。 |
| エクスポートされるログの種類。指定できる値: |
| ログ エントリが生成された時の ISO 8601 タイムスタンプ。 |
ログエントリの例
次の例は、一般的なエクスポートされたログエントリを示しています。
{ "service.name": "mongodb", "log": "{\"t\":{\"$date\":\"2026-05-19T21:58:00.309+00:00\"},\"s\":\"I\",\"c\":\"NETWORK\",\"id\":6723804,\"ctx\":\"conn928\",\"msg\":\"Ingress TLS handshake complete\",\"attr\":{\"durationMillis\":26}}", "host.name": "atlas-cluster-shard-00-00.nzmz4k.mongodb.net", "mongodb.group.id": "682f18ee72a6a02c8182cab3", "mongodb.cluster.name": "atlas-cluster", "mongodb.customer.cluster.name": "Cluster0", "mongodb.log.type": "mongod", "timestamp": "2026-05-19T21:58:00.309Z" }
logフィールドには元の MongoDB ログ メッセージが含まれています。解析すると、標準のMongoDB ログ メッセージ構造が表示されます。
{ "t": {"$date": "2026-05-19T21:58:00.309+00:00"}, "s": "I", "c": "NETWORK", "id": 6723804, "ctx": "conn928", "msg": "Ingress TLS handshake complete", "attr": { "durationMillis": 26 } }
注意
attr オブジェクト内のフィールドの順序は、ログエントリによって異なり、レガシー PBLE 形式とは異なる場合があります。ログ解析ツールは、attr 内のフィールドの順序に依存する必要はありません。
プッシュベースのログ エクスポート（PBLE）からの変更
外部ログシンク形式には、レガシーの Push-Based Log Export (PBLE) システムからの変更が多く含まれています。
変更 | 説明 |
|---|---|
ネストされたログコンテンツ | MongoDB ログ メッセージは、トップ レベルではなく、JSON エンコードされた string として |
追加のメタデータ フィールド | 新しいトップレベルフィールドにより、ログソースに関するコンテキストが提供されます: |
ログエントリの順序 | S3 に表示されるログエントリの順序は PBLE と異なる場合があります。時間分析のためにログエントリの順序に依存しないでください。正確な時間ベースのプロセシングには、 |
属性フィールドの順序付け |
|
解析の検討事項
エクスポートされたログをプロセシングする場合：
2 段階の JSON パース: まず外部 JSON オブジェクトをパースしてメタデータ フィールドにアクセスし、次に
logフィールドを JSON としてパースして MongoDB ログ メッセージにアクセスします。フィールドの抽出：特定のMongoDBログフィールド（
msg、c、attrなど）を抽出するには、まずlogフィールドを解析します。タイムスタンプ処理: トップレベルの
timestampフィールドは ISO 8601 形式を使用しますが、logコンテンツ内のt.$dateフィールドは MongoDB の拡張 JSON 形式を使用する場合があります。どちらも同じ時間を表します。クラスター識別:
mongodb.customer.cluster.nameを使用して、Atlas UI に表示されるクラスター名でログをフィルターします。mongodb.cluster.nameフィールドには内部識別子が含まれています。
ログ エクスポート失敗のアラート
Atlas が外部シンクへのログのエクスポートを停止したときに通知されるようにするには、 プロジェクト レベルのアラートを構成します。
Atlas で、Project Alerts ページに移動します。
まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Atlas UIの右上隅にある Alerts アイコンをクリックします。
Project ヘッダーの下の Alerts をクリックします。
プロジェクト アラートページが表示されます。
アラートの受信者、通知方法、頻度を選択します。
Add Notification Method セクションで、ロールのリストから [] を選択します。
Add Notifier ドロップダウン メニューで、次の表に記載されているオプションから選択します。
通知オプション説明Atlas プロジェクト
プロジェクト内の特定のロールを持つユーザーに、メールまたはテキスト メッセージでアラートを送信します。
デフォルトでは、Atlas プロジェクトがアラート受信者に設定されています。アラート送信先のロールと配信方法は構成できますが、2 番目の Atlas プロジェクトを受信者に追加することはできません。
注意
Project Ownerロールが人間のプロジェクト ノードに割り当てられると、Atlas はそのノードの構成済みのメールアドレスまたは SMS ターゲットにアラートを配送します。Project Ownerロールがプログラムで割り当てられる場合は、明示的な通知ターゲット（メール アドレス、PagerDuty、Slack、Webhook など）を構成して、アラートを受信するようにしてください。プログラムによる API キーとサービス アカウントは、デフォルトではアラート通知を受信しません。Atlas プロジェクトは、現在受信者リストに含まれていない場合にのみ、Add リストのオプションとして使用できます。
[Select Role(s)] チェックボックスからアラートを受信するプロジェクトを選択するか、アラートを受信するプロジェクト内のすべてのユーザーを対象に [All Roles] を選択します。
Atlas プロジェクトのユーザー アカウント ページで各ユーザーに設定された携帯電話番号にこれらのアラートを送信するには、[SMS] を選択します。
Atlas プロジェクト ユーザーのアカウント ページで各ユーザーに設定されたメールアドレスにこれらのアラートを送信するには、[Email] を選択します。デフォルトでは Email がオンになっています。
Atlas 組織
組織内の特定のロールを持つユーザーに、メールまたはテキスト メッセージでアラートを送信します。
[Select Role(s)] チェックボックスからアラートを受信する組織ロールを選択するか、アラートを受信する組織内のすべてのユーザーを対象に [All Roles] を選択します。
アカウント ページで各 Atlas 組織ユーザーに設定された携帯電話番号にこれらのアラートを送信するには、[SMS] を選択します。
アカウント ページで各 Atlas 組織ユーザーに設定されたメールアドレスにこれらのアラートを送信するには、[Email] を選択します。デフォルトでは Email がオンになっています。
Atlas user
指定された Atlas user にメールまたはテキスト メッセージでアラートを送信します。
Atlas user のアカウント ページで設定された携帯電話番号にこれらのアラートを送信するには、[SMS] を選択します。
Atlas user のアカウント ページで設定されたメールアドレスにこれらのアラートを送信するには、[Email] を選択します。デフォルトでは Email がオンになっています。
メールアドレス
メールアドレスにアラートを送信します。
SMS
携帯電話番号にアラートを送信します。Atlas はすべての句読点と文字を削除し、数字のみを使用します。米国またはカナダ以外のユーザーの場合は、Atlas が米国に拠点を置く
011Twilio をテキスト メッセージの送信に使用しているため、 と 国コード を含めてください。米国以外の国の電話番号には、代替として Google Voice の電話番号を使用します。たとえば、ニューヨークの携帯電話番号にアラートを送信するには、電話番号の前に
01164と入力します。Slack
Slackチャンネルにアラートを送信します。チャンネル名、およびAPIトークンまたは Bot トークンのいずれかを入力します。APIトークンを作成するには、https://api.slack.com/webページをSlack。Slackの Bot ユーザーの詳細については、https://api.slack.com/bot-users を参照してください。
API または統合キーが必要な通知を作成してから次の操作を行うと、キーは伏字で表示されます。
Atlas UI を通じてアラートを表示または編集します。
Atlas Administration API から通知するアラートを問い合わせます。
Atlas は、認証情報の最後の 4 文字以外をすべてリダクションします。リダクション公式は、PagerDuty、Slack、DataDog など、すべての通知タイプに適用されます。この公式は安定しており、オートメーションで安全に使用できます。不可能な API 変更がある場合は新しい API バージョンが必要であり、前のバージョンは引き続き使用できるようにする必要があります。
PagerDuty
アラートを PagerDuty アカウントに送信します。PagerDuty サービス キーのみを入力します。エスカレーション ルールとアラートの割り当てを PagerDuty で直接定義します。
ユーザーは PagerDuty ダッシュボードからのみ PagerDuty アラートを確認できます。
すべての新しい PagerDuty キーは Events API v2 を使用します。
Events API v1 キーをお持ちの場合は、そのキーを Atlas で引き続き使用できます。
API または統合キーが必要な通知を作成してから次の操作を行うと、キーは伏字で表示されます。
Atlas UI を通じてアラートを表示または編集します。
Atlas Administration API から通知するアラートを問い合わせます。
Atlas は、認証情報の最後の 4 文字以外をすべてリダクションします。リダクション公式は、PagerDuty、Slack、DataDog など、すべての通知タイプに適用されます。この公式は安定しており、オートメーションで安全に使用できます。不可能な API 変更がある場合は新しい API バージョンが必要であり、前のバージョンは引き続き使用できるようにする必要があります。
Datadog
DataDog アカウントに DataDogイベントとしてアラートを送信します。
Atlas はアラートが最初に開かれたときに、「エラー」イベントとしてアラートを送信します。その後の更新は「情報」イベントとして送信されます。アラートが閉じられたときには、「成功」イベントを送信します。
API Key の下に DataDog API キーを入力し、[Validate Datadog API Key] をクリックします。
API リージョンを入力します。
Atlas は、Atlas UI で次の Datadog リージョンをサポートしています。
US1US3US5EU1AP1
Datadog はデフォルトで
US1を使用します。DataDog のリージョンの詳細については、DataDog サイト を参照してください。
API または統合キーが必要な通知を作成してから次の操作を行うと、キーは伏字で表示されます。
Atlas UI を通じてアラートを表示または編集します。
Atlas Administration API から通知するアラートを問い合わせます。
Atlas は、認証情報の最後の 4 文字以外をすべてリダクションします。リダクション公式は、PagerDuty、Slack、DataDog など、すべての通知タイプに適用されます。この公式は安定しており、オートメーションで安全に使用できます。不可能な API 変更がある場合は新しい API バージョンが必要であり、前のバージョンは引き続き使用できるようにする必要があります。
（任意）データベースメトリクスの追跡を有効にするには、Send Database Metrics を On に切り替えます。
（任意）レイテンシ メトリクスの追跡を有効にするには、Send Collection Latency Metrics を On に切り替えます。
（任意）クエリシェイプメトリクスの追跡を有効にするには、Send Query Shape Metrics を On に切り替えます。
[Save] をクリックします。
VictorOps
VictorOps アカウントにアラートを送信します。
VictorOps から英数字の APIキー を入力して、アラート用の VictorOps エンドポイントを統合します。API キーにダッシュを追加して、形式
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxと一致させます。たとえば、489f7he7-790b-9896-a8cf-j4757def1161のようにします。任意のルーティングキー を入力して、アラートを特定の VictorOps グループにルーティングします。VictorOps 構成をテストするには、[Post Test Alert] をクリックします。VictorOps 内でエスカレーション ルールとルーティング ルールを直接定義します。このオプションは、確認が必要なアラートにのみ使用できます。Atlas では、このサードパーティー モニタリング サービスから情報アラートを受け取ることができます。ただし、これらのアラートは外部サービス内で解決する必要があります。VictorOps ダッシュボードから VictorOps アラートの受信を確認します。
API または統合キーが必要な通知を作成してから次の操作を行うと、キーは伏字で表示されます。
Atlas UI を通じてアラートを表示または編集します。
Atlas Administration API から通知するアラートを問い合わせます。
Atlas は、認証情報の最後の 4 文字以外をすべてリダクションします。リダクション公式は、PagerDuty、Slack、DataDog など、すべての通知タイプに適用されます。この公式は安定しており、オートメーションで安全に使用できます。不可能な API 変更がある場合は新しい API バージョンが必要であり、前のバージョンは引き続き使用できるようにする必要があります。
Opsgenie
アラートを Opsgenie アカウントに送信します。Opsgenie API キーのみを入力します。エスカレーション ルールとアラートの割り当てを Opsgenie で直接定義します。
このオプションは、確認が必要なアラートにのみ使用できます。Atlas では、このサードパーティー モニタリング サービスから情報アラートを受け取ることができます。ただし、これらのアラートは外部サービス内で解決する必要があります。Opsgenie ダッシュボードから Opsgenie アラートを確認します。
API または統合キーが必要な通知を作成してから次の操作を行うと、キーは伏字で表示されます。
Atlas UI を通じてアラートを表示または編集します。
Atlas Administration API から通知するアラートを問い合わせます。
Atlas は、認証情報の最後の 4 文字以外をすべてリダクションします。リダクション公式は、PagerDuty、Slack、DataDog など、すべての通知タイプに適用されます。この公式は安定しており、オートメーションで安全に使用できます。不可能な API 変更がある場合は新しい API バージョンが必要であり、前のバージョンは引き続き使用できるようにする必要があります。
Microsoft Teams
Microsoft Teams チャネルに アダプティブ カード としてアラートを送信します。
Microsoft Teams チャネルにアラート通知を送信するには、Microsoft Teamss 受信 Webhook を作成する必要があります。Webhook の作成後は、自動生成 URL を使用して、Atlas で Microsoft Teams 統合を構成できます。
統合を設定するには、「Microsoft Teams との統合」を参照してください。
Microsoft Teams の通知アラートを表示または編集すると、URL は部分的に伏せ字で表示されます。
Webhook
プログラムによる処理のためにエンドポイントに HTTP POST リクエストを送信します。リクエスト ボディには、Atlas Administration API アラート リソースと同じ形式を使用する JSON ドキュメントが含まれています。
Atlas には、アラート状態を示す
X-MMS-Eventと、リクエストの正当性を確認するX-MMS-Signature（シークレットが構成されている場合）を含め、各ウェブフック リクエストに HTTP ヘッダーが含まれます。Webhook ペイロード、ヘッダー、認証、および制限について詳細には、Webhook との統合 を参照してください。
このオプションは、統合ページで Webhook 設定を構成した場合にのみ使用できます。
Webhook 通知のアラートを表示または編集すると、URL とシークレットが伏字化されて表示されます。
URL: Atlas はプロトコル、ホスト、ポートを維持し、パスを
********に置き換えます。例えば、http://webhook.mycompany.com:8080/api/alerts/secretはhttp://webhook.mycompany.com:8080/********になります。シークレット: シークレットが 10 文字より長い場合、Atlas は最後の 4 文字以外を伏字で表示します。シークレットが 10 文字以下の場合、Atlas はシークレットを完全に伏字で表示します。
Atlas はシークレットを使用してリクエスト検証用の
X-MMS-Signatureヘッダーを生成し、認証ヘッダーとして送信しません。Webhook URL フィールドに、Webhook ベースのアラートのターゲットURLを指定します。
（任意）シークレットを使用して Webhook 統合をセットアップする場合、[Webhook Secret] フィールドで、Atlas がリクエストの検証用の
X-MMS-Signatureヘッダーを生成するために使用するシークレットを指定します。（任意）Webhookリクエストのヘッダーとボディのコンテンツをカスタマイズするには、フリーマーク テンプレートで Webhook Headers Template フィールドと Webhook Body Template フィールドを使用します。構成されたテンプレートを使用してアラートを表示または編集すると、テンプレートは
******で編集され、上書きできます。
Recurrence セクションでは、ログエクスポートの失敗条件が
60分以上続く場合にアラートをトリガーし、問題が解決されるまで10080分（7 日）ごとに再送信するように設定します。こうすることで、ログのエクスポート失敗が長時間にわたって失敗した場合に通知が行われ、一時的な問題の過剰な通知を回避できます。
Save[ をクリックします。
アラートの設定の詳細については、アラートの構成を参照してください。