用于生成网络依赖性的方法和装置与流程

本发明的实施例涉及生成对于给定网络拓扑的网络依赖性。

背景技术：

网络拓扑通常描述网络内的网络元件的布置。网络的网络拓扑可以描绘网络元件的放置，包括设备位置和/或网络元件之间的连接的安装。网络拓扑还可以图示在网络内的不同的网络元件之间如何传输数据。

技术实现要素：

根据第一实施例，一种方法可以包括通过轮询引擎确定根。该根可以包括网络的节点群集内的第一节点。该方法还可以包括在根与第二节点之间生成至少一个网络依赖性。所生成的至少一个网络依赖性对应于网络的节点之间的连接。所生成的至少一个网络依赖性对应于从轮询引擎到第二节点的定向路径。该方法还可以包括轮询第二节点。该轮询经由在轮询引擎与第二节点之间已经生成的至少一个网络依赖性而发生。该方法还可以包括确定第二节点是不可到达的。该方法还可以包括：如果第二节点的父节点中的任何父节点被确定为由轮询引擎可到达，则生成与不可到达的第二节点有关的激活警报。

在第一实施例的方法中，确定根可以包括：基于用户定义和轮询引擎的本地信息中的至少一个来确定根。

在第一实施例的方法中，在轮询引擎与第二节点之间已经添加至少一个手动添加的依赖性。

在第一实施例的方法中，至少一个手动添加的依赖性具有超过至少一个自动生成的依赖性的优先级。

在第一实施例的方法中，至少一个自动生成的依赖性与至少一个手动添加的依赖性不冲突。

根据第二实施例，一种装置可以包括至少一个处理器。该装置还可以包括至少一个存储器，其包括计算机程序代码。该至少一个存储器和该计算机程序代码可以被配置为与至少一个处理器一起使得装置至少确定根。该根可以包括网络的节点群集内的第一节点。还可以使得该装置在根与第二节点之间生成至少一个网络依赖性。所生成的至少一个网络依赖性对应于网络的节点之间的连接。所生成的至少一个网络依赖性对应于从装置到第二节点的定向路径。还可以使得该装置轮询第二节点。该轮询经由在装置与第二节点之间已经生成的至少一个网络依赖性而发生。还可以使得该装置确定第二节点是不可到达的。还可以使得该装置如果第二节点的父节点中的任何父节点被确定为由装置可到达，则生成与不可到达的第二节点有关的激活警报。

在第二实施例的装置中，确定根可以包括：基于用户定义和装置的本地信息中的至少一个来确定根。

在第二实施例的装置中，在装置与第二节点之间已经添加至少一个手动添加的依赖性。

在第二实施例的装置中，至少一个手动添加的依赖性具有超过至少一个自动生成的依赖性的优先级。

在第二实施例的装置中，至少一个自动生成的依赖性与至少一个手动添加的依赖性不冲突。

根据第三实施例中，计算机程序产品可以被实现在非暂态计算机可读介质上。该计算机程序产品可以被配置为控制处理器以执行方法，包括通过轮询引擎确定根。该根可以包括网络的节点群集内的第一节点。该方法还可以包括生成根与第二节点之间的至少一个网络依赖性。所生成的至少一个网络依赖性对应于网络的节点之间的连接，并且所生成的至少一个网络依赖性对应于从轮询引擎到第二节点的定向路径。该方法还可以包括轮询第二节点。该轮询经由在轮询引擎与第二节点之间已经生成的至少一个网络依赖性而发生。该方法还可以包括确定第二节点是不可到达的。该方法还可以包括如果第二节点的父节点中的任何父节点被确定为由轮询引擎可到达，则生成与不可到达的第二节点有关的激活警报。

在第三实施例的计算机程序产品中，确定根可以包括：基于用户定义和轮询引擎的本地信息中的至少一个来确定根。

在第三实施例的计算机程序产品中，在轮询引擎与第二节点之间已经添加至少一个手动添加的依赖性。

在第三实施例的计算机程序产品中，至少一个手动添加的依赖性具有超过至少一个自动生成的依赖性的优先级。

在第三实施例的计算机程序产品中，至少一个自动生成的依赖性与至少一个手动添加的依赖性不冲突。

附图说明

为了对本发明的适当的理解，应当对附图进行参考，其中：

图1图示了根据本发明的某些实施例的包括轮询引擎的示例网络拓扑。

图2图示了根据本发明的某些实施例的轮询引擎与网络节点之间的路径。

图3(a)图示了根据本发明的某些实施例的确定中心节点/根和群集的依赖性。

图3(b)图示了根据某些实施例的确定针对每个节点群集/组的根。

图3(c)图示了根据某些实施例的用于计算针对群集的根的示例程序。

图3(d)图示了根据某些实施例的根据轮询器本地信息确定根。

图4图示了自动地生成依赖性同时避免生成与用户定义的依赖性冲突的依赖性的过程。

图5图示了根据本发明的某些实施例的将所生成的依赖性存储在表内。

图6图示了根据本发明的某些实施例的移除对应于依赖性的条目。

图7图示了根据本发明的某些实施例的允许用户忽略自动生成的依赖性的接口。

图8图示了根据本发明的某些实施例的允许用户启用或禁用自动生成依赖性的方法的接口。

图9图示了根据本发明的某些实施例的允许用户管理已经被用户配置和已经被自动生成的不同的依赖性的示例接口。

图10图示了根据本发明的某些实施例的示例依赖性树。

图11图示了根据本发明的某些实施例的用于计算拓扑并且确定自动依赖性的过程。

图12图示了根据本发明的某些实施例的计算针对给定轮询器的群集的依赖性。

图13图示了根据本发明的某些实施例的方法的流程图。

图14图示了根据本发明的某些实施例的装置。

图15图示了根据本发明的某些实施例的装置。

具体实施方式

本发明的某些实施例可以涉及用于生成给定网络拓扑的节点之间的依赖性的方法和装置。生成依赖性通常指代确定和/或认定网络的至少两个节点之间的关系，其中一个节点依赖于至少一个其他节点。换句话说，所生成的依赖性可以是网络拓扑内的节点到节点连接。网络拓扑通常指代网络的节点如何连接到彼此的表示。某些实施例可以在不要求任何附加用户输入的情况下自动地生成针对给定网络拓扑的依赖性。某些实施例可以通过将算法应用在给定网络拓扑上自动地生成依赖性。对于某些实施例而言，用户可以定义节点群集/组，其中依赖性存在于群集/组的节点之间。某些实施例还可以涉及确定每簇/组节点的根节点，如下文更详细描述的。某些实施例可以自动生成每群集/组内的依赖性，并且可以确保在所生成的依赖性内没有冲突并且没有不一致性。

网络设备(诸如轮询引擎)可以与网络内的节点通信。轮询引擎可以与节点通信以例如确定节点的状态、确定节点的操作特性和/或确定节点的可用性。当生成依赖性时，所生成的依赖性可以对应于轮询引擎与相关节点之间的所确定/所认定的路径。轮询引擎可以使用路径来到达相关节点。

图1图示了包括轮询引擎110的示例网络拓扑100。如上文所描述的，轮询引擎通常执行网络设备的状态的检查以确定网络设备处于什么状态和/或执行网络设备是否仍然与网络通信的检查。网络拓扑100可以包括多个群集(151、152和153)。每个群集可以对应于整个网络的不同的部分。一个群集可以是总部群集，同时另一群集可以是分支群集。某些连接/设备可能不是立即明显的。例如，虚线140指示总部与分支之间的网络设备/连接在拓扑100中是不可见的。总部与分支之间的网络设备可以可能地不由轮询引擎监测，这是因为用户可能地不具有对他们的访问。用户可以可能地不具有对总部与分支之间的网络设备的访问，这是因为服务提供商可能在控制这样的网络设备。节点可以在每个群集内部被连接，同时在群集自身之间可能不存在可见的连接。

图2图示了根据某些实施例的轮询引擎与网络节点之间的路径。如上文所描述的，当自动生成依赖性时，生成过程可以确定轮询引擎可以跟随以到达网络节点的路径。例如，轮询引擎210可以跟随去往到达节点250的路径。由不同的轮询引擎(210、220)跟随以到达给定节点的路径可以是不同的。例如，从轮询引擎210至到达节点250的路径与从轮询引擎220至到达节点250的路径不同。如此，某些实施例可以针对每个轮询引擎确定到达每个网络节点的路径。

如此，当确定轮询引擎与给定节点之间的路径时，所生成的每个依赖性(例如，在两个节点之间)可以是路径中的定向步骤。可以存在从一个轮询引擎到给定网络节点的多个路径。

