Open dspruell opened 5 years ago
Another idea: allow defining within the MonitoredSegment a count of sensors that should report for the segment. Could alternately assign/associate EventMonitors to segments.
For example, there is a segment, LAN. There are 2 Event Monitors, IDs 1 (Suricata sensor) and 2 (Bro sensor). Event Monitors 1 and 2 could be associated to the LAN segment. If a dispatched health check probe results in a ReceivedLog for both of those monitors, then that is a healthy state. If one is received, then that is a partially healthy state and if none received, then that is an unhealthy state for the segment. It might be necessary to implement a state for the segment we don't have yet (partially healthy) to reflect when 1 or more (but not all) of the associated monitors send logs for the dispatched probe. It would also be possible to see which monitors did not send a log, possibly pointing to problem sensor(s) for the segment.
Current event logic for tracking dispatched/received/rate on monitored segments works when a single sensor (say, a Suricata box) is monitoring the segment. But in cases where multiple sensors monitor traffic for a segment, or when a packet crosses other monitored segments en route to the target segment, multiple copies of the probe packet will be picked up by deployed monitors and reported to the manager, leading to an imbalance in dispatched/received events (one dispatched probe will be reported by multiple monitors).
Possible solutions: