php+mysql日志系统设计

  1. 云栖社区>
  2. 博客>
  3. 正文

php+mysql日志系统设计

梧桐_ 2019-02-26 14:19:44 浏览839
展开阅读全文

日志系统的作用:
1、了解线上系统的运行状态
2、快速准确定位线上问题
3、发现系统瓶颈
4、预警系统潜在风险
5、挖掘产品最大价值
6、……

设计目标:
1、支持高并发日志写入
2、亿级消息内容存储
3、支持监控报警
4、分布式、高可用

存储选择:
mysql TokuDB+redis
mysql TokuDB是一个支持事务的“新”引擎,有着出色的数据压缩功能。经测试,压缩后的数据只占原数据大小的10%以下。
redis用来做队列,解决日志并发写入的压力。

字段设计:
id 主键
type 日志类型
client_ip 客户端ip
service_ip 服务器ip
site 站点名
file_path 文件路径
name 日志名称
content 日志内容(数组需要json_encode)
cookie 当前的cookie内容(需要json_encode)
url 当前的url
params 当前的url参数(需要json_encode)
create_time 时间
notice 通知方式(对应通知类型的配置文件)

日志类型:

FATAL – The FATAL level designates very severe error events that will presumably lead the application to abort.
ERROR – The ERROR level designates error events that might still allow the application to continue running.
WARN – The WARN level designates potentially harmful situations.
INFO – The INFO level designates informational messages that highlight the progress of the application at coarse-grained level.
DEBUG – The DEBUG Level designates fine-grained informational events that are most useful to debug an application.

对于日志级别的分类,有以下参考:
FATAL — 表示需要立即被处理的系统级错误。当该错误发生时,表示服务已经出现了某种程度的不可用,系统管理员需要立即介入。这属于最严重的日志级别,因此该日志级别必须慎用,如果这种级别的日志经常出现,则该日志也失去了意义。通常情况下,一个进程的生命周期中应该只记录一次FATAL级别的日志,即该进程遇到无法恢复的错误而退出时。当然,如果某个系统的子系统遇到了不可恢复的错误,那该子系统的调用方也可以记入FATAL级别日志,以便通过日志报警提醒系统管理员修复;
ERROR — 该级别的错误也需要马上被处理,但是紧急程度要低于FATAL级别。当ERROR错误发生时,已经影响了用户的正常访问。从该意义上来说,实际上ERROR错误和FATAL错误对用户的影响是相当的。FATAL相当于服务已经挂了,而ERROR相当于好死不如赖活着,然而活着却无法提供正常的服务,只能不断地打印ERROR日志。特别需要注意的是,ERROR和FATAL都属于服务器自己的异常,是需要马上得到人工介入并处理的。而对于用户自己操作不当,如请求参数错误等等,是绝对不应该记为ERROR日志的;
WARN — 该日志表示系统可能出现问题,也可能没有,这种情况如网络的波动等。对于那些目前还不是错误,然而不及时处理也会变为错误的情况,也可以记为WARN日志,例如一个存储系统的磁盘使用量超过阀值,或者系统中某个用户的存储配额快用完等等。对于WARN级别的日志,虽然不需要系统管理员马上处理,也是需要及时查看并处理的。因此此种级别的日志也不应太多,能不打WARN级别的日志,就尽量不要打;
INFO — 该种日志记录系统的正常运行状态,例如某个子系统的初始化,某个请求的成功执行等等。通过查看INFO级别的日志,可以很快地对系统中出现的 WARN,ERROR,FATAL错误进行定位。INFO日志不宜过多,通常情况下,INFO级别的日志应该不大于TRACE日志的10%;
DEBUG — 这两种日志具体的规范应该由项目组自己定义,该级别日志的主要作用是对系统每一步的运行状态进行精确的记录。通过该种日志,可以查看某一个操作每一步的执 行过程,可以准确定位是何种操作,何种参数,何种顺序导致了某种错误的发生。可以保证在不重现错误的情况下,也可以通过DEBUG级别的日志对问题进行诊断。需要注意的是,DEBUG日志也需要规范日志格式,应该保证除了记录日志的开发人员自己外,其他的如运维,测试人员等也可以通过 DEBUG日志来定位问题;

参考文档:

1、Seaslog http://blog.csdn.net/yangzaiqiu1986814/article/details/50728053

2、https://www.zhihu.com/question/21427267

3、https://zhuanlan.zhihu.com/p/27363484?hmsr=toutiao.io&utmmedium=toutiao.io&utmsource=toutiao.io

网友评论

登录后评论
0/500
评论
梧桐_
+ 关注