互联网创业中的日志系统选型

对于一个互联网创业公司来说,其生存所依赖的业务系统每天都会产生大量的日志,比如系统日志、业务流水日志、程序异常日志、访问日志、审计日志等等。通过收集业务日志数据,供离线和在线的分析系统使用,以支持线上业务或运营分析等使用。

日志除了供分析系统使用以外,更多的时候开发同学会依赖日志排查问题。当我们需要使用到日志排查问题时,它们往往是我们手上唯一可以用来查明当时的发生状况和问题的根本原因的有用信息,并且在开发过程中,我们也会使用日志查看程序运行时的状态。

日志系统三部分

关于日志,分为三部分:

  1. 打日志 打日志可以分为客户端日志和服务端日志,这两种日志都会包含日志的基本功能,排查问题、查看运行时状态和供分析系统使用;

  2. 收集日志 当日志打在客户端,或打在分布式的服务器时,就需要将这些分散在各地的日志收集回来;

  3. 分析日志 当从日志中心下载到日志后,根据实际的需求我们需要分析日志,可能是给分析系统、告警系统或者业务系统使用,又或者是直接给到开发同学确认排查问题等等。

打日志

日志分级

按 RFC5424 的标准,日志级别分为八个级别,分别是:

  • 0 Emergency 紧急:系统已不可用
  • 1 Alert 警报:必须立即采取措施
  • 2 Critical 关键:临界条件
  • 3 Error 错误:错误条件
  • 4 Warning 警告:警告状况,系统能继续运行
  • 5 Notice 注意:正常但重要的条件
  • 6 Informational 信息:参考消息,关键路径的打点日志
  • 7 Debug 调试:调试级消息,所有有用的信息

以上为新的标准,但在实际工作中经常会用到一种简化版本

  • Error:系统发生了严重的错误, 必须马上进行处理, 否则系统将无法继续运行. 比如, 保持的连接断开,服务不可用,存储写不进去了等.

  • Warning:系统能继续运行, 但是必须要关注了,可能是系统存在潜在问题,此处需要在日志备注说明中列出可能有哪些问题,也可能是一些明显的异常,此时需要人工介入检查,不过实际工作中,此类日志一般是在出了问题后才会去看.

  • Info:重要的业务逻辑处理完成. 比如一个登录逻辑,哪个用户登录了就可以写到 Info 日志中。

  • Debug:调试类信息,量会非常大,主要给开发人员看,在各种日志库中,除了Debug 还会有一个 Trace 级别,实践中我们打 Debug 日志就好,不用再细分更详细的级别了。

并且,在不同的环境部署的日志级别也不同。

  • 正式环境:个人习惯用 Info,Info 级的日志能让我看到关键的信息,在排查问题时会比较有用;也会有人或开源的组件会开启 Warning,甚至 Error;
  • 测试环境:可以开到 Debug 级,也可以默认开 Info 级,当需要排查某些特殊问题的时候再开到 Debug 级;
  • 开发环境:任何对实际开发工作有帮忙的信息都可以打到日志中,一般是 Debug 级。

在实际工作中个人建议用简化版的四个等级即可,就算打日志的 SDK 提供了 8 种级别,也可以只用你需要的简化版本。

日志包含的字段

日志包括的必要字段:

  • Version 版本
  • TIMESTAMP 时间戳,当无法获取时间戳时使用NULL
  • APP NAME 用来标识设备或某个应用
  • MSG TYPE 消息的类型 具有相同的 MSG TYPE 应该反映相同语义的事件
  • MSG CONTENT 消息内容 日志具体的内容

重要字段:

  • RESULT 结果 表示当前的结果
  • CONSUMED TIME 花费时间,表示在当前阶段花费的时间
  • SOURCE 来源 比如来源的ip,调用方等
  • LOCATION/PATH 调用的位置或路径 表示调用的地方,常用来排查问题和查看执行流程,可能会精确到某个文件的某一行

打日志的原则

  1. 染色体系 给每一次请求加上一个全局的logid(id全局唯一,最好是能根据id定位到业务或用户,比如业务编号+用户编号+时间戳+随机数),每次记日志的时候,logid打出来,所有底层的框架在调用的时候,需要在公共属性部分将这个logid传过去,打印的所有日志都要带上这个logid。这样所有的业务,所有的服务,不管有多少系统,有多少机器,在处理同一请求时,都可以根据logid找到所有的日志,如果把所有的日志都收集到日志中心,就可以按时间序将所有的请求过程打印出来。染色体系是一个系统工程,需要底层框架的支持。

  2. 结构化的数据 包含用户IP,时间,所在业务,所在机器,所在服务,所在类或函数,甚至到哪一行代码; 将什么时候,什么业务,在什么地方发生了什么事情,描述清楚这些,使得日志可追溯。结构化的数据最要是有日志类库保证其结构的完整性。

  3. 日志是给人看的 需要更友好的语言表述,不要写一些没有语义的日志,比如 保存数据错误 之类的,这里最好是说明谁在哪里保存什么样的数据错误。

收集日志

当日志以规范的格式打印出来后,我们需要收集这些日志以供后面的流程使用,如前面说的分析系统,或给到开发同学定位排查问题等等。

日志最终都是文本,当业务不大,单机的文本日志就能满足需求,甚至一些监控类的业务也可以在单机文本日志的基础上实现;然而,文本日志本身有两种方式:

  • 一种是直接日志类库写到本地的单机文本日志,这种方式的优点的是简单,易实现;缺点是日志打得比较散,需要有额外的手段来归拢日志,如最简单的,用 rsync 实现多机日志同步脚本部署,这种简单情况一般出现于仅需要将文本日志归集的简单实现,另外更复杂一些收集方案可以考虑 ELK 等开源方案;对于一个已有业务来说,这种把日志落到本地硬盘的方式对业务侵入最小最自然。以 ELK 收集日志为例,其结构示例所下所示:

    (1) LogStash Agent:在各台机器上部署的Agent,用来上传日志到队列
    (2) Redis: 接收日志的队列,削峰填谷,
    (3) Logstash集群:做日志解析,统一成 json 格式输出给 Elasticsearch ,json 格式的好处是直接
    (4) Elasticsearch:实时日志分析服务的核心技术,实时的数据存储服务,通过 index 组织数据,兼具强大的搜索和统计功能。
    (5) Kibana:基于 Elasticsearch 的数据可视化组件,前端操作非常方便,用鼠标几次点击即可完成搜索,聚合,生成报表等功能,这种可视化能力是大家选择 ELK Stack 的很重要的原因。

  • 另一种是提供一个专门的日志服务,日志服务包括写入者,中继者,收集者,存储者。

    (1)写入者: 日志服务提供专门定制的 SDK,业务直接调用 SDK 即可,SDK 负责日志的写入,直接与 Agent 通信,通过 Agent 将日志传输到 Collector 节点;
    (2)中继者: Agent 是中断者,实现日志在客户端的转发和本地存储,其可以在类似于 supervisor 等进程管理程序的监控下运行,通过第三方程序监控进程状态,异常退出时自动拉起,对于特别重要的日志可以考虑先落到硬盘再转储;
    (3)收集者:Collector 是收集者,其需要集中部署在某个集群,负责接收 Agent 发送的日志,并且将日志根据定义好的规则写到相应的 Store ;
    (4)存储者:Store 是存储者,Collector 和 Store 可以部署在相同的地方,也可以分开,一般我们将历史日志按天存储到 hadoop 中,供后续离线分析使用,与此同时,如果业务有需要,可以将日志也分发一份到 Storm 系统提供实时日志分析;

    以上的日志服务是属于比较完备的版本,如果业务不是那么复杂,可以根据自己的实际情况选择使用全部或部分功能;甚至更简单一些,日志服务本身可以仅仅是一个 UDP 的 socket 服务,将收集到的日志直接存储到本地,最多加个归档压缩。

日志的后续使用

当我们按照要求收集到足够的日志后,我们对这些日志可以做很多事情,如监控,实时搜索,问题定位等等,以 ELK 架构为例,见下图:

在日志经过 MQ 时,我们可以将日志转到到两个地方,一个是实时监控服务,针对日志中有问题的内容做实时的告警,并将规则匹配后的内容存到Jira中,用于问题记录、派发和追踪。 Jira的作用只是问题的跟进,相对简单一些,监控这块我们更推荐使用 Zabbix 类系统的日志监控来实现,制定日志监控规则,对日志做上报分析处理和告警监控,这样会更实时,更灵活。

另一个是将日志转到 ES, ELK Spark可以做实时的搜索和报表,报表呈现方为 Kibana,另外 ES 结合其自己的 Hadoop Plugin,通过 Hadoop2 做 Map Reduce 的计算反向投递给业务系统。

Kafka 中的日志保留最近几天的,并给 Storm 等实时分析系统提供数据源。

对于落到 ELK 的数据,如果有做染色,可以在 Kibana 的搜索界面中根据染色标志搜索出定位问题所需要的信息。

在创业的过程中,一个好的、在当下合适的日志系统选型能处理前期业务中的关于日志的大部分问题,也能满足后期的扩展需求。在这个阶段,除非之前有日志服务相关的系统可以重用,否则建议直接使用写本地文件,使用 ELK 收集日志的架构。其中关于写日志,找一个标准库自己封装一下对外接口,按照约定写即可;关于染色系统,前期如果资源不够,可以考虑不用上,待后期有资源投入后开发公共组件或框架。

参考资料: http://diyitui.com/content-1432833903.30823746.html


除了眼前的苟且,还有架构与远方。

介绍创业路上的技术选型和架构、大型网站架构、高性能高可用可扩展架构实现,技术管理等相关话题,紧跟业界主流步伐。

qrcode_for_gh_5d3f534e15fe_344 (1)

浅谈创业早期技术实现思路

20130108093351_79502-1068x784

浅谈创业早期技术实现思路

创业最开始的时候,是最难的时候,此时,从0到1,从无到有,做的是自己不曾做过的事情,所以,我们称之为创业。

对于早期的技术而言,不要大而全,不用高精尖,先按需求实现,活下来再说。我们需要考虑的是哪些可以用云服务,哪些可以直接用现成的开源方案或技术,哪些需要自己开发; 我们可以粗旷一些,要的是快速出活,让产品活下来。

前期那么几杆枪,就技术而行,要用团队成员最熟悉的,要有人能全盘掌控所有的技术栈。虽然我们用的是最熟悉的东西,但是在整个技术选型和开发过程中,需要有以下几个基本的思路:

1. 原则和规范

  • 注意解耦,分层,动静分离、轻重分离的原则;
  • 开发的规范,代码及代码分支管理规范、发布流程;
  • 在开发过程中,对于公共的操作要抽象成组件,即我们常说的职责单一,如缓存操作,数据库操作等等都封装成组件,一边开发一边封装;

2. 保留水平扩展的能力

  • 业务服务端无状态,会话通过 memcache 等来管理;
  • 数据库设计考虑到一定时间内的容量,做好必要的分库分表,如1到2年的容量规划;
  • 热点数据缓存起来,将大量请求打到缓存而不是数据库;

3. 业务隔离

  • 隔离关键业务和非关键业务;
  • 隔离主业务系统与旁路上报、日志上报等周边系统;如果是 HTTP 服务,至少要在域名级别保证其隔离;
  • 不同端业务的隔离; 如 PC 侧的业务和 H5 的页面可以是同一套代码,但是域名不同,接入点不同,后端机器相同;

4. 用好开源的轮子

  • 在满足现有业务需求的情况下,对业界开源的轮子做技术选型,在能驾驭的前提下尽量使用已有的,成熟的,经过了大量公司实践的开源组件,如nginx,redis,elk等等。

5. 必要的安全策略

  • 安全是互联网应用无法回避的问题,我们需要在框架或基础组件层面引入常见的 XSS 、CSRF 和 SQL注入等安全问题的过滤;
  • 对于静态的能放到CDN的内容尽量放到CDN,一是就近接入,提高访问速度,二是减少后台的服务压力;
  • 保留快速切到云服务防 DDoS 的能力;
  • 在业务层面实现一定的规则以及联合 WEB 容器实现一定程度上的防 CC 攻击能力;

6. 备份、备份、备份

  • 宕机、不同城市的机房同时起火、光缆被挖断、数据错乱等等各种神奇的事情都有可能出现,此时备份就显示出其价值。我们不仅仅是要备份业务数据库,还要备份代码,备份部署脚本等等;
  • 当所有的不幸都发生的时候,我们所有的东西都不见的时候,我们能够很快的将应用恢复到上一个可预见的备份版本,即我们有灾备方案,最好是能够提前演练过;

7. 监控可能出现的异常

  • 使用第三方的监控服务监控网站的访问可用性,服务的可用性等;
  • 对业务的数据和关键的节点进行监控,比如做金融的需要确认每个用户的进出钱要对得上账,在这里至少要有一个监控;

8. 灰度发布

  • 前期按机器做灰度发布,一个简单的脚本就可以搞定,后期可以实现按用户灰度等,以此提高业务的连续性,保证业务的可用性;

从 0 到 1,不管是技术还是业务都是不成熟的,大家都是摸着石头过河,所以我们需要快速的试错,需要快速的反馈。

在技术层面,在保证以上一些原则的同时,快速迭代,实现产品需求,对于一些出错统计类的东西直接交给第三方来实现;在业务层面,如果是网站,一些流量分析直接也是直接交给第三方,比如百度统计,Google Analytics等,对于具体的业务,一个脚本每天早上跑出报表以邮件的形式发到指定邮件组,将相关人加入邮件组列表接以能接收到报表邮件。

以上是最开始需要注意的原则和必须要实现的东西,在此之外,还有很重要的需要搭建的内容需要持续搭建和实现,包括但不限于以下一些:

  1. 降级服务能力:在遇到正常或不正常的大流量时,可以在一定范围内将业务降级,业务降级可以前期提供手动降级能力,后续实现自动降级;
  2. 第三方服务可替换:花钱能解决问题,但花钱一般不能真正的解决问题,因为花钱买来的可能是一个坑,还是一个需要自己填的坑。在使用第三方服务时,需要多家备用可替换,如短信服务,多接两家,平时两家均衡分发,或者按业务分发,当某一家出问题时,直接切到正常的那家;
  3. 日志中心:日志是定位问题的必备工具,当后台服务有多台机器时,就不能一台一台的用 grep 搜索了,需要有一个集中存储的地方,直接上一个 elk 也许能解决大部分的问题;

创业要的是活下来,技术要的是产生价值。 架构会随着业务的发展而不断的演化。


除了眼前的苟且,还有架构与远方。

介绍创业路上的技术选型和架构、大型网站架构、高性能高可用可扩展架构实现,技术管理等相关话题,紧跟业界主流步伐。

qrcode_for_gh_5d3f534e15fe_344 (1)

50天1个亿,不曾到过的世界-创业半年小结

 

2015年过完年,er又打来了电话,从去年开始,已经是第6次了,包包已经会走了,开始学会通过撒娇、大哭达到自己的目的。和er聊了1个小时,答应晚上和夫人商量一下,心已动摇。这个问题和夫人已讨论多次,还是在犹豫,不知是对未知的恐惧,还是对当下的不舍。

最终决定去上海,和er一起创业。梦想还是要有的,万一实现了呢。

选择离开

”橘子红了,是该摘了。“ -- 《橘子红了》

在腾讯的生活充实,有序,领导重视,同事nice,一切的一切都显示得让人无法离开。

创业是选择要未来,而不是现在--冯仑。

这样的当下,这样的现在,真的舍得?

和leader面谈、和总监面谈、和HR面谈、和GM面谈,惭愧,愧疚,不舍……

一切显示如此匆忙,在腾讯的日子越来越少,看着周围的同事都在忙活,心里不免有一些失落……

离别总是别样的风景,在腾讯的682天,2次晋升、3次发文奖励、1次优秀员工,得到了自己想得到的,遇见了自己该遇见的。在腾大7楼退掉工卡,慢慢走出腾讯大楼,回头看去,有些模糊了。

重新启程

”天青色等烟雨,而我在等你。“——《青花瓷》

3.31号,愚人节的前一天,从上海浦东机场转磁悬浮,5站地铁,到了世纪大道,在2号口见到了依稀有些丰满的er,在网上认识很多年,一直未曾见过面,总算见到活的张er。第一次见面,仿佛现实中认识了很多年,是如此熟悉。

