TF Analytics指南丨“分析”哪些内容？如何发出“警报”？
原创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://<analytics-ip> :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-ip>:<rest-api-port>/analytics/uves/control-node/aXXsYY&cfilt=UVEAlarms这适用于所有UVE表类型。
- 检索系统中所有报警（alarm）的列表。
GET http://<analytics-ip>:<rest-api-port>/analytics/alarms- 确认报警（alarm）。
POST http://<analytics-ip>:<rest-api-port>/analytics/alarms/acknowledge
Body: {“table”: <object-type>,“name”: <key>, “type”: <alarm type>, “token”: <token>}可以使用以下URL查询参数和前面列出的GET操作具体查询已确认和未确认的报警（alarm）。
ackFilt=True
ackFilt=FalseSSE流的分析API
下面的例子展示了用于检索全部或部分SE流的API。
- 检索基于SSE的UVE更新流，用于控制节点报警（alarm）。
GET http://<analytics-ip>:<rest-api-port> /analytics/uve-stream?tablefilt=control-node这对所有UVE表类型都可用。如果没有提供tablefilt URL查询参数，则会检索所有UVE。
- 只检索基于SSE的UVE更新流的警报部分，而不是整个内容。
GET http://<analytics-ip>:<rest-api-port> /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加密参数
参数 | 说明 | 默认 |
|---|---|---|
analytics_api_ssl_enable | 启用或禁用分析API服务器和Client服务器之间的SSL加密支持。 | 如果赋值为TRUE：支持SSL加密。 如果赋值为FALSE：不启用对SSL加密的支持，且分析API服务器不接受HTTPS请求。 |
analytics_api_insecure_enable | 启用或禁用对HTTPS请求中所需证书的支持。 | 如果赋值为TRUE：不需要证书就支持HTTPS连接。 如果赋值为FALSE：没有证书就不支持HTTPS连接。 |
analytics_api_ssl_keyfile | 节点私钥的路径。 | /etc/contrail/ssl/private/server-privkey.pem |
analytics_api_ssl_certfile | 节点公共证书的路径。 | /etc/trail/ssl/certs/server.pem |
analytics_api_ssl_ca_cert | CA证书的路径 | /etc/ipa/ca.crt |
配置好这些参数后，分析API服务器就会开始使用SSL证书，从而实现对分析API服务器和Client服务器之间连接的SSL加密支持。
在下篇文章中，我们将继续“游览”TF Analytics的功能，看看如何使用Analytics进行underlay overlay映射。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。