NetScout产品介绍.ppt

PM/CDM 4.0 Introduction * Company Confidential * * * PM/CDM 4.0 Introduction * Company Confidential * * NOTE: When you print the speaker notes, this slides notes get clipped as they take up more than ? page. 1) You can see them all online when viewing electronically 2) Copy and paste them into notepad or word and print This feature is unique to NetScout… a polling based product will never be able to do this (such as Concord, you do not have to mention vendor names, rather infer it). Use the analogy of a video camera in a bank… the video camera has the evidence recorded when a significant event occurs in the bank such as a burglary. The probe is always recording what is occurring as it watches the network. So, when an alarm condition happens it has the evidence in memory that gets associated with the alarm that triggers. Normally (meaning with other products), the alarm would trigger and the product would come back in the future and poll the device or perform an manual packet capture to see what is causing the alarm condition. The application or user that caused the issue may or may not be around anymore. This is a hit or miss… we have the actual evidence of what was occurring on the link at the time of the alarm. Example: A WAN circuit is experiencing high utilization for a sustained period of time (time-over-threshold), meaning that this is a significant event. When the threshold condition for utilization is met, the probe starts tracking things such as the applications and users taking up the bandwidth. If the utilization stays hot for the significant period of time, the alarm triggers. The probe stores away the evidence, which gets retrieved by the PM Server. Note that the evidence is based on the actual applications and users that were on the link at the time of the alarm! The same holds true for response time. If response time was degrading for a significant period of time, then the actual applications and users that were using the link will be provided a