阿里云logstash（阿里云盘10t永久激活2021）

本文目录一览：

• 1、ELK日志分析系统初体验
• 2、分布式日志系统Graylog、Loki及ELK的分析和对比
• 3、发送给rocketmq的消息日志怎么看
• 4、详解三款日志采集工具--Logstash,Fluentd, Logtail比较

ELK日志分析系统初体验

ELK

logstash

elasticsearch

kibana

ELK技术栈要点总结

官方文档之安装教程

Mac第三方工具安装

$ brew install logstash

********启动命令********

$ bin/logstash -f logstash-example.conf

Logstash根据logstash-example.conf配置文件对数据源进行数据读取和清洗，并将清洗结果写入指定的目标文件。

logstash命令除了可以使用“-f”指定配置文件外，还可以指定其他参数，具体说明可以参见 官方文档之Command Flags 。

Logstash除了通过命令行参数进行配置外，还可以在logstash.yml等setting文件中进行设置，具体说明参见 官方文档之Setting files

配置文件

配置文件结构清晰，但所涉及的插件种类繁多，而且在插件使用过程中还涉及 环境变量使用 和 条件语句使用 等内容。用户可根据需要选择适当的插件和语法实现数据收集和清洗的目标。

##1.2 Elasticsearch****技术

****Cluster****与****Node****

****Index****、****Type****与****Document****

****Shards****与****Replicas****

********启动命令********

$ bin/elasticsearch 前端方式启动

$ bin/elasticsearch -d 守护进程方式启动

elasticsearch启动比较简单，也额外创建配置文件，它将收集的数据重新编排存储，以支持数据的全文检索。检索是Elasticsearch最为重要的功能，也是最为复杂的语法。

********需要注意的是：********elasticsearch不支持在root用户下启动，因此，在启动前，用户需要创建非root用户，并为该用户赋予elasticsearch目录的操作权限，详情参见

********配置管理********

Elasticsearch一般不需额外配置，但是为了提高Elasticsearch性能可以通过elasticsearch.yml文件修改配置参数。当然，也可以根据用户系统配置降低配置参数，如jvm.heapsize。Elasticsearch默认占用2G内存，对于系统配置较低的服务器，很可能带来负载过大的问题，因此需要适当减少jvm.heapsize。

Elasticsearch提供大量的API支持检索服务，用户甚至可以根据需要定制化 分析器 、 映射器 .

##1.3 Kibana****技术

********安装********

参见 官方教程 ，值得注意的是Kibana与Elasticsearch版本要保持一致。

********启动********

********配置********

Kibana配置可以通过命令行参数或配置文件 kibana.yml 。Kibana应用的默认地址为localhost，无法从远程访问Kibana，因此，用户需要修改配置文件的server.host属性。

********数据检索********

（1）时间筛选：限定检索的时间范围

（2）index pattern：限定检索的数据范围

（3）字段筛选：限定特殊字段以及特殊字段值

（4）搜索框：采用Elasticsearch检索语法查询

********数据分析********

数据分析是Elasticsearch与Kibana的核心模块，Elasticsearch提供分析功能，kibana提供图形渲染功能。

数据分析需要涉及Elasticsearch的 Aggregation 、 Mapping 、 Analysis 和Kibana的 Visualize 和 Dashboard 等模块，内容相对比较复杂，用户可根据实际需要适当选择。

Kibana的Visualize是基于Elasticsearch聚合结果进行图形化展示，支持AreaChart、DataTable、PieChart等图表结构。Dashboard则是将多个visualize综合展示，并配注markdown记录，形成完整的数据分析报告。

#2 ****日志分析系统

##2.1 ****基于阿里云****NAS****的日志分析系统架构设计

********日志生成：********对于Java和Node应用，分别采用Logback与winston日志框架生成日志，注意，日志采用json格式单行存储（一行json对应一条日志）

********日志存储：********分布式应用的日志采用NAS统一存储，减少因日志分散保存而带来数据收集的高复杂度。

********日志收集与清洗：********基于Logback的Pipeline功能，从NAS读取日志数据，并通过 filter插件进行日志的格式化清洗，并将清洗结果传送到Elasticsearch。

********日志重排与存储：********Elasticsearch将收集的数据进行重排，以支持符合elasticsearch检索语法。并将重排数据予以保存，同事可以通过集群、分片（Shards、Replicas）等进行冗余存储。

********日志分析与检索：********通过Elasticsearch Search API即可检索与分析数据，但基于命令行的分析可视化不够，借助Kibana可以将日志分析与检索采用图形化、列表化的方式予以展现，提高数据的可读性。

##2.2 ****日志收集

********（****1****）**** Input****部分********

采用file插件收集NAS日志收据，path指定日志存放地址，采用通配符指定多个文件。

为了便于日志的Archive，以及标识产生日志的应用容器，日志文件采用“log+hostname”方式命名，因此，同一类日志可能会存在多个日志文件。

