Linux内核系统日志（详细版）

一、The Basics

Linux，Ubuntu，Centos和Red Hat Enterprise Linux(RHEL)，它们共同的Linux核心意味着这些操作系统都安装了日志框架来监视系统及其服务。

Linux日志框架包括一组管理员可以使用的目录、文件、服务和命令。

1.1 Common Linux Logs and Their Locations

使用Linux的日志模式，日志位于 /var/log 目录下，其中包含系统上每个服务或日志消息流(stream of log messages)的文件和目录。

/var/log/syslog (Debian) or /var/log/messages (RHEL):：这是一般系统消息和指标的整合流。在此日志文件中，您可以找到来自邮件、内核、身份验证和 cron 等服务的消息。

/var/log/auth.log (Debian) or /var/log/secure (RHEL)：此文件包含系统上成功和失败的尝试登录的身份验证日志。

/var/log/wtmp：此文件包含所有用户登录和注销活动的历史记录，用于审计用户在系统上的活动。

/var/log/lastlog：类似于 wtmp audit文件，该日志文件跟踪用户上次登录的情况。这是一个二进制文件，您可以通过以下方式读取 lastlog 命令。

/var/log/kern.log：此文件包含内核在传递到系统日志服务(如rsyslog) 进行进一步处理之前生成的日志消息。

/var/log/cron：cron服务作为协调器(orchestrator) 运行，以按计划的时间间隔启动任务。来自该服务的消息 (例如cron作业何时启动以及执行期间是否发生任何错误) 可以在此日志文件中找到。

在PostgreSQL 或Apache 等系统上运行服务时，您的应用程序的特定日志将在以下子目录下提供：/var/log。例如，如果您在基于Debian 的Linux 系统上运行Apache Web 服务器，您将在以下位置找到日志文件：/var/log/apache2。您会在此目录中找到每个日志流的单独文件，例如acess.log 或者error.log。

1.2 Introduction to Syslog

Syslog 是一种基于网络的日志记录协议，用于监视您的系统和应用程序。该协议为服务和应用程序报告其日志提供了一种标准方法。这样，就可以根据需要对它们进行处理和重定向。

1.2.1 标准化消息格式

syslog 协议提供由RFC 5424标准定义的消息格式。在这种格式中，定义了常见的事件信息，例如时间戳、主机名和生成消息的应用程序的名称。为了进一步支持此消息的构造，系统日志工具可用于指示日志来自系统的哪个部分。这是通过在消息中附加一个数字来完成的。以下是所有可用 facilities 的列表，编号从 0 到 23：

同样，可以使用 0 到 7 之间的数字将优先级附加到消息。

通过使用系统日志消息中的 facilities 和 priorities，访问系统日志数据的工具现在可以根据原始设施和消息的严重性来过滤消息。

1.2.2 系统日志协议（syslog protocol）实现

syslog 进程作为系统上的守护进程运行，以接收、存储和解释来自其他服务或应用程序的 syslog 消息。该服务通常监听用于 TCP 连接的514端口和用于 UDP 连接的601端口。许多应用程序允许您配置其事件日志，以将消息推送到正在运行的系统日志服务。

syslog 协议由不同的服务实现，例如 rsyslog 和 syslog-ng，允许您根据所需的功能集选择服务。由于这些服务与syslog 协议保持一致，因此它们可以互换用于系统和应用程序的日志记录，从而使其具有很强的可扩展性。

1.3 The Rsyslog Daemon

Rsyslog 是 syslog 守护进程的现代 open-source 实现，为任何环境提供高性能、注重安全的模块化设计。rsyslog 守护进程作为主机上的服务运行，监听发送给它的日志消息，并根据定义的操作路由这些消息。

在rsyslog的典型安装中，守护进程是通过位于以下位置的文件配置的：/var/rsyslog.conf 。在此配置文件中，使用日志消息的 facilities 和 priority 选择器允许您定义应对消息执行的操作。在下面的示例中，任何具有 mail facility 且priority 为 notice 或更高的消息都将被写入位于 /var/log/mail_errors 的日志文件中。

# <facility>.<severity>    <action>
mail.notice /var/log/mail_errors

这些选择器由facility（消息的来源）和priority（消息的严重性serverity）构成，并用点分隔。下面的示例显示了使用此简单配置对传入日志执行操作的一些可能性。

# Log a message to file
mail.notice /var/log/mail_errors

# Log a message to a user
Kern.debug bob

# Emergency messages from any facility should go to all users
*.emerg *

# Log a message to another host over UDP
*.* @remote-host

# Log a message to another host over TCP
*.* @@remote-host:514

1.4 Basic Commands for Linux Logging

我们经常会连接到Linux 服务器来读取日志消息，以对系统或在其上运行的服务进行故障排除。Linux 系统上提供了多个实用程序命令，简化了您浏览存储日志消息的方式。

cat、more、less、tail、head、grep

使用这些基本命令，您可以轻松访问和导航系统上的日志消息。通过在命令中使用管道（|），您可以将多个命令链接在一起，进一步过滤它们的输出。例如，以下命令链将读取 /var/log/cron 文件并检查是否有任何消息包含字符串 “foo”。

cat /var/log/cron | grep "foo"

高级日志记录操作也可以使用 awk，cut以及高级的grep 过滤器，使你可以更深入地了解系统上发生的情况。

二、Advanced Concepts

在 Linux 日志记录指南概述的第一部分中，我们讨论了 Linux 日志记录框架的基础知识：常见的 Linux 日志文件及其位置、syslog 协议以及用于获取消息流的 rsyslog 守护进程。我们还介绍了访问和操作这些日志流的常用 Linux 命令。

在第二部分中，我们将深入探讨：

配置rsyslog 守护进程

使用systemd 和 journald 实用程序检查系统上的服务日志

使用 logrotate 在不填满磁盘的情况下维护系统上相关性最高的日志

2.1 The rsyslog Daemon Configuration

正如我们在第一部分中介绍的，Linux 使用名为 rsyslogd 的守护进程来使用 syslog 协议处理消息。该服务从常规的 syslog 守护进程演变为当前的企业级日志系统。让我们检查一下默认 rsyslog 文件的内容。例如，在 Centos 8 上，您可以在以下位置找到此文件：/etc/rsyslog.conf

# rsyslog configuration file

# For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
# If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html

#### MODULES ####

# The imjournal module bellow is now used as a message source instead of imuxsock.
$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imjournal # provides access to the systemd journal
#$ModLoad imklog # reads kernel messages (the same are read from journald)
#$ModLoad immark  # provides --MARK-- message capability

# Provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# Provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514


#### GLOBAL DIRECTIVES ####

# Where to place auxiliary files
$WorkDirectory /var/lib/rsyslog

# Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# File syncing capability is disabled by default. This feature is usually not required,
# not useful and an extreme performance hit
#$ActionFileEnableSync on

