ELK Stack 在入门学习过程中，必然会碰到自己修改定制索引映射(mapping)乃至模板(template)的问题。
这时候，不少比较认真看 Logstash 文档的新用户会通过下面这段配置来制定自己的模板策略：

output {

    elasticsearch {

        host => "127.0.0.1"

        manage_template => true

        template => "/path/to/mytemplate"

        template_name => "myname"

    }

}

然而随后就发现，自己辛辛苦苦修改出来的模板，通过 curl -XGET 'http://127.0.0.1:9200/_template/myname' 看也确实上传成功了，但实际新数据索引创建出来，就是没生效！

这个原因是：Logstash 默认会上传一个名叫 logstash 的模板到 ES 里。如果你在使用上面这个配置之前，曾经运行过 Logstash（一般来说都会），那么 ES 里就已经存在这么一个模板了。你可以curl -XGET 'http://127.0.0.1:9200/_template/logstash' 验证。

这个时候，ES 里就变成有两个模板，logstash 和 myname，都匹配 logstash-* 索引名，要求设置一定的映射规则了。

ES 会按照一定的规则来尝试自动 merge 多个都匹配上了的模板规则，最终运用到索引上:https://www.elastic.co/guide/e ... lates

其中要点就是：template 是可以设置 order 参数的！而不写这个参数，默认的 order 值就是 0。order 值越大，在 merge 规则的时候优先级越高。

所以，解决这个问题的办法很简单：在你自定义的 template 里，加一行，变成这样：

{

    "template" : "logstash-*",

    "order" : 1,

    "settings" : { ... },

    "mappings" : { ... }

}

当然，其实如果只从 Logstash 配置角度出发，其实更简单的办法是：直接修改原来默认的 logstash 模板，然后模板名称也不要改，就好了：

output {

    elasticsearch {

        host => "127.0.0.1"

        manage_template => true

        template_overwrite => true

    }

}

想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。

三斗已经写了好多篇了，分享了很多小经验和知识，非常不错，不如我们一起把Advent玩起来吧，这样，我们玩一个接力游戏，每个同学写完之后可以@论坛里面的其它同学，被@的同学需要完成一篇小的Advent，然后写完再继续接着传给下一位，如果不在论坛的同学，就邀请他加入下 ：）
 
@的操作就是在贴子里@对方的名字，然后你想办法通知到对方就行了，QQ、论坛消息等等反正告诉对方被@和继续就行咯。
没有找到下一个接班的人就继续写下去。哈哈

写Advent，选择发表类型『文章』，分类选择『advent』，话题添加『advent』+其它的自选

下面是一篇ELK的Advent，顺便分享一下。Day 5 - ELK Operations and Administration
 
 欢迎补充完善规则。
 

ELK的架构：
logstash==>redis==>logstash==>elasticsearch==>kibana开始我自己在ES上建索引，
建索引语句如下：
curl -XPUT "http://localhost:9200/qn-service" -d '{"mappings":{"_default_":{"properties":{"speaker":{"type":"string","index":"not_analyzed"},"play_name":{"type":"string","index":"not_analyzed"},"line_id":{"type":"integer"},"speech_number":{"type":"integer"}}}}}'
然后通过logstash导数据到ES后，却发现查询不到数据，然后用
curl http://localhost:9200/_cat/indices?v  命令发现索引的数据为空；

发现es自动建的索引有数据，而我自己的索引数据为空。
找了半天原因没找到，然后就将es中得数据删除，
 curl -XDELETE *[/url]
用上述方法重建索引；
然后按照书上《ELK权威指南》上得方法，直接导入数据到es，
curl -XPUT http://localhost:9200/_bulk --data-binary @shakespeare.json
却发现自己建的索引还是没有数据，es却多了一个叫shakespeare得索引，这个索引中有数据，那么我有两点疑问1：为什么我用书上建索引的方法建立索引(shakespeare名字被我改成qn-service)却没有数据？
2：shakespeare这个索引是哪里来得？
 
logstash shipper.conf
input {
        file {
                path => ["/data/logs/superErpLog/trace/shakespeare.json"]
                start_position => "beginning"
                sincedb_path => "/dev/null"
        }
}
filter{
        json{
                source=>"message"
                remove_field => ["message"]
        }
}
output {
        stdout{}
        redis {
                host => "localhost"
                port => 6379
                data_type => "list"
                key => "performance"
        }
} 
logstash center.conf
input {
        redis {
                host => "localhost"
                port => 6379 
                type => "redis-input"
                data_type => "list"
                key => "performance"
        }   
}

output {
        stdout {}
        elasticsearch {
                cluster => "elasticsearch"
                host => "localhost"
                port => 9200
                codec => "json" 
                protocol => "http"
        }   
}

Kibana4 上线后，又有同事找过来。还好这次是小问题：『新版的这个仪表盘顶部菜单栏太宽了啊。头顶上监控屏幕空间有限，能不能省省？』

跟 Kibana3 相比，确实宽了点。这时候好几个方案瞬间进入我脑子里：

1. 浏览器往下拖动一点，不过要确保定期刷新的时候还能回到拖动位置；
2. 进 ui/public/chrome/chrome.html 里把 navbar 干掉；
3. 添加一个 bootstrap 效果，navbar 默认隐藏，鼠标挪上去自动浮现。

不过等打开 chrome.html 看了一下，发现 navbar 本身是有相关的隐藏判断的：

<nav

  ng-style="::{ background: chrome.getNavBackground() }"

  ng-class="{ show: chrome.getVisible() }"

  class="hide navbar navbar-inverse navbar-static-top">

这个设置在 ui/public/chrome/api/angular.js 里的 internals.setVisibleDefault(!$location.search().embed);。我们知道 $locatio.search() 是 AngularJS 的标准用法，这里也就是代表 URL 请求参数里是否有 ?embed 选项。

好了，我们试一下，把 http://localhost:5601/app/kiba ... ydash 改成http://localhost:5601/app/kiba ... embed，回车，果然，整个菜单栏都消失了！同步消失的还有每个 panel 的编辑按钮。

其实呢，embed 在页面上是有说明的，在 dashboard 的 share 连接里，提供了一个 iframe 分享方式，iframe 里使用的，就是 embed 链接！

注意：Kibana4 部分版本的 share 说明中的 embed 位置生成的有问题，请小心。

想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。

用 Logstash 接收 Kafka 里的业务日志再写入 Elasticsearch 已经成为一个常见的选择。但是大多数人随后就会碰到一个问题：logstash-input-kafka 的性能上不去！

这个问题，主要是由于 Logstash 用 JRuby 实现，所以数据从 Kafka 下来到最后流转进 Logstash 里，要经过四五次 Ruby 和 Java 之间的数据结构转换，大大浪费和消耗了 CPU 资源。作为优化，我们可以通过修改默认的 logstash-input-kafka 的 codec 配置为 line，把 Jrjackson 处理流程挪到 logstash-filter-json 里多线程处理，但是也只能提高一倍性能而已。

Logstash 开发组目前也在实现纯 Java 版的 logstash-core-event，但是最终能提高多少，也是未知数。

那么在 Logstash 性能提上去之前，围绕 Kafka 还有什么办法能高效又不失灵活的做到数据处理并写入 Elasticsearch 呢？今天给大家推荐一下携程网开源的 hangout。

hangout 采用 YAML 格式配置语法，跟 Elasticsearch 一样，省去了 Logstash 解析 DSL 的复杂度。下面一段配置是 repo 中自带的 example 示例：

inputs:

  - Kafka:

    codec: plain

    encoding: UTF8 # defaut UTF8

    topic: 

      app: 2

    consumer_settings:

      group.id: hangout

      zookeeper.connect: 192.168.1.200:2181

      auto.commit.interval.ms: "1000"

      socket.receive.buffer.bytes: "1048576"

      fetch.message.max.bytes: "1048576"

      num.consumer.fetchers: "4"

  - Kafka:

    codec: json

    topic: 

      web: 1

    consumer_settings:

      group.id: hangout

      zookeeper.connect: 192.168.1.201:2181

      auto.commit.interval.ms: "5000"



filters:

  - Grok:

    match:

      - '^(?<logtime>\S+) (?<user>.+) (-|(?<level>\w+)) %{DATA:msg}$'

    remove_fields: ['message']

  - Add:

    fields:

      test: 'abcd'

    if:

      - '<#if message??>true</#if>'

      - '<#if message?contains("liu")>true<#elseif message?contains("warn")>true</#if>'

  - Date:

    src: logtime

    formats:

      - 'ISO8601'

    remove_fields: ['logtime']

  - Lowercase:

    fields: ['user']

  - Add:

    fields:

      me: 'I am ${user}'

  - Remove:

    fields:

      - logtime

  - Trim:

    fields:

      - user

  - Rename:

    fields:

      me: he

      user: she

  - Gsub:

    fields:

      she: ['c','CCC']

      he: ['(^\w+)|(\w+$)','XXX']

  - Translate:

    source: user

    target: nick

    dictionary_path: /tmp/app.dic

  - KV:

    source: msg

    target: kv

    field_split: ' '

    value_split: '='

    trim: '\t\"'

    trimkey: '\"'

    include_keys: ["a","b","xyz","12"]

    exclude_keys: ["b","c"] # b in excluded

    tag_on_failure: "KVfail"

    remove_fields: ['msg']

  - Convert:

    fields:

      cs_bytes: integer

      time_taken: float

  - URLDecode:

    fields: ["query1","query2"]



outputs:

  - Stdout:

    if:

      - '<#if user=="childe">true</#if>'

  - Elasticsearch:

    cluster: hangoutcluster

    hosts:

      - 192.168.1.200

    index: 'hangout-%{user}-%{+YYYY.MM.dd}'

    index_type: logs # default logs

    bulk_actions: 20000 #default 20000

    bulk_size: 15 # default 15 MB

    flush_interval: 10 # default 10 seconds

    concurrent_requests: 0 # default 0, concurrent_requests设置成大于0的数, 意思着多线程处理, 以我应用的经验,还有是一定OOM风险的,强烈建议设置为0

  - Kafka:

    broker_list: 192.168.1.200:9092

    topic: test2

其 pipeline 设计和 Logstash 不同的是：整个 filter 和 output 流程，都在 Kafka 的 consumer 线程中完成。所以，并发线程数完全是有 Kafka 的 partitions 设置来控制的。

实际运行下来，hangout 比 Logstash 确实在处理能力，尤其是 CPU 资源消耗方面，性价比要高出很多。

想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。