Forem: Altair Lage

Essential Linux Commands Map

Altair Lage — Wed, 15 Apr 2026 13:12:52 +0000

Essential Linux Commands Map

With the evolution of operational systems visual environments, the majority of users don't ever need to use the command terminal for their daily activities. Most users do not execute any advanced system tasks, and when they do it, the configuration apps are more than enough. You probably know some Windows users that never opened the "black screen" for anything.
The same happens with Linux. It evolved its visual environments, also known as Desktop environments (DEs), to a point that the terminal is not necessary for almost 100% of an average user needs. The most popular choices, GNOME, KDE, and XFCE, allow system configurations and troubleshooting from the UI. But when you need advanced troubleshooting and system administration, the terminal is always your best friend.

You may feel intimidated the first time you open a Linux terminal. That black screen with thousands of commands, many options, and sometimes, many ways to do the same thing. Beginners often feel lost, and even experienced users sometimes fall back on the same small set of commands every day.

That's why a visual command map like the main image of this article is useful. It is superficial, but focuses on the commands people use most often in real life. The main image organizes the commands into functional groups to make it easier to understand the kind of tasks they solve. Further in this article, all the groups and commands are explained briefly for reference.

In practice, most terminal work is the same you perform on a UI. You move through folders, inspect files, edit content, check running processes, review system details, manage users, troubleshoot networks, and install software. Once you understand that terminal and a visual interfaces are only faces of the same coin, Linux terminal feels more practical and less overwhelming.

A list of commands is not a good way to learn something. People remember things better when they make associations with other things, happenings or feelings. Grouping it by purpose works better because you create associations, for an example, "I have no internet connection" relates to networking, which can relate to IP misconfiguration, so maybe ipconfig command may help to diagnose the issue. That is what makes the presented map helpful. It gives structure to the learning process.

Instead of thinking, “I need to memorize all Linux commands”, you can think “I need these few commands for files, a few for processes, and a few for networking”.
It reflects real life. Most users do not need hundreds of commands every day. They need a small set they can use with confidence for the day-by-day tasks, the same way most users don't need to know and perform multiple advanced tasks via the UI. Once that core is familiar, learning more advanced tools becomes much easier.

File and Directory Management

These commands allow you move/browse around the filesystem and manage files and folders.

ls - List files and directories in the current location.
- Example: ls -la: Lists all files (including hidden ones) in long format, showing permissions, owner, size, and modification date.
pwd - Show the full path of the current working directory.
- Example output: # /home/myuser/projects/my-app.
- Useful when you've navigated deep into a directory tree and need to confirm where you are.
cd - Change, or moves, from one directory to another.
- Examples:
- cd /var/log # Move to an absolute path
- cd .. # Move one level up
- cd ~ # Move to the current user home directory
mkdir - Create a new directory.
- Examples:
- mkdir my-folder # Create the "my-folder" folder in current directory
- mkdir -p parent/child/grandchild # Create nested directories in one go
  - The -p flag creates intermediate directories as needed, so you don't have to create each level manually.
rmdir - Remove an empty directory.
- Example: rmdir old-folder
- This only works if the directory is completely empty. If it contains files, you'll need rm -r instead.
touch - Create an empty file or updates a file timestamp.
- Examples:
- touch notes.txt # Create a new empty file
- touch existing-file.log # Update the modification timestamp to now
cp - Copie files or directories.
- Examples:
- cp report.txt report-backup.txt # Copy the report.txt file and name it to report-backup.txt
- cp -r src/ src-backup/ # Copy the src directory recursively
- The -r (recursive) flag is required when copying directories, otherwise cp will skip them.
mv - Move or renames files and directories.
- Examples:
- mv old-name.txt new-name.txt # Rename a file
- mv file.txt ~/Documents/ # Move a file to another directory
- Unlike cp, mv works on directories without needing any extra flags.
rm - Remove files or directories.
- Examples:
- rm unwanted-file.txt # Remove the file
- rm -r old-project/ # Remove a directory and everything inside it
- rm -ri important-folder/ # Remove recursively but ask for confirmation on each file
- Be careful with rm -r there is no trash can in the terminal. Once removed, files are gone for good.

These are often the first commands people learn, and for good reason. They are the foundation of daily terminal use. If you think about it, this is also the most frequent actions you perform in a visual interface, like Windows.

File Viewing and Editing

Once you find a file, the next step is usually to read or edit it. These commands handle these actions.

cat - Print file content directly in the terminal.
- Examples:
- cat server.log # Display the entire file in the terminal
- cat -n server.log # Display with line numbers
- cat file1.txt file2.txt > combined.txt # Concatenate two files into a new one
less - Open a file for scrolling and reading page by page.
- Examples:
- less /var/log/syslog # Open a log file for browsing (use q to quit)
- less -N app.log # Open with line numbers shown
- dmesg | less # Pipe command output into less for easy scrolling
more - Display file content one screen at a time.
- Examples:
- more readme.txt # View the file one screenful at a time
- more -10 config.yaml # Display 10 lines at a time
- ls -la /etc | more # Pipe a long directory listing through more
nano - A simple terminal-based text editor.
- Examples:
- nano notes.txt # Open (or create) a file for editing
- nano +15 script.sh # Open a file and jump directly to line 15
- nano -B /etc/hosts # Open a file and automatically create a backup before editing
vim - A powerful terminal-based text editor with advanced features.
- Examples:
- vim deploy.sh # Open a file for editing (press i to enter insert mode, Esc then :wq to save and quit)
- vim +42 main.py # Open a file and jump to line 42
- vim -d file-v1.txt file-v2.txt # Open two files side by side in diff mode
gedit - A graphical text editor often found on desktop Linux systems.
- Examples:
- gedit todo.txt # Open a file in the graphical editor
- gedit +25 app.conf # Open a file and place the cursor on line 25
- gedit file1.txt file2.txt # Open multiple files in separate tabs

This group is useful for everything from reading logs to editing config files.

Process Management

Linux is always running processes in the background and foreground. These commands help you inspect and control them. It is similar to the Windows Task Manager, but in text mode.

ps - Show a snapshot of running processes.
- Examples:
- ps aux # List all running processes with detailed info
- ps -ef | grep nginx # Find all processes related to nginx
- ps -u jdoe # Show all processes owned by user jdoe
top - Display live system activity and active processes.
- Examples:
- top # Launch the interactive process viewer
- top -u www-data # Show only processes owned by the www-data user
- top -p 1234,5678 # Monitor only specific PIDs
kill - Send a signal to stop or control a process by PID.
- Examples:
- kill 1234 # Gracefully terminate process with PID 1234 (sends SIGTERM)
- kill -9 1234 # Force-kill a stubborn process (sends SIGKILL)
- kill -STOP 1234 # Pause a running process without ending it
killall - Stop processes by name.
- Examples:
- killall firefox # Terminate all Firefox processes
- killall -9 node # Force-kill all Node.js processes
- killall -u jdoe python # Kill all Python processes owned by user jdoe
pstree - Display processes in a tree structure.
- Examples:
- pstree # Show all processes as a tree from init/systemd
- pstree -p # Show the tree with PIDs next to each process
- pstree -u jdoe # Show the process tree for a specific user
htop - An interactive process viewer with a cleaner interface than top.
- Examples:
- htop # Launch the interactive viewer with color-coded output
- htop -u www-data # Filter to show only a specific user's processes
- htop -p 1234,5678 # Monitor only specific PIDs in the interactive viewer

When a system is slow or an app freezes, this is usually where you start troubleshooting.

System Information

These commands help you learn more about the machine itself, including hardware, storage, and memory usage.

uname - Show basic system information such as kernel and OS name and version.
- Examples:
- uname -a # Display all system info (kernel, hostname, architecture, etc.)
- uname -r # Show only the kernel release version
- uname -m # Print the machine hardware architecture (e.g., x86_64)
df - Report disk space usage by filesystem.
- Examples:
- df -h # Show disk usage in human-readable format (GB, MB)
- df -h /home # Check available space on the /home partition
- df -T # Include the filesystem type in the output (ext4, xfs, etc.)
du - Estimate disk usage for files and directories.
- Examples:
- du -sh /var/log # Show total size of the /var/log directory in human-readable format
- du -h --max-depth=1 /home # Show sizes of immediate subdirectories under /home
- du -ah /tmp | sort -rh | head -10 # Find the 10 largest files and folders in /tmp
free - Display memory and swap usage.
- Examples:
- free -h # Show RAM and swap usage in human-readable format
- free -m # Display memory values in megabytes
- free -h -s 5 # Refresh memory stats every 5 seconds
lscpu - Show CPU architecture details.
- Examples:
- lscpu # Display full CPU info (cores, threads, model, cache, etc.)
- lscpu | grep "Model name" # Show only the CPU model name
- lscpu | grep "CPU(s)" # Check the total number of CPUs/cores available
lshw - List detailed hardware information.
- Examples:
- sudo lshw -short # Show a compact summary of all hardware components
- sudo lshw -class network # Display only network adapter details
- sudo lshw -class memory # Show RAM module details (size, speed, slots)
lsblk - Display block devices such as disks and partitions.
- Examples:
- lsblk # List all block devices in a tree view
- lsblk -f # Include filesystem type and UUIDs in the output
- lsblk -o NAME,SIZE,TYPE,MOUNTPOINT # Show only specific columns for a cleaner view

This category is especially helpful for troubleshooting and performance checks.

User and Group Management

Linux is built around users, groups, and permissions. These commands support account administration.

passwd - Changes a user password.
- Examples:
- passwd # Change the password for the currently logged-in user
- sudo passwd jdoe # Reset the password for user jdoe (requires root)
- passwd -e jdoe # Force user jdoe to change password on next login
useradd - Creates a new user account.
- Examples:
- sudo useradd jdoe # Create a new user with default settings
- sudo useradd -m -s /bin/bash jdoe # Create a user with a home directory and bash shell
- sudo useradd -G developers,docker jdoe # Create a user and add them to multiple groups
userdel - Deletes a user account.
- Examples:
- sudo userdel jdoe # Remove the user account but keep the home directory
- sudo userdel -r jdoe # Remove the user and delete their home directory
- sudo userdel -f jdoe # Force removal even if the user is currently logged in
usermod - Modifies an existing user account.
- Examples:
- sudo usermod -aG docker jdoe # Add user jdoe to the docker group without removing other groups
- sudo usermod -s /bin/zsh jdoe # Change the default shell for user jdoe
- sudo usermod -l jsmith jdoe # Rename the user account from jdoe to jsmith
groupadd - Creates a new group.
- Examples:
- sudo groupadd developers # Create a new group called developers
- sudo groupadd -g 1500 devops # Create a group with a specific GID
- sudo groupadd --system appusers # Create a system group for service accounts
groupdel - Deletes a group.
- Examples:
- sudo groupdel developers # Remove the developers group
- sudo groupdel old-team # Delete a group that is no longer needed
- sudo groupdel temp-project # Clean up a temporary project group
groups - Shows the groups a user belongs to.
- Examples:
- groups # Show the groups for the currently logged-in user
- groups jdoe # List all groups that user jdoe belongs to
- groups root # Check which groups the root user is a member of
id - Displays user ID, group ID, and related group information.
- Examples:
- id # Show UID, GID, and groups for the current user
- id jdoe # Display the full identity info for user jdoe
- id -gn jdoe # Print only the primary group name of user jdoe

Specially if you manage shared systems or servers, you will use these commands very often.

Network Configuration and Monitoring

Networking is a big part of Linux administration. These commands help you inspect connections and test communication.

