Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zlog2.0 开发中,求建议,求现实使用反馈。 #35

Open
HardySimpson opened this issue Jul 25, 2013 · 12 comments
Open

zlog2.0 开发中,求建议,求现实使用反馈。 #35

HardySimpson opened this issue Jul 25, 2013 · 12 comments

Comments

@HardySimpson
Copy link
Owner

zlog2.0的目标是:
1.节省内存
2.节省CPU
3.增强性能

这3者是可能实现的吗?我想是的,软件开发,永远都会又更加优雅合适的解决方法,随着时间不断涌现出来。

当然,为了达到这3个目标,zlog的API语义也要有一定的变化

  1. zlog_category_t ,分类,不再是跨线程可用的,多线程下的代码会是这样
    // in thread a
    static zlog_category_t *a_cat;
    {
    a_cat = zlog_get_category("my_cat");
    zlog_info(a_cat, "blablaa...");
    }

    // in thread b
    static zlog_category_t *b_cat;

    {
    b_cat = zlog_get_category("my_cat");
    zlog_info(b_cat, "blablaa...");
    }

2.增加了一个“深度”的配置文件项,更透明的由用户来控制缓存、速度和安全性的平衡。配置文件就像这样:

[global]
  strict init = true
  rotate lock file = self
  auto reload = 3600 # reload configure file once every 3600 second # file mtime

[deepness]
# sign = permisson, buffer size, flush size, flush count, fsync count
  + = 600, 10KB, 8KB, 20, 1000
  - = 600, 10KB, 1KB, 1, 20
 ++= 777, 10KB, 8KB, 100, 0

[levels]
  TRACE = 10
  CRIT = 130, LOG_CRIT

[formats]
  * = "%d %V [%p:%F:%L] %m%n"
  simple = "%m%n"
  normal = "%d(%F %T.%l) %m%n"

[rules]
  *.*                             +"%12.2E(HOME)/log/%c.log"; simple
  my_cat.!ERROR     -"aa.log"
  my_.info                     >stderr;
  my_dog.=DEBUG     >syslog, LOG_LOCAL0; simple

[deepness]决定了zlog给每个文件开多大的用户态缓存、缓存到多少write出去、多久fsync一次,然后以加减号的形式写在规则前面。

  1. 考虑自动重载配置文件这个特性该怎么设计,原先在zlog1.2中开一个计数器,然后每次写日志+1。现在在zlog 2.0中,自动重载打算由时间来触发。问题是,每次写日志的时候,只有在rule或者format里面碰到需要输出时间的时候,才会调用gettimeofday()。如果没有任何一个rule或者format需要时间,那zlog就不会知道现在是什么时候,也没办法去做自动重载。

所以,还是性能和功能的平衡点

我是否应该抛弃自动重载配置文件这个特性呢?
或者在每次写日志函数被调用时,都去跑一次gettimeofday(),无论后面是否需要。然后用这个时间来做自动重载呢?

希望大家能给我一些反馈,任何想法,或者其他希望在zlog 2.0中实现的特性或改变都行。

@boxcounter
Copy link

Hi, HardySimpson:
我使用了您的zlog有大半年的时间了,很稳定且高效。非常感谢您的这个作品。
在使用过程中有一点点想法,借着您这个建议帖反馈给您:

  1. 能否将配置文件升级成xml格式?
    因为我的实际使用环境里提供了一个WEB管理组件,通过它来进行软件的配置。如果配置文件能使用xml格式,那WEB修改起来就更方便了。
  2. 能否在源码里提供了一个ChangeLog文件?

@HardySimpson
Copy link
Owner Author

  1. xml格式或者json格式的配置文件也考虑过。一个是实现起来比较麻烦,要在目前的代码中增加xml解析的代码,破坏zlog的无依赖性;还有就是我试过把配置语句用xml写出来过,规则那段的信息比较冗余,不能像现在那样一目了然的看出输出的关系。可能最后的配置文件会变成这样:
    http://www.cnblogs.com/dflying/archive/2006/12/15/593158.html

2.目前我的历史放在TODO里面,包括想做的和已经做的,下次改个名吧,哈哈。

@boxcounter
Copy link

哈哈,明白。加油,希望2.X版本更出色 :-)

@cy-chengyan
Copy link

不建議搞得太複雜,簡單是最美的,簡單也是最難的。

@fbzhong
Copy link

fbzhong commented Dec 19, 2013

配置文件自动重载是一个好的功能,平时用不上,用上的时候就会觉得非常有用。比如7x24的一个业务,不能shutdown,需要enable某些log(比如DEBUG),这时候就需要修改配置文件,然后Reoad。日志完成后再还原配置。

站在Lib使用者的角度,Zlog Lib原生的支持此功能是最好的,Don't Make Me Think。

@wuqingwei
Copy link

内核打印的支持有没有考虑过?

@heihuhu310
Copy link

作为C库

  1. 无依赖是很重要的一项。
  2. 另一项是功能要短小,精悍,不可求大
  3. 高性能。一般能用C的地方都是系统资源相对紧张,对内存和CPU的占用一定需要着重考虑进来。
    这其中尤其是对多线程安全-锁的使用上更是要谨慎又谨慎,锁是CPU的天敌,万不可滥用,能不用就不用,能少用就少用。

楼主可以参考ccan这个库,其设计值得参考。

感谢开源社区,感谢楼主。

@Evangileon
Copy link

能否考虑增加 level TRACE,reference http://www.tutorialspoint.com/log4j/log4j_logging_levels.htm
并且提供编译期宏,在编译期指定最低级别 LOG,低于此级别的去除log代码,作为log level 的补充,作优化性能之考虑。

@wuqingwei
Copy link

考虑模块可供裁剪?

@ywdzym
Copy link

ywdzym commented Jun 19, 2017

用了HardySimpson的库还是不错的,库的特性很符合C语言的风格,感觉三个方面依然是要保持的
线程安全,高性能,无依赖体积小,这样比较便于保证库在硬件规格可伸缩的系统上的跨平台性。
提几个建议
1、关于配置方式的多样化,可以设计一些适配接口,通过使用者自己实现或或者提供样例适配模块,这样便于整体的结构化和拓展性,都做到一起感觉还是比较臃肿,核心还是无依赖。
2、关于自动加载配置这个功能,不知道该怎么评价,仅仅从自己使用的效果来看,如果本身输出的日志比较少,配置文件又比较大,不想频繁的重载配置文件,这个时候自动加载就很尴尬。特别不知道算不算bug,当我从不输出日志到要输出日志时,该功能完全不生效。目前自己的解决办法是通过自己实现定周期重载配置还有中断形式重载配置来解决问题。
3、关于seq写文件的地方不知道是我理解的有问题还是其他,发现在使用的1.2版本中文件分割有个bug,个数和配置的参数不匹配
4、关于线程ID的地方,感觉可以深化一些线程内容,现有的pthread_self()感觉还是比较单薄。

@ugenehan
Copy link

ugenehan commented Jul 4, 2017

不知道作者是否还会更新2.0

@HardySimpson
Copy link
Owner Author

这两年失去维护这个库的兴趣了~~后面有人想做非常欢迎

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants