[ Walkthrough ]
Searchable observability for OT and IT: network devices, Linux servers and containers in one place. The logging obligation met, without a SIEM project.
When an incident hits, the answer is in the events: the link that flapped, the config that changed, the login that failed. The hard part is keeping them: long enough, in one place, ready to search.
Get compliant, and analyse security, network and OT issues faster.
Reconstruct what happened at 02:00: the exact sequence of events, in seconds, instead of SSH-ing into ten devices.
Retained, searchable logs and an audit trail: the logging obligation met, without a large design and infrastructure project.
Link flaps, STP topology changes, controller faults and interface errors, surfaced as they happen.
Logins, session activity and change events: who acted on which device, and when. With narrowin Explorer you also see the config changes themselves: what changed, when, and who.
Filter the whole network by host, app, severity or vendor and find the root event before the call escalates.
Failed logins, unexpected sources and anomalies: the events a security review needs, already collected.
Get the events in, find the answer, then keep watch over what matters.
Log Analytics runs in the same narrowin controller as Explorer and Diode: the network you can see, segment and now search.
Point your devices, servers and containers at it and the events start landing. Quick and easy.
Switches, firewalls and controllers over syslog. Debian and other Linux hosts via rsyslog or journald. Docker containers via the syslog log driver or a log collector.
Messages are ingested, parsed and normalised automatically. No schema to define, whatever the source.
The query language or a plain search, the severity histogram and facets: the answer in seconds.
Pin watch queries to the dashboard, set the retention you need, export for the audit.
| Ingestion | Syslog over UDP / TCP (RFC 3164 & RFC 5424): one endpoint for every source |
|---|---|
| Sources | Switches, routers, firewalls, controllers · Linux / Debian hosts via rsyslog or journald · Docker containers via the syslog log driver · application and file logs via a standard log collector |
| Query | A field-aware query language, with a plain-text Search mode |
| Severity model | Full eight-level syslog ladder: emerg through debug |
| Time window | 15 minutes to 30 days, plus custom ranges |
| Views | Dashboard, Explore, per-device drill-down |
| Storage | High-compression log store: retention you set, not sampling |
| Export | CSV; saved queries; pinned watch queries |
| Deployment | Part of the narrowin controller, cloud or on-premises |
| Authentication | Local users, SAML SSO (Keycloak, Entra ID, Okta, ADFS), and LDAP / Active Directory |
| Data | Your events stay on your infrastructure |
| Documentation | /docs/loganalytics (login) → |
A SIEM is a platform and a programme: correlation rules, tuning, a team to run it. Log Analytics is right-sized: ingest, retain and search the events, so a mid-size OT operator meets its obligation without the project.
Yes. Anything that can send syslog lands in the same store and the same schema. Network devices send directly. Debian and other Linux hosts forward their system logs via rsyslog or systemd-journal-upload. Docker containers use the syslog log driver, or you put a lightweight log collector in front when you want to parse, enrich or filter container and file logs first. One endpoint, one search box across OT, IT and containers.
Not on network devices: they already speak syslog, you point them at the narrowin controller and events start landing. On servers you use what is already installed, rsyslog or journald. Only if you want to shape container or application logs first does a lightweight log collector come into it. The common open-source collectors all work; which one is your call.
A fast, field-aware query language with autocomplete, quick even over millions of events. A plain-text Search mode covers the quick look when you don't need precision.
As long as you choose. A high-compression store keeps months of events on modest disk; retention is a setting, tuned to your obligation.
Yes. NIS2 and the KRITIS rules expect retained, reviewable logs. Log Analytics provides the retention, the search and the export an audit asks for.
On your infrastructure. Log Analytics runs as part of the narrowin controller, cloud or on-premises. Your events do not leave it.
A central monitoring and logging infrastructure is an essential building block for our security and auditing guidelines.
NIS2 and the KRITIS rules expect critical-infrastructure operators to retain and review their logs. Log Analytics is that obligation, met proportionately, without the cost and staffing of a full SIEM.
Bringing OT and IT events into one searchable place, for security and for the audit.
Read →
Diagnosing a Layer 2 loop by walking the fault back through the events: the flap, the cause, the recovery.
Read →
How lightweight tools map to the Swiss ICT minimum standard, logging and review included.
Read →
Turning equipment you already run into intrusion detection, no extra sensors required.
Read →Start keeping them now: searchable, retained, and ready the moment you need them.
Talk to us about your logging