精华内容
下载资源
问答
  • 2018-08-13 13:32:17

    Eventlog Analyzer日志管理系统、日志分析工具、日志服务器的功能及作用

        Eventlog Analyzer是用来分析和审计系统及事件日志的管理软件,能够对全网范围内的主机、服务器、网络设备、数据库以及各种应用服务系统等产生的日志,进行全面收集和细致分析,通过统一的控制台进行实时可视化的呈现。

        通过定义日志筛选规则和策略,帮助IT管理员从海量日志数据中精确查找关键有用的事件数据,准确定位网络故障并提前识别安全威胁,从而降低系统宕机时间、提升网络性能、保障企业网络安全。

    一、日志管理
    保障网络安全
    Windows系统日志分析
    Syslog日志分析
    应用程序日志分析
    Windows终端服务器日志监控
    Syslog服务器
    通用日志解析 & 索引(ULPI)技术
    事件日志监控
    云设施日志监控
    数据库审计

    应用程序日志分析
    监控和分析应用日志
    IIS Web服务器日志分析
    IIS FTP服务器日志分析
    DHCP Windows应用日志分析
    DHCP Linux应用日志分析
    MS SQL数据库日志分析
    Oracle数据库日志分析
    Apache Web服务器日志分析
    打印机服务器日志分析

    IT合规性审计报表
    满足合规性审计需要
    合规性审计
    PCI合规性报表
    ISO 27001合规性报表
    FISMA合规性报表
    HIPAA合规性报表
    SOX合规性报表
    GLBA合规性报表
    新法规合规性报表
    自定义合规性报表

    系统与用户监控日志报表
    及时了解事件活动
    内建报表
    自定义报表
    微软IIS服务器日志报表
    IBM AS/400日志报表
    VMware服务器日志报表
    活动目录日志报表
    特权用户监控报表
    用户会话监控
    事件日志监控 - 问答报表
    历史事件趋势
    搜索结果报表

    安全信息管理
    管理网络安全信息
    无代理的采集日志方式
    基于代理的采集日志方式
    日志搜索
    日志分析
    日志归档
    日志取证
    日志导入
    用户认证

    安全管理服务提供商(MSSP)
    适用于MSSP的日志管理方案
    操控板与用户视图
    个性化界面

    安全信息和事件管理(SIEM)
    全面保证网络及IT安全
    实时事件关联
    安全日志管理
    服务器日志管理
    日志管理
    文件完整性监控
    安全信息和事件管理(SIEM)

    告警与通知
    及时发现网络故障问题
    实时告警
    邮件、短信通知或运行程序

    集成第三方工具
    扩展管理
    EventLog Analyzer API

    更多相关内容
  • 日志管理系统

    万次阅读 2019-06-26 11:47:19
    为什么需要日志管理系统 保留现场 自知者自明 所有即将发生的,都取决于已经发生的 数据商业化运作 1.1 日志管理系统的解决方案 机器上的日志实时收集,存储到日志中心 给日志建立索引,通过索引能很快找到...

    一.为什么需要日志管理系统

    1. 保留现场
    2. 自知者自明
    3. 所有即将发生的,都取决于已经发生的
    4. 数据商业化运作

    1.1 日志管理系统的解决方案

    1. 机器上的日志实时收集,存储到日志中心
    2. 给日志建立索引,通过索引能很快找到日志
    3. 架设web界面,在web上完成日志的搜索

    1.2 日志管理系统的困难

    1. 日志量很大,每天几十亿条
    2. 日志的实时收集,延迟控制在分钟级别
    3. 能够在线水平扩展

    1.3 业内解决方案-ELK

         ELK 不是一款软件,而是 Elasticsearch、Logstash 和 Kibana 三种软件产品的首字母缩写:

    • Elasticsearch:分布式搜索和分析引擎,具有高可伸缩、高可靠和易管理等特点。基于 Apache Lucene 构建,能对大容量的数据进行接近实时的存储、搜索和分析操作。通常被用作某些应用的基础搜索引擎,使其具有复杂的搜索功能

    • Logstash:数据收集引擎。它支持动态的从各种数据源搜集数据,并对数据进行过滤、分析、丰富、统一格式等操作,然后存储到用户指定的位置

    • Kibana:数据分析和可视化平台。通常与 Elasticsearch 配合使用,对其中数据进行搜索、分析和以统计图表的方式展示

    1.3.1 简单ELK架构

          把一个 Logstash 数据搜集节点扩展到多个,分布于多台机器,将解析好的数据发送到 Elasticsearch server 进行存储,最后在 Kibana 查询、生成日志报表等 。

    1.3.2 引入消息队列的ELK架构

          使用 Logstash 从各个数据源搜集数据,然后经消息队列输出插件输出到消息队列中。目前 Logstash 支持 Kafka、Redis、RabbitMQ 等常见消息队列。然后 Logstash 通过消息队列输入插件从队列中获取数据,分析过滤后经输出插件发送到 Elasticsearch,最后通过 Kibana 展示。

    1.3.3 ELK方案的问题

    • 运维成本高,每增加一个日志收集,需要手动修改配置
    • 监控缺失,无法准确获取Logstash的状态二. 日志管理系统架构

    二. 日志收集系统架构

    2.1 组件介绍

    •  Log Agent:日志收集客户端,用来收集服务器上的日志
    •  Kafka:基于zookeeper协调的高吞吐量的分布式队列
    •  ES:elasticsearch,开源的分布式搜索引擎,给文档建立索引
    •  Hadoop:分布式计算框架,能够对大量数据进行分布式处理的平台

    2.2.1 日志采集工具介绍

                                                                Logstash

    优势:

           Logstash 主要的有点就是它的灵活性,主要因为它有很多插件,详细的文档以及直白的配置格式让它可以在多种场景下应用。我们基本上可以在网上找到很多资源,几乎可以处理任何问题。

    劣势:

            Logstash 致命的问题是它的性能以及资源消耗(默认的堆大小是 1GB)。尽管它的性能在近几年已经有很大提升,与它的替代者们相比还是要慢很多的。这里有 Logstash 与 rsyslog 性能对比以及Logstash 与 filebeat 的性能对比。它在大数据量的情况下会是个问题。另一个问题是它目前不支持缓存,目前的典型替代方案是将 Redis 或 Kafka 作为中心缓冲池:

    典型应用场景:

           因为 Logstash 自身的灵活性以及网络上丰富的资料,Logstash 适用于原型验证阶段使用,或者解析非常的复杂的时候。在不考虑服务器资源的情况下,如果服务器的性能足够好,我们也可以为每台服务器安装 Logstash 。我们也不需要使用缓冲,因为文件自身就有缓冲的行为,而 Logstash 也会记住上次处理的位置。如果服务器性能较差,并不推荐为每个服务器安装 Logstash ,这样就需要一个轻量的日志传输工具,将数据从服务器端经由一个或多个 Logstash 中心服务器传输到 Elasticsearch:随着日志项目的推进,可能会因为性能或代价的问题,需要调整日志传输的方式(log shipper)。当判断 Logstash 的性能是否足够好时,重要的是对吞吐量的需求有着准确的估计,这也决定了需要为 Logstash 投入多少硬件资源。

                                                                 Filebeat

    优势:

           Filebeat 只是一个二进制文件没有任何依赖。它占用资源极少,尽管它还十分年轻,正式因为它简单,所以几乎没有什么可以出错的地方,所以它的可靠性还是很高的。它也为我们提供了很多可以调节的点,例如:它以何种方式搜索新的文件,以及当文件有一段时间没有发生变化时,何时选择关闭文件句柄。

    劣势:

          Filebeat 的应用范围十分有限,所以在某些场景下我们会碰到问题。例如,如果使用 Logstash 作为下游管道,我们同样会遇到性能问题。正因为如此,Filebeat 的范围在扩大。开始时,它只能将日志发送到 Logstash 和 Elasticsearch,而现在它可以将日志发送给 Kafka 和 Redis,在 5.x 版本中,它还具备过滤的能力。

    典型应用场景:

          Filebeat 在解决某些特定的问题时:日志存于文件,我们希望将日志直接传输存储到 Elasticsearch。这仅在我们只是抓去(grep)它们或者日志是存于 JSON 格式(Filebeat 可以解析 JSON)。或者如果打算使用 Elasticsearch 的 Ingest 功能对日志进行解析和丰富。将日志发送到 Kafka/Redis。所以另外一个传输工具(例如,Logstash 或自定义的 Kafka 消费者)可以进一步丰富和转发。这里假设选择的下游传输工具能够满足我们对功能和性能的要求。

                                                                 Logagent

    优势:

           可以获取 /var/log 下的所有信息,解析各种格式(Elasticsearch,Solr,MongoDB,Apache HTTPD等等),它可以掩盖敏感的数据信息,例如,个人验证信息(PII),出生年月日,信用卡号码,等等。它还可以基于 IP 做 GeoIP 丰富地理位置信息(例如,access logs)。同样,它轻量又快速,可以将其置入任何日志块中。在新的 2.0 版本中,它以第三方 node.js 模块化方式增加了支持对输入输出的处理插件。重要的是 Logagent 有本地缓冲,所以不像 Logstash ,在数据传输目的地不可用时会丢失日志。

    劣势:

          尽管 Logagent 有些比较有意思的功能(例如,接收 Heroku 或 CloudFoundry 日志),但是它并没有 Logstash 灵活。

    典型应用场景:

          Logagent 作为一个可以做所有事情的传输工具是值得选择的(提取、解析、缓冲和传输)。

     

                                                            tailf示例:

    package main
    
    import (
    	"fmt"
    	"github.com/hpcloud/tail"
    	"time"
    )
    func main() {
    	filename := "./my.log"
    	tails, err := tail.TailFile(filename, tail.Config{
    		ReOpen:    true,
    		Follow:    true,
    		Location:  &tail.SeekInfo{Offset: 0, Whence: 2},
    		MustExist: false,
    		Poll:      true,
    	})
    	if err != nil {
    		fmt.Println("tail file err:", err)
    		return
    	}
    	var msg *tail.Line
    	var ok bool
    	for true {
    		msg, ok = <-tails.Lines
    		if !ok {
    			fmt.Printf("tail file close reopen, filename:%s\n", tails.Filename)
    			time.Sleep(100 * time.Millisecond)
    			continue
    		}
    		fmt.Println("msg:", msg)
    	}
    }
    

    2.2.2 Kafka介绍

    介绍:

            Kafka是最初由Linkedin公司开发,是一个分布式、支持分区的(partition)、多副本的(replica),基于zookeeper协调的分布式消息系统,它的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎,web/nginx日志、访问日志,消息服务等等,用scala语言编写,Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。

    Kafka的特性:

           高吞吐量、低延迟:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒,每个topic可以分多个partition, consumer group 对partition进行consume操作。

    • 可扩展性:kafka集群支持热扩展
    • 持久性、可靠性:消息被持久化到本地磁盘,并且支持数据备份防止数据丢失
    • 容错性:允许集群中节点失败(若副本数量为n,则允许n-1个节点失败)
    • 高并发:支持数千个客户端同时读写

    Kafka的应用场景:

    • 异步处理:把非关键流程异步化,提高系统的响应时间和健壮性

     

    • 应用解耦:通过消息队列

    • 流量削峰:缓存消息

     

    Kafka的原理:

            两个服务器Kafka群集,托管四个分区(P0-P3),包含两个使用者组。消费者组A有两个消费者实例,B组有四个消费者实例。每个实例(server)成为broker。无论是kafka集群,还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息。

     

     

          一个Topic可以认为是一类消息,每个topic将被分成多个partition(区),每个partition在存储层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部,每条消息在文件中的位置称为offset(偏移量),offset为一个long型数字,它是唯一标记一条消息。它唯一的标记一条消息。kafka并没有提供其他额外的索引机制来存储offset,因为在kafka中几乎不允许对消息进行“随机读写”。

    Kafka使用示例:

    package main
    
    import (
    	"fmt"
    	"github.com/Shopify/sarama"
    )
    
    func main() {
    	config := sarama.NewConfig()
    	config.Producer.RequiredAcks = sarama.WaitForAll
    	config.Producer.Partitioner = sarama.NewRandomPartitioner
    	config.Producer.Return.Successes = true
    
    	msg := &sarama.ProducerMessage{}
    	msg.Topic = "nginx_log"
    	msg.Value = sarama.StringEncoder("this is a good test, my message is good")
    
    	client, err := sarama.NewSyncProducer([]string{"192.168.31.177:9092"}, config)
    	if err != nil {
    		fmt.Println("producer close, err:", err)
    		return
    	}
    
    	defer client.Close()
    
    	pid, offset, err := client.SendMessage(msg)
    	if err != nil {
    		fmt.Println("send message failed,", err)
    		return
    	}
    
    	fmt.Printf("pid:%v offset:%v\n", pid, offset)
    }
    

    2.2.3 Elasticsearch介绍

    介绍:

            Elasticsearch(ES)是一个基于Lucene构建的开源、分布式、RESTful接口的全文搜索引擎。Elasticsearch还是一个分布式文档数据库,其中每个字段均可被索引,而且每个字段的数据均可被搜索,ES能够横向扩展至数以百计的服务器存储以及处理PB级的数据。可以在极短的时间内存储、搜索和分析大量的数据。

    Near Realtime(NRT) 几乎实时

    Elasticsearch是一个几乎实时的搜索平台。意思是,从索引一个文档到这个文档可被搜索只需要一点点的延迟,这个时间一般为毫秒级。

    Cluster 集群

           群集是一个或多个节点(服务器)的集合, 这些节点共同保存整个数据,并在所有节点上提供联合索引和搜索功能。一个集群由一个唯一集群ID确定,并指定一个集群名(默认为“elasticsearch”)。该集群名非常重要,因为节点可以通过这个集群名加入群集,一个节点只能是群集的一部分。

           确保在不同的环境中不要使用相同的群集名称,否则可能会导致连接错误的群集节点。例如,你可以使用logging-dev、logging-stage、logging-prod分别为开发、阶段产品、生产集群做记录。

    Node节点

          节点是单个服务器实例,它是群集的一部分,可以存储数据,并参与群集的索引和搜索功能。就像一个集群,节点的名称默认为一个随机的通用唯一标识符(UUID),确定在启动时分配给该节点。如果不希望默认,可以定义任何节点名。这个名字对管理很重要,目的是要确定你的网络服务器对应于你的ElasticSearch群集节点。

           我们可以通过群集名配置节点以连接特定的群集。默认情况下,每个节点设置加入名为“elasticSearch”的集群。这意味着如果你启动多个节点在网络上,假设他们能发现彼此都会自动形成和加入一个名为“elasticsearch”的集群。

          在单个群集中,您可以拥有尽可能多的节点。此外,如果“elasticsearch”在同一个网络中,没有其他节点正在运行,从单个节点的默认情况下会形成一个新的单节点名为"elasticsearch"的集群。

    Index索引

           索引是具有相似特性的文档集合。例如,可以为客户数据提供索引,为产品目录建立另一个索引,以及为订单数据建立另一个索引。索引由名称(必须全部为小写)标识,该名称用于在对其中的文档执行索引、搜索、更新和删除操作时引用索引。在单个群集中,您可以定义尽可能多的索引。

    Type类型

           在索引中,可以定义一个或多个类型。类型是索引的逻辑类别/分区,其语义完全取决于您。一般来说,类型定义为具有公共字段集的文档。例如,假设你运行一个博客平台,并将所有数据存储在一个索引中。在这个索引中,您可以为用户数据定义一种类型,为博客数据定义另一种类型,以及为注释数据定义另一类型。

     Document文档

          文档是可以被索引的信息的基本单位。例如,您可以为单个客户提供一个文档,单个产品提供另一个文档,以及单个订单提供另一个文档。本文件的表示形式为JSON(JavaScript Object Notation)格式,这是一种非常普遍的互联网数据交换格式。在索引/类型中,您可以存储尽可能多的文档。请注意,尽管文档物理驻留在索引中,文档实际上必须索引或分配到索引中的类型。

    Shards & Replicas分片与副本

           索引可以存储大量的数据,这些数据可能超过单个节点的硬件限制。例如,十亿个文件占用磁盘空间1TB的单指标可能不适合对单个节点的磁盘或可能太慢服务仅从单个节点的搜索请求。为了解决这一问题,Elasticsearch提供细分你的指标分成多个块称为分片的能力。当你创建一个索引,你可以简单地定义你想要的分片数量。每个分片本身是一个全功能的、独立的“指数”,可以托管在集群中的任何节点。

    Shards分片的重要性主要体现在以下两个特征:

    • 分片允许您水平拆分或缩放内容的大小
    • 分片允许你分配和并行操作的碎片(可能在多个节点上)从而提高性能/吞吐量,这个机制中的碎片是分布式的以及其文件汇总到搜索请求是完全由ElasticSearch管理,对用户来说是透明的。

           在同一个集群网络或云环境上,故障是任何时候都会出现的,拥有一个故障转移机制以防分片和结点因为某些原因离线或消失是非常有用的,并且被强烈推荐。为此,Elasticsearch允许你创建一个或多个拷贝,你的索引分片进入所谓的副本或称作复制品的分片,简称Replicas。

    Replicas的重要性主要体现在以下两个特征:

    • 副本为分片或节点失败提供了高可用性。为此,需要注意的是,一个副本的分片不会分配在同一个节点作为原始的或主分片,副本是从主分片那里复制过来的。
    • 副本允许用户扩展你的搜索量或吞吐量,因为搜索可以在所有副本上并行执行。

     Elasticsearch代码示例:

    package main
    
    import (
    	"fmt"
    	elastic "gopkg.in/olivere/elastic.v2"
    )
    
    type Tweet struct {
    	User    string
    	Message string
    }
    
    func main() {
    	client, err := elastic.NewClient(elastic.SetSniff(false), elastic.SetURL("http://192.168.31.177:9200/"))
    	if err != nil {
    		fmt.Println("connect es error", err)
    		return
    	}
    
    	fmt.Println("conn es succ")
    
    	tweet := Tweet{User: "olivere", Message: "Take Five"}
    	_, err = client.Index().
    		Index("twitter").
    		Type("tweet").
    		Id("1").
    		BodyJson(tweet).
    		Do()
    	if err != nil {
    		// Handle error
    		panic(err)
    		return
    	}
    
    	fmt.Println("insert succ")
    }
    

     

    展开全文
  • 1. 为什么需要集中的日志系统? 在分布式系统中,众多服务分散部署在数十台甚至是上百台不同的服务器上,要想快速方便的实现查找、分析和归档等功能,使用Linux命令等传统的方式查询到想要的日志就费时费力,更不要...

    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的方案,发现有几个缺点:

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

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

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

    对比图
    GraylogELKLoki
    Graylog是一个强大的平台,基于Scala语言开发。使用它能很容易对结构化和非结构化日志进行管理以及调试应用程序。它依赖Elasticsearch和MongoDB。Graylog的主服务从客户端节点获取数据,同时还提供Web接口,方便用户可视化聚合来的日志。
    Graylog的优点包括以下方面:
    1.免费的开源工具
    2.相比ELK更优秀的报警功能
    3.更好的交互,通过跟踪Graylog收到的错误堆栈,工程师可以了解源代码中的上下文。这大量节省了排错的时间和精力
    4.强大的搜索功能,支持TB级别的查询
    5.有归档功能,超过30天的所有内容都可以存储在廉价存储中,在出现查询需求时,可以重新导入到Graylog
    6.Python库支持
    目前,最著名的开源日志管理解决方案应该是ELK Stack,之所以称为Stack,是因为它不是一个软件包,而是由同一个团队开发的开源工具组合:Elasticsearch、Logstash、Kibana、及周边工具。
    Elasticsearch:是一个非常强大和高度可伸缩的搜索引擎,可以存储大量数据并作为集群使用。在ELK Stack中主要存储收集来的日志,并根据设置的索引,进行日志检索。
    Logstash:具有许多功能的日志转发器。支持多种类型的输入、过滤和输出。此外,Logstash可以处理许多编解码器,例如Json。
    Kibana:用户界面,可以查看日志条目、创建炫酷的仪表盘。
    ELK Stack的优点:
    1.成名更早
    2.知名度更高

    Loki具有下面的一些特性:

    • 不对日志进行全文索引。Loki中存储的是压缩后的非结构化日志,并且只对元数据建立索引,因此Loki 具有操作简单、低成本的优势。
    • 使用与 Prometheus 相同的标签。Loki通过标签对日志进行索引和分组,这使得日志的扩展和操作效率更高。
    • 特别适合储存 Kubernetes Pod 日志。诸如 Pod 标签之类的元数据会被自动删除和编入索引。
    • Grafana 原生支持。

    Loki 日志系统由以下3个部分组成:

    • loki是主服务器,负责存储日志和处理查询。
    • promtail是专为loki定制的代理,负责收集日志并将其发送给 loki 。
    • Grafana用于 UI展示。

    【本文未完待续……敬请后期作者空了贴详细比较!】

    总结


    虽然两种解决方案在功能上非常相似,但仍有一些差异需要考虑。
    两者之间最重要的区别在于,从一开始,Graylog就定位为强大的日志解决方案,而ELK则是大数据解决方案。 Graylog可以通过网络协议直接从应用程序接收结构化日志和标准syslog。相反,ELK是使用Logstash分析已收集的纯文本日志的解决方案,然后解析并将它们传递给ElasticSearch。
    在ELK中,Kibana扮演仪表盘的角色并显示从Logstash收到的数据。Graylog在这点上更方便,因为它提供了单一应用程序解决方案(不包括ElasticSearch作为灵活的数据存储),具有几乎相同的功能。因此,部署所需的时间更短。此外,与ELK相比,Graylog开箱即用,且具有出色的权限系统,而Kibana则不具备此功能。作为Elasticsearch的粉丝,我更喜欢Graylog而不是ELK,因为它完全符合我在日志管理方面的需求。
    Graylog具有直观的GUI,并提供警报、报告和自定义分析功能。最重要的是,它能在多个日志源和跨机房收集数TB的数据。基于这些优势,我更喜欢用Graylog而不是另一个具有类似功能的流行堆栈——ELK。

     

    展开全文
  • elk日志管理系统搭建

    万次阅读 2019-11-12 15:58:06
    简介 ELK是指Elasticsearch、Logstash、Kibana的简称 Elasticsearch : 实时全文搜索和分析...它支持几乎任何类型的日志,包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志,这些来源包括 sysl...

    简介

    ELK是指Elasticsearch、Logstash、Kibana的简称

    Elasticsearch : 实时全文搜索和分析引擎,提供搜集、分析、存储数据三大功能, 构建于Apache Lucene搜索引擎库之上。

    Logstash: 一个用来搜集、分析、过滤日志的工具。它支持几乎任何类型的日志,包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志,这些来源包括 syslog、消息传递(例如 RabbitMQ)和JMX,它能够以多种方式输出数据,包括电子邮件、websockets和Elasticsearch。

    Kibana: 一个基于Web的图形界面,用于搜索、分析和可视化存储在 Elasticsearch指标中的日志数据。它利用Elasticsearch的REST接口来检索数据,不仅允许用户创建他们自己的数据的定制仪表板视图,还允许他们以特殊的方式查询和过滤数据

    环境

    系统: centos7
    JDK: 1.8
    三个二进制安装包下载地址:
    https://download.csdn.net/download/zhaosongbin/11974259


    jdk 安装

    安装方法: https://zhaosongbin.blog.csdn.net/article/details/87927937

    elasticsearch

    安装

    mkdir elasticsearch
    cd elasticsearch
    wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.4.2-linux-x86_64.tar.gz
    tar -zxvf elasticsearch-7.4.2-linux-x86_64.tar.gz
    

    启动

    注意
    不可使用root启动,否则会报以下错误
    can not run elasticsearch as root

    [root@erk bin]# ./elasticsearch
    future versions of Elasticsearch will require Java 11; your Java version from [/usr/local/jdk1.8.0_211/jre] does not meet this requirement
    [2019-11-12T17:37:39,170][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] [gk-erk] uncaught exception in thread [main]
    org.elasticsearch.bootstrap.StartupException: java.lang.RuntimeException: can not run elasticsearch as root
    	at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:163) ~[elasticsearch-7.4.2.jar:7.4.2]
    	at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:150) ~[elasticsearch-7.4.2.jar:7.4.2]
    	at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86) ~[elasticsearch-7.4.2.jar:7.4.2]
    	at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:125) ~[elasticsearch-cli-7.4.2.jar:7.4.2]
    	at org.elasticsearch.cli.Command.main(Command.java:90) ~[elasticsearch-cli-7.4.2.jar:7.4.2]
    	at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:115) ~[elasticsearch-7.4.2.jar:7.4.2]
    	at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:92) ~[elasticsearch-7.4.2.jar:7.4.2]
    Caused by: java.lang.RuntimeException: can not run elasticsearch as root
    	at org.elasticsearch.bootstrap.Bootstrap.initializeNatives(Bootstrap.java:105) ~[elasticsearch-7.4.2.jar:7.4.2]
    	at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:172) ~[elasticsearch-7.4.2.jar:7.4.2]
    	at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:349) ~[elasticsearch-7.4.2.jar:7.4.2]
    	at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:159) ~[elasticsearch-7.4.2.jar:7.4.2]
    	... 6 more
    

    添加用户和组 elk

    groupadd elk
    useradd -g elk elk
    

    切换目录所属的用户组和用户

    cd /home/elasticsearch
    chgrp elk elasticsearch-7.4.2 -R
    chown elk elasticsearch-7.4.2 -R
    

    切换用户elk,然后启动

    su elk
    cd /home/elasticsearch/elasticsearch-7.4.2/bin/
    ./elasticsearch
    

    服务器外部访问修改配置文件==elasticsearch.yml==
    cd ../config/
    pwd
    /home/elasticsearch/elasticsearch-7.4.2/config
    vim elasticsearch.yml
    

    #network.host: 192.168.0.1
    network.host: 192.168.1.1

    #@discovery.seed_hosts: [“host1”, “host2”]
    discovery.seed_hosts: [“192.168.1.1”, “[::1]”]

    此时启动会报错

    ERROR: [2] bootstrap checks failed
    [1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]
    [2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
    

    vm.max_map_count 表示虚拟内存大小,它是一个内核参数。elasticsearch 默认要求 不低于 262144
    nofile 表示进程允许打开的最大文件数。elasticsearch 进程要求可以打开的最大文件数不低于 65536
    我们需要修改服务器内容,先切换到root用户

    修改配置文件 /etc/sysctl.conf

    vm.max_map_count=655360
    

    修改配置文件 /etc/security/limits.conf

    * soft     nofile     65536
    * hard     nofile     131072
    * soft     nproc      2048
    * hard     nproc      4096
    

    修改后需要重启服务器

    然后重启服务

    su elk
    cd /home/elasticsearch/elasticsearch-7.4.2/bin/
    ./elasticsearch
    

    后台启动

    nohup ./elasticsearch &
    

    Logstash


    安装启动

    mkdir  /home/logstash
    cd /home/logstash
    wget https://artifacts.elastic.co/downloads/logstash/logstash-7.4.2.tar.gz
    tar -zxvf logstash-7.4.2.tar.gz
    cd logstash-7.4.2/
    

    修改配置

    开放http地址,用来接收服务发送来的日志

    vim /config/logstash-sample.conf
    
    # Sample Logstash configuration for creating a simple
    # Beats -> Logstash -> Elasticsearch pipeline.
    
    input {
      beats {
        port => 5044
      }
      
      tcp {
        # 这里其实把logstash作为服务,开启9250端口接收logback发出的消   
        host => "0.0.0.0" port => 9250 mode => "server" tags => ["tags"] codec => json_lines
      }
        
    }
    
    output {
      elasticsearch {
        hosts => ["http://192.168.1.1:9200"]
        index => "%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}"
        #user => "elastic"
        #password => "changeme"
      }
    }
    
    

    启动

    nohup bin/logstash -f config/logstash-sample.conf &
    

    Kibana

    解压安装

    mkdir /home/kibana/
    cd /home/kibana/
    wget https://artifacts.elastic.co/downloads/kibana/kibana-7.4.2-linux-x86_64.tar.gz
    tar -zxvf kibana-7.4.2-linux-x86_64.tar.gz
    

    修改配置

    Kibana 服务外部访问还需要修改下配置

    vim config/kibana.yml
    

    #server.host: “localhost”
    server.host: “192.168.1.1”

    #elasticsearch.hosts: [“http://localhost:9200”]
    elasticsearch.hosts: [“http://192.168.1.1:9200”]

    #i18n.locale: “en”
    i18n.locale: “zh-CN”


    启动

    注意Kibana不能使用root启动,否则会报错

    Kibana should not be run as root.  Use --allow-root to continue.
    

    切换目录所属的用户组和用户

    cd /home/kibana
    chgrp elk kibana-7.4.2-linux-x86_64 -R
    chown elk kibana-7.4.2-linux-x86_64 -R
    
    su elk
    cd /home/kibana/kibana-7.4.2-linux-x86_64
    nohup bin/kibana &
    

    kibana查看进程

    ps -ef |grep node
    

    访问地址
    http://192.168.1.1:5601

    展开全文
  • 日志管理和分析系统的设计与实现

    热门讨论 2009-03-31 15:46:17
    在 日志 管 理系统的设计和实现中首先分析了日志管理系统实现的常用技术,还详细 分析了日志格式一Windows操作系统事件日志、UNIX系统日志和通用防火墙日志。系统 通过采集、筛选分析法、特征匹配分析法、统计网络...
  • 管理系统的操作日志如何做成通用的模块一直是个让我头疼的问题,不过看了博客园里的某篇文章后,现在基本解决了。  相关文章链接:《系统操作日志设计》  在开始做之前,必须把两个日志分清楚,那就是普
  • 日志管理系统rsyslogd

    千次阅读 2020-03-01 09:57:52
    日志管理系统rsyslogd 什么是rsyslogd rsyslogd是一个进程,是一个日志服务,我们可以通过rpm -qc查询软件包的方式来查看 [root@localhost ~]# rpm -qc rsyslog /etc/logrotate.d/syslog /etc/rsyslog.conf /etc/...
  • 日志分析工具、日志管理系统、syslog分析  系统日志(Syslog)管理是几乎所有企业的重要需求。系统管理员将syslog看作是解决网络上系统日志支持的系统和设备性能问题的关键资源。人们往往低估了对完整的sys­log...
  • 系统日志管理

    万次阅读 2018-07-28 15:47:59
    1.rsyslog 此服务是用来采集系统日志的,不产生日志,只是起到采集作用 2 .rsyslog的管理 /var/log/messages 采集服务信息日志 /var/log/secure 采集系统登陆日志 /var/log/cron 采集定时任务日志 /var/log/...
  • 系统日志管理

    万次阅读 2017-02-22 10:19:47
    我们可以使用日志系统所记录的信息为系统进行排错,优化系统的性能,或者根据这些信息调整系统的行为。 收集你想要的数据,分析出有价值的信息,可以提高系统、产品的安全性,可以帮助开发完善代码,优化产品。 ...
  • Java系统日志管理

    万次阅读 2018-07-06 15:24:06
    在一个系统日志管理是一个很重要的部分,因为当系统发布到线网后出了问题只能看系统日志了,这个时候系统日志起到了一个错误排查功能,同时也可以通过系统日志统计用户吞吐量等等,总之系统日志是系统管理一个重点...
  • 日志管理系统之保存日志到数据库

    万次阅读 2016-10-24 17:14:14
    Web项目可以通过log4j logback等技术实现保存访问日志到本地文件中,但是会在一些特殊的需求中会让我们保存用户访问日志到数据库中,此时我们可以通过拦截器来实现访问日志的保存。 目录 保存Web访问日志到数据库 ...
  • 有能力的运维团队能够搭建一个日志监控和管理系统,来应对系统故障或应用程序的怪异行为。 为什么日志记录如此重要? 当系统崩溃或应用程序出现故障时,有时需要了解问题真相并找出故障原因。日志文件记录系统活动...
  • 安装测试环境:Ubuntu 16.04.2 LTS前言(1)ELK是Elasticsearch,Logstash,Kibana 开源软件的集合,对外是作为一个日志管理系统的开源方案。它可以从任何来源,任何格式进行日志搜索,分析获取数据,并实时进行展示...
  • 学生信息管理系统模板(静态页面)

    千次下载 热门讨论 2015-03-18 14:57:56
    一个很好的学生信息管理系统模板(静态页面)非常好的一个资源 是一个模板,可以自己改为自己想要的页面、功能 内容如下: 个人中心 --我的信息 --班级信息 --短信息 --学院通知 教务中心 --我的报考 --我的成绩 --...
  • 最佳日志管理工具:51个有用的日志管理、监视、分析等工具 痛苦的纯文本日志管理日子一去不复返了。虽然纯文本数据在某些情况下仍然很有用,但是在进行扩展分析以收集有洞察力的基础设施数据并改进代码质量时,寻找...
  • 日志管理方法及系统

    万次阅读 2016-01-16 11:44:06
    本发明涉及应用系统日志管理技术领域,提供了一种日志管理方法和系统,所述方法包括如下步骤:S1:初始化系统业务功能列表和业务功能方法列表;S2:将业务操作中的具体操作信息与系统日志表和历史数据日志表直接相...
  • 集中化Linux日志管理系统

    千次阅读 2014-03-25 14:30:20
    笔者 工作中 负责 着 60 多 台Linux服务器的运维管理工作, 初期 每台机器日志的巡查,是一件...目前这套系统已经投入到我们的生产环境, 实践证明 效果 良好, 大大提高了运维工作中日志检查效率 。 
  • 企业系统操作日志的分析处理,
  • springboot核心技术之日志管理(三)

    千次阅读 2019-03-14 22:39:56
    一、常见的日志框架 常见日志框架:JUL、JCL、Log4j、Log4j2,Logback、SLF4j、Jboss-logging 日志门面(日志的抽象) 日志实现 JCL(Jakarta Commons Logging) SLF4j(Simple Logging Facade for ...
  • 上一篇:Linux操作系统安装ELK stack日志管理系统–(1)Logstash和Filebeat的安装与使用上一篇介绍了Logstash和Filebeat的安装,以及使用Filebeat作为Logstash输入进行数据的获取,接下来将学习一下Elasticsearch与...
  • 全栈工程师开发手册 (作者:栾鹏) python教程全解 ...django使用python内建的logging模块去建造自己的系统日志的,如果你想详细了解这个模块的话,请自己去看python的说明文档,这里仅仅介绍d...
  • LeetCode 635. 设计日志存储系统(map)

    千次阅读 2020-07-21 20:14:56
    文章目录1. 题目2. 解题 1. 题目 你将获得多条日志,每条日志都有唯一的 id 和 timestamp,...void Put(int id, string timestamp):给定日志的 id 和 timestamp,将这个日志存入你的存储系统中。 int[] Retrieve
  • 通过应用和系统日志可以了解Kubernetes集群内所发生的事情,对于调试问题和监视集群活动来说日志非常有用。对于大部分的应用来说,都会具有某种日志机制。因此,大多数容器引擎同样被设计成支持某种日志机制。对于...
  • Laravel-日志管理

    万次阅读 2017-08-14 15:04:59
    Laravel 集成了 Monolog 日志函数库,Monolog 支持和提供多种强大的日志处理功能。 1、设置,日志模式 Laravel 提供可立即使用的 single、daily、syslog 和 errorlog 日志模式。例如,如果你想要每天保存一...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 792,405
精华内容 316,962
关键字:

日志管理系统

友情链接: 展厅监控分布.zip