ecs-logging-javaつかってみた

ecs-logging-java つかってみた 第39回Elasticsearch勉強会 2020.12.17 #elasticsearchjp

あなた誰？ 某決済代行会社所属 Java中心にサーバサイド開発 U゜Д゜)＜ヨロシクオネ

@shiba_dog 今回話すこと ● ecs-logging-javaを使ったアプリケーションログの可視化活用例 ○ ○ 導入は軽く触れる程度 どう使っているかを中心に

@shiba_dog アプリログ、kibanaでどう可視化していますか？ ● messageの中身のgrokはとりあえずせずにログビューア的な使い方？ これだと、業務的なメトリクスやTermsしたい情報を可視化できない！！ ログのレイアウトをいじって、構造 化させればいいじゃん！

@shiba_dog 動機 ● ● 今までアプリケーションログをそのままElasticsearchに格納し、プラットフォーム・ア プリ全体で扱うキー情報をMDCに入れることで可視化に役立てていた。 また、ログメッセージを詳細に出力することにより、kibanaのクエリ検索を使って絞 り込んでいた。

@shiba_dog 動機 でも、運用している中、障害調査などで調査し辛い部分が出てきた。 ● ● ● 特定の業務ログでTermsした情報を見たい！ 業務的なメトリクスで可視化したい！ ExceptionのメッセージやClass情報をぱっと見たい！

@shiba_dog でもでも ● 複数のアプリを動かすPasSで稼働しているため、アプリ個別のgrokを プラットフォーム側で管理するのはしんどい（これはうちの事情） ● マイクロサービスで作られたアプリに対して、ログ出力のルールを敷い て管理するのはしんどい

@shiba_dog そこでecs-logging-java！

@shiba_dog ecs-loggin-javaいいところ ● ● 依存追加とlogライブラリのLayoutを変更するだけ。 ソースは変えずに、出力内容がイイ感じにJSONになる。 ○ ● log4j2を使えば、オブジェクトをそのままlog.infoに渡すことも簡単 ○ ● なのでgrokはjsonでやればOK メッセージ内容を Jsonにしておけば勝手に構造化 ExceptionやStackTraceをイイ感じに統一して構造化

@shiba_dog ecs-loggin-javaいいところ ● ● 依存追加とlogライブラリのLayoutを変更するだけ。 ソースは変えずに、出力内容がイイ感じにJSONになる。 ○ ● log4j2を使えば、オブジェクトをそのままlog.infoに渡すことも簡単 ○ ● なのでgrokはjsonでやればOK メッセージ内容を Jsonにしておけば勝手に構造化 StackTraceをイイ感じに統一して構造化

@shiba_dog ecs-loggin-javaいいところ ● ● 依存追加とlogライブラリのLayoutを変更するだけ。 ソースは変えずに、出力内容がイイ感じにJSONになる。 ○ ● log4j2を使えば、オブジェクトをそのままlog.infoに渡すことも簡単 ○ ● なのでgrokはjsonでやればOK メッセージ内容を Jsonにしておけば勝手に構造化 ExceptionやStackTraceをイイ感じに統一して構造化

@shiba_dog

ecs-loggin-javaいいところ
●
●

依存追加とlogライブラリのLayoutを変更するだけ。
ソースは変えずに、出力内容がイイ感じにJSONになる。
○

●

なのでgrokはjsonでやればOK

log4j2を使えば、オブジェクトをそのままlog.infoに渡すことも簡単
メッセージ内容を Jsonにしておけば勝手に構造化

{"@timestamp":"2019-08-06T12:09:12.375Z", "log.level": "INFO", "message":"Tomcat started on port(s): 8080 (http) with context path ''",

○

"service.name":"spring-petclinic","process.thread.name":"restartedMain","log.logger":"org.springframework.boot.web.embedded.tomcat.TomcatWebServer"}

●

StackTraceをイイ感じに統一して構造化

{"@timestamp":"2019-08-06T12:09:12.379Z", "log.level": "INFO", "message":"Started PetClinicApplication in 7.095 seconds (JVM running for 9.082)",
"service.name":"spring-petclinic","process.thread.name":"restartedMain","log.logger":"org.springframework.samples.petclinic.PetClinicApplication"}
{"@timestamp":"2019-08-06T14:08:40.199Z", "log.level":"DEBUG", "message":"init find form",
"service.name":"spring-petclinic","process.thread.name":"http-nio-8080-exec-8","log.logger":"org.springframework.samples.petclinic.owner.OwnerController","transaction
.id":"28b7fb8d5aba51f1","trace.id":"2869b25b5469590610fea49ac04af7da"}

@shiba_dog ecs-loggin-javaいいところ ● ● 依存追加とlogライブラリのLayoutを変更するだけ。 ソースは変えずに、出力内容がイイ感じにJSONになる。 ○ ● log4j2を使えば、オブジェクトをそのままlog.infoに渡すことも簡単 ○ ● なのでgrokはjsonでやればOK メッセージ内容を Jsonにしておけば勝手に構造化 ExceptionやStackTraceをイイ感じに統一して構造化

@shiba_dog ecs-loggin-javaいいところ ● ● 依存追加とlogライブラリのLayoutを変更するだけ。 ソースは変えずに、出力内容がイイ感じにJSONになる。 ○ ● log4j2を使えば、オブジェクトをそのままlog.infoに渡すことも簡単 ○ ● なのでgrokはjsonでやればOK メッセージ内容を Jsonにしておけば勝手に構造化 ExceptionやStackTraceをイイ感じに統一して構造化

@shiba_dog ecs-loggin-javaいいところ ● ● 依存追加とlogライブラリのLayoutを変更するだけ。 ソースは変えずに、出力内容がイイ感じにJSONになる。 ○ ● log4j2を使えば、オブジェクトをそのままlog.infoに渡すことも簡単 ○ ● なのでgrokはjsonでやればOK メッセージ内容を Jsonにしておけば勝手に構造化 ExceptionやStackTraceをイイ感じに統一して構造化

@shiba_dog

ecs-loggin-javaいいところ
● 依存追加とlogライブラリのLayoutを変更するだけ。
{"@timestamp":"2019-09-17T13:16:48.038Z",
"log.level":"ERROR", "message":"Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception
● ソースは変えずに、出力内容がイイ感じにJSONになる。

[Request processing failed; nested exception is java.lang.RuntimeException: Expected: controller used to showcase what happens when an exception is thrown] with

○

root cause",

なのでgrokはjsonでやればOK

"process.thread.name":"http-nio-8080-exec-1","log.logger":"org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet]","log.origin":{"file.name":"

●

log4j2を使えば、オブジェクトをそのままlog.infoに渡すことも簡単

DirectJDKLog.java","function":"log","file.line":175},"error.type":"java.lang.RuntimeException","error.message":"Expected: controller used to showcase what happens

○

メッセージ内容を Jsonにしておけば勝手に構造化

when an exception is thrown","error.stack_trace":[

"java.lang.RuntimeException: Expected: controller used to showcase what happens when an exception is thrown",

●"\tat org.springframework.samples.petclinic.system.CrashController.triggerException(CrashController.java:33)",
StackTraceをイイ感じに統一して構造化
"\tat sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)",
"\tat sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)",
"\tat sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)",
"\tat java.lang.reflect.Method.invoke(Method.java:498)",
"\tat org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)",
"\tat java.lang.Thread.run(Thread.java:748)"]}

@shiba_dog こんな風に使っています！ ● ● ● アプリケーション独自のaccess logを可視化 Exceptionのスタックトレースを構造化してエラーの種類と発生具合を簡単に把握 いつか対応が必要になる線形に増加する情報の可視化 ○ ⇒ キャッシュさせている情報（線形に増える）を出力しておいてグラフ日々の推移を確認

@shiba_dog 使ってみて困ったこと ● 構造化できるのはお手軽だが、構造化ルールはどっちにしろ決めないとindex patternがぐちゃる ○ ○ ● 今は、アプリごとに一段レイヤを掘って使うように 何でもかんでも構造化したオブジェクトを出力するのはよくなさそう 開発時にローカル起動するときはJSONよりいつものログのほうが見やすい ○ プロファイルでログパターンを制御するようにして解決。

@shiba_dog まとめ ● ● ecs-logging-java簡単だよ！ アプリログの可視化をすると運用がすごく楽だよ！