How can I configure the performance panel?

The 0.10 performance panel reports real time statistics from a mongodb server.    There are two ways in which you can customize the behavior of the panel:

  1. Refresh rates and general alarm properties can be configured from the preferences panel within dbKoda
  2. Alarm thresholds can be configured from the alarmThresholds.json file

Configuring refresh rates

The general preferences panel contains the settings for performance panel refresh rates, moving averages and alarm retention

Here are the descriptions of each of the items.  When it says "(Panel restart required)" you need to restart any open panels to apply the change. 

  • Prevent display sleep when panel is visible. (Panel restart required) If this checkbox is selected, dbKoda will prevent your display from sleeping if a performance panel is active.  This is useful if you are using the panel as a dashboard on an otherwise inactive display 
  • Metric moving average (number of samples) We "smooth" data samples retrieved from MongoDB and the OS in order to avoid jerky movements in data.  By default, we take the last 6 measurements and plot the average of those.  With a default refresh rate of 5000 ms, this means we are displaying information on the last 30 seconds of data, updated every 5 seconds. 
  • Foreground sampling rate (ms). This is the number of ms between sampling when the panel is visible. 
  • Background sampling rate (ms).  This is the number of ms between sampling when the panel is invisible.  
  • History size (number of samples). (Panel restart required).  This is the number of samples shown in a history graph.  The default represents one hour of history at the foreground sampling rate. 
  • History default brush size. (Panel restart required).  This controls the thickness of lines rendered in a history graph. 
  • Alarm keepalive (ms). (Panel restart required).  This controls the amount of time an alarm stays active.  The default is to keep an alarm for 60 seconds. 

Alarm thresholds

Alarm thresholds can currently only be configured by editing the file ~/.dbKoda/alarmThresholds.json.  Be careful editing this file -  changing the metric or alarmpaths may cause alarms to fail.   And if the document is not valid JSON the product might become unstable. 

If you make a mistake, delete the file - it will be recreated on restart. 

There are two types of alarms.  simpleThresholds are based on fixed threshold numbers.  For instance, in the metric query_scanToDocRatio , the alarm fires at 100 (caution) and 1000 (critical).  Don't worry about the notes section - they are notes for the developers :-).  If you think this alarm is firing too often, increase l1 to (say) 1000 and l2 to 20000.  

  "simpleThresholds": [{
    "metric": "query_scanToDocRatio",
    "l1": 100,
    "l2": 1000,
    "alarmPath": "alarm.mongo.scanToDocRatio",
    "warningMessage": "%d documents scanned for every document returned: review Indexes and slow queries",
    "notes": "large scans - enronloop.js for instance will cause this alarm"
  }, {
    "metric": "connections_inusePct",
    "l1": 80,
    "l2": 90,
    "alarmPath": "alarm.mongo.connectionsInUse",
    "warningMessage": "%d%% of connections are in use",
    "notes": "use makeconnections to cause this alarm"

The standard Deviation Thresholds are a bit different.  The fire when a value is unusually high.  For instance the connections threshold fires if the number of connections is more than 3 standard deviations above the mean.  As you might remember from high school math,  values more than 3 standard deviations above the mean will only occur about once in every 1,500 observations.  

"standardDeviationThresholds": {
    "minimumSamples": 20,
    "thresholds": [{
      "metric": "connections_current",
      "l1": 3,
      "l2": 5,
      "alarmPath": "alarm.mongo.connections_current",
      "warningMessage": "You have an unusually high number of connections (mean=%.2f,sd=%.2f, current=%d)",
      "notes": "Use node makeconnections.js to fire"
    }, {
      "metric": "latency_readWaitUsPs",
      "l1": 2,
      "l2": 3,
      "alarmPath": "alarm.mongo.connections_current",
      "warningMessage": "Connections are spending an unusually large amount of time waiting for reads (mean=%.2f,sd=%.2f, current=%d us/s)",
      "notes": "randCrud.js, randQry.js enronloop2.js"

The minimumSamples setting controls the minimum number of samples that must exist before these alarms fire. 

Is this article helpful?