从通断说起
sky
频繁就必需把记录合并成一条一段时间内告警多次发生的记录。
处理的关键就在于探测NE联通的机制，好的网管机制设计的很合理，管理大数量的网元也可以在一秒内监测到。而不好的机制，就会越来越慢。
当然，如果系统本身有漏洞，EMS运行个十几天本来也会各种各样的毛病全部冒出来。
通断是NE管理的基础，其他的定时任务和监控任务以及管理任务都建立在NE通的情况下的。
各位可以先就这个话题讨论讨论，讨论完通断，才能讨论后面的告警，日志，性能这些任务。
techabc
sky
采取什么技术去监测通断？
对于长期不通的NE应该采取什么策略？
任务调度的设计？
On Aug 25, 3:25 pm, techabc <tech...@gmail.com> wrote:
> 关于通断监测，确实比较容易遇到问题。接入网的设备，在网设备数量大，设备成本则尽量压缩，甚至很多都没有嵌入式的OS，更甚至连以太网都不支持而只有串口(这-种情况现在已经很少见了，但历史遗留设备还是有的)，这样就全凭EMS主动监测，当设备数量破百后，这真的是个问题，多线程、线程池等上阵，却也常遇到头疼的情-况。
techabc
sky
已后会在ALARM中讨论TRAP，居然还有厂商告警全部通过TRAP来收集，真是玩笑。所以瞬间产生大量告警总是会丢就是因为先天机制不可靠。
Trap和通断没有关系。
On Aug 26, 4:44 pm, techabc <tech...@gmail.com> wrote:
> 因为一些简单的设备无trap等机制，所以主要采用EMS发起轮询的方式；
> 对于长期不通的设备，采用如退避窗口等类似gmail、msn、qq等重新连接的算法，如：假如多次不通，则每次退避1，2，5，8，......个时间单位后再试，这-样还是会错过设备恢复的时刻的。并且，有时不得已采用对设备同步进行轮询的机制，就是必须等设备超时后才继续进行下一步的操作，这样的话，就更麻烦了；
> 任务调度，就像进程调度一样，只有某种情况下合理的算法，但设备种类多样，很难大面积适合
>
> 2009/8/25 sky <shuhail...@gmail.com>
>
>
>
> > 这里有个策略问题。
> > 采取什么技术去监测通断？
> > 对于长期不通的NE应该采取什么策略？
> > 任务调度的设计？
>
> > On Aug 25, 3:25 pm, techabc <tech...@gmail.com> wrote:
>
> > 关于通断监测，确实比较容易遇到问题。接入网的设备，在网设备数量大，设备成本则尽量压缩，甚至很多都没有嵌入式的OS，更甚至连以太网都不支持而只有串口(这--种情况现在已经很少见了，但历史遗留设备还是有的)，这样就全凭EMS主动监测，当设备数量破百后，这真的是个问题，多线程、线程池等上阵，却也常遇到头疼的-情-况。- Hide quoted text -
>
> - Show quoted text -