ifconfig - Displays or configures network interfaces on older systems.
- Examples:
- ifconfig # Show all active network interfaces and their IPs
- ifconfig eth0 # Display details for a specific interface
- sudo ifconfig eth0 down # Disable the eth0 network interface
ip - Modern command for viewing and managing network interfaces, routes, and addresses.
- Examples:
- ip addr show # List all interfaces with their IP addresses
- ip route show # Display the routing table
- ip link set eth0 up # Bring the eth0 interface up
ping - Test the connectivity to another host.
- Examples:
- ping google.com # Continuously ping Google to check internet connectivity
- ping -c 4 192.168.1.1 # Send exactly 4 ping packets to a host
- ping -i 2 server.local # Ping every 2 seconds instead of the default 1 second
netstat - Show network connections, routing tables, and interface stats.
- Examples:
- netstat -tulnp # Show all listening TCP/UDP ports with process names
- netstat -an | grep :80 # Check if anything is listening on port 80
- netstat -r # Display the kernel routing table
ss - Display socket and network connection information, often faster than netstat.
- Examples:
- ss -tulnp # List all listening ports with associated processes
- ss -s # Show a summary of socket statistics
- ss -t state established # Display only established TCP connections
traceroute - Show the path packets take to reach a destination.
- Examples:
- traceroute google.com # Trace the route to Google showing each hop
- traceroute -n 8.8.8.8 # Trace without resolving hostnames (faster output)
- traceroute -m 15 example.com # Set a maximum of 15 hops
ssh - Connect securely to a remote machine.
- Examples:
- ssh jdoe@192.168.1.50 # Connect to a remote host as user jdoe
- ssh -p 2222 jdoe@server.com # Connect using a non-default SSH port
- ssh -i ~/.ssh/mykey.pem ec2-user@10.0.0.5 # Connect using a specific private key
nc - Netcat, a flexible tool for testing ports, sending data, and debugging network services.
- Examples:
- nc -zv server.com 443 # Test if port 443 is open on a remote host
- nc -l 8080 # Listen for incoming connections on port 8080
- nc -zv 192.168.1.10 20-100 # Scan a range of ports on a host

This is the part of Linux that becomes essential the moment something stops connecting.

Package Management

Linux distributions use package managers to install, update, and remove software. The exact tool depends on the distro.

apt-get - Package management tool used on Debian-based systems.
- Examples:
- sudo apt-get update # Refresh the list of available packages
- sudo apt-get install nginx # Install the nginx web server
- sudo apt-get remove --purge nginx # Remove nginx and its configuration files
apt - A more user-friendly package command for Debian-based systems.
- Examples:
- sudo apt update && sudo apt upgrade # Update package list and upgrade all packages
- sudo apt install git curl wget # Install multiple packages at once
- apt search image editor # Search for packages related to image editing
yum - Older package manager for RPM-based distributions.
- Examples:
- sudo yum install httpd # Install the Apache web server
- sudo yum update # Update all installed packages
- yum list installed # Show all currently installed packages
dnf - Modern package manager used in newer RPM-based distributions.
- Examples:
- sudo dnf install nodejs # Install Node.js
- sudo dnf upgrade --refresh # Refresh metadata and upgrade all packages
- dnf search python3 # Search for packages matching python3
rpm - Low-level tool for managing RPM packages directly.
- Examples:
- sudo rpm -ivh package.rpm # Install a local RPM package file
- rpm -qa | grep java # List all installed packages containing "java"
- rpm -qi nginx # Show detailed info about an installed package
dpkg - Low-level tool for managing Debian packages directly.
- Examples:
- sudo dpkg -i package.deb # Install a local .deb package file
- dpkg -l | grep python # List installed packages matching "python"
- dpkg -L nginx # Show all files installed by the nginx package
snap - Installs and manages snap packages across supported distributions.
- Examples:
- sudo snap install code --classic # Install VS Code as a snap package
- snap list # Show all installed snap packages
- sudo snap refresh # Update all installed snaps to their latest versions
zypper - Package manager used on openSUSE and SUSE systems.
- Examples:
- sudo zypper install git # Install git on an openSUSE system
- sudo zypper refresh # Refresh all configured repositories
- zypper search docker # Search for packages related to docker

Not every Linux system uses all of these, but knowing the distro family you use will help you to know which commands to use.

Start Learning

Start learning the commands in small groups:

Start with navigation: pwd, ls, cd.
Then learn file handling: touch, cp, mv, rm.
Add file reading and editing: cat, less, nano.
Move into process and system checks: ps, top, df, free.
Finish with network basics: ip, ping, ssh.

Th-Th-That's all, folks!

Linux becomes much easier once you stop seeing it as a wall of commands and start seeing it as a set of tools for clear tasks. This map is a good reminder that the terminal is not about complexity for the sake of complexity. It is about control, speed, and understanding what your system is doing.

You do not need to master every command today. Learn the ones that solve the problems in front of you. Use them often. Repeat them in real situations. That is how confidence grows.

And after a while, the terminal stops feeling technical and starts feeling natural.

Apache Kafka tutorial – What is Apache Kafka?

Altair Lage — Tue, 14 Apr 2026 22:18:13 +0000

Apache Kafka is an open-source distributed event streaming platform used by thousands of companies to publish, store, and process streams of records in real time. It was originally developed by LinkedIn before moving into the open-source world in early 2011. It was built because LinkedIn needed a better way to handle massive amounts of data to track site events, like page views and user clicks, and to gather all their log data in one place.

Kafka is designed for distributed high throughput systems. Kafka tends to work very well as a replacement for a more traditional message broker. In comparison to other messaging systems, Kafka has better throughput, built-in partitioning, replication and inherent fault-tolerance, which makes it a good fit for large-scale message processing applications.
In this tutorial, we are going to dive into what Kafka actually is and walk through the most common definitions you'll run into when working with it.

Who is using Kafka?

Twitter uses Kafka to power its mobile application performance management and analytics platform. In 2015, this system was already handling around five billion sessions per day.
Netflix relies on Kafka as the messaging backbone for its Keystone pipeline, a unified platform for publishing, collecting, and routing events across both batch and stream processing. As of 2016, Keystone included more than 4,000 brokers running entirely in the cloud, handling over 700 billion events every single day.
Tumblr uses Kafka as a core part of its event processing pipeline. In 2012, it was already capturing up to 500 million page views per day through this system.
Square uses Kafka as its central data bus. It supports stream processing, website activity tracking, metrics collection, monitoring, log aggregation, real-time analytics, and complex event processing.
Pinterest runs Kafka as part of its real-time advertising platform. The system includes over 100 clusters and more than 2,000 brokers deployed on AWS. It processes more than 800 billion events per day, with peaks reaching up to 15 million events per second.
Uber is one of the most well-known Kafka adopters. The company processes over a trillion events per day using Kafka, mainly for data ingestion, event stream processing, database changelogs, log aggregation, and general-purpose publish-subscribe messaging.

Kafka architecture

Kafka is a publish/subscribe system built around event data. It involves four main actors: producers, consumers, brokers, and ZooKeeper nodes.

Broker nodes: These handle most of the I/O work and are responsible for durable data storage within the cluster. A Kafka broker receives messages from producers and writes them to disk, organizing them by partition and indexing them with a unique offset. Consumers can then fetch messages by topic, partition, and offset. Brokers also work together to form a Kafka cluster, sharing information either directly or indirectly through ZooKeeper.
ZooKeeper nodes: Kafka relies on ZooKeeper to manage the overall state of the cluster. It keeps track of broker health, maintains metadata about topics, and helps coordinate cluster operations.
Producers: Producers are responsible for sending messages to Kafka brokers, typically organized by topic.
Consumers: Consumers are client applications that read messages from Kafka topics.

In the diagram above, a topic is divided into three partitions:

Partition 1 contains two offsets: 0 and 1
Partition 2 contains four offsets: 0, 1, 2, and 3
Partition 3 contains a single offset: 0

A replica is simply a copy of a partition, including the same data, offsets, and partition ID.

Now, consider a scenario where the replication factor is set to 3. Kafka will create three identical copies of each partition and distribute them across the cluster to ensure availability and fault tolerance. In the example shown, the replication factor is 1, meaning each partition has only one copy.

To balance load across the cluster, partitions are distributed among brokers, and each broker can store one or more partitions. At the same time, multiple producers and consumers can publish and read messages concurrently, making Kafka highly scalable and efficient.

Kafka component concepts

Broker nodes

A broker acts as the middle layer between producers and consumers, helping move data across the system. It stores messages in partitions and ensures that data is safely persisted for a configurable amount of time. This design also helps Kafka handle failure scenarios without losing data.

In Kafka, a broker is a key unit of scalability. By increasing the number of brokers in a cluster, you can improve I/O throughput, availability, and overall durability. Brokers also coordinate with each other and communicate with ZooKeeper to maintain cluster state and consistency.

In most setups, each server runs a single broker. While it is technically possible to run multiple brokers on the same server, this is generally not recommended in production environments.

Topic

A Kafka Topic is where messages sent by producers are stored. Topics are split into partitions, and each topic has at least one partition. Each partition contains messages in an immutable and ordered sequence. Once a message is written, it cannot be changed. A partition is internally implemented as a set of segment files of equal sizes. So we can imagine a topic as a logical aggregation of partitions. By splitting a topic into multiple partitions, Kafka can process data in parallel, which improves performance and scalability.

When a producer publish a record, the producer automatically select a partition based on the record’s key. A producer will digest the byte content of the key using a hash function (Kafka uses murmur2 for this purpose).

The process works like this:

The key is hashed using murmur2.
The highest-order bit is masked to ensure the result is a positive integer.
The final partition number value is calculated using modulo with the number of partitions. This process determines the target partition for the record.

As a result, records with the same key will always be routed to the same partition, ensuring ordering for that key. However, if the number of partitions changes, the hash result will also change. This means Kafka may assign the same key to a different partition after the change.

The topic structure, contents, and how producers interact with partitions are depicted below.

This is the nature of hashing: Records with different hashes may still end up in the same partition due to hash collisions.

Consumer groups and load balancing

Kafka’s producer-topic-consumer topology adheres to a flexible and highly scalable model. A multipoint-to-multipoint model, which means multiple producers and multiple consumers can interact with the same topic at the same time.

A consumer is a process (or thread) that attaches to a Kafka cluster using a client library. When multiple consumers subscribe to a topic and belong to the same consumer group, Kafka distributes the partitions among the consumer in the group. Each consumer reads from a different subset of partitions in the topic.

Let’s walk through an example.

Suppose we have a topic called T1 with four partitions. If we create a single consumer C1 in group G1 and subscribe it to topic T1, then C1 will receive messages from all four partitions.

But, if we add a second consumer C2 to the same group G1, Kafka will rebalance the partitions. Each consumer will now read from two partitions. For example:

C1 reads from partitions 0 and 2
C2 reads from partitions 1 and 3

If we keep adding more consumers to the same group G1, and the number of consumers exceeds the number of partitions, some consumers will remain idle. This happens because Kafka guarantees that each partition is assigned to only one consumer within a group.

Now, if a new consumer group G2 is introduced, with a single consumer. This consumer will receive all messages from topic T1, completely independent of what group G1 is doing.

If G2 has multiple consumers, Kafka will again split the partitions among them, just like it does for G1. However, the key point is that each consumer group receives the full stream of messages, regardless of other groups.

This works because of how Kafka manages offsets:

Offsets are managed by consumers, but they are stored in a special Kafka topic called __consumer_offsets.
Offsets are tracked per (consumer group, topic, partition) combination.
This combination is used as the key when storing offsets, which allows Kafka to:
- Keep offsets organized in the same partition of the __consumer_offsets topic.
- Use log compaction to remove outdated offset records.
- Efficiently manage progress tracking for each consumer group.

