DEV Community: Adavize

Building a Real-Time System Monitor with Zig, Bun, and WebSockets

Adavize — Thu, 19 Mar 2026 08:41:33 +0000

Intro

Most monitoring tools are either bloated or cloud-dependent. I wanted something minimal, local, and fast so I built one using Zig for system-level collection and Bun for a real-time WebSocket API. Here is how I approached it.

System architecture

The core idea is simple: collect system metrics at regular intervals, store them in a database for later access, and broadcast updates to a web interface in real time.

Metric collectors

The first step is a set of metric collectors that reads system metrics ands send them to the API every second.

I chose the Zig programming language for this. Why Zig?

Zig is a modern alternative to C, offering better safety and performance while giving explicit control over memory. This makes it ideal for building lightweight tools with minimal overhead.
Zig provides native access to system resources which enables direct interaction with hardware while offering stronger memory checks than C.

To keep this article concise, I'll explain each metric collector in plain English rather than diving deeply into implementation details.

CPU metric

CPU usage is captured from /proc/stat. The /proc directory in Linux is a virtual filesystem managed by the kernel that exposes real-time system and process information. Other system metrics are also available here.

Flow for CPU metric collector:

[ Get first reading from /proc/stat ]
      |
[ After first reading cycle ]
      |
[ Get second reading from /proc/stat ]
      |
[ Calculate delta total and delta active difference ]
      |
[ Compute the CPU usage in percentage ]
      |
[ Send to API Service ]

CPU usage is calculated by comparing two readings of CPU time and computing the percentage of time spent doing active work versus idle time.

Source code for CPU metric collector here

Memory metric

Memory metrics are read from /proc/meminfo.

Flow for memory metric collection:

[ Read total memory from /proc/meminfo ]
      |
[ Read available memory from /proc/meminfo ]
      |
[ Compute the percentage being used ]
      |
[ Send to API Service ]

Source code for memory metric collector here

Temperature metric

Temperature metrics are read from the /sys virtual filesystem, which exposes hardware attributes and allows inspection or control of devices.

While /proc provides system and process stats, /sys exposes hardware-level information such as temperature sensors and power supply data.

Flow diagram of temperature metric collector:

[ Read the content of /sys/class/thermal/thermal_zone0/temp ]
      |
[ Convert from millidegrees Celsius to degree Celsius ]
      |
[ Send to API Service ]

Source code for temperature metric collector here

Battery metric

Battery metrics are also read from /sys. The collector reads the battery capacity from /sys/class/power_supply/BAT0/capacity (as a percentage) and sends it to the API.

Flow diagram of battery metric collector:

[ Read the content of /sys/class/power_supply/BAT0/capacity ]
      |
[ Send to API Service ]

Source code for battery metric collector here

API service

Once metrics are collected, the next step is to store and make them available to clients in real time. This is handled by a lightweight API service.

The API service is built with TypeScript and Bun. Bun is a fast Javascript runtime designed for modern applications, with built-in HTTP, WebSocket, and SQLite support.

Why Bun?

Fast and easy to setup
Built-in WebSockets support
Built-in SQLite
No need for extra tooling

The Web API service is responsible for:

Persisting collected metrics in SQLite
Broadcasting metrics to connected clients via WebSockets

Endpoints:

Method	Route	Description
`POST`	`/api/metrics/cpu`	Ingest CPU usage
`POST`	`/api/metrics/memory`	Ingest memory usage
`POST`	`/api/metrics/temperature`	Ingest temperature
`POST`	`/api/metrics/battery`	Ingest battery level
`GET`	`/api/history?metric=<name>`	Last 200 data points for a metric
`WS`	`/ws`	Real-time broadcast of all incoming metrics

Database

SQLite is used for its lightweight nature and simplicity, making it ideal for a local monitoring tool.

Metric table

Column	Type	Constraints	Description
id	INTEGER	PRIMARY KEY, AUTOINCREMENT	Unique row identifier
metric	TEXT	NOT NULL	Metric type (cpu, memory, temperature, etc.)
value	REAL	NOT NULL	Recorded metric value
ts	INTEGER	NOT NULL	Unix timestamp of when the metric was recorded

Writing to the database every second could cause performance issues, so SQLite is configured for Write-Ahead Logging (WAL) and relaxed synchronous mode:

PRAGMA journal_mode = WAL;
This configures SQLite to write to a separate WAL file before merging into the main database thereby improving concurrency and write performance, at the cost of slightly more disk usage.
PRAGMA synchronous = NORMAL;
This configuration reduces the number of disk sync operations for faster writes. In rare cases (e.g., sudden power loss), some recent writes may be lost—acceptable for this use case.

Web dashboard

Finally, to visualize the metrics in real time, I built a simple web interface that connects to the WebSocket endpoint. Whenever the API receives a new metric, it broadcasts it to all connected clients. The frontend listens for these events and updates the UI accordingly.

This approach avoids polling and ensures that the dashboard reflects system changes instantly.

I used CanvasJS for visualization, providing charts that show trends over time at a glance.

Conclusion

Building this monitoring tool helped me gain hands-on experience with Linux virtual filesystems (/proc and /sys) and real-time WebSocket communication.

While this is minimal, there are several possible improvements:

Adding alerting for threshold breaches
Enhancing the visualization layer
Aggregating metrics over time for example:
- average CPU usage over 1 minute
- maximum temperature over 5 minutes

