istioのconfigmapを確認してみます
kubectl edit configmap istio -n istio-system
事前確認
accessLogFile: "" # ここを修正します。
accessLogFormat: ""
accessLogEncoding: 'TEXT'
修正後
accessLogFile: "/dev/stdout"
accessLogFormat: ""
accessLogEncoding: 'TEXT'
ついでにistio-proxy側のログレベルも変更しておきます
istioctl proxy-config log --level http:info -n [Namespace] [podName] -c istio-proxy
その後に実際にログを確認してみます
kubectl logs [podName] -n [Namespace] -c istio-proxy -f
- -f (tail -fと同じモード)
出力イメージ(istioのバージョンによって異なる(?)
[2020-04-18T06:42:18.630Z] "GET /nginx HTTP/1.1" 200 - "-" "-" 0 612 4 1 "10.1.10.1" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36" "00c83e93-0eb0-920f-b059-0a5120826b7c" "localhost:31380" "10.1.10.104:80" outbound|80||nginx.default.svc.cluster.local - 10.1.10.84:80 10.1.10.1:39754 - -
気になる点
アクセスして即座にログ出力されるかと思いきや、時間差で出力される。
1分〜2分は待つのはなぜ？単なるI/Oの負荷とは思えない。
4/23 追記
@yteraoka さんコメントありがとうございます！
コメントに記載頂いたEnvoyのページにこのような記述が。
Asynchronous IO flushing architecture. Access logging will never block the main network processing threads.
メインのネットワーク処理を邪魔するようなログ出力はしないぞ。という設計みたいですね。
Envoy（サイドカー）のネットワーク処理が忙しくなるほどログへの吐き出しは遅れる......ということに。