日志统计

2024-08-24

日志统计（精选3篇）

日志统计篇1

对于所有服务器运行管理人员而言,服务器系统日志是一类需要经常查看文档,这些文档能记录服务器在运行过程中发生的各类事件,以便于管理人员对服务器进行维护、排故及用途规划等。但是在Linux系统中很多的日志文档可读性差,而且数量多,往往用vim/vi打开后看不出特定数据的总体情况,只能看到每条日志的具体内容。为了方便维护人员能够迅速对日志有一个总体的了解,设计并实现了一个简单的日志统计工具。

1 程序设计

设计的工具主要由3大部分组成,分别是:参数校验、数据统计及结果显示。如图1所示。

参数校验阶段主要由5个子函数联合实现:_rc_file、_read_rc、_parse_rc、_merge_rc及_parse_rc。如图2所示。

当启动程序,stats命令在读取命令行参数前将会寻找配置文件。默认的配置文件是以“.statsrc”结尾,可以使用“--rc”参数来特别指明此类配置文件。一般配置文件默认的存放路径在$HOME下,但是如果STATSRC_DIR环境变量被修改,那么stats命令将在指定目录及当前目录寻找配置文件。系统通过_rc_file子函数来识别“--rc”参数,当发现该参数后交_read_rc定位配置文件目录并读取该配置文件,在读取配置文件的同时由_parse_rc对文件进行格式处理,以便后续的数据统计,除“--rc”外的其他参数交由_merge_opt子函数处理,最终将准备阶段的处理结果传递给-main函数。

数据统计阶段的功能主要由_loop及_after_calc两个函数来实现。经过参数识别,程序在将在该阶段对原始日志中的特定位置的数值进行统计,包括计算出现次数、总和、中位数、平均数、最大值、最小值、方差、标准差及跨度。统计结果将传递给_finalize函数。如图3所示。

如图3所示,_loop及_after_calc函数各有其子函数,当程序调用时,这些子函数将分别计算出平均数、中位数、方差及标准差并将结果返回给主程序。

在结果显示阶段主要考虑统计数据是以CSV(Comma Separated Value)显示,还是采用TSV(Tab Separated Value)。这是通过参数识别阶段的“--tsv”及“--csv”来区别,由函数_view_delimited_line及_view_table来实现,各类统计数据独占一行显示,最终结果将为用户展现一个简单统计表,方便用户阅读。如图4所示。

2 程序实现

由于该日志统计系统的最初设计目的是为了解决Linux系统下/var/log目录中各类日志基本数据的简单统计问题,所以系统实现采用Perl语言[1],开发平台选择Padre。

参数校验阶段的程序实现如下:

数据统计阶段的程序实现如下:

结果显示阶段程序实现如下:

除上述3个主要程序外,还有更下一层的子程序,限于篇幅不在文中详述。由于Perl语言编程自身的特点,该系统中的一些变量继承了下列类:Class::Accessor::Lite(控制该类变量的访问和存储),Getopt::Long(处理命令行参数),IO::Interactive::Ting(输出格式的控制类),Pod::Usage(打印程序内嵌pod文档),Text::ASCIITable(打印表格控制类)。

3 应用举例

实现的日志统计系统代码只有406行,占用存储空间仅有12K,同时由于使用Perl编程,能够在目前常见Linux操作系统能够平台上运行,为服务器日志管理提供了一个可选的小工具。如下是一个应用举例截图,如图5所示。

4 结语

该工具为日志文档基本数据的统计提供了一种选择,而且体量轻,可移植性好,能够帮助服务器管理人员减轻一点工作量,但同样是由于程序简单,该工具能够实现的功能较弱,管理员只能通过命令行操作该工具,人机交互界面不友好。不过在此工具的基础上,未来还要根据工作实际逐步完善功能。

摘要：服务器日志的统计与分析是每个运维人员必备的技能,对于使用Linux操作系统的服务器,查看其各类系统日志往往是个费时费力的工作,虽然市场上有很多日志统计与分析系统可以解决此类问题,但是这些系统往往价格不菲,而且代码不开源。设计并实现了一个简单的日志统计工具,能够帮助运维人员对日志文件中的特定数据进行简单的统计,计算日志中指定位置数据的出现次数、平均数、最大值及最小值等基本的统计数据,方便运维人员及时了解日志文件的特征。

关键词：日志统计,Perl语言,Linux系统

参考文献

[1]Randal L.Schwartz,brian d foy,Tom Phoenix,Learning Perl[M].O'Reilly Media.1994.

日志统计篇2

