Compliance · 6 min read

What is IP Log Management and why does it matter?

Every internet service provider sits on a firehose of connection records. IP log management is the discipline of capturing those records reliably, storing them safely, and being able to answer one deceptively simple question at any moment: who was using this IP address at this time?

The record you're required to keep

When a subscriber's device opens a connection, the router sees a flow: a source IP and port, a destination, a MAC address, and — behind it all — the PPPoE account that owns the session. In Bangladesh, the BTRC requires ISPs to retain this activity and produce it on demand. That means the record has to be complete (PPPoE ID, MAC, source and NAT IP, ports, precise timestamps), tamper-resistant, and retained for the mandated window.

Get any part of that wrong and the log is worthless when it's needed most — during an investigation or an audit, when you can't go back and re-capture what already happened.

Why it's harder than it sounds

At ISP scale the volume is enormous. A network of 20,000 subscribers can generate tens of millions of flow records a day. A naïve log store fills disks in weeks and grinds to a halt the first time someone runs a real search. So IP log management is really three problems at once:

Capture — record every flow, enriched with the subscriber behind it, without dropping lines under load.
Storage — keep months of it affordably, which means serious compression, not raw text files.
Retrieval — find one subscriber's session among billions of rows in seconds, not hours.

What "good" looks like

A healthy IP log system captures in real time, resolves any IP-and-moment back to a subscriber, and hands you a clean, timestamped export you can give a regulator without editing. It stays fast as history grows, and it's honest about retention — you should know exactly how far back you can answer.

That's the bar InfinityLog is built to clear: real-time capture from your Mikrotik, columnar storage at roughly 16 bytes per event, and sub-second search across a full day of traffic.

See it on your own traffic →

Guide · 8 min read

How to choose the right IP log management tool for your ISP

Not all log servers are equal, and the differences don't show up until you're mid-audit or mid-investigation. Here's what actually decides whether a tool will serve you for years — or become the thing you dread.

1. Compliance fit, first

Start with the record itself. Does the tool capture everything the BTRC expects — PPPoE ID, MAC, source and NAT IP, ports and accurate timestamps — out of the box, with templates tuned for Mikrotik? A tool that captures "most" of the fields is a tool that fails the one audit that matters.

2. Search speed at your scale

Ask for a demo on realistic volume, not a toy dataset. A search over a full day of a 20,000-subscriber network should return in about a second. If it takes minutes on a demo, it will take forever in production — and your team simply won't use it.

3. Storage economics

Retention is a cost, and compression is the lever. A legacy row-store can need several times more disk than a modern columnar engine for the same logs — roughly 8× in our deployments. That’s the difference between a 16 TB HDD and a 2 TB SSD — and between a system that's slow on spinning rust and one that's fast on flash.

4. Real-time visibility

Compliance is the floor, not the ceiling. Live log streaming turns the same data into an operational tool — you spot an issue as it happens instead of reading about it afterwards.

5. Access control & accountability

Multiple people will touch the system. Role- and group-based permissions with activity tracking mean every lookup is scoped and auditable — important when the logs themselves are sensitive.

6. Who's behind it

A log server is infrastructure. You want a vendor who deploys it, supports it, and has done so for years across many ISPs — not a one-off install you're left to babysit.

InfinityLog was built against exactly this checklist, and it's run in production for 350+ ISPs across five countries.

Compare packages →

Benefits · 5 min read

Top 5 benefits of implementing an IP log management solution

Beyond ticking the compliance box, a proper log server changes how an ISP operates. Here are the five wins operators tell us about most.

1. Audit-ready, always

When the regulator asks, you answer in minutes with a clean export — not a scramble through half-complete files. The record is already complete and already searchable.

2. Faster investigations

IP-to-subscriber attribution turns "who had this address?" from an afternoon of grep into a one-second query. That speed matters when a lawful request has a deadline.

3. Lower storage cost

Columnar compression shrinks the same logs by roughly 8×, so you keep more history on less — and cheaper — disk. Many operators move from bulk spinning disks to a small, fast SSD.

4. Real-time operational insight

Live streaming and traffic analytics surface top destinations, busy hours and anomalies — the same compliance data, working double duty for your NOC.

5. Peace of mind

Append-only storage, per-source retention and role-scoped access mean the record is trustworthy and the system is accountable. You stop worrying about the logs and get back to running the network.

Book a demo →

Engineering · 7 min read

Why we rebuilt InfinityLog's storage on a columnar engine

For years InfinityLog stored logs the obvious way — a relational database, a table per day, a row per event. It worked, until it didn't. Here's why we tore out the storage layer and rebuilt it on a columnar engine, and what changed for the ISPs running it.

The problem with a row per event

A row-store keeps every field of every event together on disk, wrapped in per-row overhead and indexes. For a handful of records that's fine. For an ISP writing tens of millions of flows a day it's brutal: disks fill in weeks, and a query for one subscriber has to walk enormous per-day tables that were never built for analytical scans. Operators told us the same thing — the logs were there, but searching them was something you avoided.

Columnar storage, in one idea

A columnar engine stores each field in its own contiguous stream. Millions of timestamps sit together, millions of IPs sit together — and data that looks alike compresses extraordinarily well. The same event that cost a bloated row now lands in roughly 16 bytes on disk. A network that once needed a 16 TB HDD comfortably fits on a 2 TB SSD — about 8× smaller — and because a search only reads the columns it needs, a full day of traffic comes back in under a second.

Migrating without losing a single line

The catch: you can't take a compliance log server offline to re-platform it, and you can't lose history mid-cutover. So the migration is a dual-write: new events flow into the columnar store and the legacy store at the same time, reads are served from whichever holds the range you ask for, and only once the new store is proven do we retire the old write path. Ingestion never stops. No day goes dark.

What the operator actually feels

Storage bills drop — months of retention on a small SSD instead of a rack of spinning disks.
Search becomes something you use — investigations that were an afternoon are now a query.
Nothing changes at the router — the same syslog stream, the same fields, the same compliance record.

None of this shows up on a spec sheet the day you sign. It shows up six months later, the first time a lawful request lands with a deadline and you answer it before the call ends.