By default, the __consumer_offsets topic is configured with 50 partitions.

Th-th-that's all, folks!

Apache Kafka is much more than just a messaging system. It is a distributed event streaming platform designed to handle large-scale data with high throughput, reliability, and scalability.

The key takeaway is simple: Kafka is built for movement, durability, and scalability of data. Once you understand these core concepts, everything else, from stream processing to real-time analytics, becomes much easier to reason about.

If you're starting with Kafka, these fundamentals are the base for everything you will build on top of it.

Essential AWS services every engineer should know

Altair Lage — Mon, 13 Apr 2026 19:48:38 +0000

When we start learning AWS, the number of services feels overwhelming. But we don't need to learn everything at once. A strong foundation usually starts with a few key groups, like compute, storage, databases, networking, security, monitoring, etc.

This chart is a simple way to see how the AWS ecosystem is organized. It brings together core services in one place.

My advice is to start with the basics. Then connect the dots as long as you need.

A practical start could look like this:

Create and manage your networking with VPC.
Run apps with EC2, Lambda, or ECS.
Store data in S3.
Store your servers data with EBS, or EFS.
Use RDS and Aurora for your relational databases.
Refer DynamoDB for your NoSQL DBs.
Secure access with IAM, KMS, and Secrets Manager.
Monitor everything with CloudWatch, and troubleshoot with CloudTrail.
Automate delivery with CodePipeline, CodeBuild, and CodeDeploy.
Make your apps to talk with each other with SQS and SNS.
Manage your resources with Infrastructure as Code with CloudFormation.

AWS gets much easier when you stop seeing isolated services and start seeing how they work together.

DevOps Engineer Routine

Altair Lage — Mon, 13 Apr 2026 14:45:05 +0000

Every DevOps knows this feeling

On one side, there’s:

Infrastructure melting down at 2 AM.
CI/CD pipelines stuck in "pending" forever.
Mysterious server crashes with zero warning.

On the other side:

"Is it safe to push to production today?".
“Why did the app get so slow all of a sudden?”.
“But everything was fine in staging…”.

That’s the job, really. DevOps isn't about learning and using the latest fashion tools.
It's about staying calm under fire, bringing order to chaos, and designing systems resilient enough to handle reality, not just theory.

What really helps in practice:

Monitoring that raises the flag before users feel the impact.
CI/CD pipelines clean and simple enough for anyone to follow and trust.
Automation for repetitive work, so people spend time fixing problems instead of clicking through tasks.
Clear ownership and documentation that stays useful over time (instead of relying on tribal knowledge).
Blameless postmortems that turn outages and mistakes into concrete improvement.

If you're a DevOps, SRE, Cloud, or Platform Engineer, you already know this feeling. We all spend time dealing with fires. But the real goal is not just becoming better at reacting. It’s designing systems where fewer fires happen at all.

New tutorial, folks!

Altair Lage — Mon, 30 Mar 2026 17:38:18 +0000

Altair Lage

Mar 30

RabbitMQ Management Interface

#webdev #devops #programming #tutorial

Comments

12 min read

RabbitMQ Management Interface

Altair Lage — Mon, 30 Mar 2026 17:36:39 +0000

In my last articles, How to install RabbitMQ and Unraveling RabbitMQ we installed and deep dived into RabbitMQ, one of the most popular and mature message brokers in the open-source ecosystem. Its capability to handle queues, routes, and message publish/subscribe functionality is essential to ensure asynchronous communication, resilience, and scalability in modern applications.

In this article, I present you the RabbitMQ Management interface. This is a user-friendly web interface that allows operators to monitor and configure the RabbitMQ Server from a web browser. This is a practical guide on how to get the most out of this web interface, which transforms broker management into a transparent and controllable task.

This article will guide you to:

Access and navigate the management dashboard.
Monitor crucial metrics, such as message rates, node status, and overall system health.
Manage and interact with essential entities like Connections, Channels, Exchanges, and Queues.
Use the administrative tools to configure Virtual Hosts (VHosts), Users, and Permissions.

The Management interface

After starting RabbitMQ, you can monitor and manage it from the administration console. The web interface operates on port 15672 and you can access it by the URL: http://localhost:15672/ . Use the defaultcredentials: username: guest and password: guest to login for the first time.

It is strongly recommended that these default credentials be modified immediately in any non-development environment.

From RabbitMQ Management it is possible to:

Manage exchanges, queues, bindings, users, virtual hosts, policies, runtime parameters and user permissions.
Export and import schema (vhosts, users, permissions, queues, exchanges, bindings, parameters, policies).
Monitor queue length, message rates, resource usage of queue, node GC activity, data rates of client connections, and more.
Force close client connections, purge queues.
Send and receive messages for debugging.
Monitor node resource use: sockets and file descriptors, memory usage breakdown, available disk space, and bandwidth usage on inter-node communication links.

The overview page

After logging in, the Overview page is the default landing screen, presenting a real-time assessment of the broker's operational state and performance metrics. You will see the following stats:

The Overview page displays 2 charts: The current Queued Messages volume and the Messages Rate.
The time series displayed in these charts can be adjusted (e.g., last minute, last hour) for historical analysis. Information about all the different states of the messages can be found by pressing ? link.

Queued messages: This graph shows the total number of messages in all Queues. These statistics are essential to identify message backlogs and potential throughput limitations.

Ready: Indicates the number of messages that are currently available for delivery and consumption by connected consumers.
Unacked: The number of messages that server is waiting for confirmation. Represents messages that have been delivered to a consumer but the server has not yet received a positive acknowledgment (ACK). These messages are retained for potential redelivery, ensuring message reliability.
Total: The total number of messages queued in all Queues, calculated as the sum of Ready and Unacked messages.

Messages rate: The chart shows the rate of processing messages, typically measured in messages per second. This is a primary indicator of system performance and workload.

Publish: Displays the rate at which producers are submitting new messages to the server/broker.
Publisher confirm: Indicates the rate at which the server is confirming receipt of messages back to the producers. Applicable when the publisher confirm mechanism is used.
Deliver (manual ack) / Deliver (auto ack): Displays the delivery rate of messages from queues to consumers, segregated based on whether the consumer requires manual acknowledgment (manual ack) or utilizes automatic acknowledgment (auto ack).
Get (manual ack) / Get (auto ack): Displays the rate at which consumers are actively fetching messages from the queue using the basic.get method, also categorized by acknowledgment mode.
Redelivered: The rate at which the server/broker is resending messages to consumers, typically following connection interruptions or negative acknowledgments (NACKs).
Disk read/write: The frequency of disk I/O operations (reads and writes) executed by the broker, primarily related to managing persistent messages and durable queue data.

Global Count: Static panel that provides instantaneous totals for key operational entities. It summarizes the count of all active Connections, Channels, Exchanges, Queues, and Consumers across ALL virtual hosts, offering a rapid assessment of current resource utilization.

Nodes

Provides critical system-level details for each Node operating within your RabbitMQ cluster. A cluster is essentially a logical grouping of RabbitMQ server instances running on separate machines or processes. Monitoring these metrics is vital for capacity planning and troubleshooting performance issues across the cluster.

Here you can observe key resource utilization statistics:

Memory: Displays the amount of system memory currently consumed by the node.
Erlang Processes: Shows the total number of underlying Erlang processes running on the node. RabbitMQ is built on Erlang, and managing this count is essential as there is a finite limit to the number of processes a node can handle.
Disk Space: Indicates the remaining available disk space on the host machine. If disk space drops below a defined watermark, the broker may block producers to prevent data loss.
Uptime: Displays the duration since the RabbitMQ node was last started.

Churn statistics

Displays the rate of new (created) or closed (closed) connections, channels, and queues.
"Churn" refers to the velocity at which these resources are instantiated and destroyed in the broker. High churn rates can sometimes indicate issues with client connection management or rapid scaling events.

This panel displays the rate (per second) of:

Connections: New client connections being opened or existing connections being closed.
Channels: Channels being created or shut down within connections.
Queues: Queues being created or deleted.

Ports and contexts

This simple but important section serves as a reference for network configuration. Here you can find the network interfaces and listening ports configured for various protocols that RabbitMQ uses to communicate with clients and other nodes.

You can quickly verify the ports used for:

AMQP (standard client connections)
HTTP (management interface)
Inter-node communication (clustering)

Import export definitions

It is possible to import and export definitions to configure all information of the RabbitMQ broker. This functionality is crucial for configuration management, backup, and restoration. It allows the complete definition of the RabbitMQ broker's state to be exported or imported as a single artifact.

Exporting the definitions, we get a JSON file representing the broker (RabbitMQ). This can be used to restore Exchange, Queue, virtual host, policy, user, etc. This feature can be used as a backup. Every time you change the configuration, you can keep the old settings to restore when needed.

When definitions are exported, we get a JSON file that encapsulates the entire configuration of the broker. This file includes all defined Exchanges, Queues, Virtual Hosts, Policies, Users, and Permissions. This feature can serve as backup mechanism and for replicating configurations across development, staging, and production environments. It ensures consistency and allows quick rollback to previous settings state in case of issues.

Connections

A RabbitMQ Connection is a TCP connection between the application and the RabbitMQ broker. This connection acts as the secure and stable pipe through which all messaging traffic flows. When the client disconnects for any reasons, or a system failure occurs, the underlying TCP connection will be terminated and closed by the broker.

The Connections page provides a list of active connection to the RabbitMQ server.

Key details displayed for each connection include:

Overview: Displays essential metadata, such as the client IP address (source), the username used for authentication, and the current Connection Status (e.g., running, blocked).
Channels: Indicates the current number of Channels that have been opened and are actively running within this specific connection.
SSL/TLS: A flag indicating whether the connection is utilizing SSL/TLS encryption for secure data transmission.

Clicking on one of the connections, you will get an overview of that specific connection, and view channels in connection and data rate. You can see the Client properties and close the connection if you want (Force Close).

View Channels: The list of all active channels currently multiplexed over this connection.
Data Rate: The current inbound and outbound message and byte traffic rates associated with the connection.
Client Properties: Metadata provided by the connecting application, such as the application name, version, and client library used.
Force Close: Manually terminate the connection. This administrative action is useful for troubleshooting unresponsive clients or managing resource utilization.

Channels

A RabbitMQ Channel is a virtual connection inside a connection. It reuses a connection, to avoid the need to reauthorize and open a new TCP stream. When messages are published or consumed, it is done over a channel. Many channels can be established within a single connection.

The Channels page displays information about all current Channels: Displays the username the user is associated with the channel, connection status, confirmation, Message exchange rate, etc..

If you click on one of the Channels, you will get a detailed overview of that Channel.

Exchanges

The RabbitMQ Exchange entity is in charge of applying routing rules for messages, making sure that messages are reaching their final destination. In other words, the exchange ensures that the received message ends up in the correct queues. Which queue the message ends up in depends on the rules defined by the exchange type. A queue needs to be bound to at least one exchange to be able to receive messages.

Routing rules include:

Direct (point-to-point): a message goes to the queue(s) with the binding key that exactly matches the routing key of the message.
Topic (publish-subscribe): route messages to queues based on wildcard matches between the routing key and the routing pattern, which is specified by the queue binding.
fanout (multicast): ignores routing key and broadcast a message to all queues.
header exchanges: similar to topic exchanges, but route messages based on header values instead of routing keys.

All Exchanges can be listed from the Exchange tab.

Name: displays the name of the Exhange created.
Type: is the type of Exchange like direct, topic, fanout and header.
Feature: displays parameters for Exchange (eg: D is durable, and AD is auto-delete).
Message rate in/out: Rate of processing incoming and outgoing Messages.

