AWS provides a complete monitoring engine called CloudWatch. This works with metrics, including custom, user-provided metrics and it’s able to raise alarms when any such metric crosses a certain threshold. This is the only tool used for perfomance monitoring tasks within AWS.
This text will cover a monitoring scenario regarding deploying an arbitrary application to the “Cloud” and then being able to determine what causes performance limiting, be it in the application code itself or coming from limits enforced by Amazon.
Scenario
Let’s assume that you have just started using Amazon Web Services and are deploying applications on this free tier or by using general purpose (T2) instances. You quickly learn that the general purpose instances work with “credits” that allow dealing with short load spikes through performance bursting, but when these credits are exhausted, instance performance is reverted to some baseline. These particular details do not make a lot of sense, but you need to know if the application can meet the desired service targets while sticking to this setup.
From time to time one may receive a request from QA team in line of:
For testing purposes, I need that /opt/test/xxx directory be limited to 10 Megabytes. This directory is used by this 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: