mongodb 服务器性能监控,MongoDB监控
MongoDB監控?
監控是所有數據庫管理的重要組成部分。牢牢掌握 MongoDB 的報告將使您評估您的數據庫的狀態，并使您的部署不出意外。另外， 一種MongoDB 的常規操作參數允許您在它們惡化為失敗之前進行診斷。
本文概略地介紹了可用的監控實用程序和在MongoDB中可用的統計報告。本文還介紹了監控副本集和分片集群的診斷策略和建議。
注解
MongoDB Management Service (MMS) 是一項托管監控服務，該服務收集和聚合數據以供直觀地了解MongoDB部署的性能和操作。更多信息請參見 MMS documentation 。
監控策略?
有三種方法可用于收集正字運行的 MongoDB 實例的狀態數據：
第一種，有一套隨著MongoDB一起分發的實用程序提供了數據庫活動的實時報告。
第二種， 數據庫命令 返回有關當前數據庫狀態更高保真度的統計信息。
每個策略可以幫助解決不同的問題，在不同的場景下各有其用。并且這些方法是相輔相成的。
MongoDB報表工具?
本節概述了隨MongoDB一起分發的報告方法。本節還提供了每一種方法最適合的那類問題的例子來幫助您選擇合適的方法定位問題。
實用程序?
MongoDB發行版包含了大量快速返回實例性能和活動統計信息的實用程序。通常情況下，這些程序對診斷問題和評估一般操作是最有用。
mongostat?
mongostat 捕捉并返回各種類型(如插入、 查詢、 更新、 刪除等)數據庫操作的計數。這些計數展示了服務器上的負載分布。
使用 mongostat 以了解操作類型的分布，并告知容量規劃。詳細信息請參見 mongostat 手冊 。
mongotop?
mongotop 追蹤并報告MongoDB實例當前的讀取和寫入活動，而且是基于每個集合報告這些統計數據。
使用 mongotop 來檢查數據庫的活動和使用是否符合您的期望。詳細信息請參見 mongotop manual 。
HTTP 控制臺?
3.2 版后已移除:HTTP interface for MongoDB
MongoDB提供了一個在一個簡單的網頁上展示診斷和監控信息的網絡接口。該接口通過``localhost:``訪問， 其中的 比 mongod 的端口大 1000 。
例如，如果一個正在本地運行的 mongod 使用默認的端口 27017，那么在 http://localhost:28017 可以訪問到HTTP控制臺。
命令?
MongoDB包含了許許多多報告數據庫狀態的命令。
這些數據可以比上文討論的實用程序提供更細層次的粒度。當開發自定義警報，或改變您的應用程序在響應您的實例的活動時的行為，請考慮在(您的)腳本和程序中使用其輸出。 db.currentOp 方法是另一種用于確定數據庫實例正在進行的操作的有用工具，。
serverStatus?
serverStatus 命令，或外殼程序中的 db.serverStatus() 返回數據庫狀態的總覽，具體包括磁盤使用狀況、 內存使用狀況、 連接、 日志和可用的索引。此命令迅速返回，并不會影響 MongoDB 性能。
serverStatus 輸出MongoDB實例狀態的總覽。(然而我們)很少直接運行該命令。(因為)在大多數情況下，人們通過監控工具包括 MMS 看到的聚合過的數據才更有意義。盡管如此，所有管理員都應熟悉 serverStatus 提供的數據。
dbStats?
dbStats 命令，或外殼程序中的 db.stats() 返回一份針對存儲使用情況和數據卷的文檔。 dbStats 顯示了存儲的使用量、包含在數據庫中的數據的總量以及對象、集合和索引計數器。
使用此數據來監控特定數據庫的狀態和存儲容量。該輸出(的數據)也可以讓你比較各數據庫的使用情況，并確定數據庫中 document 的平均大小。
collStats?
shell中的 collStats 或者 db.collection.stats() 在集合級別上提供類似 dbStats 的統計數據，包括集合中對象的計數、集合的大小、集合占用的硬盤空間總量以及集合索引的相關信息。
replSetGetStatus?
replSetGetStatus 命令(對應外殼程序中的 rs.status() )返回復制集狀態的總覽。 replSetGetStatus 文檔詳細描述了復制集的狀態和配置和有關復制集成員的統計信息。
參照此數據以確保復制集配置正確，并檢查當前主機和其他副本集成員之間的連接。
第三方工具?
A number of third party monitoring tools have support for MongoDB,
either directly, or through their own plugins.
自托管的監控工具?
以下這些是你必須在自己的服務器上安裝、配置、維護的監控工具。(它們中的)大多數都是開源的。
工具
插件
描述
報告內存使用、btree統計情況、主/從狀態、當前操作、每秒的操作的Python腳本。
None
MongoDB服務器的實時監控工具。每秒以歷時長短排序展示目前的操作。
None
和top類似的工具
Munin
Retrieves collection statistics (sizes, index sizes, and each
(configured) collection count for one DB).
Munin
一些不在主要發行版中的、附加的munin插件。
還可以考慮 dex，一個MongoDB的索引和查詢分析工具。該工具比較MongoDB的日志文件和索引并對索引提出建議。
Also consider dex, an index and
query analyzing tool for MongoDB that compares MongoDB log files and
indexes to make indexing recommendations.
參見
作為 MongoDB Enterprise 的一部分，你可以運行 MMS On-Prem，它提供了在你的基礎設施上運行MMS功能的包。
托管(SaaS)監控工具?
以下這些是被作為托管服務提供的監控工具，(它們)通常是通過付費訂閱的。
名稱
說明
MongoDB Cloud Manager is a cloud-based suite of services for managing MongoDB
deployments. MongoDB Cloud Manager provides monitoring, backup, and automation
functionality. For an on-premise solution, see also
Ops Manager, available in MongoDB Enterprise Advanced.
Dashboard for MongoDB，包含MongoDB特定的警報，復制故障轉移的時間表以及iPhone、iPad、Android的移動應用程序。
IBM有一個應用程序性能管理的SaaS產品，包括MongoDB的監控器以及其他應用程序和中間件。
New Relic offers full support for application performance
management. In addition, New Relic Plugins and Insights enable you to view
monitoring metrics from Cloud Manager in New Relic.
Infrastructure monitoring to visualize
the performance of your MongoDB deployments.
在(進行)常規操作時， mongod 和 mongos 實例會向標準輸出或日志文件寫入當前帳號的所有服務器活動和操作。以下的運行時設置控制這些選項。
Process Logging?
During normal operation, mongod and mongos
instances report a live account of all server activity and operations
to either
standard output or a log file. The following runtime settings
control these options.
quiet. Limits the amount of information written to the
log or output.
verbosity. Increases the amount of information written to
the log or output. You can also modify the logging verbosity during
runtime with the logLevel parameter or the
db.setLogLevel() method in the shell.
path。開啟記錄寫入到文件，而不是標準輸出。調整這個設置時必須指定完整的日志文件路徑。
logAppend。增加信息到一個日志文件而不是覆蓋原文件。
注解
你可以參照 mongod 或 mongos 的命令行參數指定這些配置操作。
例如：
mongod -v --logpath /var/log/mongodb/server1.log --logappend
以 verbose 模式啟動 mongod 實例，并向 /var/log/mongodb/server1.log/ 所在的日志文件追加數據。
Log Redaction?
3.4 新版功能:Available in MongoDB Enterprise only
A mongod running with security.redactClientLogData
redacts messages associated with any given
log event before logging, leaving only metadata, source files, or line numbers
related to the event. security.redactClientLogData prevents
potentially sensitive information from entering the system log at the cost of
diagnostic detail.
For example, the following operation inserts a document into a
mongod running without log redaction. The mongod
has systemLog.component.query.verbosity set to 0:
db.clients.insertOne( { "name" : Joe, "PII" : "Sensitive Information" } )
This operation produces the following log event:
2016-09-23T13:51:43.572-0400 I COMMAND [conn1] command employeeData.directory
appName: "MongoDB Shell"
command: insert {
insert: "directory",
documents: [
{
_id: ObjectId('57e56baf6a71e2b785153aec'),
name: "Joe",
PII: "Sensitive Information"
}
],
...
A mongod running with security.redactClientLogData
performing the same insert operation produces the following log event:
注解
The exact redacted output may change leading up to the MongoDB 3.4 release.
This output is based on the 3.3 development series build.
2016-09-23T13:51:43.572-0400 I COMMAND [conn1] ###
Use redactClientLogData in conjunction with
encryption to assist compliance with
regulatory requirements.
診斷性能問題?
除非受制于系統范圍的約束，否則MongoDB對接入的連接沒有限制。你可以使用 ulimit 命令或通過修改系統的 /etc/sysctl 文件來修改系統的限制。更多詳情請參見 UNIX系統下 ulimit 的設置 。
復制和監控?
除了對任意MongoDB實例基本的監控需求,對于復制集,管理員還必須監控 復制延遲.”復制延遲” 指的是從一個 primary 復制寫操作到 secondary 所花的總時間.一些小的延遲間隔是可以接受的,但兩個顯著的問題會隨著復制延遲的增長出現:
第一個，延遲期間發生的操作不會復制到一個或多個從節點。如果您使用復制以確保數據持久化，特別長的延遲可能會影響到您的數據集的完整性。
第二個,如果復制延遲超過操作日志(oplog) 的長度,那么MongoDB就不得不在從節點上執行一個初始化同步,即復制 primary 的所有數據并重建所有索引。這在正常情況下很少見，但如果你設置的oplog比默認值小，可能會出現該問題。
注解
oplog的大小僅可在第一次運行時通過 mongod 命令的 --oplogSize 參數或最好使用MongoDB配置文件中的 oplogSizeMB 進行配置.如果在運行 --replSet 選項之前你沒有在命令行指定該參數, mongod 將創建默認大小的oplog.
默認情況下,oplog(的大小)在64位系統上是總的可用磁盤空間的5%。有關更改oplog大小的詳細信息，請參閱 修改Oplog大小
復制問題通常是成員之間網絡連接問題或是 primary 沒有足夠的資源來支持應用和復制的流量造成的結果。要檢查副本的狀態,可以在命令行中使用 replSetGetStatus 或如下助手：
rs.status()
文檔 replSetGetStatus 提供了該輸出的更深入的總覽.一般情況下,查看 optimeDate 的值并特別留意 primary 和 secondary 成員們的時間差.
分片和監控?
在大多數情況下, sharded clusters 的組件和所有其他的MongoDB實例同樣受益于監測和分析。另外，集群需要更深入的監測以確保數據被高效地分發在各節點之間，并且分片操作正確地發揮了作用。
參見
See the 分片 documentation for more
information.
配置服務器?
The config database maintains a map identifying which
documents are on which shards. The cluster updates this map as
chunks move between shards. When a configuration
server becomes inaccessible, certain sharding operations become
unavailable, such as moving chunks and starting mongos
instances. However, clusters remain accessible from already-running
mongos instances.
Because inaccessible configuration servers can seriously impact
the availability of a sharded cluster, you should monitor your
configuration servers to ensure that the cluster remains well
balanced and that mongos instances can restart.
MongoDB Cloud Manager and Ops Manager monitor config servers and can
create notifications if a config server becomes inaccessible. See the
MongoDB Cloud Manager documentation and Ops Manager documentation for more information.
均衡和數據塊分布?
最高效的 sharded cluster 部署能在分片間均勻地平衡 chunks .為了方便(達到)這一點,MongoDB有個分配數據的后臺 balancer 進程以確保數據段總是最佳地分布 shards 間.
穩定鎖?
幾乎所有情況下，當平衡器變穩定時,他們使用過的所有鎖將自動釋放。然而，由于任意一個持續時間過長的鎖都可能阻止以后的平衡，所以確保所有鎖都是合法的非常重要。要檢查數據庫的鎖定狀態，(你可以)用 mongo 命令行連接到一個 mongos 實例。使用如下命令序列切換到 配置 數據庫并展示分片數據庫中所有的顯式鎖:
use config
db.locks.find()
對于正在活動的部署,上面的查詢可以直觀的顯示.起源于隨機選擇的一個 mongos 的平衡進程使用了一種特殊的 “平衡器”–它可以阻止其他平衡活動的擴散.同樣地,對 配置 數據庫使用如下命令,即可檢查 “平衡器” 鎖的狀態.
db.locks.find( { _id : "balancer" } )
在 3.4 版更改:Starting in 3.4, the primary of the CSRS config server holds the
“balancer” lock, using a process id named “ConfigServer”. This lock
is never released. To determine if the balancer is running, see
Check if Balancer is Running.
總結
以上是生活随笔為你收集整理的mongodb 服务器性能监控,MongoDB监控的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： STL--list的模拟实现
- 下一篇： 服务器项目描述,项目服务器 2010 S