CN106777371B - 日志收集系统和方法 - Google Patents
日志收集系统和方法 Download PDFInfo
- Publication number
- CN106777371B CN106777371B CN201710058570.XA CN201710058570A CN106777371B CN 106777371 B CN106777371 B CN 106777371B CN 201710058570 A CN201710058570 A CN 201710058570A CN 106777371 B CN106777371 B CN 106777371B
- Authority
- CN
- China
- Prior art keywords
- log
- server
- available
- log data
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 62
- 238000012544 monitoring process Methods 0.000 claims abstract description 47
- 230000008569 process Effects 0.000 claims description 16
- 238000012790 confirmation Methods 0.000 claims description 3
- 238000010586 diagram Methods 0.000 description 11
- 230000006870 function Effects 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 239000003795 chemical substances by application Substances 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000004931 aggregating effect Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000005065 mining Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/172—Caching, prefetching or hoarding of files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
- G06F16/1815—Journaling file systems
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明公开了一种日志收集系统，该系统包括：一个或多个第一服务器，一个或多个第二服务器以及监控服务器。其中，监控服务器用于实时获取各第二服务器的运行状态，并生成可用的第二服务器列表。第一服务器基于客户端发起的HTTP请求生成格式化的日志数据，监听可用的第二服务器列表，并将格式化的日志数据发送至可用的第二服务器。第二服务器接收到日志数据后，根据其所属的日志类型将其本地化存储于相应的日志文件中。本发明还公开了适于在上述日志收集系统中执行的日志收集方法。
Description
技术领域
本发明涉及数据采集技术领域，尤其涉及一种日志收集系统和方法。
背景技术
用户对互联网的访问实际上就是对某台服务器的访问，即向服务器发起HTTP请求。当服务器被访问时，会在本地生成用户访问日志。对日志数据进行分析和挖掘可以为行业/企业带来巨大的价值。
随着互联网技术的发展和终端设备的普及，用户对服务器的访问量增大，相应地，服务器端生成的用户访问日志的数据体量也越来越大。面对海量的日志数据，简单的日志本地化采集和处理已无法满足需求，因此，需要提供一种分布式的日志收集系统。
目前比较常用的分布式日志收集系统为Flume日志收集框架。Flume以Agent为最小的独立运行单位。一个Agent由Source、Channel和Sink三大组件构成。Flume的数据流由Event(事件)贯穿始终。Event是Flume的基本数据单位，它携带日志数据(字节数组形式)并且携带有header(头信息)。尽管Flume是一种高可用的分布式海量日志采集、聚合和传输的系统，但是，其在日志的分类整理和流量统计监控的实现上很不方便。例如，用Flume实现日志的分类整理时，需要由技术人员自行实现interceptor(拦截器)接口，对请求进行拦截，区分不同的日志类型，然后给每个Event添加header。此外，还需要对Channel和Sink进行配置，当日志种类很多的时候，配置很麻烦。
发明内容
为此，本发明提供一种日志收集系统和方法，以解决或至少缓解上面存在的问题。
根据本发明的一个方面，提供一种日志收集系统，该系统包括：一个或多个第一服务器，每一个第一服务器中均存储有多个配置文件，所述配置文件适于指定每种日志类型所对应的请求路径和日志数据格式，每一个第一服务器均包括：日志生成单元，适于从客户端发起的HTTP请求中解析出请求路径，根据请求路径确定日志类型，根据该日志类型所对应的配置文件中所指定的日志数据格式将所述HTTP请求生成日志数据；第一输出单元，适于将日志数据发送至第二服务器；一个或多个第二服务器，每一个第二服务器均包括：本地化存储单元，适于接收第一服务器发送的日志数据，并根据日志数据所属的日志类型将接收到的日志数据存储于第二服务器的相应日志文件中；监控服务器，适于获取第二服务器的运行状态，生成可用的第二服务器列表；其中，第一输出单元中还包括：监听模块，适于监听所述可用的第二服务器列表，所述第一输出单元适于根据所述可用的第二服务器列表向可用的第二服务器发送日志数据。
可选地，在根据本发明的日志收集系统中，监控服务器进一步适于：每隔第一时间向每一个第二服务器发送确认信息；若在第二时间内接收到第二服务器的反馈信息，则将该第二服务器判定为可用的第二服务器，加入可用的第二服务器列表。
可选地，在根据本发明的日志收集系统中，可用的第二服务器列表包括一条或多条可用的第二服务器记录，每条可用的第二服务器记录包括IP地址和端口号信息。
可选地，在根据本发明的日志收集系统中，第一输出单元还适于：在可用的第二服务器的数量小于第一阈值时，将所述日志数据存储于第一服务器；在可用的第二服务器的数量大于等于第一阈值时，将第一服务器中已存储的日志数据和日志生成单元在当前时刻生成的日志数据发送至可用的第二服务器。
可选地，在根据本发明的日志收集系统中，第一输出单元还适于：在可用的第二服务器的数量大于等于第一阈值时，以轮询的方式从多个可用的第二服务器中确定一个第二服务器，并将日志数据发送至确定的所述第二服务器。
可选地，在根据本发明的日志收集系统中，第二服务器中还包括第二输出单元，适于读取第二服务器中存储的日志文件，将所述日志文件中的日志数据发送至数据应用端。
可选地，在根据本发明的日志收集系统中，第二输出单元进一步适于：将待发送的日志类型添加至队列中，其中，每个日志类型包括一个或多个日志文件；创建多个线程；对于每一个线程：从队头取出一个日志类型；读取该日志类型所对应的日志文件中的日志数据并将其发送至数据应用端；将该日志类型放回队尾。
可选地，在根据本发明的日志收集系统中，数据应用端包括：Hadoop集群、Kafka集群、UDP服务器中的一种或多种。
可选地，在根据本发明的日志收集系统中，日志生成单元、第一输出单元、本地化存储单元、第二输出单元中均包括监控模块，适于监控每一种日志类型的日志数据的流量情况。
根据本发明的一个方面，提供一种日志收集方法，该方法适于在日志收集系统中执行，日志收集系统包括一个或多个第一服务器、一个或多个第二服务器以及监控服务器，其中，每一个第一服务器中均存储有多个配置文件，所述配置文件适于指定每种日志类型所对应的请求路径和日志数据格式，该方法包括：监控服务器获取第二服务器的运行状态，生成可用的第二服务器列表；第一服务器从客户端发起的HTTP请求中解析出请求路径，根据请求路径确定日志类型，根据该日志类型所对应的配置文件中所指定的日志数据格式将所述HTTP请求生成日志数据；第一服务器监听所述可用的第二服务器列表，将所述日志数据发送至可用的第二服务器；第二服务器接收到第一服务器发送的日志数据后，根据日志数据所属的日志类型将接收到的日志数据存储于第二服务器的相应日志文件中。
根据本发明的技术方案，根据HTTP请求中的请求路径来确定日志类型，为每种日志类型指定相应的日志数据格式，这样，仅需要简单地设置几个配置文件就可以实现基于HTTP请求的日志数据的分类格式化采集，方便高效。在将已分类的日志数据发送至第二服务器后，根据日志数据的类型将该日志数据存储于相应的日志文件中，即，实现了日志数据的分类存储。另外，第一服务器、第二服务器中均部署有监控模块，可以监控每一种日志类型的日志数据的流量情况，从而能够及时地发现问题。
另外，本发明的日志收集系统中包括可以监控第二服务器运行状态的监控服务器；第一服务器中包括监听模块，可以从监控服务器处获取可用的第二服务器列表，将数据发送至可用的第二服务器，从而防止了因第二服务器不可用而造成的数据丢失。更进一步地，根据可用的第二服务器列表中包括的可用的第二服务器的数量来选择启用主通道或备通道。当可用的第二服务器较多时(数量大于等于第一阈值时)，第二服务器的状态良好，启用主通道，将日志数据发送至可用的第二服务器；当可用的第二服务器较少时(数量小于第一阈值时)，第二服务器很可能出现问题，这时暂时将日志数据存储于第一服务器本地，当可用的第二服务器的数量恢复正常时，再启用主通道，将第一服务器本地暂存的日志数据和当前时刻生成的日志数据发送至可用的第二服务器，从而进一步保证了数据传输的可靠性。
另外，在第二服务器向数据应用端发送日志数据时，采用了一个全局的阻塞队列来控制并发，使得同一时间同一个日志类型只能被一个线程占用，避免了同时读取一个日志类型文件所带来的数据混乱和数据安全问题。
附图说明
为了实现上述以及相关目的，本文结合下面的描述和附图来描述某些说明性方面，这些方面指示了可以实践本文所公开的原理的各种方式，并且所有方面及其等效方面旨在落入所要求保护的主题的范围内。通过结合附图阅读下面的详细描述，本公开的上述以及其它目的、特征和优势将变得更加明显。遍及本公开，相同的附图标记通常指代相同的部件或元素。
图1示出了根据本发明一个实施例的日志收集系统100的示意图；
图2示出了根据本发明另一个实施例的日志收集系统100的示意图；
图3示出了根据本发明一个实施例的多线程处理日志数据的示意图；
图4A、4B示出了根据本发明的日志数据流量的监控结果的示意图；
图5示出了根据本发明一个实施例的日志收集方法500的流程图；以及
图6示出了根据本发明一个实施例的日志收集方法600的流程图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
图1示出了根据本发明一个实施例的日志收集系统100的示意图。图1所示的日志收集系统100包括五个第一服务器200(构成第一服务器集群)、四个第二服务器300(构成第二服务器集群)以及一个监控服务器400。应当指出，图1所示的日志收集系统100仅用于示例性地说明本发明的技术方案，在具体的实践情况中，日志收集系统中可以包括其他数量的第一服务器、第二服务器和监控服务器，本发明对日志收集系统100中所包括的第一服务器、第二服务器和监控服务器的数量不做限制。另外，第一服务器、第二服务器、监控服务器可以根据实际情况部署于任意位置，本发明对三者的部署情况亦不做限制。
第一服务器200为能够接收客户端发起的HTTP(HyperText Transfer Protocol，超文本传输协议)请求，并向客户端返回其所请求的内容的服务器，例如HTTP服务器、WEB服务器、应用服务器等，但不限于此。第二服务器300为能够提供存储服务的服务器，例如文件服务器、数据库服务器等，但不限于此。监控服务器400为能够提供监控服务的服务器，例如WEB服务器、应用服务器等，但不限于此。
在本发明中，监控服务器400用于实时获取各第二服务器300的运行状态，并生成可用的第二服务器列表。第一服务器200基于客户端发起的HTTP请求生成分类格式化的日志数据，监听可用的第二服务器列表，并将生成的日志数据发送至可用的第二服务器300。第二服务器300接收到日志数据后，根据其所属的日志类型将其本地化存储于相应的日志文件中。以下将对系统100中各部分的功能和处理逻辑进行详细描述。
监控服务器400可以获取第二服务器300的运行状态，并生成可用的第二服务器列表，从而避免了因为第二服务器300不可用而导致数据丢失的情况。根据一种实施例，监控服务器400每隔第一时间向每一个第二服务器发送确认信息。若在第二时间内接收到第二服务器的反馈信息，则将该第二服务器判定为可用的第二服务器，加入可用的第二服务器列表；若在第二时间内未接收到第二服务器的反馈信息，则将该第二服务器判定为不可用。根据一种实施例，每一个可用的第二服务器在可用的第二服务器列表中体现为一条可用的第二服务器记录，每条可用的第二服务器记录包括该可用的第二服务器的IP地址和端口号信息。一般来说，为了实现对第二服务器运行状态的实时监控，第一时间和第二时间均设置为一个较小的数值。
监控服务器400获取第二服务器300的运行状态的一种可能的实现方式是，在每一个第二服务器300中均配置有ZooKeeper程序(ZooKeeper是一种能够实现集群管理功能的分布式应用程序协调服务)，相应地，每个第二服务器300均是ZooKeeper的注册服务器。监控服务器400是能够提供ZooKeeper服务的服务器。基于ZooKeeper，监控服务器400可以实时获取第二服务器300的运行状态。监控服务器400以“心跳”的方式获取各第二服务器的运行情况，即周期性地向第二服务器发送“心跳包”，若在预设的超时时间内接收到第二服务器对于“心跳包”的响应，则认为该第二服务器在线，处于可用状态，在第二服务器对于“心跳包”的响应中包括其自身的IP地址和端口号。若在预设的超时时间内未接收到第二服务器对于“心跳包”的响应，则表明该第二服务器离线，处于不可用状态。
如图1所示，第一服务器200包括日志生成单元210和第一输出单元220，其中，第一输出单元220包括监听模块222。另外，为了实现日志的分类，第一服务器200中存储有多个配置文件，每个配置文件用于定义一个日志类型，并指定该日志类型所对应的请求路径和日志数据格式。根据一种实施例，配置文件可以是以下形式：
<logger catlog＝"mall_augf_click_count"delimer＝"\\t">
<description>web_mall_augf_click_count</description>
<category>web_mall_augf_click_count</category>
<msg>
{const('20160614')；
onlyid()；
param('ahpplid')；
param('ahpsign')；
now()；
autoip()；
visittype()；
cuid()；
reguserid()；
useragent()；
param('cur')；
param('ref')；
param('site')；
param('category')；
param('subcategory')；
param('target')；
}</msg>
<agent name＝"udp"/>
</logger>
其中，第一行代码用于指定请求路径，第二行代码是对本日志种类的描述，第三行代码用于指定日志种类，其余的代码用户设置日志数据格式。另外，应当指出，配置文件中只是定义了日志数据格式，并不能将HTTP请求解析成设定格式的日志数据。本领域技术人员应当知道，为了将HTTP请求处理成配置文件中预设格式的日志数据，还需要设置对应的方法。当然，上述配置文件仅是一个示例，本领域技术人员可以根据实际情况自行设置配置文件，本发明对第一服务器200中存储的配置文件的具体内容不做限制。
第一服务器200可以接收客户端发起的HTTP请求，日志生成单元210从HTTP请求中解析出请求路径，根据请求路径确定日志类型，根据该日志类型所对应的配置文件中所指定的日志数据格式，调用相应的方法，将该HTTP请求解析成日志数据。
监听模块222可以监听监控服务器400处的可用的第二服务器列表，由第一输出单元220根据该列表向可用的第二服务器发送日志数据。根据一种实施例，当列表中可用的第二服务器的数量小于第一阈值时，将日志数据存储于第一服务器本地；当可用的第二服务器的数量大于等于第一阈值时，将第一服务器本地已存储的日志数据和日志生成单元210在当前时刻生成的日志数据发送至可用的第二服务器。该方案相当于，第一输出单元220在发送日志数据时，有主通道、备通道两个路径。当可用的第二服务器较多时(数量大于等于第一阈值时)，第二服务器的状态良好，启用主通道，将日志数据发送至可用的第二服务器。当可用的第二服务器较少时(数量小于第一阈值时)，第二服务器很可能出现问题，若这时将数据发送至第二服务器则可能造成数据丢失，因此，在这种情况下启用备通道，暂时将日志数据存储于第一服务器本地，当可用的第二服务器的数量恢复正常时，再启用主通道，将第一服务器本地暂存的日志数据和日志生成单元210在当前时刻生成的日志数据发送至可用的第二服务器，这样可以保证数据传输的可靠性。应当指出，第一阈值可以由本领域技术人员根据实际情况自行设置，例如，在考虑到服务器冗余容灾的简单情况下，可以将第一阈值设置为2。
另外，在可用的第二服务器的数量大于等于第一阈值(第一阈值≥2)时，可用的第二服务器有多个，第一输出单元220没有必要向每一个可用的第二服务器均发送日志数据，而是从中选择一个发送数据即可。根据一种实施例，在可用的第二服务器的数量大于等于第一阈值时，第一输出单元220以轮询的方式从多个可用的第二服务器中确定一个第二服务器，并将日志数据发送至确定的所述第二服务器。所谓轮询，即依次询问列表中的第二服务器是否空闲，若空闲，则将日志数据发送至该第二服务器。
第一输出单元220例如可以实现为基于log4j(log for java)实现的一个自定义的Appender对象，其内部封装了能够实现对可用的第二服务器列表进行监听的ZooKeeper客户端以及用于数据传输的UDP(User Datagram Protocol，用户数据报协议)客户端。ZooKeeper客户端可以以注册监听的方式监听监控服务器400处的可用的第二服务器列表。基于该列表，UDP客户端可以采用UDP协议向可用的第二服务器发送日志数据。
第二服务器300中包括本地化存储单元310，用于接收第一服务器发送的日志数据，并根据日志数据所属的日志类型将接收到的日志数据存储于第二服务器300的相应日志文件中。本地化存储单元310可以将接收到的日志数据放到队列中，并开启多个线程来处理队列中的日志数据，将日志数据保存到本地的日志文件中。第二服务器300中也可以存储有针对不同日志类型所设置的配置文件，用于指定将日志数据存入日志文件过程中的一些参数。以下是配置文件的一个示例：
<log type＝"web_mall_augf_click_count"desc＝"web_mall_augf_click_count">
<rollmin>30</rollmin>
<flushsec>3</flushsec>
</log>
其中，第一行代码表示日志类型为“web_mall_augf_click_count”。第二行代码表示文件生成时间间隔为30分钟，即每30分钟生成一个文件。另外，可以根据日志类型和文件生成时间间隔来为文件命名，文件名称＝日志类型+时间，后一个文件的时间为前一个文件的时间与配置的时间间隔之和。例如，2017年1月1日日志类型“web_mall_augf_click_count”的第一个日志文件的名称为“web_mall_augf_click_count.201701010000”，第二个文件名称为“web_mall_augf_click_count.201701010030”，以此类推。第三行代码表示每3秒钟将缓存的日志数据写入文件。例如，对于接收到的日志数据，首先将其写入缓存队列，3秒后再将缓存中的日志数据写入文件，这样可以保证日志数据的写入效率。当然，该配置文件仅是一个示例，本领域技术人员可以根据实际情况自行设置配置文件，本发明对第二服务器300中存储的配置文件的具体内容不做限制。
根据一种实施例，如图2所示，第二服务器300中还包括第二输出单元320，用于读取第二服务器300中存储的日志文件，并将日志文件中的日志数据发送至数据应用端120，方便后续对日志数据进行应用。根据一种实施例，第二输出单元320可以按照以下步骤来读取第二服务器300中存储的日志文件，并将日志文件中的日志数据发送至数据应用端：首先，将待发送的日志类型添加至队列中，其中，每个日志类型包括一个或多个日志文件。创建多个线程，每个线程可以从队头取出一个日志类型，读取该日志类型所对应的日志文件中的日志数据并将其发送至数据应用端。为了避免同时读取一个日志类型文件所带来的数据混乱和数据安全问题，同一时间同一个日志类型只能被一个线程占用，当触发预设的释放条件时，线程在其处理的日志文件中标记当前处理到的数据位置，随后解除对日志类型的占用，将该日志类型放回队尾，从队头再重新取出一个日志类型，进行下一轮的日志数据处理和发送。释放条件可以由本领域技术人员根据实际情况自行设置，例如，可以设置为当线程读取到当前日志文件的最后一个换行符\n(即读取到当前时刻的最后一条日志数据)时解除对当前日志类型的占用。
应当指出，一般来说，第二输出单元320是实时工作的，即，本地化存储单元310每存储一条日志数据，第二数据单元320即时将其加入队列，等待发送至数据应用端120。相应地，队列中的每一个日志类型一般仅对应于该日志类型当前时刻最新的日志文件。在这种情况下，由于本地化存储单元310会按照一定的时间间隔来生成日志文件(例如每半小时生成一个日志文件)，那么若线程刚好在本地化存储单元310切换日志文件的时刻读取日志文件，则可能会出现找不到文件的情况。因此，根据一种实施例，为线程在日志切换时读取文件设置一个等待时间，例如，30秒。若超过等待时间后仍未生成新的日志文件，则线程也无法读取文件，这时再报错提示找不到文件。该方案相当于在线程读取日志文件时为本地化存储单元310预留了一段时间生成新的日志文件，避免了线程找不到文件的虚假报错以及频繁报错。
图3示出了根据本发明一个实施例的多线程处理日志数据的示意图。如图3所示，队列中包括N个日志类型，每个日志类型中包括多个日志文件。图3所示的队列为静态队列，其所占用的存储空间固定不变。当然，在其他的实施例中，也可以采用动态队列，其所占用的存储空间随着队列中元素的数量而变化。本发明对队列的形式不做限制。图3中，采用三个线程，即线程1～线程3来处理并发送日志数据。首先，线程1从队头取出日志类型1，线程2从队头取出日志类型2，线程3从队头取出日志类型3，随后，各线程分别读取各日志类型所对应的日志文件中的日志数据并将其发送至数据应用端。当线程读取到当前日志文件的最后一个换行符(即读取到当前时刻的最后一条日志数据)时解除对当前日志类型的占用，将其占用的日志类型放回队尾，在分别从队头取一个日志类型，继续进行日志数据的读取和发送。
根据一种实施例，数据应用端包括Hadoop集群、Kafka集群、UDP服务器等，但不限于此。Hadoop集群可以提供离线计算服务，Kafka集群可以提供实时计算服务。其中，根据本发明的技术方案，可以将日志数据快速写入数据应用端，对于Hadoop集群仅有2min延迟，而Kafka集群仅有5s延迟。
例如，第二输出单元320的将日志数据发送至Hadoop集群的过程可以采用以下代码来配置实现：
<log type＝"web_mall_augf_click_count"desc＝"web_mall_augf_click_count">
<hdfs>
<path>/stage/web/mall/web_mall_augf_click_count</path>
<compress>true</compress>
<latency>30000</latency>
<rollmin>30</rollmin>
</hdfs>
</log>
其中，第一行代码表示日志类型，<path>表示Hadoop集群的目标路径，<compress>表示数据是否压缩，<latency>表示线程在日志切换时刻的等待时间(单位为毫秒)，<rollmin>表示日志文件的时间间隔(单位为分钟)。
根据一种实施例，日志生成单元210、第一输出单元220、本地化存储单元310、第二输出单元320中均包括监控模块333(图1、图2中均未示出)，可以监控每一种日志类型的日志数据的流量情况。图4A、4B示出了根据本发明的日志数据流量的监控结果的示意图，其中，横坐标为时间，纵坐标为每秒HTTP请求数量(query per second)。图4A为日志生成单元210处生成的所有日志类型的日志数据的流量情况，图4B为日志生成单元210处生成的日志类型为web_pvlog的日志数据的流量情况。
图5示出了根据本发明一个实施例的日志收集方法500的流程图。方法500可以在如前述图1所示的日志收集系统100中执行。如图5所示，该方法包括步骤S510～S550。
在步骤S510中，监控服务器获取第二服务器的运行状态，生成可用的第二服务器列表。该步骤的具体过程可以参考前述对监控服务器400的描述，此处不再赘述。
在步骤S520中，第一服务器从客户端发起的HTTP请求中解析出请求路径，根据请求路径确定日志类型，根据该日志类型所对应的配置文件中所指定的日志数据格式将该HTTP请求生成日志数据。该步骤的具体过程可以参考前述对日志生成单元210的描述，此处不再赘述。
在步骤S530中，第一服务器监听可用的第二服务器列表。该步骤的具体过程可以参考前述对监听模块222的描述，此处不再赘述。
在步骤S540中，第一服务器将日志数据发送至可用的第二服务器。该步骤的具体过程可以参考前述对第一输出单元220的描述，此处不再赘述。
在步骤S550中，第二服务器接收到第一服务器发送的日志数据后，根据日志数据所属的日志类型将接收到的日志数据存储于第二服务器的相应日志文件中。该步骤的具体过程可以参考前述对本地化存储单元310的描述，此处不再赘述。
应当指出，步骤S510和S520之间并不存在先后顺序，实际上，二者都是不停地在进行的，即，在步骤S510中，监控服务器每隔第一时间都会获取第二服务器的运行状态；在步骤S520中，由于第一服务器几乎每时每刻都会接收到客户端发起的HTTP请求，相应地，也会不断地生成日志数据。
图6示出了根据本发明一个实施例的日志收集方法600的流程图。方法600可以在如前述图2所示的日志收集系统100中执行。如图6所示，该方法包括步骤S510～S560。其中，步骤S510～S550与图5所示的方法500完全相同，此处不再赘述。方法600与方法500的区别仅在于步骤S560。
在步骤S560中，读取第二服务器中存储的日志文件，将所述日志文件中的日志数据发送至数据应用端。该步骤的具体过程可以参考前述对第二输出单元320的描述，此处不再赘述。
A6：A1所述的系统，其中，第二服务器中还包括第二输出单元，适于读取第二服务器中存储的日志文件，将所述日志文件中的日志数据发送至数据应用端。
A7：A6所述的系统，其中，所述第二输出单元进一步适于：
将待发送的日志类型添加至队列中，其中，每个日志类型包括一个或多个日志文件；
创建多个线程；
对于每一个线程：
从队头取出一个日志类型；
读取该日志类型所对应的日志文件中的日志数据并将其发送至数据应用端；
将该日志类型放回队尾。
A8：A6所述的系统，其中，所述数据应用端包括：Hadoop集群、Kafka集群、UDP服务器中的一种或多种。
A9：A6所述的系统，其中，所述日志生成单元、第一输出单元、本地化存储单元、第二输出单元中均包括监控模块，适于监控每一种日志类型的日志数据的流量情况。
B15：B10所述的方法，其中，在根据日志数据所属的日志类型将接收到的日志数据存储于第二服务器的相应日志文件中的步骤之后，还包括步骤：读取第二服务器中存储的日志文件，将所述日志文件中的日志数据发送至数据应用端。
B16：B15所述的方法，其中，所述读取第二服务器中存储的日志文件，将所述日志文件中的日志数据发送至数据应用端的步骤包括：
将待发送的日志类型添加至队列中，其中，每个日志类型包括一个或多个日志文件；
创建多个线程；
对于每一个线程：
从队头取出一个日志类型；
读取该日志类型所对应的日志文件中的日志数据并将其发送至数据应用端；
将该日志类型放回队尾。
B17：B15所述的方法，其中，所述数据应用端包括：Hadoop集群、Kafka集群、UDP服务器中的一种或多种。
B18：B10所述的方法，其中，还包括步骤：监控每一个第一服务器、第二服务器中每一种日志类型的日志数据的流量情况。
在此处所提供的说明书中，算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与本发明的示例一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员应当理解在本文所公开的示例中的设备的模块或单元或组件可以布置在如该实施例中所描述的设备中，或者可替换地可以定位在与该示例中的设备不同的一个或多个设备中。前述示例中的模块可以组合为一个模块或者此外可以分成多个子模块。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
此外，所述实施例中的一些在此被描述成可以由计算机系统的处理器或者由执行所述功能的其它装置实施的方法或方法元素的组合。因此，具有用于实施所述方法或方法元素的必要指令的处理器形成用于实施该方法或方法元素的装置。此外，装置实施例的在此所述的元素是如下装置的例子：该装置用于实施由为了实施该发明的目的的元素所执行的功能。
如在此所使用的那样，除非另行规定，使用序数词“第一”、“第二”、“第三”等等来描述普通对象仅仅表示涉及类似对象的不同实例，并且并不意图暗示这样被描述的对象必须具有时间上、空间上、排序方面或者以任意其它方式的给定顺序。
尽管根据有限数量的实施例描述了本发明，但是受益于上面的描述，本技术领域内的技术人员明白，在由此描述的本发明的范围内，可以设想其它实施例。此外，应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围，对本发明所做的公开是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。
Claims (16)
1.一种日志收集系统，所述系统包括：
一个或多个第一服务器，每一个第一服务器中均存储有多个配置文件，所述配置文件适于指定每种日志类型所对应的请求路径和日志数据格式，每一个第一服务器均包括：
日志生成单元，适于从客户端发起的HTTP请求中解析出请求路径，根据请求路径确定日志类型，根据该日志类型所对应的配置文件中所指定的日志数据格式将所述HTTP请求生成日志数据；
第一输出单元，适于将日志数据发送至第二服务器；
一个或多个第二服务器，每一个第二服务器均包括：
本地化存储单元，适于接收第一服务器发送的日志数据，将日志数据放到队列中，开启多个线程来处理队列中的日志数据，并根据日志数据所属的日志类型将接收到的日志数据存储于第二服务器的相应日志文件中，其中第二服务器中存储有针对不同日志类型所设置的配置文件，用于指定将日志数据存入日志文件过程中的参数；
监控服务器，适于获取第二服务器的运行状态，生成可用的第二服务器列表；
其中，第一输出单元中还包括：监听模块，适于监听所述可用的第二服务器列表，所述第一输出单元适于在可用的第二服务器的数量小于第一阈值时，将所述日志数据存储于第一服务器；在可用的第二服务器的数量大于等于第一阈值时，将第一服务器中已存储的日志数据和日志生成单元在当前时刻生成的日志数据发送至可用的第二服务器。
2.如权利要求1所述的系统，其中，所述监控服务器进一步适于：
每隔第一时间向每一个第二服务器发送确认信息；
若在第二时间内接收到第二服务器的反馈信息，则将该第二服务器判定为可用的第二服务器，加入可用的第二服务器列表。
3.如权利要求1或2所述的系统，其中，所述可用的第二服务器列表包括一条或多条可用的第二服务器记录，每条可用的第二服务器记录包括IP地址和端口号信息。
4.如权利要求1所述的系统，其中，所述第一输出单元还适于：
在可用的第二服务器的数量大于等于第一阈值时，以轮询的方式从多个可用的第二服务器中确定一个第二服务器，并将日志数据发送至确定的所述第二服务器。
5.如权利要求1所述的系统，其中，第二服务器中还包括第二输出单元，适于读取第二服务器中存储的日志文件，将所述日志文件中的日志数据发送至数据应用端。
6.如权利要求5所述的系统，其中，所述第二输出单元进一步适于：
将待发送的日志类型添加至队列中，其中，每个日志类型包括一个或多个日志文件；
创建多个线程；
对于每一个线程：
从队头取出一个日志类型；
读取该日志类型所对应的日志文件中的日志数据并将其发送至数据应用端；
将该日志类型放回队尾。
7.如权利要求5所述的系统，其中，所述数据应用端包括：Hadoop集群、Kafka集群、UDP服务器中的一种或多种。
8.如权利要求5所述的系统，其中，所述日志生成单元、第一输出单元、本地化存储单元、第二输出单元中均包括监控模块，适于监控每一种日志类型的日志数据的流量情况。
9.一种日志收集方法，在日志收集系统中执行，所述系统包括一个或多个第一服务器、一个或多个第二服务器以及监控服务器，其中，每一个第一服务器中均存储有多个配置文件，所述配置文件适于指定每种日志类型所对应的请求路径和日志数据格式，所述方法包括：
监控服务器获取第二服务器的运行状态，生成可用的第二服务器列表；
第一服务器从客户端发起的HTTP请求中解析出请求路径，根据请求路径确定日志类型，根据该日志类型所对应的配置文件中所指定的日志数据格式将所述HTTP请求生成日志数据；
第一服务器监听所述可用的第二服务器列表，在可用的第二服务器的数量小于第一阈值时，将所述日志数据存储于第一服务器；在可用的第二服务器的数量大于等于第一阈值时，将第一服务器中已存储的日志数据和日志生成单元在当前时刻生成的日志数据发送至可用的第二服务器；
第二服务器接收到第一服务器发送的日志数据后，将日志数据放到队列中，开启多个线程来处理队列中的日志数据，根据日志数据所属的日志类型将接收到的日志数据存储于第二服务器的相应日志文件中，其中第二服务器中存储有针对不同日志类型所设置的配置文件，用于指定将日志数据存入日志文件过程中的参数。
10.如权利要求9所述的方法，其中，所述监控服务器获取第二服务器的运行状态，生成可用的第二服务器列表的步骤包括：
监控服务器每隔第一时间向每一个第二服务器发送确认信息；
若在第二时间内接收到第二服务器的反馈信息，则将该第二服务器判定为可用的第二服务器，加入可用的第二服务器列表。
11.如权利要求9或10所述的方法，其中，所述可用的第二服务器列表包括一条或多条可用的第二服务器记录，每条可用的第二服务器记录包括IP地址和端口号信息。
12.如权利要求9所述的方法，其中，所述将第一服务器中已存储的日志数据和当前时刻生成的日志数据发送至可用的第二服务器的步骤包括：以轮询的方式从多个可用的第二服务器中确定一个第二服务器，并将日志发送至确定的所述第二服务器。
13.如权利要求9所述的方法，其中，在根据日志数据所属的日志类型将接收到的日志数据存储于第二服务器的相应日志文件中的步骤之后，还包括步骤：读取第二服务器中存储的日志文件，将所述日志文件中的日志数据发送至数据应用端。
14.如权利要求13所述的方法，其中，所述读取第二服务器中存储的日志文件，将所述日志文件中的日志数据发送至数据应用端的步骤包括：
将待发送的日志类型添加至队列中，其中，每个日志类型包括一个或多个日志文件；
创建多个线程；
对于每一个线程：
从队头取出一个日志类型；
读取该日志类型所对应的日志文件中的日志数据并将其发送至数据应用端；
将该日志类型放回队尾。
15.如权利要求13所述的方法，其中，所述数据应用端包括：Hadoop集群、Kafka集群、UDP服务器中的一种或多种。
16.如权利要求9所述的方法，其中，还包括步骤：监控每一个第一服务器、第二服务器中每一种日志类型的日志数据的流量情况。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710058570.XA CN106777371B (zh) | 2017-01-23 | 2017-01-23 | 日志收集系统和方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710058570.XA CN106777371B (zh) | 2017-01-23 | 2017-01-23 | 日志收集系统和方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106777371A CN106777371A (zh) | 2017-05-31 |
| CN106777371B true CN106777371B (zh) | 2019-12-06 |
Family
ID=58942195
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710058570.XA Active CN106777371B (zh) | 2017-01-23 | 2017-01-23 | 日志收集系统和方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106777371B (zh) |
Families Citing this family (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107508869B (zh) * | 2017-08-11 | 2021-01-01 | 上海信联信息发展股份有限公司 | 追溯数据采集方法及客户端 |
| CN109428914B (zh) * | 2017-08-24 | 2022-01-25 | 北京国双科技有限公司 | 监控方法和装置、存储介质、处理器 |
| CN107908690B (zh) * | 2017-11-01 | 2021-07-20 | 南京欣网互联网络科技有限公司 | 一种基于大数据运营分析的数据处理方法 |
| CN107885610A (zh) * | 2017-11-17 | 2018-04-06 | 北京锐安科技有限公司 | 一种处理数据的方法以及装置 |
| CN107947975A (zh) * | 2017-11-17 | 2018-04-20 | 北京锐安科技有限公司 | 一种采集数据的方法以及装置 |
| CN108197013B (zh) * | 2017-12-26 | 2022-03-08 | Oppo广东移动通信有限公司 | 日志处理方法、装置、终端设备及存储介质 |
| CN107908802A (zh) * | 2017-12-26 | 2018-04-13 | 广东欧珀移动通信有限公司 | 日志处理方法、装置、终端设备及存储介质 |
| CN108491300A (zh) * | 2018-01-10 | 2018-09-04 | 北京掌阔移动传媒科技有限公司 | 一种基于分布式的日志处理系统 |
| CN110545296A (zh) * | 2018-05-28 | 2019-12-06 | 阿里巴巴集团控股有限公司 | 一种日志数据获取方法、装置及其设备 |
| CN109376020B (zh) * | 2018-09-18 | 2021-02-12 | 中国银行股份有限公司 | 多区块链交互并发下的数据处理方法、装置及存储介质 |
| CN109600254B (zh) * | 2018-11-29 | 2022-04-26 | 恒生电子股份有限公司 | 全链路日志的生成方法及相关系统 |
| CN109889593B (zh) * | 2019-02-27 | 2021-11-12 | 中国人民解放军海军工程大学 | 一种移动机动保障方舱的分布式主从机通讯方法及装置 |
| CN109918282B (zh) * | 2019-03-16 | 2023-02-24 | 河南工学院 | 一种计算机日志监控方法及监控平台 |
| CN110175154A (zh) * | 2019-05-17 | 2019-08-27 | 深圳前海微众银行股份有限公司 | 一种日志记录的处理方法、服务器及存储介质 |
| CN112019581B (zh) * | 2019-05-30 | 2022-02-25 | 华为技术有限公司 | 一种调度任务处理实体的方法及装置 |
| CN111046009B (zh) * | 2019-11-11 | 2023-11-21 | 杭州迪普科技股份有限公司 | 日志存储方法及装置 |
| CN112988679B (zh) * | 2021-03-18 | 2024-04-12 | 北京大米科技有限公司 | 日志采集控制方法、装置、存储介质及服务器 |
| CN115278213A (zh) * | 2022-07-11 | 2022-11-01 | 海南乾唐视联信息技术有限公司 | 掉线检测方法、服务器、电子设备及存储介质 |
| CN117194549B (zh) * | 2023-11-07 | 2024-01-26 | 上海柯林布瑞信息技术有限公司 | 基于任务数据配置的数据传输方法及装置 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103685501A (zh) * | 2013-12-06 | 2014-03-26 | 北京奇虎科技有限公司 | 数据处理方法、装置和系统 |
| CN103944973A (zh) * | 2014-04-02 | 2014-07-23 | 北京中交兴路车联网科技有限公司 | 一种日志采集方法及装置 |
| CN104301360A (zh) * | 2013-07-19 | 2015-01-21 | 阿里巴巴集团控股有限公司 | 一种日志数据记录的方法、日志服务器及系统 |
| CN106130782A (zh) * | 2016-07-19 | 2016-11-16 | 努比亚技术有限公司 | 一种获取服务器日志的方法和系统 |
| CN106254109A (zh) * | 2016-08-02 | 2016-12-21 | 深圳中兴网信科技有限公司 | 日志采集方法、日志采集系统和服务器 |
-
2017
- 2017-01-23 CN CN201710058570.XA patent/CN106777371B/zh active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104301360A (zh) * | 2013-07-19 | 2015-01-21 | 阿里巴巴集团控股有限公司 | 一种日志数据记录的方法、日志服务器及系统 |
| CN103685501A (zh) * | 2013-12-06 | 2014-03-26 | 北京奇虎科技有限公司 | 数据处理方法、装置和系统 |
| CN103944973A (zh) * | 2014-04-02 | 2014-07-23 | 北京中交兴路车联网科技有限公司 | 一种日志采集方法及装置 |
| CN106130782A (zh) * | 2016-07-19 | 2016-11-16 | 努比亚技术有限公司 | 一种获取服务器日志的方法和系统 |
| CN106254109A (zh) * | 2016-08-02 | 2016-12-21 | 深圳中兴网信科技有限公司 | 日志采集方法、日志采集系统和服务器 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN106777371A (zh) | 2017-05-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106777371B (zh) | 日志收集系统和方法 | |
| CN109522287B (zh) | 分布式文件存储集群的监控方法、系统、设备及介质 | |
| CN109076026B (zh) | 用于基于等待时间排队的系统和方法 | |
| JP2023520851A (ja) | ブロックチェーンメッセージ処理方法、装置、コンピュータデバイスおよびコンピュータプログラム | |
| US8135979B2 (en) | Collecting network-level packets into a data structure in response to an abnormal condition | |
| US20110138037A1 (en) | Techniques for web server management | |
| US20100229182A1 (en) | Log information issuing device, log information issuing method, and program | |
| CN110336848B (zh) | 一种访问请求的调度方法及调度系统、设备 | |
| CN109768899A (zh) | 网站可用性监测方法、装置、设备及介质 | |
| CN111176941B (zh) | 一种数据处理的方法、装置和存储介质 | |
| CN110311938A (zh) | 基于redis的请求处理方法、装置、网关及系统 | |
| CN112350854A (zh) | 一种流量故障定位方法、装置、设备及存储介质 | |
| CN115622906A (zh) | 一种应用日志抓取系统及方法 | |
| EP3742697A1 (en) | Data transmission scheduling method and system | |
| CN114281524A (zh) | 一种智能电缆业务处理系统管理方法及装置 | |
| CN110012051A (zh) | 通知推送方法、装置、终端设备、服务器及系统 | |
| CN115643166B (zh) | 一种高可靠回传cdn日志的方法及装置 | |
| CN114598622B (zh) | 数据监控方法及装置、存储介质、计算机设备 | |
| CN114422599B (zh) | 数据的传输方法、系统、电子设备及可读介质 | |
| JP2018067829A (ja) | 即時トラフィック収集・分析システム及び方法 | |
| WO2023043370A2 (en) | Method and apparatus for sending logs, and log management system | |
| CN112994934B (zh) | 数据交互方法、装置及系统 | |
| CN111913732A (zh) | 一种服务更新方法、装置及管理服务器、存储介质 | |
| CN109586968A (zh) | 大数据平台的日志处理方法和大数据平台的日志处理系统 | |
| CN113055493B (zh) | 数据包处理方法、装置、系统、调度设备和存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |