Day 1: Getting the most out of your trial

Welcome aboard. This quick start guide will help you make the most out of your Server Density trial. If you are unsure about anything just email us at hello@serverdensity.com. You can also call us on +1 (646) 419-4674.

This guide is also available as a downloadable PDF.

1. Install the agent

To start monitoring a server you’ll need to install a lightweight agent.

2. Configure alerts

Alerts trigger against a specific metric—disk usage, for example, or load average.

3. Add Graphs to your Dashboard

Dashboards are filled with widgets that allow you to see an overview of all of your monitored devices, services and providers on one screen.

4. Install your Plugins

Out of the box, the Server Density agent collects key system metrics such as memory, disk, CPU, and network usage. You can then use one of our agent plugins to monitor pretty much everything else.

5. Configure Service Web Checks

Service checks provide an insight into how your websites/URLs respond when accessed from various locations.

6. Alert Costs

With Alert Costs you can find out which alerts are keeping your on-call team awake at night and distracting them throughout the day.

1. Install the agent

To start monitoring a server you need our lightweight agent.

The monitoring agent only ever posts data one way— from your servers to us. It never executes code based on remote commands, avoiding any risks from remote execution exploits.

Once in place, various system metrics will begin posting back to Server Density every minute.

Installing the agent can fall right in with your normal automation workflow. You can deploy to hundreds of servers in minutes using Chef, Puppet, Ansible, SaltStack or our one-line shell command.

2. Configure alerts

Alerts trigger against a specific metric—disk usage for example, or load average.

The value of a metric determines when the alert triggers, for example when the value is greater than 5, or if there is a regex match to a predefined string.

Alerts trigger immediately, but you may not need to receive an actual notification unless the alert has been open for some time. If you experience occasional load spikes you may want to set a delay so you only get notified when, say, CPU load remains high for more than 2 minutes.

3. Add Graphs to your Dashboard

Dashboards contain widgets that allow you to see an overview of all of your monitored devices, services and providers on one screen

One type of widget you can add on your dashboard is Graphs. Static Graphs display the metrics for specific servers. Try filtering by services, devices, or both. Clicking the name of a device lets you specify which metrics to plot.

Static dashboard graphs are good if your cluster never changes. But if you have an elastic environment where new instances appear and disappear, you should use the Elastic Graph widget instead.

Elastic Graphs display metrics for servers (and/or service checks) that match a specific search criteria. This is useful if you have a cluster of servers which changes frequently, for example launching new instances and removing old ones. You can specify a search term for your inventory of devices and service checks. This can take the form of a regular expression with wildcards.

You can specify a search term for your inventory of devices and service checks. This can take the form of a regular expression with wildcards.

Here is just a taste of things you could search for:

  • Single words which will match if they exist anywhere in the name
  • Basic wildcards e.g. Linux*
  • Regex wildcards e.g. 
    • /(.*)Linux/ - will match anything before Linux
    • /(.*)Linux(.*)/ - will match anything before and after Linux
  • Other complex regexes will also match

Your graph will update automatically and new servers will appear on the graph once they match your search term. Set a name for the graph by clicking on “Graph Name” and you’re good to go.

Tip: Set a prefix for your cluster and name new servers based on that prefix. 

4. Install your Plugins

Out of the box, the Server Density agent collects key system metrics such as memory, disk, CPU, and network usage. You can then use one of our agent plugins to monitor pretty much everything else.

Plugins are delivered as OS packages. You will need to install an additional package to use a plugin. These packages can be found using, for example on Debian/Ubuntu, apt-cache

apt-cache search sd-agent

Or on CentOS/Red Hat, yum search

yum search sd-agent

You can also find the package name within the plugin's documentation.

For example, to install the MongoDB plugin, you will need to run:

sudo apt-get install sd-agent-mongo

You can then configure the plugin as per the steps below (detailed steps within individual plugin documentation).

Example configuration files for plugins can be found in /etc/sd-agent/conf.d on most installations with the .example suffix. To activate a plugin, you can either use these configuration files (recommended), or create them from scratch when using a custom plugin. As an example:

cd /etc/sd-agent/conf.d
mv mongo.yaml.example mongo.yaml

You can then follow the instructions with the plugin file, or refer to the agent plugins docs for configuration. When you activate a plugin, ensure you restart the agent (example for RHEL and Debian based systems):

sudo /etc/init.d/sd-agent restart

5. Configure Service Web Checks

Service checks provide an insight into how your websites/ URLs respond when accessed from various locations.

Checks allow you to monitor a given URL, either via HTTP or by opening a TCP connection to a given port. Server Density will then poll the URL every 5 minutes and provide historical response times.

  1. To add a web check just click on the Services icon.
  2. Choose whether you want it to be checked over HTTP or TCP, and select the IP version (we support both IPv4 and IPv6).
  3. Select the locations you want to monitor from. We recommend at least 6 locations to minimise false positives (i.e. over-sensitive alerts).
  4. Click on the Save button. After a few minutes the check will start executing.
  5. Click to view the check map and click on the Alerting tab to add alerts for the check. For example, response time is high or status is down.

We also recommend the following two alerts for true "site down" monitoring:

  1. HTTP Code != 200 from at least 4 locations
  2. HTTP Status == down from at least 4 locations

6. Alert Costs

Did you know – each time an alert opens it costs you an additional 23 minutes of lost productivity due to context switching.

With Alert Costs you can find out which alerts are keeping your on-call team awake at night and distracting them throughout the day. Use Alert Costs to find patterns and trends to prevent your team from burning out from alert fatigue. Best practice dictates you should prioritise fixing the underlying issue causing the alerts that have the highest cost.

This is just the beginning.

You should now be up and running with the basics of what Server Density has to offer. Check out our full documentation for additional guides, tricks and troubleshooting and let us know if you need help with anything.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Monday  —  Friday.

10am  —  6pm UK.

Dedicated Support.