两个节点之间的一种类型的依赖性关系是父节点对子节点关系，其中子节点依赖于父节点。再参考图2，父节点240具有多个子节点(节点250和节点260)。在父节点240发生故障(使得父节点240通过网络不能到达或通信)的情况下，父节点240的子节点250继续由网络轮询。即，轮询引擎210可以仍然尝试与子节点250通信。由于子节点250看起来也发生故障(作为父节点240实际上发生故障的结果，子节点250是由轮询引擎210不可到达的)，因而轮询引擎可以激活网络警报以指示子节点250发生故障。轮询引擎可以生成警报，并且用户接口(UI)可以将警报显示给用户。用户可以利用web浏览器或特殊工具(诸如例如警报中心)来查看警报。在轮询引擎不能到达子节点250的情况下，检查子节点的相关联的依赖性，并且从所检查的依赖性导出子节点的父节点或组。然后，如果子节点的所有父节点发生故障，则某些实施例确定节点250的状态是不可到达的。如果警报被配置为当节点状态改变到发生故障时生成，并且如果节点250的状态被确定为不可到达的，则不由轮询引擎生成警报，如上文所描述的。如果未确定依赖性，则无论何时轮询引擎不能到达节点250，节点250的状态将被认为是发生故障。在这种情况下，如果警报被配置为当节点状态改变到发生故障时生成，那么通过轮询引擎生成这样的警报。

然而，在子节点由于对应的父节点发生故障而不可到达的情况下，由于问题在于父节点，因而应当忽略与子节点有关的激活警报。对于某些实施例而言，生成/激活警报可以包括两个步骤。第一步骤是确定子节点的节点状态。第二步骤是当已经满足用于生成警报的条件时而生成警报。存在处理警报的至少两个方式。利用处理警报的第一方式，生成的仅有警报是旨在由用户查看的警报。利用该方法，如上文所指定的，当节点250不能由轮询引擎到达并且其所有父节点发生故障时，其节点状态是不可到达的。因此，针对该不可到达的节点未生成警报，这是因为用于生成警报的条件是发生故障的节点状态。当节点状态改变到不可到达时，尚未满足用于生成警报的条件，并且因此未生成警报。利用处理警报的第二方式，首先生成警报，并且然后如果用户不应当查看所生成的警报，则忽略所生成的警报。可能的是，当轮询引擎不能到达节点250时生成警报，并且然后当进一步的处理指示节点250的父节点全部发生故障时忽略警报。在其中所生成的一些警报将被忽略的这样的情况下，与子节点有关的激活警报应当由轮询引擎忽略以便避免利用激活警报充满网络。轮询引擎还应当避免激活针对子节点的网络警报。

父节点可以是中心节点(诸如例如边缘路由器)。如上文所描述的，当网络的中心节点发生故障时，轮询引擎可能不能够到达/通信被配置在发生故障的中心节点后面(即，被配置为依赖于的)节点。

如上文所描述的，与被配置在发生故障的中心节点后面的节点有关的激活警报应当由轮询引擎忽略，以便避免警报的泛滥。如此，某些实施例可以首先通过标识被配置在中心节点后面的节点来标识依赖节点。与针对被配置在中心节点后面的所有节点生成警报相反，某些实施例可以然后仅针对中心节点生成警报。

鉴于上文，当节点是不可到达的时，某些实施例可以基于由轮询引擎(即，被分配给不可到达的节点的轮询引擎)已知的依赖性，确定针对该不可到达的节点的所有父节点。如果(节点的)父节点中的任何父节点是正常的/可到达的，那么不可到达的节点的状态被认为是“发生故障的(down)”。另一方面，如果所有父节点发生故障，那么节点的状态将被认为是仅“不可到达的(unreachable)”，并且可以忽略来自这样的节点的激活警报。利用某些其他实施例，如果针对不可到达的节点的所有父节点发生故障，那么未针对不可到达的节点生成警报。

某些实施例可以执行/运行算法以便在需要时或根据规律间隔自动生成网络依赖性，使得所生成的依赖性是最新的。某些实施例还可以允许用户手动添加依赖性。虽然依赖性的手动配置通常是繁琐的并且虽然手动配置通常地不能适当地适于改变网络拓扑，但是本发明的某些实施例可以提供实现手动配置的有效方法。特别地，某些实施例可以集成自动生成依赖性的功能连同其中用户配置依赖性的功能。对于某些实施例而言，用户定义/用户配置的依赖性可以取得超过自动生成的依赖性的优先级。

在生成依赖性时，如上文所描述的，某些实施例可以抑制某些警报，可以导出基于拓扑的组，并且可以报告节点可用性。关于导出基于拓扑的组，用户可能想要定义包含直接或间接地(递归地)依赖于特定节点的所有节点的组。利用自动确定依赖性(即，“自动依赖性”)，某些实施例可以确定该节点作为父节点直接或递归的所有依赖性，并且然后那些依赖性中的所有子代在该组中。例如，用户可以将对该组的访问许可分配给账户或基于组状态定义警报条件。这允许用户管理组级别而不是节点级别上的网络设备。如上文所描述的，所生成的依赖性可以被用于适当的节点状态(即，关于节点状态是否“发生故障”或仅“不可到达的”)。

某些实施例的算法可以处理具有多个轮询引擎的场景。

每个节点可以被分配给不同的轮询引擎，并且节点与轮询引擎之间的分配可以随时间改变。在任何时刻，节点通常被分配给单个轮询引擎。通常不可能的是，用户分配超过一个轮询引擎以对来自给定节点的数据进行轮询。在不同的时间处，用户可以改变配置，并且让另一轮询引擎对给定节点进行轮询。

图3(a)图示了根据某些实施例的确定中心节点/根和群集的依赖性。拓扑连接可以是某些实施例的计算的输入，并且自动生成的依赖性可以是输出。某些实施例可以确定其中连接群集内的节点的节点群集。在步骤310处，某些实施例可以确定每个群集的根节点。对于每个轮询引擎而言，某些实施例可以确定每个群集的根节点。根节点可以对应于群集中的其他节点所依赖的的节点(诸如例如父节点)。根节点可以然后保存在AutoDependencyRoot表内。为了确定群集的根节点，自动生成依赖性的过程可以首先确定最接近特定轮询引擎(其然后被确定为群集的根)的节点。该过程可以然后构建/生成从所确定的根节点开始的每个群集内的依赖性。换句话说，某些实施例可以确定从所确定的根节点到群集中的其他节点的路径。依赖性可以然后保存在Dependency表内。

关于手动配置依赖性，某些实施例可以允许用户通过添加从所生成的依赖性的集合缺少的依赖性来手动地调节依赖性。某些实施例还可以校正错误的自动生成的依赖性。例如，如果拓扑连接出于任何原因是错误的(其中例如节点1未连接到节点2，但是拓扑数据示出节点1连接到节点2)，那么自动生成的依赖性可能是错误的，或者依赖性的方向可能是错误的。用户可以通过添加用户定义的依赖性对此进行改正。用户还可以忽略不需要的依赖性。对于某些实施例而言，用户可以调节由自动生成过程所执行的计算：(1)允许用户配置的依赖性采取超过自动生成的依赖性的优先级，和/或(2)避免生成用户依赖性与自动生成条目之间的循环依赖性回路。循环依赖性回路对应于一系列依赖性，其中每个节点取决于相同系列依赖性中的另一节点。

图3(b)图示了根据某些实施例的确定针对节点的每个群集/组的根。第一，某些实施例可以确定节点的群集/组。群集可以包括基于拓扑连接到彼此的节点。在一个群集中的节点与不同群集中的另一节点之间可以不存在(如由拓扑所反映的)连接。第二，某些实施例可以根据以下过程确定针对每个群集的根(一旦确定根，则过程可以停止)。某些实施例可以确定针对给定群集的用户定义根。例如，某些实施例可以从地址解析协议(ARP)表得到根。某些实施例还可以从轮询引擎的默认网关得到根。当确定特定群集的根时，某些实施例可以跟踪从轮询引擎到群集中的节点的路由。最接近轮询引擎的节点可以被确定为是群集的根。例如，参考图1，轮询器1可以是总部，并且某些实施例可以确定针对群集“分支办公室B”中的轮询器1的根。轮询器1可以向节点10发出跟踪路由，并且跟踪路由的路径可以包括“轮询器1、节点1、节点2、节点8、节点9、节点10”。如此，节点8可以是针对群集“分支办公室B”中的轮询器1的根，因为节点8是从“分支办公室B”内到轮询器1最接近的节点。

图3(c)图示了根据某些实施例的用于计算针对群集的根的示例程序。首先，某些实施例可以确定来自轮询器的列表的拓扑的轮询器。接下来，某些实施例可以来自根据轮询器的列表中的要处理的轮询器。某些实施例可以处理利用群集内的超过一个节点对群集进行轮询的轮询器。如果存在群集中的、针对轮询器的用户定义根，那么用户定义根可以被确定为是该群集中的、针对该轮询器的根。如果不存在任何用户定义根，则某些实施例可以使用来自轮询器的本地信息来确定群集的根。如上文所描述的，某些实施例还可以使用跟踪路由来确定群集的根。

