从03年开始接触TUXEDO到现在已经有些年头，从开始的一知半解、略懂皮毛到现在的稍有小成，也算积累了一些知识和经验。之前一直想将一些知识和经验总结一下，但总是有想法没有动手，年底趁着有点空闲整理了几年来的知识，希望能跟大家一起探讨一下。
       由于我们的客户主要是电信，系统是7*24运行，不能间断，系统运行压力比较大，而且系统和很多外围系统存在着大量的接口，因此当客户端比较多或者是外围系统出现问题时，TUXEDO系统经常也会出现不稳定，例如客户端并发使用量比较大而导致系统性能下降时，会出现消息队列出现堵塞，客户端和服务端异常死亡，服务被清除，客户端连接数已经达到LICENCE最大连接数，进程数已经达到系统设置的最大的进程数等严重错误，出现这种错误时，往往无法立即知道情况，需要过一段时间从使用者才知道有问题发生，而且也不知道是何错误，需要从TUXEDO日志才能了解一些信息。如果是在深夜发生，那么维护是相当麻烦。
       因此当时便有写一个TUXEDO在线监控程序的想法，阅读了TUXEDO的官方文档，总算在文档中找到了一些TUXEDO的管理办法。TUXEDO的管理方法有几种，一种就是我们常用的命令行方式，用tmadmin,dmadmin,tmconfig等命令来查看TUXEDO系统状况。另一种就是通过设置服务的日志方式来记录执行情况。另外两种就是我下面重点介绍的事件通知和通过查询方式。
       TUXEDO提供了一个事件(event)监控（EventBroker）的机制，用我们熟悉的订阅/发布方式来提供事件发生通知。事件分为2种，一种是 TUXEDO提供的系统事件，例如服务异常死亡、消息队列堵塞等；另一种就是我们自己的编写发布的服务，在服务中通过tppost()通知订阅者。这两种方式的事件订阅方式都是一样，用tpsubscribe（）通知TUXEDO系统要订阅那些事件，对于系统事件来说，由TUXEDO自身通知订阅者，对于非系统服务来说，需要我们在服务中调用tppost()来通知订阅者。下面介绍一下如何订阅和接收事件。
      首先我们要编写一个服务，此服务用来接收TUXEDO系统的事件通知发布，只要我们订阅的事件有发生，那么TUXEDO就会调用这个服务，我们就可以根据事件来处理一些错误，例如服务异常死亡，那么我们可以自动将改服务重新启动。订阅的代码简单如下：

             userlog("订阅事件(%s)出错，错误信息：%s",t_subscribeEvent,tpstrerror(tperrno));

      从上面代码我们可以看到，订阅时间非常简单，剩下的事情就是接收事件，在我们自己编写的服务中处理。建议将需要监控的事件定义在数据库表中或者是配置文件中，这样我们可以写一个服务，在服务的tpsvrinit()中进行订阅，然后在tpsvrdone()中取消订阅。
    下面简单谈一下事件接收服务该如何写。
     事件接收服务跟我们平常写的服务一样，只不过是TUXEDO系统调用了这个服务而已，TUXEDO将EVENT的一些数据写在FML32数据区中。
         事件接收的代码简单如下：

       从上面代码可以看出，接收服务也很简单。
       从上面的例子我们可以看到，利用TUXEDO的事件监听机制，我们可以很好的监控到我们关心的事件，根据事件自动处理一些错误和异常，对于严重的错误，可以实时给系统管理员通过发短信、电话通知、邮件等方式来告警。对于一些我们自己编写的重要服务，我们也可以设立监控，实时监控流程的进行。当时笔者将这个事件监控加载到在线TUXEDO系统以后，系统的稳定性得到了很大的提高，维护工作量减少了很多，很多异常由监控程序自身完成。而且可以将维护工作交给系统管理员，由他们去做日常查看和维护工作。
      下一篇文章我将介绍如何通过接口编程方式来实时监控TUXEDO系统的运行状况，例如监控消息队列的长度、服务的调用情况、客户端的连接情况、域间通讯的连接状态等。
TUXEDO在线监控浅谈（二）：用MIB实时监控系统状况之SERVER篇

