ウェブサイト及びサーバー監視の プレミアム製品

Server Densityについて

Mongodbの監視方法


アップデート:
当社はMongoDBのPaul DoneとMongoDBの監視方法について議論する公開Hangout on Air を開催しました。当社は、このスライドとビデオを作成しており、本ブログの記事の最下部からご利用いただけます。


当社では、サーバー監視の様々なコンポーネントを稼動させるためにMongoDBを使用しています。これは、基本的なユーザ・プロフィールから 30TB/月を越える時系列データの高スループットの処理まであります。

これは当社が、MongoDBクラスターがどのように稼動しているか、システムのすべての面を監視して、細かに目を光らせていることを意味します。本投稿では、主要な指標とMongoDBの監視方法についての詳細について説明します。

 MongoDB Server Density ダッシュボード

MongoDB監視の主要指標

指標については広大な範囲で様々なポイントがあります。  MongoDB クラスターには常に注意を払うことが必要ですが、重要なのはほんのわずかです。これらが、当社が考える重要なリストにある監視に関する指標です。

Oplog レプリケーションの遅れ

レプリカのセットとしてMongoDBに組み込まれているレプリケーションは、当社の経験ではうまく稼動しています。しかしながら、デフォルトの書き込みは、プライマリのメンバーに受け入れられるだけで、他のセカンダリに非同期に複製されます。 MongoDB はデフォルトで最終的に一貫性があります。. これは、プライマリがフェイルモードの場合には、データが複製されない短い期間が、通常存在することを意味します。これは既知の特性であるため、重要なデータについては、書き込みの不安を調整することができ、データがいくつかのセカンダリに到達してからのみ、戻すことができます。他の書き込みの場合には、セカンダリが遅れるのを知っておく必要があります。なぜならば、これはネットワーク等の問題やハードウェア容量不足を意味しているからです。 MongoDBの書き込みの不安 共有されたクラスタの大量のデータを移動する場合には、レプリカのセカンダリは時には遅れがでます。レプリカがある特定の時間だけ遅れた場合のみアラートが発信され、30分以内に復旧した場合には、アラートが発信されません。

レプリカの状態

通常の運用では、レプリカの一つがプライマリとして、他はセカンダリとして設定されます。これはほとんど変更がなく、もし選択できる場合、, その理由を把握したくなります。 これは通常、セカンダリで発生し、その状態はそれ自体で解決しますが、ハードウェアやネットワークの障害があった可能性があるため、すぐに原因を調査したいと考えます。状態間のフラッピングは、通常の運用条件では起こらずに、例えば、メンテナンスのため、またハードウエア障害などの有効なインシデント発生時において起こります。

###ロック%とディスクI / Oの使用率%
MongoDB2.6については、ロックはデータベースレベルで実行され、MongoDB2.8では進行中のドキュメントレベルでロックされます。書き込みではグローバルデータベースのロックが実行されますが、このような状況が頻繁に起こる場合には、他の操作の問題が(読み込みを含む)キューにバックアップされるのでパフォーマン上の問題が発生します。高い効率的なロック%は、例えば不十分な設定のインデックス、インデックスなし、ディスクのハードウェア障害、不適切なスキーマ設計などデータベース内の他の問題で確認できました。これは、長時間数値が高い時には把握しておくことが重要であることを意味します。なぜならば、サーバの速度が低下し(レプリカの状態に変化を起こし、応答しなくなり)、 oplogが遅れる可能性があるからです。しかしながら、それはあまりに頻繁に引き起こすことになるので、注意する必要があります。例えば、ロックが30分以上75%を超えたままの状態になると、長期の遅延を起こし、レプリカの状態とoplogの遅れのアラートがある場合には、非クリティカルなアラートとして実際に設定することができます。これはディスクのI / Oの使用率%などディスクがどれだけ稼動しているかに関連しています。100%に近づくとディスクが最大容量になっていることを示し、アップグレードする必要があります。SSDにディスクをスピン. If ySSDを既に使用している場合には、RAMを追加で提供したり、データをシャードに分割したりする必要があります。