# Include all config files in /etc/rsyslog.d/
$IncludeConfig /etc/rsyslog.d/*.conf

# Turn off message reception via local log socket;
# local messages are retrieved through imjournal now.
$OmitLocalLogging on

# File to store the position in the journal
$IMJournalStateFile imjournal.state


#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 :omusrmsg:*

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log
# s30021712 test
local4.*                                                /var/log/haha


# ### begin forwarding rule ###
# The statement between the begin ... end define a SINGLE forwarding
# rule. They belong together, do NOT split them. If you create multiple
# forwarding rules, duplicate the whole block!
# Remote Logging (we use TCP for reliable delivery)
#
# An on-disk queue is created for this action. If the remote host is
# down, messages are spooled to disk and sent when it is up again.
#$ActionQueueFileName fwdRule1 # unique name prefix for spool files
#$ActionQueueMaxDiskSpace 1g   # 1gb space limit (use as much as possible)
#$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
#$ActionQueueType LinkedList   # run asynchronously
#$ActionResumeRetryCount -1    # infinite retries if host is down
# remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
#*.* @@remote-host:514
# ### end of the forwarding rule ###

此配置调用其他实用程序，例如 module 多次导入某个功能，然后对其进行配置 input。

你可以根据您的需要通过配置 rsyslog来链接其中的许多模块。

module(load="imtcp")
input(type="imtcp" port="514")

为 rsyslog 进程提供了指令以打开全局功能或使用系统上的其他文件扩展配置。

# File syncing capability is disabled by default. This feature is usually not required,
# not useful and an extreme performance hit
#$ActionFileEnableSync on

# Include all config files in /etc/rsyslog.d/
$IncludeConfig /etc/rsyslog.d/*.conf

除了配置 rsyslog 服务之外，您还可以自定义对消息进行哪些操作。

将消息写入提供的文件路径

提供用户名以在用户控制台中打印消息

提供星号 (*) 以将消息写入所有用户

使用 @host 将消息发送到不同的主机（由该远程主机的 syslog daemon 处理）。

# Write kernel logs to file
kern.* /var/log/kern

# Everybody gets emergency messages
*.emerg *

# Forward all messages to another host
*.* @@remote-host:514

Rsyslog 可以使用预定义的消息格式模板来处理消息，将其处理为所需的输出格式。Rsyslog 可以处理的日志文件格式有限，这些格式类似于其他应用程序和日志分析工具使用的默认格式。

有时，您可能需要为系统解析您自己的日志格式。通过 $ActionFileDefaultTemplate 参数，您可以配置 rsyslog 如何处理您的自定义日志格式。

# Create a log template formate
$template myFormat,"%rawmsg%\n"

# Set the template as the default
$ActionFileDefaultTemplate myFormat

在 rsyslog 配置文件中定义 ActionFileDefaultTemplate 参数后，rsyslog将根据规定的默认模板格式集来解析进一步的消息。

2.2 What is the systemd journal?

Systemd是一个Linux系统和服务管理器，可以根据用户定义的配置按需启动其他守护进程。该服务允许管理员在系统上配置一系列操作，从安装磁盘和网络位置等低级服务到启动 GUI 或 Web 服务器等面向用户的服务。您可以通过系统的unit、target或位于磁盘上的纯文本配置文件来配置服务的生命周期行为。

systemd 日志为 systemd 管理的服务提供集中的进程和系统日志记录工具。

请注意，这与前面讨论的syslog文件不同，因为这些服务日志不会写入纯文本文件。Journald daemon维护日志本身，将它们写入 /etc/systemd 。journald service 维护从 systemd 管理的服务中捕获的日志信息的索引日志。通过使用 journald 作为记录日志服务，它为系统管理员提供了管理服务生命周期的单一工具链，并使用单一工具监视其日志。要配置 journald service，可以更新配置文件(通常在 /etc/systemd/journald.conf)以控制存储选项、日志保留以及在需要时将日志转发给其他服务。

2.2.1 What is journalctl?

journalctl 实用程序允许您访问由 journald service 存储的日志信息。您可以使用该工具查询特定应用程序或服务的日志信息。

# Query for messages from the cron service
journalctl -u cron.service

还可以按时间范围、生成消息的用户或消息优先级对消息进行其他查询。

# Query for messages within a timeframe
journalctl --since 09:00 --until "1 hour ago"

# Check logs made by a specific user
journalctl _UID=100

# Show any error messages
journalctl -p err

在检查日志时，减少从 journalctl 收集的一些信息可能会有所帮助。可以通过指定找到的消息的输出消息格式来实现。

journalctl -o short
journalctl -o verbose
journalctl -o json-p­retty

2.2.2 journald Configuration

要配置journald服务，在典型的systemd和journald安装中可以使用 /etc/systemd/journald.conf 文件。下面是在Centos安装中找到的默认配置文件:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See journald.conf(5) for details.

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitInterval=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg
#LineMax=48K

正如您所看到的，所有配置行都使用默认值，并被注释掉。通常，这些值足以合理地管理计算机上的日志。如果您对日志进程有更具体的要求，则列出了一些关键参数及其可用值:

Storage：设置服务器使用哪个存储后端

Compress：如果为true，这将压缩写入日志的数据对象。默认情况下，当大小大于512字节时，将发生这种情况。该参数可以直接设置为一个数字，定义数据在压缩之前的阈值大小。

Splitmode：使用此参数，您可以指定 journald 如何拆分写入的日志文件。您可以将此参数配置为none，以避免拆分日志文件并将所有日志保存在单个流中。您可以使用uid为每个用户创建单独的日志。注意，uid是默认配置，需要使用persistent 的 Storage。

RateLimitIntervalSec and RateLimitBurst：这些参数用于配置在丢弃进一步消息之前 journald 服务将接受多少消息。一旦配置的时间间隔结束，将再次处理进一步的服务消息。

注意，对 /etc/systemd/journald.conf 文件的任何更改都需要重新启动 journald 服务才能使更改生效。

$ sudo systemctl restart systemd-journald

2.3 Rotating Log Files

在跟踪Linux系统上的消息时，日志文件会随着时间的推移而增长。如果不加以控制和监控，这些大文件可能会导致系统内存和存储空间出现问题。您可以通过设置 logrotate 来避免这个问题，它可以自动创建新的日志文件并关闭旧的日志文件。

根据您的日志保留配置，当日志文件达到特定大小或距离上次轮换已经过了一定时间时，可以进行日志轮换。日志循环还将从系统中删除最旧的文件，保留最新的消息可用。logrotate 配置文件位于/ect/logrotate.conf。

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
#compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
        minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.

要配置的参数包括以daily、weekly、monthly为指示的日志轮换频率。您还可以使用 rotate 参数配置要在系统上保留多少日志文件，并设置一个数字，该数字将控制在磁盘上保留多少文件。

还可以使用 maxsize 参数设置日志文件的最大大小，以便在 logrotate 创建新文件之前设置文件的最大大小。

# Rotate the log when it reaches the following size
size 10M

系统上生成日志的其他包和服务可以通过编写它们的日志文件来管理它们创建的日志文件，从而自动配置它们自己。

接下来参数中的 include 行可用于告诉 logrotate 查找其他 logrotate配置文件以扩展所使用的配置。

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

如果需要手动或自动化地与 logrotate 交互，可以使用 logrotate命令。这个命令是通过 cron 自动调用的，但是您也可以在任何时候调用它来运行 logrotate 并评估它应该如何处理您的日志文件。使用 -f 选项，您可以传入要用于执行的配置文件路径。

logrotate -f /etc/logrotate.conf

要验证该命令在不对文件进行任何更改的情况下执行的操作，可以使用-d标志执行该命令的试运行。

logrotate -d /etc/logrotate.conf

三、Best Practices

在此之前，我们介绍了Linux日志记录的基础知识，例如常见的文件位置和 syslog协议，以及Advanced Concepts，例如 rsyslog 以及 rsyslog 如何与 journald 结合使用。

在规模上，日志记录可能会导致问题。一些例子包括过多的日志记录、不一致的格式和缺乏上下文。但是，通过遵循Linux日志 best practices，您可以更有效地利用日志并避免许多常见的缺陷。

3.1 Use log levels to distinguish severity

在Linux操作系统中，日志级别表示日志的重要程度。这是一种区分日志事件的强大方法。每个日志语句都应该有适合该条目的级别。常见的日志级别包括：

Trace：包括有关应用程序行为的所有详细信息。它们只能用于开发目的，而不能用于生产。

Debug：这些应该包括有意义的条目，以帮助调试问题，但不应该在生产中使用。

Info：用于理解系统或用户行为。

Warn：指示可能成为错误的潜在问题。

Error：指示系统中存在错误，但这些错误不会影响系统的正常工作。

Critical/Fatal：表示系统出现故障，无法继续正常运行。

所有 level 都有特定的功能，可以作为分组事件的有效方式。密切关注这些指示关键故障的日志是必要的；这通常表明您的应用程序停止向其用户提供服务。

3.2 Avoid creating unnecessary logs

虽然这听起来可能违反直觉，但过多的日志可能是一个问题。太多的日志消息使得人们很难在半夜对生产问题进行故障排除，因为他们必须在大量的噪音（noise）中搜索以找到有用的信息。类似地，自动化流程可能会因为解析和分析无用的消息而浪费时间和资源。此外，存储不重要的日志消息会产生不必要的成本。因此，最好避免创建不相关的日志消息。

同时，您希望有足够的日志，其中包含完成任务所需的足够信息(例如安全信息和事件管理(SIEM))，以及评估潜在威胁所需的必要日志。

在生成的日志消息数量和它们的质量之间找到一个平衡。使用适当的日志级别有助于平衡不同软件开发和维护阶段的数量和质量。例如，在测试环境中，详细的日志记录可能是有帮助的;但是在生产环境中，日志可以减少到只包含错误或关键问题。

3.3 Distinguish between types of logs

不同的日志有不同的用途，因此区分它们很重要。例如，用户访问日志（user access logs）能帮助跟踪谁访问了某个系统，而调试日志提供了对系统完整状态的清晰理解。

混合不同类型的日志可能会使提取有价值的信息变得困难。相反，您应该根据日志消息的用途拆分它们，使用每个日志消息进行独立分析。在实践中，这种区别并不总是直截了当的。将相关的日志信息放在一起，同时添加足够的信息。这使得不同类型的日志之间的关系成为可能。

3.4 Rate-limit your logs

某些服务可能会产生过多的日志并耗尽资源(如磁盘空间)。但是，简单地禁用日志或减少其中的信息量可能会使它们毫无用处。

一种可能的解决方案是强制执行日志生成的速率限制，以减慢消息生成的速率。这将帮助您避免系统过载。大多数库和服务都具有速率限制功能。

3.5 Use a consistent log format

重要的是不要使用手动打印语句编写日志，因为这种方法容易出现错误和不一致。使用printf()进行日志记录会创建格式不一致的日志，使其难以阅读和解析。日志必须是有用的，使用一致的格式非常重要。每种编程语言都有可用的日志库来帮助您创建具有预期格式的日志(例如，Apache Log4j 2或zerolog)。

使用库将允许您轻松创建由其他服务使用的消息。例如，以JSON格式生成消息使日志解析器能够轻松、直接地使用索引消息。

使用一致的格式还可以使人们更容易地读取日志消息，特别是在进行故障排除时。使用标准的日期和时间格式，使用正确的级别，并包括适当的上下文，将使您的日志更易于人类阅读。

3.6 Add context to your log message

没有适当的上下文，日志消息可能是无用的。简单地记录“Error”的日志消息不会向人或机器传达足够的信息。可能会出现以下问题:错误指的是什么操作?错误是什么时候发生的?到底发生了什么?

添加上下文允许将日志事件与其他事件联系起来理解。为了理解一个系统是如何到达某种状态的，事件常常需要相互关联。一致的日志格式和日志消息中的适当上下文大大简化了这些任务。

3.7 Avoid logging sensitive information

日志中不包含敏感信息是很重要的。在日志中公开密码或个人可识别信息(PII)信息是一种不好的做法，这些安全问题可能会带来法律问题。

清理日志以避免记录和暴露敏感信息是很重要的。大多数标准库都有提供帮助的特性。使用日志扫描器还可以暴露敏感信息，因此相应地处理这些日志非常重要。

此外，确保日志文件权限与其文件内容相关。包含高度敏感信息的日志应该具有更严格的文件权限，并被传送到一个安全的位置。避免将它们留在主机上。

3.8 Rotate your logs

如果处理不当，日志文件的大小可能无法控制地增长。提前配置日志轮换来处理这个问题非常重要。日志轮询确保文件不会变得太大，可能会因为磁盘满或内存耗尽而中断服务。

有关设置日志轮询的详细信息，请参阅Advanced Concepts。

3.9 Use a centralized logging solution

许多企业拥有具有复杂基础设施和许多服务的复杂系统。由于这种复杂性，通过连接到每个服务器或组件进行手动检查来调试或调查日志是不可行的。即使使用脚本形式的自动化，这个过程也是难以忍受的。

集中式日志解决方案，如CrowdStrike Falcon LogScale，为这个问题提供了解决方案。LogScale提供了一个单一的地方来分析日志和一致的方式来查询它们，它可以大规模地处理。此外，集中式日志解决方案还可以提供其他特性，例如 alerting 或 APIs，从而使您能够更好地利用日志。

四、Centralized Logging

在本文章的前面几个章节中，我们介绍了与Linux日志相关的基本和高级概念。然后，在第3部分中，我们重点介绍了处理Linux日志记录的最佳实践。我们提到的最佳实践之一是集中式日志解决方案。集中式日志管理系统可以帮助我们克服处理和分析来自数十(甚至数百)Linux主机的复杂分布式系统的日志的困难。

接下来，我们将看看如何在我们的Linux系统上使用Falcon LogScale Collector，以便将系统日志发送到CrowdStrike Falcon LogScale。通过一个简单而统一的日志层，我们可以跨多个Linux主机的日志进行查询，处理多种日志格式等等。

4.1 Set up the Collector for Linux

首先，在Linux主机上download and install Falcon LogScale Collector。收集器依靠摄取令牌(用于身份验证的唯一字符串)将日志发送到正确的存储库。为您的 Falcon LogScale 存储库Generating an ingest token非常简单。

通过YAML文件和其他环境变量（environment variables）配置Falcon LogScale Collector。下面是一个最小配置文件的示例，它收集Linux内核日志并将它们发送给Falcon LogScale。

dataDirectory: data
sources:
  kernal_logs:
    type: file
    include: /var/log/kern.log
    sink: my_humio_instance
sinks:
  my_humio_instance:
    type: humio
    token: <ingest-token>
    url: https://cloud.community.humio.com

4.2 Processing

发送到Falcon LogScale的日志需要在存储之前进行处理。解析器可以处理结构化数据(如 JSON )或非结构化数据(如应用程序 stdout )。Falcon LogScale有几个内置的解析器（built-in parsers），您甚至可以create your own parser。

4.3 Indexing

虽然大多数集中式解决方案依赖于索引作为有效的解决方案来维护数据和提高查询效率，但Falcon LogScale提供了一个创新的解决方案，并提供了一个无索引的平台（index-free platform）。尽管没有索引，但Falcon LogScale展示了它在保持极快查询速度的同时进行大规模扩展的能力（Falcon LogScale demonstrates its ability to scale immensely）。

4.4 Querying

有了位于中心位置的Linux日志，就可以深入研究数据并进行查询了。通过搜索原始日志或从特定字段中选择数据来执行查询。例如，下面的查询给出了状态等于或大于 400 的前三种常用HTTP方法( PATCH 除外):

status >=400
| method != PATCH
| top(method, limit=3)

根据Falcon LogScale中的查询结果，您可以构建由小部件组成的仪表板（build dashboards composed of widgets）。

您还可以用几个小部件配置每个仪表板，包括原始数据或过滤数据，这些小部件可用于向下钻取更具体的数据。有关更多详细信息，请阅读how to create and maintain dashboards。

4.5 Conclusion

构建集中式日志解决方案有很多好处，比如简化的日志管理和安全分析。集中式日志帮助开发人员构建统一的日志层，该层收集Linux日志并将其发送到一个地方进行处理、索引、查询和可视化。

我们演示了如何使用Falcon LogScale Collector收集Linux日志并将其发送到Falcon LogScale。从头开始构建统一的日志层可能是一项艰巨的任务。Falcon LogScale Collector和Falcon LogScale大大简化了这一过程，使您能够专注于为客户提供商业价值。