MongoDB 監視
設定不要で、MongoDBのドキュメント操作、レプリカセットの状態、接続状況、およびストレージのメトリクスをリアルタイムで監視できます。
なぜ監視するのか MongoDB?
MongoDBは、柔軟なスキーマと水平スケーラビリティにより、最新のアプリケーションを支える主要なNoSQLドキュメントデータベースです。クエリのパフォーマンスを追跡し、レプリケーションの遅延を検知し、接続プールを管理し、ストレージ容量の枯渇を防ぐためには、MongoDBの監視が不可欠です。XitoringのMongoDB統合機能により、データベースクラスタの状態を詳細に把握することができます。
MongoDB 監視を、 解説
MongoDB 監視は、レプリケーションラグ、oplog ウィンドウの崩壊、WiredTiger キャッシュ圧迫、暴走クエリを、レプリカ障害、セカンダリへのフォールバック ストーム、ユーザーから見える減速を引き起こす前に検知します。MEAN/MERN スタック、シャーディングされたクラスター、あらゆるレプリカセット構成において、ノードごとの可視性こそが、優雅なフェイルオーバーと数時間続くインシデントとを分ける鍵です。Xitoring はあなたの MongoDB を自動検出し、clusterMonitor ロールでネイティブの server-status コマンドにクエリし、Slack、PagerDuty、Telegram、その他既存のオンコール体制にアラートを送信します。
私たちが 監視するもの
ドキュメント操作
1秒あたりのinsert、update、delete、queryのレート。
接続
MongoDBインスタンスへの現在のアクティブ、利用可能、総接続数。
レプリケーションラグ
レプリカセットのプライマリとセカンダリメンバー間の時間遅延。
Oplogウィンドウ
レプリケーション用にoplog内に保持される操作の期間。
WiredTigerキャッシュ
現在キャッシュ内のバイト数、ダーティバイト、キャッシュヒット率。
ページフォルト
データがメモリ内にないことを示すページフォルト数。
カーソル
タイムアウト無しのものを含む開いているカーソル数。
ネットワークI/O
MongoDBインスタンスへの送受信バイトとリクエスト数。
ロックキュー
読み取りまたは書き込みロックの取得を待機している操作数。
インデックスカウンタ
インデックスアクセス、ヒット、ミス。インデックスの有効性を示します。
ストレージサイズ
総データサイズ、インデックスサイズ、ディスクの空き容量。
アサーション
通常、警告、ロールオーバーを含むアサートメッセージ数。
設定可能 アラートのトリガー
ダッシュボードでカスタムトリガーを設定し、MongoDBのメトリクスが定義した閾値を超えた瞬間に通知を受け取れるようにします。
レプリケーションラグ
重要なセカンダリメンバーがプライマリから遅延したときに発動。フェイルオーバー時のデータ不整合リスクを示します。
接続数
警告アクティブ接続が最大値に近づいたときに発動。接続プール枯渇の可能性を示します。
WiredTigerキャッシュ使用量
警告キャッシュ使用率が閾値を超えたときにアラート。ディスクI/Oの増加とクエリ低速化を引き起こします。
ページフォルト
重要なページフォルトレートが急増したときに発動。作業セットが利用可能メモリを超えていることを示します。
ロックキュー長
警告操作がロック取得のためにキューに入ったときに発動。競合とパフォーマンス低下の可能性を示します。
ストレージ容量
重要なディスク容量使用量が閾値を超えたときにアラート。データベース書き込みがブロックされるリスクを示します。
の重要性： MongoDB監視
MongoDBは数百万のドキュメントを扱うミッションクリティカルなアプリケーションを支えます。監視がないと、レプリケーションのずれ、接続枯渇、キャッシュ圧迫がパフォーマンスを静かに劣化させ、データ損失につながります。
- フェイルオーバーがデータ不整合を引き起こす前にレプリケーションラグを検出
- パフォーマンスボトルネックを特定するためにドキュメント操作レートを監視
- メモリ割り当てを最適化するためにWiredTigerキャッシュ効率を追跡
- アプリケーションクライアントからの接続プール枯渇を特定
- 中断のないデータベース運用のためのストレージ容量を確保
なぜ選ぶべきか： Xitoring
XitoringはゼロコンフィグでエンタープライズグレードのMongoDB監視を提供します。軽量エージェントがMongoDBインスタンスを自動検出し、60秒以内にメトリクス収集を開始、既存の通知チャネルと統合します。
- ワンコマンドインストール — 複雑なYAMLや設定ファイルは不要
- 低遅延チェックのための15以上のグローバル監視ノード
- サーバー、データベース、稼働率を統合したダッシュボード
- Slack、PagerDuty、Telegramなどによる柔軟なアラート
- キャパシティプランニングと監査のための履歴データ保持
よくある MongoDB 監視 シナリオ
MongoDBが今日一般的に実行されている場所 — そして誰も監視していない場合に何が問題になる可能性があるか。
バックアップコピーを持つセルフホスト型データベース
本番環境のセットアップでは、データベースの複数のコピーを実行しているため、障害でアプリがダウンすることはありません。1つのコピーが他のコピーに静かに遅れをとると、セーフティネットは見かけよりも弱くなります。私たちはその兆候を早期に捉え、フェイルオーバーが本来の役割を果たすようにします。つまり、ユーザーには見えないようにします。
複数のサーバーに分割されたデータベース
データが1つのサーバーには大きすぎる場合、それは多くのサーバーに分割されます — しかし、一部のサーバーが他のサーバーよりも多くの作業を行うことになると、アプリ全体が遅くなります。私たちはその不均衡を表面化させ、1つの過負荷サーバーが顧客に影響を与える問題になる前に、チームが負荷を再バランスできるようにします。
Node.jsアプリの背後にあるデータベース
ほとんどのNode.jsアプリはMongoDBに大きな負荷をかけ、データベース接続のプールを再利用して高速を維持します。アプリが接続をリークしたり、非効率なクエリを実行したりすると、すべてのリクエストが遅くなります。私たちはその原因を迅速に表面化させ、適切なチームがそれを修正できるようにします。
MongoDB の 前提条件
これらが揃っていることを確認してください — 揃っていれば、ほとんどの導入は 60 秒で完了します。
- MongoDB 4.x 以上がサーバー上で稼働していること
- clusterMonitor ロール（またはレガシーバージョンでは readAnyDatabase）を持つユーザー
- Xitogent から MongoDB インスタンスへのネットワーク到達性
はじめに 議事録
Xitogent をサーバーにインストール
まだの場合は、軽量な Xitogent 監視エージェントをサーバーにインストールしてください。
curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEYMongoDB に監視ユーザーを作成
Xitogent が serverStatus、レプリケーション状態、ストレージメトリクスを読み取れるように、`clusterMonitor` ロールを持つ専用 MongoDB ユーザーを作成します:
use admin
db.createUser({
user: "xitogent",
pwd: "xitogent!",
roles: [{ role: "clusterMonitor", db: "admin" }]
})MongoDB 連携を有効化
Xitoring ダッシュボードまたは CLI から MongoDB 連携を有効化してください。Xitogent が MongoDB インスタンスを自動検出します。
sudo xitogent integrateアラートしきい値を設定（オプション）
レプリケーション遅延、接続数、ストレージ使用量などのメトリクスにカスタムしきい値を設定し、注意が必要なときに通知を受け取れるようにします。
動作確認
サーバー上でこのコマンドを実行して、Xitogent が連携を認識していることを確認してください。約 30 秒以内に新しいメトリクスがダッシュボードに流れ始めます。
sudo xitogent status代替ツールを 検討中ですか？
MongoDB 監視の代替ツールと比べて Xitoring がどう優れているかをご覧ください — 定額料金、より深い統合、そしてスタック全体をカバーする 1 つのエージェント。
頻繁に 質問をした
MongoDBとの連携には認証が必要ですか？
この統合はMongoDBのパフォーマンスに影響を与えますか？
MongoDB Atlas を監視することはできますか？
シャーディングされたクラスタを監視することはできますか？
MongoDBのどのバージョンがサポートされていますか？
指標はどのくらいの頻度で収集されますか？
mongostat は何に使うのですか？
MongoDB Atlas とセルフホストの監視はどう違いますか？
サポートされている MongoDB バージョンは何ですか？
探検を続けよう
