日志分析(php+nosql+rsync+crontable)

2024-06-21 10:48

本文主要是介绍日志分析(php+nosql+rsync+crontable),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

是不是常常要分析用户的行为?是不是常常遇到多台服务器上传的日志一起分析?是不是对数据统计的间隔时间要求很短?还有木有因为日志文件过大,而需要分块处理?

1、说明一点在日志写入的时候必须按照一种严格的格式,这样在做解析的时候,才好切割。比如 gameid:123  gameid:2333。切割统一标准就行。

2、在生成日志的文件名的时候也要按照一定规则,在分析的时候,正则表达式好匹配,如 服务器hostname_date.log  这样在匹配的时候 只需要 glob(*—date.log); //glob 见php函数手册,寻找与模式匹配的文件路径。

3、为什么要用nosql?其实工程师不是仅仅局限于知道怎么实现,而是要多思考什么样的业务用什么样的工具来解决。非关系型数据很适合这种,日志中常常加入新的行为,你用key-value的方式,不需要日志新增了要分析的行为,你就得手动改变你程序的配置,这样我个人觉得不是太好。~假如用mysql,你纵向设计数据库,

结构: id gameid count createtime

          1   1001    3000  2013-03-23  12:22:21

          2   1002   2222   2013-03-23  12:22:21

        ………………

这样设计的话那么不会因为新增gameid来修改数据表,这样有什么坏处?那就是每次插入数据很多,假如30秒插入一次,一次插入30个游戏的统计值,那么一天的增量  2*30*60*24 = 86400 条数据,这样显然不合理。

那么横向设计,一次插入一条数据。

id gameid_1001 gameid_1002 gameid_1003 …… createtime 

1  3000             2222             40000               2013-03-23 09:08:56

2  4000             1800             4000                2013-03-23 09:09:20

……

 这样的坏处是 每次新增了游戏ID 那么就得改变数据表结构,加字段,当然你牛逼点的可以全部用程序来实现,但是这样我觉得不太好。

mongo中有这个内嵌文档,很爽。推荐使用hadoop

存储结构如下

        +{

            "_id":3e3ess3sazxcdsdsfdf,

            "createtime":"2013-03-23 09:13:02",

            "data":{

                    "gameid_1001": 2000,

                    "gameid_1002": 3000,

                    ……

                      }


        }

一次只插入一条数据,新增游戏类型不需要做任何改变,perfect~

4、为什么要用rsync?将多台服务器的日志同步到一个目录下,一起处理,比较方便。

5、需要用到的几个函数,glob, fopen,fget,isset,explode

程序最好不要写得很死板,

 批量读入日志文件

$sLogfileName = '/path/../*_date.log';

$aLogfileName = glop($sLogfileName); // 匹配要处理的日志文件,读入数组中。

……

fopen();

while() //用while循环,处理完文件中的一行数据再去文件中取,如果用foreach一次读入数组,内存会溢出。

{

……

}

……

$aCountResult = array();

$iNum = 100;

if(isset($aCountResult[$iGameId]))

        $aCountResult[$iGameId] = (int)$aCountResult[$iGameId] + $iNum;

else

        $aCountResult[$iGameId] = $iNum;

……

统计完插入。。

然后加入计划程序中,ok。。

主要还是不同的业务用不同的方法解决。

@update 2013-3-25 21:31:45

在日志分析中 \n 是一个很重要的切割符,避免防止内存溢出,不要以 \n

EOF 作为切割符,同事要严格按照日志标准格式写入,这样在解析的时候比较好解析。用fgets方式获取,不能一次读入内存中。

这篇关于日志分析(php+nosql+rsync+crontable)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1081010

相关文章

Nginx分布式部署流程分析

《Nginx分布式部署流程分析》文章介绍Nginx在分布式部署中的反向代理和负载均衡作用,用于分发请求、减轻服务器压力及解决session共享问题,涵盖配置方法、策略及Java项目应用,并提及分布式事... 目录分布式部署NginxJava中的代理代理分为正向代理和反向代理正向代理反向代理Nginx应用场景

