业务场景
目前公司采用的游戏日志采集方式为一个服对应于一个日志库,然而游戏后台希望可以实时对这些游戏日志进行分析,当服不多时,这个还可以实时查询,但是游戏服越来越多的时候,这个就有瓶颈了,因为查询的时候后台是希望选择多个服一起进行日志分析的,尽管可以利用多线程进行查询,但等待时间还是会很长(因为服的数量会逐渐比线程数高),甚至直接就超出了网页的等待时间,报504网关等待超时。
后来,针对于查询时间过长甚至查不出结果的情况,做了如下改善:把需要进行的日志分析封装成一个个的定时任务,利用每天的凌晨某个时间跑这个任务,一个任务就会有一个和该任务关联的结果集,并且这个结果集保存在后台本地。那么当用户在后台对相应的日志模块进行分析时,直接读取后台本地的该任务管理的结果集即可。这样一来,确实解决了查询时间过长的问题。但是,随着游戏服的越来越多,在凌晨跑的那些日志分析任务所需要的时间越来越长了,更极端的一个情况就是可能会出现,从第一天的凌晨开始跑(比如一个任务是凌晨1:00开始的),也许到了第二天的凌晨的这个任务时间段(第二天的凌晨1:00,这个任务又到了执行时间了),前一天的该任务都没跑完,新一天的该任务又要开始了。这样循环下去,所需时间会更长,也有可能分析出每天的日志分析结果。
数据库用的是mysql(不管是游戏服的日志库还是后台的结果集),如何在不需要更改数据库的情况下(因为游戏服的日志库那边暂时不可以更改库,即使有想过改成mongodb),在现有的方案上进行优化呢?(假设我那些任务中都不会存在慢查询的情况,但是还是需要很长时间,因为服多)。在此,希望各位有经验的大神给小弟指点指点(⊙o⊙)。小弟感激不尽~~~
logstash
에 로그를 작성하세요.elasticsearch
이것은 매우 성숙한 로그 분석 솔루션입니다. 사용 방법도 매우 간단합니다.
logback-encoder
을 사용하여 logstash-logback-encoder현재 데이터베이스 구성표를 수정하지 않더라도
elasticsearch
을 사용하여elasticsearch
으로 데이터를 가져올 수 있습니다.위 내용은 정말 추천할만한 로그 수집 및 분석 솔루션으로, 추가적인 정리나 변환이 필요하지 않은 명확한 로그 형식을 가진 로그 유형에 적합합니다. 로그 데이터를 정리하거나 새로운 형식으로 변환해야 하는 경우 Kafka + Spark 스트리밍 + Hive on Spark 솔루션을 사용하는 것이 좋습니다. 실제로 결과를 Mysql과 같은 관계형 데이터베이스에 저장하면 전체 분석 적시성에 병목 현상이 발생하므로 결과를 다시 Mysql에 저장하는 것은 권장되지 않습니다. 또한, 해당 플랜의 사용 방법은 온라인에서 확인할 수 있습니다.