Linux日志监控：syslog-ng与ELK实战教程

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《Linux实时监控日志：syslog-ng与ELK实战应用》，聊聊，我们一起来看看吧！

syslog-ng在日志收集和预处理中扮演了可靠、灵活且具备智能预处理能力的日志交通枢纽角色。①它通过缓冲机制、多线程处理和多种传输协议支持，确保高并发和网络不稳定下的日志传输可靠性；②具备日志过滤、重写和格式化为JSON的能力，减轻Logstash负载；③可进行敏感信息脱敏和结构化处理，提升整个日志链效率与安全性。

在Linux系统上实现日志的实时监控，我个人认为，最行之有效且业界普遍推崇的方案，就是将强大的日志收集与转发工具syslog-ng，与功能全面的ELK Stack（Elasticsearch, Logstash, Kibana）结合起来。这套组合拳能让你从海量的日志数据中迅速捕获关键信息，实现真正的“实时”洞察。

要构建这套实时监控体系，核心在于数据流的打通与优化。

解决方案

首先，我们需要在各个Linux服务器上部署syslog-ng。syslog-ng的强大之处在于其灵活的配置能力，它可以收集来自内核、系统服务、应用程序的各类日志，并根据预设规则进行过滤、解析，然后以可靠的方式（比如TCP协议）将这些日志流式传输到一个中心化的Logstash实例。

在Logstash端，它会作为日志的“中央处理器”。Logstash配置了特定的输入插件来接收来自syslog-ng的数据流。接着，通过一系列的过滤器（比如grok、date、mutate等），Logstash能够对原始、非结构化的日志进行深度解析，提取出关键字段（如时间戳、日志级别、来源IP、错误信息等），并将其标准化为结构化的JSON格式。这个解析过程是整个链条中至关重要的一环，它决定了后续在Elasticsearch中数据的可查询性和Kibana中可视化的粒度。

解析后的结构化数据，会被Logstash的输出插件发送到Elasticsearch集群。Elasticsearch作为分布式搜索引擎，负责高效地存储、索引和检索这些海量的日志数据。它的横向扩展能力意味着无论日志量有多大，都能保持高性能。

最后，Kibana登场了。Kibana是Elasticsearch的配套可视化工具，通过它，我们可以直观地探索Elasticsearch中的日志数据。你可以创建各种仪表板（Dashboards），实时展示错误率、特定事件的发生频率、用户行为模式等。Kibana的Discover界面允许你进行自由查询和过滤，而Visualize界面则能将数据转化为各种图表，比如折线图、柱状图、饼图等，帮助我们从宏观和微观层面理解系统运行状况。

syslog-ng在日志收集和预处理中扮演了什么角色？

坦白说，很多时候我们提到日志，第一反应可能是直接用Logstash或Filebeat去拉取。但当我真正深入到大规模生产环境的日志管理时，我发现syslog-ng的价值远不止于此。它不仅仅是一个日志收集器，更像是一个智能的“日志交通枢纽”。

在我看来，syslog-ng最核心的价值体现在它的可靠性、灵活性和预处理能力。传统的syslogd在面对高并发日志写入或网络不稳定时，可能会出现丢包或性能瓶颈。syslog-ng则通过其内部的缓冲机制、多线程处理以及对多种传输协议（TCP、UDP、TLS）的支持，大大提升了日志传输的可靠性。即使中心Logstash暂时不可用，syslog-ng也能将日志缓存起来，待网络恢复后继续发送，这在关键业务系统中是不可或缺的特性。

更重要的是它的预处理能力。在日志发送到Logstash之前，syslog-ng就可以对日志进行初步的过滤、重写、甚至简单的解析。比如，你可以配置syslog-ng只转发特定级别的日志，或者将某些敏感信息进行脱敏处理。它甚至支持将日志格式化为JSON，这对于Logstash来说是极大的便利，因为它省去了Logstash在接收端进行复杂grok解析的步骤，直接接收结构化数据，从而减轻了Logstash的负载，提升了整个处理链的效率。这种“源头治理”的思路，让整个日志管道更加健壮和高效。

如何配置Logstash以有效处理来自syslog-ng的日志数据？

配置Logstash来接收并处理syslog-ng发送过来的日志，说起来，关键在于Logstash的输入（input）和过滤（filter）环节。我个人觉得，这里面最容易出错但也最能体现水平的，就是grok正则匹配。

通常，Logstash会使用syslog输入插件来监听来自syslog-ng的TCP或UDP连接。一个典型的配置可能看起来像这样：

input {
  syslog {
    port => 5000
    codec => plain { charset => "UTF-8" }
    type => "syslog"
  }
}

filter {
  if [type] == "syslog" {
    grok {
      match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" }
      add_tag => [ "syslog_parsed" ]
    }
    date {
      match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
      target => "@timestamp"
      remove_field => [ "syslog_timestamp" ]
    }
    mutate {
      convert => { "syslog_pid" => "integer" }
    }
    # 根据需要添加更多过滤规则，例如针对特定程序的日志解析
    if "ssh" in [syslog_program] {
      grok {
        match => { "syslog_message" => "Accepted %{WORD:auth_method} for %{USER:user} from %{IPORHOST:src_ip} port %{NUMBER:src_port} %{WORD:protocol}" }
        add_tag => [ "ssh_login" ]
      }
    }
  }
}

output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "syslog-%{+YYYY.MM.dd}"
  }
  stdout { codec => rubydebug } # 调试用
}

这里面有几个关键点：

1. syslog输入插件： 它能很好地处理标准syslog协议的日志。port指定监听端口，codec确保字符编码正确。
2. grok过滤器： 这是解析非结构化日志的利器。上面的例子使用了SYSLOGTIMESTAMP、SYSLOGHOST等预定义模式来匹配标准syslog格式。但实际情况中，应用程序的日志格式千变万化，你可能需要自定义grok模式。我通常会使用Grok Debugger这样的工具来测试和构建复杂的grok模式，这能省去大量试错时间。
3. date过滤器： 将日志中的时间戳字段（如syslog_timestamp）转换为Elasticsearch要求的@timestamp字段。这个字段对于Kibana的时间序列分析至关重要。如果转换失败，日志就无法正确地在Kibana的时间轴上显示。
4. mutate过滤器： 用于类型转换（如将字符串转换为整数）、字段重命名、添加/删除字段等。这有助于数据在Elasticsearch中正确存储和查询。
5. 条件判断： 使用if语句可以根据日志的来源、内容等进行有针对性的处理，比如只对SSH相关的日志进行更详细的解析。

配置Logstash是一个持续优化的过程。随着新的日志源加入，你可能需要不断调整grok模式和过滤规则，以确保所有关键信息都被正确提取。

利用Kibana进行日志可视化与实时监控的关键技巧有哪些？

当我第一次接触Kibana的时候，感觉它就是个“万能仪表盘”，但真正用起来，才发现有些技巧能让它发挥更大的作用，不仅仅是“好看”，更是“好用”。

首先，最基础但也是最重要的，是熟练使用Discover界面。这里是你探索原始日志数据的地方。学会使用KQL（Kibana Query Language）或Lucene查询语法进行高效搜索和过滤，比如 level:error AND host:webserver01。利用时间选择器（Time Picker）快速切换时间范围，这对于排查特定时间段的问题至关重要。我个人习惯在排查问题时，先在Discover里找到几个典型的日志样本，然后根据它们的字段结构去构建可视化。

其次，是有效利用Visualize界面创建多样化的图表。不要局限于默认的柱状图或折线图。例如：

• Metrics（指标）图： 用于显示关键数值，如错误日志总数、平均响应时间。
• Data Table（数据表）：展示聚合后的详细数据，比如按IP地址统计的错误次数列表。
• Pie Chart（饼图）/Donut Chart（环形图）： 分析不同日志级别或不同应用程序的占比。
• Line Chart（折线图）： 监控一段时间内的趋势，如每分钟的错误日志数量、CPU使用率等。通过添加多个Y轴，可以同时监控多个指标。
• Heat Map（热力图）： 观察事件在时间和维度上的分布密度，例如在一天中哪些时间点某个错误更频繁出现。

创建可视化时，关键在于选择合适的聚合方式。比如，统计日志数量用Count，计算平均值用Average，找出最大值用Max。合理使用Buckets（桶）进行分组，比如按host.keyword分组、按syslog_program.keyword分组，能让你从不同维度审视数据。

最后，将这些独立的图表组合成Dashboard（仪表板），是实现实时监控的核心。一个好的仪表板应该能在一瞥之间，让你对系统的整体健康状况有一个清晰的认识。你可以为不同的团队或不同的系统模块创建专属的仪表板。例如，一个“应用错误监控”仪表板可能包含错误日志趋势图、按错误类型分类的饼图、以及最新的错误日志列表。设置好自动刷新，你就可以实时看到日志的变化。

当然，Kibana本身也提供了简单的Alerting（告警）功能（通常在Elastic Stack的X-Pack组件中），你可以基于特定条件（如某个时间窗口内错误日志数量超过阈值）触发通知。这让监控从被动查看变为主动告警，真正实现了“实时”响应。但话说回来，告警策略的制定需要经验，过多的告警会造成“告警疲劳”，而太少的告警又可能错过关键问题。这是一个需要不断迭代和优化的过程。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Linux日志监控：syslog-ng与ELK实战教程》文章吧，也可关注golang学习网公众号了解相关技术文章。