精华内容
下载资源
问答
  • 为了解决这些问题,故而开发了此款软件,该软件不仅解决了上述问题,而且还支持对日志文件进行离线分析和导出备份,支持对日志内容的横向过滤和纵向过滤,且可通过ADB工具直连物理设备进行日志的监控和分析,无需...
  • 基于Hbase的网站日志分析系统(附带web展示页面) 基于Hbase的网站日志分析系统(附带web展示页面)基于Hbase的网站日志分析系统(附带web展示页面)
  • 一款真正意义上的MSSQL日志分析和浏览工具,直接解析LDF文件,支持SQL2008,SQL2005,SQL2000. 程序主要功能: 1:\l日志浏览. 用户可以输入指定的日志块序号,程序从指定的日志块往下浏览,可以快速定位需要查看的...
  • c#log日志类和日志分析器(源码)

    热门讨论 2013-08-09 10:25:47
    c# 最简单的log功能和log查看分析器,可以直接在项目中使用,也可以修改源码成为你自己的日志功能某模块,供c#入门的同学学习和参考
  • 超详细 ELK 日志分析系统

    千次阅读 2021-01-07 10:53:45
    文章目录一、ELK日志分析系统简介1:ELK日志分析系统组成2:日志处理步骤二:三款软件简介1:Elasticsearch(1)Elasticsearch的概述(2)Elasticsearch核心概念2:Logstash(1)Logstash介绍(2)Logstash的主要...

    文章目录

    一、ELK日志分析系统简介

    ELK日志分析系统是Logstash、Elastcsearch、Kibana开源软件的集合,对外是作为一个日志管理系统的开源方案,它可以从任何来源、任何格式进行日志搜索、分析与可视化展示

    1:ELK日志分析系统组成

    • elasticsearch (es) :通过搭建群集;存储日志数据,索引日志数据
    • logstash :收集日志,收集到了后给es存储
    • kibana :视图形式展现日志信息,更加人性化

    2:日志处理步骤

    1. 将日志进行集中化管理
    2. 将日志格式化(Logstash)并输出到Elasticsearch
    3. 对格式化后的数据进行索引和存储(Elasticsearch)
    4. 前端数据的展示(Kibana)

    二:三款软件简介

    1:Elasticsearch

    (1)Elasticsearch的概述

    • 提供了一个分布式多用户能力的全文搜索引擎

    (2)Elasticsearch核心概念

    (1)接近实时(NRT)

    • elasticsearch是一个接近实时的搜索平台,这意味着,从索引一个文档直到这个文档能够被搜索到有一个轻微的延迟(通常是1秒)

    (2)集群(cluster)

    • 一个集群就是由一个或多个节点组织在一起,它们共同持有你整个的数据,并一起提供索引和搜索功能。其中一个节点为主节点,这个主节点是可以通过选举产生的,并提供跨节点的联合索引和搜索的功能。集群有一个唯一性标示的名字,默认是elasticsearch,集群名字很重要,每个节点是基于集群名字加入到其集群中的。因此,确保在不同环境中使用不同的集群名字。
    • —个集群可以只有一个节点。强烈建议在配置elasticsearch时,配置成集群模式。
    • es具有集群机制,节点通过集群名称加入到集群中,同时在集群中的节点会有一个自己的唯一身份标识(自己的名称)

    (3)节点(node)

    • 节点就是一台单一的服务器,是集群的一部分,存储数据并参与集群的索引和搜索功能。像集群一样,节点也是通过名字来标识,默认是在节点启动时随机分配的字符名。当然,你可以自己定义。该名字也很重要,在集群中用于识别服务器对应的节点。
    • 节点可以通过指定集群名字来加入到集群中。默认情况,每个节点被设置成加入到elasticsearch集群。如果启动了多个节点,假设能自动发现对方,他们将会自动组建一个名为elasticsearch的集群。

    (4)索引 (type)

    • 在一个索引中,你可以定义一种或多种类型。一个类型是你的索引的一个逻辑上的分类!分区,其语义完全由你来定。通常,会为具有一组共同字段的文档定义一个类型。比如说,我们假设你运营一个博客平台并且将你所有的数据存储到一个索引中。在这个索引中,你可以为用户数据定义一个类型,为博客数据定义另一个类型,当然,也可以为评论数据定义另一个类型。

    • 类型相对于关系型数据库的表 ——》索引(库)-》类型(表)-》文档(记录)

    (6)文档(document)

    • 一个文档是一个可被索引的基础信息单元。比如,你可以拥有某一个客户的文档,某一个产品的一个文档,当然,也可以拥有某个订单的一个文档。文档以SON
      (Javascript Object Notation))格式来表示,而JSON是一个到处存在的互联网数据交互格式。
    • 在一个index/type里面,只要你想,你可以存储任意多的文档。注意,虽然一个文档在物理上位于一个索引中,实际上一个文档必须在一个索引内被索引和分配一个类型。
    • 文档相对于关系型数据库的列。

    (7)分片和副本(shards & replicas)

    • 在实际情况下,索引存储的数据可能超过单个节点的硬件限制。如一个10亿文档需1TB空间可能不适合存储在单个节点的磁盘上或者从单个节点搜索请求太慢了。为了解决这个问题,elasticsearch提供将索引分成多个分片的功能。当在创建索引时,可以定义想要分片的数量。每一个分片就是一个全功能的独立的索引,可以位于集群中任何节点上。

    分片的两个最主要原因

    • a.水平分割扩展,增大存储量

    • b.分布式并行跨分片操作,提高性能和吞吐量

    分布式分片的机制和搜索请求的文档如何汇总完全是有elasticsearch控制的,这些对用户而言是透明的。

    网络问题等等其它问题可以在任何时候不期而至,为了健壮性,强烈建议要有一个故障切换机制,无论何种故障以防止分片或者节点不可用。为此,elasticsearch让我们将索引分片复制一份或多份,称之为分片副本或副本。

    副本也有两个最主要原因

    • a.高可用性,以应对分片或者节点故障。出于这个原因,分片副本要在不同的节点上。

    • b.×××能,增大吞吐量,搜索可以并行在所有副本上执行。

    2:Logstash

    (1)Logstash介绍

    • —款强大的数据处理工具
    • 可实现数据传输、格式处理、格式化输出
    • 数据输入(从业务输入)、数据加工(如过滤、改写等)以及数据输出(输出到Elasticsearch群集)

    (2)Logstash的主要组件

    • shipper:日志收集者,负责监控本地日志文件的变化,及时把日志文件的最新内容收集起来。通常,远程代理端(agent)只需要运行这个组件即可
    • indexer:日志存储者,负责接收日志并写入到本地文件
    • broker:日志hub,负责连接多个shipper和多个indexer
    • search and storage:允许对事件进行搜索和存储
    • web interface:基于wWeb的展示界面

    3:Kibana

    (1)Kibana介绍

    • 一个针对Elasticsearch的开源分析及可视化平台
    • 搜索、查看存储在Elasticsearch索引中的数据
    • 通过各种图表进行高级数据分析及展示

    (2)Kibana主要功能

    • Elasticsearch无缝之集成
    • 整合数据,复杂数据分析
    • 让更多团队成员受益
    • 接口灵活,分享更容易
    • 配置简单,可视化多数据源
    • 简单数据导出

    三:ELK日志分析系统部署

    1:拓扑图

    在这里插入图片描述

    2:实验环境

    3:部署步骤

    node1 节点配置

    3.1、3台服务器关闭防火墙

    [root@apache ~]# systemctl stop firewalld
    [root@apache ~]# setenforce 0

    3.2、3台服务器域名映射

    [root@apache ~]# vi /etc/hosts
    20.0.0.10   apache
    20.0.0.11   node1
    20.0.0.12   node2

    3.3、部署elasticsearch软件

    (1)安装elasticsearch-rpm包

    [root@node1 ~]# rpm -ivh elasticsearch-5.5.0.rpm 

    (2)加载系统服务

    [root@node1 ~]# systemctl daemon-reload                            # 守护进程重载,重新识别
    [root@node1 ~]# systemctl enable elasticsearch.service             # 开机自启动 

    3.4、更改elasticsearch主配置文件

    (1)拷贝文件备份

    [root@node1 ~]# cp /etc/elasticsearch/elasticsearch.yml /etc/elasticsearch/elasticsearch.yml.bak

    (2)修改配置文件

    [root@node1 ~]# vi /etc/elasticsearch/elasticsearch.yml
    cluster.name: my-elk-cluster                          # 17 集群名字
    node.name: node1                                      # 23 节点名字
    path.data: /data/elk_data                             # 33 数据存放路径,退出后需要单独创建
    path.logs: /var/log/elasticsearch                     # 37 日志存放路径
    bootstrap.memory_lock: false                          # 43 不在启动的时候锁定内存
    network.host: 0.0.0.0                                 # 55 提供服务绑定的IP地址,0.0.0.0代表所有地址
    http.port: 9200                                       # 59 侦听端口为9200
    discovery.zen.ping.unicast.hosts: ["node1", "node2"]  # 68 集群发现通过单播实现

    (3)过滤查看修改的配置

    [root@node1 ~]# grep -v "^#" /etc/elasticsearch/elasticsearch.yml
    cluster.name: my-elk-cluster
    node.name: node1
    path.data: /data/elk_data
    path.logs: /var/log/elasticsearch
    bootstrap.memory_lock: false
    network.host: 0.0.0.0
    http.port: 9200
    discovery.zen.ping.unicast.hosts: ["node1", "node2"]

    3.5、创建数据存放路径并授权

    [root@node1 ~]# mkdir -p /data/elk_data
    [root@node1 ~]# chown elasticsearch:elasticsearch /data/elk_data/ 

    3.6、启动elasticsearch是否成功开启

    [root@node1 ~]# systemctl start elasticsearch.service     # 启动慢
    [root@node1 ~]# netstat -anpt | grep 9200
    tcp6       0      0 :::9200                 :::*                    LISTEN      54502/java     

    3.7、查看节点信息,用谷歌浏览器查看

    在这里插入图片描述

    node2 节点配置

    1:与 node1 节点操作相同,只需更改 elasticsearch主配置文件的节点名字为 node2

    2:过滤查看修改的配置

    [root@node2 ~]# grep -v "^#" /etc/elasticsearch/elasticsearch.yml
    cluster.name: my-elk-cluster
    node.name: node2
    path.data: /data/elk_data
    path.logs: /var/log/elasticsearch
    bootstrap.memory_lock: false
    network.host: 0.0.0.0
    http.port: 9200
    discovery.zen.ping.unicast.hosts: ["node1", "node2"]

    3:查看节点信息,用谷歌浏览器查看
    在这里插入图片描述

    3.7、集群检查健康和状态

    (1)检查群集健康情况

    在这里插入图片描述
    (2)检查群集状态信息

    在这里插入图片描述

    3.8、安装elasticsearch-head插件

    上述查看集群的方式,及其不方便,我们可以通过安装elasticsearch-head插件后,来管理集群

    node1 节点与 node2 节点操作相同

    3.8.1、编译安装 node
    • 解压缩
    [root@node1 ~]# tar zxvf node-v8.2.1.tar.gz
    • 配置编译安装
    [root@node1 node-v8.2.1]# ./configure
    [root@node1 node-v8.2.1]# make && make install
    3.8.2、安装phantomjs 前端框架
    • 解压缩
    [root@node1 ~]# tar jxvf phantomjs-2.1.1-linux-x86_64.tar.bz2
    • 拷贝文件
    [root@node1 ~]# cp phantomjs-2.1.1-linux-x86_64/bin/phantomjs /usr/local/bin/
    3.8.3、安装 elasticsearch-head 数据可视化工具
    • 解压缩
    [root@node1 ~]# tar zxvf elasticsearch-head.tar.gz
    • 安装
    [root@node1 ~]# cd elasticsearch-head/
    [root@node1 elasticsearch-head]# npm install

    3.9、修改 elasticsearch 主配置文件

    [root@node1 ~]# vi /etc/elasticsearch/elasticsearch.yml            # 配置文件末尾添加
    http.cors.enabled: true                                # 开启跨域访问支持,默认为false
    http.cors.allow-origin: "*"                            # 跨域访问允许的域名地址    
    3.9.1、重新启动服务
    [root@node1 ~]# systemctl restart elasticsearch.service

    4.0、启动 elasticsearch-head 服务

    4.0.1、启动服务
    [root@node1 ~]# cd elasticsearch-head/
    [root@node1 elasticsearch-head]# npm run start &        # 切换到后台启动
    [1] 101339
    [root@node1 elasticsearch-head]# 
    > elasticsearch-head@0.0.0 start /root/elasticsearch-head
    > grunt server
    
    Running "connect:server" (connect) task
    Waiting forever...
    Started connect web server on http://localhost:9100
    4.0.2、查看状态
    [root@node1 ~]# netstat -anpt | grep 9100
    tcp        0      0 0.0.0.0:9100            0.0.0.0:*            LISTEN      101349/grunt        
    [root@node1 ~]# netstat -anpt | grep 9200
    tcp6       0      0 :::9200                 :::*                 LISTEN      101608/java

    4.1、谷歌浏览器登录查看

    4.1.1、登录前端框架

    在这里插入图片描述

    4.2、新建索引

    4.2.1、谷歌浏览器新建索引

    在这里插入图片描述

    4.2.2、node1 节点创建索引
    • 创建
    [root@node1 ~]# curl -XPUT 'localhost:9200/index-demo/test/1?pretty&pretty' -H 'content-Type: application/json' -d '{"user":"lisi","mesg":"hello world"}'
    • 完成
    {
      "_index" : "index-demo",             # 索引名称
      "_type" : "test",                    # 索引类型
      "_id" : "1",
      "_version" : 1,
      "result" : "created",                # 创建
      "_shards" : {
        "total" : 2,                       # 总量
        "successful" : 2,
        "failed" : 0
      },
      "created" : true
    }
    4.2.3、进入谷歌浏览器刷新

    在这里插入图片描述

    4.3、apache 服务器配置

    4.3.1、安装 apache 服务
    [root@apache ~]# yum -y install httpd
    4.3.2、开启 apache 服务
    [root@apache ~]# systemctl start httpd

    4.4、检查 java 环境

    [root@apache ~]# java -version
    openjdk version "1.8.0_131"
    OpenJDK Runtime Environment (build 1.8.0_131-b12)
    OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)

    4.5、安装 logstash

    4.5.4、解压缩
    [root@apache ~]# rpm -ivh logstash-5.5.1.rpm 
    4.5.2、启动服务
    [root@apache ~]# systemctl start logstash.service 
    [root@apache ~]# systemctl enable logstash.service 
    4.5.3、建立 logstash 软连接
    [root@apache ~]# ln -s /usr/share/logstash/bin/logstash /usr/local/bin/

    4.6、输入采用标准输入,输出采用标准输出

    [root@apache ~]# logstash -e 'input { stdin{} } output { stdout{} }' 
                      省略
    09:02:20.499 [Api Webserver] INFO  logstash.agent - Successfully started Logstash API endpoint {:port=>9600}
    
    www.baidu.com           # 输入
    2021-01-07T01:04:14.008Z apache www.baidu.com      # 输出

    4.7、使用rubydebug显示详细输出

    [root@apache ~]# logstash -e 'input { stdin{} } output { stdout{ codec=>rubydebug } }'
              省略
    The stdin plugin is now waiting for input:
    09:10:19.822 [Api Webserver] INFO  logstash.agent - Successfully started Logstash API endpoint {:port=>9600}
    
    www.baidu.com                                     # 输入
    {
        "@timestamp" => 2021-01-07T01:11:16.829Z,     # 详细输出
          "@version" => "1",
              "host" => "apache",
           "message" => "www.baidu.com"
    }          

    4.8、使用logstash将信息写入elasticsearch中

    4.8.1、写入
    [root@apache ~]# logstash -e 'input { stdin{} } output { elasticsearch{ hosts=>["20.0.0.11:9200"] } }'
                省略
    The stdin plugin is now waiting for input:
    09:15:23.436 [Api Webserver] INFO  logstash.agent - Successfully started Logstash API endpoint {:port=>9600}            
    4.8.2、输入
    www.baidu.com
    www.sina.com
    www.google.com
    4.8.3、谷歌浏览器对接查看

    在这里插入图片描述
    在这里插入图片描述

    4.9、apache 服务器收集系统日志

    4.9.1、对日志文件授权

    (1)查看日志文件

    [root@apache ~]# ll /var/log | grep messages
    -rw-------  1 root         root   218981 17 09:33 messages

    (2)授权

    [root@apache ~]# chmod o+r /var/log/messages
    [root@apache ~]# ll /var/log | grep messages
    -rw----r--  1 root         root   241485 17 09:37 messages

    4.9.2、创建配置文件,系统日志收集

    4.9.1、创建配置文件
    [root@apache ~]# vi /etc/logstash/conf.d/system.conf
    input {
           file{
           path => "/var/log/messages"
           type => "system"
           start_position => "beginning"
           }
         }
    output {
           elasticsearch {
           hosts => ["20.0.0.11:9200"]
           index => "system-%{+YYYY.MM.dd}"
           }
         }
    4.9.2、重启服务
    [root@apache ~]# systemctl restart logstash.service 
    4.9.3、谷歌浏览器查看索引

    在这里插入图片描述
    在这里插入图片描述

    5.0、在node1 节点安装 kibana

    5.0.1、安装并修改配置文件
    [root@node1 ~]# rpm -ivh kibana-5.5.1-x86_64.rpm 
    [root@node1 ~]# vi /etc/kibana/kibana.yml 
    server.port: 5601                                # 2 kibana 打开的端口
    server.host: "0.0.0.0"                           # 7 kibana 侦听的地址
    elasticsearch.url: "http://20.0.0.11:9200"       # 21 和elasticsearch 建立联系
    kibana.index: ".kibana"                          # 30 在elasticsearch中添加.kibana索引 
    5.0.2、开启 kibana 服务
    [root@node1 ~]# systemctl start kibana.service 
    [root@node1 ~]# systemctl enable kibana.service

    5.1、谷歌浏览器登录 kibana 展示页面

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    5.2、在 apache 服务器创建 apache 日志配置

    [root@apache ~]# cd /etc/logstash/conf.d/
    [root@apache conf.d]# vi apache_log.conf
    input {
         file{
           path => "/etc/httpd/logs/access_log"
           type => "access"
           start_position => "beginning"
           }
         file{
           path => "/etc/httpd/logs/error_log"
           type => "error"
           start_position => "beginning"
           }
    }
    output {
         if [type] == "access" {
         elasticsearch {
           hosts => ["20.0.0.11:9200"]
           index => "apache_access-%{+YYYY.MM.dd}"
           }
         }
         if [type] == "error" {
         elasticsearch {
         hosts => ["20.0.0.11:9200"]
         index => "apache_error-%{+YYYY.MM.dd}"
          }
         }
    }
    5.2.1、指定 apache_log.conf 配置文件收集日志
    [root@apache conf.d]# logstash -f apache_log.conf
          省略
    10:22:49.702 [[main]-pipeline-manager] INFO  logstash.pipeline - Pipeline main started
    10:22:49.744 [Api Webserver] INFO  logstash.agent - Successfully started Logstash API endpoint {:port=>9601}      
    5.2.2、查看日志
    [root@apache ~]# ls /etc/httpd/logs/
    access_log  error_log
    5.2.3、谷歌浏览器查看

    在这里插入图片描述

    5.3、创建 apache 的 access 和 error 日志索引

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    总结

    工作原理

    在需要收集日志的所有服务上部署logstash,其中logstash agent ( logstash shipper)用于监控并过滤收集日志,将过滤后的内容发送到 logstash indexer ,logstash indexer将日志收集在一起交给全文搜索服务ElasticSearch ,可以用Elasticsearch进行自定义搜索,通过Kibana来结合自定义搜索进行页面展示。

    展开全文
  • python日志分析

    万次阅读 2019-05-14 09:57:51
    日志分析 生产中会出现大量的系统日志、应用程序日志,安全日志等,通过贵日志的分析可以了解服务器的负载,健康状况,可以分析客户的分布情况、客户的行为,甚至基于这些分析可以做出预测。 一般采集流程: ...
    日志分析

    生产中会出现大量的系统日志、应用程序日志,安全日志等,通过贵日志的分析可以了解服务器的负载,健康状况,可以分析客户的分布情况、客户的行为,甚至基于这些分析可以做出预测。
    一般采集流程:

    • 日志产出->采集(logstash、Flumen、Scribe)->存储->分析->存储(数据库、NoSQL)->可视化

    开源实时日志分析ELK平台
    Logstash收集日志,并存放到ElasticSearch集群中,Kibana则从ES集群中查询数据生成图表,返回游览器端

    数据提取

    半结构化数据
    日志是半结构化数据,是有组织的、有格式的数据。可以分割成行和列,就可以当作表理解和处理了,当然也可以分析里面的数据。
    文本分析
    日志是文本文件,需要依赖文件IO、字符串操作、正则表达式等技术
    通过这些技术就可以将日志需要的数据提取出来了
    使用正则表达式

    import re
    s='''123.125.71.36 - - [06/Apr/2017:18:09:25 +0800] \
    "GET / HTTP/1.1" 200 8642 "-" "|Mozilla/5.0 (compatible; \
    Baiduspider/2.0; +http://www.baidu.com/search/spider.html)\"'''
    pattern='''([\d.]{3,}) - - \[(.*)\] "(\w+) (\S+) (.*)" (\d+ \d+) "-" "(.*)"'''
    regex=re.compile(pattern)
    def extract(log:str):
        m=regex.match(log)
        if m:
            print(m.groups())
    extract(s)
    

    在这里插入图片描述
    使用命名分组

    import re
    s='''123.125.71.36 - - [06/Apr/2017:18:09:25 +0800] \
    "GET / HTTP/1.1" 200 8642 "-" "|Mozilla/5.0 (compatible; \
    Baiduspider/2.0; +http://www.baidu.com/search/spider.html)\"'''
    pattern='''(?P<ip>[\d.]{3,}) - - \[(?P<time>.*)\] "(\w+) (\S+) (.*)" (\d+ \d+) "-" "(?P<useragent>.*)"'''
    regex=re.compile(pattern)
    def extract(log:str):
        m=regex.match(log)
        if m:
            print(m.groups())
            print('ip :{}'.format(m.group('ip')),'time :{}'.format(m.group('time')),'useragent :{}'.format(m.group('useragent')),sep='    ')
    extract(s)
    

    在这里插入图片描述
    使用上面的分组就能提取想要的所有的组,也就是我们想要的数据,为了方便可以使用命名分组
    映射
    对每一个字段命名,然后与值和类型转换的方法对应
    最简单的方式,就是使用正则表达式分组

    import re
    s='''123.125.71.36 - - [06/Apr/2017:18:09:25 +0800] \
    "GET / HTTP/1.1" 200 8642 "-" "|Mozilla/5.0 (compatible; \
    Baiduspider/2.0; +http://www.baidu.com/search/spider.html)\"'''
    pattern='''(?P<ip>[\d.]{3,}) - - \[(?P<time>.*)\] "(\w+) (\S+) (.*)" (\d+ \d+) "-" "(?P<useragent>.*)"'''
    regex=re.compile(pattern)
    #使用映射将得到的结果转换成需要的类型
    con={
        'datetime':lambda time:datetime.datetime.strptime(time,"%d/%b/%Y:%H:%M:%S %z"),
    }#这里举例只转换了时间
    def c(long:str):
        m=regex.match(long)
        if m:
            return {k:con.get(k,lambda x: x)(v) for k,v in m.groupdict().items()}
    print(c(s))
    

    在这里插入图片描述

    异常处理
    日志中不免出现一些不匹配的行,需要处理,这里使用re.match方法,有可能匹配不上,需要加一个判断,采用抛出异常的方式,让调用者活的异常并自行处理

    import re
    s='''123.125.71.36 - - [06/Apr/2017:18:09:25 +0800] \
    "GET / HTTP/1.1" 200 8642 "-" "|Mozilla/5.0 (compatible; \
    Baiduspider/2.0; +http://www.baidu.com/search/spider.html)\"'''
    pattern='''(?P<ip>[\d.]{3,}) - - \[(?P<time>.*)\] "(\w+) (\S+) (.*)" (\d+ \d+) "-" "(?P<useragent>.*)"'''
    regex=re.compile(pattern)
    con={
        'time':lambda time:datetime.datetime.strptime(time,"%d/%b/%Y:%H:%M:%S %z"),
    }
    def c(long:str):
        m=regex.match(long)
        if m:
            return {k:con.get(k,lambda x: x)(v) for k,v in m.groupdict().items()}
        #考虑匹配不到的情况
        else:
            #采用报错
            #raise Exception('No match. {}'.format(s))
            #采用返回特殊值
            return None
    print(c(s))
    def load(path):
        with open(path) as f:
            for line in f:
    

    数据载入
    对于本项目来说,数据就是日志的一行行记录,载入数据就是文件IO的读取,将获取的数据的防范封装成函数

    def load(path):
        with open(path) as f:
            for line in f:
                fields=extract(line)
                if fields:
                    yield fields
                else:
                    continue
    

    日志文件的加载
    目前实现的代码中,只能接受一个路径,修改为接受一批路径。
    可以约定一个路径下文件的存放形式:

    • 如果送来的是一批路径,就迭代其中路径。
    • 如果路径是一个普通的文件,就直接加载这个文件。
    • 如果路径是一个目录,就便利路径下所有指定类型的文件,每一个我呢见按照行处理,可以提供参数处理是否递归子目录
    from pathlib import Path
    def load(*paths,encoding='utf-8',ext='*.log',recursive=False):
        for x in paths:
            p=Path(x)
            #目录处理
            if p.is_dir():
                if isinstance(ext,str):
                    ext=[ext]
                else:
                    ext=list(ext)
            for e in ext:
            files=p.rglob(e)if recursiversive else p.glob(e)
                yield from loadfile(str(file.absolute()),encoding=encodingoding)
            elif p.is_file():
                yield from loadfile(str(file.absolute()),encoding=encodingoding)
    

    完整代码

    from pathlib import Path
    import datetime
    import re
    pattern='''(?P<ip>[\d.]{3,}) - - \[(?P<time>.*)\] "(\w+) (\S+) (.*)" (\d+ \d+) "-" "(?P<useragent>.*)"'''
    regex=re.compile(pattern)
    conversion={
        "datetime":lambda timestr:datetime.datetime.strptime(timestr,'%d%b%Y:%H:%M:%S %z')
    }
    def extract(logline:str)->dict:
        """返回字段的字典,如果返回None说明匹配失败"""
        m=regex.match(logline)
        if m:
            return {k:conversion.get(k,lambda x :x)(v)for k,v in m.groupdict().items()}
        else:
            return None #或输出日志记录
    def loadfile(filename:str,encoding='utf-8'):
        """装载日志文件"""
        with open(filename,encoding=encoding) as f :
            for line in f:
                fields=extract(lien)
                if fields:
                    yield fields
                else:
                    continue
    from pathlib import Path
    def load(*paths,encoding='utf-8',ext='*.log',recursive=False):
        """装载日志文件"""
        for x in paths:
            p=Path(x)
            #目录处理
            if p.is_dir(): #处理目录
                if isinstance(ext,str):
                    ext=[ext]
                else:
                    ext=list(ext)
            for e in ext:
            files=p.rglob(e)if recursiversive else p.glob(e)
                yield from loadfile(str(file.absolute()),encoding=encodingoding)
            elif p.is_file():
                yield from loadfile(str(file.absolute()),encoding=encodingoding)
    
    
    展开全文
  • 很多的日志其实都是以文本的形式来做数据记录的,如果想做深层次的日志分析、统计、计算的时候,就需要对日志的内容进行提取和切片。例如说安全设备的一条日志需要拆分成具体的时间、日志来源设备、安全事件名,具体...

    什么是运维

     

    首先我们谈一谈什么是运维。

     

     

    很多人对运维有自己的理解,他们认为运维是一件特别简单的事情。当我们企业购买了一些信息化的产品,硬件、软件等,我们需要有一个团队让它正常的运转。但是在运转的过程当中,不可避免的会出现各种问题,这就需要有一个专门的团队来做保障。如果你只是把运维简单的理解为一个平台,我觉得这种认识可能比较肤浅。到底什么是运维呢?网上有很多理解 ,关于运维工作的划分,包括网站的运维、系统的运维、网络的运维、数据库的运维、IT 的运维,运维开发、运维安全。从这些分工来看,运维其实是一个复杂、系统的一个工程。

     

    运维的价值

     

    · 运维要知道准确的系统瓶颈点,进而知道系统准确的容量;在系统出现瓶颈前,知道如何快速提供容量。

     

    · 知道系统的风险点,可以协调风险点上下相关关联模块,做出冗余策略;相比集中解决单点模块稳定性,更合理。

     

    · 长期从事相关工作,积累较多的架构设计经验,可以指导新架构设计和审核。

     

    · 从公司不同业务角度看,运维可以从中抽象相同的模块,进行统一管理,去形成企业内部的能力平台、基础设施平台,包括我们可以共用的一些微服务,那么形成这样有效的平台和自动化的管理方法。

     

    现有运维的普遍现状

    以及运维人员的挑战

     

    从运维的价值来看,我们了解到运维是一个复杂、系统的工程。对运维工程师来说,日常需要处理非常多的工作,如何帮助运维工程师做好日常的运维工作,至关重要。但是现在运维工程师在日常运维里遇到很多问题,最主要的原因是现在的 IT 环境越来越复杂。因为信息化建设不是一蹴而就的,公司会在不同的阶段建设不同的业务系统、不同的应用支撑、采购不同的硬件设备。但是由于采购周期的互相递进、堆叠,其实会造成内部有众多不同型号的网络设备、海量不同型号的服务器、各种各样的虚拟化方案、不同的操作系统、多样化的应用软件和数据库。

     

    其实现在很多数据库是由应用软件的开发商来决定的,有些开发商更熟悉 MySQL,他可能用 MySQL 作为应用支撑的数据库,有一些开发商原来一直都在用 Oracle,他可能就会用 Oracle 来做应用支撑。各种不同的业务软件、不同的业务系统都会有不同的业务架构和底层的不同平台,每个平台又会带来不同的监控系统、自己内部相关的一些工具,这会导致一个企业整体的 IT 部门环境变得很复杂,从而带来很多问题:  

     

    · 监控软件纷繁复杂众多监控软件,无法统一管理;  

     

    · 监控告警杂乱无章监控方式存在各种不足,在问题发生时无法及时感知;

     

    · 排错时间长系统复杂,排查问题流程漫长,在发生问题后无法快速准确的定位问题原因;

     

    · 全局性弱无法对全局情况有一个全面的掌控,从而无法有效预测问题的发生;

     

    · 安全挑战大无法高效发现安全性问题,比如黑客侵入和违规操作;

     

    · 管理员管理难度大面对众多异构的监控软件,管理员需要承担极大的心智负担;

     

    通过日志进行运维管理

     

    现在大量的运维团队都是通过日志来进行运维管理。原因是什么呢?

     

    日志系统将我们系统运行的每一个状况信息都使用文字或者日志的方式记录下来。这些信息我们可以理解为设备或是普通人在虚拟世界的行为的记录和投影。这些信息有助我们观察系统运行过程中的正常状态和系统运行错误时快速定位错误位置的途径等。

     

    日志的类型很多,主要包括系统日志、应用程序日志和安全日志还包括很多数据库的日志,等等。每条日志都记载着时间戳、相关设备名称、使用者及操作行为等相关的描述,系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷,性能安全性,及时分析相关问题、追查错误根源纠正错误。

     

    下面我们举了几个相关的例子,大家在日常工作中也会遇到一些这样的监控或是安全的日志。

     

     

    日常对日志的分析主要是应对以下几个场景:

     

    机房集中化监控

     

     

    第一个是机房集中化监控,特别是现在很多机房的建设都会存在大量的不同品牌的服务器、网络设备,特别是大型的企业,他们往往不愿采购单一品牌的服务器,为了避免出现一些厂商依赖的风险,所以会出现机房里存在不同品牌甚至异构的一些设备,运维人员需要对机房有一个管控平台。将交换机、服务器等相关的一些硬件设备,包括你可能涉及到的一些软件上的日志,以及保安系统的日志、业务的日志、用户访问行为的日志等等。将这些日志统一的收集整理起来,形成一个机房的日常的运行状态的一个监控。

     

    上图的示例图是我们在一个案例里面给客户做的展示大屏,他可以反映整个机房的运行状况,运维人员能够很直观的通过大屏知道机房整体的日常运行状态。下面是我们设计的架构图,我们通过交换机、服务器上采集到相关的硬件、软件的一些监控指标,然后读取到我们的日志管理系统里,对日志进行统一的存储、分析、监控、告警,最终形成这样一个大屏的展示。这个是现在很多运维同学在日志使用中最经典的场景。

     

    应用质量管理

     

    

    第二个是应用质量管理,也就是 APM。因为所有的业务系统在运行过程当中也会产生一些业务系统的日志,我们通过采集业务系统日志,能够快速的去分析整个应用针对最终用户的服务质量是怎么样的。

     

    比如说企业有一个 OA 系统,大家平时去 OA 系统查询企业的组织架构人员、日常的一些电子流的流转,包括一些业务申请审批,都会产生大量的日志。我们去分析这些日志可以看到服务平均的响应时长是多少,或者大家平均多久会去使用这个平台一次,我们就能够全面的对这个应用质量进行管理和追踪。一旦我们发现大家都在吐槽我的 OA 打开的很慢,我的整个数据查询反馈结果很慢。到底问题是什么?我们通过应用质量管理的模块去查询到对应的故障点然后对这个应用质量进行优化,为最终的用户去提供更优质的体验。不仅在互联网企业会用到应用质量管理,我们在日常的很多传统企业也会有这样一个需求。

    

    统一日志管理平台

     

     

    第三个叫做统一日志管理平台,这个其实是把场景 1 和场景 2 做了一个更深层次的延伸。大家最开始可能只是针对机房设备做一个监控,后来希望能够针对更上层的业务系统、应用系统进行监控。那现在我们希望能够把企业里面只要能产生日志地方的日志都收集起来。包括开发团队在开发过程中产生的日志,包括业务运行过程中产生的日志,包括机房运维的日志,等等。把这些日志统一的收集在一起,形成统一的日志仓库,这跟我们传统理解的数据仓库类似。

     

    数据仓库是把所有的业务数据、结构化的数据存在一起,来做后续的数据分析。统一的日志管理平台是把所有企业产生的日志收集在一起,然后你来做实时或离线的数据分析,然后把分析出来的结果通过接口输出的方式或是通过消息队列的方式去支撑具体的业务应用。相关人员可以对这些日志进行检索与分析,从而更快的定位问题,并且持续挖掘数据价值。现在很多企业在逐步发展,不仅建设企业内部统一的数据管理平台,也在建设内部统一的日志管理平台。

     

    物联网数据分析和监控

     

     

    第四个结合了现在国家在大力推动的工业 4.0 或是中国制造 2025,其实是希望能够以物联网的手段更好的支撑制造业的发展。现在很多制造业企业会在自己的生产线上去增设很多物联网的探头或是传感器,收集整个生产线在运转过程中产生的各种收据。比如说车间的温度、湿度,包括机器的转速、压力、流量等等。然后把这些数据以数据流的方式采集回我的数据平台,实时的对数据进行汇聚和分析,例如进行数据的上卷统计或者实时数据的监控,一旦出现温湿度的异常,转速的异常,压力的异常,流量的异常,系统需要及时报警,车间管理人员能够及时解决出现的问题。

     

    除此之外,也需要及时的监控一段时间内我的整个生产线上生产的运行情况,甚至和我的品控、质量管理等等结合在一起,能够去找出生产线上的温湿度指标和实际的生产质量之间的一些因果关系。这是很多企业现在在做的物联网方面的一些尝试。这四个我认为是现在传统行业、新兴行业遇到的一些日志运维方面的场景和问题。

     

    统一日志管理的必要性

     

    所以我们很明显感觉到统一日志管理对于传统行业来讲是一个非常重要的事情,不仅能够解决传统行业运维上面的问题,甚至能够去提升一些企业业务层面的能力,包括能够支撑未来很多业务方面的决策和发展。过去,日志被分散的储存在各台服务器上,没有集中管理,难以做关联分析,甚至被删除。

     

    举个简单的例子,传统的防火墙 IPS 等等很多安全数据都存在各自的日志系统里,现在去做安全日志关联分析的企业还很少,像这样的数据很多时候是被大大的浪费掉了。如果你管理数十上百台服务器,你还在使用依次登录每台机器的传统方法查阅日志。这样感觉很繁琐和效率低下。当务之急我们需要使用集中化的日志管理,将所有服务器上的日志收集汇总。在大数据时代,日志数量巨大,种类多样化,企业数据就如同一座亟待开发的金矿,但是随着日志的统一集中,日志的统计和检索的难度也会加大,传统上一般我们使用 grep、awk 和wc 等 Linux 命令来实现日志的检索和统计,但是对于要求更高的查询、排序和统计等要求和庞大的机器数量依然使用这样的方法难免有点力不从心。

     

    日志管理的技术选择

     

    针对日志管理,现在有非常多的技术选择,最传统简单的就是使用 grep/sed/awk 等脚本工具,无需额外工具支持,而且很多运维工程师都有独立写脚本的能力,但效率低下,容易出错。后来也可以把数据采集到 MySQL 里,进行统一数据汇聚和一些简单的计算,虽然使用方便,但是由于 MySQL 本身性能问题,对于数据量的支撑不会很大,所以能力有限。有些企业会采用 NoSQL 数据库来支持大数据量的存储,但它不支持交叉查询与全文检索,去查具体的某一条日志信息的时候,使用负担就会变得很大。

     

    后来出现了很多大数据方面的技术,比如说 Hadoop/Spark/Storm,他们都能很方便的以离线的方式、实时的方式、或者数据流的方式把数据采集进来,但是使用比较繁杂,对于我们的运维团队、IT 部门来说要求会比较高,而且不支持全文检索。所以现在使用 Hadoop/Spark 来做日志管理的公司也不多。现在绝大多数做日志管理的都会使用 ELK,你可以很方便的在网上下载安装来使用,但是 ELK 产品化及体验层面优化做得远远不足,在一些小批量的数据想试用功能的时候,是没有问题的。但如果想把整个机房或是整个企业所有的日志采用 ELK 来做一个统一日志仓库或者企业日志中心的话,他的稳定性和易用性都会受到很大挑战。特别是如果你的数据量达到百TB 级数据的时候,使用 ELK 就会遇到很多的问题。

     

    日志管理系统建设关注要点

     

    那么我们到底如何去选择日志管理系统来支撑我们内部的运维或者支撑我们日志分析呢?我认为可能需要通过八个角度去思考日志管理平台建设的要点,也就是说数据的采集、清洗、存储、搜索、监控告警、分析、报表、开放这八个环节。

    

     

    数据采集

     

    数据采集看起来是一个很简单的概念。但是细分下来,还可以再分为四个功能点:数据的收集、解析、转换、发送。

     

     

    数据采集需要日志管理平台支持各种各样的数据源,这是作为一个优秀的数据采集平台必须具备的功能。包括关系型数据库比如说 MySQL、Oracle,甚至可能像 SQL server 等。以及非关系型数据库、消息队列、 ES 这样的搜索平台,还包括 Hadoop 的服务,将这些数据源的数据准确无误的采集进来是一个数据管理平台在数据采集这块必须支持的功能。另外最好还有针对硬件指标的采集,比如说服务器的 CPU, 服务器的内存使用率,存储的使用率,还包括网络设备的网络流量。这些指标可能不会以日志的形式呈现出来,但是你需要有一个相关的采集工具,能够部署在服务器上,或是部署在网络设备上去采集这些底层硬件的监控指标。这也是数据采集平台在采集这块功能需要去体现的一些能力。

     

    很多的日志其实都是以文本的形式来做数据记录的,如果想做深层次的日志分析、统计、计算的时候,就需要对日志的内容进行提取和切片。例如说安全设备的一条日志需要拆分成具体的时间、日志来源设备、安全事件名,具体描述等若干个字段。日志管理平台需要考虑的第一个功能就是支持非常丰富的预定义的解析规则,不管以什么日志格式进来,都可以很方便的把这些数据解析成相关的字段。

     

    第二个针对个性化的日志格式,能够支持自定义日志解析规则,原因是日志一定是每一个应用开发商在做系统开发的过程当中自己定义的,包含日志相关的格式、内容、规则。所以这个就会造成百花齐放,各个公司日志都不一样的情况发生。那么不同系统的不同日志我们都只用同一套的解析规则去解析的话,一定会出现水土不服的情况。所以如果用户能够非常方便的自定义的对这些日志的解析规则,比如说关于一条样本的日志,能够以划词的方式把切分成若干个字段,系统自动生成相关的解析的规则,这样的话对运维日常的使用来说,就会非常方便易用。

     

    收集、解析之后还有数据转换,为什么还会有转换的工作呢?是因为针对日志中的某些字段,我们希望它的可读性更好一些。比如内网的某个用户访问了某一个业务系统,日志系统一定会记录访问的源 IP 地址,但是当我后续想要对这条日志进行分析的时候,我其实并不关心这个 IP 地址是多少,我关心的其实是这个 IP 地址对应的账号或者是具体的哪个人,所以我们这个时候就需要一个转换的过程,把 IP 地址转换为对应的实体。而通过这样一些转换规则运维人员可以对于后续数据的分析和对数据的统计做到更精准,而且使用过程更易用。

     

    所以说收集、解析、转化都是一个非常重要的工作,这些环节缺一不可。最后处理完的数据,我们需要发送到一个存储里面去进行持久化的存储或者进行后续的分析。那么收集、解析、转化、发送就是数据采集这个功能点里面细分的四个小的需要思考的方面。

     

    数据处理

     

     

    数据采集完成之后,可能还需要对数据进行一些深层次加工处理。对于一些简单的数据可以不处理直接拿来做分析或是搜索。那针对一些复杂的业务场景,例如有大量的数据采集进来后,需要每五分钟或是每十分钟去对数据进行一个简单的计算统计,或者针对一些实时性要求比较高的业务应用,需要数据实时的采集进来之后,跟已有的业务模型或安全模型进行匹配,去实现业务服务或者安全态势监控,在这些场景下,单纯通过数据采集平台是无法满足需求的。这时候需要的是一个强大的数据处理的平台,最好可能是类似于 Hadoop、Spark 这样的大数据计算引擎,能够针对不同种类的数据源进行实时的或者离线的计算,并且支持任务的定时执行、循环执行等周期性调度,最终能够把计算分析的结果,导出到对象存储、日志分析,或者导出到业务数据库去直接支撑后续的实际生产业务。

     

    数据分析

     

    数据采集处理过后就可以进入数据分析的阶段,在这个环节里面,我们需要对收集到的日志进行全方位的快速分析并对结果进行展示,那么首先需要对日志进行统一存储,这个存储至少需要支持 TB 级,甚至 PB 级的数据量,并且能够支持对这些数据进行快速搜索,形成相关的图表以及支撑相关的监控、告警或者分析预测,日志管理平台同时也需要提供相关的 API 接口,能够去对接第三方的监控平台、监控工具或者直接去支撑类似精准营销,用户画像这样的业务系统,以上都是数据分析在这个过程中需要支撑的功能。我日常跟很多用户在沟通的过程当中,我也会发现他们或多或少都会遇到一些日志分析业务的痛点,我总结了四点如下:

     

     

    自动字段分析

    在日志采集阶段已经完成了日志解析,把一条标准的文本型日志解析成了若干个字段,那么能不能对这些字段做一些自动的统计和分析,运维人员不需要自己再去通过写脚本的方式,编辑任务的方式去做数据的计算。比如说系统能够自动的告诉你网络中平均流量是多少,你的流量的峰值和最低值是多少,如果有一些错误的日志,我们统计出来,你的 TOP10 的错误是哪些错误,他来自于哪一个用户或是哪一台设备,针对这样的一些字段分析能大大的降低用户在使用这个平台过程当中去做的一些计算或是任务配置方面的一些工作或难度。

     

    联合搜索

    顾名思义就是通过一个条件去同时搜索多个日志仓库,这个场景就比如说防火墙、IPS、杀毒软件、访问日志可能是存在不同地方,统一采集到日志管理平台上以后一般也是放在不同的日志仓库中,当有一个安全事件发生的时候,安全事件会包含来自哪个 IP 地址的攻击,或是来自哪个用户名的攻击,那我需要通过这个 IP 地址或是用户名能够检索到所有安全设备的日志,然后把相关内容统一的展现出来,那么这个时候就有一个联合搜索的场景。这个时候需要有这样一个功能,能够搜索所有能看到的在这个日志仓库里的内容。

     

    划词分析

    大家在日常使用日志分析功能的时候,并不是所有任务都是固化的,有时候需要根据业务要求灵活变动。比如今天我需要分析一个设备或是某一个用户的日常访问行为,那我会搜索这个用户的用户名,日志管理平台会把符合条件对应的所有内容列出来。但当你仔细去看时,搜索出来的内容会非常多,可能是成百甚至上千条相关的日志,若是传感器类的日志可能会更多。仅仅通过一个搜索条件,往往无法满足你对于日志分析的需求的。这个时候,你可以选择在搜索框里增加一个 and 搜索条件去对日志进行更深层次的结果的筛选。

     

    但能不能有一种更简单的方式?例如既然已经找出了跟这个用户名相关的所有日志,那么是不是能够搜索结果中的某条日志里再划一段词出来,自动的填充到我的搜索框里面,去对数据的搜索结果进行二次过滤,或者我可以在搜索结果里面排除掉划出来的这些词所对应的日志内容,如果这个功能可以实现的话是可以大大提高平台的易用性,去解决日常很多令人崩溃的事情。这是划词分析的一个痛点。

     

    实时搜索

    系统中产生的所有日志都会以数据流的方式不停的采集到日志平台上,对日志进行搜索的时候希望新进来的日志也能实时的展现出来。这样当我去对一个业务进行变更,或对故障进行恢复的时候,我能看到最新进来的日志情况,可以很方便地看到业务是否恢复正常。这有点像我们日常使用的 tail -f 数据实时滚动的场景。这也是很多用户在对数据分析的过程当中会遇到的一个痛点。如果有一个产品能够去解决用户的这些痛点,降低平台的使用负担,这能够大大降低大家日常运维的压力,提升整个工作效率。

     

    七牛智能日志管理平台:https://www.qiniu.com/products/insight

    展开全文
  • java8 GC日志分析

    千次阅读 2018-09-28 16:16:52
    minor GC 日志分析 Full GC 日志分析 参考文档 前言 最近学习分析了一下java8的GC日志,顺便记录下来,忘性太大了 背景: java version "1.8.0_144" Java(TM) SE Runtime Environment (build 1.8.0_144-b01)...

    前言

    最近学习分析了一下java8的GC日志,顺便记录下来,忘性太大了

    背景:

    java version "1.8.0_144"
    Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
    Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
    

    jmap查看信息:

    jmap -heap 56343

    Attaching to process ID 56343, please wait...
    Debugger attached successfully.
    Server compiler detected.
    JVM version is 25.144-b01
    
    using thread-local object allocation.
    Parallel GC with 8 thread(s)
    
    Heap Configuration:
       MinHeapFreeRatio         = 0
       MaxHeapFreeRatio         = 100
       MaxHeapSize              = 4294967296 (4096.0MB)
       NewSize                  = 89128960 (85.0MB)
       MaxNewSize               = 1431306240 (1365.0MB)
       OldSize                  = 179306496 (171.0MB)
       NewRatio                 = 2
       SurvivorRatio            = 8
       MetaspaceSize            = 21807104 (20.796875MB)
       CompressedClassSpaceSize = 1073741824 (1024.0MB)
       MaxMetaspaceSize         = 17592186044415 MB
       G1HeapRegionSize         = 0 (0.0MB)
    
    Heap Usage:
    PS Young Generation
    Eden Space:
       capacity = 1286078464 (1226.5MB)
       used     = 569220648 (542.8511123657227MB)
       free     = 716857816 (683.6488876342773MB)
       44.26018038040951% used
    From Space:
       capacity = 69206016 (66.0MB)
       used     = 25521552 (24.339248657226562MB)
       free     = 43684464 (41.66075134277344MB)
       36.877649480646305% used
    To Space:
       capacity = 66060288 (63.0MB)
       used     = 0 (0.0MB)
       free     = 66060288 (63.0MB)
       0.0% used
    PS Old Generation
       capacity = 163577856 (156.0MB)
       used     = 55992088 (53.398216247558594MB)
       free     = 107585768 (102.6017837524414MB)
       34.22962579971705% used
    
    29765 interned Strings occupying 3248952 bytes.
    

    MaxHeapFreeRatio: GC后如果发现空闲堆内存占到整个预估堆内存的N%(百分比),则收缩堆内存的预估最大值, 预估堆内存是堆大小动态调控的重要选项之一. 堆内存预估最大值一定小于或等于固定最大值(-Xmx指定的数值). 前者会根据使用情况动态调大或缩小, 以提高GC回收的效率MinHeapFreeRatio: GC后如果发现空闲堆内存占到整个预估堆内存的N%(百分比), 则放大堆内存的预估最大值

    MaxHeapSize: 即-Xmx, 堆内存大小的上限

    InitialHeapSize: 即-Xms, 堆内存大小的初始值

    NewSize: 新生代预估堆内存占用的默认值

    MaxNewSize: 新生代占整个堆内存的最大值

    OldSize: 老年代的默认大小, default size of the tenured generation

    NewRatio: 老年代对比新生代的空间大小, 比如2代表老年代空间是新生代的两倍大小. The ratio of old generation to young generation.

    SurvivorRatio: Eden/Survivor的值. 这个值的说明, 很多网上转载的都是错的. 8表示Survivor:Eden=1:8, 因为survivor区有2个, 所以Eden的占比为8/10. Ratio of eden/survivor space size. -XX:SurvivorRatio=6 sets the ratio between each survivor space and eden to be 1:6, each survivor space will be one eighth of the young generation.

    MetaspaceSize: 分配给类元数据空间的初始大小(Oracle逻辑存储上的初始高水位,the initial high-water-mark ). 此值为估计值. MetaspaceSize设置得过大会延长垃圾回收时间. 垃圾回收过后, 引起下一次垃圾回收的类元数据空间的大小可能会变大

    MaxMetaspaceSize: 是分配给类元数据空间的最大值, 超过此值就会触发Full GC. 此值仅受限于系统内存的大小, JVM会动态地改变此值

    CompressedClassSpaceSize: 类指针压缩空间大小, 默认为1G

    G1HeapRegionSize: G1区块的大小, 取值为1M至32M. 其取值是要根据最小Heap大小划分出2048个区块. With G1 the Java heap is subdivided into uniformly sized regions. This sets the size of the individual sub-divisions. The default value of this parameter is determined ergonomically based upon heap size. The minimum value is 1Mb and the maximum value is 32Mb. Sets the size of a G1 region. The value will be a power of two and can range from 1MB to 32MB. The goal is to have around 2048 regions based on the minimum Java heap size.

    GC运行情况:

    jstat gcutil -pid

    S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
    0.00  36.88  59.47  34.23  97.89  96.65     15    0.398     3    0.269    0.667
    

    S0: 新生代中Survivor space 0区已使用空间的百分比

    S1:新生代中Survivor space 1区已使用空间的百分比

    E: Eden已使用空间的百分比

    O:Old已使用空间的百分比

    M:metaspace使用百分比

    CCS:类指针压缩空间使用率 Compressed class space utilization as a percentage.

    YGC:从应用程序启动到当前,发生Yang GC 的次数

    YGCT:从应用程序启动到当前,Yang GC所用的时间【单位秒】

    FGC:从应用程序启动到当前,发生Full GC的次数

    FGCT:从应用程序启动到当前,Full GC所用的时间

    GCT:从应用程序启动到当前,用于垃圾回收的总时间【单位秒】

    启动参数:

    我的本地项目启动参数:

    jinfo -flags 56343
    
    -XX:CICompilerCount=4 -- 最大并行编译数
    -XX:InitialHeapSize=268435456  -- 初始化堆大小
    -XX:+ManagementServer --
    -XX:MaxHeapSize=4294967296 --最大堆大小
    -XX:MaxNewSize=1431306240 --新生代最大大小
    -XX:MinHeapDeltaBytes=524288 --为了防止频繁扩展内存代空间,每次扩展内存代时都有一个最小值_min_heap_delta_bytes,由JVM参数MinHeapDeltaBytes决定,其默认值为128KB
    -XX:NewSize=89128960 --设置年轻代的大小
    -XX:OldSize=179306496 --老年代的大小
    -XX:+UseCompressedClassPointers --使用-XX:+UseCompressedClassPointers选项来压缩类指针
        --对象中指向类元数据的指针会被压缩成32位
        --类指针压缩空间会有一个基地址
    -XX:+UseCompressedOops --压缩对象指针
        --"oops"指的是普通对象指针("ordinary" object pointers)。
        --Java堆中对象指针会被压缩成32位。
        --使用堆基地址(如果堆在低26G内存中的话,基地址为0)
    -XX:+UseFastUnorderedTimeStamps 
    -XX:+UseParallelGC  --使用 Parallel收集器
    

    查看GC日志

    设置tomcat

    vim /Users/liyi/myapp/apache-tomcat-8.5.23/bin/catalina.sh
    

    添加

    JAVA_OPTS="-server -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/Users/liyi/myapp/apache-tomcat-8.5.23/logs/gc.$$.log"
    

    到文件最前面。

    查看日志

    启动tomcat
    查看logs/gc.$$.log

    1.067: [GC (Allocation Failure) [PSYoungGen: 65536K->10748K(76288K)] 65536K->14605K(251392K), 0.0133509 secs] [Times: user=0.04 sys=0.01, real=0.01 secs] 
    1.443: [GC (Allocation Failure) [PSYoungGen: 76284K->10744K(141824K)] 80141K->18577K(316928K), 0.0126569 secs] [Times: user=0.04 sys=0.02, real=0.02 secs] 
    1.772: [GC (Allocation Failure) [PSYoungGen: 141816K->10746K(141824K)] 149649K->34101K(316928K), 0.0214159 secs] [Times: user=0.06 sys=0.01, real=0.02 secs] 
    2.081: [GC (Allocation Failure) [PSYoungGen: 141818K->10738K(272896K)] 165173K->49254K(448000K), 0.0228556 secs] [Times: user=0.10 sys=0.01, real=0.02 secs] 
    2.775: [GC (Allocation Failure) [PSYoungGen: 272882K->10739K(272896K)] 311398K->78908K(448000K), 0.0343582 secs] [Times: user=0.15 sys=0.02, real=0.03 secs] 
    3.378: [GC (Allocation Failure) [PSYoungGen: 272883K->38222K(561152K)] 341052K->106399K(736256K), 0.0285881 secs] [Times: user=0.09 sys=0.02, real=0.03 secs] 
    4.638: [GC (Allocation Failure) [PSYoungGen: 557390K->47073K(566272K)] 625567K->137810K(741376K), 0.0543765 secs] [Times: user=0.14 sys=0.04, real=0.05 secs] 
    5.703: [GC (Allocation Failure) [PSYoungGen: 566241K->66033K(1090560K)] 656978K->163980K(1265664K), 0.0603416 secs] [Times: user=0.09 sys=0.04, real=0.06 secs] 
    26.672: [GC (Metadata GC Threshold) [PSYoungGen: 462923K->25009K(1104384K)] 560870K->123676K(1279488K), 0.0240012 secs] [Times: user=0.04 sys=0.02, real=0.02 secs] 
    26.696: [Full GC (Metadata GC Threshold) [PSYoungGen: 25009K->0K(1104384K)] [ParOldGen: 98666K->33427K(135168K)] 123676K->33427K(1239552K), [Metaspace: 20826K->20826K(1069056K)], 0.0433701 secs] [Times: user=0.17 sys=0.00, real=0.05 secs] 
     56.355: [GC (Metadata GC Threshold) [PSYoungGen: 855695K->50537K(1317376K)] 889123K->83973K(1452544K), 0.0683987 secs] [Times: user=0.15 sys=0.03, real=0.07 secs] 
    56.423: [Full GC (Metadata GC Threshold) [PSYoungGen: 50537K->0K(1317376K)] [ParOldGen: 33435K->62082K(167936K)] 83973K->62082K(1485312K), [Metaspace: 34475K->34475K(1081344K)], 0.0678678 secs] [Times: user=0.30 sys=0.00, real=0.07 secs] 
    77.226: [GC (Metadata GC Threshold) [PSYoungGen: 927352K->29880K(1270272K)] 989434K->91971K(1438208K), 0.0282360 secs] [Times: user=0.08 sys=0.01, real=0.03 secs] 
    77.255: [Full GC (Metadata GC Threshold) [PSYoungGen: 29880K->0K(1270272K)] [ParOldGen: 62090K->54796K(167936K)] 91971K->54796K(1438208K), [Metaspace: 57953K->57953K(1101824K)], 0.1936572 secs] [Times: user=0.55 sys=0.02, real=0.19 secs] 
    379.100: [GC (Allocation Failure) [PSYoungGen: 1240064K->30296K(1319936K)] 1294860K->85100K(1487872K), 0.0177720 secs] [Times: user=0.08 sys=0.01, real=0.02 secs]
    

    minor GC 日志分析

    (第一条):
    1.067: [GC (Allocation Failure) [PSYoungGen: 65536K->10748K(76288K)] 65536K->14605K(251392K), 0.0133509 secs] [Times: user=0.04 sys=0.01, real=0.01 secs]

    ![avatar][youngGCpng]
    在这里插入图片描述

    Full GC 日志分析

    (Metaspace不够用引发fullGC):
    26.696: [Full GC (Metadata GC Threshold) [PSYoungGen: 25009K->0K(1104384K)] [ParOldGen: 98666K->33427K(135168K)] 123676K->33427K(1239552K), [Metaspace: 20826K->20826K(1069056K)], 0.0433701 secs] [Times: user=0.17 sys=0.00, real=0.05 secs]

    ![avatar][fullGCpng]
    在这里插入图片描述
    关于Times解释: GC 时间 —— USER, SYS, REAL?

    引发GC的原因:metaspace区使用内存达到MetaspaceSize设置的值,XX:MetaspaceSize是有一个默认值的:21M

    fullGC原因有很多种,上面只是其中一种,而且所用的收集器不一样,日志也会不一样。
    扩展阅读:GC之详解CMS收集过程和日志分析

    参考文档

    展开全文
  • JMeter自定义日志与日志分析

    万次阅读 2019-07-13 15:46:01
    承接前文,将JMeter脚本部署到Linux服务器上进行压力测试,这种方式也存在一些...针对以上问题,通过【BeanShell断言】记录自定义日志。 首先,测试接口的响应内容如图所示: 在接口下添加三个【JSON Path Extract...
  • ELK 日志分析系统部署

    千次阅读 2019-08-08 11:09:40
    ELK 日志分析系统 组件简介 0、beats :日志收集客户端 1、Logstash:日志收集服务端 2、Elasticsearch :日志搜索引擎持久化 3、Kinaba :数据分析工具 Beats可以直接(或者通过Logstash)将数据发送到Elastic...
  • 日志分析

    千次阅读 2013-07-28 20:18:59
    日志分析方法概述 (2011-4-27 02:04:57) 标签: 数据挖掘 , 统计 分类:数据挖掘 日志在计算机系统中是一个非常广泛的概念,任何程序都有可能输出日志:操作系统内核、各种应用服务器等等。日志的内容...
  • 日志分析方法概述

    万次阅读 2016-08-22 11:31:24
    注:写得有点乱,但目前市面上这...日志在计算机系统中是一个非常广泛的概念,任何程序都有可能输出日志:操作系统内核、各种应用服务器等等。日志的内容、规模和用途也各不相同,很难一概而论。 本文讨论的日志处理方
  • ELK日志分析系统

    万次阅读 多人点赞 2019-07-08 10:17:39
    ELK日志分析系统 介绍: 顾名思义ELK是由ElasticsearchLogstash Kibana三大组件构成的一个基于web页面的日志分析工具。 日志分析是运维工程师解决系统故障,发现问题的主要手段。日志包含多种类型,包括程序日志...
  • MySQL慢查询日志分析详解

    千次阅读 2019-06-27 12:59:56
    MySQL的慢查询日志是MySQL提供的一种日志记录,它用来记录在MySQL中响应时间超过阀值的语句,具体指运行时间超过long_query_time值的SQL,则会被记录到慢查询日志中。long_query_time的默认值为10,意思是运行10S...
  • 强大好用的iis日志分析工具!

    热门讨论 2012-10-30 15:13:42
    iis日志分析工具 用这个软件很容易分析出iis日志,哪个页面访问的最多, 哪个ip消耗的流量最大!
  • Spark日志分析

    千次阅读 2019-01-27 23:21:43
    日志里,通常包含大量的信息,但是这些信息不太容易被利用,这里我们通过对Apache的access.log日志进行分析,来进一步的学习Spark下的程序开发。 2. 假定需求 假设给我们提供一份apache的access.log文件,根据...
  • 用spark做web日志分析

    千次阅读 2018-01-04 15:36:02
    本文以服务器日志分析为例,给大家展示真实场景中,怎么用pySpark去完成大数据的处理和分析的。总述这里的应用主要包括4部分: Part 1: Apache Web服务器日志格式 Part 2: web服务器日志初步解析 Part 3: web...
  • 【日志审计】Apache日志分析

    千次阅读 2019-06-04 12:50:34
    日志分析是我们进行网站维护的重要技能,下面我们就以Apache日志为例分析一下攻击者是如何入侵网站的 通过分析Apache日志了解到了攻击者在入侵网站时的主要步骤 攻击者在27/May/2019:15:46:42利用payload注出后台...
  • 干货 | 携程ClickHouse日志分析实践

    千次阅读 2020-01-22 16:59:00
    结合携程的日志分析场景,日志进入ES前已经格式化成JSON,同一类日志有统一的Schema,符合ClickHouse Table的模式;日志查询的时候,一般按照某一维度统计数量、总量、均值等,符合ClickHouse面向列式存储的使用场景...
  • Android ANR日志分析指南

    千次阅读 2019-08-20 15:17:38
    本文将详细讲解ANR的类型、出现的原因、ANR案例详细分析、经典的案例。 定义 ANR(Application Not Responding)应用程序无响应。如果你应用程序在UI线程被阻塞太长时间,就会出现ANR,通常出现ANR,系统会弹出一个...
  • Windows 日志分析

    千次阅读 2017-09-14 20:59:14
    使用方式 开始-程序-管理工具-计算机管理-系统工具-事件查看器。 然后开始清理日志。 ...各项日志说明 ...Windows 2000 的日志文件...应用程序日志、安全日志、系统日志、DNS日志默认位置: %systemroot%system32con
  •   ELK就是一款非常优秀的、开源的、用于搭建实时日志分析平台的组件。ELK是Elasticsearch、Logstash和Kiabana这3款开源框架首字母的缩写。通过这三个组件,构建一个统一的日志管理系统,用来收集分布式部署系统中...
  • 一不小心错删数据库里面几条重要的数据,后来通过这个东东找了回来,虚惊一场! 该工具有强大的日志分析功能,推荐一下。
  • Windows系统日志分析

    万次阅读 2021-07-30 22:37:28
    Windows系统的日志文件存放在C:/windows/system32/winevt/logs目录下 Windows系统的日志分为三种 系统日志:System.evtx (系统组件等日志) 应用程序日志: Application.evtx (应用程序等日志) 安全日志:Security...
  • goaccess—nginx 日志分析工具

    热门讨论 2012-04-16 18:31:40
    goaccess nginx日志分析工具
  • wpf日志分析工具

    热门讨论 2013-01-15 12:18:53
    wpf日志分析工具
  • 行为日志分析思路与想法

    千次阅读 2017-11-17 10:37:12
    对于如何做一个行为日志分析,因为最近正在做这方面的功能,所以这里我记录下我自己的思路与想法: 首先,我们要做行为日志分析,我们需要理清以下几点东西: 1. 你的行为日志需要做到什么程度,也就是需要做到...
  • Windows日志分析 一、Windows事件日志简介 1、Windows事件日志 Windows系统日志是记录系统中硬件、软件和系统问题的信息,同时还可以监视系统中发生的事件。用户可以通过它来检查错误发生的原因,或者寻找受到...
  • JVM GC日志分析

    千次阅读 2018-09-07 16:17:43
    分析gc日志后,经常需要调整jvm内存相关参数,常用参数如下 -Xms:初始堆大小,默认为物理内存的1/64(<1GB);默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时,JVM就会增大堆直到-Xmx的最大限制 -Xmx:...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 622,253
精华内容 248,901
关键字:

日志分析