During my early years as a Network Engineer in an ISP environment, our monitoring strategy was fairly traditional.

We primarily relied on:

  • Centreon for monitoring and alerting;
  • MRTG for traffic graphing and bandwidth visualization;
  • Various vendor-specific management platforms depending on the equipment and technology in use, similar to solutions such as cnMaestro in wireless environments.

At the time, this architecture appeared sufficient.

Alerts were generated whenever:

  • a device became unreachable;
  • a service stopped working;
  • a predefined threshold was exceeded.

Our role was essentially reactive.

  • A Centreon alert would appear.
  • A router would suddenly go DOWN.
  • A service would stop responding.
  • A link would become unstable.

And immediately, the process that many network engineers know all too well would begin: a lengthy and often frustrating troubleshooting session.

In many ways, we were firefighters. The most difficult challenge was not always the outage itself. The real challenge was the lack of a comprehensive understanding of the network's behavior.

More often than not:

  • we mitigated the issue before truly understanding it;
  • we applied temporary workarounds;
  • we restored service stability;
  • and only days, weeks, or sometimes even months later did we fully identify the root cause.

Looking back, this exposed a major limitation in our monitoring approach.

We had an abundance of data:

  • graphs;
  • alerts;
  • SNMP statistics;
  • logs;
  • dashboards;
  • vendor platforms.

Yet despite all this information, we frequently lacked meaningful visibility into how our infrastructure was actually behaving. And as the network grew, the situation became increasingly difficult. The number of graphs exploded, alerts became constant, dashboards became overcrowded.

The Centreon + MRTG combination remained technically effective, but it gradually became difficult to operate at scale. We were monitoring more devices than ever before. Yet we were not necessarily understanding our network any better.

This realization led me to a deeper conclusion:

Monitoring metrics does not necessarily mean understanding a system.

And as modern infrastructures continue to grow in complexity, this limitation becomes increasingly apparent.


Beyond Monitoring: Toward Operational Memory

Throughout the years, I noticed a recurring pattern in network operations.

When an incident occurred, our first objective was always clear:

Restore the service. And rightly so.

Customers do not care about root cause analysis when their Internet connection is down. They expect service restoration as quickly as possible.

As a result, many incidents followed a familiar lifecycle:

Incident
    ↓
Investigation
    ↓
Workaround
    ↓
Service Restored

Only later would we fully understand what had actually happened.

Sometimes a few hours later, Sometimes days later, Sometimes never 😅...

The surprising realization was that restoring service and understanding an incident are two very different objectives.

Restore Service ≠ Understand Incident

Traditional monitoring platforms are excellent at telling us that something is wrong.

They are much less effective at helping us remember what we learned from previous incidents.


The Missing Component: Memory 🤗

Modern network infrastructures generate an enormous amount of information.

We collect:

  • SNMP metrics
  • Telemetry streams
  • Syslogs
  • NetFlow records
  • Routing events
  • Optical measurements
  • Application metrics

Yet very little of this information becomes operational knowledge.

Most incidents are investigated, resolved, documented, and eventually forgotten.

The network itself does not learn.

The monitoring platform does not learn.

Only the engineers learn.

And when engineers leave, change roles, or simply forget details over time, much of that operational knowledge disappears with them.

This raises an interesting question:

Why do we continue to treat recurring incidents as completely new incidents?

A Different Approach

Instead of building systems that only collect metrics, perhaps we should build systems that accumulate operational experience.

Imagine that every incident generates a structured record:

Incident ID
Symptoms
Telemetry Snapshot
Affected Services
Root Cause
Resolution
Impact
Lessons Learned

Over time, this creates a growing operational memory.

Not a collection of alerts.

Not a collection of graphs.

A collection of experience 🤷🏽‍♂️.

Introducing Network Memory Intelligence

I call this concept Network Memory Intelligence (NMI).

The idea is simple:

  • A network should not only be monitored.
  • A network should be able to remember.
  • Every incident becomes a learning opportunity.
  • Every root cause becomes knowledge.
  • Every resolution becomes experience.

Instead of relying exclusively on human memory, the infrastructure gradually develops an operational memory repository.

When a new incident appears, the system can compare current symptoms against historical incidents.


The objective is not to replace engineers.

The objective is to augment their operational knowledge.

From Monitoring to Learning

For decades, network monitoring has focused on visibility.

Observability expanded that vision by helping us understand relationships between events.

The next step may be something different.

  • Not simply observing.
  • Not simply correlating.
  • Learning.

A future network operation center may not be defined by the number of dashboards it has, but by its ability to learn from every incident it experiences.

Because ultimately, the most valuable asset in any operations team is not its monitoring platform.

It is its accumulated experience.