故障处理

1. 故障处理思路

   1. 数据链路

      Agent将监控数据、事件数据、自定义消息的上报到barad-nws，barad-nws对维度信息翻译以后缓存到kafka，kafka数据流入到flink，flink再将数据计算结果流入kafka，kafka再将数据写入writer，writer写入es，客户在前端查看数据，调用api，api从es拉取数据展示。

   2. 告警链路

      创建了告警策略之后，同步器会去同步告警策略和告警规则到adp告警检测，adp告警检测会从第二层kafka获取监控数据进行检测是否符合告警规则，符合则到amp告警发送，amp告警发送发送消息给到客户，并且将告警历史等信息存到es保存。

  排查思路：

1. 分析具体场景，缩小范围。

2. 针对具体case分析。

3. 全链路分析，逐一排查。

2. 故障处理CASE

   1. 所有产品都无监控数据

   • 排查思路：

     根据数据链路去查每一个组件。

   • 故障现象：

     租户端控制台所有产品都看不到监控数据。

   • 故障定位及处理：

     1. 检查ES集群是否正常部署：

        在pod内curl es1.barad:9200/_cat/health?v，如果集群状态为green则正常。

     查看存储表是否正常初始化： curl es1.barad:9200/_metrics，正常应返会viewName index的集合，若报无权限或无该index，则创建集群的初始化参数有问题，开启了鉴权，或集群类型创建的不是ctsdb，需将集群销毁重新创建。

2. 查看建表的时间戳格式是否正常：curl es1.barad:9200/_metric/cvm_device-60,若返回的format为epoch_second则为正常，若为epoch_mills则为异常。如异常需要将该表删掉重建（如管控刚刚拉起，存量数据无需保留的话，可将所以metric删掉后重新执行初始化脚本）。

3. 如以上都正常，且集群本身运营有一段时间后突然没数据，可查看es存储是否被写满,

     curl es1.barad:9200/cat/allocation?v的disk.indices可查看当前已使用的node空间，

     curl es1.barad:5100/_search/clusters 可以看到对应集群预先分配的node磁盘空间。如已达到分配容量，则需要对ES进行扩容：

4. 检查zk和kafka是否正常：

     登录zk节点，进入zk安装目录，进入bin目录，执行./zkServer.sh status命令，正常则返回leader或follower。若报错则可能zk未启动，执行ps -ef|grep zookeeper查看zk是否正常拉起。

     若zk正常，则在zk的bin目录下执行./zkCli.sh进入zk的shell（最好在leader节点执行,follower也可以，如果执行命令未响应，可重试几次），然后执行ls /kafka/brokers/ids，正常则会返回所有的kafka节点id，一般为[0,1,2]或[1,2,3]三个节点，若少于3个则可能有部分kafka节点异常，get    /kafka/brokers/ids/1可查看具体的kafka node信息,endpoints和host为具体的节点信息,此处的ip需要能被集群内pod访问到。

5. 若有部分kafka节点异常，未出现在上述brokers中，则需要登录kafka节点查看kafka节点是否正常。若endpoints中的ip地址不是外界可以访问的ip，则说明kafka配置有误，需登录kafka节点检查kafka的配置文件server.properties中advertised.host.name是否配置为本机的ip，如果不是，需改为本机ip，然后重启kafka节点，其他节点以此类推。（kafka重启需使用bin目录下的kafka-server-stop.sh和kafka-server-start.sh，重启后ps -ef|grep kafka观察下进程的启动时间是否为当前时间）。

6. kafka节点异常通常是由于磁盘分区被写满，可在相应节点下执行df -lh查看分区使用率。同时检查kafka配置文件的log.dirs是否配置为容量较大的磁盘目录，检查过期时间配置log.cleanup.policy，log.retention.hours是否太长（正常配置过期时间为3d即可）。

7. 若第一层kafka异常后恢复，则需要重新提交任务到flink ，在master节点进入到barad-skywalker ,cd /usr/local/services/barad-skywalker/job,执行 sh run-job.sh。

2. 部分产品有数据，部分产品无数据

• 排查思路：

  这种情况可以肯定的是数据链路是通。部分产品涉及到翻译

• 故障现象：

  部分产品在控制台可以看到监控数据，部分产品看不到。

• 故障定位：

  1. 确认上报方是否上报。

  2. 如确实上报，检查上报的时间戳是否当前时间戳，默认超过半小时的时间戳会被丢弃。

  3. 如有翻译，则检查翻译配置是否正常，翻译字典表数据是否ok：

     查看barad的数据库，StormDictionary库下对应的表里有没有相应的记录。

     若翻译记录未存在，则：

  • 如果是cvm和LB，则查看barad-script容器内的barad_sync_server是否正常（ps -ef|grepsync_tool）服务是否正常，配置里的CCDB地址是否正确。

  • 如果是非cvm产品，则先确认业务方是否上报翻译数据，如果有上报，则查看barad-script容器里的dict_access和dict_sync_tool是否正常（ps -ef|greptornado_cgi.py, ps -ef|grep translate_tool.py）,如不正常，则查看对应组件的日志(位于/data/log下)。

  4. 确认ES建表的时间戳格式是否正常。

     检查统计方式是否配置正确（一般只有新业务接入才会有错）。

  5. 排查nws和flink日志（nws日志位于/usr/local/services/barad-nws-1.0/log，flink日志可在前端查看。

