随着容器化混合云等落地,线上问题会变得更加错综复杂,但做得多了逐渐就有了套路。于是产生了用一些工具辅助排错的想法,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地址的相关信息查询