MongoDB SSD パフォーマンスのベンチマーク

MongoDB監視の重要ではない指標

定期的に記録をチェックすべき他の指標もいくつかあります。重要でないかもしれませんが、うまく取り扱い、調査した場合には、プロダクション上の問題にエスカレートする前に問題を回避するのに役立ちます。

メモリ使用量とページフォルト

メモリはMongoDBへのおそらく最も重要なリソースであるので、常に十分にあることを確認しておくべきです!経験則では、すべてのインデックスがメモリに収まるように十分なRAMを提供し、できればすべてのデータのための十分なメモリを提供することが必要です。常駐メモリが重要な指標となります。 – MongoDBは有益な統計を提供し 、メモリに何をしているかを示します。ページフォールトは、メモリに関連にしています。それはページフォールトはMongoDBが、データを検索するためにメモリよりもディスクに行く必要がある時に発生するからです。 さらなるページフォルトは、メモリ不足であることを示しており、利用可能なRAMを増やすことを検討すべきです。

接続

MongoDBへのすべての接続が、システムの必要なメモリへの負荷になります。これは初期にはUNIXのulimitの設定によって 制限されますが、次第にサーバーのリソース特にメモリーによって制限されます。多数の接続は、高いロック%によりバックアップの要望など他の問題やアプリケーションコードが多くの接続が開きすぎる問題などを示します。

シャードチャンクの分配

MongoDBはすべてのシャードを均等にバランスを保つようにしますが、高いロック% によるmoveChunk操作の遅れなどシステムに制約がある場合には、遅れが出てきます。そのため、定期的にクラスターが均衡を保っているか注視しておくべきです。当社では これを解決する無料のツールをリリースしました。これは、単独で、プログラムまたは Server Densityのプラグインの一部として実行することができます、

MongoDB監視のツール

これで、注視せねばならない点やこれらの監視に関する統計を実際に収集するかについて理解いただけたと思います。

リアルタイムでのMongoDB 監視

MongoDBの中には、多数のツールが含まれています。これらは、すべてライブでMongoDBサーバーに対して実行されており、リアルタイムで統計をレポートします。

  • mongostat - これはopcounts 、ロック% 、メモリ使用量と秒ごとに更新するレプリカセットの状態といった主要な指標を示しています。今何が起こっているのか確認できるので、リアルタイムでのトラブルシューティングに便利です。
  • mongotop - mongostatはグローバルサーバの指標を示しますが、 mongotopは、具体的に、読み取りと書き込みの関係で、コレクションレベルでの指標を調べます。これは、ほとんどの活動がどこで起こっているか示すために役立ちます。
  • rs.status() - これは、コマンドを実行するメンバーの観点から設定されたレプリカの状態を表示します。これは、メンバーの状態とそのoplog遅れを確認するのに便利です。
  • sh.status() - これはシャードクラスターの状態特に特にシャードごとのチャンクの数を示し、均衡がとれているか否かを確認できます。

MongoDB監視、グラフ及びアラート

上記のツールは、リアルタイムでの監視のために有用ですが、時間をかけて統計に注視し、特定の重要または重要ではない指標がしきい値 に達した時に通知を受ける必要があります。これこそがServer Densityのような監視ツールが必要な理由です。当社はこれらの統計を収集し、労力をかけずにアラートやダッシュボードを設定し、時間の経過とともにデータをグラフ化することができます。

MongoDB graphs

もし、皆さんがNagios やMuninのような自社の監視ツールを稼動しているのであれば、 これらのシステム用の様々なプラグインもあります。MongoDBはそれ自体が
MongoDB管理サービスの一つとして無料の監視ツール
 を提供します。これはServer Densityと同様にアラートやグラフで、上記のような統計を収集しますが、すべての他のシステム、可用性やアプリケーションの監視は含まれていません。

Monitor MongoDB スライド

Monitor MongoDB ビデオ