Immudb can work alongside rsyslog, Loki, Elasticsearch, or an operational database to give Linux administrators a way to preserve and verify the integrity of critical event histories.
Linux has never had a shortage of logging options. Between systemd-journald, rsyslog, syslog-ng, Fluent Bit, Loki, Elasticsearch, and dozens of other tools, administrators can collect, search, visualize, and archive practically every event occurring on a system. For operational troubleshooting, these solutions are excellent. They help explain why a service crashed, identify failed SSH login attempts, or pinpoint the source of an application error. However, they were never designed to answer a much more important question: Can you prove that a particular log entry has never been altered?
That distinction becomes critical in an e-commerce environment. Every online purchase generates a sequence of events that have financial and legal significance: an order is created, a payment is authorized, inventory is reserved, a shipping label is generated, a package is dispatched, or a refund is issued. These events are more than operational logs — they are business records. An organization needs confidence that the historical record is exactly as it was originally written when a customer disputes a charge, an auditor requests evidence of a transaction, or investigators reconstruct a security incident.
This is where open source immudb fits naturally into a modern Linux infrastructure. Rather than replacing existing logging systems, immudb complements them by providing an immutable, cryptographically verifiable ledger for high-value events. Every record written into immudb becomes part of an append-only Merkle tree, allowing later modifications or deletions to be detected. Rather than having to trust that historical data has remained intact, administrators can prove it.
Consider a typical order lifecycle. A customer purchases a laptop from an online retailer. During the next few minutes, multiple systems generate events:
ORDER_CREATED
PAYMENT_AUTHORIZED
INVENTORY_RESERVED
WAREHOUSE_PICK_STARTED
SHIPPING_LABEL_CREATED
PACKAGE_DISPATCHED
PACKAGE_DELIVERED
Most e-commerce platforms already write these events to application logs while maintaining the current order state in PostgreSQL or MySQL. That works well for day-to-day operations, but both systems remain changeable. A privileged administrator — or an attacker who gains privileged access — can modify database records, edit log files, or even delete them entirely. Unless additional safeguards exist, detecting those changes afterwards can be extremely difficult.
Instead of relying solely on conventional logging, each business event can be written into immudb as it occurs. The operational database continues to answer questions such as “What is the current status of order #847293?” while immudb answers a different class of question entirely: “What happened to this order throughout its lifetime, and can we prove that none of those events were modified?” The two databases serve complementary purposes rather than competing with one another.
The good news for Linux administrators is that much of the required infrastructure already exists. Most distributions use either systemd-journald or rsyslog to collect system events. Web servers, payment services, authentication daemons, Docker containers, reverse proxies, and custom applications already emit structured log messages. Rather than sending every log entry to an indexing platform, selected events can be forwarded to a lightweight collector responsible for inserting them into immudb.
A typical rsyslog configuration might forward authentication events to a central logging host:
module(load="imtcp")
authpriv.* @@audit.example.com:514
Likewise, an application server could forward only payment-related events:
if $programname == 'paymentd' then {
action(type="omfwd"
target="audit.example.com"
protocol="tcp"
port="514")
}
Notice that rsyslog is not communicating directly with immudb. Instead, it forwards messages to an ingestion service. That collector receives incoming syslog messages, extracts the relevant fields, enriches them with metadata where appropriate, and inserts them into immudb using its client API or SQL interface. This architecture keeps the logging pipeline simple while allowing validation, filtering, batching, and application-specific processing before records become immutable.
Suppose the collector receives the following payment event:
Aug 04 14:17:03 shop01 paymentd[3142]:
Order=847293 Payment=AUTHORIZED Amount=149.95 Gateway=Stripe
It can immediately persist the event in immudb:
INSERT INTO transaction_log (
order_id,
event_time,
event_type,
gateway,
amount,
hostname,
message
)
VALUES (
847293,
NOW(),
'PAYMENT_AUTHORIZED',
'Stripe',
149.95,
'shop01',
'Payment authorized successfully'
);
Alternatively, an application may choose to bypass syslog entirely and write business events directly into immudb through one of its client libraries. Many organizations adopt a hybrid approach — operational events continue flowing through rsyslog, while the application itself records critical business transactions directly into the immutable ledger.
Now, imagine a customer calls six months later claiming they never authorized a $2,400 purchase. The application database still contains the order, but by now the operational logs have been rotated, backups have expired, and several software upgrades have taken place. Was the payment really authorized? Did someone manually change the shipping address? Was the refund issued by a customer service representative or automatically by the fraud detection system?
If every business event was written to immudb as it happened, answering those questions becomes straightforward. The transaction history might look something like this:
2026-08-04 14:17:03 ORDER_CREATED
2026-08-04 14:17:04 PAYMENT_AUTHORIZED
2026-08-04 14:17:07 INVENTORY_RESERVED
2026-08-04 14:17:31 SHIPPING_ADDRESS_CHANGED
User: support-17
Previous IP: 203.0.113.24
2026-08-04 14:18:10 SHIPPING_LABEL_CREATED
2026-08-06 09:44:52 PACKAGE_DELIVERED
Because every record is cryptographically linked to every previous record, investigators can verify not only what happened, but also that the sequence itself has not been rewritten. That’s an important distinction. Traditional logging systems tell you what they currently contain; immudb lets you prove that yesterday’s history is still yesterday’s history.
This capability becomes particularly valuable in organizations where multiple systems participate in a single transaction. An order may pass through Nginx, an API gateway, Kubernetes, a payment service, PostgreSQL, Redis, a warehouse management system, and a shipping provider before reaching the customer. Each component produces its own logs, often in different formats and on different servers. Instead of trying to preserve dozens of independent log files forever, a small collector can extract the business-significant events from each system and commit them to a single immutable ledger.
That doesn’t replace your existing observability stack. Elasticsearch, Loki, Splunk, and OpenSearch remain the right tools for searching millions of log lines and diagnosing operational problems. Immudb serves a different purpose. Think of it as the system that records the facts you may someday need to prove: payments, refunds, administrative actions, API calls, inventory changes, and every other event whose integrity matters long after the logs themselves have disappeared.
In practice, deployment is remarkably simple. Existing applications continue logging exactly as they do today, while rsyslog or journald forwards selected events to a lightweight ingestion service. That service inserts them into immudb, where they become part of an append-only, cryptographically verifiable history. Organizations can begin by protecting payment transactions and gradually expand the scope to customer authentication, inventory management, pricing changes, or administrative actions without redesigning the rest of their infrastructure.
Linux has always excelled at generating, transporting, and analyzing logs. What it has traditionally lacked is a straightforward way to prove that those logs — and the business events they represent — have remained untouched over time. By adding immudb as an immutable audit layer, Linux administrators can build systems that are not only observable but also verifiable. In an era where every online transaction can become a legal, financial, or security event, that’s a capability worth having.
Dennis Zimmer is a co-founder and the chief technology officer of Codenotary. He has more than 25 years of experience in the IT industry.
Be First to Comment