chatops实践

随着容器化混合云等落地,线上问题会变得更加错综复杂,但做得多了逐渐就有了套路。于是产生了用一些工具辅助排错的想法,chatops便是其中一个实践。

情境
  • 平时,会有同事来问:

    • service-xx是谁在负责,我想对接他们。
    • 我的服务service-yy出口IP是什么,银行等三方需要添加白名单。
    • 我们的k8s集群资源分配怎么样了?
    • 我们的带宽情况如何,是饱满还是不足了?
    • IPxxx是谁的机器,此刻上面有什么应用,怎么还在调我的一个老接口?
  • 故障时,我们常需要做如下查询:

    • 当前故障是小范围还是全局,全局状态怎么样?
    • service-xx的全链路是怎么样的,cdn,waf,LB,带宽,endpoint,状态码比例都是什么情况
    • 都有哪些异常日志、事件?
  • 每天,我们要做基本的巡检:

    • 定时上班前发送巡检报告,检查带宽、核心集群资源、链路状态等基本状况。

目的

针对上述场景和稳定性需求,主要是两点:

  • 缩短MTTD,协助快速定位问题
  • 减少重复工作,提高SRE与开发人员在信息获取上的自动化程度

策略

  • 交互式运维 chatops
    • 比起输入网址或打开小程序,在聊天窗口直接操作是最快捷、安全、可追溯、高效协同的方式了。
  • 整合已有系统接口,尽可能重复造轮子
    • cmdb,云平台,日志平台,三方云平台、waf、cdn,公网dns,内网dns等的信息联动

衡量标准

  • 定时巡检从无到有,且实现自动化
  • 缩短相关对象的查询时间在90%以上(实现一键查询),降低故障发生时的定位时间(mttd)
  • 提高开发测试等用户方获取信息的效率(ip 域名等各自相关信息的一键查询)
  • 不对已有系统造成负担
  • 敏感信息需在授权后才可交互获得

功能

  • 自动巡检并发送全局状态报告(支持定时、实时)
    • 过去一段时间(如24小时),全局核心组件状态的收集和汇报+汇总类数据
  • 特定对象的关联信息查询
    • 对一个域名的链路追踪(dns–>ingress–>nginx–>pod–>责任人)
    • 对一个IP的反向域名追踪
    • 对一个IP的主机责任人查询
  • 审计与授权
    • 敏感信息需授权,如查询k8s
    • 所有交互均可审计,交互记录入库和日志系统。

要检查的核心组件

IAAS层面的

  • DNS
  • 带宽
  • IP
  • LB
  • 主机(CPU,内存,硬盘)
  • WAF
  • 高防
  • CDN

PAAS层面的

  • 应用和团队(人员)的关系
  • K8S相关(鉴于复杂性,随后再考虑支持多集群)
    • 集群资源利用率
    • Ingress-svc-endpoint
    • Deployment-Rs-pod
    • 过去一段时间的异常事件
  • 监控系统相关指标
  • 日志系统相关指标(40x,50x,exception)

依赖的组件或信息源:

  • CMDB系统
  • 三方如Ucloud
  • 云平台的人员查询接口
  • K8S接口
  • dnspod
  • 内网dns接口
  • 日志系统
  • promethes
效果图:
  • 定时发送或手动(输入/report)查看此刻状态

  • 查看帮助信息

  • 查看k8s集群资源利用率

  • 服务流量链路分析

  • kubectl命令查询(大消息体拆分)

  • 某IP地址的相关信息查询