In this list there are several Exchange amq.* and Default Exchange (default exchange unnamed), which are created by default.

It is possible to add a new Exchange in this page:

By clicking on the Exchange name, a detailed page about the Exchange is displayed.

You can view and add biding for the Exchange.

Bindings

The Binding is the fundamental relationship mechanism in RabbitMQ. it defines the routing logic between an Exchange and a Queue (or between two Exchanges). Without a binding, a queue cannot receive messages from any exchange.

Essentially, a binding is a directive that tells an exchange how to send data to a queue or another exchange. The binding also contains routing keys and arguments that customize message passing:

Source: The Exchange that receives the message.
Destination: The Queue (or another Exchange) where the message is sent.
Routing Key: An optional parameter supplied by the producer, which the exchange uses to match against the binding.

In the Management Interface, bindings are configured on the detail page of the Exchange or Queue, allowing the operator to define precisely which messages flow to which destinations based on the Exchange's type (direct, topic, etc.).

You can also publish a message to Exchange in this page:

Queues

A RabbitMQ Queue is the central storage component, an ordered sequence of items, in this case, messages waiting for consumers to process them. The queue exists within the broker context (RabbitMQ server or Cluster).
Queues have different parameters and arguments depending on how they were created, which determine their behavior and resilience:

Name: The unique identifier of the created queue.
Features: Displays the primary configuration attributes that define the queue's persistence and lifecycle:
- Durable Queues: Indicated by D. If the RabbitMQ node is restarted, the queue and any persistent messages within it will be recovered. This is essential to guarantee data is not lost in case of failure.
- Auto-delete Queues: Indicated by AD. The queue will be automatically deleted by the broker as soon as its last consumer disconnects or is canceled (e.g., when the TCP connection with the server is lost or the channel is closed). This is useful for temporary queues.
Message Ready: Displays the number of messages currently available to be delivered to consumers.
Message Unacked: Represents the number of messages that have already been delivered to consumers, but for which the server has not yet received an acknowledgment of processing (ACK). These messages remain in the queue and will be redelivered if the consumer fails.
Message Total: The total number of messages currently queued. This is the sum of Ready and Unacked messages.
Message Rate in/out: The real-time processing rates. In shows the speed at which messages are arriving at the queue (publish rate), while Out shows the speed at which messages are being processed/delivered to consumers (delivery rate).

A new Queue can be added in this same page:

By clicking on the Queue name, a Queue detail page will be displayed:

A Consumer is an application (or application instance) that consumes messages. The consumer sub page displays consumers/channels that are connected to the Queue. you can view and add constraints for Queue:

It is also possible to publish a message to the Queue:

A Queue can be deleted by clicking the Delete Queue button. You can aslo delete all Messages in the Queue by clicking the Purge Messages button:

Admin page

From the Admin page, we can add m users, change user permissions, set up vhosts, policies, limit the number of connections or change the cluster name.

Click on the Virtual Hosts menu on the left to view a list or add new Virtual Hosts:

Policy can be added or updated in the Policies sub-menu on the left:

Similarly click on the Limits sub-menu to limit the number of Connections, Queues of a Virtual Host.

By default, RabbitMQ names the cluster rabbit@, and we can rename it in the cluster sub-menu.

This article mainly introduces you to the features that we can use from RabbitMQ Management Interface.

Virtual Hosts (VHosts)

Virtual Hosts (VHosts) are the primary administrative partitions within a single RabbitMQ broker. They provide a way to group and isolate user permissions, exchanges, queues, and bindings. From a multi-tenant or multi-application perspective, a VHost functions like a separate, logical broker instance, ensuring that resources and messaging data from one application environment (e.g., 'production' or 'development') cannot interfere with another.

Advanced Debugging Tools

Beyond the standard Overview metrics, the Management Interface provides specialized tools for deep-level diagnostics, particularly useful when troubleshooting complex routing or delivery issues.

Message Tracing (Tracer)

The Tracer is a powerful debugging feature used to inspect the path messages take through the broker. When enabled, the Tracer logs every message event, including when a message is published, routed by an exchange, and delivered to a queue.

Usage: Operators enable tracing on a specific virtual host to capture detailed logs of all message activity within that environment.
Benefit: This allows developers to definitively confirm if a message arrived at the correct queue, or if it was dropped due to an incorrect binding or routing key.

Alarms and Health Checks

The Alarms sub-menu, found under the Admin section, provides a centralized view of system-critical alerts. RabbitMQ nodes trigger alarms when they encounter severe resource constraints, such as:

Disk Alarm: Triggered if available disk space drops below the configured watermark, preventing the writing of persistent messages.
Memory Alarm: Triggered if the node exceeds a pre-set memory utilization limit.

Monitoring these alarms is crucial for preemptive capacity management and avoiding producer throttling, when the broker blocks incoming messages to prevent a more severe failure.

That's all foks!

The RabbitMQ Management Web Interface is not just an optional tool. It is an important component for any operator or developer working with asynchronous systems. The interface provides complete and real-time visibility into the operational core of the broker, making management tasks that were once, complex command-line operations, an intuitive web console action.

Mastering this interface allows you to manage the messaging infrastructure, ensuring high availability and message reliability. Always remember to prioritize security by managing user permissions and regularly updating credentials, transforming your RabbitMQ instance from a simple message relay into a resilient and scalable communication hub.

Learn how to develop like a pro for free

Altair Lage — Fri, 27 Mar 2026 17:59:18 +0000

There is no excuse nowadays to learn Software development. It is no longer a privilege, but accessible for everyone. The following cheat sheet is a straight source of 100% free tools and platforms to study the main market technologies and languages.

HTML → https://w3schools.com
CSS → https://codecademy.com
JavaScript → https://freecodecamp.com
React → https://react.dev
Python → https://learnpython.org
Java → https://sololearn.com
PHP → https://php.net
Cybersecurity → https://tryhackme.com
C → https://learn-c.org
C++ → https://learncpp.com
AWS → https://skillbuilder.aws
IA / ML → https://coursera.org
Git → https://learngitbranching.js.org
SQL → https://sqlbolt.com

These websites are excellent free resources for learning everything from the basics to advanced content.

How to install RabbitMQ

Altair Lage — Thu, 19 Mar 2026 12:38:37 +0000

This article is a sequence of my previous RabbitMQ article: Unraveling RabbitMQ: How to Scale Systems with Queues. Check it out to deep dive into the concepts!

RabbitMQ is an open-source message broker that acts as the intermediary between independent and heterogeneous applications, providing systems a common way to communicate. Commonly used in Microservices Architecture, it is a software where queues are defined, to which applications connect in order to transfer messages. The queue-manager software stores the messages until a receiving application connects and takes a message off the queue.

RabbitMQ uses an implementation of Advanced Message Queuing Protocol - AMQP, which supports advanced features such as clustering and complex message routing.

What is AMQP?

AMQP (Advanced Message Queuing Protocol) is a powerful, open-standard application layer protocol for message-oriented middleware. It basically defines how a system can exchange messages. Its main purpose is to provide a standardized way for different systems to exchange messages asynchronously, regardless of the operating system, programming language, or message broker implementation being used.
The protocol defines a set of rules and capabilities that systems must follow. By implementing this specification, AMQP ensures interoperability between different vendors' messaging brokers and client applications.

Why should you use RabbitMQ?

When an application is broken down into many small, independent services, or "microservices" as called in Mircroservices Architecture, they need a way to talk to each other. There are two main ways for them to communicate:

1. Synchronous Communication
This is like calling someone on the phone.

How it works: One microservice calls another microservice directly, then stops and waits for an immediate response.
Example: The Request-Response pattern (like using HTTP). A service asks, "What is the price?" and waits for the answer before doing anything else.
The Problem (Coupling): This creates a strong dependency, or coupling, between the services. If the second service is slow, busy, or completely down, the first service also stops working or slows down. It ties the services together.
When to use it: When you absolutely need an immediate answer to proceed, like checking a user's login credentials.

2. Asynchronous Communication
This is like sending an email or a text message.

How it works: Instead of calling the service directly, the first service sends a message (a "request") to a central Message Queue (like RabbitMQ). The sending service then immediately goes back to its own work, without waiting.
The Role of RabbitMQ: RabbitMQ acts as this messenger. It reliably holds the message until the correct microservice is ready to pick it up, process it, and deliver the result back later.
The Benefit (Decoupling): This allows services to be loosely coupled. If one service is busy, the messages just queue up, and the sending service doesn't even notice the delay, it keeps running smoothly. This improves resilience, scalability, and performance.
When to use it: For tasks that can happen in the background or take time, such as processing a large payment, sending an email confirmation, or generating a report.

In summary: RabbitMQ enables Asynchronous communication, which is crucial for making microservices reliable, scalable, and independent of each other.

How does RabbitMQ work?

To understand how RabbitMQ works, check the diagram below, which illustrates the journey of a message through an example application, a PDF generation system.

The process happens in four main, simple steps:

The Request (Start): A user on a Website Application triggers a task that should run in the background, such as asking to "Create a PDF."
The Producer Publishes: The Website Application, acting as the PRODUCER, doesn't do the work immediately. Instead, it packages the request (including necessary data like name and email) into a message and Publishes (sends) it to RabbitMQ.
The Routing Inside RabbitMQ:
1. A component called the Exchange receives the message from the Producer.
2. The Exchange's job is to act as a sorter. It uses Routing rules to ensure the message is delivered to the correct Queue (in this diagram, the Message Queue for PDF requests).
3. The Queue securely holds the message, acting as a buffer until a service is available to handle it.
The Consumer Processes:
1. A dedicated background service, called the CONSUMER (the PDF Creator Worker), constantly monitors the Queue.
2. The Consumer retrieves (Consumes) the task message and begins the actual work: creating the PDF.

How to install RabbitMQ using Docker

Using Docker is the easiest and fastest way to get RabbitMQ running on your local machine. This method uses a pre-built image that includes both the RabbitMQ server and its Web Management interface, saving you the hassle of manual installation.

To start RabbitMQ with the management plugin enabled, you need to run a specific docker run command. This command sets up the container, maps the necessary ports, and specifies the RabbitMQ version you want to use.

# For RabbitMQ 3.13 specific version
docker run -it --rm --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3.13-management

# For RabbitMQ 3.8, specific version
# Support timeline: https://www.rabbitmq.com/versions.html
docker run -it --rm --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3.8-management

docker run: The command to create and start a container.
-it: Runs the container in interactive mode and allocates a pseudo-TTY, allowing you to see logs and output.
--rm: Crucial: This automatically removes the container and its file system when it exits. This keeps your system clean.
--name rabbitmq: Assigns the easy-to-read name rabbitmq to your container.
-p 5672:5672: Maps the AMQP Port. This forwards the standard RabbitMQ port inside the container (5672) to the same port on your computer. This port is used by applications to send and receive messages.
-p 15672:15672: Maps the Management Port. This forwards the port for the Web Management interface (15672) to your computer, allowing you to access the dashboard in your browser.
rabbitmq:3.13-management: Specifies the Docker image to use. The -management tag ensures the helpful web interface is included. (You can check the official Docker Hub for other versions like rabbitmq:latest-management).

If you want to see the server status while it's running, open a new terminal window and use this command: docker logs -f rabbitmq

After the container starts (which usually takes only a few seconds), the RabbitMQ Web Management interface will be available.

URL: Access the dashboard at: http://localhost:15672
Default Login: Use the default credentials:
- Username: guest
- Password: guest