start_position指定从日志文件Start位置开始收集，file插件默认从End位置收集，只会收集Logstash启动后生成的日志。

type标识日志类型，对于微服务应用，我们借助type区分应用类型，以方便日后检索与问题定位。

********（****2****）**** Filter****部分********

filter的配置需要根据日志格式和清洗目标按需定制，在我们的项目中，日志采用json格式，其中message key对应的value又是json对象的字符串，因此在提取json key-value时需要做两次json过滤。

Logstash默认每条日志为message key的value，因此第一个json是对一条完整日志进行筛选，将json转换为一个个键值对。转换后，并不能将日志message字段对应的json对象拆分提取，因此需要再使用json插件过滤。由于完整日志对应的message key与日志内message key，二次使用json时Logstash会认为对完整日志进行过滤，为此需要对 message进行重命名，这时采用mutate插件完成。

********注意：********filter插件比较多，也比较复杂，用户可以根据自己需要按需选择。

##2.3 ****日志分析（检索）

（1）时间范围：按照日、周、月、年度分别统计分析

（2）应用比较：各类应用的使用频繁程度比较，结合监控数据判断每类应用耗用资源情况等

（3）API分析：各类请求接口的使用情况分析，哪类API使用频繁，各API的响应时间如何

分布式日志系统Graylog、Loki及ELK的分析和对比

日志系列：

企业级日志平台新秀Graylog，比ELK轻量多了

日志系统新贵Loki，比ELK轻量多了

1. 为什么需要集中的日志系统？

在分布式系统中，众多服务分散部署在数十台甚至是上百台不同的服务器上，要想快速方便的实现查找、分析和归档等功能，使用Linux命令等传统的方式查询到想要的日志就费时费力，更不要说对日志进行分析与归纳。

如果有一个集中的日志系统，便可以将各个不同的服务器上面的日志收集在一起，不仅能方便快速查找到相应的日志，还有可能在众多日志数据中挖掘到一些意想不到的关联关系。

作为DevOps工程师，会经常收到分析生产日志的需求。在机器规模较少、生产环境管理不规范时，可以通过分配系统账号，采用人肉的方式登录服务器查看日志。然而高可用架构中，日志通常分散在多节点，日志量也随着业务增长而增加。当业务达到一定规模、架构变得复杂，靠人肉登录主机查看日志的方式就会变得混乱和低效。解决这种问题的方法，需要构建一个日志管理平台：对日志进行汇聚和分析，并通过Web UI授权相关人员查看日志权限。

2. 日志系统选择与对比

关于企业级日志管理方案，比较主流的是ELK stack和Graylog。

常见的分布式日志系统解决方案有经典的ELK和商业的splunk。为什么没有选择上面的两种方案呢，原因主要是如下两种：

ELK目前很多公司都在使用，是一种很不错的分布式日志解决方案，但是需要的组件多，部署和维护相对复杂，并且占用服务器资源多，此外kibana也在高版本中开始商业化。

splunk是收费的商业项目，不在考虑范围。

3. 认识graylog

3.1 简介

graylog是一个简单易用、功能较全面的日志管理工具，graylog也采用Elasticsearch作为存储和索引以保障性能，MongoDB用来存储少量的自身配置信息，master-node模式具有很好的扩展性，UI上自带的基础查询与分析功能比较实用且高效，支持LDAP、权限控制并有丰富的日志类型和标准（如syslog，GELF）并支持基于日志的报警。

在日志接收方面通常是网络传输，可以是TCP也可以是UDP，在实际生产环境量级较大多数采用UDP，也可以通过MQ来消费日志。

3.2 优势

部署维护简单

资源占用较少

查询语法简单易懂(对比ES的语法…)

内置简单的告警

可以将搜索结果导出为 json

UI 比较友好

3.3 graylog单机架构图

3.4 graylog集群架构

4、基于 GrayLog ELK 的日志监控

Collector

FileBeat：轻巧占用资源少，但是功能有点弱。「想起了一些东西，都是泪」

Fluentd：个人理解在Logstash与FileBeat中间，可以简单处理一些日志，插件丰富「要再研究下」

自己弄：架构图里面只是mysql调用了自己实现的解析工具，但是其实当日志大到一定的量的还是必须自己来的，类似日志抽样、降级、控制频率等功能，是要真真切切的花费大量时间精力下去的一个sidecar并非动动嘴巴就能搞定的。「都是泪」

Queue

Kafka：王者地位「量小的时候也可以不用这个直接朝后面输出，有很多中间方案大家自己脑补」，不同的日志分不同的topic，严格区分日志所属类型，为后续消费打下基础，比如A业务进入A Topic并在日志中打上所属语言类型的Tag。

Consumer

Logstash：其实这个东西也可以作为收集端来使用，就是比较耗费资源有点重，还会莫名其妙挂了「应该是我不会玩」

