TF Analytics指南丨“分析”哪些内容?如何发出“警报”?



  • Tungsten Fabric是一个由计算节点、控制节点、配置节点、数据库节点、Web UI节点和分析节点组成的分布式系统。

    分析(Analytics)节点负责收集系统所有节点上所有软件模块的系统状态信息、使用统计和调试信息。分析节点将整个系统收集到的数据存储在数据库中,数据库基于Apache Cassandra开源分布式数据库管理系统。该数据库通过类似SQL的语言和表示状态转移(REST)API进行查询。

    分析节点收集到的系统状态信息将汇总到所有的节点上。

    分析节点收集的调试信息包括以下几种类型。

    • 系统日志(syslog)消息——由系统软件组件产生的信息和调试消息。
    • 对象日志消息——记录对系统对象(如虚拟机、虚拟网络、服务实例、虚拟路由器、BGP对等体、路由实例等)的更改。
    • 追踪消息——软件组件在本地收集的活动记录,仅在需要时才发送给分析节点。

    与流量、CPU和内存使用情况等相关的统计信息也由分析节点收集,并可进行查询以提供历史分析和时间序列信息。查询使用REST APIs进行。

    分析数据会被写入到Tungsten Fabric的数据库。数据将在默认的48小时有效时间(TTL)后过期。这个默认的TTL时间可以根据需要通过改变集群配置中的database_ttl值来改变。

    TF警报流(Alert Streaming)

    TF警报(alert)是在基于每个用户可见实体(UVE)提供的。TF分析(analytics)使用Python编码的规则来触发或解除警报,这些规则将检查UVE的内容和对象的配置。一些规则是内置的,其它规则可以使用Python stevedore插件添加。

    本主题介绍了Tungsten Fabric警报功能。

    警报API格式

    TF警报分析API提供以下内容。

    • 作为UVE GET APIs的一部分,读取对警报的访问。
    • 使用POST请求进行警报确认。
    • 使用服务器发送的事件(SSE)进行UVE和警报流。

    例如:
    GET http:// :8081/analytics/alarms。

    {
        analytics-node: [
            {
                name: "nodec40",
                value: {
                    UVEAlarms: {
                        alarms: [
                            {
                                any_of: [
                                    {
                                        all_of: [
                                            {
                                                json_operand1_value: ""PROCESS_STATE_STOPPED"",
                                                rule: {
                                                    oper: "!=",
                                                    operand1: {
                                                        keys: [
                                                            "NodeStatus",
                                                            "process_info",
                                                            "process_state"
                                                        ]
                                                    },
                                                    operand2: {
                                                        json_value: ""PROCESS_STATE_RUNNING""
                                                    }
                                                },
                                                json_vars: {
                                                    NodeStatus.process_info.process_name: "contrail-topology"
                                                }
                                            }
                                        ]
                                    }
                                ],
                                severity: 3,
                                ack: false,
                                timestamp: 1457395052889182,
                                token: "eyJ0aW1lc3RhbXAiOiAxNDU3Mzk1MDUyODg5MTgyLCAiaHR0cF9wb3J0I
    ................................... jogNTk5NSwgImhvc3RfaXAiOiAiMTAuMjA0LjIxNy4yNCJ9",
                                type: "ProcessStatus"
                            }
                        ]
                    }
                }
            }
        ]
    }
    

    在这个例子中:

    • any_of属性包含以[ [rule1 AND rule2 AND ... AND ruleN] ... OR [rule11 AND rule22 AND ... AND ruleNN] ]格式定义的报警(alarm)规则。
    • 警报是在每个UVE的基础上发出的,可以通过在UVE上的GET来检索。
    • ack表示警报是否已被确认。
    • token用于客户端的请求确认。

    用于警报的分析API

    下面的示例显示了用于显示警报(alert)和报警(alarm),以及确认报警(alarm)的API。

    • 检索对名为aXXsYY的控制节点发出的警报列表。
    GET http://:/analytics/uves/control-node/aXXsYY&cfilt=UVEAlarms
    

    这适用于所有UVE表类型。

    • 检索系统中所有报警(alarm)的列表。
    GET http://:/analytics/alarms
    
    • 确认报警(alarm)。
    POST http://:/analytics/alarms/acknowledge
    Body: {“table”: ,“name”: , “type”: , “token”: }
    

    可以使用以下URL查询参数和前面列出的GET操作具体查询已确认和未确认的报警(alarm)。

    ackFilt=True
    ackFilt=False
    

    SSE流的分析API

    下面的例子展示了用于检索全部或部分SE流的API。

    • 检索基于SSE的UVE更新流,用于控制节点报警(alarm)。
    GET http://: /analytics/uve-stream?tablefilt=control-node
    

    这对所有UVE表类型都可用。如果没有提供tablefilt URL查询参数,则会检索所有UVE。

    • 只检索基于SSE的UVE更新流的警报部分,而不是整个内容。
    GET http://: /analytics/alarm-stream?tablefilt=control-node
    

    这对所有UVE表类型都可用。如果没有提供tablefilt URL查询参数,则会检索所有UVE。

    内置节点警报

    可以使用分析API中列出的API来检索以下内置节点警报。

    control‐node: {
    PartialSysinfoControl: "Basic System Information is absent for this node in BgpRouterState.build_info",
    ProcessStatus: "NodeMgr reports abnormal status for process(es) in NodeStatus.process_info",
    XmppConnectivity: "Not enough XMPP peers are up in BgpRouterState.num_up_bgp_peer",
    BgpConnectivity: "Not enough BGP peers are up in BgpRouterState.num_up_bgp_peer",
    AddressMismatch: “Mismatch between configured IP Address and operational IP Address",
    ProcessConnectivity: "Process(es) are reporting non‐functional components in NodeStatus.process_status"
    },
    
    vrouter: {
    PartialSysinfoCompute: "Basic System Information is absent for this node in VrouterAgent.build_info",
    ProcessStatus: "NodeMgr reports abnormal status for process(es) in NodeStatus.process_info",
    ProcessConnectivity: "Process(es) are reporting non‐functional components in NodeStatus.process_status",
    VrouterInterface: "VrouterAgent has interfaces in error state in VrouterAgent.error_intf_list”,
    VrouterConfigAbsent: “Vrouter is not present in Configuration”,
    },
    
    config‐node: {
    PartialSysinfoConfig: "Basic System Information is absent for this node in ModuleCpuState.build_info",
    ProcessStatus: "NodeMgr reports abnormal status for process(es) in NodeStatus.process_info",
    ProcessConnectivity: "Process(es) are reporting non‐functional components in NodeStatus.process_status"
    },
    
    analytics‐node: {
    ProcessStatus: "NodeMgr reports abnormal status for process(es) in NodeStatus.process_info"
    PartialSysinfoAnalytics: "Basic System Information is absent for this node in CollectorState.build_info",
    ProcessConnectivity: "Process(es) are reporting non‐functional components in NodeStatus.process_status"
    },
    
    database‐node: {
    ProcessStatus: "NodeMgr reports abnormal status for process(es) in NodeStatus.process_info",
    ProcessConnectivity: "Process(es) are reporting non‐functional components in NodeStatus.process_status"
    },
    

    分析API服务器和Client服务器之间的加密

    Tungsten Fabric 1910版本支持SSL加密,用于分析(Analytics)API服务器和Client服务器之间的连接。Client服务器是Service Monitor和Contrail Command,后者通过REST API端口连接到分析API服务器。在1910版之前的版本中,分析API服务器和Client服务器之间的连接没有加密,这可能会造成安全威胁。

    只有当Tungsten Fabric与Red Hat OpenStack Platform(RHOSP)一起部署时,1910版才支持SSL加密。在RHOSP部署中,添加了一个全局标志,它决定了SSL加密的状态。

    如果启用了全局标志:

    • 您不必修改配置文件,因为SSL加密是自动启用的。
    • 如果要禁用SSL加密,必须修改配置文件。

    如果全局标志被禁用:

    • 您不必修改配置文件,因为SSL加密是自动禁用的。
    • 即使修改配置文件,也无法启用SSL加密。由于全局标志被禁用,因此在部署期间不会生成证书。

    配置文件有contrail-analytics-api.conf、contrail-svc-monitor.conf和command_servers.yml。在配置文件中,修改下表中的参数,以启用或禁用基于SSL的加密。

    表1:SSL加密参数

    edc2345a-0244-4b9d-a40b-39a981aadc18-image.png

    配置好这些参数后,分析API服务器就会开始使用SSL证书,从而实现对分析API服务器和Client服务器之间连接的SSL加密支持。

    在下篇文章中,我们将继续“游览”TF Analytics的功能,看看如何使用Analytics进行underlay overlay映射。


    原文链接:
    https://www.juniper.net/documentation/en_US/contrail20/topics/concept/analytics-overview-vnc.html
    https://www.juniper.net/documentation/en_US/contrail20/topics/concept/alerts-overview.html
    https://www.juniper.net/documentation/en_US/contrail20/topics/task/configuration/encrypting-connection-analytics-server-and-client-server.html



Log in to reply