On this screen, you can monitor the health of your broker, view the number of active Queues and Exchanges, manage Users, and inspect the flow and volume of messages.

Note: For security reasons, the guest/guest user can only connect from localhost (your machine) by default. For production environments or when deploying to a server, you must create a new administrator user with a strong password.

How to install RabbitMQ on Ubuntu

Installing RabbitMQ on Ubuntu requires two main steps: getting the necessary packages like Erlang (which RabbitMQ is built on) and then installing the RabbitMQ server itself. The official RabbitMQ team provides an easy-to-use package repository for this.

Important: The script below is comprehensive but relies on specific versions and repository settings that can change over time. It is best practice to always check the official RabbitMQ documentation for the absolute latest installation instructions and key fingerprints before running this on a production server.

The following script automates the entire process: installing dependencies, adding the necessary software repositories, importing the security keys, and finally installing Erlang and RabbitMQ Server.

#!/usr/bin/sh

# 1. Install necessary tools (curl, gnupg, etc.)
sudo apt-get install curl gnupg apt-transport-https -y

# 2. Import GPG keys for security verification (RabbitMQ, Erlang, and PackageCloud)
curl -1sLf "https://keys.openpgp.org/vks/v1/by-fingerprint/0A9AF2115F4687BD29803A206B73A36E6026DFCA" | sudo gpg --dearmor | sudo tee /usr/share/keyrings/com.rabbitmq.team.gpg > /dev/null
curl -1sLf "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xf77f1eda57ebb1cc" | sudo gpg --dearmor | sudo tee /usr/share/keyrings/net.launchpad.ppa.rabbitmq.erlang.gpg > /dev/null
curl -1sLf "https://packagecloud.io/rabbitmq/rabbitmq-server/gpgkey" | sudo gpg --dearmor | sudo tee /usr/share/keyrings/io.packagecloud.rabbitmq.gpg > /dev/null

# 3. Add the RabbitMQ and Erlang package repositories to APT sources
sudo tee /etc/apt/sources.list.d/rabbitmq.list <<EOF
## Provides modern Erlang/OTP releases
deb [signed-by=/usr/share/keyrings/net.launchpad.ppa.rabbitmq.erlang.gpg] http://ppa.launchpad.net/rabbitmq/rabbitmq-erlang/ubuntu bionic main
deb-src [signed-by=/usr/share/keyrings/net.launchpad.ppa.rabbitmq.erlang.gpg] http://ppa.launchpad.net/rabbitmq/rabbitmq-erlang/ubuntu bionic main

## Provides RabbitMQ Server
deb [signed-by=/usr/share/keyrings/io.packagecloud.rabbitmq.gpg] https://packagecloud.io/rabbitmq/rabbitmq-server/ubuntu/ bionic main
deb-src [signed-by=/usr/share/keyrings/io.packagecloud.rabbitmq.gpg] https://packagecloud.io/rabbitmq/rabbitmq-server/ubuntu/ bionic main
EOF

# 4. Update package lists
sudo apt-get update -y

# 5. Install Erlang and its components (required by RabbitMQ)
sudo apt-get install -y erlang-base \
                         erlang-asn1 erlang-crypto erlang-eldap erlang-ftp erlang-inets \
                         erlang-mnesia erlang-os-mon erlang-parsetools erlang-public-key \
                         erlang-runtime-tools erlang-snmp erlang-ssl \
                         erlang-syntax-tools erlang-tftp erlang-tools erlang-xmerl

# 6. Install rabbitmq-server
sudo apt-get install rabbitmq-server -y --fix-missing

The steps 1, 2 and 3, install basic tools, import the required GPG security keys, and add the official repositories (one for Erlang and one for RabbitMQ) to your system's package list.

The steps 4, 5, and 5 update the package list and install all the required Erlang components and the RabbitMQ server.

How to install RabbitMQ on RPM-based Linux (RHEL, CentOS Stream, Fedora, Amazon Linux)

If you're using an RPM-based Linux distribution like Red Hat Enterprise Linux (RHEL), CentOS Stream, Fedora, or Amazon Linux 2023, installing RabbitMQ is best done using the official package repositories maintained by the RabbitMQ team.

This method ensures you get the latest stable versions of both Erlang (which RabbitMQ is built on) and the RabbitMQ server itself.

Step 1: Install Dependencies

RabbitMQ requires a few essential packages to manage repositories and fetch software.

# For RHEL/CentOS Stream/Fedora/Amazon Linux
sudo yum install -y curl gnupg

Step 2: Install Erlang/OTP

RabbitMQ is written in Erlang. You must install a compatible, modern version of Erlang/OTP before installing the RabbitMQ server package. The official RabbitMQ team provides a dedicated repository for this.

First, import the GPG key used to verify the authenticity of the Erlang packages:

# Import the Erlang signing key
sudo rpm --import 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xf77f1eda57ebb1cc'

Next, add the repository configuration file to your system. This file tells your package manager (YUM/DNF) where to find the correct Erlang packages:

# Add the Erlang repository file
sudo tee /etc/yum.repos.d/rabbitmq-erlang.repo <<EOF
[rabbitmq-erlang]
name=rabbitmq-erlang
baseurl=https://packagecloud.io/rabbitmq/erlang/el/8/\$basearch
repo_gpgcheck=1
gpgcheck=1
enabled=1
gpgkey=https://packagecloud.io/rabbitmq/erlang/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
EOF

Now, you can install the required Erlang package:

# Install Erlang/OTP
sudo yum install -y erlang

Step 3: Install RabbitMQ Server

With Erlang successfully installed, you can now add and install the RabbitMQ server.

Import the GPG key used to verify the RabbitMQ server packages:

# Import the RabbitMQ signing key
sudo rpm --import 'https://packagecloud.io/rabbitmq/rabbitmq-server/gpgkey'

Add the RabbitMQ server repository configuration file:

# Add the RabbitMQ repository file
sudo tee /etc/yum.repos.d/rabbitmq-server.repo <<EOF
[rabbitmq-server]
name=rabbitmq-server
baseurl=https://packagecloud.io/rabbitmq/rabbitmq-server/el/8/\$basearch
repo_gpgcheck=1
gpgcheck=1
enabled=1
gpgkey=https://packagecloud.io/rabbitmq/rabbitmq-server/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
EOF

Finally, install the RabbitMQ server package.

# Install RabbitMQ Server
sudo yum install -y rabbitmq-server

Step 4: Manage the Service

After installation, you need to start the RabbitMQ service and ensure it starts automatically after a reboot.

Use systemctl to start the service and enable it:

# Start the RabbitMQ service
sudo systemctl start rabbitmq-server

# Enable RabbitMQ to start automatically on boot
sudo systemctl enable rabbitmq-server

You can check the service status to confirm it's running:

# Check the status of the service
sudo systemctl status rabbitmq-server

Just like on Ubuntu, the useful Web Management Plugin is not enabled by default. To get the graphical dashboard (which runs on port 15672), enable the plugin and restart the service:

# Enable the web management plugin
sudo rabbitmq-plugins enable rabbitmq_management

# Restart the service to apply the plugin changes
sudo systemctl restart rabbitmq-server

You can now access the dashboard at http://localhost:15672 using the default credentials: guest/guest.

How to install RabbitMQ admin dashboard in Linux?

By default, RabbitMQ is managed only via the command line. To get the friendly web interface (the Management Plugin), you need to enable it using a simple command:

sudo rabbitmq-plugins enable rabbitmq_management

Once the plugin is enabled, you can access the dashboard in your web browser.

URL: Go to http://localhost:15672
Default Login: Use the default, out-of-the-box credentials:
- Username: guest
- Password: guest

The administration screen allows you to easily monitor the volume of messages (Ready vs. Unacknowledged), check active Connections and Queues, and view server resources like Memory and Disk space.

Configuring RabbitMQ users

To add a user in RabbitMQ you can use web management or command line with the below command:

$ sudo rabbitmqctl add_user your_user your_password
    Adding user "your_user" ...
$ sudo rabbitmqctl set_user_tags your_user administrator
    Setting tags for user "your_user" to [administrator] ...

Or using web management tool:

To change the password for an existing user, you can use the below command:

sudo rabbitmqctl change_password guest guest123@#

Installing RabbitMQ on Windows (Using the Installer)

The easiest and most common way to install RabbitMQ on a Windows system is by using the official Windows Installer (.exe). Remember that Erlang must be installed first, as RabbitMQ is built using the Erlang language.

Step 1: Install Erlang/OTP (The Prerequisite)

RabbitMQ relies entirely on the Erlang platform to run. You must install Erlang before installing RabbitMQ.

Download Erlang: Go to the official Erlang website and download the latest 64-bit installer for Windows.
Run the Installer: Execute the downloaded file. Follow the installation prompts, usually accepting the default options.
- Tip: It is highly recommended to run the installer using an administrative account.

Step 2: Install RabbitMQ Server

Once Erlang is successfully installed, you can install the RabbitMQ server.

Download RabbitMQ: Visit the official RabbitMQ Downloads page and get the latest RabbitMQ Server Windows installer (.exe file).
Run the Installer: Double-click the downloaded file. The installer will install RabbitMQ as a Windows Service and start it automatically using the default configuration.

Step 3: Enable the Web Management Dashboard

By default, RabbitMQ is managed via the command line. To get the graphical web interface, you need to enable the management plugin.

Open Command Prompt (Admin): Search for cmd, right-click, and select "Run as administrator".
Run the Plugin Command: Execute the following command to activate the plugin.
```
rabbitmq-plugins enable rabbitmq_management
```

Restart the Service: The service needs to be restarted for the plugin to take effect.

# Stop the service
rabbitmq-service stop

# Start the service
rabbitmq-service start

Step 4: Access the Dashboard

You can now access the management interface through your web browser.

URL: Go to http://localhost:15672
Default Login: The default username is guest and the password is guest.

This dashboard lets you monitor connections, queues, message rates, and server health.

If you're interested in alternative methods, you can also install RabbitMQ on Windows using the Chocolatey package manager.

This video shows a step-by-step guide on How to install #RabbitMQ on windows 10 step by step.

That's all, folks!

How to Create an SSH Key and configure key-based authenication on your linux server

Altair Lage — Wed, 11 Mar 2026 19:51:14 +0000

Intro

SSH is an encrypted protocol used to communicate with and administer servers. It is very often used to access and manage Linux servers remotely. If you manage Linux systems regularly, you will probably spend a lot of time working in a terminal connected through SSH.

While there are a few different ways to log in to an SSH server, in this guide, I’ll focus on setting up SSH keys. SSH keys provide an extremely secure way to log in to your server. For this reason, this is the method I recommend for all users.

SSH keys are a more secure way to authenticate than passwords. Password-based authentication can be vulnerable to brute-force attacks, but SSH keys rely on cryptographic key pairs that significantly improve the security of server access.
SSH authentication works with a public–private key pair. The private key stays on the client machine and must always remain secret. The public key is placed on the server in the ~/.ssh/authorized_keys file, which allows the server to recognize and authenticate the client.
SSH keys are generated with the ssh-keygen utility. The OpenSSH tool ssh-keygen creates a pair of keys that are usually stored in the ~/.ssh directory (for example, id_rsa and id_rsa.pub).
You can add a passphrase to protect the private key. Encrypting the private key with a passphrase adds an extra layer of security. This means that even if someone gains access to the key file, they still cannot use it without the passphrase.
The public key must be copied to the server for authentication to work. The most common way to do this is with the ssh-copy-id command, which automatically installs the public key in the server’s authorized_keys file. You can also copy the key by piping it through SSH or by adding it manually.
After the public key is installed, you can log in without using a password. The server verifies that the client has the matching private key, and if the verification succeeds, it allows access without asking for the account password.
Once SSH keys are configured, password authentication should be disabled. By editing /etc/ssh/sshd_config and setting PasswordAuthentication no, you reduce the risk of brute-force attacks against the server.
Hardware Security Modules (HSMs) can make SSH keys even more secure. HSMs store private keys inside tamper-resistant hardware, which prevents them from being stolen or exposed, even if the system itself is compromised.

