パリ郊外の小規模拠点で、障害対応用のログ検索ツールを運用している。構成はアプリ3台、ログ集約1台、保管は90日。1日あたりの取り込みは約80万行、日本語のエラーメッセージも混ざる。先週、現地スタッフが「昨日の決済失敗を検索しても0件になる」と連絡してきた。実際には障害は起きていて、生ログには日本語の例外文言が残っていた。
再現した手順は単純だった。取り込み側の解析設定で、文字コードの推定がUTF-8ではなくISO-8859-1に落ちていた。フランス語のアクセント記号を含む行が先に来ると、そこで推定が確定し、後続の日本語が置換文字に化ける。検索インデックスには化けた文字列が入るので、日本語キーワードでは引けない。修正は取り込みパイプラインの先頭で明示的に指定するだけ。
# logstash相当の設定例
input {
file {
path => "/var/log/app/*.log"
codec => plain { charset => "UTF-8" }
}
}
filter {
mutate { gsub => [ "message", "\\x{FFFD}", "?" ] }
}
重要だったのは、文字コードを推定に任せないことと、化けた行を黙って捨てないこと。捨てると件数が合わなくなり、障害の全体像を誤る。置換してでも残し、別インデックスに警告として集計する方が、後の照合が楽だった。
ただしこの方法は、元のアプリがUTF-8で出している場合にしか効かない。古いバッチがEUC-JPで吐いている区間があり、そこは個別にcodecを分ける必要があった。また、アクセント記号付きのフランス語と日本語が同一行に混在するログでは、化けた箇所の復元はできない。復元を狙うより、発生時点で気づける監視を足す方が現実的だった。私も最初、推定の精度を上げれば直ると考えて半日溶かした。
今は取り込み時に文字化け率を出し、0.1%を超えたらアラートにしている。皆さんの拠点では、複数言語が混ざるログの文字コードをどう固定していますか。
0
赞同度 100% · 0 条评论 · 3 阅读
0 条评论
还没有评论,写下第一条。