AWS provides a complete monitoring engine called CloudWatch; it works with metrics – including custom, user-provided metrics – and is able to raise alarms when any such metric crosses a certain threshold. This is the tool that is used for all perfomance monitoring tasks within AWS.
This text will cover a monitoring scenario regarding deploying an arbitrary appplication to the cloud and being able to determine what causes the performance limits to be met, be it the application code itself or resource limits enforced by Amazon.
Scenario
Let’s assume that one has just started using Amazon Web Services and is deploying applications on free tier or other general purpose (T2) instances. One learns that the general purpose instances work with “credits” that allow dealing with short spikes through performance bursting – but once the credits are exhausted the performance is reverted to some baseline. All the particular details do not make a lot of sense but one needs to know if the application can meet the desired service limits with this setup.
From time to time one may receive a request from the QA in line of:
For testing purposes, I need that /opt/test/xxx directory be limited to 10 Megabytes. This directory is used by the zzz application ran as user tester.
How could the directory size be limited in Linux? Is it even possible? – these are fair questions and the answer is yes. One needs to:
Use the directory as a mount point for a size-limited storage device;
Use the proper mount options to allow full access to the non-root user specified;
Disable Selinux (easy) or allow that particular user to access data on mount points (complicated).
Let’s start with the beginning, the storage device. There are multiple options here:
A simple loop device (a regular file used as a file system);
A logical volume (LVM), assuming the disk setup is based on this technology and there is enough free space left to accomodate the new device;
Attaching a new storage device (e.g. in a Cloud environment like Amazon Web Services).
The big data repository known as Chef Server is manipulated with a tool called knife. The general (simplified) syntax for this tool is:
$ knife category command item
The category can be one of: environment, client, node, data bag, cookbook, … The full list can be found here.
The command (usually) is one of create, list, show, edit or delete. There are more commands, though, depending on what is being requested through knife.
On the cheat sheat itself, let’s start with some classics: