CN111177098A

CN111177098A - 查看系统日志上下文的方法及系统

Info

Publication number: CN111177098A
Application number: CN201911376364.9A
Authority: CN
Inventors: 周杰; 马楠
Original assignee: CITIC Aibank Corp Ltd
Current assignee: CITIC Aibank Corp Ltd
Priority date: 2019-12-27
Filing date: 2019-12-27
Publication date: 2020-05-19
Anticipated expiration: 2039-12-27
Also published as: CN111177098B

Abstract

本发明公开了一种查看系统日志上下文的方法及系统，特别是大规模集中采集日志搜索后查看上下文。该方法包括四个步骤：步骤一、用日志采集程序对日志进行大规模的日志数据集中采集，初始化FID，设定目标日志原始位置的FID的定位，生成FID自增序列。步骤二、数据接收端对日志数据进行接收、接收后将数据批量转发至kafka。步骤三、由分布式数据采集引擎对原始数据进行消费解析后，存储进ES中，由ES搜索引擎进行检索，用于定位目标日志的FID。步骤四、通过实现对目标日志原始位置的FID的定位，依据多个维度的条件，确定待查询日志的上下文关系，并查看该结果的上下文。

Description

查看系统日志上下文的方法及系统

技术领域

本发明涉及领域，特别是涉及一种计算机系统和应用日志监控/分析技术领域，特别涉及一种查看系统日志上下文的方法。

背景技术

日志通常是分布在多台物理机/虚拟机上的，开发与运维人员查看日志时，需要登陆机器，但此做法在分布式/微服务广泛应用的今天已不可取，往往技术人员需要登陆N多台机器后才能找到想要的日志。

在现有技术解决方案中，我们采用类似ELK架构的日志集中采集方案，此种方案能有效的提升技术人员查看、分析系统/业务日志的效率，掌握良好的搜索技巧，甚至可以做到快速报表统计等效果。

但是该种方案有一定的缺陷，主要体现在，当技术人员需要查看上下文关联日志时，就会遇到无法解决的问题，因为ES引擎无法判定哪些document是所搜索日志的上下文，ES的倒排索引和全文搜索技术，是为了快速检索和统计设计的，并没有如Mysql的自增ID技术。

目前现有的开源架构，日志采集时并不记录行号，在日志搜索时，可以通过关键字进行日志的定位，但是由于该条日志的上下文中并不包含可以定位的关键字，所以无法直接查询到上下文是什么。对于生产排障，尤其是连续性的业务日志，是非常不友好的。

目前的日志搜索无法查看所选日志条目的上下文。ES的Text索引搜索技术，主要采用了对document进行分词后索引，支持模糊/精准查询。

虽然producer生产数据到kafka时是有顺序保障的，但是由于kafka还需要将数据分散到不同的partition中，这就导致consumer在消费时，无法保障日志数据仍然是按照采集时的顺序进入到ES引擎中，且consumer是分布式可横向扩容的，所以无法通过维持内存中唯一ID，来为document实现自增ID。

基于以上技术特点，虽然我们可以快速查找想要的关键字所在的日志条目，但所选日志条目的上下文却不可见，而很多业务日志的上下文具备关联性，必须联动查看才能明确问题。

以上问题，会导致技术人员日志分析不准确，问题无法定位等隐患。

本申请涉及的主要名词解释：

source：日志document里记录的日志文件路径。

FID：日志document中记录的日志行号，是根据本发明方法在日志采集时生成。

timeFrom：日志搜索条件中的起始时间，为了兼顾选中日志条目的时间可能在范围的最早，且有可能遇到日期切换，需要向前偏移一分钟。

timeTill：日志搜索条件中的截止时间，为了兼顾选中日志条目的时间可能在范围的最晚，且有可能遇到日期切换，需要向后偏移一分钟。

Golang：是由google设计，为实现充分利用硬件性能，同时兼顾开发效率的一种新的开发语言，跨平台/天生高并发/支持垃圾回收，快速编译。

Appname：我行管理上，要求每个业务系统都具备三位系统编码，统一由运维管理中进行维护，在日志采集时，即定义该日志所属的业务系统。

Tag：我行管理上，要求每个业务系统根据部署单元不同，进行命名划分，在采集时通过appname+tag，即可以区分唯一的业务系统日志。

分词：简单来说，就是对入库的文本进行拆分，分隔成多个词组，每个词组可以作为一个搜索关键词，同时整个文本也是搜索关键词，保证了搜索的模糊匹配能力。

倒排索引：正常的索引是对document生成一个ID，如果知道ID，可以快速查找对应的document，但是这种索引方式无法应对用户查找某些特定词组都出现在哪些document中，这里就用到了倒排索引方式，将词组作为关键索引，ID作为对应内容，实现根据关键词的document查找与统计。

发明内容

本发明的目的在于提供一种查看系统日志上下文的方法,尤其解决的是大规模集中采集日志搜索后查看上下文的问题。该技术问题是在统一集中UI界面，即可做到日志的快速检索查询，通过点击查看上下文的简单操作，实现对上下文的检索，从而帮助用户快速定位查询结果。

而在目前现有的开源架构中，日志采集时并不记录行号，从而无法实现日志定位及查看上下文的问题。

本发明基于图1的逻辑示意图，基于开源产品Elasticsearch搜索引擎设计，从整体架构上，本发明参考ELK开源日志分析平台进行设计，但在采集接收端到ES引擎中增加了kafka组件，由于kafka具备的高性能I/O吞吐，确保数据消费能完整的进入ES，且提供了缓冲功能。

发明人应用golang语言进行开发。基于ES搜索引擎设计检索功能，搜索前端采用vue.js开发，搜索后端web采用python开发。

本发明的关键点在于，在日志采集时，即赋予了FID(“行号”)的属性，在入库后依据多个维度的条件，即可唯一确定待查询日志的上下文关系。

本发明所取得的技术效果为，可通过IP/source/FID/timeFrom/timeTill共5个字段，能唯一确定所选日志条目的顺序上下文，然后通过定制UI界面返回展示。同时，用户无需关心后台的处理过程，只要在界面选中日志，点击查看上下文即可。

后端存储和搜索用到了开源的Elasticsearch，本方案的数据流是，客户端采集数据并预处理，将数据批量上送至接收端；将数据批量转发至Kafka，然后进行消费解析，消费解析后转储于ES之中，由ES搜索引擎进行检索；通过实现对检索结果的定位，唯一确定待查询日志的上下文关系，实现查看该结果的上下文。

基于图1的逻辑示意图，本发明技术方案的实现方式：

步骤1，通过用日志采集程序采集日志，采集程序在采集时设定appname与tag，用以区分所采集的日志的业务系统归属，采集时还会将IP信息、Hostname数据、source数据上送至数据接收端。通过初始化FID，生成FID自增序列。

步骤2，数据接收端对数据进行接收、转发。所述接收是指，将采集到的、并预处理过的数据，批量上送到数据接收端，接收端接收数据；数据接收端基于http接口接收数据，将数据批量转发至kafka进行缓冲。

步骤3，通过golang开发的分布式数据采集引擎进行数据解析，从kafka中消费数据并按照既定规则解析出对应的字段；消费解析后，转储于ES搜索引擎之中，由ES搜索引擎进行检索，用于定位目标日志原始位置的FID。

步骤4，通过实现对搜索结果的定位，确定待查询日志的上下文关系，并查看该结果的上下文。

可选的或优选的，大规模集中采集日志搜索后查看上下文的方法，步骤四中所述查看上下文，将查看条数，设置为50条；

当FID达到2^31-1的上限后，重新置为0进行轮转，我们的默认上下文查看是选择50条日志，所以web-server组合的查询条件中，当所选日志在边界范围时，会自动进行FID转换，确保查询的日志在上下文50条范围内。

优选的，权利要求1所述的大规模集中采集日志搜索后查看上下文的方法，其特征在于，发起日志采集时，在内存中开辟一个uint32类型的整数进行维护。

可选的，可进一步扩大设置查看上下文条目数量，区间范围为大于50条小于10000条。

优选的，权利要求1所述的大规模集中采集日志搜索后查看上下文的方法，其特征在于，所述权利要求1的检索引擎Elasticsearch。

优选的，权利要求1所述的大规模集中采集日志搜索后查看上下文的方法，其特征在于，所述权利要求1的分布式发布订阅消息系统为Kafka。

一种查看系统日志上下文的系统，其特征在于，包括日志采集单元、日志接收单元、数据缓冲单元、日志解析单元、数据存储单元、日志检索单元；

所述日志采集单元，用于大规模集中采用日志文件信息，将所采集到的日志存储到数据存储单元进行存储；

所述数据接收单元，用于对日志采集单元采集到的日志数据进行接收；

所述日志缓冲单元，用于接收所述日志采集单元发送的日志文件，并将所接收的日志文件信息添加至分布式消息队列中；

所述数据解析单元，从上述分布式消息队列中消费数据并按照既定规则解析出对应的字段；消费解析后，转储于数据存储单元之中，由搜索引擎检索定位目标日志；

所述数据存储单元，用于存储消费解析后的数据；

所述日志检索单元，根据用户的日志查询条件，定位目标日志原始位置的FID，检索得到对应的检索目标日志文件。

该查看系统日志上下文的系统可以存储于计算机可读存储介质中，所属存储介质包括：ROM、RAM、磁盘或光盘等。该日志所适用于的归档分析平台为Storm分布式日志分析平台。

附图说明

图1是本发明方法实施例的逻辑示意图；

图2是本发明方法实施例提供的一种日志采集生成FID示意图；

图3是本发明方法日志搜索时查看上下文流程示意图；

图4是本发明系统实施例的组成系统示意图；

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图2、图3对本发明实施方式作进一步地详细描述。显然，所描述的实施例实际上仅仅是说明性的或者示例性的，决不作为对本发明及其应用或使用的任何限制。在下面的详细描述中，提出了许多具体细节，以便提供对本发明的全面理解。但是，对于本领域技术人员来说很明显的是，本发明可以在不需要这些具体细节中的全部细节均已了解的情况下实施。下面对实施例的描述仅仅是为了通过展示本发明的示例来提供对本发明的更好的理解。本发明决不限于下面所提出的任何具体配置和算法，而是在不脱离本发明的精神的前提下覆盖了元素、部件和算法的任何修改、替换和改进。

下面结合具体实施例对本发明做进一步详细的描述，但本发明的实施方式不限于此。

具体地实施例

提供的一种查看系统日志上下文的方法，如图2、图3所示，按照下列技术方案展开：

步骤S101，日志采集程序读取配置文件，根据配置信息确定需要采集的日志。日志采集程序再将配置信息转化成其所需的数据，注册到全局变量。注册后，日志采集程序根据全局变量，分配足够的线程进行日志采集。

对日志进行大规模集中采集，采集线程首先分配初始化FID和seek，采集线程首先分配初始化seek和FID，读取文件路径和文件名，以及iNode信息。

设定目标日志的FID定位，生成FID自增序列。FID的具体生成规则见下方详述。

FID的生成规则具体为：

1.发起日志采集时，在内存中开辟一个uint32类型的整数(大小为2^32-1)进行维护，选择uint32类型，是考虑到：

首先，最终存储在Elasticsearch中的类型实现，在Elasticsearch中选择integer类型，大小为2^31-1(int32类型，在正整数范围已经被uint32包含)；

数值类型也可以选择uint64，提供更大的数值范围，但对于日志行数，uint32已经够用，设置更大的存储类型，会消耗更多的存储空间。

其次，在不同的语言实现的web-server中，以及不同的操作系统中，对int型的长度支持兼容性；

再有，由于单个日志的大小通常是有限的，2^31-1行，已经可以包含很久的日志了，重复性很低，不用浪费更多的存储空间去存更大的FID。

2.当FID达到2^31-1的上限后，重新置为0进行轮转，我们的默认上下文查看是选择50条日志，所以web-server组合的查询条件中，当所选日志在边界范围时，会自动进行FID转换，确保查询的日志在上下文50条范围内。

3.日志采集程序为每一个采集日志分配单独的采集线程，在线程中维护FID的自增长，线程安全的FID变量，可以保证不会出现FID冲突问题；同时将采集时的日志seek位置、FID信息注册到全局变量，由定时线程将数据刷入到磁盘，防止程序意外退出导致采集进度丢失。

采集程序在采集时设定appname与tag，用以区分所采集的日志的业务系统归属。

根据图2，判断iNode是否与记录的iNode相等；如果相等，读取记录的seek信息；如果不相等，seek初始化为0；循环过程读取一行日志Seek++，FID++；将FID与2147483647比较；

如果小于等于，则FID保持不变，如果大于FID初始化为0。

document是描述数据在ES中存储的结构，可以理解为每条日志数据，包含其所有属性字段的值组成了一个document，

采集时，除了将日志、seek、FID等信息组成document，还会将IP信息、Hostname数据、source数据上送至数据接收端document文件，消费后入库ES。然后插入到channel中，从channel中读取数据，累积到足够的数量后，或距离上次提交超过N秒后，批量提交到统一上送接口。

步骤S102，数据接收端对日志数据进行接收、接收后将数据批量转发至kafka。

具体地，业务人员的数据端对数据所进行接收、转发工作。其中，接收指的是，将采集到的，并预处理过的数据，批量上送到数据接收端，接收端接收数据；接收端基于http接口接收数据，数据接收端将数据批量转发至kafka。

kafka提供了更好的缓存机制，后端的数据解析及入库ES可以变成异步的方式，这样提高了数据处理的吞吐量。由于数据解析是非常消耗CPU资源的，而ES入库则消耗CPU和磁盘I/O，且I/O效率不及kafka。同时由于将数据接收与数据解析消费进行解耦，可以对解析模块进行单独的扩容，因为接收模块并不需要太多的资源，只需要进行校验转发即可。

在采集接收端到ES引擎中增加了kafka组件，kafka可做高性能I/O吞吐，确保数据消费能完整的进入ES，且提供了缓冲功能。

步骤S103，通过golang开发的分布式数据采集引擎进行数据解析，从kafka中消费数据并按照既定规则解析出对应的字段；消费解析后，转储于ES之中，由ES搜索引擎进行检索，用于定位目标日志原始位置的FID。

步骤S104，通过实现对目标日志的FID定位，依据多个维度的条件，确定待查询日志的上下文关系，并查看该结果的上下文。

所述多个维度，包括但不限于：时间范围[@timestamp]+IP+日志文件绝对路径[source]+日志行号[FID]，最终在搜索引擎中执行的搜索条件为，@timestamp gte:${timeFrom},lte:${timeTill}，IP:${IP}_AND source:${source}AND FID:>${FID}-25ANDFID:<${FID}+25，查询的结果集按照FID进行排序。

查看上下文条数可以设定，当前环境设定默认为50条，但这个可以优化为通过前端选定，即数量不作限制，但最多不超过10000条，10000条为ES集群默认的查询返回最大结果集，该最大值需要修改ES配置文件并重启集群方可实现修改。

从用户操作的角度对该技术方案进行解释，如图3所示，用户以timeFrom和timeTill选定时间范围，并输入搜索语句，后端会解析成ES搜索需要的Lucene语法，从而查找日志，当用户看到定位的感兴趣的日志后，在该条日志上选择“查看上下文”，该条日志的基本属性中包含IP信息，IP信息用于定位唯一主机、source用于定位唯一日志文件，FID用于定位该条日志的原始位置，程序会自动组合一条新的搜索语句，用于查询ES获取上下文，所应用的查询语句为：

IP:${IP}AND source:${source}AND FID:>${FID}-25AND FID:<${FID}+25，查询的结果集使用FID排序，即可完成上下文查询。

本发明应用在生产与测试环境的日志采集agent中，上送的报文信息请参见说明书附录。

本发明，解决了大规模日志采集、集中存储后，所遇到的只能搜索，不能上下文关联查询的问题，提升了技术人员在故障处理前的问题定位能力和定位效率，为生产环境稳定运行、快速处置提供了基础保障。

本发明还设计一种查看系统日志上下文的系统20，在本发明系统的实施例中，日志采集单元读取配置文件，根据配置信息确定需要采集的日志，初始化FID，设定目标日志原始位置的FID的定位，生成FID自增序列。

将日志文件采集单元201采集到的日志文件发送到日志接收单元202，日志接收单元202接收所述日志采集单元201发送的日志文件后，数据接收单元将所接收的日志文件信息添加至数据缓冲单元203，在分布式消息队列中进行缓冲；

获取用于定位目标日志的FID的日志文件，按照预设的分析策略对所获取的日志文件进行分析，得到对应的日志分析结果。由数据解析单元204的分布式数据采集引擎对原始数据进行消费解析后，将解析后的数据存储进数据存储单元205中，以备后续用户的查询需求。

当用户需要查看上下文时，日志检索单元206接收用户的日志查询请求后，从所述日志查询请求中解析得到对应的日志查询条件，基于所得到的日志查询条件，以及用户选择的查看上下文条目范围，由日志检索单元206进行检索，定位目标日志原始位置的FID，得到对应的日志文件并将目标日志的上下文输出显示给所述用户。

该系统可以存储于计算机可读存储介质中，所属存储介质包括：ROM、RAM、磁盘或光盘等。该日志所适用于的归档分析平台为Storm分布式日志分析平台。包括日志采集单元、日志缓冲单元、日志存储单元和日志查询单元。

除非另作定义，此处使用的技术术语或者科学术语应当为本发明所属领域内具有一般技能的人士所理解的通常意义。本发明专利发明说明书以及权利要求书中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。同样，“一个”或者“一”等类似词语也不表示数量限制，而是表示存在至少一个。

以上所述仅为本发明的示例实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

说明书附录：

{"recv_timestamp":1566810054606,"log_id":"AWsgWD2vQcDD_c1GxIpc","raw_message":"[2019/08/26 17:00:54CST][INFO](rpc.StateHttpServerResponse:212)SG_10003HttpResponse:sg:172.20.101.131:8881,provider:184002100,service:ifiCoreApi,version:20180509,method:apply,src:174001100,transfer-encoding:chunked,date:Mon,26Aug 2019 17:00:54GMT,msoa.requestid:1619415,msoa.traceid:4f87c2e3a3fb4a05accaf656f4dfe8f0,msoa.parentid:45ee60557764b28,msoa.spanid_v2:606a09ad0409620f,msoa.response.timestamp.ss:1566810054454,msoa.request.timestamp.cs:1566810053819,msoa.spanid:20497,msoa.response.timestamp.sr:1566810053804,msoa.userid:-1,content-type:application/json,server:SG,common_response:{"values":{"OUT_BOUND_SERVER":"AQY_001","INNER_TRANS_CODE":"GYL-WY_WMT0010012","transId":"190826bzifi1742302669097103397463","sourceBranchNo":"200001","_STEP_RETURN":0,"FROM_SYSTEM_ID":"WMT_001","Tx_CD":"WMT0010012","MESSAGE_ID_IN":"ac1464490000201908261700954387","sourceServerId":"bzaqyjserap1001","_STEP_NUM":1,"TRANS_CODE":"WMT0010012","TRANS_SERIAL":"190826bzIQYQYJ2321336021404395519","PREV_TRANS_CODE":"","_WORKFLOW_SATE":"2","wsId":"QYJ","branchId":"800001","priority":1,"_BODY_LEN":602,"version":"1.0.0","RSP_ENTRY":{"App_Id":"AQY_001","Format":"JSON","App_Auth_Token":"token580353628005906972","Charset":"utf-8","Sign":"lDePdO68M+5LJyu59qZIh2Jvqrm+j9l9/cFl/mpTtGLvhw73YuWJVuZ88JoJ1QojjhS7/oRaK/5oAoMNSa+7movv8GkIoWfMf7b3uN4WIsJOEU7Y/TKBlXrp2pTdMkU57Ik3rkPftFJBJhOJ9aOetq1Eq2edsCWDfpcA1MVpocQ＝","Tx_CD":"WMT0010012","Tx_Dt":"20190826050053815","TxnSrlNo":"190826bzIQYQYJ2321336021404395519","To_SysTem_ID":"CAC_001","returnCode":"CARD00033","returnMsg":"失败"},"destBranchNo":"","MSG_CHARSET":"UTF-8","PROCESS_INF\n400\nO":"交易成功。

","sourceType":"9999","_SERVER_TYPE":"http","sysDate":"20190826","subTransSeq":"11000000000000000000","_STEP_STATE":"2","REQUEST_ID":"WMT_001","_HIRER_CODE_KEY":null,"result":"1","_WORKFLOW_NAME":"TRANSMIT_FLOW","REQ_ENTRY":{"sysDate":"20190826","wsId":"QYJ","branchId":"800001","subTransSeq":"11000000000000000000","transId":"190826bzIQYQYJ2321336021404395519","sourceBranchNo":"200001","priority":1,"userId":"ifm00001","version":"V1","destBranchNo":"","async":false,"sourceServerId":"bzaqyjserap1001","sourceType":"9999","sourceServiceId":"AQY_001","sysTimestamp":"20190826170053821","customerId":"WMT_001","Tx_CD":"WMT0010012","To_SysTem_ID":"AQY_001","tradeSeqNo":"180426P00008A0011ab490880","retMessage":"成功","remark":"11890","sourceAppId":"P00044A001","tradeDate":"20220402","acctName":"**","checkDate":"20220402","retCode":"00000000","sourcePlatformId":"P00044","tradeAmount":1.0,"tradeTime":"141002","acctNo":"10000000********000001","tradeStatus":"1","messageCode":"PROFIT02"},"TRANS_DAT\n202\nE":"20190826","sourceServiceId":"AQY_001","sysTimestamp":"20190826170053821","customerId":"WMT_001","_STEP_NAME":"outBound1","To_SysTem_ID":"AQY_001","MESSAGE_ID_OUT":"ac14644900002019082617009543871","_REQ_URI":"/WMT_001","TO_SYSTEM_ID":"AQY_001","requestType":"qz","TRANS_SEGMENT_1":1566810053818,"userId":"ifm00001","PREV_TRANS_STANDARD":"","_FILTER_CHAIN":"outWithSignFiters","async":false,"PROCESS_CODE":"000000","MSG_FMT":"JSON","OUT_MAP_ID":895,"TRANS_TIME":"170053"},"id":"ac1464490000201908261700954387"}\n0","ip":"172.20.101.131","source_update_timestamp":1566810054526,"source":"/var/log/fsg/service-gateway/logs/sg.log","hostname":"bzafsg001gw1003","appname":"fsg","domain":"ops","FID":268435455,"tag":"sg","timestamp":1559615781000}

在用户界面输入搜索条件：

"msoa.traceid:4f87c2e3a3fb4a05accaf656f4dfe8f0"AND"msoa.requestid:1619415"

得到明确的日志返回结果，然后点击查看上下文，最终实现上下文的查看目的。

Claims

1.一种查看系统日志上下文的方法及系统，其特征在于，包括：

步骤一、通过日志采集程序对日志数据进行采集，日志采集程序生成FID自增序列，将数据批量上送至数据接收端。

步骤二、数据接收端对步骤一采集的日志数据进行接收，数据接收端将数据批量转发至分布式消息队列中进行缓冲；

步骤三、由分布式数据采集引擎对原始数据进行消费解析后，将解析后的数据存储进搜索引擎中，由搜索引擎进行检索，用于定位目标日志的FID。

步骤四、通过实现对目标日志的FID的定位，确定所述目标日志的上下文，从而实现对上下文的查看。

2.根据权利要求1所述的查看系统日志上下文的方法，其特征在于，步骤四中所述查看上下文，将查看条数，设置为50条；

3.根据权利要求2所述的查看系统日志上下文的方法，其特征在于，可将查看条数，设置为大于50条小于10000条。

4.根据权利要求1所述的查看系统日志上下文的方法，其特征在于，发起日志采集时，在内存中开辟一个uint32类型的整数进行维护。

5.根据权利要求1所述的查看系统日志上下文的方法，其特征在于，所述权利要求1的检索引擎Elasticsearch。

6.根据权利要求1所述的查看系统日志上下文的方法，其特征在于，所述权利要求1的分布式消息队列为Kafka。

7.一种查看系统日志上下文的系统，其特征在于，包括日志文件采集单元、日志接收单元、数据缓冲单元、数据解析单元、数据存储单元、日志检索单元；

所述数据解析单元，从上述分布式消息队列中消费数据并按照既定规则解析出对应的字段；消费解析后，转储于数据存储单元之中，由搜索引擎检索定位目标日志。

所述数据存储单元，用于存储消费解析后的数据；

8.权利要求7所述的查看系统日志上下文的系统，其特征在于，所述系统可以存储于计算机可读存储介质中，所属存储介质包括：ROM、RAM、硬盘设备。

9.根据权利要求7所述的查看系统日志上下文的系统，其特征在于，该系统应用于日志归档分析平台为Storm分布式日志分析平台。