Inside EyeOTmonitor’s Events and Alerts Engine: A Complete Guide

Recap from the Technical Deep Dive with COO/CPO Kirill Sokolinsky and VP of Sales & Marketing Chris Nixon

EyeOTmonitor’s latest customer webinar took a technical deep dive into one of the most critical capabilities of the platform: the Events and Alerts Management system. Led by COO/CPO Kirill Sokolinsky and moderated by Chris Nixon, the session offered real-world examples, live configuration demos, and a detailed roadmap for what’s next.

Why Events and Alerts Matter in Network and Device Monitoring

Today’s networks are increasingly complex, made up of not only traditional routers and switches, but also radios, edge devices, surveillance cameras, and IoT endpoints with varying protocols. Being able to detect early indicators of failure — like a drop in signal strength, bandwidth transmission anomalies, or interface errors — can dramatically reduce downtime, truck rolls, and support escalations.

At the heart of EyeOTmonitor’s monitoring platform is a powerful events and alerts engine that uses severity logic, tagging, and real-time data collection to:

• Identify and categorize abnormal behavior across devices
• Generate meaningful alerts only when necessary
• Help operators analyze long-term trends or point-in-time incidents

It’s not just about sending an alert. It’s about surfacing what matters — and doing it intelligently.

The Anatomy of a Device in EyeOTmonitor

Kirill began the session by breaking down how EyeOTmonitor conceptually understands and monitors a device. Each device is categorized based on three dimensions, which together determine its severity state:

Service Status

Refers to how the system connects with and validates device functionality. EyeOTmonitor checks for responsiveness using protocols like:

• Ping
• HTTP/HTTPS
• SMTP
• DNS, and more

Metrics tracked include latency, jitter, stability, and availability. Visual indicators (such as a changing icon color) give instant insight into whether these services are healthy.

Device Properties

Collected via SNMP, ONVIF, or APIs, these include:

• CPU and memory utilization
• Disk usage
• RSSI and SNR for radios
• System uptime
• API-based telemetry from vendors like Cradlepoint

Properties reflect the “health” of the device itself beyond basic network reachability.

Interfaces

Every networked device — whether wired or wireless — relies on interfaces. EyeOTmonitor tracks:

• Packet errors and discards
• Input/output traffic levels
• Interface status (up/down)
• Optical transceiver metrics like temperature and TX/RX power (on platforms like MikroTik)

These three categories — services, properties, interfaces — are the foundation of EyeOTmonitor’s Severity Rules Engine.

Introducing the Severity Rules Engine

The Severity Rules Engine lets users define thresholds for when a device or individual property moves from a normal to warning, severe, or critical state. This affects both UI visualization (such as color-coded icons and alerts in the side panel) and triggers for event generation.

Users can define:

• Thresholds by metric (e.g., “If CPU > 85% for 10 minutes, mark as critical”)
• Which categories (services, properties, interfaces) influence the overall device state
• Whether changes happen immediately or require a hold-down timer (e.g., sustained issue for 10 minutes)

You can think of this as both visual feedback and logic enforcement. If a property crosses a threshold, you’ll see it — and you can act on it.

Smart Targeting with Device and Property Tags

Tags are one of the most powerful and flexible features in EyeOTmonitor. They allow you to apply logic broadly or narrowly, without rewriting rules for each device type or protocol.

Device Tags

• Auto-assigned based on type (camera, switch, router), vendor (e.g., Axis, Ubiquiti), or capabilities (e.g., SNMP + ONVIF).
• Let users define alerts/events for groups of devices with shared characteristics.

Example:
Set one rule for all “Access Cameras” regardless of how they’re monitored (SNMP or ONVIF).

Property Tags

• Used for grouping specific metrics like interface TX bandwidth, signal strength (RSSI), or CPU.
• Enable rules based on function rather than metric source.

Example:
Set an event to trigger if any radio’s local RSSI falls below -70dBm, regardless of model.

This abstraction layer makes large-scale monitoring scalable and consistent.

Events vs Alerts: Two Tools, Two Purposes

Kirill stressed a key point: EyeOTmonitor separates events from alerts on purpose.

Events

• Logged in the UI for visibility and historical analysis
• Not meant to trigger notifications
• Ideal for low-priority conditions or trend monitoring

Alerts

• Trigger email notifications or escalation workflows
• Include device prioritization (e.g., core router vs. edge AP)
• Support hold-down timers to avoid flapping or false positives

You might care about CPU spikes across a month but don’t need an email every time it happens. That’s an event, not an alert.

Building Real-World Use Cases (Live Demos)

The heart of the session was a series of live configuration demos. Here are the key examples:

Camera to VMS Traffic Drop

Goal: Detect when a camera stops sending video to a recorder.

Approach: Monitor TX bandwidth on the camera’s interface. Trigger a “No Video” event if bandwidth drops below 250kbps.

Outcome: Event is logged, and interface visually enters a severe state.

RSSI Monitoring on Wireless Radios

Goal: Detect signal degradation on point-to-point and point-to-multipoint links.

Approach: Track local RSSI and tag radios by vendor (e.g., Ubiquiti Wave).

Outcome: Events are generated across multiple links and visible in the event log.

Cisco Interface Down Detection

Goal: Catch physical port failures even if the device remains reachable.

Approach: Create events tied to “Interface Operational Status.”

Outcome: Event triggers, port visually marked red, validating the detection logic.

MicroTik Optical Temperature Monitoring

Goal: Catch overheating on SFP modules.

Approach: Set interface-level rule for optical transceiver temperature > 70°C. Trigger a critical event.

Outcome: Event logged and property marked critical.

Overall Device Severity Visualization

Demonstrated how device state is derived from worst-case property unless otherwise configured.

Adjusted latency threshold on a camera from 4ms to 2ms — device UI updated from green to yellow in real time.

What’s Coming Next: Feature Roadmap

Several enhancements are in development to give users even more control and context:

Interface Traffic Load %

• Move from absolute bandwidth (e.g., >100Mbps) to relative saturation (e.g., >80% of link capacity)
• Dynamically adjust based on interface speed

Volume-Based Alerts

• Trigger alerts based on volume over time (e.g., “More than 1GB in 1 hour”)
• Useful for anomaly detection or billing insights

Rate of Change Rules

Detect deltas over time, such as:

• CPU spikes
• Sudden drops in interface speed
• Escalating RX/TX errors

We’re building logic that focuses not just on values — but on how those values behave over time.

This enables use cases like: If interface errors increase by 500 packets in 5 minutes, trigger alert.

Wrap-Up: Trust, Feedback, and Collaboration

The session closed with gratitude and an open call for collaboration:

We’re humbled by the turnout and your continued trust. Everything we’ve built — and are building — comes directly from conversations with users like you.

Chris emphasized EyeOTmonitor’s commitment to support:

• Help building event/alert rules with your team
• Best practices for tagging, thresholding, and escalation
• One-on-one walkthroughs on request

Get Started: Put What You’ve Learned Into Practice

If you’re ready to start building your own intelligent monitoring strategy:

• Explore the Severity Rules Engine
• Review your current device and property tags
• Create events for trend insights and alerts for real-time action
• Use the filterable event log for audits, RCA, or trend visualization