CN1825985A

CN1825985A - 分布式管理***的消息跟踪方法

Info

Publication number: CN1825985A
Application number: CN 200510008751
Authority: CN
Inventors: 林涛
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2005-02-25
Filing date: 2005-02-25
Publication date: 2006-08-30
Anticipated expiration: 2025-02-25
Also published as: CN100563356C

Abstract

本发明公开了一种分布式管理***的消息跟踪方法，包括：(1)维护台接收用户输入的消息跟踪信息，并将之发送至主节点，所述消息跟踪信息包括跟踪节点、跟踪对象、交互节点、交互对象、消息类型及流控标志；(2)主节点将所述消息跟踪信息保存在***消息跟踪存储区，并将所述消息跟踪信息发送至所述跟踪节点；(3)跟踪节点根据所述消息跟踪信息在本节点的消息跟踪过滤器中设置对应的跟踪条件；(4)消息跟踪过滤器侦听本跟踪节点的消息，捕获符合过滤条件的消息，并将之发送至所述维护台。本发明支持离线设置和消息跟踪的配置恢复，并且具有很好的通用性。

Description

分布式管理***的消息跟踪方法

技术领域

本发明涉及通信领域，尤其涉及分布式管理***的消息跟踪方法。

背景技术

分布式管理是目前很多通信设备采用的管理本通信设备各个组成部件的一种方式。请参阅图1，其为分布式管理***的一种结构示意图。分布式管理***包括前台1和后台2。前台1包括主节点11和若干从节点12。其中，主节点11控制该些从节点12协调完成设备的各项操作。后台2包括维护台21，用于建立用户与前台1的各个节点(包括主节点11和从节点12)之间的交互。并且，节点可以是主机、单板或网络单元。

目前，最为典型的一种分布式管理***为交换机***，交换机***至少包括维护台和若干单板，所述单板包括主控板、交换板、线路处理板。主控板相当于主节点，而交换板、线路处理板等各块业务板相当于上述的从节点，各块业务板分别连接主控板，接受主控板的控制：加入交换机***，并参予***工作。

通常分布式管理***需要通过消息跟踪技术进行本通信设备的调试、侦听，以便获得性能更佳的通信产品。请参阅图2，其为分布式管理***的现有消息跟踪方法的流程图。它包括以下步骤：首先，维护台21接收用户(通常是指调试人员)通过用户界面输入的消息跟踪信息，所述消息跟踪信息包括跟踪节点、跟踪对象等跟踪条件(步骤S110)；然后，维护台21将所述消息跟踪信息组装成消息跟踪请求消息发送至跟踪节点(步骤S120)；随后，所述节点根据接收到的消息跟踪请求消息，在本节点的消息跟踪过滤器中设置对应的跟踪条件(步骤S130)；最后，消息跟踪过滤器侦听本节点的消息，捕获符合过滤条件的消息，并将之发送至维护台21，以将所述消息显示于用户界面，便于用户进行分析(步骤S140)。

上述消息跟踪方法存在以下缺陷：

第一：由于节点的消息跟踪过滤器设置在本节点的内存中，因此当节点发生重启时，需要维护人员通过用户界面重新发送消息跟踪信息，并重新设置消息跟踪过滤器中的过滤条件，不仅费时费力，而且给用户造成很大不方便。最重要的是，无法跟踪到节点在启动阶段的各种消息，由此导致跟踪效果不佳的后果；

第二，现有技术中维护台和节点之间按照预先约定的消息跟踪请求消息格式进行通讯。但是，现有的消息格式中仅针对用户类的消息提供过滤条件的设置，但无法跟踪其他消息类型、其他消息对象及不同对象之间的消息，由此导致跟踪设置比较单一，进而造成消息跟踪的局限性，从而影响跟踪效果。

发明内容

本发明的目的在于提供一种分布式管理***的消息跟踪方法，以解决现有技术中无法跟踪到节点在启动阶段的各种消息，由此导致跟踪效果不佳的技术问题。

