Abstract: An example method comprises receiving flow packets from network traffic analyzing platforms, for each particular flow packet: identify the particular flow packet as belonging to one of at least two flow packet types based on a format, if the particular flow packet is sFlow, determine if the particular flow packet is an sFlow sample, counter record, or a third packet type, if the particular flow packet is the sFlow sample or counter record, identify a flow source of the particular flow packet and at least one metric, and update a flow source data structure else ignore the particular flow packet, and if the particular flow packet is a second flow packet type: if the particular flow packet is of a format that matches a template, identify the flow source, and update the flow source data structure to include the identified flow source and the at least one metric.

Abstract: An example method comprises receiving flow packets from network traffic analyzing platforms, for each particular flow packet: identify the particular flow packet as belonging to one of at least two flow packet types based on a format, if the particular flow packet is sFlow, determine if the particular flow packet is an sFlow sample, counter record, or a third packet type, if the particular flow packet is the sFlow sample or counter record, identify a flow source of the particular flow packet and at least one metric, and update a flow source data structure else ignore the particular flow packet, and if the particular flow packet is a second flow packet type: if the particular flow packet is of a format that matches a template, identify the flow source, and update the flow source data structure to include the identified flow source and the at least one metric.

Abstract: A method comprising: receiving network traffic data from a network traffic monitoring platform, the network traffic data identifying communication between entities of an enterprise network and storage monitoring data from a server-based SAN monitoring platform, the storage monitoring data identifying communication between a software-only server-based SAN and entities of the enterprise network, parsing the received traffic data and storage monitoring data to identify object data and/or metric data, creating a metric table entry from metric data, creating an object table entry from object data linking metric table entries with object table entries, creating a link table entry from the linking of metric table entries with object table entries, for each link table entry, assigning an object performance threshold, comparing each metric table entries to the assigned object performance threshold, if an alarm trigger condition is satisfied based on the comparison, then triggering an alarm event and outputting an alar

Abstract: A monitoring device responds to status data to detect storms, analysis, and to attempt to remediate those storms. The monitoring device several types of storms, for each of which it has a technique for analysis of the storm. The monitoring device can determine if the storm is due to resource contention, excess or unbalanced performance activity, or network degradation. Once analyzed, the monitoring device analyzes the storm, and attempts to remediate the cause of the storm.

Abstract: A monitoring device responds to status data pushed from a network device, and also manages a link with another network device, the link allowing the monitoring device to pull status data from the second network device. The monitoring device receives packets including status, the data indicating activity for one or more clock ticks. The monitoring device can compute statistical measures, rather than the network device. The monitoring device maintains the status data in a buffer. The monitoring device lags actual activity, but has is more likely to capture delayed packets. The network device sends packets as wrappers, each wrapper indicating sets of status information. When the information in a wrapper crosses a clock tick boundary, the monitoring device allocates reported activity among clock ticks, assuming that activity follows a uniform distribution.

Abstract: A monitoring device responds to status data pushed from a network device, and also manages a link with another network device, the link allowing the monitoring device to pull status data from the second network device. The monitoring device receives packets including status, the data indicating activity for one or more clock ticks. The monitoring device can compute statistical measures, rather than the network device. The monitoring device maintains the status data in a buffer. The monitoring device lags actual activity, but has is more likely to capture delayed packets. The network device sends packets as wrappers, each wrapper indicating sets of status information. When the information in a wrapper crosses a clock tick boundary, the monitoring device allocates reported activity among clock ticks, assuming that activity follows a uniform distribution.

Abstract: For example, as indicated in the Incorporated Disclosures, rapid change from relatively little use of network bandwidth, to heavy overuse of network bandwidth (combined with a large number of endpoints attempting to access that network bandwidth) can often indicate an email virus or other maladjusted use of the system. In such cases, it could be appropriate to generate an alert, and bring the change to the attention of a human expert, or otherwise escalate the problem. In this Application, the phrase “best practices,” and variants thereof, can generally refer to business preferences (and to business rules imposed by management, or law or regulation), such as high utilization preferences often expressed by management. In such cases, one or more operators can enter descriptors of rules the system that it is desired the system follow, such as “processor cycle utilization >90%.

