Jamie van der Pijll

SNMP vs syslog vs flow: wat geeft echt bruikbaar netwerkzicht?

Written by

in

,

3 mei 2026 · Door Jamie van der Pijll · 7 min leestijd

Als iemand vraagt welke databron het belangrijkst is, weet ik meestal al dat het gesprek nog niet scherp genoeg staat. SNMP, syslog en flow concurreren niet met elkaar. Ze beantwoorden gewoon andere vragen, en precies daar gaat observability vaak mis.

Als ik netwerkzichtbaarheid moet opschonen, begin ik bijna nooit met tooling. Ik begin met de signalen zelf. Wat vertelt toestand mij? Welke events zijn echt bruikbaar? En wanneer laat verkeer iets zien wat status en logs allebei missen? Pas daarna wordt het zinvol om dashboards of alerts te bouwen.

Kort antwoord

SNMP is het handigst voor toestand, trends en capaciteit. Syslog is het handigst voor expliciete gebeurtenissen, fouten en policy-hits. Flow is het handigst voor echte verkeerspaden en gedragsvragen. Geen van drieën is op zichzelf genoeg voor bruikbaar netwerkzicht.

Begin met de vraag, niet met de bron

Wil ik weten of iets gezond of verzadigd is? Dan kom ik meestal bij SNMP uit. Wil ik weten welk device expliciet toegaf dat er iets veranderde of faalde? Dan kijk ik naar syslog. Wil ik zien wie met wie praat en welk pad het verkeer echt neemt? Dan wil ik flow-data hebben.

De ruis begint zodra alles op één hoop belandt. Dan verwacht iemand root cause uit counters, trendgedrag uit losse logs of applicatiebegrip uit flowrecords zonder context. Dat werkt zelden lekker.

SNMP is voor mij de basislaag

  • het laat zien of interfaces, CPU, geheugen of sessie-achtige counters gezond blijven;
  • het maakt verzadiging, foutopbouw en langzame degradatie zichtbaar;
  • het helpt om te zien of een patroon al liep vóórdat iemand het incident meldde.

Daarom gebruik ik SNMP vaak als eerste kapstok voor baselines en capacity-vragen. Niet sexy, wel nuttig. Je leert er het ritme van een omgeving mee kennen.

Maar het houdt ook snel op. Een link kan keurig up zijn terwijl policy, DNS, identity of applicatielogica allang ontspoord zijn. Wie daar causaliteit uit probeert te halen, vraagt te veel van de bron.

Syslog is de contextbron, maar alleen als je durft te snoeien

  • het laat zien welk device expliciet een fout, flap, auth-failure of policy-hit meldde;
  • het maakt duidelijk wanneer een wijziging of state-change echt plaatsvond;
  • het geeft operators vaak precies dat ene stukje context dat counters niet konden leveren.

Het probleem is bekend: als alles omhoog mag, leest uiteindelijk niemand nog iets. Dan verandert syslog van contextbron in herrie. Ik wil vooral events die iets verklaren: tunnel down, route flap, auth-failure, HA failover, policy deny, interface reset. De rest mag vaak stiller.

Flow is de reality check

  • het laat zien welke hosts, subnets of applicatiepaden het verkeer echt bepalen;
  • het maakt hotspots, onverwachte routes en scheve traffic-patronen zichtbaar;
  • het laat vaak genadeloos zien dat de feitelijke verkeersstroom niet lijkt op het ontwerpverhaal.

Voor vragen rond segmentatie, branch-verkeer, firewallhotspots of onverwachte east-west-paden is flow-data vaak het moment waarop de discussie ophoudt abstract te zijn. Niet omdat flow alles uitlegt, maar omdat het laat zien wat er werkelijk gebeurt.

De grens is ook hier duidelijk. Zonder labels, context en applicatiekennis blijft het half zicht. Gedrag alleen is nog geen betekenis.

Waar het meestal misgaat

  • SNMP overvragen. Dan verwacht je oorzaak uit iets dat vooral toestand en trend toont.
  • Syslog ongefilterd laten stromen. Dan verdrinkt bruikbare context in bulk-events.
  • Flow behandelen als complete waarheid. Dan overschat je verkeersdata zonder applicatie- of identity-kader.
  • Alles tegelijk visualiseren. Dan krijg je een dashboard dat veel laat zien, maar weinig helpt.

Mijn volgorde

  1. Start met SNMP als je eerst wilt weten hoe gezond of afwijkend de omgeving zich gedraagt.
  2. Gebruik syslog om state-changes, foutmeldingen en policy-signalen te verklaren nadat je de eventset kleiner hebt gemaakt.
  3. Gebruik flow zodra je echte paden, hotspots en verkeersgedrag wilt zien.
  4. Combineer ze pas daarna in dashboards of alerting, zodat elk signaal zijn eigen taak houdt.

Validatie en grenzen

Dit patroon werkt in firewalls, branches, campus-netwerken en WAN-paden, maar niet elke omgeving geeft dezelfde kwaliteit terug. SNMP kan te grof zijn, syslog slecht geredigeerd en flow half sampled. Dat is juist waarom ik eerst één concrete vraag kies en daarna pas bepaal welke bron daar het snelst antwoord op geeft.

Als ik twijfel welke bron ik nodig heb, is dat vaak een teken dat de omgeving niet te weinig tooling heeft, maar te weinig signaalhiërarchie.

Verder lezen

Conclusie

SNMP, syslog en flow-data zijn geen concurrenten. Het zijn drie verschillende lenzen op hetzelfde netwerk. SNMP vertelt of de vorm gezond blijft, syslog vertelt wat een device expliciet toegaf, en flow laat zien wat het verkeer echt deed.

Zodra je die rollen door elkaar trekt, krijg je rumoer. Zodra je ze bewust naast elkaar zet, wordt observability eindelijk bruikbaar.

More posts