为解决上述问题，本发明公开了一种分布式管理***的消息跟踪方法，所述分布式管理***包括前台和后台，所述后台包括维护台，所述前台包括主节点和分别连接主节点的若干从节点，包括：(1)维护台接收用户输入的消息跟踪信息，并将之发送至主节点，所述消息跟踪信息包括跟踪节点和跟踪对象，交互节点、交互对象、跟踪消息类型；(2)主节点将所述消息跟踪信息保存在***消息跟踪存储区，并将所述消息跟踪信息发送至所述跟踪节点；(3)跟踪节点根据所述消息跟踪信息在本节点的消息跟踪过滤器中设置对应的跟踪条件；(4)消息跟踪过滤器侦听本跟踪节点的消息，捕获符合过滤条件的消息，并将之发送至所述维护台。

本发明还包括：当所述从节点上电启动后，向主节点发出发送配置数据的请求消息；主节点接收到所述请求消息，将预先保存的所述从节点对应的所有配置数据发送给所述从节点，所述配置数据包括跟踪节点为所述从节点的所有消息跟踪信息。

步骤(4)还包括，当跟踪节点的CPU占用率超过告警阈值时，则跟踪节点不进行侦听和捕获，以防对***性能造成过重负担。

若所述***发生重启时，主节点向每个从节点发送跟踪节点为该从节点的所有消息跟踪信息。

其中，步骤(4)中消息跟踪过滤器将符合条件的消息发送至维护台具体为：当消息跟踪过滤器获知用户已设置限制过长标志，则判断符合过滤条件的消息的长度是否大于预先设定的阈值，若是，则从所述消息中截取所述阈值长度的信息，并将所述信息发送至维护台，否则将所述消息发送至维护台。

另外，本发明还包括：在前台设置备用节点，所述备用节点分别连接主节点和各个从节点，并且备节点本身也作为主节点的从节点存在。

其中，步骤(2)还包括：主节点将所述消息跟踪信息发送至备用节点，以便备用节点将所述消息跟踪信息保存在备用节点的***消息跟踪存储区，当新增、修改、删除***消息跟踪信息时，主节点会将更新信息同步发送到备用节点上，备用节点上电或重启时，主节点也会自动将***消息跟踪信息同步备份到备用节点上。

还有，本发明还包括：定时检测主节点的***消息跟踪存储区和备用节点的***消息跟踪存储区中数据的一致性，若一致，则退出，否则，更新备用节点的***消息跟踪存储区中的数据以便与主节点的***消息跟踪存储区中数据一致。

步骤(3)中还包括：跟踪节点采用二级链表结构保存接收到的消息跟踪信息，第一级链表为所述跟踪节点的所有跟踪对象，第二级链表为每个跟踪对象所有消息跟踪信息。所述消息跟踪信息包括跟踪节点标识、跟踪对象标识、交互方节点标识、交互方对象标识、跟踪消息类型及是否限制过长消息标志。***消息跟踪存储区是以节点为索引建立各个节点的节点消息跟踪表，所述节点消息跟踪表用以保存本节点上跟踪对象的消息跟踪信息。

与现有技术相比，本发明具有以下优点：

第一：本发明在维护台向跟踪节点下发消息跟踪信息时，若跟踪节点是从节点，则通过主节点下发跟踪信息至该跟踪节点对应的从节点，并且还将该消息跟踪信息保存在主节点的内存中，以便从节点发生重启时能及时从主节点中获得与该从节点相关的所有消息跟踪信息，进而使得能够跟踪到从节点启动阶段的各种消息，同时，避免用户重新输入该些消息跟踪信息，由此提高跟踪效率；

第二：由于消息跟踪信息设定的通用性，可支持***中不同类型的各种消息的跟踪。另外，消息跟踪设置更为灵活，如可由用户任意定制消息的跟踪对象及交互对象，由此来提高消息跟踪的通用性。

第三：本发明还支持主备备份。当主节点接收到消息跟踪信息时，还将该消息跟踪信息备份到主节点。以便主节点发生故障时，备用节点能升为主节点，而原有设置继续生效，以使获得本分布式管理***的消息跟踪冗余设置；

第四：本发明对消息跟踪还增加了流控设置，不仅考虑到CPU的处理能力，而且还考虑到跟踪捕获消息的长度，进而防止对***性能造成过重负担；