Abstract: A method comprising: receiving network traffic data from a network traffic monitoring platform, the network traffic data identifying communication between entities of an enterprise network and storage monitoring data from a server-based SAN monitoring platform, the storage monitoring data identifying communication between a software-only server-based SAN and entities of the enterprise network, parsing the received traffic data and storage monitoring data to identify object data and/or metric data, creating a metric table entry from metric data, creating an object table entry from object data linking metric table entries with object table entries, creating a link table entry from the linking of metric table entries with object table entries, for each link table entry, assigning an object performance threshold, comparing each metric table entries to the assigned object performance threshold, if an alarm trigger condition is satisfied based on the comparison, then triggering an alarm event and outputting an alar

Abstract: Network monitoring views can be recorded, replayed and shared. A monitoring system receives monitoring data, in response to which a monitoring view can be constructed. The monitoring data is maintained in memory or mass storage. One or more monitoring views can later be constructed in response to user preferences, even if those users would not have known to select those particular preferences or construct those particular monitoring views at the time. The monitoring views constructed in response to that monitoring data can be presented to users in a simulation of the problem, as if it were occurring at that time. Users can send particular monitoring views to others, with both the effects that the monitoring view can be preserved as part of a trouble report, and the persons receiving the monitoring view can have useful insight into what problem the user has pointed to.

Abstract: Network monitoring views can be recorded, replayed and shared. A monitoring system receives monitoring data, in response to which a monitoring view can be constructed. The monitoring data is maintained in memory or mass storage. One or more monitoring views can later be constructed in response to user preferences, even if those users would not have known to select those particular preferences or construct those particular monitoring views at the time. The monitoring views constructed in response to that monitoring data can be presented to users in a simulation of the problem, as if it were occurring at that time. Users can send particular monitoring views to others, with both the effects that the monitoring view can be preserved as part of a trouble report, and the persons receiving the monitoring view can have useful insight into what problem the user has pointed to.

Abstract: A network monitoring device responds to network status data (whether “pushed” from the network device or “pulled” from the network device) to maintain a buffer of saved status data. The network status data is reordered, manipulated, and presented to users of the network monitoring device in order. The monitoring device can provide a status report of the network environment. When network status data is delayed too long, the monitoring device can discard the network status data, or reduce its weighted consideration. The monitoring device attempts to balance accuracy and latency by adjusting wait time for network status data. The monitoring device maintains a record of the amount of network status data it receives and processes from each network device and each network device's ability to provide accurate and complete information to operators and users in a distributed network monitoring environment.

Abstract: A monitoring device responds to status data pushed from a network device, and also manages a link with another network device, the link allowing the monitoring device to pull status data from the second network device. The monitoring device receives packets including status, the data indicating activity for one or more clock ticks. The monitoring device can compute statistical measures, rather than the network device. The monitoring device maintains the status data in a buffer. The monitoring device lags actual activity, but has is more likely to capture delayed packets. The network device sends packets as wrappers, each wrapper indicating sets of status information. When the information in a wrapper crosses a clock tick boundary, the monitoring device allocates reported activity among clock ticks, assuming that activity follows a uniform distribution.

Abstract: An example method comprises receiving flow packets from network traffic analyzing platforms, for each particular flow packet: identify the particular flow packet as belonging to one of at least two flow packet types based on a format, if the particular flow packet is sFlow, determine if the particular flow packet is an sFlow sample, counter record, or a third packet type, if the particular flow packet is the sFlow sample or counter record, identify a flow source of the particular flow packet and at least one metric, and update a flow source data structure else ignore the particular flow packet, and if the particular flow packet is a second flow packet type: if the particular flow packet is of a format that matches a template, identify the flow source, and update the flow source data structure to include the identified flow source and the at least one metric.