搜索引擎的日志文件是由使用者的搜索行为产生的, 是对用户在终端行为的一种记录。通过对日志文件的分析可以获得很多有价值的数据, 可以对不同用户的个性进行更加全面的分析, 实现更加个性化的推荐方案。随着时间的推移, 网站的用户访问量快速增长, 搜索引擎产生的日志数据快速增长。传统的日志分析方式已经无法满足大数据量日志分析的需求, 使用大数据技术可以为日志分析设计一整套自动化流程包括从数据采集, 传输, 存储, 计算和查询, 这种方式可以使得数据的处理过程更加高效。

2 集群概述

本系统为了模拟真实线上搜索日志产生的情况, 使用脚本语言模拟连续生成的日志数据, 通过Flume集群进行实时的采集。Flume采集到数据之后, 使用Kafka集群对数据进行消费, 将数据先存入到HDFS文件系统中。搭建Hive集群使用HQL语句对数据进行过滤分析。使用Sqoop工具把Hive中的数据导入到My SQL提供实时查询。

目标日志是由搜狗实验室提供的用户查询日志。下面是访问日志中一条典型记录:

00:00:01 0014362172758659586[明星合成] 64 21 link.44box.com/

这行内容由6项构成:1) 访问时间。2) 用户ID。3) 查询词。4) 该URL在返回结果中的排名。5) 用户点击的顺序号。6) 用户点击的URL。其中, 用户ID是根据用户使用浏览器访问搜索引擎时的Cookie信息自动赋值, 即同一次使用浏览器输入的不同查询对应同一个用户ID。

3 系统的设计与实现

3.1 系统的基本目标

利用分布式的架构对模拟生产环境下实时产生的用户查询日志进行采集, 传输和存储, 按查询过滤条件对日志数据进行分析。

3.2 集群部署

3.2.1 Hadoop部署

图1介绍了Hadoop集群部署的架构, 包含一个主控节点namenode和两个从节点datanode。namenode主要职责是跟踪文件如何被分割成文件块、文件块又被哪些节点存储、以及分布式文件系统的整体运行状态是否正常等工作。Resource M⁃anager负责集群中所有资源的统一管理和分配, 它接收来自各个节点 (Node Manager) 的资源汇报信息, 并把这些信息按照一定的策略分配给各个应用程序。Secondary Namenode定时查询namenode节点中集群启动时对文件系统的改动序列, 并保持同步;然后将得到的信息更新到namenode节点文件系统快照文件中。Nodemanager管理Hadoop集群中单个计算节点, 包括与Resource Manager保持通信, 监督任务的生命周期管理, 监控每个任务的资源使用, 追踪节点健康状况, 管理日志和不同应用程序用到的附属服务。

3.2.2 Flume部署

Flume本身不限制Agent中Source、Channel和Sink的数量。因此Flume Source可以接收事件, 并可以通过配置将事件复制到多个目的地。如图2所示, 可以将事件发送到多个Kafka终端, 进行分布式的处理过程。

3.2.3 Kafka部署

图3介绍了Kafka集群部署的基本架构, Producer称为消息的发送者, 而消息接收者称为Consumer。Kafka集群由多个实例组成, 每个节点称为broker, 对消息保存时根据Topic进行归类, 为了加快读取速度, 多个comsumer划分为一个组, 并行消费一个topic。Kafka集群中通过Zookeeper管理集群配置, 选举leader, 以及在Consumer Group发生变化时进行rebalance。

3.3 日志数据的HDFS存储

图4展示了HDFS的工作原理。当用户查询日志进入集群时, HDFS Client负责切分文件, 与Name Node交互, 获取文件位置信息;与Data Node交互, 读取和写入数据。Name Node是m主节点, 管理HDFS的名称空间和数据块映射信息, 配置副本策略, 处理客户端请求。Datanode是从节点, 存储实际的数据, 汇报存储信息给Nmae Node。Secodary Name Node辅助Name Node分担其工作量;定期合并fsimage和fsedits, 推送给Name Node;紧急情况下, 可辅助恢复Name Node。

3.4 日志采集与传输

3.4.1 模拟产生日志

通过shell脚本模拟生产环境下日志产生过程, 实现原理是把已经存在的搜狗用户查询日志内容重定向到另一个文件中, 利用时间字符串定义初始文件的名字, 将日志按照一定的时间间隔进行传输。

3.4.2 文件到Kafka

文件传输到Kafka的过程使用Flume实现。Flume的配置文件中使用Spool Directory Source实现, 定义type为spooldir, 指定数据输入路径spool Dir, 实现文件输入。本文使用的搜狗用户查询日志采用GBK编码格式, 通过修改Spool Directory Source⁃Configuration Constants参数, 定义Input Charset配置项为GBK, 实现GBK编码格式的文件输入。Flume的source端输出使用Out⁃put Charset配置项定义文件输出格式。从Flumed的Source传输到Channel时, 为了使日志按时间格式显示文件名, 本文通过将文件名信息传递到Kafka由其依据名称生成目标目录的方式实现;利用Flume的event中的header传递文件名信息时, 定义键值目录结构为a/b/c;相关的配置项为file Header和file Header⁃Key;定义file Header Key的值为Key。最终实现带着目录结构的数据文件缓存到Kafka。

3.4.3 Kafka到hdfs

Kafka到hdfs数据的持久化, 本文通过自定义Kafka Con⁃sumer来实现。通过获取消息体中每条消息的Key, 获取日期字符串;然后将数据存入相应位置。文件传输完毕之后重命名为.Done结尾, 作为文件传输完毕的识别标志。定义输出流时开启独立的线程将内存中的数据刷写到hdfs, 减少数据的丢失实现数据在hdfs的固化。

3.4.4 Hdfs到Hive

hdfs数据传入到Hive。实现方法是定义输入文件路径和指定hive table两个参数, 取出输入目录下结尾是.Done的文件, 解析出时间参数加载到Hive。

3.5 日志分析系统流程

图5展示了整个日志分析系统流程。日志采集以及传输使用Flume+Kafka的方式。Flume设计思想是是数据的多样性、数据来源的多样性、数据流向的多样性;Kafka设计目标是高吞吐量、高负载 (topic下可以有多个partition) ;所以在日志分析系统使用Flume+Kafka架构可以使系统更加高效, 保证高性能。存储使用HDFS实现, 实现分布式存储目的;查询使用Hive中的HQL语句, HQL语句查询过程是以mapreduce的方式实现。Sqoop具有数据传递的功能, 利用Sqoop的特性将Hive中的数据导入My SQL实现SQL语句的实时查询。

4 结果分析

图6展示了数据在各个阶段的情况。下图分为六个部分, 第一部分展示了模拟实时产生172万条搜索日志数据进入系统的情况;第二部分展示了日志数据通过Flume收集进入Kafka;第三部分展示了Kafka开始消费日志数据, 并且将数据加载到hdfs;第四部分展示了数据从hdfs加载到Hive;第五部分展示了日志数据文件加载到hdfs之后存储的目录结构;第六部分展示了使用HQL语句完成查询的功能。整个系统启动之后172万条实时产生的日志数据的采集、传输、进入存储系统等过程自动开始运行, 对于大量数据的采集、传输、与存储进行了分布式高效的处理, 达到了本文研究的目的。

5 小结

大数据技术受到全世界开源社区的热烈支持, 发展的越来越成熟, 在未来的优势越来越明显。用大数据技术能很方便地在廉价机器上实现分布式数据处理架构, 多个系统之间可以很好地协同工作, 体现了系统协作与互联、经济性、性能和可伸缩性、容错性等很多方面的优点。以本文实例为基础可以进一步进行拓展, 对大数据任务进行更深入和详细的分析和探索, 为各个领域的大数据处理提供参考。

摘要：随着大数据时代的来临, 网络数据呈现爆炸式增长, IDC数据表明, 全球企业数据正以62%的速度逐年增长, 大量数据当中隐藏着巨大的商业价值, 引起了企业的广泛关注。然而, 大数据给数据的同步、存储、和数据统计分析带来了一定的问题和困难。本文旨在实现基于大数据技术的日志统计分析系统, 解决了现有的工具逐渐无法有效的处理大量数据的问题。本文在对此系统进行需求分析的基础上, 设计了以多个分布式集群为基础, 数据源层、存储层、计算层相互融合的体系结构, 设计并实现了日志数据转码、日志传输、自动识别新文件的产生、日志存储、数据查询的功能。日志数据转码对于GBK格式编码的日志进行格式转换;日志传输提供数据从不同终端到储存系统的数据收集、聚合和移动, 以便模拟生产环境中数据实时产生的过程;自动识别新文件的产生, 不同模块之间完成通信加载数据功能。本文综合使用了大数据生态圈的各种开源技术, 包括Hadoop、Flume NG、Kfaka、Sqoop、Hive、My SQL。从日志数据的收集同步, 到日志的存储和计算分析, 到最终分析结果的查询, 涵盖了使用大数据技术进行日志统计分析的典型流程。本文使用开发语言Java和shell脚本语言, 开发工具为Intelli J IDEA, VIM。在多台Cent OS6.5机器之上搭建集群, 进行分布式存储和计算。用户通过统计分析系统进行日志同步、传输、任务提交和调度、结果查询等操作。

关键词：大数据,网络数据,日志统计分析,流程自动化

参考文献

[1]陈森博, 陈张杰.基于Hadoop集群的日志分析系统的设计与实现[J].电脑知识与技术, 2013, 9 (34) :7647-7650.

[2]Tom White.Hadoop权威指南[M].北京:清华大学出版社, 2015.

[3]Hari Shreedharan.Flume构建高可用、可扩展的海量日志采集系统[M].北京:电子工业出版社, 2015.

[4]Edward Capriolo, Dean Wampler, Jason Rutherglen.Hive编程指南[M].北京:人民邮电出版社, 2013.

日志统计篇3

1 方案设计

ICU日志监测内容中的当日入院人数、患者总数两个指标在“军卫一号”信息系统中有相应的数据, 方便统计;但没有呼吸机使用人数、中心静脉导管留置人数、保留尿管人数等监测指标。要实现ICU日志监测自动统计功能, 应从医嘱信息中提取相关数据, 并建立医嘱与监测指标对照字典 (ORDER_VS_INDEX_DICT) 和ICU日志记录表 (ICU_DAY_RECORD) , 将统计生成的结果存储到ICU日志记录表中, 以备查看、统计和输出。

ICU监测指标日统计功能设计, 采用后台数据自动采集的形式, 从医院信息系统 (HIS) 数据库中提取入出转日志、医嘱、在院患者记录等诊疗信息, 并通过医嘱与监测项目进行对照, 提取ICU日志监测的相关指标, 具体程序流程, 见图1。

ORDER_VS_INDEX_DICT数据结构如下:

ICU日志记录表ICU_DAY_RECORD数据结构如下:

基于“军卫一号”系统的相关信息, 可采用下面的方法对ICU监测指标进行统计, 其中icucode表示ICU病区代码, startdate表示统计的开始时间, enddate表示统计的结束时间, 各指标的统计语句如下:

ICU新入患者人数, 从入出转日志表ADT_LOG中提取数据, 转入科室为ICU病区, 状态为新入 (“D”表示新入) 或他科转入 (“C”表示他科转入) 。

ICU在院患者人数, 直接从在院患者表PATS_IN_HOSPITAL中提取数据, 科室为ICU病区;呼吸机、留置尿管、中心静脉置管患者人数, 是指ICU病区在院患者进行了呼吸机或留置尿管或中心静脉置管相关治疗, 可从该病人已经执行的与呼吸机、留置尿管、中心静脉置管相关的或指定的长期医嘱中提取数据。

2 应用实现

2.1 维护对照字典

维护医嘱与监测指标对照字典ORDER_VS_INDEX_DICT数据, 根据执行呼吸机、留置尿管、中心静脉置管治疗的医嘱, 在表中插入医嘱类别、医嘱代码、医嘱名称, 同时设置好相应的指标类型和指标名称, “VENTILATOR”表示呼吸机指标, “CATHETER”表示留置尿管指标, “CENTRALVENOUS”表示中心静脉置管指标。

2.2 后台日统计程序

采用POWERBUILDER编程语言设计ICU监测指标后台日志统计软件, 实现了每天自动统计ICU各监测指标, 见图2。该软件可以设置文件中的统计时间、倒计时时间, 图2所示的统计时间为16:20, 进入倒计时还有6min;如遇到特殊情况也可以手工统计, 点击“手工预警”按钮后, 该按钮变灰, 出现“预警”按钮, 设置后, 点击“预警”按钮即可实现手工统计, 见图3。

2.3 ICU监测指标日志

同样采用POWERBUILDER编程语言设计并实现ICU监测指标日志输出软件, 实现了ICU监测指标日志的查询、打印功能, 见图4。同时也可将日志文件另存为TXT文本或EXCELL表格文件, 使ICU监测数据存储、查询、打印更方便、安全。

3 小结

基于“军卫一号”系统建立医嘱与监测指标对照关系, 设计并实现了ICU监测指标后台日统计及输出软件, 实现了ICU监测指标自动统计功能, 提高了ICU日志的准确性和完整性。不但方便ICU医护工作人员进行查询, 也省去了人工填写和统计ICU日志表的人力资源。

摘要：本文对“军卫一号”信息系统中的ICU日志监测指标统计内容进行了具体分析, 建立了医嘱与监测指标对照字典, 设计并实现了ICU监测指标后台自动日统计功能, 提高了ICU日志的准确性和完整性。

关键词：军卫一号,ICU,ICU监测指标

参考文献

[1]周萍, 朱同娥, 孙建玲.重症监护病房医院感染目标性监测分析及预防措施[J].中国中医急症, 2010, (4) :657-658.下转第137页

[2]孙玉蓉, 刘梅芳.电子特护记录单在ICU的应用与效果评价[J].中国医疗设备, 2011, 26 (8) :105-106.

[3]潘杰, 赵亚平.ICU医院感染目标性监测分析[J].中国医学创新, 2013, (31) :136-138.

[4]陈云飞, 张群, 殷瑾, 等.综合性医院ICU医院感染目标监测研究分析[J].中华医院感染学杂志, 2009, (9) :1083-1085.

[5]张为华, 易光兆, 袁喆, 等.综合性ICU医院感染的目标性监测分析[J].重庆医学, 2011, 40 (3) :3457-3459.