Automatically deploying server monitoring across servers
Last week we announced integration into a number of popular cloud provider APIs for our server monitoring service, Server Density. This functionality helps with administration when adding lots of servers, particularly over multiple providers, but it doesn’t help with deploying the agent across lots of cloud instances, particularly when deployment is automated from an image. You would have to use our deploy script to register the agent against your Server Density account. That has now changed.
Auto deployment
You can now deploy the agent with the same config for any of your servers and we’ll automatically detect that it is a new server, create it within Server Density and copy all your alerts from the original server. This means you can create a single config as part of your VM image, and then when you boot from it, Server Density monitoring will start automatically.
This works particularly well with our OS packages for Debian / Ubuntu and Red Hat / Fedora as they also install init scripts so the agent starts on boot. With this new functionality, the agent will start on a new server and register itself in your account.
This will work on any cloud provider (e.g. Amazon EC2 AMIs or Rackspace Cloud backup images) as well as on any other server, virtualised or not. We detect the existence of a new server based on the hostname (which must therefore be unique).
Now, as your infrastructure changes and responds to demand with new servers and instances, Server Density will stay up to date so your monitoring never stops.
Note: This requires a new version of the agent, v1.4.2, which has also just been released, a minor bug fix only release.
Recommended setup
- Create a new server within Server Density and configure any alerts you want. These settings will be copied to any new server automatically detected.
- Install the agent onto your server using our OS packages for Red Hat/Fedora or Debian/Ubuntu. These include init scripts so the agent starts on boot.
- Configure the agent using the agent key (and any other settings you want) from the server you created in step 1.
- Create your OS image.
When you launch a new instance from your image, the agent will automatically start and register itself as a copy of the server created in step 1. This will include any alerts and will start monitoring immediately. Full documentation can be found here.
Any idea how pricing works on this?
Is there any way to limit the number of servers we monitor automatically?
Pricing is the same as the standard pricing and you can’t limit the number of servers – it’ll just add them as they’re launched and the agent registers.
It be handy to have some way of limiting the number of servers. After a certain point I’m more interested in the aggregate. But up to then I’d rather not accidentally land up with 25 servers being monitored when I can probably extrapolate from 3 or 4 servers doing the same function.
How would you see the limit working? Just as a hard limit that no more can be added after that so you have to delete servers before more can be added?
Yeah pretty much. At least as a basic step.
If you wanted handy functionality around this
- ability to group server types together and a hard limit for each group (mail servers, app servers, batch servers)
- dashboard showing how many unmonitored servers there are per group
- ability to increase or decrease limit per group and it automatically add or remove servers being monitored
- monitoring and alerts on how many servers there are per group
- aggregate/average information per group
I’d pay a small premier for this. Perhaps paying a monitoring cost per group of servers. So if it’s £10 per server and I have a hard limit of 4 servers, with 10 servers in the group (4 monitored, 6 not) I would pay £50 (4x servers + 1 group ing feature).
Is this making any sense?
Monitoring individual servers is critical when I only have 2 servers and no automatic scaling. With automatic scaling, it’s less critical, as high loads just spin up new servers. The more important information is what’s going on in the group.
The monitoring switches from letting me know when something is wrong with a server to allowing me to fine tune my server images and diagnostics for optimisation.
Adrian