利用管理工具查错.docx

利用管理工具查错.docx

《利用管理工具查错.docx》由会员分享，可在线阅读，更多相关《利用管理工具查错.docx（16页珍藏版）》请在冰豆网上搜索。

利用管理工具查错

利用恒生金融基础件统一管理平台排错

系统运行检查

启动检查

管理工具连接到一套环境中的某个总线AR上进行管理。

一套环境中所有的中间件实例全部启动之后，首先通过拓扑图的界面可以查看所有的节点是否已经启动成功，是否连接成功，在工具右下角会显示管理工具的链接状态和连接节点的名字。

如图一所示：

图一：

拓扑图界面

拓扑图上首先查看所有的节点是否已经存在，拓扑图的排列是有顺序，如上图所示。

然后右键，有一排菜单，先自动配置节点树，方便以后管理，接下来有两件事要做：

1、中间件版本检查、业务版本检查，这两个按钮会返回当前拓扑图上的所有实例的中间件的库以及业务版本的库是不是都是一样。

2、查看是不是有重名节点，这个主要是要检查某个实例下面有没有重名的邻居，需要检查某点，就在某个点上右击选择“邻居节点重名检查”。

如果环境很复杂，有很多营业部的节点，如果觉得在拓扑图上实例太多的话，可以通过设置过滤条件，省略那些不用关心的节点。

连接检查

所有节点启动之后，首先检查连接是否都成功，就是说上下级之间关系是否正确以及完整。

这个可以通过任意节点管理界面检查。

如图二所示。

在树形图里面显示了所有节点，如果有下级的点，就可以展开子树看连接下级情况。

图二：

任意节管理界面

数据库检查

所有节点都启动成功之后，需要检查一下原子AS数据库的连接情况，在左边的节点树上选择需要检查的原子，双击，然后选择数据库TAB页。

如图三所示。

通过这个页面可以看到数据库的连接情况，查看数据库连接是否正常。

图三：

数据库界面

内存数据库检查

数据库连接都成功之后，就再检查一下内存数据库的情况，检查数据库是否已经同步成功。

，需要检查一下原子AS数据库的连接情况，在左边的节点树上选择需要检查的原子，双击，然后选择内存数据库TAB页。

如图四所示。

图四：

内存数据库界面

监控

启动没有问题之后，接下来就是开启监控，实时监控所有节点，在左右的节点树，选择你需要监控的那套环境，右键选择监控，如图五所示。

如果监控点正常就会是绿色图标显示，如果监控节点不在或者和这个节点通信有问题，那么就会变成红色的图标。

日志区域，如果有错误也会报警。

图五：

监控界面

注意：

如果怀疑某个实例的t2通道有问题，可以通过管理客户端去连那个实例的t2通道，看看是否可以连上，这样可以检测t2通道是否正常。

如果通过总线AR去管理某点发现无法管理的时候，也可以让管理客户端直连那点去管理。

监控还要包括积压的监控，监控界面如图六所示。

这个监控主要是监控proc插件的积压情况，显示出来的数据是proc所有线程积压数和请求数的和。

最大可以容纳的请求的上限是proc的线程数和队列的上限之积，如果积压太大，就需要增加线程或者增加队列上限，否则客户端就会收到“系统忙，缓存空间已满”的错误应答，业务请求就会被抛弃。

图六：

积压监控界面

如何查看proc的线程数和队列的上限，通过双击左边节点树需要查看的节点，然后点击“业务处理”这个TAB页。

如图七所示。

只有逻辑和原子才会有业务处理界面。

点击刷新按钮可以看到实时积压情况。

图七：

具体的业务积压界面

节点管理

中间件的所有管理信息都是来自每个插件的管理功能，管理工具上的哥哥界面只是把管理工具的结果显示出来了。

如果想查看某个节点的所有插件的所有管理功能，可以选择查看节点双击，选择核心这个TAB页。