• 故障处理：

  如上报方未上报，则通知上报方处理。

  若翻译组件由于配置错误导致服务异常，则更新配置后重启barad-script容器。

  若ES建表错误，则将表删除后重建。

  如统计方式有误则更正统计方式。

  若有其他错误则根据日志信息进行定位。控制台可以看到监控数据恢复正常。

• 运维经验：

  集群的初始化操作一定要做。

  配置的管理切记不要搞错。

3. CVM部分指标无监控数据

• 故障现象：

  CVM的 CPU使用率，内存使用量和内存使用率无监控数据。

• 故障定位：

  1. 在子机上确认agent是否安装，agent位于/usr/local/qcloud/monitor目录下。

  2. 若agent已安装，确认agent配置的域名是否正确，域名是否能够正常解析，agent配置位于/usr/local/qcloud/monitor/barad/etc/plugin.ini。

  3. 若agent未安装，则检查子机stargate是否正常运行(ps -ef|grepsgagent)，日志是否有报错(/usr/local/qcloud/stargate/logs)。

  4. 观察子机agent日志有无报错(/usr/local/qcloud/monitor/barad/log)

• 故障处理：

  5. 若agent未安装，则安装agent。

  6. 若域名不能解析，则需要加上barad相应域名的解析。

• 故障清除：

  在控制台上可以看到CVM的监控数据。

4. 所有业务均无告警

   • 告警架构

     云监控中台将告警能力分为检测和告警

• 告警组件：

  同步组件tcloud-barad-alarm-synchronizer

  告警发送tcloud-barad-alarm-amp

  告警检测tcloud-barad-alarm-detector

  库 StormCloudConf，alert_management_platform_new，manager

• 数据同步逻辑：

1. 查看是否有监控数据，若无监控数据，则先按照《所有产品都无监控数据》进行定位

2. 若有监控数据但无告警，则需要查看告警组件的日志，根据日志报错进行排查

5. 部分业务无告警

• 故障现象：

  有部分产品可以收到告警，部分产品收不到告警。

• 故障定位及处理：

  查看是否有监控数据。

  查看当前的数据是否满足告警条件和持续时间（有时候可能会出现设置了>0但是实际曲线为0的情况，这种不满足告警条件的不会告警），持续N个周期需要连续N+1个异常点才会告警（例如设置了持续一个周期，则需要有连续的两个满足条件的异常点才会告警）。

  查看alarm-amp是否有发送日志(tcloud-barad-alarm-amp容器)，如果有发送日志，但是有报错，大概率是回调接口请求业务接口报错，需根据具体报错信息排查。

  如果alarm-amp无发送日志，则需排查tcloud-barad-alarm-synchronize pod内的日志，如日志中没有收到异常点的请求，则是由于kafka未发送异常点导致。

• 告警功能恢复：

  控制台告警列表可以看到收不到告警的产品告警触发的信息，并且能收到告警的短信和邮件。

6. cvm有数据无告警

• 故障现象：

  CVM在控制台上有数据，但是收不到告警。

• 故障定位及处理：

  大概率为字典表未正确加载，在isd.barad上，qce/cvm的cvm_device视图下，查看对应uuid的appId是否为改用户的appId，如果appId不是租户的appId，则表明字典表未正常加载：

  查看barad的db，StormDictionary.tDictionary_1表里是否有对应uuid的记录，如果有，则可能是dict_loader未正常加载，需重启barad-nws pod。

  如果db里无对应翻译记录，则可能是barad_sync_server配置的ccdb地址错误，需进入barad-script容器对应服务查看日志(/usr/local/services/barad_sync_server-1.0)和配置文件。

• 故障清除：

  对于满足告警条件的CVM，控制台上可以看到CVM的告警信息。

7. 无事件信息

• 故障现象：

  某个产品发生了某个事件，但是在事件中心的控制台看不到对应的事件信息。

  1. 故障定位及处理

  2. 检查业务方是否上报。

  3. 检查kafka是否正常：

     查看barad-event容器内的nws_event_front日志（/usr/local/services/nws_event_front-1.0/log）,是否有写kafka失败的日志。如果有超时或发送失败，则可能kafka配置不正确或者未初始化 topic，需排查kafka配置和kafka的topic列表。

     如果写kafka正常（上报成功，且nws_event_front无错误日志），但是event_handle模块的日志没有消费kafka的日志，则可能kafka该topic异常。可尝试换一个topic进行测试，即在kafka上新建一个topic，然后更新nws_event_front和event_handle的配置文件，替换topic为新的topicName，然后重启这两个服务。

     检 查ES建表是否正常：cur:les1.barad:9200/_metric/tce_bm_lost_agent ,返回的timestamp的format字段应为epoch_second，如果返回报错或者返回的字段为epoch_mills，则表明未建表或建表异常，需删掉改表并重新建表。

• 故障清除：

  在事件中心控制台可以看到新增的事件信息。

8. 有事件无告警

• 故障现象：

  事件中心可以看到事件发生，但是告警列表看不到，并且订阅了告警的人员收不到告警信息。

• 故障定位及处理：

  即事件中心有记录但告警列表无记录。查看该事件和对象是否绑定了告警策略，如未配置，则事件中心的记录里会展示未配置，该情况为正常情况，如需要告警，则需要在告警策略页面为改事件绑定告警对象。

  若事件绑定了告警，但是无告警记录，则需要查看AMS日志进行排查。

• 故障清除：

  对于已绑定告警的时间，在控制台告警列表可以看到已发生事件的告警记录，已订阅告警的人员能够收到告警。