CN104113579A - 一种基于udp的业务***数据采集与实现 - Google Patents

Abstract

本发明涉及数据自动化采集领域的设计与实现，具体涉及一种采用UDP网络通信协议实现业务***数据采集的设计与实现。本发明的技术方案具体就是通过在业务***中内置一个Agent，由业务***根据业务监控的品质要求通过Agent向业务监控服务器发送监控KPI指标信息，所述的业务监控服务器将监听接受到的监控数据存入监控日志数据库，并通过日志归并模块将监控数据根据业务展示和运维的目标将监控日志数据归并存储如CMDB中，所述的业务展示***通过读取CMDB提供不同维度的展示视图供运维人员使用。

Description

一种基于UDP的业务***数据采集与实现

技术领域

本发明涉及数据自动化采集领域的设计与实现，具体是一种采用UDP网络通信协议实现业务***数据采集的设计与实现。

背景技术

随着企业规模和IT基础设施的扩展，在保证不对业务***产生扰动的情况下，如何加强对业务***的监控力度，已成为一个紧迫的问题。本发明提供了一个标准的、面向服务的、低耦合的UDP采集手段，实现了对业务数据的实时采集，从而实现利用较小的网路开销，在传输层选择简单可靠的UDP，实现了面向无连接的可靠传输。   

发明内容

本发明基于UDP技术，旨在对业务***的运行细节进行精确化监管。本发明的技术方案具体就是通过在业务***中内置一个Agent，由业务***根据业务监控的品质要求通过Agent向业务监控服务器发送监控KPI指标信息。业务监控服务器将监听接受到的监控数据存入监控日志数据库。通过日志归并模块将监控数据根据业务展示和运维的目标将监控日志数据归并存储如CMDB中。业务展示***通过读取CMDB提供不同维度的展示视图供运维人员使用。

附图说明

图1是本发明总体结构图；

图2是业务监控KPI阈值示意图。

具体实施方式

本发明在具体实施方式上主要由异构数据集成、管理数据的导入、业务影响分析和服务仪表盘四部分组成，具体如下；

进一步的，上述的异构数据集成主要是通过TCP和UDP两种方式将不同厂商的应用报文声明数据和监控数据以统一的形式提供给业务视图模块，由该模块进行统一的处理展现。主要包括报文声明和监控报文 UDP。进一步的，上述的报文声明基于TCP发送，描述一个业务要监控哪些KPI指标，以及KPI指标的阈值。

a) 声明业务***的唯一编码 CD

b) 声明业务名称 Name

c) 声明业务类型 Type

d) 声明业务监控KPI值，一个KPI指标有如下属性：

1) Key：kpi值名，一个英文字母，在该业务中唯一

2) Level：2个数字定义KPI指标的报警阈值，分别为红色报警阈值和黄色报警阈值，表示当值出于何值时是报警状态值。如图2所示：

两个阈值将KPI监控指标划分为三个区段：

红色区段：表示该监控目标处于问题状态；

黄色区段：表示该监控目标处于潜在威胁的状态；

绿色区段：表示该监控目标状态正常。

3) 单位：KPI值的单位，如“公文数”，“流量”，“业务数”，一个业务可以有1~n个KPI指标。

e) 多常时间***不发监控报文，需触发警报。

{

    "ID": "XXXX",

    "NAME": "XXXX",

    "TYPE": "XXXX",

    "KPIS": [

        {

            "NAME": "key1",

            "LEVEL": {

                "red": 70,

                "yellow": 40

            },

            "BASEUNIT": "XXXXX"

        },

        {

            " NAME": "key2",

            " LEVEL": {

                "red": 70,

                "yellow": 40

            },

            " BASEUNIT": "XXXXX"

        },

        {

            "NAME": "key3",

            "LEVEL ": {

                "red": 70,

                "yellow": 40

            },

            "BASEUNIT": "XXXXX"

        }

    ],

    "TIMEOUT": 60

}

进一步的，上述的监控报文基于UDP协议进行发送，报文为一个Json报文，报文如下格式：

{

    "ID": "XXXX",

    "KPI": {

        "Key1": "xx",

        "Key2": "xx",

        "Key3": "xx",

        "Key4": "xx"

    },

    "TIME": 10012545554

}。

进一步的，上述的管理数据导入通过在应用***内置Agent的方式与监控服务器进行交互传递应用监控数据。

上述的Agent客户端是运行在业务***上的一个代理程序，当向“业务监控服务器”发送报文，Agent由业务***自己决定以什么频率发送“报文声明”和“监控报文”。

一般情况下，业务***上线前会从运维中心获取一个业务***的唯一报文编码，以该编码做为以后发送报文的标示，当业务***启动向“监控服务器”发送“报文声明”以后每分钟发送一次“监控报文”向“监控服务器”回报业务状态。

进一步的，上述的监控服务器在指定TCP/UDP端口监听通过TCP/UDP发来的“报文声明”和“监控报文”。监控服务器启动后，在指定的端口上监听，当监听到端口为9999时，客户端通过TCP发送报文声明，则监控服务器接收发送过来的报文声明数据，解析后得到业务id，通过业务id检查数据库中是否已存在该业务应用，若存在，则更新业务应用。当监听到端口为10000时，客户端通过UDP发送监控报文，则监控服务器接收发送过来的监控报文数据，解析后得到业务id，通过业务id检查数据库中是否已存在该业务应用，若存在，则将监控报文信息***到监控日志中，否则不保存监控报文信息。

进一步的，上述的业务服务影响分析即对应用业务所涉及到的配置发生变更时所作的操作与记录，用于描述服务器与资源，业务服务，使用者，组件，软件之间的关系，分为连接关系，使用关系，包含关系和业务关系。通过直观的方式向运维人员展示当前应用业务与资源，以及资源与资源之间的关联关系，从而客观直接的反映出各资源之间的物理关系和逻辑关系，当应用出现问题时可迅速地找出受影响用户和部门，动态显示企业各个部门之间对应的服务情况，一旦发生问题，***管理员能很快了解受影响的客户以及故障严重程度，从而及时采取措施进行处理。

进一步的，上述的服务仪表盘即将接收到的各应用业务的监控数据经过统计分析之后展示出来，供运维人员使用。具体算法如下：通过应用***的id查询应用***表，获取该应用***的报文声明，通过解析json格式的报文声明，得到该应用***的所有KPI属性、KPI中文名及KPI单位，将KPI中文名及单位放到集合中返回到页面上。再根据应用***id分页查询业务监控表，得到该应用的监控列表信息，循环业务监控列表，获取单个监控报文，通过json解析监控报文，得到时间戳及json格式的KPI，根据报文声明解析的KPI属性，解析json格式的KPI，获取KPI属性对应的KPI值，将时间戳（转换成时间类型）、KPI值放到一个数组中保存起来，将该数组放到循环外的集合中保存起来，依次循环业务监控列表。从而使运维人员及时掌握各应用***运行情况。

Claims (1)

1.一种基于UDP的业务***数据采集与实现，其特征在于，通过在业务***中内置一个Agent，由业务***根据业务监控的品质要求通过Agent向业务监控服务器发送监控KPI指标信息，所述的业务监控服务器将监听接受到的监控数据存入监控日志数据库，并通过日志归并模块将监控数据根据业务展示和运维的目标将监控日志数据归并存储如CMDB中，所述的业务展示***通过读取CMDB提供不同维度的展示视图供运维人员使用。