How Do SSH Keys Work?

An SSH server can authenticate clients using several different methods. The most basic one is password authentication. It is simple and widely supported, but it is not the most secure option.

Even though passwords are sent to the server through a secure channel, they are often not long or complex enough to resist some attacks. With the modern computing power and automated scripts, brute-force attacks against password-protected accounts are a reality. There are ways to add extra protection, but SSH keys offer a much more reliable and secure alternative.

SSH key pairs are two cryptographically secure keys that allow a client to authenticate to an SSH server. Each pair is made up of a public key and a private key.

The private key stays on the client machine and must always remain completely secret. If the private key is compromised, an attacker could log in to any server that has the corresponding public key configured, without needing additional authentication. For extra protection, the private key can also be encrypted on disk using a passphrase.

The public key, on the other hand, can be shared freely without causing security issues. During authentication, SSH uses the key pair to prove that the client owns the private key without ever sending the private key over the network. In practice, the client signs a piece of data using the private key, and the server verifies that signature using the public key.

To enable this authentication method, the public key must be uploaded to the remote server you want to access. The key is stored in a special file inside the user account you will use to log in, called ~/.ssh/authorized_keys.

When a client attempts to connect using SSH keys, the server checks whether the client can prove it owns the corresponding private key. If the client successfully proves ownership, the server grants access by starting a shell session or by executing the requested command.

1. Creating SSH Keys

The first step in setting up SSH key authentication for your server is to generate an SSH key pair on your local computer.

To do this, we use a utility called ssh-keygen, which is included in the standard OpenSSH suite of tools. By default, this command generates a 3072-bit RSA key pair.

On your local machine, create the SSH key pair by running the following command:

ssh-keygen

OutputGenerating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):

The utility will then ask you to choose a location where the generated keys should be saved. By default, the keys are stored in the ~/.ssh directory inside your user’s home folder. The private key is named id_rsa, and the matching public key is named id_rsa.pub.

In most cases, it is best to keep the default location. This allows your SSH client to automatically find and use your SSH keys when it tries to authenticate. If you want to store the keys in a different location, you can type the new path now. Otherwise, simply press ENTER to accept the default.

If you have already generated an SSH key pair in the past, you may see a prompt like this:

Output/home/username/.ssh/id_rsa already exists.
Overwrite (y/n)?

If you choose to overwrite the key on disk, you will not be able to authenticate using the previous key anymore. Be very careful when selecting yes, as this is a destructive process that cannot be reversed.

OutputCreated directory '/home/username/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Next, the utility will ask you to enter a passphrase for the key. This is optional and is used to encrypt the private key file stored on your disk. You might wonder what the advantage of using an SSH key is if you still need to type a passphrase. In practice, SSH keys still provide several important security benefits:

The private SSH key (the part that can be protected with a passphrase) is never sent over the network. The passphrase is only used locally to decrypt the key on your machine. Because of this, attackers cannot attempt network-based brute-force attacks against the passphrase.
The private key is stored in a restricted directory. The SSH client will ignore private keys that are not located in secure directories. In addition, the key file itself must have restricted permissions (read and write only for the owner). This prevents other users on the same system from accessing or inspecting your key.
Any attacker trying to crack the private SSH key passphrase must already have local access to your system. In other words, they would already need access to your user account or even the root account. If that happens, the passphrase can still slow them down and prevent immediate access to your other servers. This gives you time to generate a new SSH key pair and remove the compromised key.
Because the private key is never exposed to the network and is protected by strict file permissions, it should never be accessible to anyone except you (and the root user). The passphrase adds another layer of protection in case these safeguards are somehow bypassed.

Adding a passphrase is optional. If you set one, you will need to enter it each time you use the key, unless you are using an SSH agent that stores the decrypted key in memory. In most cases, using a passphrase is recommended. However, if you prefer not to set one, you can simply press ENTER to skip this step.

OutputYour identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:CAjsV9M/tt5skazroTc1ZRGCBz+kGtYUIPhRvvZJYBs username@hostname
The key's randomart image is:
+---[RSA 3072]----+
|o   ..oo.++o ..  |
| o o +o.o.+...   |
|. . + oE.o.o  .  |
| . . oo.B+  .o   |
|  .   .=S.+ +    |
|      . o..*     |
|        .+= o    |
|        .=.+     |
|       .oo+      |
+----[SHA256]-----+

You now have a public and private key that you can use to authenticate. The next step is to place the public key on your server so that you can use SSH key authentication to log in.

2. Copying an SSH Public Key to Your Server

There are several ways to upload your public key to a remote SSH server. The method you choose mainly depends on the tools available on your system and your current server configuration.

All of the methods below achieve the same result. The first method is the simplest and most automated. The methods that follow require a bit more manual. You should only use them if you are unable to use the earlier ones.

Copying Your Public Key Using `ssh-copy-id`

The easiest way to copy your public key to a server is by using a utility called ssh-copy-id. Because it is simple and mostly automated, this is the recommended method when it is available.

The ssh-copy-id tool is included in the OpenSSH packages on many Linux distributions, so it may already be installed on your system. For this method to work, you must currently be able to access the server using password-based SSH authentication.

To use this utility, you need to specify the remote host you want to connect to and the user account that has SSH password access. This is the account where your public SSH key will be copied.

The syntax is:

ssh-copy-id username@remote_host

You may see a message like this:

The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

This message means that your local computer does not yet recognize the remote host. It usually appears the first time you try to connect to a new server. Type yes and press ENTER to continue.

Next, the utility will check your local account for the id_rsa.pub key that we created earlier. Once it finds the key, it will ask you for the password of the remote user’s account:

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
username@203.0.113.1's password:

Type the password (your typing will not appear on the screen for security reasons) and press ENTER. The utility will connect to the remote host using the password you provided. It will then copy the contents of your ~/.ssh/id_rsa.pub key into a file called authorized_keys, located in the ~/.ssh directory of the remote account.

You should see output similar to the following:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'username@203.0.113.1'"
and check to make sure that only the key(s) you wanted were added.

At this point, your id_rsa.pub key has been successfully uploaded to the remote account. You can now move on to the next section.

Copying Your Public Key Using SSH

If ssh-copy-id is not available, but you still have password-based SSH access to your server, you can upload your key using a standard SSH command.

The idea is simple. We display the contents of the public SSH key on our local machine and pipe that output through an SSH connection to the remote server. On the remote side, we make sure the ~/.ssh directory exists for the user account, and then we write the received key into a file called authorized_keys inside that directory.

We use the >> redirect operator so the key is appended to the file instead of replacing its contents. This allows you to add new keys without removing any keys that were previously added.

The complete command looks like this:

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

You may see a message like this:

The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

This message means that your local computer does not yet recognize the remote host. This usually happens the first time you connect to a new server. Type yes and press ENTER to continue.

After that, you will be prompted to enter the password for the account you are trying to connect to:

username@203.0.113.1's password:

After you enter your password, the contents of your id_rsa.pub key will be appended to the authorized_keys file in the remote user’s account.
If the process completes successfully, you can move on to the next section.

Copying Your Public Key Manually

If password-based SSH access to your server is not available, you will need to perform the previous process manually.
In this case, the contents of your id_rsa.pub file must be added to the ~/.ssh/authorized_keys file on the remote machine by another method.

To display the contents of your id_rsa.pub key on your local computer, run the following command:

cat ~/.ssh/id_rsa.pub

You will see the key’s content, which may look something like this:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== username@hostname

Access your remote host using any method that is available to you. For example, you might use a web-based console provided by your infrastructure or hosting provider.

Once you have access to your account on the remote server, make sure the ~/.ssh directory exists. The following command will create the directory if it does not exist, or do nothing if it is already present:

mkdir -p ~/.ssh

Now you can create or update the authorized_keys file inside this directory. Add the contents of your id_rsa.pub file to the end of the authorized_keys file. If the file does not exist yet, it will be created automatically. You can do this with the following command:

echo public_key_string >> ~/.ssh/authorized_keys

In the command above, replace public_key_string with the output from the cat ~/.ssh/id_rsa.pub command that you ran on your local machine. The key should start with something like ssh-rsa AAAA... or a similar prefix.

If everything worked correctly, you can move on to test your new SSH key-based authentication.

3. Authenticating to Your Server Using SSH Keys

If you completed one of the procedures above successfully, you should now be able to log in to the remote host without using the account password.

The process is almost the same as before:

ssh username@remote_host

If this is your first time connecting to this host (if you used the last method above), you may see something like this:

The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

This message means that your local computer does not yet recognize the remote host. Type yes and press ENTER to continue.

If you did not set a passphrase for your private key, you will be logged in immediately. If you did set a passphrase when creating the key, you will be prompted to enter it now. After that, a new shell session will start for your account on the remote server.

If everything works as expected, you can continue to the next step and learn how to further secure your server.

Connecting with a Specific SSH Key

In most situations, the SSH client automatically looks for keys inside the ~/.ssh directory and tries them when connecting to a server. However, sometimes you may want to explicitly specify which key should be used. This is very common when you manage multiple servers or use different keys for different environments.

In these cases, you can pass the private key file directly to the SSH command using the -i option.

Let’s walk through a complete example.

First, generate a new SSH key pair using ssh-keygen. In this example, we will create a key called my_server_key:

ssh-keygen -t rsa -b  3072  -f ~/.ssh/my_server_key

You will see prompts similar to the following:

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

After the command finishes, two files will be created:

~/.ssh/my_server_key → your private key
~/.ssh/my_server_key.pub → your public key

The private key must remain on your local machine and should never be shared.

Next, copy the public key to the server so that the server can recognize your client during authentication. For example:

ssh-copy-id -i ~/.ssh/my_server_key.pub user@your_server_ip

Once the key has been installed in the server’s authorized_keys file, you can connect using the private key by running:

ssh  -i ~/.ssh/my_server_key user@your_server_ip

With this command, SSH will use the specified private key when attempting authentication. If the server finds the matching public key in the authorized_keys file, the login will succeed without asking for the account password.

If your private key is protected with a passphrase, SSH will prompt you to enter it locally in order to unlock the key before the connection is established.

Using the -i option is especially useful when you maintain several keys for different servers, environments, or clients. It gives you full control over which key is used for each connection.

4. Disabling Password Authentication on Your Server

If you were able to log in to your account using SSH without entering a password, then SSH key-based authentication has been successfully configured for your account. However, password authentication is still enabled, which means the server can still be targeted by brute-force attacks.

Before continuing with the steps in this section, make sure that one of the following conditions is true:

SSH key-based authentication is configured for the root account on the server, or preferably
SSH key-based authentication is configured for a user account with sudo privileges (this is the recommended approach).

The next step will disable password-based logins, so it is critical to ensure that you will still have administrative access to the server.

Once you have confirmed this, log in to your remote server using SSH keys, either as root or as a user with sudo privileges. Then open the SSH daemon configuration file:

sudo nano /etc/ssh/sshd_config

Inside the file, look for a directive called PasswordAuthentication. In some cases, this line may be commented out. If it is, remove the # at the beginning of the line and set the value to no.

This change disables the ability to log in through SSH using account passwords:

PasswordAuthentication no

Save the file and close it when you are done. To apply the changes you just made, you need to restart the SSH service.

On most Linux distributions, you can do this with the following command:

sudo systemctl restart ssh

Success!
After completing this step, you’ve successfully transitioned your SSH daemon to only respond to SSH keys.

Th-th-th-that's all, folks!

At this point, SSH key-based authentication should be properly set up on your server. This means you can now log in without typing your account password each time you connect.

From here, you have several directions you can explore next. If you want to deepen your understanding of SSH and learn more about how to work with it, check out the following tutorials:

Unraveling RabbitMQ: How to Scale Systems with Queues

Altair Lage — Thu, 29 Jan 2026 19:42:45 +0000

Why do decoupled and scalable systems need a message broker?

This question guides this entire article, where we explore RabbitMQ, one of the most popular and mature message brokers in the open-source ecosystem. We will explore the fundamental concepts, the benefits that RabbitMQ offers, and in practice, show, through examples and code, how to send and consume messages.

Introduction

Monolithic systems require all modules to “talk” directly to each other, creating strong dependencies and fragility. However, as applications grow and become increasingly distributed, the need to decouple components and services increases. This is why systems based on microservices architecture are growing.

In this type of architecture, a message broker acts as an intermediary between systems or microservices (producers and consumers): it receives messages from those who publish events and messages, and guarantees their delivery to those who consume and process them, in an asynchronous manner, allowing different parts of an application or separate systems to exchange information efficiently, even when they are not available at the same time.

In addition, it helps solve scalability and reliability problems and allows the integration of services developed in different languages.

The RabbitMQ architecture is simple: producers send messages to components called exchanges, which act as routers. The exchanges are configured with specific rules that determine which queues the messages should be sent to. Each queue, in turn, is consumed by one or more consumers, who read and process the messages according to their business logic.

RabbitMQ implements the AMQP (Advanced Message Queuing Protocol) protocol, is written in Erlang and adopts a multithreaded architecture, which allows high concurrency.

The management interface makes the tool attractive for simple maintenance and monitoring of queues, messages and connections.

Usage Examples

One of the main practical applications of RabbitMQ is in e-commerce order processing. It is also widely used in system integration in various sectors, such as logistics, transport, and billing. It allows heterogeneous systems to share data reliably and in an organized manner, even in highly complex scenarios.

Imagine an online shopping scenario. When an order is placed, a message is sent to a distribution queue, where the service responsible for stock consumes it and confirms the product's availability. Another message can be sent to the transport queue, where the logistics system organizes delivery. Simultaneously, a message is processed in the billing queue, generating the invoice. This efficient and asynchronous organization avoids delays and promotes greater flexibility in communication between systems. The separation into queues ensures that each service works independently and scalably.

Asynchronous Nature

RabbitMQ uses an asynchronous pattern, allowing messages to be processed independently of the consumer's execution time. This means that producers can publish messages without having to wait for consumers to process them immediately. This approach decouples systems, ensuring that the data flow continues to flow even when consumers are temporarily unavailable or dealing with high workloads.

This operating model is ideal for distributed systems, allowing scalability, flexibility, and resilience in message processing. With the ability to organize and prioritize message traffic, RabbitMQ becomes an assertive solution for implementing asynchronous architectures in various types of applications.

Benefits of RabbitMQ

Decoupling between components and systems: the producer does not directly know the consumer. This facilitates the maintenance and evolution of the system, as new consumers can be added without changing who produces the messages.
Resilience and fault tolerance: messages can be stored persistently. If a consumer fails, the messages remain in the queue until it or another consumer processes them.
Horizontal scalability: it is possible to add new workers to process messages as demand increases.
Integration of heterogeneous systems: RabbitMQ supports several languages (Python, Java, Ruby, Go, etc.), making it ideal for microservices architectures.
Reliability and performance: delivery confirmation, acknowledgment control, durable queues, and high throughput contribute to making systems robust.
Flexibility: different types of exchanges (direct, topic, fanout, headers) allow for varied routing patterns.
Monitoring and management: the web administration interface provides graphs and statistics of messages, connections, channels, exchanges, and queues, facilitating operations.

Fundamental Concepts

This section covers the fundamental concepts of RabbitMQ and messaging in general.

Message

RabbitMQ is a message-queueing software, meaning a message is the information to be queued and sent to the consumer service. A message can include any type of information. For example, it can contain information about a process or task that must be started in another application (which may even be on another server), a JSON with some system entity data, or it can just be a simple text message.

Producer

In the RabbitMQ context, a Producer is the system or application responsible for creating and sending messages to the broker in an exchange. It acts as the starting point in the messaging flow, generating information that needs to be processed or shared by other systems or services.

Producers do not interact directly with the queues where messages are stored. Instead, they send messages to the exchanges, which have the function of routing them to the appropriate queues based on the configured routing rules.

In an e-commerce application, for example, the system responsible for registering new orders acts as a producer, sending messages to an exchange. These messages may contain order information, such as the ID, purchased items, and customer data. The exchange then routes these messages to specific queues, where they will be consumed by services, such as stock control, billing, and logistics, for example.

The producer's role is fundamental, as it initiates the communication process, ensuring that messages are delivered to RabbitMQ for later processing by consumers. This structure allows producers to focus only on creating and sending messages, while RabbitMQ manages the entire messaging flow.

Consumer

Consumers are the systems or applications responsible for consuming messages from queues. They act as the recipients of messages sent by producers and stored by the broker, processing the data according to the necessary business logic.

Consumers connect to specific queues and read the available messages asynchronously, or on demand, depending on the configuration. This flexibility allows the consumer to process messages at their own pace, ensuring that the system works efficiently even in high-load scenarios.

For example, in an e-commerce application, a consumer can be responsible for reading messages from an order queue and, based on this information, performing tasks such as updating inventory, generating an invoice, or triggering the shipping system.

Consumers transform the messages stored in the queues into concrete actions, allowing RabbitMQ to integrate various systems and ensure fluid communication between them.

It is possible to have multiple consumers competing for messages from the same queue.

Queue

A Queue is the location where messages are temporarily stored until they are consumed. It works as a buffer that ensures that the data sent by producers remains available to consumers, even if they are not ready to process it immediately.

Queues are organized sequentially, ensuring that messages are delivered in the order they were received. In addition, they can be configured with different properties, such as durability (Time-To-Live - TTL), to ensure that messages remain stored even in the event of a system restart, and auto-delete when there are no consumers.

Using e-commerce as an example again, messages related to new orders can be stored in a specific queue until they are consumed by stock control or payment processing services. This structure allows each consumer to process messages at their own pace, without directly depending on the producers' execution time.

Exchange

It is the entity responsible for routing messages to one or more queues. The type of exchange determines how the message will be routed.

The direction of messages by an Exchange is essential to organize the message flow in distributed systems, allowing different types of data or events to be directed to the appropriate services.

For example, in a logistics application, an exchange can receive messages from a producer that reports package shipping events and status updates. Based on the configured rules, the exchange can route them to different queues: one queue for the transport service and another for the tracking system.

There are several types of exchanges:

Direct exchange: Routing based on an exact routing key. Useful for delivering a message to a specific queue.
Topic exchange: Uses wildcards in the routing key to match patterns. The character * represents one word and # represents zero or more words.
Fanout exchange: Ignores the routing key and sends the message to all queues bound to the exchange. Excellent for disseminating real-time events.
Headers exchange: Routing based on attributes defined in the message headers, not on the routing key.

Routing keys and bindings

The routing key is a string that the producer sends along with the message. The exchange uses this key to decide which queue to deliver the message to. A binding connects a queue to an exchange and defines the routing rule, for example: the logs.error queue can be associated with a log.error routing key. In a topic exchange, you can use log.* to receive all logs of a certain type and log.# to receive all logs.

In other words:

Binding: Bindings are rules that exchanges use (among other things) to route messages to queues.
Routing key: A key that the exchange uses to decide how to route the message to the queues. Think of the routing key as an address for the message.

Users

It is possible to connect to RabbitMQ with a specific username and password. Users can have associated permissions such as read, write, and configuration privileges within the instance (read, write, and configure). Users can also be given permissions for specific virtual hosts.

For production environments, delete the default user (guest)!.

The default user can only connect from localhost, as it has known credentials. Instead of enabling remote connections, consider creating a separate user with administrative permissions and a strong password. It is recommended to use a separate user per application. For example, if you have a mobile application, a web application, and a data aggregation system, create 3 separate users. This facilitates several things:

Correlate client connections with applications.
Use fine-grained permissions.
Credential renewal - roll-over (for example, periodically or in case of a security breach).

Vhost

RabbitMQ is a multi-tenant system: connections, exchanges, queues, bindings, user permissions, policies and other elements belong to virtual hosts (vhosts), logical groups of entities.

Virtual hosts provide logical grouping and separation of resources. Users can have different permissions for different vhosts, and queues and exchanges can be created to exist only in one vhost.

A virtual host has a name. When a client connects to RabbitMQ, it specifies a vhost name to connect to. If authentication is successful and the provided username has permissions for the vhost, the connection will be established.

Communication Patterns

In addition to the simple work queue pattern, where several instances process tasks concurrently, there are also other patterns:

Pub/Sub (publish/subscribe): with the fanout exchange, the same message is delivered to all consumers, useful for notification and broadcast events.
Work queues: when several instances consume from the same queue, improving task distribution.
RPC (request/reply): a client sends a message requesting a result and waits for the response in the queue indicated in the reply_to header. The correlation is done by a correlation_id.

Installation and Configuration

The simplest way to run RabbitMQ locally is by using Docker. Follow these steps to provision a local RabbitMQ container (run in a terminal with Docker installed):


# 1. Download the official image with the management plugin
$  docker pull rabbitmq:3.13-management

# 2. Start the container with the default ports (5672 for AMQP and 15672 for the web interface)
$  docker run -d --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3.13-management

# 3. Check the logs (optional)
$  docker logs -f rabbitmq

After a few seconds, the interface will be available at http://localhost:15672.

The default login is guest/guest. On the administration screen, you can monitor the volume of messages, connections, and server resources.

You can also create new users and configure permissions.

Optional: creating users and queues via script

If you want to automate the creation of queues and users, or avoid using the graphical interface, you can use commands via the HTTP API, as in the examples below:


# Create a user
$  curl  -u  guest:guest  -XPUT  -H  "content-type:application/json"  \
-d '{"password":"admin123","tags":"administrator"}' \
http://localhost:15672/api/users/myadmin

# Create a queue
$  curl  -u  myadmin:admin123  -XPUT  -H  "content-type:application/json"  \
-d '{"durable":true}' \
http://localhost:15672/api/queues/%2F/myqueue

Exploring the Management Interface

The RabbitMQ web interface provides graphs of message rates, queue message statistics (ready, unacknowledged), active connections, open channels, and information about each cluster node, such as memory usage, disks, and processes. The queued messages and message rate graphs are examples of these graphical statistics.

After starting RabbitMQ, we can monitor and manage RabbitMQ from the web interface at port 15672. You can access this page via the following URL: http://localhost:15672/ with the default username and password as guest/guest.

Tabs such as Connections, Channels, Exchanges, Queues and Streams and Admin allow you to manage each resource. The Queues tab, for example, shows all queues, allowing you to configure TTL, view pending messages, and even send messages manually.

Overview

The Overview page displays two graphs: one for Queued Messages and one for the message rate. You can change the period displayed on the graph by pressing the "Last Minute" tab above the graph. Information about all the different message states can be found by pressing the ? tab/button.

Creating a Producer and a Consumer in Python

In this part of the article, we will create two Python programs: a producer that sends messages, and a consumer that receives the messages and prints them to the screen. They are implemented using the pika library for Python. First, make sure you install the library with pip install pika.