第五：用户设置消息跟踪时，可以任意指定与被跟踪对象产生交互消息的交互节点、交互对象类型和交互对象标识，任意指定消息交互类型。支持通配符输入，即：跟踪对象与所有/指定交互节点上的所有/指定交互对象类型、所有/指定交互对象实例之间的发送/接收/所有消息交互。

附图说明

图1是分布式管理***的一种结构示意图；

图2是分布式管理***的现有消息跟踪方法的流程图；

图3是本发明分布式管理***的消息跟踪方法的流程图；

图4是实施例所适用的分布式管理***的示意图；

图5是基于图4的消息跟踪方法的流程图。

具体实施方式

以下结合附图，具体说明本发明。

本发明在维护台向跟踪节点下发消息跟踪信息时，若跟踪节点是从节点，则通过主节点下发跟踪信息至该跟踪节点对应的从节点，并且还将该消息跟踪信息保存在主节点的内存中，以便从节点发生重启时能及时从主节点中获得与该从节点相关的所有消息跟踪信息，进而使得能够跟踪到从节点启动阶段的各种消息，同时，避免用户重新输入该些消息跟踪信息，由此提高跟踪效率。

另外，即便该跟踪节点对应的从节点处于离线状态，维护台只要将该从节点相关的消息跟踪信息发送至主节点，主节点将其作为配置文件中的一部分数据进行保存，当从节点启动时，从主节点可以通过主节点下发的配置数据获得相应的消息跟踪信息，大大提高消息跟踪命令设置的方便性。

请参阅图3，其为本发明分布式管理***的消息跟踪方法的流程图。它包括以下步骤：首先，维护台接收用户输入的消息跟踪信息，并将之发送至主节点，所述消息跟踪信息包括跟踪节点和跟踪对象(步骤S210)；然后，主节点将所述消息跟踪信息保存在***消息跟踪存储区，并将所述消息跟踪信息发送至所述跟踪节点(步骤S220)；随后，跟踪节点根据所述消息跟踪信息在本节点的消息跟踪过滤器中设置对应的跟踪条件(步骤S230)；最后，消息跟踪过滤器侦听本跟踪节点的消息，捕获符合过滤条件的消息，并将之发送至所述维护台(步骤S240)。

当所述从节点上电启动后，向主节点发出发送配置数据的请求消息；主节点接收到所述请求消息，将预先保存的所述从节点对应的所有配置数据发送给所述从节点，所述配置数据中包括跟踪节点为所述从节点的所有消息跟踪信息。

通过上述的方法，对从节点的消息跟踪设置即可做到通过配置数据进行自动恢复，由此提高消息跟踪的效率，最重要的是能跟踪到启动阶段的各种消息，进而提高消息跟踪的准确性。特别是，不仅可以跟踪用户类消息，而且可以跟踪***管理对象之间的控制消息，使得消息跟踪适用对象具有通用性。

另外，很多分布式管理***都支持主备结构，即设置主节点的备用节点，以备主节点发生故障时，能及时用备用节点替换主节点，以便使整个分布式管理***正常工作。为此，在步骤S220中还包括：主节点将所述消息跟踪信息发送至备用节点，以便备用节点将所述消息跟踪信息保存在备用节点的***消息跟踪存储区。备用节点自身也是一个从节点，因此主节点和备用节点之间的任何消息同样可以设置跟踪。另外，当新增、修改、删除***消息跟踪信息时，主节点会将更新信息同步发送到备用节点上，备用节点上电或重启时，主节点也会自动将***消息跟踪信息同步备份到备用节点上。

并且，还要定时检测主节点的***消息跟踪存储区和备用节点的***消息跟踪存储区中的数据是否一致，若是，则退出，否则，根据主节点的***消息跟踪存储区更新备用节点的***消息跟踪存储中的数据，以便于主节点的***消息跟踪存储区中的数据相同。当主节点发生故障倒换时，备用节点升为主节点后，原有设置能够继续生效。