图3(d)图示了根据某些实施例的根据轮询器本地信息来确定根。首先，可以从轮询器的ARP表确定与轮询器相邻的节点。接下来，如果相邻的节点由轮询器监测，则某些实施例确定被监测并且具有与其他所监测的节点最多连接的相邻的节点。该相邻的节点可以被认为是针对轮询器的根。备选地，如果一个默认网关由轮询器监测，那么默认网关可以被认为是针对轮询器的根。

图4图示了自动地生成依赖性同时避免生成与用户定义的依赖性冲突的过程。在用户将节点420定义为依赖于节点410的情况下，那么某些实施例的自动生成过程将避免复制该用户定义的依赖性。参考图4，假设节点3被建立为节点1的依赖节点(在节点3与节点1之间建立依赖性)，那么某些实施例将避免生成节点2与节点3之间的依赖性。避免节点2与节点3之间的依赖性，这是因为节点3经由与节点1的依赖性已经是可到达的。而且，某些实施例的自动生成将还避免生成与用户定义的依赖性冲突的依赖性。例如，再参考图4，如果节点1被确定为依赖于节点2，那么某些实施例避免生成其中节点2依赖于节点1的依赖性。

某些实施例可以确保在依赖性内未形成循环依赖性回路。某些实施例还可以最小化通过仅保留对单次通过中的轮询引擎有用/相关的那些依赖性而被生成的依赖性的数目。单次通过可以一般地意指节点仅被处理一次以用于生成依赖性并且最小化依赖性的数目。备选方案是首先处理用于生成依赖性的给定节点。一旦完成针对所有节点的处理，那么再次处理相同节点以移除没有用的依赖性来最小化依赖性的数目。备选方案可以要求两次通过并且可以要求将所有所生成的依赖性保持在存储器中(其可以导致高存储器要求)或将所生成的依赖性保存到数据库中并且然后将其移除，其可能引起大量的数据库更新并且引起性能问题。下文描述了单次通过处理的细节。依赖性可以被确定为是有用/相关的，如下文更详细描述的。

如果依赖性在将轮询引擎连接到被分配给该轮询引擎的节点的路径内，则依赖性可以被确定为是对轮询引擎有用/相关的。如果没有依赖性的子代(和/或依赖性的递归子代)是被分配给轮询引擎的节点，则依赖性对轮询引擎不是有用/相关的。如果依赖性对轮询引擎不是有用/相关的，那么可以安全地移除依赖性。当节点未对来自其分配的轮询引擎的轮询请求作出反应，则所移除的依赖性将不被用于确定节点由于发生故障的父节点而是发生故障还是不可到达的。

当生成每个依赖性时，则依赖性可能是或可能不是有用的。如此，所生成的依赖性可以需要存储，直到已经处理依赖性的所有子代或者直到子代之一被分配给相关轮询引擎。如此，所生成的依赖性可以需要保持在存储器中。所生成的依赖性是否是有用的可能是未知的，直到已经处理所有子代(其被分配给该轮询引擎并且是依赖性的父节点的子代)或者直到子代之一被分配给相关轮询引擎。某些实施例可以确定何时已经处理父节点的所有子代，这是因为某些实施例可以跟踪已经处理分配给该群集内的该轮询引擎的节点个数，并且某些实施例可以知道该群集中的、被分配给该轮询引擎的节点的总数。在已经处理依赖性的所有子代之后，某些实施例可以然后认定子代中的任何是否被分配到给定轮询引擎，并且因此可以确定依赖性自身对给定轮询引擎是否是有用的。当子代之一被确定为被分配给相关轮询引擎时，依赖性可以被确定为是有用的。如果已经处理依赖性的所有子代，并且没有子代被确定为被分配给相关轮询引擎，那么依赖性可以被确定为不是有用的。

鉴于上文，某些实施例可以计算/生成针对给定轮询引擎的群集内的依赖性，并且某些实施例可以计算/生成群集中的根节点。

某些实施例可以基于未来输入执行过滤。某些实施例可以集成第2层和第3层路径以生成紧密地类似网络的真实性的依赖性。第2层连接示出了关于如何连接节点的较多细节，但是节点不是连续的。第3层示出了关于如何连接节点的较小细节，但是其在群集中是连续的。例如，在图2中，第2层连接示出了节点3被连接到节点4，并且节点4被连接到节点5。第2层连接未示出节点1被连接到节点3，这是因为节点1和节点3二者是路由器。第3层连接仅示出了节点3直接被连接到节点5，这是因为节点4是交换机并且在第3层连接中不是可见的。从节点3到节点5的实际路径是从节点3到节点4并且然后到节点5。图12示出了如何使用第2层连接和第3层连接来构建整个路径。

