Resource cheap : i.e not consuming many resources on our host.Now that you know why we want to build this dashboard, let’s have a look at the architecture put in place in order to build it.īefore having a look at the architecture that we are going to use, we want to use a solution that is: With a monitoring dashboard, you can simply go back in time and see which process was causing the issue. You would have to dig into kernel logs to see what has been killed. In this case, running a top command would give you zero information as it would be too late for you to catch who’s causing performance issues on your system. The main reason would be system availability: in case of a system overload, you may have no physical or remote access to your instance.īy externalizing process monitoring, you can analyze what’s causing the outage without accessing the machine.Īnother reason is that processes get created and killed all the time, often by the kernel itself. Knowing that those two commands exist, why would we want to build yet another way to monitor processes? Htop also provides gauges that reflects current system usage. Htop provides the same set of functionalities (CPU, memory, uptime.) as top but in a colorful and pleasant way. The top command is already pretty readable, but there is a command that makes everything even more readable than that: htop. This command is widely used among sysadmins and is probably the first command run when a performance bottleneck is detected on a system (if you can access it of course!)
Top provides a full overview of performance metrics on your system such as the current CPU usage, the current memory usage as well as metrics for individual processes. When it comes to process monitoring for Unix systems, you have multiple options. Now that we have an overview of everything that we are going to learn, and without further due, let’s have an introduction on what’s currently existing for Unix systems. Bonus : implementing ad-hoc filters to track individual processes or instances.