如图八所示。

图八：

节点所有插件管理界面

点击保存查询结果之后，会返回文件保存的目录信息。

如下图所示：

所有节点管理

当然我们也可以通过一个就界面对一套环境中所有节点的所有插件做管理。

就是前面提到的任一节点管理按钮。

如图九所示。

图九：

任意节点所有插件管理界面

常见问题检查

如果前台操作发现异常，可以根据不同的异常，然后通过管理工具检查不同的界面，收集各种数据来排除异常。

如果柜台操作发现异常，首先通过柜台的通信日志，可以查看具体的错误信息，对于除了接受超时之外的错误一般都会有具体的信息返回，同时上面还可以看到错误是由哪个中间件节点返回的。

柜台的通信日志界面如图十所示：

图十：

柜台通信日志界面

问题一：

转发错误

错误查找

转发错误有两种情况，一种会报TTL为0，可能配置了环路，还有一种就是转发错误。

对于这种情况，首先通过前台的日志，可以找到返回错误的节点是哪个，然后再通过管理功能去查看这个节点路由的配置。

首先在左边节点树上找到你需要查看的节点，双击然后选择路由TAB页。

如图十一所示：

注意：

如果是指定路由，就直接查看请求中指定的路由节点是那个，这样就不需要查看这个节点的路由信息，直接查看邻居信息。

图十一：

路由信息

通过前台看无法转发的请求的功能号、系统号、子系统号、营业部号这四个信息，对照路由表，找到目标节点，路由优先级由上到下依次递减。

找到目标就节点之后，就看看邻居信息有没有这个节点，如图十二所示：

图十二：

邻居节点信息

出现这个错误，目标节点不会再邻居信息中存在，那么接下来就看一下需要看一下拓扑结构，看看目标节点是不是真的不可达。

拓扑需要看ospf插件的管理功能，就是选择核心里面的ospf的1号管理功能（GetTopo），如图十三所示：

图十三：

ospf的1号管理功能

在拓扑结构中看看目标节点是不是通过这个节点是否可以到达。

最后还要看一下静态网关，最后通过Router的11号管理功能（GetGatewayInfo），看看有没有静态网关。

图十四：

Router的11号管理功能

如果拥有静态网关，就需要查看静态网关这点是否可达，这个顺序也是先看邻居，再ospf拓扑。

对于如果是返回TTL为0的转发错误。

那就需要查看请求从进入点开始到最后返回错误的应答点之间所有节点的路由配置，步骤和前面的检查一样，这样一步一步下来可以找到循环的路径。

如果目标节点应该是自己的邻居，结果邻居信息中有没有这个节点的信息，那么就需要看看f2的管理功能，首先看上级的地址信息，f2的8号管理功能（GetParentAddress）。

图十四：

f2的8号管理功能

看看这个列表里面有没有目标节点的信息，看看地址是否正确，状态是否为2，如果状态为0表示上级没开，如果状态为1，表明正在连接，但是连不上，那么可以看下日志，里面有记载连接不上的原因。

当然最直接就是打开配置文件和nrs.xml检查一下，配置是否正确。

中间件的日志查看也可以通过管理工具来看，查看远程的日志，需要配置一下，如图十四所示。

在左侧选择你需要查看的那个节点，右击选择属性修改。

注意：

查看服务端的日志，必须保证一点：

后台中间件机器时间和你打开管理客户端的机器的时间必须是同一天，否则只有通过ssh取下来，打开本地文件查看了。

图十五：

属性修改界面

这样填写之后然后确定，接下来会有一个确认界面弹出，选择否。

如图十六所示。

图十六：

确认界面

这些配置都成功之后，就可以双击需要查看的节点，选择中间件日志的TAB页。

如图十七所示。

图十七：

中间件日志查看界面

解决办法

1、解决办法就是更改路由错误那个中间件的路由配置。

