オススメのJavaログ管理手法～コンテナ編～（Open Source Conference 2022 Online/Spring 発表資料）

© 2022 NTT DATA Corporation
オススメのJavaログ管理手法（コンテナ編）
2022年3月11日
株式会社NTTデータ技術開発本部
佐藤雄太
オープンソースカンファレンス2022 Online/Spring

© 2022 NTT DATA Corporation 2
自己紹介
⚫ 佐藤雄太(さとうゆうた)
⚫ 株式会社NTTデータ所属
技術開発本部先進コンピューティング技術センタ
⚫ OpenJDKに関連したR&Dとサポート支援
⚫ 元々はPythonでAIなど
⚫ （正直まだJavaよりPythonの方が好き）
⚫ なぜか最近JITのアセンブラ出力見てる
末永恭正
OpenJDK
Reviewer
IcedTea
Committer
阪田浩一
Java Champion
OpenJDK
Author
こんな人達がいる職場で働いてます!!

Java 17開発貢献数
1. Oracle
2. Red Hat
3. 個人
4. SAP
5. Tencent
6. Amazon
7.NTT DATA
8. Arm
9. Alibaba
10.Intel

このセッションの対象と想定している方
◼ Javaを使っている方
◼ ULログを知らずに使っている、復習したい人
◼ コンテナに興味がある方、使っている方
◼ ログ収集ツールに興味ある方
Javaのみに特化した内容ではありません!
初学者向けです!

セッションの流れ
◼ コンテナ+Javaの背景
◼ ULログについて基本的な解説
◼ コンテナ環境でのログに関する問題点、その解決策
◼ OSSツールを活用した解決策
◼ 解決策の実例紹介

何故にJavaでコンテナ？
6

コンテナを選ぶ理由

マイクロサービスアーキテクチャ
◼ コンテナ技術等を用いてそれぞれのサービスを
独立したプロセスとしてアプリケーションを動作
⚫ 負荷が高くなったサービスを個別にスケールできる
⚫ サービスがそれぞれ独立しているのでお互いを
そこまで気にする必要がない
⚫ ログはどう扱う？
その前に現在のJavaのログはどういうものか？

Java ULログについて
9

