租户端 运维工具 云监控（BARAD） 运维手册

节点重启

最近更新时间: 2024-06-12 15:06:00

  1. 产品部署架构

    介绍产品各个节点的角色、作用、组件。

    模块/容器 节点类型 组件介绍
    tcloud-barad-update2 容器 内含stargate server以及告警加载服务。
    2. stargate server为cvm机器上的stargate agent（ps aux | grep sgagent）提供服务，主要用于记录、更新cvm状态信息以及下发barad agent
    3. 告警加载服务是为减少storm的supervisor数据库查询而设计的统一查询服务，它将数据库中的告警配置数据缓存一份到容器内的/data/www/alarmdb.barad.tencentyun.com/alarm_file目录下，并通过nginx暴露http服务供storm supervisor拉取
    tcloud-barad-event 容器 包含事件中心cgi以及handler服务
    1. 事件中心cgi提供http服务供其他垂直产品上报事件，对上报的事件进行简单校验后写入kafka消息队列，topic配置为cm_event
    2. handler服务从kafka消息队列消费数据，对重复上报的事件进行收敛（重复上报判断依据是：是否同一告警对象——由StormCloudConf.cEventProductConfig.astrictDimension字段决定，以及收敛时长——由StormCloudConf.cEventProductConfig. astricPeriod）和校验，并检测是否配置了告警策略，并将数据存入es。如果是已配置告警策略，则发出http请求到ams进行告警
    3. 多地域部署每个地域都要部署tcloud-barad-event镜像
    tcloud-barad-isd 容器 包含多个后台管理服务和脚本、overlay子机 agent上报超时检测服务（即将下架）以及barad配置中心配置拉取服务，一般无需多实例
    其他各个容器中一般都会有ConfClient组件，用来缓存barad配置中心的配置
    tcloud-barad-dispatch-tsm 容器 仅包含一个将barad部分命名空间数据导入argus的服务
    tcloud-barad-script 容器 包含6个旁路服务
    4. barad_sync_server 自动从ccdb中同步cvm的信息到翻译表，供nws作维度翻译
    5. cm_php_script 用于同步主库的告警策略信息到地域库
    6. dict_access 为其他产品上报维度翻译信息的服务端，它将数据缓存到kafka消息队列。Topic列表为StormDictionary库中tDictionary_*的表，每个topic建议只创建两个partition，否则容器会因为进程过多的原因不断重启
    7. dict_sync 从 kafka 消息队列消费维度翻译信息，然后转存到数据库（与dict_access组成完整的服务）
    8. getAppTraffic 的作用是获取每个地域的qce/lb下视图的流量数据，汇集计算每个租户的总出入流量到qce/lb_total，展示在租户端的流量监控一栏
    9. monitor_cvm_msg_forward用于同步cvm的实例销毁信息，同步调用接口删除绑定了该cvm的告警策略中的信息
    tcloud-barad-dataapi 容器 包含dataapi以及newdataapi两个服务。均为旧接口，调用方极少，后续可能下架。
    tcloud-barad-nws 容器 包含3个服务
    nws 服务用于接收FT上报数据，对数据进行合法性判断后，执行维度翻译，后存入kafka消息队列中
    nws进行维度翻译的功能是由dict_loader保障的，该组件将维度翻译信息从db中缓存到容器内的/data/storm/local_dict/目录下（db中的信息由tcloud-barad-script的dict_access和dict_sync写入）
    另外容器中还有一特殊的cgi，由customAlarmNws提供的自定义告警接收功能，用户可以通过cvm上的cagent_tools工具进行自定义告警。该功能涉及组件较复杂，在此不多赘述。
    tcloud-barad-alarm 容器 仅包含一个服务cloud_alarm，其主要对外提供两个服务，一个是接收storm并对告警状态进行扭转和传递（正常-》异常-》告警-》正常），另一个是平台事件的接收服务
    tcloud-barad-api 容器 包含customapi、baradapi、ams、customAlarm、policyapi
    customapi 与云图对接，提供前端接口以及部分开放接口
    baradapi封装了调用es的逻辑，相当于一个专属barad的esClient
    ams处于tcloud-barad-alarm的下游，用于记录告警信息以及对接消息中心，发送告警
    customAlarm 自定义告警，与tcloud-barad-nws相关，用于将clientkey刷入ckv
    policyapi 342新增，脱胎于customapi
    tcloud-barad-skywalker 容器 包含Flink流计算逻辑组件及其管理脚本
    product-barad-deploy 容器 部署用生产组件，目前并不完善，其中有部分实用工具，如TCE/tools/fix下有修复es表timestamp类型为mills的工具fix_es_table_err，以及修复数据库ft回调接口写死域名的工具fix_ft_host，部署时可以不需要此组件
    product-barad-sgagent Stargate agent标准化组件，执行deploy将直接将stargate agent标准化并传到hdfs，供母机新建cvm子机时下载安装
    yunapi-barad Barad的云图配置
    tcloud-barad-api-go 这个是baradapi v3版本，大部分都是对policyapi的改动，因为policy是v2的版本，但是私有云需要全量升级为v3版本，所以tcloud-barad-api-go做了一层代理，将网关请求的apiv3的格式做了一层参数转换，转换成v2的参数调用方式来调用policy api

  2. 一般情况下pod重启

    一般情况下直接重启组件所在的pod，k8s会自动完成负载流量转移，delete之后会自动拉起并回切到集群。

    1. 获取barad pod列表：kubectlget pod --all-namespaces -o wide |grep barad

    2. Delete Pod：kubectl delete pod -n tce ${pod}

    3. 等待拉起状态为：

  3. 按组件重启

    1. 获取barad pod列表：kubectl get pod --all-namespaces-o wide |grep barad-nws

    2. 进入pod ：kubectl exec -it -n tce ${pod}bash

    3. 一般情况组件所在的目录： /usr/local/services/

    4. sh/usr/local/services/barad_nws-1.0/admin/restart.sh all

      正常：