1
00:00:00,320 --> 00:00:07,860
Sistemas baseados em eventos, os protocolos de gerenciamento de rede funcionam de maneira muito diferente para consultar sistemas baseados.

2
00:00:08,010 --> 00:00:14,910
Em qualquer sistema baseado em eventos, o sistema de gerenciamento de rede simplesmente escuta possíveis anúncios ou eventos

3
00:00:14,910 --> 00:00:17,270
a serem enviados por fio.

4
00:00:18,000 --> 00:00:22,050
Normalmente, protocolos de gerenciamento de rede que aproveitam esses tipos de eventos.

5
00:00:22,060 --> 00:00:26,720
Portanto, com base no log de origem ou na captura de S&amp;P.

6
00:00:26,820 --> 00:00:34,480
Agora, todos são controláveis em termos da quantidade de detalhes que você recebe dos dispositivos da sua rede.

7
00:00:34,560 --> 00:00:42,490
Assim, como exemplo em um Cisco Rada, você pode ativar a depuração, que produz uma quantidade muito grande de dados.

8
00:00:42,600 --> 00:00:47,220
Há muitos detalhes de baixo nível gerados com a depuração.

9
00:00:47,490 --> 00:00:53,290
Você pode não querer necessariamente essa quantidade de dados enviados ao seu sistema de gerenciamento de rede.

10
00:00:53,370 --> 00:00:59,520
Um dos problemas aqui é se você receber uma grande quantidade de dados que analisará os dados

11
00:00:59,910 --> 00:01:06,780
para tomar decisões significativas sobre os dados que foram recebidos, para que você não queira que apenas ative muitas

12
00:01:06,780 --> 00:01:13,990
informações baseadas em eventos que são enviadas a você como um servidor slog uma das vantagens dos sistemas baseados em

13
00:01:14,170 --> 00:01:17,170
eventos é que eles podem reagir muito rapidamente.

14
00:01:17,170 --> 00:01:22,870
Em outras palavras, se algum evento ocorrer na rede, o sistema de gerenciamento de

15
00:01:22,870 --> 00:01:29,820
rede poderá agir imediatamente nesse evento, em vez de esperar que um intervalo de pesquisa expire como exemplo.

16
00:01:29,880 --> 00:01:36,450
Se você estiver pesquisando uma interface turbulenta por seu status a cada cinco minutos, saberá que ela faz interface

17
00:01:36,450 --> 00:01:42,970
sempre que a pesquisa é feita ou a consulta é feita em um sistema baseado em consulta.

18
00:01:43,200 --> 00:01:49,410
Porém, se a interface ficar inativa logo após a sua retirada, poderá levar mais cinco

19
00:01:49,410 --> 00:01:55,740
minutos para você perceber que ela caiu quando o sistema de gerenciamento de rede puxa o

20
00:01:55,740 --> 00:02:03,000
roteador a cada cinco minutos, ele receberá uma resposta positiva do roteador, confirmando que o faz interface como

21
00:02:03,000 --> 00:02:03,950
um exemplo.

22
00:02:04,140 --> 00:02:09,840
Isso geralmente é feito usando um protocolo de gerenciamento de rede, como um MP, para que você saiba

23
00:02:09,840 --> 00:02:15,840
que a interface está operacional porque você consultou o Rada se não receber uma resposta do roteador, pois sabe

24
00:02:15,840 --> 00:02:17,460
que há um problema.

25
00:02:17,460 --> 00:02:23,340
Mas a desvantagem de um sistema baseado em consulta é que você está pesquisando apenas a cada cinco minutos.

26
00:02:23,340 --> 00:02:30,090
Se a interface foi desativada imediatamente após você ter puxado o roteador, pode levar até cinco minutos

27
00:02:30,570 --> 00:02:37,230
para perceber que há um problema na interface desse leme, como em um sistema baseado em

28
00:02:37,230 --> 00:02:44,000
eventos e na captura de S&amp;P ou mensagens de log de origem enviadas imediatamente quando a interface cai.

29
00:02:44,010 --> 00:02:49,710
Portanto, nesse caso, a estrada informa o sistema de gerenciamento de rede de que há um problema, em vez de

30
00:02:49,710 --> 00:02:56,040
o sistema de gerenciamento de rede ter que esperar um intervalo de cinco minutos para consultar o Rada quanto ao status de

31
00:02:56,040 --> 00:02:56,900
uma interface.

32
00:02:57,920 --> 00:03:01,700
Agora, há uma desvantagem nos sistemas baseados em eventos.

33
00:03:01,700 --> 00:03:08,120
Os protocolos de gerenciamento de rede não são confiáveis porque o sistema de gerenciamento de rede está

34
00:03:08,120 --> 00:03:12,600
simplesmente aguardando e ouvindo passivamente os eventos serem enviados a ele.

35
00:03:12,770 --> 00:03:18,710
Não saberia se havia um problema na rede se esse evento não chegasse ao sistema de

36
00:03:18,710 --> 00:03:19,920
gerenciamento de rede.

37
00:03:20,000 --> 00:03:26,090
Portanto, se houver um problema na rede ou uma interface for desativada, impedindo que a mensagem de log

38
00:03:26,090 --> 00:03:32,720
de origem ou a armadilha de S&amp;P cheguem ao sistema de gerenciamento de rede, o sistema de gerenciamento de rede

39
00:03:32,720 --> 00:03:37,250
não teria conhecimento do problema sem pesquisar explicitamente o dispositivo de rede.
