作者:SUNNY
时间:2018-11-08
为什么要做统一操作平台?
根据实际数据统计,运维工作中,登陆服务器操作的操作,80%以上操作命令是查看之类操作(包括ls,cd,more等),还有一部分操作是文件编辑。
目标:运维人员的日常操作,均能通过统一平台来实现,减少琐事,提高质量、效率
有哪些需求?
日常操作简单分类为:
- 文件查看
- 线上配置变更
- 日志分析
- 重启服务
- 机器/系统级变更
- 各应用服务特有操作
- 其他
结合实际操作数据统计、走访调研,初步分析出数据云运维人员日常操作包括但不限于:
说明:
- 飘红框表示操作频率比较高
- 与服务相关的操作中,频率最大的是应用重启操作
解决思路是怎样的?
- 文件查看
- 这类操作暂时不细分,在线上服务器上开通dev开发账号(在线服务通过hadoop部署),运维人员通过dev来进行配置查看
- 线上配置变更
- 通过云翼包部署,不支持配置变更,这样对运维是一个很大麻烦,多次反馈,云翼表示不支持配置变更功能
- 变更频率比较高的任务,通过Jenkins Job来完成(基于Jenkins的统一操作平台来完成)
- 日志分析
- 通过ELK来实现
- 重启服务
- 基于Jenkins的统一操作平台来完成
- 机器/系统级变更
- 基于Jenkins的统一操作平台来完成
- 各应用服务特有操作
- 基于Jenkins的统一操作平台来完成
- 其他
基于Jenkins的统一操作平台
这是统一操作平台的重点,把日常操作全部抽象为Jenkins Job,每个操作对应一个Jenkins Job。
在通用性操作中,服务重启使用频率最高,因此优先来完成重启Job。
在Jenkins平台上完成了所有应用的启动、关闭、重启、状态查看操作,方便运维来操作。既然做到了这一步,为什么不再进一步呢?为什么还需要运维来操作应用的重启呢?能不能自动来完成?
为了更进一步解决应用重启这类高频操作,准备使用进程管理工具来管理这些应用,出现问题之后,可以自己拉起,减少运维同学操作,避免人工过多参与。
调研了systemd、supervisor、monit三种常用工具
systemd 虽然功能丰富,性能强大,但使用成本较大,并且只能使用root,没有可视化集群管理界面。而服务要求必须使用非root操作,因此无法使用
supervisor 很轻巧,并且可有可视化管理界面,很实用,但最大问题是只能管理前台应用,当前线上所有应用通过云翼部署,通过云翼启停进行控制,因此需要改造,改造成本太大。可以使用,但需改造每个应用启停脚本
supervisor管理界面:
monit 使用也很方便,比supervisor更灵活些,可以管理前台、后台应用,并且可以自定义start、stop、check条件,最大问题是脚本路径不支持正则,必须是确定的,通过云翼部署的任务,无法做到这一点,对接成本较大
小结
对接monit来实现应用监控,成本最低。但也存在几个改造点:
- 解决应用启停控制脚本路径变化问题
操作任务化过程中,遇到哪些主要问题?
- 如何梳理运维操作。运维操作很杂、很琐碎,需要按照一个统一维度去梳理
大数据组件常用操作。针对大数据组件任务操作,需要有一定大数据运维经验积累。比如Namenode主备切换等,再完善Job过程中,还需要关注任务的鲁棒性
任务搜索。比如,我期望找kafka topic配置更新操作,上百个Job中,你很难快速找到,这时需要有一定命名规范
来源:CSDN
作者:智能运维
链接:https://blog.csdn.net/zhinengyunwei/article/details/103976705