以下就举个具体实施例来说明上述的消息跟踪方法。请参阅图4，其为本实施例所适用的分布式管理***的示意图。它包括前台1和后台2。其中前台1除了包括主节点11和从节点12外，还包括与主节点11相连的备用节点13。并且，从节点12每次重新启动时，需要到主节点11中获得本从节点12相关的所有配置数据，以便能加入***工作。另外，从节点12通常通过主节点11与维护台21连接，以便建立用户与该从节点12的连接。

其于上述***结构，请参阅图5其为该分布式管理***的消息跟踪方法的流程图。具体方法如下：

S310：设置一个通用消息属性模型。

由于在***内部产生的各种交互消息总是有一些通用的属性。如发送节点、对象、接收节点、对象等。为此，设置一个通用消息属性模型，它具有如下成员域：跟踪节点标识、跟踪对象标识、交互方节点标识、交互方对象标识、跟踪消息类型、是否限制过长消息标志。以下公开本实施例定义的通用消息属性模型(并非局限于此)。消息跟踪模型定义如下：

struct DBG_MSGTRACE_ITEM_S{

UINT32 ulTraceNode；//跟踪节点标识

UINT32 ulTraceObjId；//跟踪对象标识

UINT32 ulTraceMsgType；//跟踪消息类型

UINT32 ulOppNode；//交互方节点标识

UINT32 ulOppObjId；//交互方对象标识

UINT32 ulPartialFlag；//是否限制过长消息标志

}

用户根据该消息属性模型通过用户界面输入相应的消息跟踪信息，即包括跟踪节点标识、跟踪对象标识、跟踪消息类型、交互方节点标识、交互方对象标识及是否限制过长消息标识。对象ID根据用户需求可由对象类型ID和实例ID组合而成(也可仅由实例ID组成，这时仅标识某一类对象)，因此所表示的对象可以是任务、进程、模块、通道、队列等任何可以独立发送、接收消息的主体。由于消息跟踪信息设置的通用性，可支持不同类型***上的各种消息跟踪。比如：这些消息可以是同一节点同一对象之间，不同节点不同类对象之间，不同节点同一类对象之间以及同一对象内部的消息。

跟踪消息类型包括接收、或发送、或接收与发送。缺省情况下跟踪消息类型为接收和发送。当交互方节点标识和交互方对象标识缺省时，***默认为跟踪节点的所有消息。消息跟踪设置更灵活更通用。需要能由用户任意定制消息的跟踪对象、发送或接收或交互方对象。

限制过长消息标识用于限制跟踪节点捕获满足跟踪条件的消息时，能对所述消息进行流控设置。满足跟踪条件的消息的长度小于等于该阈值的消息，才通过主节点11发送至维护台21。若消息长度大于该阈值的消息，则截取阈值长度的信息通过主节点11发送至维护台21，以此来防止给***网路造成过重负担。当然，用户也可以将阈值设置为O，即不限制消息的长度。也就是说，用户可以根据具体情况来具体设置是否需要限制消息的长度以及阈值的大小。

S320：维护台21根据用户输入的消息跟踪信息设置消息跟踪请求消息，发送消息跟踪请求消息至主节点11。

维护台21和主节点11之间预先约定消息跟踪请求消息的格式，以便两者之间顺利进行通信。所述消息跟踪请求消息是根据用户输入的消息跟踪信息进行设置的。它至少也包括跟踪节点标识及跟踪对象标识。

S330：主节点11将消息跟踪请求消息中获得消息跟踪信息，并将之保存在***消息跟踪存储区中，同时，将该消息跟踪信息传送至备用节点13，以便保存在该备用节点13的***消息跟踪存储区中。不管是主节点11还是备用节点13的***消息跟踪存储区，可以有很多的存储方式存储该消息跟踪信息。由于一个主节点11通常控制多个从节点12的工作，因此，可以在***消息跟踪存储区中设置每个从节点12和主节点11的节点消息跟踪表，每个节点消息跟踪表保存消息跟踪信息。这样，当该从节点启动时，从主节点11下载相应的配置数据中直接包括该从节点对应的节点消息跟踪表，由此来提高下载配置数据的效率。

S340：主节点将消息跟踪信息发送至跟踪节点；

