是运维就必须硬起来,插件化运维系统思路
是运维就必须硬起来,插件化运维系统思路
自由的眼 发表于1年前
是运维就必须硬起来,插件化运维系统思路
  • 发表于 1年前
  • 阅读 15
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 技术升级10大核心产品年终让利>>>   

习惯每周写一篇基于技术的帖子,描述一些自己的想法和故事,一方面是整理自己的思路,另一方面是欢迎拍砖。
这几天看到一些论坛里的技术帖子,顺便梳理了一下2016所有的技术精英大赛的C++帖子。
把一些好的思想,结合自己的实践,变为自己的,很是愉快。
有时间,好好的和Billing的同事去学习一下区块链,那里真是一个宝库,呵呵。
说正文吧,
有几篇帖子说到日志的难管理,以及问题出现了,运维人员只能打电话给程序,让他们帮忙分析问题。
这是很多项目的通病。
程序一般喜欢打日志,这里打一点,那里打一点,弄的到处都是日志。
而实际运维系统上的人,基本看不懂这些日志,以至于日积月累,巨大量的日志,哪个可以删,哪个不可以删?
你让程序员自己去清理?靠谱么?可能这个开发说,"那天出问题了我还要用呢,别删!!"
又比如,周末,程序员正在休息,运维发现问题,打电话给程序,往往最多说的是。"XXX目前不正常", 负责一点的,"XXX进程好像挂了",程序听了这些,心里多半会说:"和没说一样,什么还得自己去看。"
这样的问题,我遇到过好多次了。
运维抱怨研发弄的乱七八糟,而研发抱怨运维只是一个高级传话筒。
这种隔阂,造成了很多项目的"内伤",这种"内伤"就像大堤的裂缝,那天说不定就造成大事件。
2008年,我开源了一套自己的服务器引擎,基于ACE的。
一开始用途就是想把自己从无尽的IO重写中拯救出来。当时做了好几个系统,由于接口关系,自己写了无数遍的select epoll。虽说都那么几百行代码反过来调过去,就是不爽。当时想法很简单,别人用不用我不管,我只要自己用的爽就行了。反正我是不想再每次都重复写IO了。
2011年,没想到民生银行的一个开发和我联系,问我关于这个开源系统的一些实现细节,他们要用。
当时觉得很有趣,就帮助他们借助我的工具实现了一些东西,权当提高自己的能力。
其中有一个细节特别值得我记忆和总结。
他们遇到的问题,就是外包的有些模块,日志到处都是,再加上各种交接,有些日志谁也不清楚到底是什么,有没有用。以至于不敢动,身为运维非常的头痛。
结合自己的经历,回想起自己的项目写的日志,时间一长,不看代码,都不知道在干什么的,自己有些脸红。
于是开始思考,如何让运维硬起来?(好的设计,必须从问题产出者的出发点去思考)
于是设计出了一套运维插件规则,直接理顺了当时的整合项目,起到了很好的效果。
今天先说日志部分。
在我看来,日志必须是运维的关键性检查指标之一。
甚至,在某些时候,它的强度和研发是一致的。运维懂研发的日志,那么更加就能直接的反应问题了。不再受必须研发出现的制约。
于是我就提出,身为运维,必须提供一个日志插件体系,所有的研发必须只能用此体系。
怎么理解这句话?
也就是,运维提供一个基于C++的日志系统插件,供研发使用。所有的研发不得使用自己的写日志文件。全部必须使用此日志接口的API实现自己的日志记录。(当时的项目是C++的,后来,这个插件扩展到支持Java和python)
再说的细一点,运维必须提供一个日志记录的功能代码集合,甚至是可以加载的so文件。具体根据项目而定。
分级日志插件系统就这么出来了。
首先,我写的这个日志插件,就是实现研发日常的日志记录。和程序员自己使用的记录日志代码本质上没有什么区别。
但是有一条,我的这个插件,支持规则限制。
什么叫规则限制?
也就是可以做到,运维可以任意配置日志规则,而这个配置规则,完全不需要研发参与。
怎么理解?
来看看,我的日志插件依赖的是一个XML的配置文件。

这个配置文件,在测试阶段,是研发配置的,但是在生产环境,似乎运维配置的。
这里有几个参数稍微解释一下。

