这是我参与8月更文挑战的第16天，活动详情查看：8月更文挑战

前言

elk日志系统用法此篇文章不做描述，一般来说elk是elastic、logstash、kibana，但是小编所在公司不是大公司，logstash如果和elastic放在一台服务器中，一般的服务器拖不动，按照之前的经验如果数据量大，内存至少在8g之上，那么就不配置logstash了，elastic内置的解析器能实现一般的业务要求了

具体操作

elastic配置ingest（解析器）

ingest 文档地址 最重要的是其中的Processors 下面是小编的配置

{
	// 描述
    "description": "java spring boot common parse",
    "processors": [
        {
        	// grok 解析器
            "grok": {
            	// 需要处理的字段名
                "field": "message",
                // 解析方式（和logstash一样配置）
                "patterns": [
                    "%{TIMESTAMP_ISO8601:time}  %{LOGLEVEL:level} %{NUMBER:pid} --- \\[%{MYSELF:thread}\\] %{JAVACLASS:class}  %{MYSELF:message}",
                    "%{MYSELF:message}"
                ],
                "pattern_definitions": {
                    "MYSELF": "[\\s\\S]*"
                }
            }
        }
    ]
}

可以发送请求测试 POST /_ingest/pipeline/_simulate

{
    "pipeline": {
    "description": "java spring boot common parse",
    "processors": [
        {
            "grok": {
                "field": "message",
                "patterns": [
                    "%{TIMESTAMP_ISO8601:time}  %{LOGLEVEL:level} %{NUMBER:pid} --- \\[%{MYSELF:thread}\\] %{JAVACLASS:class}  %{MYSELF:message}",
                    "%{MYSELF:message}"
                ],
                "pattern_definitions": {
                    "MYSELF": "[\\s\\S]*"
                }
            }
        }
    ]
},
    "docs": [
        {
            "_source": {
                "message": "2019-04-25 11:12:31.740  INFO 4013 --- [-8081-exec-1247] c.e.i.framework.aspect.ValidationAspect  : 接受请求并返回 ====> {\"controllerName\":\"com.eco.ipad.controller.MessageController\"}"
            }
        }
    ]
}

#返回结果如下
{
    "docs": [
        {
            "doc": {
                "_index": "_index",
                "_type": "_type",
                "_id": "_id",
                "_source": {
                    "level": "INFO",
                    "pid": "4013",
                    "time": "2019-04-25 11:12:31.740",
                    "thread": "-8081-exec-1247",
                    "message": ": 接受请求并返回 ====> {\"controllerName\":\"com.eco.ipad.controller.MessageController\"}",
                    "class": "c.e.i.framework.aspect.ValidationAspect"
                },
                "_ingest": {
                    "timestamp": "2020-03-21T08:01:38.605Z"
                }
            }
        }
    ]
}

测试成功后请求elastic ingest api PUT /_ingest/pipeline/java_log 其中java_log 是自定义的名字

{
	// 描述
    "description": "java spring boot common parse",
    "processors": [
        {
        	// grok 解析器
            "grok": {
            	// 需要处理的字段名
                "field": "message",
                // 解析方式（和logstash一样配置）
                "patterns": [
                    "%{TIMESTAMP_ISO8601:time}  %{LOGLEVEL:level} %{NUMBER:pid} --- \\[%{MYSELF:thread}\\] %{JAVACLASS:class}  %{MYSELF:message}",
                    "%{MYSELF:message}"
                ],
                "pattern_definitions": {
                    "MYSELF": "[\\s\\S]*"
                }
            }
        }
    ]
}

配置filebeat

output.elasticsearch:
  # Array of hosts to connect to.
  hosts: ["172.17.0.107:9092"]
  index: "callback-%{[fields.project]}-%{+yyyy.MM.dd}"
  # 刚刚配置的名字
  pipeline: java_log

接下来启动测试即可

删除无用字段

实际使用的时候有个事情看不顺眼，就是kibana字段太多了 我还没截完。。。我看着就受不了 这次需要用到process中的remove processor 继续改造

{
    "description": "java spring boot common parse",
    "processors": [
        {
            "grok": {
                "field": "message",
                "patterns": [
                    "%{TIMESTAMP_ISO8601:time}  %{LOGLEVEL:level} %{NUMBER:pid} --- \\[%{MYSELF:thread}\\] %{JAVACLASS:class}  %{MYSELF:message}",
                    "%{MYSELF:message}"
                ],
                "pattern_definitions": {
                    "MYSELF": "[\\s\\S]*"
                }
            },
            "remove": {
            	"field": 
            	[
            		"beat.version",
            		"host.architecture",
            		"host.containerized",
            		"offset",
            		"host.id",
            		"host.os.family",
            		"host.os.codename",
            		"host.os.name",
            		"host.os.platform",
            		"host.os.version",
            		"input.type",
            		"meta.cloud.region",
            		"meta.cloud.provider",
            		"meta.cloud.instance_id",
            		"meta.cloud.availability_zone"
            	],
            	// 忽略失败
            	"ignore_failure" : true
            }
        }
    ]
}

注意 ignore_failure和on_failure 我都试过，相比之下前者稍微好点 测试发现如果设置的删除字段如果实际中不存在，又设置了on_failure结果会导致日志丢失，设置前者的话会按照顺序删除出现异常之后后续哪些需要删除的字段还是存在，但是日志不会丢