Abstract: One network monitoring system maintains both information regarding historical activity and emergent activity of the network. Comparison of recent activity of the network with historical activity allows the system to determine whether recent network activity is within the realm of normal. The system maintains data structures representing a p.d.f. for observable values of network parameters. Such data structures are maintained both for historical and for emergent activity of the network. Recent activity can be compared with the p.d.f. for historical activity to aid in determining whether that recent activity is within the realm of normal. Network activity not within the realm of normal can include values of observable network parameters too high or too low to be consistent with historical activity of the network, or other values too unlikely to be consistent with historical activity at the network.

Abstract: A method comprising: receiving network traffic data from a network traffic monitoring platform, the network traffic data identifying communication between entities of an enterprise network and storage monitoring data from a server-based SAN monitoring platform, the storage monitoring data identifying communication between a software-only server-based SAN and entities of the enterprise network, parsing the received traffic data and storage monitoring data to identify object data and/or metric data, creating a metric table entry from metric data, creating an object table entry from object data linking metric table entries with object table entries, creating a link table entry from the linking of metric table entries with object table entries, for each link table entry, assigning an object performance threshold, comparing each metric table entries to the assigned object performance threshold, if an alarm trigger condition is satisfied based on the comparison, then triggering an alarm event and outputting an alar

Abstract: A network monitoring device responds to a network status data (whether “pushed” from the network device or “pulled” from the network device), maintaining a buffer of saved status data. The status data is reordered, manipulated, and presented to users in order. The monitoring device can thus report an accurate momentary report of the status of the network environment. When status data is delayed too long, the monitoring device can discard it, or reduce its weighted consideration. The monitoring device adjusts its wait for status data, either as an average or individually per device, attempting to balance accuracy and latency. The monitoring device also records of how much status data it is required to process, in response to the amount it can process reliably, and maintains a sampling rate for status data, somewhere between evaluating all of the status data, and evaluating only a small portion of the status data, when capable, attempting to balance the degree of sampling, against both error and latency.

Abstract: A monitoring device responds to status data pushed from a network device, and also manages a link with another network device, the link allowing the monitoring device to pull status data from the second network device. The monitoring device receives packets including status, the data indicating activity for one or more clock ticks. The monitoring device can compute statistical measures, rather than the network device. The monitoring device maintains the status data in a buffer. The monitoring device lags actual activity, but has is more likely to capture delayed packets. The network device sends packets as wrappers, each wrapper indicating sets of status information. When the information in a wrapper crosses a clock tick boundary, the monitoring device allocates reported activity among clock ticks, assuming that activity follows a uniform distribution.

Abstract: An example method comprises receiving flow packets from network traffic analyzing platforms, for each particular flow packet: identify the particular flow packet as belonging to one of at least two flow packet types based on a format, if the particular flow packet is sFlow, determine if the particular flow packet is an sFlow sample, counter record, or a third packet type, if the particular flow packet is the sFlow sample or counter record, identify a flow source of the particular flow packet and at least one metric, and update a flow source data structure else ignore the particular flow packet, and if the particular flow packet is a second flow packet type: if the particular flow packet is of a format that matches a template, identify the flow source, and update the flow source data structure to include the identified flow source and the at least one metric.

Abstract: A monitoring device responds to status data to detect storms, analysis, and to attempt to remediate those storms. The monitoring device several types of storms, for each of which it has a technique for analysis of the storm. The monitoring device can determine if the storm is due to resource contention, excess or unbalanced performance activity, or network degradation. Once analyzed, the monitoring device analyzes the storm, and attempts to remediate the cause of the storm.

Abstract: A method comprising: receiving network traffic data from a network traffic monitoring platform, the network traffic data identifying communication between entities of an enterprise network and storage monitoring data from a server-based SAN monitoring platform, the storage monitoring data identifying communication between a software-only server-based SAN and entities of the enterprise network, parsing the received traffic data and storage monitoring data to identify object data and/or metric data, creating a metric table entry from metric data, creating an object table entry from object data linking metric table entries with object table entries, creating a link table entry from the linking of metric table entries with object table entries, for each link table entry, assigning an object performance threshold, comparing each metric table entries to the assigned object performance threshold, if an alarm trigger condition is satisfied based on the comparison, then triggering an alarm event and outputting an alar