S350：跟踪节点根据消息跟踪信息在本节点的消息跟踪过滤器中设置对应的跟踪条件。跟踪节点还需要本节点将消息跟踪信息保存在节点消息跟踪表中。本实施例中节点消息跟踪表采用二级链表结构，第一级链表为该跟踪节点的所有跟踪对象，第二级链表为每个跟踪对象的消息跟踪信息。消息跟踪信息包括跟踪节点标识、跟踪对象标识、跟踪消息类型、交互方节点标识、交互方节点标识。本实施例消息跟踪项结构定义如下：typedef struct DBG_MSGTRACE_LST_S

{

DBG_MSGTRACE_ITEM_T stMsgtrItem；

DBG_MSGTRACE_LST_T* pstNextMsgtrItm；//下一个消息跟踪表项

}DBG_MSGTRACE_LST_T；

消息跟踪表结构定义如下，将一个跟踪对象下的所有跟踪设置组织起来：

typedef struct DBG_MSGTRACE_OBJ_S

{

UINT16 ucMsgTraceOBJId；

DBG_MSGTRACE_LST_T*pstMsgtrLst；

DBG_MSGTRACE_OBJLST_T*pstNextMsgtrOBJlst；

}DBG_MSGTRACE_OBJLST_T；

节点消息跟踪表定义如下，将一个跟踪节点上所有跟踪对象的跟踪设置组织起来：

DBG_MSGTRACE_OBJLST_T* g_pstMsgTraceBdtbl

***消息跟踪表定义如下，将整个***中所有跟踪节点上的跟踪设置组织起来，只保

存在主控节点上：

DBG_MSGTRACE_OBJST_T* g_apMsgTraceSystbl[DBG_NODE_MAXNUM]

上述公开的仅为本实施例所采用的保存消息跟踪信息的结构，但并非局限于此，可以采用数组等其他保存形式，因此上述公开并不是用于局限本发明。

S360：消息跟踪过滤器跟踪本跟踪节点的消息，捕获符合过滤条件的消息，并将之发送至维护台21。若所述跟踪节点是从节点，则可以通过主节点将所述消息发送至维护台21。

当***发生任何一次消息发送或消息接收事件时，触发一次消息跟踪过滤器中的消息跟踪过滤动作(DBG_Msgtr_Catch)：根据事件对象标识，搜索节点消息跟踪表的对象链表(DBG_Msgtr_Filter)，若搜索到相应对象标识，则在搜索对象链表下的跟踪设置项链表是否存在匹配项，若匹配满足，则捕获消息并输出给用户(DBG_MsgtrOutput)。若对象存在于从节点，则不能直接转发给用户，需要通过主控板中转(DBG_Msgtr_Relaytompu)。若对象或跟踪设置项搜索失败，不捕获。并且，对消息跟踪增加了流控设置(DBG_Msgtr_FlowControl)，该函数检查当前***的CPU占用率是否超过告警阈值，若是，则不进行过滤和捕获，以防对***性能造成过重负担。

当维护台21接收到用户要求删除/修改消息跟踪信息时，维护台21将发送删除/修改消息跟踪信息消息至主节点11；主节点11删除/修改***消息跟踪存储区中相应的消息跟踪信息，并判断所述跟踪节点是否是从节点12，若是，则将所述删除/修改消息跟踪信息发送至跟踪节点对应的从节12，以便从节点12删除/修改相应消息跟踪信息，否则退出。

如果备用节点13重启(或当时不存在)，启动成功时，主节点11向备用节点13备份整个***消息跟踪表。若被设置跟踪的从节点12重启(或当时不存在)，启动成功时，主节点11将配置下发到从节点12。***跟踪表保存在主节点11本地，若全***发生重启，主节点11可以自动从该文件重新恢复***消息跟踪表，然后向所有从节点13逐一设置节点消息跟踪表，实现全***设置的恢复。

首先，在主节点11(MMPU)、备用节点13(SMPU)、从节点12(DPU)上分别创建一个DBG线程，协作完成***内所有消息跟踪事务处理。

其次，针对节点消息跟踪链表，定义一系列操作，它们是：***、删除消息跟踪设置，组装消息跟踪表项到内存缓冲区，从内存缓冲区中读取解析消息跟踪表项。

