如何为logstash+elasticsearch配置索引模板?

在使用logstash收集日志的时候，我们一般会使用logstash自带的动态索引模板，虽然无须我们做任何定制操作，就能把我们的日志数据推送到elasticsearch索引集群中，但是在我们查询的时候，就会发现，默认的索引模板常常把我们不需要分词的字段，给分词了，这样以来，我们的比较重要的聚合统计就不准确了： 举个例子，假如有10台需要的监控的机器，他们的机器名如下：

Java代码

1. search-0-170
2. search-1-171
3. search-2-172
4. search-3-173
5. search-4-174
6. search-5-175
7. search-6-176
8. search-7-177
9. search-8-178
10. search-9-179

如果使用的是logstash的默认模板，它会按-切分机器名，这样以来想统计那台机器上的收集日志最多就有问题了，所以这时候，就需要我们自定义一些索引模板了： 在logstash与elasticsearch集成的时候，总共有如下几种使用模板的方式： （1）使用默认自带的索引模板 ，大部分的字段都会分词，适合开发和时候快速验证使用 （2）在logstash收集端自定义配置模板，因为分散在收集机器上，维护比较麻烦 （3）在elasticsearc服务端自定义配置模板，由elasticsearch负责加载模板，可动态更改，全局生效，维护比较容易 以上几种方式： 使用第一种，最简单，无须任何配置 使用第二种，适合小规模集群的日志收集，需要在logstash的output插件中使用template指定本机器上的一个模板json路径， 例如 template => "/tmp/logstash.json" 使用第三种，适合大规模集群的日志收集，如何配置，主要配置logstash的output插件中两个参数：

Java代码

1. manage_template => false//关闭logstash自动管理模板功能
2. template_name => "crawl"//映射模板的名字

如果使用了，第三种需要在elasticsearch的集群中的config/templates路径下配置模板json，在elasticsearch中索引模板可分为两种： （一）：静态模板 适合索引字段数据固定的场景，一旦配置完成，不能向里面加入多余的字段，否则会报错 优点：scheam已知，业务场景明确，不容易出现因字段随便映射从而造成元数据撑爆es内存，从而导致es集群全部宕机 缺点：字段数多的情况下配置稍繁琐 一个静态索引模板配置例子如下：

Json代码

1. {
2. "crawl" : {
3. "template": "crawl-*",
4. "settings": {
5. "index.number_of_shards": 3,
6. "number_of_replicas": 0
7. },
8. "mappings" : {
9. "logs" : {
10. "properties" : {
11. "@timestamp" : {
12. "type" : "date",
13. "format" : "dateOptionalTime",
14. "doc_values" : true
15. },
16. "@version" : {
17. "type" : "string",
18. "index" : "not_analyzed",
19. "doc_values" : true
20. },
21. "cid" : {
22. "type" : "string",
23. "index" : "not_analyzed"
24. },
25. "crow" : {
26. "type" : "string",
27. "index" : "not_analyzed"
28. },
29. "erow" : {
30. "type" : "string",
31. "index" : "not_analyzed"
32. },
33. "host" : {
34. "type" : "string",
35. "index" : "not_analyzed"
36. },
37. "httpcode" : {
38. "type" : "string",
39. "index" : "not_analyzed"
40. },
41. "message" : {
42. "type" : "string"
43. },
44. "path" : {
45. "type" : "string"
46. },
47. "pcode" : {
48. "type" : "string",
49. "index" : "not_analyzed"
50. },
51. "pro" : {
52. "type" : "string",
53. "index" : "not_analyzed"
54. },
55. "ptype" : {
56. "type" : "string",
57. "index" : "not_analyzed"
58. },
59. "save" : {
60. "type" : "string",
61. "index" : "not_analyzed"
62. },
63. "t1" : {
64. "type" : "string",
65. "index" : "not_analyzed"
66. },
67. "t2" : {
68. "type" : "string",
69. "index" : "not_analyzed"
70. },
71. "t3" : {
72. "type" : "string",
73. "index" : "not_analyzed"
74. },
75. "url" : {
76. "type" : "string"
77. }
78. }
79. }
80. }
81. }
82. }

（二）：动态模板 适合字段数不明确，大量字段的配置类型相同的场景，多加字段不会报错 优点：可动态添加任意字段，无须改动scheaml， 缺点：如果添加的字段非常多，有可能造成es集群宕机 如下的一个logstash的动态索引模板，只设置message字段分词，其他的字段默认都不分词

Json代码

1. {
2. "template" : "crawl-*",
3. "settings" : {
4. "index.number_of_shards": 5,
5. "number_of_replicas": 0
7. },
8. "mappings" : {
9. "_default_" : {
10. "_all" : {"enabled" : true, "omit_norms" : true},
11. "dynamic_templates" : [ {
12. "message_field" : {
13. "match" : "message",
14. "match_mapping_type" : "string",
15. "mapping" : {
16. "type" : "string", "index" : "analyzed", "omit_norms" : true,
17. "fielddata" : { "format" : "disabled" }
18. }
19. }
20. }, {
21. "string_fields" : {
22. "match" : "*",
23. "match_mapping_type" : "string",
24. "mapping" : {
25. "type" : "string", "index" : "not_analyzed", "doc_values" : true
26. }
27. }
28. } ],
29. "properties" : {
30. "@timestamp": { "type": "date" },
31. "@version": { "type": "string", "index": "not_analyzed" },
32. "geoip" : {
33. "dynamic": true,
34. "properties" : {
35. "ip": { "type": "ip" },
36. "location" : { "type" : "geo_point" },
37. "latitude" : { "type" : "float" },
38. "longitude" : { "type" : "float" }
39. }
40. }
41. }
42. }
43. }
44. }

总结： 定制索引模板，是搜索业务中一项比较重要的步骤，需要注意的地方有很多，比如： （1）字段数固定吗 （2）字段类型是什么 （3）分不分词 （4）索引不索引 （5）存储不存储 （6）排不排序 （7）是否加权 除了这些还有其他的一些因素，比如，词库的维护改动，搜索架构的变化等等。 如果前提没有充分的规划好，后期改变的话，改动其中任何一项，都需要重建索引，这个代价是非常大和耗时的，尤其是在一些数据量大的场景中。