Overall, this project was an excellent hands-on learning experience, deepening my understanding of low-level system operations and real-time data streaming.

Thank you for taking the time to read. Looking forward to whatever questions or suggestions you may have.

Here is the link to the entire source code. Happy digging!

Understanding file access permissions in Unix-like systems

Adavize — Wed, 13 Dec 2023 11:30:15 +0000

Before we jump right in, allow me to test your knowledge on this topic. Take a look at this list below, Can you confidently interpret the file access permissions on each line?

drwxr-xr-x   7 user1  group3   224 Jun 10  2022 nodejs-tutorials
-rw-rw-r--   3 user1  group1    96 Nov 25 00:25 hello_world.txt
drwxr--r--  20 user3  group2   640 Oct 23 18:56 docker-notes
lrwxr-xr--   3 user1  group2    96 Sep 12 10:58 repos
-rwxr-xr-x  11 user2  group1   352 Oct  5 11:42 main.sh

If your answer is "NO," then this article is for you. Here, Together, we will explore the concept of file access permissions, including its composition, various access levels, how to grant user and group access to a file, and more. By the end, you should have a comprehensive understanding of this topic.

BTW, the strange looking characters at the beginning of each line are called 'permission bits'. They are a set of flags in a Unix-like operating system that define the access rights of a file or directory.

So what is file access permission?

File access permissions refer to the rules and settings that determines who can perform specific actions (such as reading, writing, or executing) on a file or directory within a computer's file system.

It shouldn't be surprising that at the core of file access permissions are files, permissions and access levels. So let let us take a look at each aspect:

Files

Files are categorised into several types based on their characteristics and usage. They include:

Regular file: These are the most common type of files that contain data, such as texts, images, or programs. In Unix based file systems, files are represented by the '-' character
Directory: These files contain lists of other files and directories. They are represented by the 'd' character
Symbolic link or symlink: These are links or references to existing files or directories. They allow you to create a link to a target file or directory from another location in the file system. Symbolic links are represented by the 'l' character

Permissions

Every file or directory that exists in a system has permission and access level depending on the desired need. Permissions for a file can be one of or a combination of read, write and execute:

Read permission allows reading a file's contents and listing a directory's contents, respectively. It is represented by the letter 'r'
Write permission allows for the modification of a file’s contents and creating, deleting, and renaming files within a directory. Write permission is represented by the letter 'w'
Execute permission allows executing the file if it is a program or script and accessing a directory. It is represented by the letter 'x'

Access levels

Each permission 'read' 'write' 'execute' can be controlled within three(3) access levels of user, group and others;

User represents the owner of the file or directory
Group represents a collection of users associated with the file or directory
Others represents every other user in the system who are not the owner and also do not belong to the group associated with that file or directory

This diagram below breaks down permission bits, illustrating how file type is presented and how permissions are represented for each access level

The first letter in this case the letter 'd' represents the file type which is a directory
The next 3 characters represent permissions for the user or owner of the file
The following 3 characters in green represent the members of the associated group
The last 3 characters represent permissions for others who do not own the directory or are not members of the associated group

Now that you understand the composition of permission bits, let us apply this new found knowledge to the example we saw earlier. I added some comments explaining each section:

# d: 'nodejs-tutorials' is a directory
# rwx: user/file owner(user1) has read, write and execute permission
# r-x: associated group(group3) has read and execute permission
# r-x: others have read and execute permission
drwxr-xr-x   7 user1  group3    224 Jun 10  2022 nodejs-tutorials

# -: 'hello_world.txt' is a regular file
# rw-: user/file owner(user1) has read, and write permission
# rw-: associated group(group1) has read and write permission
# r--: others have only read permission
-rw-rw-r--   3 user1  group1    96 Nov 25 00:25 hello_world.txt


# d: 'docker-notes' is a directory
# rwx: user/file owner(user3) has read, write, execute permission
# r--: associated group(group2) has only read permission
# r--: others have only read permission
drwxr--r--  20 user3  group2   640 Oct 23 18:56 docker-notes

# l: 'repos' is a symbolic link or symlink
# rwx: user/file owner(user1) has read, write and execute permission
# r-x: associated group(group2) has read and execute permission
# r--: others have only read permission
lrwxr-xr--   3 user1  group2    96 Sep 12 10:58 repos

# -: 'main.sh' is a regular file
# rwx: user/file owner(user2) has read, write and execute permission
# r-x: group(group1) has read and execute permission
# r-x: others have read and execute permission
-rwxr-xr-x  11 user2  group1   352 Oct  5 11:42 main.sh

How to update file permissions

Changes to file permissions in a Unix-like system can be achieved using the chmod command. The chmod command expects 2 arguments: the [MODE] and the [FILE]

i.e $ chmod MODE FILE

The MODE can be specified using either symbolic or numeric representation but I will only be focusing on symbolic representation as it is easier to grasp and remember:

Examples

$ chmod u+x main.sh # gives execution permission to the user or file owner
$ chmod o-rw main.sh # removes read and write permission from other users
$ chmod g+w main.sh # gives write permission from the group

What if we want to grant all 3 permissions to all access levels?

# This gives read, write, execute permission to the user, group and other users
$ chmod ugo+rwx main.sh
# The above can otherwise be written as:
$ chmod a+rwx main.sh
# 'a' which means all can be used to represent all access levels

And that is it, hopefully this article turned out helpful and you are able to get a better understanding of file access permissions. If you found this helpful, let me know by liking, sharing and leaving comments.

Cheers!