TUXEDO提供了一套可编程的管理员 API接口(Management Information Bases),简称为MIBS。通过MIBS，可以方便的监控TUXEDO运行时的所有系统资源，例如SERVER和SERVICE的运行状况、 SERVER队列和消息队列的资源情况、客户端的使用情况、域间通讯的连接情况、系统的资源配置等，所有的资源你都可以通过MIBS的API来获取或者动态的修改资源配置。例如对于某些关键的SERVER或者SERVICE，我们想监控它在多少秒之内的被调用情况，服务是否出现异常或者是被挂起，SERVER对应的消息队列是否出现了堵塞或者是队列空间紧张，当SERVER出现请求反应较慢需要增加进程时，通过MIBS动态的增加进程个数。对于消息队列，我们需要监控消息队列当前的请求总数，队列中的长度是否达到了危险程度需要告警。对于客户端使用者来说，我们需要监控有那些客户端调用超时或者是调用已经被系统给挂起了，某些客户端调用出现异常导致系统性能下降，我们可以自动先将这些客户端请求给消除或者杀掉，根据客户端请求的全过程来找出问题。如果系统和其它外围系统存在着连接或者是分布式的TUXEDO系统，我们需要监控系统和其它系统的域间通讯连接是否正常，远端的系统是否还在正常运行。用一句话来概括，TUXEDO所有的应用都可以通过MIBS进行实时监控。
   
     MIB接口规定了系统管理员，系统操作员和其它用户，三者具有不同的操作权限。MIB接口将系统资源划分为三种类型，分别为Classes和 Attributes和States。Classes指资源的分组，例如SERVER、SERVICE、CLIENT、QUEUE、MSG等。 Attributes指Classes对应的属性，例如SERVER的属性有SERVERNAME、SRVGRP、SRVID和运行时的参数值等属性。 States指Classes在运行时的状态，以及在运行时可以更改的属性。MIB的操作类(OPERATION)分为GET和SET两种类型，即指查询和设置两种操作。
   
    Classes的类型有T_MACHINE、T_GROUP、T_SERVER 、T_SERVICE 、T_SVCGRP、T_QUEUE、T_MSG T_DOMAIN、T_CLIENT等，下面逐一介绍怎么获取这些类型的属性和运行时的参数，重点介绍T_SERVER 、T_SERVICE 、T_SVCGRP、T_QUEUE、T_MSG 、T_DOMAIN、T_CLIENT等几个我们主要关心的类型。
    用MIBS的API查询系统资源的接口比较简单，跟客户端调用SERVICE方法一样，都是用tpcall()或者tpacall()。只是服务名为.MIB。输入输出的缓冲区类型为FML32。在调用之前我们需要指定几个查询参数TA_OPERATION和TA_CLASS、TA_FLAGS，已经Classes对应的参数，例如我们在查询T_SERVER这个Classes，我们想根据LMID、SERVERNAME、SRVGRP、 SRVID、RQADDR等参数来查询对应，那么就在输入缓冲区中输入对应的参数值。
    首先我们来介绍T_SERVER这个Classes。T_SERVER就是我们在TUXEDO配置文件的SERVER节中所定义的SERVER。用 MIBS来查询SERVER在运行状态下的数据，可以获取到SERVER的配置参数值，以及SERVER运行时的其它动态参数值，例如进程ID(操作系统的PID)，请求消息队列的PID，回复消息队列的PID，队列名称，SERVER当前处于被请求服务的SERVICE，SERVER被调用的次数、已经完成的调用次数，还没有完成的请求数等。
    代码简单如下：

    从上面代码可以看到，我们可以获取到SERVER在运行状态下的所有参数值。例如假设有一个服务有异常，那么我们就可以根据获取的服务状态，来自动做一些处理。可以监控到SERVER被调用的频率，如果SERVER包含多个SERVICE，那么可以监控到某个SERVICE是否被调用次数过多而且影响到 SERVER中其它的SERVICE，那么就要考虑将这个SERVICE移到其它SERVER或者是单独成为一个SERVER。根据SERVER的 RPID，我们可以关联查询SERVER对应的REQUES消息队列，查看REQUES消息队列的排队率和占用率是否过高，自动进行处理或者是告警。
    如果我们想在运行状态时动态的修改SERVER的配置参数，那么我们可以将TA_OPERATION改为SET，将需要修改的参数输入缓冲区，调用 MIBS的接口即可。修改某些参数有时需要将SERVER的状态改为INActive，相当是tmshutdown -s SERVER,然后才能修改。