Redis中的有序集合zset从使用到原理分析

《Redis中的有序集合zset从使用到原理分析》Redis有序集合(zset)是字符串与分值的有序映射,通过跳跃表和哈希表结合实现高效有序性管理,适用于排行榜、延迟队列等场景,其时间复杂度低,内存占... 目录开篇:排行榜背后的秘密一、zset的基本使用1.1 常用命令1.2 Java客户端示例二、zse

Redis中的AOF原理及分析

《Redis中的AOF原理及分析》Redis的AOF通过记录所有写操作命令实现持久化,支持always/everysec/no三种同步策略,重写机制优化文件体积,与RDB结合可平衡数据安全与恢复效率... 目录开篇:从日记本到AOF一、AOF的基本执行流程1. 命令执行与记录2. AOF重写机制二、AOF的

MyBatis Plus大数据量查询慢原因分析及解决

《MyBatisPlus大数据量查询慢原因分析及解决》大数据量查询慢常因全表扫描、分页不当、索引缺失、内存占用高及ORM开销,优化措施包括分页查询、流式读取、SQL优化、批处理、多数据源、结果集二次... 目录大数据量查询慢的常见原因优化方案高级方案配置调优监控与诊断总结大数据量查询慢的常见原因MyBAT

分析 Java Stream 的 peek使用实践与副作用处理方案

《分析JavaStream的peek使用实践与副作用处理方案》StreamAPI的peek操作是中间操作,用于观察元素但不终止流,其副作用风险包括线程安全、顺序混乱及性能问题,合理使用场景有限... 目录一、peek 操作的本质:有状态的中间操作二、副作用的定义与风险场景1. 并行流下的线程安全问题2. 顺

MyBatis/MyBatis-Plus同事务循环调用存储过程获取主键重复问题分析及解决

《MyBatis/MyBatis-Plus同事务循环调用存储过程获取主键重复问题分析及解决》MyBatis默认开启一级缓存,同一事务中循环调用查询方法时会重复使用缓存数据,导致获取的序列主键值均为1,... 目录问题原因解决办法如果是存储过程总结问题myBATis有如下代码获取序列作为主键IdMappe

Java 日志中 Marker 的使用示例详解

《Java日志中Marker的使用示例详解》Marker是SLF4J(以及Logback、Log4j2)提供的一个接口,它本质上是一个命名对象,你可以把它想象成一个可以附加到日志语句上的标签或戳... 目录什么是Marker?为什么使用Markejavascriptr?1. 精细化的过滤2. 触发特定操作3

linux查找java项目日志查找报错信息方式

《linux查找java项目日志查找报错信息方式》日志查找定位步骤:进入项目,用tail-f实时跟踪日志,tail-n1000查看末尾1000行,grep搜索关键词或时间,vim内精准查找并高亮定位,... 目录日志查找定位在当前文件里找到报错消息总结日志查找定位1.cd 进入项目2.正常日志 和错误日

Java中最全最基础的IO流概述和简介案例分析

《Java中最全最基础的IO流概述和简介案例分析》JavaIO流用于程序与外部设备的数据交互,分为字节流(InputStream/OutputStream)和字符流(Reader/Writer),处理... 目录IO流简介IO是什么应用场景IO流的分类流的超类类型字节文件流应用简介核心API文件输出流应用文

PHP轻松处理千万行数据的方法详解

《PHP轻松处理千万行数据的方法详解》说到处理大数据集,PHP通常不是第一个想到的语言,但如果你曾经需要处理数百万行数据而不让服务器崩溃或内存耗尽,你就会知道PHP用对了工具有多强大,下面小编就... 目录问题的本质php 中的数据流处理:为什么必不可少生成器:内存高效的迭代方式流量控制:避免系统过载一次性