xflush监控设计详解

一、Xflush架构图

三机房容灾方案

二、监控容灾方案

1.概述

apmonitor 增加网关，接收 oneAgent 吐出的 metric beat 数据。

2.数据容灾

• 元数据库(mongodb)进行双读双写。
• 监控数据(tsdb)进行双读双写

3.架构

4.TSDB双读双写

双写

发出两份写入请求，非同步写，写入结果独立，无关联逻辑。

双读

1. 发出两份读取请求，对接收到的数据进行无差别合并，即以metric+tags为key，dps为value进行合并。
2. 有小黑屋机制，若读取连续失败若干次（当前设置值为500），则将该后端节点关进小黑屋，之后的读取请求不再发给它。小黑屋按固定频率清空（一般取1~5分钟）。

5.用户体感的效果

参照上图，不论故障情况如何，只要AB两机房还有一个的产品层组件+一个存储组件存活，数据就能写进去。不论故障恢复情况如何，只要还要一个产品层组件存活，那么就能读到所有现存活存储组件中写入过的数据。

三、业务架构

监控解决方案 (AntMonitor)

• apmonitor Metric 监控: 物理机OneAgent 标准日志或指标采集推送方案。
• xflush 业务自定义监控: 虚机采集业务日志自定义监控方案。
• ALS 日志服务: 物理机 OneAgent 日志推送方案。

四、源数据管理

1. 监控元数据源

监控系统元数据来源:
1） 通过调用云游、RMC内部金融云系统pull拉取的元数据。
2）Kube云原生数据，定时调用cluster云原生API拉取数据。

• a. kube的cluster元数据格式定义
• b. 单cluster元数据格式定义

3）通过前端页面添加自定义应用、资源数据。
4）配置新增自定义拉取第三方指定API的数据。

2. 元数据存储

1）自定义应用、应用归属资源元数据表结构
继续存储在原来的应用(apmonitor_metadata_app)、ECS资源元数据(apmonitor_metadata_ecs)表。

2）应用、资源表结构字段做扩展

• 新增元数据表添加采集的频率字段标识。
• 新增标识数据来源的字段origin(云游、RMC、自定义应用、第三方API、Kube数据)。
• 新增标识应用级别字段level。
• 新增标识应用技术栈字段techStack。
• 新增扩展字段extension。

3）Kube数据采集元数据新增表存储

• kube的cluster元数据表：apmonitor_metadata_kube_cluster
• kube的node元数据表：apmonitor_metadata_kube_node，数据模型：

{
        "name": <string>,
        "uid": <uuid>,
        "ip": <ip>,
        "cluster_name": <string>,
        "labels": {
          "workspace_id": <string>,
          "tenant_id": <string>,
          "minion_cluster_id": <string>,
          "cell_id": <string>,
          "zone_id": <string>,
          "region_id": <string>,
          ...
        },
}

• kube的container元数据表：apmonitor_metadata_kube_container，数据模型：

{
    "id": <uuid>,
    "name": <string>,
    "image": <string>,
    "cluster_name": <string>,
    "node_name": <string>,
    "node_ip": <ip>
        "pod": {
      "name": <string>,
      "uid": <uuid>,
      "ip": <ip>,
      "namespace": <string>
    }
        "labels": {
          "workspace_id": <string>,
          "tenant_id": <string>,
          "app_id": <string>,
          "app_name": <string>,
          "app_service_id": <string>,
          "minion_cluster_id": <string>,
          "cell_id": <string>,
          "zone_id": <string>,
          "region_id": <string>,
          ...
        },
        "metrics": [
              {
                    "type": <metric_type>,
                "port": <port>,
                "path": <string>,
                "timeout": <timeout>,
                    "username": <string>,
                    "password": <string>,
                "labels": {
                  "<string>": <string>
                }
              }
        ],
    "logs": [
      {
        "type": <log_type>,
        "paths": [<path>,],
        "encoding": <encoding>,
        "labels": {
          "<string>": <string>
        }
        }
    ]
}

• 如何查询container归属哪个node节点
  根据cluster_name+(node_name或者node_ip)联合主键确定归属node信息。

4）元数据配置表
新增元数据配置表，用于存储自定义应用、第三方元数据配置信息，表数据模型：

3.元数据采集

1）定时采集云游、RMC系统数据
这个部分数据继续原有的方案不变。
2）Kube云原生数据
定时采集Kube插件提供的API。
3）自定义应用
自定义应用

• 必选字段：名称、技术栈?、负责人。
• 应用数据存储在应用(apmonitor_metadata_app)表中，通过字段origin标识数据来源。

应用归属的资源类型：

• 资源数据存储在原类型(apmonitor_metadata_ecs)表中，通过字段origin标识数据来源。
• 自定义应用归属资源ECS、ACS类型资源，类型可配置。
• 归属ECS资源必填项：hostname、IP、idcId，可选项：idcName、LDC、Cell、regionId、iaasId、tenantId、resType。
  部分字段数据为空的情况需要特殊考虑(数据展示、采集数据逻辑、告警逻辑、通知消息逻辑)。
  自定义应用 展示/编辑/删除/告警规则/订阅：
• 类似资源那样在应用中添加一个tab。
• 仅自定义应用才可编辑、删除。
• 告警规则/订阅同当前应用的一致。

4）第三方指定API拉取数据
（1）通过配置管理页面添加第三方采集API地址信息。

• 数据采集拉取间隔。
• HTTP协议，是否需要支持TLS。
• 鉴权模式(Token、user/paasword)。

（2） 数据中的必选字段(字段名称可通过配置映射转换)

• 应用：名称、技术栈、负责人
• 资源：hostname、IP、IDC，可选项：idcName、LDC、Cell、regionId、iaasId、tenantId、resType。

（3）通过Groovy动态代码支持多种格式解析。