json logstash 解析失敗 ctrl-code 1
阿新 • • 發佈：2018-01-09
pic 終端 blog org 轉換 問題： nag size flume "問題：
從windows 通過flume傳輸到kafka的日誌（GBK），然後再logstash 消費，用json 解析。有些日誌解析報錯：ctrl-code 1(SOH 文本頭)。
分析：
在終端上用gbk編碼查看會有 方框的字符，可以判斷該字符就是json 無法識別的控制字符（SOH）。
但是不知道kafka消費的時候顯示成什麽字符，如果知道這個（SOH）然後替換成，json 可以解析的字符就可以了。
topics_pattern => ""rzrqbp-C010001""
value_deserializer_class => ""org.apache.kafka.common.serialization.ByteArrayDeserializer"" #源字節編碼轉換器，因為一直以GBK編碼傳輸
codec => plain{charset => [""GBK""]}
}
}
filter {
mutate {
convert => { ""[indicator][usedtime]"" => ""integer"" }
gsub =>[""message"",""\u0001"","" ""]
}
json {
source => ""message""
}
date {
match => [""[time_stamp]"",""UNIX_MS""]
target => ""@timestamp""
}
從windows 通過flume傳輸到kafka的日誌（GBK），然後再logstash 消費，用json 解析。有些日誌解析報錯：ctrl-code 1(SOH 文本頭)。
分析：
在終端上用gbk編碼查看會有 方框的字符，可以判斷該字符就是json 無法識別的控制字符（SOH）。
但是不知道kafka消費的時候顯示成什麽字符，如果知道這個（SOH）然後替換成，json 可以解析的字符就可以了。
解決辦法：
在日誌裏發現每一個（SOH）處，都顯示為\u0001,這是16進制的ascll code 1。和控制字符的code1也是對應的，斷定（SOH)被解析成\u0001這個字符。
input kafka中之前都是直接codec => json{charset =>[""GBK""]},相當於在消費的時候先進行json 解析，這樣很無力，一直報錯。
換個思路：
1，先無格式plain消費，然後把SOH(\u0001)
2，替換成空格（因為soh無意義，替換成空格不影響源信息）gsub =>["message","\u0001"," "]，
3，再用 json {source => ""message""} 進行解析，這樣就可以了。
--------------------------配置信息---------------------------------
input {
kafka {
bootstrap_servers => ""ZBSZ1-LOG-KFK01:9092,ZBSZ1-LOG-KFK02:9092,ZBSZ1-LOG-KFK03:9092""
topics_pattern => ""rzrqbp-C010001""
value_deserializer_class => ""org.apache.kafka.common.serialization.ByteArrayDeserializer"" #源字節編碼轉換器，因為一直以GBK編碼傳輸
codec => plain{charset => [""GBK""]}
}
}
filter {
mutate {
convert => { ""[indicator][usedtime]"" => ""integer"" }
gsub =>[""message"",""\u0001"","" ""]
}
json {
source => ""message""
}
date {
match => [""[time_stamp]"",""UNIX_MS""]
target => ""@timestamp""
}
}
output {
elasticsearch {
hosts => [""ZBSZ1-LOG-ES01:9200"", ""ZBSZ1-LOG-ES02:9200"", ""ZBSZ1-LOG-ES03:9200""]
index => ""app-rzrqbp-%{+YYYY.MM.dd}""
document_id => ""%{[indicator][msgid]}""
}
}
"
json logstash 解析失敗 ctrl-code 1