MongoDBエラーログのデコード

MongoDBエラーログのデコードには注意が必要な場合があり、貴重な時間を大量に消費する可能性があります。この記事では、ログメッセージの各部分を分析して、MongoDBエラーログを調べる方法を学習します。

MongoDBログ行の一般的な形式

バージョン3.0以降のログラインパターンは次のとおりです...

<timestamp> <severity> <component> [<context>] <message>

以前のバージョンのMongoDBのログラインパターンには次のもののみが含まれていました：

<timestamp> [<context>] <message>

各タグを見てみましょう。

タイムスタンプ

ログメッセージのタイムスタンプフィールドには、ログメッセージがログファイルに挿入された正確な時刻が格納されます。 MongoDBでサポートされているタイムスタンプには4つのタイプがあります。デフォルトの形式はiso8601-localです。 --timeStampFormatパラメータを使用して変更できます。

重大度

次の表に、考えられるすべての重大度レベルの意味を示します。

コンポーネント

バージョン3.0以降、ログメッセージに「コンポーネント」が含まれるようになり、メッセージの機能分類が提供されます。これにより、特定のコンポーネントを確認することで、検索を簡単に絞り込むことができます。

コンテキスト

エラーメッセージのコンテキスト部分には、通常、スレッドまたは接続IDが含まれています。他の値はinitandlistenすることができます。この部分は角括弧で囲まれています。 MongoDBへの新しい接続のログメッセージは、initandlistenとしてコンテキスト値を持ち、他のすべてのログメッセージの場合、スレッドIDまたは接続IDのいずれかになります。例：

2018-05-29T19:06:29.731+0000 [initandlisten] connection accepted from 127.0.0.1:27017 #1000 (13 connections now open)
2018-05-29T19:06:35.770+0000 [conn1000] end connection 127.0.0.1:27017 (12 connections now open)

メッセージ

実際のログメッセージが含まれています。

ログファイルの場所

サーバー上のデフォルトの場所は次のとおりです：/var/log/mongodb/mongodb.log

この場所にログファイルが存在しない場合は、MongoDB構成ファイルをチェックインできます。 MongoDB構成ファイルは、これら2つの場所のいずれかにあります。

/etc/mongod.conf or /yourMongoDBpath/mongod.conf

設定ファイルを開いたら、その中のlogpathオプションを検索します。 logpathオプションは、すべてのメッセージをログに記録する場所をMongoDBに指示します。

単純なログメッセージの分析

これが典型的なMongoDBエラーメッセージの例です...

2014-11-03T18:28:32.450-0500 I NETWORK [initandlisten] waiting for connections on port 27017

タイムスタンプ：2014-11-03T18：28：32.450-0500
重大度：I
コンポーネント：ネットワーク
コンテキスト：[initandlisten]
メッセージ：ポート27017で接続を待機しています

このエラーの最も重要な部分はメッセージ部分です。ほとんどの場合、このフィールドを確認することでエラーを特定できます。メッセージが明確でない場合は、コンポーネント部分に進むことができます。このメッセージの場合、コンポーネントの値はネットワークです。これは、ログメッセージがネットワークの問題に関連していることを意味します。

エラーを解決できない場合は、このメッセージが情報提供を目的としていることを示すログメッセージの重大度を確認できます。さらに、タイムスタンプやコンテキストなどのログメッセージの他の部分をチェックして、完全な根本原因を見つけることもできます。

一般的なエラーログメッセージのデコード

1. メッセージ：

   2018-05-10T21:19:46.942 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.

   解決策： 認証データベースに管理者ユーザーを作成する

2. メッセージ：

   2018-05-10T21:19:46.942 E COMMAND  [initandlisten] ** ERROR: getMore command failed. Cursor not found

   解決策： カーソルからタイムアウトを削除するか、カーソルのバッチサイズを増やします。

3. メッセージ：

   2018-05-10T21:19:46.942 E INDEX  [initandlisten] ** ERROR:E11000 duplicate key error index: test.collection.$a.b_1 dup key: { : null }

   解決策： 一意キー制約の違反。別のキーでドキュメントを挿入してみてください。

4. メッセージ：

   2018-05-10T21:19:46.942 E NETWORK  [initandlisten] ** ERROR:Timed out connecting to localhost:27017.

   解決策： ドライバーとサーバー間の待ち時間が長すぎるため、ドライバーは諦める可能性があります。接続文字列にconnectionTimeoutオプションを追加することで設定を変更できます。

5. メッセージ：

   2018-05-10T21:19:46.942 E WRITE  [initandlisten] ** ERROR: A write operation resulted in an error. E11000 duplicate key error index: test.people.$_id_ dup key: { : 0 }

   解決策： 競合するドキュメントから_idフィールド値の重複を削除します。

6. メッセージ：

   2018-05-10T21:19:46.942 E NETWORK  [initandlisten] ** ERROR: No connection could be made because the target machine actively refused it 127.0.0.1:27017 at System.Net.Sockets.Socket.EndConnect

   解決策： サーバーがポート27017で実行されていないか、正しいホストとポートでサーバーを再起動してみてください。

ログ管理ツール

MongoDB 3.0は、すべてのデータベースアクティビティについてより良い洞察を提供するために、ロギング機能を更新しました。市場には、MongoDB Ops Manager、ログエントリ、mtoolsなどの多くのログ管理ツールがあります。

結論

ロギングは、適切で適切なデータベース管理のためにレプリケーションやシャーディングと同じくらい重要です。データベース管理を改善するには、ログを簡単にデコードして、例外/エラーをすばやく修正できる必要があります。このチュートリアルを読んだ後、複雑なMongoDBログを分析する際により快適に感じることを願っています。