ELKStack-使用消息队列扩展

ELKStack-使用消息队列扩展

官方文档:https://www.elastic.co/guide/en/logstash/5.x/deploying-and-scaling.html

流程图

流程:数据源 --> logstash(input收集、output消息队列) -->  MQ  -->  logstash (input收集消息队列、filter过滤、output ES) --> ES

使用这个流程,主要是基于性能考虑,第一层logstash主要做原始数据收集,不对数据进行处理,提高对数据源的收集性能。同时部署第一层logstash需要放在生产环境的服务器上,做为agent端,这样使用也是基于尽量少消耗服务器性能的考量。

本章使用redis做消息队列

yum install -y redis

配置/etc/redis.conf

daemonize yes
bind 192.168.137.11

启动 systemctl start redis

logstash output redis使用

官方文档:https://www.elastic.co/guide/en/logstash/5.x/plugins-outputs-redis.html

1、标准输入、redis输出

input {
    stdin {}
}

filter {
}

output{
    redis {
        host => ["192.168.137.11"]
        port => 6379
        db => 1
        data_type => "list"
        key => "demo"
        timeout => 10
    }
}

启动/opt/logstash/bin/logstash -f /etc/logstash/conf.d/redis.conf

2、apache日志输入,redis输出

input {
    file {
        path => "/etc/httpd/logs/access_log"
        start_position => "beginning"
    }
}

filter {
}

output{
    redis {
        host => ["192.168.137.11"]
        port => 6379
        db => 1
        data_type => "list"
        key => "apache"
        timeout => 10
    }
}

启动/opt/logstash/bin/logstash -f /etc/logstash/conf.d/apache.conf

时间: 2024-10-13 09:32:21

ELKStack-使用消息队列扩展的相关文章

ELKStack之消息队列

redis消息队列 安装redis yum -y install redis 修改配置文件 修改ip 后台运行 启动 systemctl start redis 查看 lsof -i:6379 连接 redis-cli -h 10.13.85.9 cd /etc/logstash/conf.d/ vim redis.conf input{ stdin {} } output{ redis{ host => "10.13.85.9" port => "6379&qu

系统可扩展设计方法之消息队列

消息队列在现在各种系统中都有广泛的应用,除非你做的就是一个单独的工具或小软件, 否则稍大点的系统都会用到消息队列,它对系统的可扩展性很重要.它基于这样的事实,如果系统的各个模块之间的协作不是通过直接的调用关系来实现的,那么系统的可扩展性就一定会更好. 系统各个模块之间只是通过消息队列来传输事件消息,而各模块之间并没有直接的调用关系.保持松散的耦合关系. 事件驱动架构最典型的一个应用就是操作系统中常见的生产者和消费者模式,将其应用到网站设计中就是分布式消息队列. 分布式消息队列同样采用了生产者和消

Asp.net 面向接口可扩展框架之消息队列组件

消息队列对大多数人应该比较陌生.但是要提到MQ听说过的人会多很多.MQ就是英文单词"Message queue"的缩写,翻译成中文就是消息队列(我英语差,翻译错了请告知). PS:话说国人熟悉MQ比消息队列多,是不是因为国人的外语水平高于国语水平好几个数量级 1.看一下度娘怎么解释消息队列 参考链接:消息队列_百度百科 度娘解释消息队列是在两台计算机间传输的,套句很时髦的说法就是用来做分布式传输的,是个很高大上的东西 2.我的看法稍有不同 我更追溯到“消息队列”的字面“本源”的意思.我

thinkphp5 消息队列thinkphp-queue扩展

1.简介 thinkphp-queue是thinkphp的一个第三方扩展, 内置了 Redis,Database,Topthink ,Sync这四种驱动,推荐使用redis 2. 下载 和安装 composer require topthink/think-queue 配置目录在: application/extra/queue.php return [ 'connector' => 'Redis', // Redis 驱动 'expire' => 60, // 任务的过期时间,默认为60秒;

使用.NET Core搭建分布式音频效果处理服务(五)利用消息队列提升水平扩展灵活性

消息队列 神马是消息队列,看看某度的原话“在项目中,将一些无需即时返回且耗时的操作提取出来,进行了异步处理,而这种异步处理的方式大大的节省了服务器的请求响应时间,从而提高了系统的吞吐量”. 其实消息队列还可以用于解耦,在多层项目模型或中型项目以上,都会用到消息队列,减少层与层之间的耦合:还可以做跨进程间的通讯(传输率显然比不上RPC). 上一节说道最终需要采用消息队列来进行分离前级和后级,并且采用异步方式,用于提高业务服务器的吞吐率,不过,虽然分离了,如果后级服务器的处理能力达不到请求数或接近平

EQueue - 一个纯C#写的分布式消息队列介绍2

一年前,当我第一次开发完EQueue后,写过一篇文章介绍了其整体架构,做这个框架的背景,以及架构中的所有基本概念.通过那篇文章,大家可以对EQueue有一个基本的了解.经过了1年多的完善,EQueue无论是功能上还是成熟性上都完善了不少.所以,希望再写一篇文章,介绍一下EQueue的整体架构和关键特性. EQueue架构 EQueue是一个分布式的.轻量级.高性能.具有一定可靠性,纯C#编写的消息队列,支持消费者集群消费模式. 主要包括三个部分:producer, broker, consume

C#分布式消息队列 EQueue 2.0 发布啦

前言 最近花了我几个月的业余时间,对EQueue做了一个重大的改造,消息持久化采用本地写文件的方式.到现在为止,总算完成了,所以第一时间写文章分享给大家这段时间我所积累的一些成果. EQueue开源地址:https://github.com/tangxuehua/equeue EQueue相关文档:http://www.cnblogs.com/netfocus/category/598000.html EQueue Nuget地址:http://www.nuget.org/packages/eq

使用消息队列的理由

对任何架构或应用来说,消息队列都是一个至关重要的组件,下面是十个理由: 1. 解耦 在项目启动之初来预测将来项目会碰到什么需求,是极其困难的.消息队列在处理过程中间插入了一个隐含的.基于数据的接口层,两边的处理过程都要实现这一接口.这允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束. 2. 冗余 有时在处理数据的时候处理过程会失败.除非数据被持久化,否则将永远丢失.消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险.在被许多消息队列所采用的"插入-

消息队列

1.为什么需要消息队列?当系统中出现“生产“和“消费“的速度或稳定性等因素不一致的时候,就需要消息队列,作为抽象层,弥合双方的差异. 举个例子:业务系统触发短信发送申请,但短信发送模块速度跟不上,需要将来不及处理的消息暂存一下,缓冲压力. 再举个例子:调远程系统下订单成本较高,且因为网络等因素,不稳定,攒一批一起发送. 再举个栗子,交互模块5:00到24:00和电商系统联通,和内部ERP断开.1:00到4:00和ERP联通,和电商系统断开. 再举个例子,服务员点菜快,厨师做菜慢. 再举个例子,到