某些实施例可以自动处理其中网络是不连续的网络的情况。不连续的网络可以通常指代不是对用户完全可访问/可控制的网络。网络的一部分可以不是对用户完全可访问/可控制的，这是因为该部分可以由例如服务提供商控制。为了处理其中网络是不连续的网络的情况，某些实施例可以找到针对每个轮询引擎和每个群集的根，如上文所描述的。图5图示了将所生成的依赖性存储在表510内。在使能依赖性的自动生成时，可以迅速地生成依赖性(511、512、513、514等)。新生成的依赖性可以出现在表510(诸如例如Orion.Dependencies表)中。在禁能依赖性的自动生成时，可以从Orion.Dependencies表迅速地移除先前生成的依赖性。当设置被改变到禁能活使能依赖性的自动生成时，设置的改变可以触发审计事件。

图6图示了根据本发明的某些实施例的移除依赖性的条目。某些实施例可以允许用户管理自动生成的依赖性。某些实施例可以既不允许用户编辑也不允许用户删除自动生成的依赖性。然而，用户可以忽略某些依赖性。可以从Orion.Dependencies表610移除忽略的条目(诸如条目611)。用户可以决定自动生成条目是否应当忽略(未示出在Dependencies表中)。例如，用户可以决定如果用户知道这样的依赖性不存在，则忽略自动生成的条目。例如，用户可以知道节点4未被连接到节点5，但是拓扑可以是错误的，并且不正确的拓扑可以包括节点4与节点5之间的连接。然后，当Auto Dependency(自动依赖性)生成条目611时，用户可以通过忽略条目611来改正该问题。如果存在节点4与节点5之间的连接，其指示节点5依赖于节点4，但是节点4实际上依赖于节点5，那么用户可以通过添加用户配置的依赖性(其中，父节点是节点5，并且子代是节点4)校正该问题。由于条目可以对应于作为依赖性612的复制的依赖性，因而可以忽略条目611。忽略的依赖性将不影响与忽略的依赖性有关的节点的状态。例如，忽略的依赖性可以示出在图7的标签“管理忽略的依赖性(Manage Ignored Dependencies)”730下。

图7图示了允许用户忽略自动生成的依赖性的接口710。接口710允许用户管理依赖性。接口710可以包括允许用户忽略一个或多个自动生成的依赖性的窗口720。

图8图示了根据某些实施例的允许用户启用或禁用自动生成依赖性的方法的接口810。对于某些实施例而言，可以通过具有管理员权限的用户启用或禁用自动生成依赖性的过程。用户可以经由例如轮询设置(Polling Setting)页/管理依赖性(Manage Dependencies)页启用/禁用功能性。

对于某些实施例而言，如果网络拓扑虑及依赖性的自动生成，则可以启用依赖性的自动生成。某些实施例可以允许用户移除忽略的自动生成的依赖性。然而，作为移除忽略的自动生成的依赖性的结果，在执行后续计算/生成过程时，可以将这些自动生成的依赖性重新添加/重新列入Orion.Dependencies表中，并且忽略的自动生成的依赖性可以然后再次变得有效。

对于某些实施例而言，当用户忽略自动生成的依赖性时或当用户移除忽略的自动生成的依赖性时，可以生成审计事件。审计事件的一个示例涉及创建针对动作的事件并且将其添加到事件日志。因此，用户可以观看事件并记录事件，并且通知改变依赖性的动作。因此，动作可以记录在历史中并且可以稍后审计。

关于自动生成依赖性的功能，以下配置信息可以存储在数据库中如下。第一，条目可以指示是否启用自动生成功能。可以启用或禁用条目(诸如“SWNetPerfMon-Settings-AutoDependency”)。

依赖性中的每个依赖性可以存储有以下参数中的一些或全部参数。每个依赖性的一个参数可以是“AutoManaged”参数。该参数可以指示对应的依赖性/条目是否是被自动生成的(即，其中参数被设定为“真”)或者对应的依赖性/条目是否是用户/手动定义的(即，其中参数被设定为“假”)。

每个依赖性的另一参数可以是“引擎ID(EngineID)”参数。该参数可以指示与依赖性相关联的轮询引擎。对于某些实施例而言，用户定义的依赖性可以与所有轮询引擎相关联。自动生成的依赖性可以通常与一个轮询引擎相关联。

针对每个依赖性的另一参数可以是“类别”参数。该参数可以指示依赖性的类型。

出于性能原因，可以针对每个依赖性添加一些其他参数。这些其他参数可以包括ParentEntityType，其指示依赖性的父节点的实体类型。另一参数可以包括ParentNetObjectID，其指示依赖性的父对象的标识符。另一参数可以包括ChildEntityType，其指示依赖性的子节点的实体类型。另一参数可以包括ChildNetObjectID，其指示依赖性的子对象的标识符。

对于某些实施例而言，新表可以是“AutoDependencyRoot”表。当计算依赖性时，可以使用该表。该表可以包含针对每个轮询引擎和群集计算的根节点。某些实施例还可以包括“DeletedAutoDependencies”表。该表可以包含忽略的自动生成的依赖性。

图9图示了允许用户管理已经被用户配置和已经被自动生成的不同的依赖性的示例接口910。接口910的每个条目911、912、913可以对应于不同的依赖性。弹出式窗口915可以图示每个依赖性的每个依赖节点的操作特性/可用性。

图10示出了示例依赖性树。对于某些实施例而言，用户可以查看已经通过使用可视化依赖性树生成的依赖性。用户可以然后确定自动生成的依赖性中的一些依赖性是否应当忽略。示例依赖性树内的每个条目可以对应于依赖性，并且每个条目可以包括依赖性的名称/标识符、依赖性的父节点以及依赖性的子节点。

图11图示了根据本发明的某些实施例的用于计算拓扑并且确定自动依赖性的过程。在步骤1处，用户可以触发计算(诸如例如根据需求计算)或者计时器可以触发计算(诸如例如周期性计算)。在步骤2处，可以计算拓扑，并且可以将拓扑连接存储到TopologyConnections表中。在步骤3处，基于从步骤2生成的连接，可以自动生成依赖性。

图12图示了根据本发明的某些实施例的计算针对给定轮询器的群集的依赖性。如上文所描述的，某些实施例可以集成第2层和第3层路径以生成紧密地类似网络的真实性的依赖性。图12示出了针对给定轮询引擎的处理流程并且示出如何组合第2层和第3层连接以生成详细依赖性来形成从轮询引擎到群集中的所有节点的路径。计算从针对给定轮询引擎的群集的根开始。直接连接到根的所有节点是其子代。首先针对N个步骤(例如，N的默认值可以是3个步骤)递归地计算使用第2层连接的依赖性。然后，计算使用第3层连接的依赖性。如果可以通过从第2层导出由依赖性到达节点，则将不从第3层导出依赖性以到达这样的节点。例如，在图2中，基于第2层连接，节点3具有子节点4(AutoDep-1-3-4-2)，并且节点4具有子节点5(AutoDep-1-4-5-3)。然而，基于第3层连接，节点3具有子节点5(AutoDep-1-3-5-2，由于轮询引擎可以使用第2层导出的依赖性通过节点4到达节点5，因而可以忽略该依赖性)。由于第2层提供连接性的更多细节，因而第2层依赖性可以采取超过第3层依赖性的优先级。

当处理分配给该轮询引擎的所有节点并且不可以生成更有用的依赖性时，检查该轮询器的经处理的节点的数目的条件试图最小化依赖性的数目。

图13图示了根据本发明的某些实施例的方法的流程图。在图13中所图示的方法包括在1310处通过轮询引擎确定根。该根包括网络的节点群集内的第一节点。该方法还可以包括在1320处生成在根与第二节点之间的至少一个网络依赖性。所生成的至少一个网络依赖性对应于网络的节点之间的连接。所生成的至少一个网络依赖性对应于从轮询引擎到第二节点的定向路径。该方法还可以包括在1330处轮询第二节点。该轮询经由在轮询引擎与第二节点之间已经被生成的至少一个网络依赖性而发生。该方法还可以包括在1340处确定第二节点是不可到达的。对于某些实施例而言，轮询的第二节点可以被确定为在轮询引擎发送出请求并且在超时发生之前未接收到响应之前而是不可到达的。该方法还可以包括在1350处如果第二节点的父节点中的任何父节点被确定为是由轮询引擎可到达的，则生成与不可到达的第二节点有关的激活警报。如果没有父节点是可到达的，则某些实施例不生成与不可到达的轮询节点有关的警报。