然后，在上述的各个时机，通过调用以上操作，完成***消息跟踪表的初始化备份、实时备份、配置恢复，节点消息跟踪表的配置恢复过程。

以上公开的仅为本发明的几个具体实施例，但本发明并非局限于此，任何本领域的人员能思之的变化，都应落在本发明的保护范围内。

Claims

1、一种分布式管理***的消息跟踪方法，所述分布式管理***包括前台和后台，所述后台包括维护台，所述前台包括主节点和分别连接主节点的若干从节点，其特征在于，包括：

(1)维护台接收用户输入的消息跟踪信息，并将之发送至主节点，所述消息跟踪信息包括跟踪节点和跟踪对象；

(2)主节点将所述消息跟踪信息保存在***消息跟踪存储区，并将所述消息跟踪信息发送至所述跟踪节点；

(3)跟踪节点根据所述消息跟踪信息在本节点的消息跟踪过滤器中设置对应的跟踪条件；

(4)消息跟踪过滤器侦听本跟踪节点的消息，捕获符合过滤条件的消息，并将之发送至所述维护台。

2、如权利要求1所述的分布式管理***的消息跟踪方法，其特征在于，还包括：

当所述从节点上电启动后，向主节点发出发送配置数据的请求消息；

主节点接收到所述请求消息，将预先保存的所述从节点对应的所有配置数据发送给所述从节点，所述配置数据包括跟踪节点为所述从节点的所有消息跟踪信息。

3、如权利要求1或2所述的分布式管理***的消息跟踪方法，其特征在于，若所述***发生重启时，主节点向每个从节点发送跟踪节点为该从节点的所有消息跟踪信息。

4、如权利要求1或2所述的分布式管理***的消息跟踪方法，其特征在于，步骤(4)中消息跟踪过滤器将符合条件的消息发送至维护台具体为：

当消息跟踪过滤器获知用户已设置限制过长标志，则判断符合过滤条件的消息的长度是否大于预先设定的阈值，若是，则从所述消息中截取所述阈值长度的信息，并将所述信息发送至维护台，否则将所述消息发送至维护台。

5、如权利要求1或2所述的分布式管理***的消息跟踪方法，其特征在于，步骤(4)还包括，当跟踪节点的CPU占用率超过告警阈值时，则跟踪节点不进行侦听和捕获，以防对***性能造成过重负担。

6、如权利要求1或2所述的分布式管理***的消息跟踪方法，其特征在于，还包括：在前台设置备用节点，所述备用节点分别连接主节点和各个从节点，并且备节点本身也作为主节点的从节点存在。

7、如权利要求6所述的分布式管理***的消息跟踪方法，其特征在于，步骤(2)还包括：主节点将所述消息跟踪信息发送至备用节点，以便备用节点将所述消息跟踪信息保存在备用节点的***消息跟踪存储区，当新增、修改、删除***消息跟踪信息时，主节点会将更新信息同步发送到备用节点上，备用节点上电或重启时，主节点也会自动将***消息跟踪信息同步备份到备用节点上。

8、如权利要求7所述的分布式管理***的消息跟踪方法，其特征在于，还包括：定时检测主节点的***消息跟踪存储区和备用节点的***消息跟踪存储区中数据的一致性，若一致，则退出，否则，更新备用节点的***消息跟踪存储区中的数据以便与主节点的***消息跟踪存储区中数据一致。

9、如权利要求1或2所述的分布式管理***的消息跟踪方法，其特征在于，步骤(3)中还包括：跟踪节点采用二级链表结构保存接收到的消息跟踪信息，第一级链表为所述跟踪节点的所有跟踪对象，第二级链表为每个跟踪对象所有消息跟踪信息。

10、如权利要求1所述的分布式管理***的消息跟踪方法，其特征在于，所述消息跟踪信息包括跟踪节点标识、跟踪对象标识、交互方节点标识、交互方对象标识、跟踪消息类型及是否限制过长消息标志。

11、如权利要求1所述的分布式管理***的消息跟踪方法，其特征在于，***消息跟踪存储区是以节点为索引建立各个节点的节点消息跟踪表，所述节点消息跟踪表用以保存本节点上跟踪对象的消息跟踪信息。