到了办公室,略拥挤,er说已经在张罗新的办公场地了,先将就下,研发部20多人,移动开发,后台、前端、设计、测试。已经是下班时间了,还有一半的人在,有新版本准备上线。

之前已经了解过后端的代码了,对于数据库结构及代码基本已经摸清了,后面就是人员的磨合,对具体业务和流程的熟悉,紧张而忙碌。

一晃一月过去了,经历了几次问题,幸运的是最终都得以妥善解决。在此期间日志系统、监控系统、数据监控系统等周边系统逐步上线,一切朝着稳定的方向前进。

新的挑战

”谁的江山,马蹄声狂乱,我一身的戎装,呼啸沧桑“——《菊花台》

搬到新的办公场地,还没有装修好,一切从简。

面对着黄浦江,看着江上船来船往。

有一天,er忽然抬头笑道:你看,这江边有很多树啊

我道:嗯。 

er道:你可知道有多少棵 

我道:三十七棵。 

er的心沉落了下去,笑容也冻结。 

因为他数过江边的树。他了解一个人在数树时,那是多么寂寞。

4月25日,火理财项目正式启动,第4天后台所有接口ready,第8天,iOS版本出企业版,第10天,安卓版上线,创业的速度,创业的激情,狼性的团队,已不再是寂寞。

内测版通过,公测版通过,5月正式上线。

不曾到过的世界

“有的人求名,有的人求利,我求的是什么呢?”  -——《陆小凤传奇》

第1期,1万

第2期,50万 144小时

第3期,100万 14小时

第4期,100万 10小时

……

……

第65期,700万 12小时

到第40期,项目投资总额就已经超过了1个亿。

见或不见,一个亿就在那里,不悲不喜

念或不念,一天700万就在那里,只增不减

跟或不跟,各种问题就在那里,不增只减

这样的一个世界,光怪陆离,不曾到过,曾想过,只是没想过会来得这么快。

手机24小时开机,电脑24小时在身边,快速处理所有发生的问题,我们做的是金融,过手的都是钱,不能有个万一,兢兢业业,诚惶诚恐。

新版快速迭代,两周一个版本,每天后端都有迭代发布,新的规划正在实现,如此滚动……

后记一 关于技术

  • 当业务需要时,使用数据库的最高级别的事务机制保证数据的完整性;
  • 在数据库层面制定好数据约束,即使代码出错最终也不会影响数据;
  • 用户的操作最好在数据中体现出来,确保数据的完整性,关键性操作数据需要有日志类结构存在
  • 如果有第三方接口、服务或数据,在离这些接口、服务最近的地方我们需要有一个完整的日志,忠实于数据的出和入。
  • 初期个人分支开发,主干发布,中后期版本分支开发,主干发布,确保主干的持续可用。
  • 如果可以用人肉临时去解决,而技术要花比较大的成本或难度,那么直接用人去解决吧。
  • 在做方案时需要考虑数据的可追溯,特别是重要数据,简单一点留个操作日志,复杂一些,从数据结构上保证数据的可追溯。

后记二 关于管理

  • 不认同,但是执行
  • 我们要依次管理好人、产品(包括技术)和利润
  • 项目管理方式得看人,员工能力不足管理跟上,员工能力足够可以粗放管理
  • 打工要nice,创业要狼性,一团和气,必然低效
  • 当团队成员能力不齐,有高有低时,需要采用不同的管理方式,对于水平高的要多放手,少跟进,关注结果,对于水平不高的,要排期到天,多跟进。
  • 创业时需要考虑人力成本,以及人的投入产生比,重要的人做重要的事情,让其发挥其应有的价值,不合适的人要早点淘汰。
  • 管理者的分工是让大家更好,更流畅的协同工作,向同一个目标前进。团队成员可以个性鲜明,但是不能让大多数人迁就极个别的人。
  • 上层看问题,下层做事情
  • 管理者的工作:收集信息,决策

最后 招聘

开发经理

我们希望你是:

  • 能cover住20人+的团队的能力,不仅仅是某种技术
  • 能cover住每天上千万的资金流
  • 能够把握住项目的节奏,对项目结果负责

除了开发经理,我们还需要更多的PHP、安卓、iOS、前端、UI、Java、测试。欢迎推荐和自荐,base in 上海。

我的QQ:81894135