Automating Server Monitoring: A Guide to Htop and Ansible Standardization

Server Management Standardization: Automating Htop Configuration with Ansible

For a system administrator or DevOps engineer, the biggest waste of time is repetitive tasks. When managing a single server, manually updating packages or installing and configuring htop might not be an issue. However, as the number of servers increases, connecting to each one individually to enter the same commands is both inefficient and prone to human error.

In this article, I will discuss two fundamental tools I use to standardize server monitoring processes in my own infrastructure: Htop and Ansible. First, we will touch upon the technical details of these tools and why they are preferred, and then we will examine the automation structure I created using these tools, step-by-step with code examples.

Section 1: What is Htop and Why Choose it Over top?

In the Linux world, when it comes to monitoring system resources, the first command that usually comes to mind is top. It comes with every distribution and does the job. However, top can sometimes be insufficient in terms of reading and interpreting the data it presents. Although Htop is a terminal-based system monitor, it is a much more advanced alternative to top thanks to its visual interface and interaction capabilities.

Technical Advantages of Htop

Visual Resource Usage: While the top command expresses CPU and RAM usage only with numerical values, Htop offers separate colored bars for each CPU core. The colors of these bars are not random:

  • Green: Represents User processes.
  • Red: Represents Kernel processes.
  • Blue: Represents Low-priority processes.

On the RAM side, it allows you to distinguish at a glance how much of the system is actively used and how much is allocated as buffer or cache.

Process Tree: When a service is not working correctly, it may have created many interconnected child processes in the background. By pressing F5 on Htop to switch to the tree view, it becomes clear which process spawned from which “parent” process. This is a critical feature for identifying a locked application at its root.

Ease of Sending Signals: Instead of memorizing the PID (Process ID) value and entering a separate command to kill a process, you can directly send SIGTERM or SIGKILL signals by highlighting the relevant process in the Htop interface and pressing F9.

Interpreting Load Average: The values like Load Average: 0.50, 1.20, 0.85 seen in the upper right corner of the Htop interface indicate the server’s load status for the last 1, 5, and 15 minutes. Htop combines this data with real-time CPU graphs, making it easier for you to understand whether the server is experiencing an instantaneous bottleneck (spike) or is under chronic load.

Section 2: The “Infrastructure as Code” Approach with Ansible

The modern approach to infrastructure management is to store the entire configuration as code (IaC) rather than manually configuring servers. At this point, Ansible stands out with its simplicity and powerful architecture.

What is Ansible?

Ansible is a Python-based, open-source automation tool. It handles tasks such as server configuration, software deployment, and task automation.

Why Ansible?

Agentless: Unlike other tools like Puppet or Chef, Ansible does not require any “agent” or software to be installed on the servers to be managed. The only things it needs are SSH access and Python. This feature allows it to be integrated quickly without adding extra load to the system.

YAML Format and Readability: Ansible’s task files (Playbooks) are written in YAML format. Reading and writing in this format is quite simple. Even a system administrator with no coding background can easily understand what steps will be taken by looking at a Playbook.

The Principle of Idempotency: Ansible’s strongest suit is its “idempotent” nature. This means that no matter how many times you run an operation, the result does not change. For example, if you write a “create folder” command with a Bash script, you will get a “Folder already exists” error when the script runs a second time. Ansible, however, first checks for the existence of the folder; if it exists, it does nothing; if not, it creates it. This ensures system stability.

Section 3: Implementation – Setting Up the Automation

In the scenario I implemented in my own infrastructure, the goal was as follows:

  1. Connect to all servers in my inventory.
  2. Update the apt package manager.
  3. Install the htop package.
  4. Distribute the htoprc configuration file, customized according to my usage habits, to the servers.

We created three basic components for this process: Inventory, Config, and Playbook.

1. Inventory File (inventory)

Ansible needs to know which servers to talk to. For this, I created a file named inventory and grouped the servers.

[wazuh_srv]
91.xx.xx.xx ansible_user=root

Here, [wazuh_srv] is a group name. In the future, when I add new IP addresses to this group, the automation code will be applied to all of them simultaneously.

2. Customized Htop Configuration (htoprc)

I prefer the CPU bars, memory usage, and process sorting to appear exactly how I want them, rather than Htop’s default view. To do this, I copied the .config/htop/htoprc file from my local computer to the project directory. This saves the trouble of entering every server individually and making settings via the F2 menu. The file content is briefly as follows:

# Htop configuration file
fields=0 48 17 18 38 39 40 2 46 47 49 1
sort_key=46
sort_direction=-1
hide_threads=0
hide_kernel_threads=1
hide_userland_threads=0
...

3. Playbook File (install_htop.yml)

This file, the heart of the automation, defines the tasks to be performed in order.

YAML

---
- name: Htop Installation and Configuration
  hosts: all
  become: yes  # Run with Root privileges

  tasks:
    # Step 1: Update package lists (apt update)
    - name: Update Apt cache
      apt:
        update_cache: yes
        cache_valid_time: 3600 # Do not repeat if updated in the last 1 hour

    # Step 2: Install Htop package
    - name: Install Htop package
      apt:
        name: htop
        state: latest

    # Step 3: Create configuration directory
    - name: Create Htop config directory
      file:
        path: /root/.config/htop
        state: directory
        mode: '0755'

    # Step 4: Copy local htoprc file to the server
    - name: Copy custom htoprc file
      copy:
        src: htoprc
        dest: /root/.config/htop/htoprc
        mode: '0644'
        owner: root
        group: root

Code Analysis:

  • hosts: all: Targets all servers in the inventory file.
  • apt module: Used for package management. The cache_valid_time parameter shortens the process time by preventing unnecessary updates.
  • file module: Performs file system operations. Here, we guaranteed the existence of the .config/htop directory.
  • copy module: This module copies the htoprc file from our local machine to the server. Thus, when Htop is opened for the first time, it starts directly with our settings.

Section 4: Execution and Result

To run the structure we prepared, we used the following command via the terminal:

Bash

ansible-playbook -i inventory install_htop.yml

When the command was executed, Ansible performed the following steps in order:

  1. Gathering Facts: Connected to the server and collected operating system information.
  2. Task Execution: Processed the 4 tasks we defined sequentially.
  3. Recap: Presented a summary report at the end of the process.

Seeing changed=3 in the output indicates that Ansible made 3 changes on the server (installing package, opening folder, copying file). When we run the same command again, we see changed=0; because Ansible realizes that the server is already in the desired state and touches nothing.

Why This Method?

The main reasons I prefer this method over manual installation are:

  • Consistency: I guaranteed exactly the same Htop version and the same visual settings on all servers.
  • Speed: When a new server is added, the installation time dropped from 10 minutes to 10 seconds.
  • Documentation: The YAML code we wrote actually became the living documentation of our infrastructure. The answer to the question “How was Htop installed?” is no longer hidden in a person, but in the code itself.

In system management, automation is not a luxury but a necessity. Even for the installation of a simple monitoring tool, using Ansible is a solid step towards a scalable and manageable infrastructure.