For more details and examples in Python, start by accessing the examples in tutorial-one-python and the rabbitmq-tutorials repository.

Producer

In a directory, create a file for the producer RabbitMqProduce.py.


import pika

# Connection settings
def  connect():
    return pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))

# Queue declaration and message sending
def  publish_message(body: str):
    connection = connect()
    channel = connection.channel()

    # Ensures that the queue exists. "durable=True" persists the queue to disk
    channel.queue_declare(queue='hello', durable=True)

    # Publishes the message to the default exchange (""), using the routing_key equal to the queue name
    channel.basic_publish(
        exchange='',
        routing_key='hello',
        body=body,
        properties=pika.BasicProperties(delivery_mode=2) # 2 = persistent
    )

    print(f"[x] Sent: {body}")
    connection.close()

if  __name__ == '__main__':
    publish_message('Hello, RabbitMQ!')

Consumer

In the same directory, create a file for the consumer RabbitMqReceive.py.


import pika

def  connect():
    return pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))

# Callback called when a message arrives
def  callback(ch, method, properties, body):
    print(f"[x] Received: {body.decode()}")

    # Simulates processing
    # When finished, sends ack (acknowledgment of processing)
    ch.basic_ack(delivery_tag=method.delivery_tag)

# Consumption loop
def  start_consumer():
    connection = connect()
    channel = connection.channel()

    # Declares the same queue with durable=True to ensure it exists and is persistent
    channel.queue_declare(queue='hello', durable=True)

    # Qos with prefetch=1 distributes only one message at a time to each worker
    channel.basic_qos(prefetch_count=1)
    channel.basic_consume(queue='hello', on_message_callback=callback)

    print(' [*] Waiting for messages. To exit press CTRL+C')

    channel.start_consuming()

if  __name__ == '__main__':
    start_consumer()

Topic example with topic exchange

The topic pattern allows flexible routing based on patterns. Imagine we have several queues interested in different log levels. We can create a topic type exchange called logs and associate queues with specific bindings:


import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

# Declares a topic type exchange
channel.exchange_declare(exchange='logs', exchange_type='topic', durable=True)

# Declares queue for error logs and associates it with the exchange with binding key "log.error"
channel.queue_declare(queue='error')
channel.queue_bind(exchange='logs', queue='error', routing_key='log.error')

# Declares queue for logs of all levels (with wildcard)
channel.queue_declare(queue='all')
channel.queue_bind(exchange='logs', queue='all', routing_key='log.#')

# Publishes messages
channel.basic_publish(exchange='logs', routing_key='log.error', body='A critical error occurred!')
channel.basic_publish(exchange='logs', routing_key='log.info', body='Important information...')

print('Messages sent.')

connection.close()

In the consumer, just associate the desired queue and process. The error queue will only receive messages with log.error, while the all queue will receive all (log.#). Note that the # character captures zero or more words in the routing key.

Creating a Producer and a Consumer in Java

If your preferred language is Java, this is an example of how to create the same programs: a producer that sends messages, and a consumer that receives the messages and prints them to the screen. They are implemented using the amqp-client library.

First, make sure to install the library in your project. If you use Maven, add to your pom.xml file:

<dependency>
    <groupId>com.rabbitmq</groupId>
    <artifactId>amqp-client</artifactId>
    <version>5.26.0</version>
</dependency>

For more details and examples in Java, start by accessing tutorial-one-java and the rabbitmq-tutorials/java repository.

Producer

In your project, create a producer class RabbitMqProduce.java.

package com.altabuild.rabbitmq;

import com.rabbitmq.client.ConnectionFactory;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.Channel;

import java.nio.charset.StandardCharsets;

public class RabbitMqProduce {
    private final static String QUEUE_NAME = "hello";

    public static void main(String[] argv) throws Exception {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost("localhost");
        try (Connection connection = factory.newConnection();
             Channel channel = connection.createChannel()) {
            channel.queueDeclare(QUEUE_NAME, false, false, false, null);
            String message = "Hello World!";
            channel.basicPublish("", QUEUE_NAME, null, message.getBytes(StandardCharsets.UTF_8));
            System.out.println(" [x] Sent '" + message + "'");
        }
    }
}

Consumer

In your project, create a producer class RabbitMqReceive.java.

package com.altabuild.rabbitmq;

import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
import com.rabbitmq.client.DeliverCallback;
import java.nio.charset.StandardCharsets;

public class RabbitMqReceive {

    private final static String QUEUE_NAME = "hello";

    public static void main(String[] argv) throws Exception {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost("localhost");
        Connection connection = factory.newConnection();
        Channel channel = connection.createChannel();

        channel.queueDeclare(QUEUE_NAME, false, false, false, null);
        System.out.println(" [*] Waiting for messages. To exit press CTRL+C");

        DeliverCallback deliverCallback = (consumerTag, delivery) -> {
            String message = new String(delivery.getBody(), StandardCharsets.UTF_8);
            System.out.println(" [x] Received '" + message + "'");
        };
        channel.basicConsume(QUEUE_NAME, true, deliverCallback, consumerTag -> { });
    }
}

Test Results

In both examples, Java or Python, the behavior of the applications and the result are the same.

First, run the consumer application to start the listening loop. This application keeps running and consuming any message that is posted to the hello queue.

Then, run the producer application. The producer application will create a message with the content [x] Sent: Hello, RabbitMQ!.
Each message sent will be printed to the consumer's console as soon as it is consumed.

The delivery_mode=2 parameter marks the message as persistent, ensuring that it is saved to disk and not just in memory.

It is possible to monitor the hello queue metrics through the RabbitMQ console to monitor performance.

For example, when a message is produced in the queue, it is possible to monitor the number of messages ready for processing:

When consuming messages from a queue, it is possible to monitor the dequeuing of messages in Queued messages:

That's all, folks!

If you've made it this far, you've learned how a message broker is essential for anyone developing distributed systems and microservices, and the concepts involved in this important piece of messaging. RabbitMQ provides robustness, monitoring, and flexibility for complex architectures.
Run RabbitMQ locally, and run the example codes yourself to see its use in practice.

Want to learn even more? I leave you with the following challenges as next steps:

Run the producer made in Python, and the consumer made in Java (or vice versa) to see in practice how completely different systems can be integrated through queues.
Explore the management interface, and check the configurations and models explained at https://www.rabbitmq.com/tutorials.
Implement other patterns such as work queues and RPC.
Test scalability by adding multiple consumers and understanding the behavior when multiple applications consume.

Mastering these concepts will be a differentiator to ensure that your applications are prepared for high volumes of messages and efficiently integrated.

Did you like the introduction? Then try integrating RabbitMQ into a real project to have more experience! The code and step-by-step presented here are just the beginning to explore the full potential of this powerful tool.

Terraform Cheatsheet

Altair Lage — Thu, 29 Jan 2026 15:22:05 +0000

Have you ever worked with Terraform?

For those working in DevOps and Cloud Computing, Terraform can be a very important tool for Infrastructure as Code (IaC).
That’s why I created this cheat sheet with the essential Terraform commands every professional should know by heart.

Basic workflow (most important commands):

Check and Apply (Create/Change resources):

terraform init: Initializes your working directory and configures the backend for new and existing projects.
terraform plan: Generates the execution plan, showing which resources will be created or changed in the infrastructure.
terraform apply: Applies the planned changes to build your infrastructure and deploy the resources.

Check and Manage:

terraform validate: Checks the code for errors to ensure your configuration is syntactically correct.
terraform show & terraform state: Display the current Terraform state in a readable format and allow you to inspect, list, and manipulate resources directly in the state file. Essential for understanding the current state of your infrastructure.

Destroy your deployment:
terraform destroy: Removes all resources managed by Terraform. Be careful with this command! 😄

Command explanations:

terraform init – Initializes the project by downloading providers and configuring the backend.

terraform plan – Shows what will be created, changed, or destroyed before applying.

terraform apply – Applies the changes defined in the Terraform code.

terraform show – Displays the current state or plan in a readable format.

terraform destroy – Removes all resources managed by Terraform.

terraform validate – Validates the syntax and structure of Terraform files.

terraform output – Shows the output values defined in the state.

terraform state – Allows you to inspect and manipulate the state file.

terraform fmt – Formats Terraform files according to the official style.

terraform graph – Generates a graph of dependencies between resources.

terraform import – Imports existing resources into the Terraform state.

terraform refresh – Updates the state with what exists in the real environment.

terraform taint – Marks a resource to be recreated on the next apply.

terraform untaint – Removes the recreation mark from a resource.

That’s all, folks!

I hope this cheat sheet helps you remember the commands and better understand the IaC lifecycle with Terraform.

Terraform #DevOps #IaC #InfrastructureAsCode #CloudComputing #AWS #Azure #TechTips #CheatSheet #DeveloperLife #TechCommunity #Automation #SRE

This is a full guide guys! This will help you to make your Java and Python applications ready for production, to run in Kubernetes or other orchestrators. Hope you like it!

Altair Lage — Thu, 20 Nov 2025 15:26:48 +0000

Dockerizing Java and Python Applications

Altair Lage ・ Nov 20 '25

#python #docker #java #cloud

Forem: Altair Lage

Essential Linux Commands Map

Essential Linux Commands Map

File and Directory Management

File Viewing and Editing

Process Management

System Information

User and Group Management

Network Configuration and Monitoring

Package Management

Start Learning

Th-Th-That's all, folks!

Apache Kafka tutorial – What is Apache Kafka?

Who is using Kafka?

Kafka architecture

Kafka component concepts

Broker nodes

Topic

Consumer groups and load balancing

Th-th-that's all, folks!

Essential AWS services every engineer should know

DevOps Engineer Routine

New tutorial, folks!

RabbitMQ Management Interface

RabbitMQ Management Interface

The Management interface

The overview page

Nodes

Churn statistics

Ports and contexts

Import export definitions

Connections

Channels

Exchanges

Bindings

Queues

Admin page

Virtual Hosts (VHosts)

Advanced Debugging Tools

Message Tracing (Tracer)

Alarms and Health Checks

That's all foks!

Learn how to develop like a pro for free

How to install RabbitMQ

What is AMQP?

Why should you use RabbitMQ?

How does RabbitMQ work?

How to install RabbitMQ using Docker

How to install RabbitMQ on Ubuntu

How to install RabbitMQ on RPM-based Linux (RHEL, CentOS Stream, Fedora, Amazon Linux)

Step 1: Install Dependencies

Step 2: Install Erlang/OTP

Step 3: Install RabbitMQ Server

Step 4: Manage the Service

How to install RabbitMQ admin dashboard in Linux?

Configuring RabbitMQ users

Installing RabbitMQ on Windows (Using the Installer)

Step 1: Install Erlang/OTP (The Prerequisite)

Step 2: Install RabbitMQ Server

Step 3: Enable the Web Management Dashboard

Step 4: Access the Dashboard

How to Create an SSH Key and configure key-based authenication on your linux server

Intro

How Do SSH Keys Work?

1. Creating SSH Keys

2. Copying an SSH Public Key to Your Server

Copying Your Public Key Using ssh-copy-id

Copying Your Public Key Using SSH

Copying Your Public Key Manually

3. Authenticating to Your Server Using SSH Keys

Connecting with a Specific SSH Key

4. Disabling Password Authentication on Your Server

Th-th-th-that's all, folks!

Unraveling RabbitMQ: How to Scale Systems with Queues

Introduction

Usage Examples

Asynchronous Nature

Benefits of RabbitMQ

Fundamental Concepts

Message

Copying Your Public Key Using `ssh-copy-id`