2、如果需要连接的邻居没有连上，那么就查看f2的上级连接以及nrs.xml的配置。

3、修改完中间件重启，对于之前连接没有成功，需要关注界面打印，看看节点连接建立的信息有没有打印，如果还是拒绝连接，那么可以查看log文件件下面的日志，可以看到具体连接不上的错误原因。

问题二：

无此功能

错误查找

对于前台返回这种错误时，一般就是指返回应答的那个节点上没有加载对应的功能号的业务插件。

每个节点加载的功能号可以业务处理的功能列表里面可以看到，如图十八所所示。

图十八：

功能列表查看界面

解决办法

找到指定的功能对应的业务组件，然后在需要加载的节点上增加一个proc的组件配置，如下所示：

问题三：

业务错误

错误查找

前台返回业务错误，有两种原因，一种是前台操作不对，后台业务返回异常；另一种就是后台数据库操作错误。

这种错误现在已经屏蔽了，前台不会明显看到后台数据库错误。

对于后面这样情况就需要查看业务日志。

业务日志也可以通过管理工具查看。

选择返回错误应答的节点，双击，选择业务日志的TAB页。

如图十九所示。

在这里可以检索你失败的那个功能号的请求，看到具体的oracle错误信息。

图十九：

业务日志查看界面

解决办法

找到错误功能号对应的业务插件，由业务插件的开发人员解决。

问题四：

接收超时

错误查找

接收超时，一般就是请求出去了，没有应答回来。

这需要跟踪到请求或者应答到哪个节点，被哪个插件给抛弃了。

这种情况比较复杂，可以借助filter_log插件抓包来找到消息丢弃的源头。

这需要在消息流水线上配置了过滤器才行。

是否配置了流水线可以通过管理工具来查看。

双击需要抓包的哪个节点，打开消息过滤的TAB页。

必须要选择流水线视图。

如图二十所示。

图二十：

流水线日志查看界面

出现这种问题的时候，一般要从最源头开始，追根溯源。

就是说首先在客户端接入的ar那点，在t2或者t1流水线加filter_log，然后出去的f2流水线上也加上filter_log。

然后一路追踪下去，所有经过的点上f2流水线上都加上filter_log，如果是逻辑和原子，还需要在proc的流水线上加上filter_log。

所有都配置好之后，再由柜台发出请求，然后查看每个节点的消息过滤界面，通过抓下来的业务报文中找到对应的请求，看看最终在哪点被丢弃了。

对于filter_log抓包我们可以设置一下记录规则，这样可以只记录我们需要跟踪的报文。

记录规则的添加如图二十一、二十二所示。

图二十一：

记录规则右键

图二十二：

记录规则添加界面

如上图设置规则之后，filter_log只会记录功能号为620001的请求。

对于不能重现的情况，或者是在生产环境（流水线没有添加fiter_log），那么利用filter_log就不太可能了。

如果前台是通过t1通道接入的话，我们可以通过ac插件的抓包功能来检查请求和应答情况。

Ac默认是没有开启抓包功能的，首先要在管理界面上开启，在左边节点树上双击客户端接入的那个节点，选择接入控制，如图二十三所示。

图二十三：

开启AC抓包界面

开启之后，需要确认filter_log有没有增加插件的记录规则，没有规则将不记录。

记录规则添加和上面一样，不过这次要选择插件视图。

具体如图二十四、二十五所示。

图二十四：

插件记录规则添加界面

图二十五：

记录的具体消息界面

通过filter_log记录消息，我们可以判断请求以及应答的正确与否。

但是必须需要插件的配合。

如果请求没有经过AC，那么在不能重启的情况下，只能抓包解决问题。

注意：

AC的抓包开启之后，一定要关闭，否则AC会不停记录消息，这样就使记录文件不断增大，浪费硬盘空间。

当然也会影响系统性能。

解决办法

找到请求或者应答丢弃的根源之后，需要联系中间件开发人员解答。