GrayLog：本人最喜欢的一个组件，集解析、报警、简单分析、Dashboard、日志TTL的综合体，有这个东西吧其实Kibana就没啥用了，毕竟谁没事天天去分析日志。

Storage

ElasticSearch：全文索引Engine，其实并没有官方说的那么牛，当到一定的并发写入、大量查询之后其实根本不是加机器能解决的，怎么分shard，是按照天保存还是按照条数保存「我比较喜欢按照条数保存，这样可以保证每个index都差不多大小，对于reblance是有好处的，重复利用多盘」如何保存是需要不断调整的。「我们这边不讨论MongoDB去存日志，看着都不靠谱」

规范

其实日志系统最关键的是怎么打、什么格式打、但是这个东西需要消耗大量的时间去定义与各个部门Pk，遇到过大量不讲理的输出，直接线上Debug，600k的并发写入，日志又大又臭谁能扛得住「阿里云的SLS是真的很牛」

卷起袖子加油干，少动嘴，多动手，日志很好玩。在容器化的大环境下也越发的重要。

Flunted + Elasticsearch + Kibana的方案，发现有几个缺点：

不能处理多行日志，比如Mysql慢查询，Tomcat/Jetty应用的Java异常打印

不能保留原始日志，只能把原始日志分字段保存，这样搜索日志结果是一堆Json格式文本，无法阅读。

不符合正则表达式匹配的日志行，被全部丢弃。

对比图

总结

虽然两种解决方案在功能上非常相似，但仍有一些差异需要考虑。

两者之间最重要的区别在于，从一开始，Graylog就定位为强大的日志解决方案，而ELK则是大数据解决方案。Graylog可以通过网络协议直接从应用程序接收结构化日志和标准syslog。相反，ELK是使用Logstash分析已收集的纯文本日志的解决方案，然后解析并将它们传递给ElasticSearch。

在ELK中，Kibana扮演仪表盘的角色并显示从Logstash收到的数据。Graylog在这点上更方便，因为它提供了单一应用程序解决方案（不包括ElasticSearch作为灵活的数据存储），具有几乎相同的功能。因此，部署所需的时间更短。此外，与ELK相比，Graylog开箱即用，且具有出色的权限系统，而Kibana则不具备此功能。作为Elasticsearch的粉丝，我更喜欢Graylog而不是ELK，因为它完全符合我在日志管理方面的需求。

Graylog具有直观的GUI，并提供警报、报告和自定义分析功能。最重要的是，它能在多个日志源和跨机房收集数TB的数据。基于这些优势，我更喜欢用Graylog而不是另一个具有类似功能的流行堆栈——ELK。

如果有需要领取免费资料的小伙伴们， 可以点击此处领取资料哦！

发送给rocketmq的消息日志怎么看

发送给rocketmq的消息日志查看步骤。

1、创建并配置Filebeat采集器。

2、创建并运行Logstash管道。

3、模拟RocketMQ客户端日志。

4、连接安装了Filebeat的ECS实例。

5、搭建并运行消息队列RocketMQ版测试工程，发送若干条测试消息，生成日志。

6、登录目标阿里云ES实例的Kibana控制台。

7、创建一个索引模式即可观看消息日志。

详解三款日志采集工具--Logstash,Fluentd, Logtail比较

DT时代，数以亿万计的服务器、移动终端、网络设备每天产生海量的日志。中心化的日志处理方案有效地解决了在完整生命周期内对日志的消费需求，而日志从设备采集上云是第一步。

下面介绍下常见的三款日志采集工具并对比分析。

Logstash是一款开源的数据收集引擎，具备实时管道处理能力。简单来说，logstash作为数据源与数据存储分析工具之间的桥梁，结合 ElasticSearch以及Kibana，能够极大方便数据的处理与分析。通过200多个插件，logstash可以接受几乎各种各样的数据。包括日志、网络请求、关系型数据库、传感器或物联网等等。

logstash基于JRuby实现，可以跨平台运行在JVM上。

模块化设计，有很强的扩展性和互操作性。

开源社区中流行的日志收集工具，td-agent是其商业化版本，由Treasure Data公司维护，是本文选用的评测版本。

fluentd基于CRuby实现，并对性能表现关键的一些组件用C语言重新实现，整体性能不错。

fluentd设计简洁，pipeline内数据传递可靠性高。相较于logstash，其插件支持相对少一些。

阿里云日志服务的生产者，目前在阿里集团内部机器上运行，经过3年多时间的考验，目前为阿里公有云用户提供日志收集服务。

采用C++语言实现，对稳定性、资源控制、管理等下过很大的功夫，性能良好。相比于logstash、fluentd的社区支持，logtail功能较为单一，专注日志收集功能。

后面会分享更多devops和DBA方面内容，感兴趣的朋友可以关注下！