DEV Community

Robin Sishodia
Robin Sishodia

Posted on

DevOps Lab, Part 2: Building a Linux Server Health Report with Bash and Git

#devops #linux #beginners #git

In Part 1, I launched an Ubuntu server on AWS EC2 and connected to it. For this checkpoint, I moved from setting up the server to doing something useful on it: creating a small Bash script that prints a server health report, documenting it, and pushing the files to GitHub.

I am learning DevOps through small, hands-on tasks. I use AI assistance for guidance and documentation, while checking the commands and their output as I go.

What I built

The script reports four things:

  • The current UTC date and time
  • Disk usage for the root filesystem
  • Memory and swap usage
  • Server uptime and load averages

The completed files are in my devops-support-ticket-platform repository, under mini-projects/01-linux-healthcheck/.

This is a beginner learning project. The support-ticket application itself is a later checkpoint.

1. Understanding where I am in Linux

My workspace on the server was:

/home/ubuntu/devops-lab
Enter fullscreen mode Exit fullscreen mode

Two basic commands helped me avoid getting lost:

pwd
ls -la
Enter fullscreen mode Exit fullscreen mode

pwd prints the current directory. ls -la lists its contents, including hidden entries and permission details.

This matters because relative paths start from the current directory. Before creating, opening, or running a file, I need to know where I am.

2. The health-report script

Here is the script committed to the repository:

#!/bin/bash

echo "=== SERVER HEALTH REPORT ==="
echo "Generated at:"
date -u
echo "Disk space:"
df -h /

echo
echo "Memory:"
free -h

echo
echo "Uptime and workload:"
uptime
Enter fullscreen mode Exit fullscreen mode

View healthcheck.sh on GitHub

What each command does

Command Purpose
#!/bin/bash Selects Bash as the interpreter when the executable script is run directly.
echo Prints headings or blank lines to make the report readable.
date -u Displays the date and time in UTC.
df -h / Displays filesystem capacity and usage for the root filesystem in readable units.
free -h Displays memory and swap statistics in readable units.
uptime Displays uptime, logged-in user count, and load averages.

One distinction I learned: df reports filesystem space, while free reports memory. They answer different questions.

Also, the load averages from uptime are not CPU usage percentages. They represent average system load over the last 1, 5, and 15 minutes.

3. Running the script

From the repository root, the script can be run with:

bash mini-projects/01-linux-healthcheck/healthcheck.sh
Enter fullscreen mode Exit fullscreen mode

Another approach is to give the script execute permission and run it directly:

chmod +x mini-projects/01-linux-healthcheck/healthcheck.sh
./mini-projects/01-linux-healthcheck/healthcheck.sh
Enter fullscreen mode Exit fullscreen mode

Using bash filename explicitly selects the interpreter. Running ./filename directly requires execute permission and uses the script's shebang.

4. Reading the result

During the lab, the root filesystem showed roughly 6.8 GB of usable capacity and about 34–35% usage. The memory report showed approximately 952 MiB of RAM and no swap configured. These are observations from this particular instance; another machine will produce different values.

The point was to understand the output:

  • Disk: how much filesystem space is used and available?
  • Memory: what memory is available, and is swap configured?
  • Uptime: how long has the server been running, and what is its recent load?

A report alone does not decide whether the server is healthy. That depends on the workload and what normal looks like for that machine. This script also does not check application availability, send alerts, or retain a history.

5. Saving the work with Git

I committed the script and its README, then pushed the changes to GitHub.

A repeatable workflow from the repository root is:

git status
git add mini-projects/01-linux-healthcheck/healthcheck.sh mini-projects/01-linux-healthcheck/README.md
git diff --staged
git commit -m "Add Linux server health report mini-project"
git push
git status
Enter fullscreen mode Exit fullscreen mode

Before using git push, the repository needs a configured remote, authentication, and an upstream branch. The commands above assume those are already set up.

The distinction that finally became clear to me:

git commit records staged changes locally. git push uploads local commits to the remote repository.

git add selects what goes into the next commit. git diff --staged lets me review that selection. A successful commit does not mean the work is already on GitHub.

At the end of this checkpoint, the push succeeded and Git reported a clean working tree.

6. Mistakes that helped me learn

Using the wrong filename

A command cannot open or run a file if the name or path is wrong. Checking the current directory and listing its files was more useful than repeatedly trying the same command.

My troubleshooting sequence is now:

pwd
ls -la
Enter fullscreen mode Exit fullscreen mode

Then I check the exact spelling and path before trying again.

GitHub authentication

I also encountered an authentication failure while trying to push over HTTPS using a GitHub account password. GitHub account passwords are not used for HTTPS Git authentication.

I installed GitHub CLI during troubleshooting. Authentication is separate from committing: Git can create a local commit even when access to the remote is not working.

I keep credentials and authentication codes out of the repository and article.

Why this small project matters to me

This task connected several fundamentals in one exercise: navigating Linux, reading system information, writing a Bash script, understanding file permissions, documenting the result, and using Git.

The script is small enough that I can explain every command. That makes it a useful starting point for learning automation.

Possible future improvements include saving reports to a file, scheduling runs, adding meaningful failure checks, and checking an application endpoint. Those are future tasks, rather than features of this version.

Completed checkpoint

  • Created a Bash server health-report script on Ubuntu EC2
  • Ran it and interpreted disk, memory, and uptime output
  • Added a README
  • Committed and pushed the files to GitHub

Source code: Linux health-check mini-project

I am documenting each completed checkpoint as I learn. If you started DevOps with small Linux or Bash projects, what exercise helped you understand the fundamentals?

Top comments (1)

Collapse
 
officialmailkr profile image
오피셜메일 •

디스크·메모리·부하 평균을 서로 다른 질문으로 구분해 설명한 부분이 입문자에게 도움이 되겠습니다. 다음 실습에서는 출력에 호스트 식별자와 각 명령의 실패 여부도 넣어 보면, 여러 서버의 결과를 모았을 때 값이 비어 있는 상황과 실제 정상 상태를 구분하기 더 쉬울 것 같습니다.