logstash

使用 MaxCompute之前，唱吧使用自建体系来存储处理各端收集来的日志数据，包括请求访问记录、埋点数据、服务器业务数据等。初期这套基于开源组件的体系有力支撑了数据统计、业务报表、风控等业务需求。但随着每天处理数据量的增长，积累的历史数据越来越多，来自其他部门同事的需求越来越复杂，自建体系逐渐暴露出了能力上的短板。同时期，唱吧开始尝试阿里云提供的ECS、OSS等云服务，大数据部门也开始使用 MaxCompute来弥补自建体系的不足。 在内部ELK实现的基础上，从自建机房向MaxCompute进行数据同步工作是比较简单的，实践中我们主要采取两种方式：一是利用阿里云提供的datahub组件，直接对接logstash；二是把待同步数据落地到文件，然后使用tunnel命令行工具上传至MaxCompute的对应表中。 数据进入MaxCompute后，我们按照数据的主题和使用场景构造了三层结构：原始数据层ODS、中间数据层MDS、报表数据层DM。ODS层中保存直接同步的数据，在此基础上加工整理到的原始表，例如增量同步的原mysql表，经过风控清洗的访问日志表等。MDS层存放原始层数据聚合、抽象加工过的结果，这一层的数据表更可读、读取计算时更经济，一般情况下要求其他部门的同事使用这一层的数据。DM层是处理理的最终结果，支持QuickBI直接读取进行报表展示，同时也支持同步回自建机房

背景 作为中国最大的在线教育站点，目前沪江日志服务的用户包含网校，交易，金融，CCTalk 等多个部门的多个产品的日志搜索分析业务，每日产生的各类日志有好十几种，每天处理约10亿条（1TB）日志，热数据保留最近7天数据，冷数据永久保存。 为什么做日志系统 首先，什么是日志？ 日志就是程序产生的，遵循一定格式（通常包含时间戳）的文本数据 通常日志由服务器生成，输出到不同的文件中，一般会有系统日志、 应用日志、安全日志。这些日志分散地存储在不同的机器上。 通常当系统发生故障时，工程师需要登录到各个服务器上，使用 grep / sed / awk 等 Linux 脚本工具去日志里查找故障原因。在没有日志系统的情况下，首先需要定位处理请求的服务器，如果这台服务器部署了多个实例，则需要去每个应用实例的日志目录下去找日志文件。每个应用实例还会设置日志滚动策略（如：每天生成一个文件），还有日志压缩归档策略等。 这样一系列流程下来，对于我们排查故障以及及时找到故障原因，造成了比较大的麻烦。因此，如果我们能把这些日志集中管理，并提供集中检索功能，不仅可以提高诊断的效率，同时对系统情况有个全面的理解，避免事后救火的被动。 我认为，日志数据在以下几方面具有非常重要的作用： 数据查找 ：通过检索日志信息，定位相应的 bug ，找出解决方案 服务诊断 ：通过对日志信息进行统计、分析

MySql 到 Elasticsearch input { jdbc { # 驱动jar包的位置 jdbc_driver_library => "/usr/local/logstash/jdbc-driver-library/mysql-connector-java-8.0.19.jar" # 驱动类名 jdbc_driver_class => "com.mysql.cj.jdbc.Driver" # 数据库连接 jdbc_connection_string => "jdbc:mysql://127.0.0.1:3306/base_db?characterEncoding=utf8&autoReconnect=true&serverTimezone=Asia/Shanghai&zeroDateTimeBehavior=convertToNull" # mysql用户名 jdbc_user => "root" # mysql密码 jdbc_password => "123456" # 数据库重连尝试次数 connection_retry_attempts => "3" # 开启分页查询（默认false不开启） jdbc_paging_enabled => true # 单次分页查询条数（默认100000,若字段较多且更新频率较高，建议调低此值） jdbc_page_size =>

ELK之间的合作机制： L （Logstash）作为信息收集者，主要是用来对日志的搜集、分析、过滤，支持大量的数据获取方式，一般工作方式为c/s架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。 E (Elasticsearch)作为数据的保存者，保存来自L（Logstash）收集的系统日志数据。 K （Kibana ）作为展示者，主要是将ES上的数据通过页面可视化的形式展现出来。包括可以通过语句查询、安装插件对指标进行可视化等。 ELK架构图 ELK的工具 ELK新增了一个FileBeat，它是一个轻量级的日志收集处理工具(Agent)，Filebeat占用资源少，适合于在各个服务器上搜集日志后传输给Logstash，官方也推荐此工具。 Filebeat隶属于Beats。目前Beats包含四种工具： 1 、Packetbeat（搜集网络流量数据） 2 、Topbeat（搜集系统、进程和文件系统级别的 CPU 和内存使用情况等数据） 3 、Filebeat（搜集文件数据） 4 、Winlogbeat（搜集 Windows 事件日志数据） Metricbeat 系统级监控。 用于从系统和服务收集指标。从 CPU 到内存，从 Redis 到 Nginx，Metricbeat

一文入门Es、Logstash、Kibana 前言 Elasticsearch是什么？既然它是英文的，我们不妨借助有道从 Elasticsearch 这几个字母出发来看看其字面上所表达的意思吧。其分为elastic和search两个独立的单词，既然如此，我们无脑有道一波，得到的解释如下： 从有道的解释来看，我们可以简单的对其理解为： Elasticsearch是及其具有弹性的、灵活的、像松紧带一样的且可供搜寻检索的一款工具。 o(*≧▽≦)ツ┏━┓ 百度百科对其解释如下： ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java语言开发的，并作为Apache许可条款下的开放源码发布，是一种流行的企业级搜索引擎。ElasticSearch用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。官方客户端在Java、.NET（C#）、PHP、Python、Apache、Groovy、Ruby和许多其他语言中都是可用的。根据DB-Engines的排名显示，Elasticsearch是最受欢迎的企业搜索引擎，其次是Apache Solr，也是基于Lucene。 从如上信息我们可以得知，Elasticsearch是一款实时、分布式存储的搜索引擎，在实际开发过程中

EFK 不是一个软件，而是一套解决方案。EFK 是三个开源软件的缩写，Elasticsearch，FileBeat，Kibana。其中 ELasticsearch 负责日志分析和存储，FileBeat 负责日志收集，Kibana 负责界面展示。它们之间互相配合使用，完美衔接，高效的满足了很多场合的应用，是目前主流的一种日志分析系统解决方案。 EFK 和 ELK 只有一个区别， 收集日志的组件由 Logstash 替换成了 FileBeat ，因为 Filebeat 相对于 Logstash 来说有2个好处： 1、侵入低，无需修改 elasticsearch 和 kibana 的配置； 2、性能高，IO 占用率比 logstash 小太多； ELK可参考： https://blog.51cto.com/14227204/2442249 当然 Logstash 相比于 FileBeat 也有一定的优势，比如 Logstash 对于日志的格式化处理能力，FileBeat 只是将日志从日志文件中读取出来，当然如果收集的日志本身是有一定格式的，FileBeat 也可以格式化，但是相对于Logstash 来说，效果差很多。 Filebeat 隶属于 Beats。目前 Beats 包含六种工具： Packetbeat（搜集网络流量数据） Metricbeat（搜集系统、进程和文件系统级别的

【编者的话】 本文主要分享达达是如何通过Kubernetes混部构建一个日峰值处理超过130亿条日志，单日存储超过14TB，总存储量300TB的日志系统。 背景 在2016年达达与京东到家合并后线上业务迅速发展。面对海量日志增长和日志查询需求，基于ELK架构的日志系统已经不能满足达达的线上场景，迫切需要一个高效自动化的日志系统。本文主要分享达达是如何通过Kubernetes混部构建一个日峰值处理超过130亿条日志，单日存储超过14TB，总存储量300TB的日志系统。 历史包袱 达达最早也是使用ELK构建第一版日志系统，当时被研发吐槽最多的是『 Kibana怎么查不到我想要的数据』、『日志延时怎么这么久』。经过仔细梳理分析后，我们发现当时的日志系统主要存在以下三个问题： 日志采集无法自动化 每当新增一个日志接入需求，研发要和运维反复沟通，再由运维修改Flume采集配置。每次变更都需要繁琐的手工操作，且执行过程中很容出现问题。 此外在服务扩容经常时会遗落添加Flume采集配置，导致部分日志采集丢失，直接影响业务数据统计准确性。所以，自动化的采集日志是实现高效日志系统的基础。 日志无格式化解析 当时采用的是如下图展示的经典ELK日志系统架构：Flume采集 --> Kafka集群 --> Logstash解析 --> ElasticSearch存储 --> Kibana查询展示。

文章目录 一、ELK简介 1、认识ELK 2、ELK架构图 3、ELFK架构 ELFK架构图 二、ELK分布式日志平台搭建 搭建流程 1、在相应容器下载所需要软件 2、安装Elasticsearch 3、解决Elasticsearch启动报错 4、安装Kibana 5、安装Logstash 三、ELK收集标准输入日志，并在web界面显示 作为运维人员，其价值不在于部署大量服务，而在于排错及服务性能优化，优化主要是考的是对服务配置及其参数的理解，而排错我们主要是借助日志文件，来完成的，早期我们借助sed、awk、grep三剑客在一般中小企业还是有很大的作用。但是在大企业的集群架构中，三剑客已经略显疲态，日志收集与处理的非常难，而且不方便。于是ELK分布式日志平台就应运而生！ 大家可以用三剑客尝试模拟千万级别pv的日志分析，完全就是不可行的！百万级别的pv就已经很吃力了！ 一、ELK简介 1、认识ELK ELK并不是一款独立的软件服务，而是三个软件的统称，它们分别是Elasticserach、Logstash、Kibana。ELK主要用于对大量服务器的各种日志进行集中化管理，同时可以对日志进行分析。 Elasticsearch是基于JAVA语言开发的，是分布式存储、搜索引擎，底层是使用lucene检索机制，主要是用于集中化管理日志、对日志内容进行分析和统计，实时、快速展示结果

1、下载 https://artifacts.elastic.co/downloads/logstash/logstash-5.4.0.rpm 2、安装 yum install -y logstash-5.4.0.rpm 3、测试 1）输出到屏幕 /usr/share/logstash/bin/logstash -e 'input { stdin {} } output { stdout { codec => rubydebug}}' 当屏幕输出：Successfully started Logstash API字样时说明测试成功 输出解释 ： "@timestamp" 当前时间 "@version" 版本 "host" 事件发生的主机 "message" 内容 https://www.elastic.co/guide/index.html查看用法 2）测试输出到文件 /usr/share/logstash/bin/logstash -e 'input { stdin {} } output { file { path =>"/tmp/log" } }' 3)输出到文件带压缩 /usr/share/logstash/bin/logstash -e 'input { stdin {} } output { file { path =>"/tmp/log.tar.gz" gzip =>

kibana安装及其配置 1、下载 https://artifacts.elastic.co/downloads/kibana/kibana-5.4.3-x86_64.rpm 2、安装、修改配置 yum install -y kibana-5.4.3-x86_64.rpm grep "^[a-z]" /etc/kibana/kibana.yml server.port: 5601 server.host: "10.1.2.189" elasticsearch.url: " http://10.1.2.184:9200 " 3、访问 10.1.2.189:5601 查看配置状态 http://10.1.2.189:5601/status 4、配置正则匹配 在控制台的Management菜单配置如下正则匹配： 5、收集系统日志 1）先修改配置文件 vim /etc/logstash/conf.d/system.conf input { file { path => "/var/log/messages" type => "systemlog" start_position => "beginning" stat_interval => "2" } } output { elasticsearch { hosts => ["10.1.2.184:9200"] index =>