图14图示了根据本发明的某些实施例的装置。在一个实施例中，装置可以是网络节点，其被配置为执行例如轮询引擎的功能。轮询引擎可以在服务器上。轮询引擎可以是或可以不是网络设备。轮询引擎可以是终端主机。轮询引擎可以执行确定网络依赖性的功能。如果在系统中存在多个轮询引擎，则一旦对轮询引擎给定整个系统的拓扑，仅一个轮询引擎可能需要计算针对整个系统的依赖性。

图14的装置可以至少执行图13的方法。装置10可以包括用于处理信息和执行指令或操作的处理器22。处理器22可以是任何类型的通用或专用处理器。输入在图14中示出单个处理器22，但是根据其他实施例，可以利用多个处理器。处理器22还可以包括以下各项中的一项或多项作为示例：通用计算机、专用计算机、微处理器、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、专用集成电路(ASIC)和基于多核处理器架构的处理器。

装置10还可以包括耦合到处理器22的存储器14，其用于存储可以由处理器22执行的信息和指令。存储器14可以是适于本地应用环境的任何类型的一个或多个存储器，并且可以使用任何适合的易失性或非易失性数据存储技术(诸如基于半导体的存储器设备、磁性存储器设备和系统、光学存储器设备和系统、固定存储器和可移除存储器)而进行实现。例如，存储器14包括随机访问存储器(RAM)、只读存储器(ROM)、静态存储(诸如磁或光盘)或任何其他类型的非暂态机器或计算机可读介质的任何组合。存储器14中所存储的指令可以包括程序指令或计算机程序代码，其在由处理器22执行时使得装置10能够执行如本文所描述的任务。

装置10还可以包括用于将信号和/或数据发射到装置10和从装置10接收信号和/或数据的一个或多个天线(未示出)。装置10还可以包括收发器28，其将信息调制到载波波形上用于由(一个或多个)天线传输并且解调经由(一个或多个)天线所接收的信息，以用于由装置10的其他元件进一步处理。在其他实施例中，收发器28可能能够直接发射和接收信号或数据。

处理器22可以执行与装置10的操作相关联的功能和装置10的总体控制，所述装置10的操作包括但不限于天线增益/相位参数的预编码、形成通信消息的单独比特的编码和解码、信息的格式化，并且所述装置10的总体控制包括与通信资源的管理有关的过程。装置10还可以以插入网络中的网络卡的形式操作为收发器。

在实施例中，存储器14可以存储当由处理器22执行时提供功能性的软件模块。该模块可以包括提供针对装置10的操作系统功能的操作系统15。该存储器还可以存储用于提供针对装置10的附加功能的一个或多个功能模块18(诸如应用或程序)。可以以硬件或作为硬件和软件的任何适合的组合实现装置10的部件。

图15图示了根据本发明的某些实施例的装置。例如，装置1500可以是网络元件/实体(诸如网络节点)，其被配置为作为轮询引擎执行。装置1500可以包括确定根的第一确定单元1510。该根包括网络的节点群集内的第一节点。装置1500还可以包括第一生成单元1520，其生成在根与第二节点之间的一个网络依赖性。所生成的至少一个网络依赖性对应于网络的节点之间的连接。所生成的至少一个网络依赖性对应于从轮询引擎到第二节点的定向路径。装置1500还可以包括轮询单元1530，其轮询第二节点。该轮询经由在轮询引擎与第二节点之间已经被生成的至少一个网络依赖性而发生。装置1500还可以包括第二确定单元1540，其确定第二节点是不可到达的。装置1500还可以包括第二生成单元1550，如果第二节点的父节点中的任何父节点被确定为是由装置1500可到达的，则第二生成单元1550生成与不可到达的第二节点有关的激活警报。

在一个或多个实施例中，可以以任何适合的方式组合本发明的所描述的特征、优点和特性。相关领域的技术人员将认识到，可以在没有特定实施例的特定特征或优点中的一个或多个的情况下实践本发明。在其他实例中，可以在不存在于本发明的所有实施例中的某些实施例中认识到附加特征和优点。本领域的普通技术人员将容易理解到，可以利用以不同的顺序的步骤和/或利用与所公开的那些配置不同的配置中的硬件元件来实践如上文所讨论的本发明。因此，虽然基于这些优选的实施例已经描述了本发明，但是对于本领域的技术人员而言将明显的是，在保持在本发明的精神和范围的情况下，一些修改、变化和备选构造将是明显的。