ごきげんよう！mihohoi です。
コンテナーのログ(stdout/stderr)を AKS (Azure Kubernetes Service) や Azure Container Apps で出力する場合、Container Insights などを利用して Log Analytics から確認します。
では、全てのエラーログを Log Analytics で確認しようと思うと、できないことはありませんが、相当な苦労が必要です。
特にアプリケーションのエラーログを出す場合、stdout/stderr から確認するのは大変を通り越して、もう泣きたくなることもあると思います。
それでは、どこでログの確認を行うのがスマートなのか、いくつかの方法と表示例を出しながら確認してみたいと思います。
今回使用するサンプルアプリ
今回は、Java の Spring Boot でよく使われている「petclinic」を利用します。
このサンプルアプリケーションは「k8s」フォルダに yaml ファイルが設定されていたりと、何かと便利なサンプルアプリケーションですが、アプリの Dockerfile が存在していないのと、Application Insights も導入したいため、GitHub Copilot の力を借りて、新たに Dockerfile を作成しました。
今回は、ログの表示を確認したいだけのため、Dockerfile の内容は割愛します。
ローカルでの動作確認
ローカルで動作確認を行います。いつもの可愛いワンちゃんと猫ちゃんがが出てきました。
「ERROR」タブをクリックすると、エラーが発生するようになっています。押下して、エラーがコンテナー側から出力されることを確認します。
そうそう、このエラーがほしい。
それでは、Application Insights からエラーが表示されているか確認します。
Application Insights の稼働確認とともに、エラーが出力されていることも確認できました。
Azure Container Apps での確認
それでは、作成した Docker イメージを使って、Azure Container Apps にデプロイしてみましょう。
こちらが Azure Container Apps に petclinic をデプロイして出力したエラー画面です。
標準出力からだと、スタックのログが大変見えづらくなっていることがわかります。1つのエラーが数十行にわたって表示されてしまっています。
目が痛い....
では Application Insights 側からこのエラーを見るとどうなるか、確認してみます。
上記は、Application Insights 「障害」から確認した画面です。右下の「コール スタック」がスタックトレースのログになります。ここから見ると、1つの塊としてエラーを見ることができます。
この「コールスタック」に表示されているログ、Log Analytics からも確認できるので見てみます。
「details」列にログがまとまっていることがわかります。これならば見やすいですね。
AKS での確認
では、AKS で同じように確認してみましょう。
とは言っても、Azure Container Apps と出力内容は同じです。stdout/stderr は同じように Log Analytics に1行ずつ出力されます。
ただし、AKS では「複数行ログ」（と呼んでいいのか）を設定することで、コンテナーからの例外スタックトレースを合成することができます。
「複数行ログ」は、以下の制限事項があるため注意が必要です。
- 対象言語は、Java、Python、.NET、Go のみ
- カスタム例外や任意のログ メッセージなど、その他の複数行ログ エントリは結合されない
AKS に対して ContainerLogV2 スキーマを有効するには、「クラスターのデータ収集規則（DCR）」または ConfigMap を作成する必要があります。
今回は、ConfigMap を利用します。
参考となる設定は下記の URL の yaml にあります。
設定した ConfigMap は以下となります。
apiVersion: v1
kind: ConfigMap
metadata:
name: container-azm-ms-agentconfig
namespace: kube-system
data:
schema-version: v1
config-version: v1
log-data-collection-settings: |-
[log_collection_settings.schema]
containerlog_schema_version = "v2"
[log_collection_settings.enable_multiline_logs]
enabled = true
stacktrace_languages = ["java"]
[log_collection_settings.metadata_collection]
enabled = true
# 収集フィールドを限定する場合のみ設定（未指定なら全フィールド収集）
# include_fields = ["podLabels","podAnnotations","podUid","image","imageID","imageRepo","imageTag"]
適用後、AKS のコンテナーからエラーを出力してみます。
ConfigMap 適用後、複数行にまとまっていたログが 1行に合成されていることがわかります。適用前のログに影響を与えないため、設定前のログは1行のままとなっています。
まとめ
複数行ログの設定を出力前後であらためて確認したかったため、実際にどのような変化があるかを検証しました。
アプリケーションのログは、Application Insights から確認するのが個人的には一番みやすいと感じます。
ですが、何か止まれぬ事象があり、Container Insights から確認したい場合は、複数行ログの設定をしておくと便利だなと思います。
では、良いコンテナー ライフを！！
Discussion