Java UL(Unified Logging) ログ
◼ Java 9より追加された新形式のログ取得方法
⚫ カテゴリ別、ログレベル別に出力を設定可能(-Xlog option）
⚫ 根本的原因解析(Root Cause Analysis)に必須
⚫ このログを提出することでサポートサービスへの問い合わせが
しやすい

Java UL(Unified Logging) ログの指定
–Xlog[<what>][:[<output>][:[<decorators>][:<output-options>]]]
-what : 出力内容をタグとレベルで選択
-output : 出力先の指定
-decorators : デコレータの指定
-output-options : ログローテート設定
＊ちなみにデフォルトではWarningで標準出力に表示されます。

Java UL(Unified Logging) ログログレベルの変更
• デフォルト(ログレベルWarning)
• ログレベルinfo
java -Xlog:os=info -version

Java UL(Unified Logging) ログ出力先の変更
java -Xlog:os=info:file=/home/log/ul.log:t,hn,l,tg:filecount=1,
filesize=1m -version
• ファイルに出力

Java UL(Unified Logging) ログ JITコンパイルログ出力
java -Xlog:jit+compilation=debug hello
• JITの動作を表示

Java UL(Unified Logging) ログ有用性
◼ これらが出来ると何が良いか？
⚫ エラー時に見たいエラー文だけ確認できる
⚫ 前のログを指定された場所に保存して一括管理する、
後で確認したいときに参照できる
➢ とりあえずこれ一本で設定を指定できるので非常にSimple

設定したJava UL(Unified Logging) ログの確認方法
jcmd プロセスID VM.log list
Java Sleep.java

設定したJava UL(Unified Logging) ログの変更方法
jcmdプロセスID VM.log output=#1 output_options=os=info
実行中に出力の
ログレベルをinfoに変更

Java UL(Unified Logging) ログ総評
◼ Java９より搭載されたULログ
⚫ Java 8以前に比べて設定が容易
⚫ レベルやカテゴリ別に設定可能
⚫ jcmdコマンドを使って実行後確認、変更などが容易
⚫ なによりプログラム書く側から情報が見やすい
◼ ただコンテナ環境だとある問題点が...

コンテナの問題点
19

コンテナ技術とは
◼ 簡単にいうとホストOS上で独立したプロセスとして
実行されるアプリケーション環境
https://www.docker.com/resources/what-container

現時点で主流なコンテナエンジン
• Docker
Docker社が開発
• Podman
Red Hat社が開発
互換性があるのでどちらもほぼ同じコマンドで使える
PodmanはK8sのように簡単なpodを作れる
(後述のログ分析で便利なので今回は後者を主に利用）

コンテナ技術の特徴
◼ 仮想環境と違いローカル環境を汚さず、コマンド一つで簡単に
コンテナ環境を作成可能、サービスとしても利用可能
◼ 揮発性という特徴を持つ

コンテナの揮発性について
◼ 揮発性(volatility)
Wikipediaによると、、
⚫ 液体の蒸発しやすい性質（相転移参照）(灯油、有機物など)
⚫ 揮発性メモリ: 電源を切ると記憶内容が消える
性質の記憶装置

コンテナの特徴 - 揮発性について
◼ コンテナ内で出力したデータは永続しない
⚫ なぜ?
➢コンテナ環境では起動するたびに新しいコンテナを
作成することを想定しているから
⚫ なんのため？
➢起動の際はどこの環境においても同じ状況を再現
（ポータビリティを重視）

コンテナの揮発性が起こすログの消失
再起動
⚫ コンテナ内のログは？
➢ 漏れなく消えます

コンテナの揮発性が起こすログの消失
消滅
Bye !!

コンテナでのログ運用（解決策）
27

揮発性が起こす問題点への解決策
⚫ 何はともあれ外部へ保存！！
コンテナは終了したらインスタンスが破棄されるのが
前提なのでその前に外部へ保存する
⚫ いくつかある方法としては
❖ 外部ストレージに直接送る
❖ ネットワークでブロードキャスト
❖ サイドカー形式で他のコンテナに移動

コンテナでのログ分析手法（理想図）
外部ボリューム
⚫ コンテナ内で出力されたログは
「外部」のボリュームへ
⚫ 外部ボリュームに置いた
ログを別コンテナで分析
⚫ そのためにもコンテナ側で設定
を変更、OSSツールを活用

助けてもらうついでに、、、(ログ分析ツールを活用）
cat ul.log | grep ….

コンテナ側での設定
31

永続ボリュームへの移行 Step1

そもそもコンテナにおけるファイルシステムとは？
⚫ コンテナでは仮想環境と違いホストから分離されている
⚫ これを可能にしているのがnamespaceというLinuxの技術
⚫ コンテナではプロセスIDやファイルシステムなどが
コンテナごとに分離されている
（つまりコンテナからローカル環境が見えない）
⚫ じゃあどうする？
➢ マウントさせましょう

コンテナでのマウント（現時点で主な３種類）
bind volume tmpfs
メリット • 前準備が不要なので
一番簡単
• 複数コンテナでの
運用の際の
安全性の高さ
• ホストのメモリ上に
保存するので
読み取りが高速
デメリット • ホスト環境に依存するこ
と（ホスト環境への
意図しない書き込み）
• volume create
の前処理が必要
• Linuxのみ対応
• コンテナ間で
マウント領域を
共有不可

コンテナでのマウント（ボリュームタイプ）
⚫ 安全性が高い、Docker公式でも一番推奨
https://docs.docker.com/storage/volumes/

コンテナでのマウント（ボリュームタイプ）
$ volume create ullog-vol
$ --mount type=volume,src=ullog-vol,target=/home/log
⚫ Podmanだと
基本以下のパス上に作成されます
（ローカルから参照は基本非推奨）
$HOME/.local/share/contain
ers/storage/volumes/
ullog-vol/_data/

お助け外部ツールの活用その１
37

Fluent Bit データシッピングツール
Fluent Bit
• ログを収集し、外部に送信するログシッピングツール
• 出力先にAWS,Azure
GCPなど指定先が豊富
• Parserよりデータフォーマットの
変更が容易
• コンテナ版もある
ただ調整が必要
https://fluentbit.io/

Fluent Bit (もしくはFluentD)データシッピングツール
Fluent Bitでは以下の図のように”input”からデータを収集
し、”Parser”そして”Filter”でデータを処理し、その後”Router”を通し、
複数の”output”にデータが送信されるパイプライン構造となっている。

4.3.2.4.4. Fluent Bit設定ファイル（パーサー設定ファイル）
[PARSER]
Name ul
Format regex
Regex
^¥[(?<datetime>.+?)¥]¥[(?<hostname>.+?)¥]¥[(?<level>.+?)¥]¥[(?<
tags>.+?)¥]¥s+(?<message>[¥s¥S]+?¥Z)
Time_Key datetime
Time_Format %Y-%m-%dT%H:%M:%S.%L%z
jvm-ul-parsers.conf
⚫ 設定ファイルを作成し
入力データをParserを通し、
欲しい出力データに変更可能
右図では
keyとしてdatetimeを指定

Fluent Bitコンテナ調整
FROM fluent/fluent-bit
COPY ullog /log/ullog/
COPY jvm-ul-parsers.conf /fluent-bit/etc/
COPY fluent-bit.conf /fluent-bit/etc/
CMD [“/fluent-bit/bin/fluent-bit", "-c", “/fluent-bit/etc/fluent-
bit.conf"]
Dockerfile
◼ docker HubにあるFluent Bitコンテナ(AMD64版)にはmkdir,
catなど標準のコマンドが一切用意されていない...
(ディストロレスイメージ）
⚫ Dockerfileを作成し必要な設定ファイル等はローカルで作成し
予め送ることで解決 !!

お助け外部ツールの活用その２
43

ログ分析

Elasticsearch&Kibana
• Elasticsearch
分散型で無料かつオープンな
検索・分析エンジン NoSQL
• Kibana
Elasticsearchに登録したデータを可視化
状況に応じて様々なDashboardを作成可能
先ほど紹介したFlunet Bitのプラグイン設定に対応している
https://www.elastic.co/jp/

Fluent Bitとのプラグイン
Data Processing Storage Visualization
[OUTPUT]
Name es
Match *
Host 127.0.0.1
Port 9200
Logstash_Format on
Logstash_Prefix ul-log
Logstash_DateFormat %Y.%m.%d
Type type1
⚫ Fluent Bit側の設定ファイル
でElasticsearchを
出力先として登録可能

Elasticsearch 登録データ確認
以下のようにcurlコマンドでElasticseach側での
登録したデータの確認が可能
$curl -sS -XGET "localhost:9200/index名/type名/_search?pretty"
{
"_index" : "ul-log-2021.09.01",
"_type" : "type1",
"_id" : "8U4Xn3sBT2e7G3-tQ8O6",
"_score" : 1.0,
"_source" : {
"@timestamp" : "2021-09-01T00:20:48.442Z",
"hostname" : "ce1e7e309f0c",
"level" : "info",
"tags" : "os",
"message" : "Use of CLOCK_MONOTONIC is supported"
}

Kibana Dashboard画面
&&
https://www.elastic.co/jp/kibana/

お助け外部ツールの活用その２ EX
49

コンテナ環境の自動化
⚫ 確かに様々なOSSツールを使ってログ分析可能
⚫ だけどツールごとに設定ファイルとか
オプションとか設定、管理が大変そう
⚫ 複数コンテナの設定など自動化できないかなぁ..

Kubernetes(K8s)
• Kubernetes(K8s)
• コンテナ環境の管理を自動化するための
プラットフォーム
（コンテナオーケストレーションエンジン）
• 複数のコンテナをpodといった単位でまとめて一元的に管理
今まで解説してきたULログシッピングをKubernetes(K8s)を使い、
yamlで記述することで同じ動作が可能
https://kubernetes.io/

Kubernetes(K8s) yaml設定
apiVersion: v1
kind: Pod
…
…
- name:ullog
emptyDir:
- name: config-vol
configMap:
name: fluent-bit-config
• ログファイルをやり取りする
一時ボリューム
• emptyDirを利用
• サイドカーパターンを使い、
Fluent Bitコンテナにログ
をシッピングさせる
• 複数の設定ファイル
• configMapにまとめる

ULログで実際にやってみた
53

コンテナ環境ULログ分析
一時ボリューム

Podの作成
⚫ Javaアプリケーション, Fluent Bit Podを作成
⚫ Elasticsearch, Kibana Podを作成

Kibana Discover画面
Fluent Bitがログを
シッピング

Kibana Dashboard画面
状況に応じて
様々なグラフを作成可能

コンテナ環境でのログ分析（解決前）
消滅
Bye !!

コンテナ環境でのログ分析（解決後）

最後に
60

まとめこのセミナーで伝えたかったこと
⚫ ULログの有用性
⚫ コンテナは揮発性なので残したいデータは
外部ストレージへ保存する
⚫ 様々なツールと組み合わせて上記の問題を解決できる
今回は一例なので他にも色々とやり方はあると思います
❖ コンテナの特徴を理解して状況に応じた環境を作成し
よりよいJavaでのコンテナライフを送りましょう！！

本資料に記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です

オススメのJavaログ管理手法～コンテナ編～（Open Source Conference 2022 Online/Spring 発表資料）

Recommended

More Related Content

What's hot (20)

Similar to オススメのJavaログ管理手法～コンテナ編～（Open Source Conference 2022 Online/Spring 発表資料） (20)

More from NTT DATA Technology & Innovation (20)

Recently uploaded (6)