这是描述生成一个日志文件的具体描述。(文件规则目前是一天一个,以日期为后缀)
logid是唯一的数字标识,用于匹配指定的日志文件模块,下面我会介绍如何使用它。
logtype目前支持两种状态,一种是正常流水日志(0),一种是异常日志(1)。这个由具体日志的使用者配置。
Display表示的是当前输出的日志,是否输出到屏幕,还是输出到文件。0是文件,1是屏幕
Level当前日志级别,这个和整个日志系统互动。一会我会详细说明。
logname日志文件名称,实际生成的日志名称的主词,我会根据这个名称自动生成一个子目录,并在里面根据每天的日志自动生成日志信息。

好了,有了这个,再说明一下运维需要设置的关键参数

CurrLevel当前日志插件的运行模式级别,这个怎么理解?每个日志模块都有一个Level字段。在进程运行的时候,凡是大于此级别的日志才会被输出,这样做,就等于放权给了运维,你决定,那些级别的日志在生产环境是输出成文件的,低于此级别的日志,全部不会生成文件。
所有的日志配置文件,全部由运维和研发商量给出定级标准。
而最终日志配置文件如何配置,由运维给出。
在开发运行过程中,严禁使用诸如printf,fprint之类的东西,或者自己的日志类。所有日志输出必须使用此插件的输出。
目前对研发,它支持3个API接口。研发不用知道日志是怎么实现的,只要先会用就行了。
//nLogType对应logid字段,研发只管写就行了,你不用管运维是如何配置你的日志文件级别。
int WriteLog(int nLogType, const char* fmt, ...);
//二进制字段的输出
int WriteLogBinary(int nLogType, const char* pData, int nLen);
//邮件输出
int WriteToMail(int nLogType, uint32 u4MailID, char* pTitle, const char* fmt, ...);

这里三个API基本能满足所有的日志要求了,文本,二进制,大家都知道。
那么第三个邮件输出,是指,你可以配置一个邮件服务器,当某些日志产生(研发决定),将会将当前日志输出成一封邮件发送出来给指定的邮箱。这个可以权当报警事件或者事件通知事件来处理,运维在生产环境下,可以通过xml来配置自己的邮箱实现对研发的某些约定进行邮件通知的机制。

运维在生产环境上配置的日志插件文件,决定了运维知道哪些日志是干什么的。那么,为什么要运行级别呢?有意思的来了。
我们在实际运行任务中,经常会发现某些数据不正常,需要打印出日志。
但是,如果我们在所有的地方都打印日志,就未免太多了,运维人员也会看花眼。
那么怎么办呢?
我们可以让运维在所有的日志等级上设置级别。
启动进程的时候,比如大于5级的日志,才会输出。
那么当出现问题的时候怎么办?
我们需要运维可以手动的"降级"当前生产环境的日志。这个阶段,进程不需要停止。发送一个指令,让日志插件从5级降到3级,输出所有大于3级的日志。
然后可以导出给研发,或者自己分析后给研发。
导出后,可以再将日志级别"升级"为正常的运维级别(不停机)。保留最少最必要的日志。

这样,就实现了,运维提供日志插件,而研发执行日志输出。至于实际生产环境如何配置,研发不用知道,只要协调好了即可。
这个思维后来被我扩展了,那就是,运维"插件化"的思想。
有时候,并不是所有的东西,都需要研发同事去做的,有些东西,完全可以从运维出发去做,做成可独立封装的类,交付研发,达到自己的目的,谁说运维不会编程?有些高级核心运维写程序比研发还要强呢。
插件化运维的核心思想,就是把自己要收集的资料收集到自己的手里。合理的分配权限,日志可不止只有你研发去看,运维也在看,而更多的是,运维可以动态的决定日志的输出,将极大的提高运维本身的效率。
最后的结果是,民生银行采用了这套运维架构,直接要求所有的第三方产生使用统一的日志模块,并接受日志管理。极大的减轻了运维"低级传话筒"的角色,通过日志的动态"升级" "降级"。甚至可以在不停机的时候导出必要的分析数据。直接升级到了更高级的管理者。并且,结合日志,运维可以开发各种工具实现"表格展示",比如一些通用的开源的图表展示系统,在这里就不介绍了,github自己搜搜吧。

运维人员决定,那些日志,我现在是需要的。而不是研发,毕竟,研发更专注的是实现,而不是运维过程。大家物尽其用,互不干扰。

好了,我的话说完了,希望大家多多提提意见。

哦,当然,我知道,或许你们也想知道代码是怎么实现的是吧,没问题。
附件就是日志插件的源码,有兴趣可以玩玩,你玩的越愉快,我越高兴。当然,欢迎交流

共有 人打赏支持
粉丝 0
博文 9
码字总数 16565
作品 1
×
自由的眼
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: