系统日志的最佳实践

级别

系统运行过程中,或多或少会产生不同级别的日志:详情、普通、严重、错误等。一般越严重/重要的,产生的数量越少,反之,越多。

在开发环境中,我们一般会启用最详细的级别,这样可以全程跟踪系统运行情况,在生产环境中,我们一般只打开严重/错误级别,因为这样才是我们感兴趣的。但是,但真的遇到严重问题的时候,我们不能定位具体问题,就可能要打开更详细的级别来辅助我们找到问题的根源。

记录/通知方式

一些公司仍然把所有日志写入文本文件,譬如Windows的IIS网络服务器的日志就是用的CSV格式。

稍好一点做法,是数据库表。但是日志数量不断增加,这些数据都存放在一个表里面,迟早也会遇到需要切分的问题,而且一般数据库的成本比磁盘文件要高,所以一般来说,生成环境只记录最关心的内容。

而且,因为日志有一个天生的特点,就是每天记录的产生都有一个时间戳,而且是随着时间变化不断变大。我们做查询的时候,一般是按照时间来排序,最常见的就是倒序,也就是最新的日志,我们最感兴趣。所以,日志在数据库中的存储,一般是按时间戳做聚集倒序索引。

当然还有更特别的,就是遇到严重/异常的时候,通过邮件发送,甚至短信通知运维。

切分方式

一般是按每天来切分存储,如果数据量很大,那颗粒度会更低,譬如每个小时等。也有按大小来切分的,譬如每10M生成一个文件。这些都是所谓的窗口大小,可以按时间、大小、地区、部门等等来切分。

查询统计

日志的记录,除了排除,我们来会用来做数据统计。

然而从不同纬度分析这些数据麻烦,譬如分布式系统哪个地方的哪个模块那些用户群只有特定问题等,而且一般不能实时。

Raygun.io这个云日志服务提供商满足以上需求,他们以前用的nodejs,后来改成asp.net core,性能提升了20倍。

如何设计最佳的日志系统

是否想掌握怎样实现搞性能的分布式系统开发和设计出高效的日志系统?

可以找我们Dev Yeah学习全栈课程!访问官网 DevYeah.com 帮助你快速成长为更优秀的软件工程师!

版权所有

所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

大量报表的生成优化办法

前言

一个页面,加载耗时1.3分钟,分析后发现用的O/RM,我记得12306以前爆是因为用的hibernate,而且没用好。

O/RM有各种硬伤,但总是有优化办法。我改进后测试1秒。

痛点

澳大利亚很多政府/企业财年结束(6月30日)便需要进行一些年度操作,譬如给客户发送年度报告等等。

澳大利亚最大的养老金管理也不例外,需要给数百万用户发送一个流水账单(PDF文件格式),根据多年来的观察和官方的说明,一般需要等到9月底到10月初,这意味着需要起码2个月来处理。

分析

简单计算,意味着顺序处理的话,大概每秒完成一个客户,听起来不算慢。

大家会觉得,一年的流水,多则几百条记录,取出来0.4秒,生成PDF是0.5秒,发送0.1秒,那相当合理。

在这个系列操作中,单个业务的瓶颈可能是:

  • 数据获取/计算
  • PDF生成
  • Email发送

优化

最佳的优化,彻底理解业务逻辑后作出相应的改动。在没有理解业务逻辑之前,我们一般提供效率的做法可能有:

  • 分而治之:多个服务器并行操作,每个负责某个用户组,譬如如果有10台机器,那机器1可以处理10%,如此
  • 队列异步:数据获取/计算、生成PDF和Email都分开队列,异步处理,这样每一步的操作不会因为其中一部堵塞后续的操作
  • 内存操作:PDF生成无需写入磁盘再作为附件发送出去
  • 外部资源:邮件发送可以使用第三方的支持异步的服务,譬如Sendgrid,除了独特的功能之外,我们需要的是无阻塞的异步高性能操作

关于数据获取/计算,如果要做优化,可以在设计上做一些改动,譬如加入每月统计,这样到财年末的时候只需要统计过去12个月的月统计便可。而且这些流水如账本那样,只会append only,不会对现有记录进行改动,所以无需考虑重新统计。

另外,单数据库会是性能(还有安全)瓶颈,完全可以把流水/统计数据放到多节点NoSQL里面,取的时候性能优于关系型数据库。

 

当然,还有一些更高级、复杂的优化实践,有兴趣的同学们可以根据右边二维码加我的微信。

 

想知道为什么我这么多年来能掌握那么多种技术,不仅仅是广度,还有深度,达到我所说的“爆栈”吗?

在《爆栈之旅》,我根据大家都实际情况、水平、方向等规划职业路径,手把手带你做实战的项目,用最高效的办法达到你想要的高度。

爆栈之旅

是否想技术水平快速提升?是否希望快速成为公司的技术骨干?

核心价值
  • 把我这10多年来所学到的知识、总结的经验、吸取的教训分享出来
  • 针对不同的学生量身定制规划学习成长路线、1对1个人指导、代码审阅等
  • 解答各种技术问题
  • 为公司提供技术解决方案

请查看本站右边的信息联系我。

版权所有

所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

爆栈代码方案 – 如何实现快速文件比较和去重

现有方案

我们判断文件是否重复,一般是给两个需要比较的文件进行哈希,然后比较哈希值。

这个做法有个问题,就是比较慢:

  • 如果文件大小不一样,那还需要比较吗?
  • 如果文件的一部分不一样,那还需要比较吗?

新的方案

步骤如下:

  1. 把文件列表按文件大小分组,大小不一的文件会被认为不一样,尽管有可能差异只是空格或者空行(回车换行)
  2. 快速比较文件头、尾、中间的三个部分可定义的一定数量的内容,如果不一样,则会视为不是一样的文件
  3. 渐进式比较区块,任何一个区块的哈希值不一样,则文件为不一样

事实上,BT等下载引擎也是用了类似的办法。

方案特色

  • 支持并行计算,使用MapReduce方式,分而治之,加快比较速度
  • 支持保留比较结果,以备以后和别的文件比较,而且这个比较逻辑和批量比较是一致的

项目开源,地址在这里

 

爆栈之旅

是否想技术水平快速提升?是否希望快速成为公司的技术骨干?

核心价值
  • 把我这10多年来所学到的知识、总结的经验、吸取的教训分享出来
  • 针对不同的学生量身定制规划学习成长路线、1对1个人指导、代码审阅等
  • 解答各种技术问题
  • 为公司提供技术解决方案

请查看本站右边的信息联系我。

版权所有

所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。