logstash快速入门_Logstash入门

logstash快速入门

LogstashElastic发行的一种开源工具,旨在吸收和转换数据。 它最初是作为日志处理管道构建的,用于将日志数据吸收到ElasticSearch中 。 以后有几个版本,它可以做的更多。

Logstash的核心是一种Extract-Transform-Load(ETL)管道形式。 提取非结构化日志数据,过滤器对其进行转换 ,然后将结果加载到某种形式的数据存储中。

Logstash可以采用一行文本,例如syslog示例:



   
   
Sep 11 14:13:38 vorthys sshd[16998]: Received disconnect from 192.0.2.11 port 53730:11: disconnected by user

并将其转换为更丰富的数据结构:



   
   
{
  "timestamp" : "1505157218000" ,
  "host" : "vorthys" ,
  "program" : "sshd" ,
  "pid" : "16998" ,
  "message" : "Received disconnect from 192.0.2.11 port 53730:11: disconnected by user" ,
  "sshd_action" : "disconnect" ,
  "sshd_tuple" : "192.0.2.11:513730"
}

根据用于后备存储的内容,可以通过使用索引字段而不是grep TB的文本来查找类似事件。 如果您每天要生成数十至数百GB的日志,那很重要。

内部架构

Logstash具有在JRuby中实现的三阶段管道:

输入阶段插件提取数据。 这可以来自日志文件,TCP或UDP侦听器,几种特定于协议的插件之一(例如syslog或IRC),甚至可以是排队系统(例如Redis,AQMP或Kafka)。 此阶段使用事件周围的元数据标记传入的事件。

筛选器阶段插件可转换和丰富数据。 在上面的示例中,这是生成sshd_actionsshd_tuple字段的阶段。 您将在这里找到Logstash的大部分价值。

输出阶段插件将处理后的事件加载到其他内容中,例如ElasticSearch或其他文档数据库,或排队系统(例如Redis,AQMP或Kafka)。 也可以将其配置为与API通信。 也可以将诸如PagerDuty之类的内容连接到Logstash输出。

是否有cron作业来检查备份是否成功完成? 它可以在日志记录流中发出警报。 它由输入拾取,并且设置为捕获那些事件的过滤器配置会将其标记出来,从而使条件输出可以知道此事件是否适合它。 这样,您便可以向脚本中添加警报,而这些脚本原本需要创建自己的通知层,或者在不允许与外界进行通信的系统上运行。

线程数

通常,每个输入都在其自己的线程中运行。 滤波器和输出级更加复杂。 在Logstash 1.5至2.1中,过滤器级具有可配置的线程数,而输出级仅占用一个线程。 当构建过滤器级线程来处理输出级时,这在Logstash 2.2中发生了变化。 使用更少的内部队列进行跟踪,Logstash 2.2提高了吞吐量。

如果您运行的是旧版本,则值得至少升级到2.2。 当我们从1.5移到2.2时,我们看到整体吞吐量增加了20-25%。 Logstash还在等待状态上花费的时间更少,因此我们使用了更多的CPU(47%比75%)。

配置管道

Logstash可以采用单个文件或目录进行配置。 如果给出了目录,它将以词法顺序读取文件。 这一点很重要,因为排序对于过滤器插件很重要(我们将在后面详细讨论)。

这是一个裸Logstash配置文件:



   
   
input { }
filter { }
output { }

其中每个将包含零个或多个插件配置,并且可以有多个块。

输入配置

输入部分如下所示:



   
   
input {
  syslog {
    port => 514
    type => “syslog_server”
  }
}

这告诉Logstash打开端口514上syslog { }插件 ,并将通过该插件进入的每个事件的文档类型设置为syslog_server 。 此插件仅遵循RFC 3164,而不遵循较新的RFC 5424。

这是一个稍微复杂的输入块:



   
   
# Pull in syslog data
input {
  file {
    path => [
      "/var/log/syslog" ,
      "/var/log/auth.log"
    ]
    type => "syslog"
  }
}

# Pull in application - log data. They emit data in JSON form.
input {
  file {
    path => [
      "/var/log/app/worker_info.log" ,
      "/var/log/app/broker_info.log" ,
      "/var/log/app/supervisor.log"
    ]
    exclude => "*.gz"
    type     => "applog"
    codec   => "json"
  }
}

这个使用两个不同的input { }块来调用file { }插件的不同调用:一个跟踪系统级日志,另一个跟踪应用程序级日志。 通过使用两个不同的input { }块,为每个生成一个Java线程。 对于多核系统,不同的核会跟踪配置的文件。 如果一个线程阻塞,另一个将继续运行。

这两个file { }块都可以放入相同的input { }块中; 它们只是在同一线程中运行-Logstash并不在乎。

过滤器配置

在过滤器部分,您可以将数据转换为更新且更易于使用的数据。 过滤器可能变得非常复杂。 以下是一些可以实现不同目标的过滤器示例:



   
   
filter {
  if [ program ] == "metrics_fetcher" {
    mutate {
      add_tag => [ 'metrics' ]
    }
  }
}

在此示例中,如果在顶部示例输入中由syslog插件填充的program字段读取metrics_fetcher ,则它将标记事件metrics 。 此标记可在以后的过滤器插件中使用,以进一步丰富数据。



   
   
filter {
  if "metrics" in [ tags ] {
    kv {
      source => "message"
      target => "metrics"
    }
  }
}

仅当metrics在标签列表中时,此命令才会运行。 然后,它使用kv { }插件根据message字段中的key=value对填充一组新字段。 这些新键被放置为metrics字段的子字段,从而使事件上的文本pages_per_second=42 faults=0变为metrics.pages_per_second = 42metrics.faults = 0

您为什么不将其置于设置tag值的相同条件中? 由于事件可以通过多种方式获取metrics标签,因此kv过滤器将处理所有这些指标。

因为过滤器是有序的,所以确保在定义检查条件的条件之前运行定义metrics标签的过滤器插件很重要。 以下是确保最佳过滤器顺序的准则:

  1. 您的早期过滤器应尽可能多地应用元数据。
  2. 使用元数据,执行事件的详细分析。
  3. 在后期过滤器中,对数据进行规范化以减少下游问题。
    • 确保将字段数据类型转换为统一值。 priority可以是布尔值,整数或字符串。
      • 某些系统,包括ElasticSearch,将为您安静地转换类型。 将字符串发送到布尔字段中不会给您想要的结果。
      • 如果值类型不正确,其他系统将直接拒绝该值。
    • mutate { }插件在这里很有用,因为它具有将字段强制转换为特定数据类型的方法。

这是从长字符串中提取字段的有用插件:

  • date :许多日志记录系统都会发出时间戳记。 该插件解析该时间戳,并将事件的时间戳设置为该嵌入时间。 默认情况下,事件的时间戳记是提取时的时间戳记,可能是几秒钟,几小时甚至几天之后。
  • kv :如前所述,它可以将backup_state=failed progress=0.24类的字符串转换为可以对其执行操作的字段。
  • csv :给定期望的列列表时,它可以基于逗号分隔的值在事件上创建字段。
  • json :如果字段以JSON格式设置,则它将变成字段。 很强大!
  • xml :类似于JSON插件,这会将包含XML数据的字段转换为新字段。
  • grok :这是您的正则表达式引擎。 如果您需要将诸如The accounting backup failed这样The accounting backup failed字符串转换为if [backup_status] == 'failed'会通过if [backup_status] == 'failed' ,则可以执行此操作。

输出配置

Elastic希望您将其全部发送到ElasticSearch中,但是任何可以接受JSON文档或它表示的数据结构的东西都可以作为输出。 请记住,事件可以发送到多个输出。 考虑以下指标示例:



   
   
output {
  # Send to the local ElasticSearch port , and rotate the index daily.
  elasticsearch {
    hosts => [
      "localhost" ,
      "logelastic.prod.internal"
    ]
    template_name => "logstash"
    index         => "logstash-{+YYYY.MM.dd}"
  }

  if "metrics" in [ tags ] {
    influxdb {
      host         => "influx.prod.internal"
      db           => "logstash"
      measurement   => "appstats"
      # This next bit only works because it is already a hash.
      data_points   => "%{metrics}"
      send_as_tags => [ 'environment' , 'application' ]
    }
  }
}

还记得上面的metrics示例吗? 这就是我们如何输出它。 标记了事件的metrics将以其完整事件形式发送到ElasticSearch。 此外,该事件的metrics字段下的子字段将被发送到appstats metrics下的logstash数据库中的appstats 。 与测量一起, environmentapplication字段的值将作为索引标签提交。

有很多输出。 以下是一些按类型分组的内容:

  • API包含 :Jira,PagerDuty,Rackspace,Redmine,Zabbix
  • 队列 :Redis,Rabbit,Kafka,SQS
  • 消息传递平台 :IRC,XMPP,HipChat,电子邮件,IMAP
  • 文档数据库 :ElasticSearch,MongoDB,Solr
  • 指标 :OpenTSDB,InfluxDB,Nagios,Graphite,StatsD
  • 文件和其他静态工件 :文件,CSV,S3

还有更多的输出插件

特殊之处:编解码器

编解码器是Logstash配置的特殊部分。 我们在上面的file {}示例中看到了一个。



   
   
# Pull in application - log data. They emit data in JSON form.
input {
  file {
    path => [
      "/var/log/app/worker_info.log" ,
      "/var/log/app/broker_info.log" ,
      "/var/log/app/supervisor.log"
    ]
    exclude => "*.gz"
    type     => "applog"
    codec   => "json"
  }
}

在这种情况下,文件插件已配置为使用json编解码器 。 这告诉文件插件在文件的每一行上都需要完整的JSON数据结构。 如果您的日志可以以这种结构发出,那么过滤阶段将比如果必须通过grk,kv和csv进行富集的情况要短得多。

json_lines编解码器的不同之处在于,它将根据提要中的换行符分隔事件。 当使用tcp { }输入之类的东西,连接程序在不每次都重新建立连接的情况下流JSON文档时,这是最有用的。

multiline编解码器特别受关注。 顾名思义,这是一个编解码器,您可以将其输入以将多行事件(例如Java堆栈转储)重组为单个事件。



   
   
input {
  file {
    path => '/var/log/stackdumps.log'
    type => 'stackdumps'
    codec => multiline {
      pattern => "^ \s "
      what     => previous
    }
  }
}

该编解码器告诉文件插件将以空格开头的任何日志行都视为属于前一行。 它将以新行和日志行的内容附加到message字段。 一旦它碰到一个不以空格开头的日志行,它将关闭该事件并将其提交给filter阶段。

警告 :由于Logstash具有高度分布式的特性,因此多行编解码器需要在尽可能靠近日志源的位置运行。 如果它直接读取文件,那是完美的。 如果事件是通过另一个系统(例如集中式syslog系统)来的,则重组为单个事件将更具挑战性。

建筑学

Logstash可以从多功能一体机扩展到庞大的基础架构,这些基础架构在处理事件以满足不同业务所有者之前需要复杂的事件路由。

在此示例中,Logstash在四个应用程序框的每一个上运行。 每个独立的配置将处理后的事件发送到集中式ElasticSearch集群。 这可以扩展很多,但是这意味着您的日志处理资源正在与应用程序资源竞争。

此示例显示了我们要添加到的基于Syslog的现有集中式日志记录基础结构。 在这里,Logstash安装在集中式日志记录盒上,并配置为使用rsyslog的文件输出。 然后将处理后的结果发送到ElasticSearch。

进一步阅读

请在10月29日至11月3日在加利福尼亚州旧金山举行的LISA17上 ,在Jamie Riedesel的S,M和L Logstash Architectures:The Foundations演讲中了解更多信息。

翻译自: https://opensource.com/article/17/10/logstash-fundamentals

logstash快速入门

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值