一、Kafka ->logstash ->elasticsearch
logstash 5.X以上版本不兼容5.x以下版本，因此在升級logstash時會遇到很多坑。首先是配置的變化，可以參考如下配置：
input {
kafka {
bootstrap_servers => "XX:9092,YY:9093,ZZ:9094" 變化點：這里監聽的是kafka的端口號
topics => "xxxlog"
group_id => "elasticconsumer"
max_partition_fetch_bytes=> "4194304" 處理消息過大的場景
codec => "json"
}
}
output {
elasticsearch {
hosts => ["XXX:9200"]
index => "logstash-%{+YYYY-MM-dd}"
codec => "json"
}
}
output {
file {
path => "/data01/logstash.log"
flush_interval => 0
}
}
完成配置后可以通過如下命令來檢測配置文件是否有語法錯誤：
bin/logstash -t -f config/kafka-logstash-es.conf
另外，elasticsearch 5.X版本的集群安裝請參見：http://www.jianshu.com/p/9e3749daeb93
二、elasticsearch數據丟失
通過kibana監控返回的數據時，無意中發現返回的數據存在數據丟失的現象。將input數據保存進elasticsearch的同時，通過寫入log日志文件中。通過如下命令查詢elasticsearch中保存的數據時，發現數據在保存進elasticsearch的時候就已出現丟失現象：
get _index/_type/_count?q=monitorId:XXX get logstash-2017-03-21/logs/_count?q=monitorId:XXX
編寫測試配置，將出錯的json直接通過屏幕輸入：
input {
stdin {
codec => json
}
}
output {
stdout {
codec => rubydebug
}
}
又發現數據可以正常輸出。那么問題出在哪一個環節呢？
通過查看elasticsearch中的日志，發現在解析json時系統偶爾會報String_Object 轉化異常。是什么原因導致此問題的發生呢？
通過一步步追蹤最終發現問題出在dynamic mapping環節。
ES如何對對動態類型字段做mapping的呢？ES在內部對一個index下的type會根據mapping來進行存儲，所以要求type中的每個字段類型必須一致。例如對一個User表，如果有個name字段，那么一條user數據中的name為string類型的話，后續所有的user對象中的name都必須為string，否則做index時就會出錯。
但是由於一些原因平台的數據在返回時，同一個type下的值，有的為String類型，有的卻為Object對象，按照上面的邏輯在進行解析時異常是必然的了。
參見：http://jiangpeng.info/blogs/2014/11/24/elasticsearch-mapping.html
http://www.cnblogs.com/ningskyer/articles/5787702.html
http://blog.arganzheng.me/posts/datatype-in-elasticsearch.html
解決措施：統一平台返回的數據格式，將同一type下字段的值統一轉化為String類型。
三、json長度過長elasticsearch存儲異常
在解決問題二后發現kibana中依然有數據丟失的情況。分析elasticsearch的日志，發現平台返回的json長度過長導致elasticsearch在進行數據存儲時異常。
那么針對此問題需要如何進行處理呢？下面給出實際的處理方案僅供參考：
A.logstash配置
input {
kafka {
bootstrap_servers =>"XXX:9092,YYY:9093,ZZZ:9094"
topics => "klog"
group_id => "elasticconsummer"
codec => "json"
}
output {
elasticsearch {
hosts => ["XXX:9200","YYY:9200"]
index => "logstash-%{+YYYY-MM-dd}"
codec => "json"
manage_template => true
template_overwrite => true
template_name => "kTemplate"
template => "/data01/xxx.json"
}
}
output {
file {
path =>"data01/logstash.log"
flush_interval =>0
}
}
}
B.模板的配置
{
"template" : "logstash*",
"settings" : {
"index.number_of_shards" : 5,
"number_of_replicas" : 1,
"index.refresh_interval" : "60s"
},
"mappings" : {
"_default_" : {
"_all" : {
"enabled" : true
},
"dynamic_templates" : [
{
"string_fields" : {
"match" : "*",
"match_mapping_type" : "string",
"mapping" : {
"type" : "string",
"index" : "not_analyzed",
"omit_norms" : true,
"doc_values": true,
"fields" : {
"raw" : {
"type": "string",
"index" : "not_analyzed",
"ignore_above" : 256,
"doc_values": true
}
}
}
}
} ],
"properties" : {
//定義長度
"callMethodResult": {
"type": "string",
"index": "not_analyzed"
"ignore_above" : 256
}
}
}
}
}
}
參見：http://m.blog.csdn.net/article/details?id=50823494
模板的配置參見:https://github.com/chenryn/ELKstack-guide-cn/blob/master/logstash/plugins/output/elasticsearch.md
其它坑請參見：http://www.jianshu.com/p/fa31f38d241e
四、離線環境下Kibana加載慢問題
在離線環境下發現kibana加載比較慢，跟蹤定位后發現系統在離線環境上也會加載http://tiles.elastic.co/v2/manifest?my_app_version=5.2.0
將/kibana/src/server/config/schema.js中的manifestServiceUrl中的上述地址修改為http://localhost/即可
五、Kibana中文亂碼
在實際使用過程中發現應用布署到生產環境后，在Kibana中的中文日志有亂碼。將logstash采集的數據一份寫入elasticsearch,另一份寫入log，發現日志在寫入log時已經是亂碼。如果想要中文沒有亂碼，那么日志文件應該是UTF-8格式。我們可以用file命令查看日志的生成格式，如下：
[xxx@localhost logs]$ file app.log app.log: UTF-8 Unicode English text, with very long lines
log4j的配置參考如下:
<appender name="FILE" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="./logs/app.log"/> <param name="Encoding" value="UTF-8"/> <param name="DatePattern" value="'.'yyyy-MM-dd"/>
但最終定位生產環境出現此問題的原因是沒有指定tomcat的編碼格式.
六、logstash TCP指定端口監聽
通過./logstash-plugin list 查看logstash安裝的插件
input {
tcp {
host => "XXX"
port => "5000"
mode => "server"
type => "microwiki"
add_field => {
"name" => "Routh"
}
}
}
output {
file {
path => "/data01/XXX"
flush_interval => 0
}
}