Oracle Cloud Hangout Cafe Season4 #4「Observability 再入門」(2021年9月8日開催)

Logs

ログはシステムが生成するテキストデータで、正常な動作や異常な動作などが含まれます。これはファイルや標準出力、標準エラー出力として表示されます。一例ですが、システム運用においては「いつ、どこで、何が起きたか」を把握するためにシステムログ、イベントログ、アプリケーションログ、通信ログなどを利用します。また、セキュリティ監査においては「いつ、誰が、何をした」を把握するために、監査ログや認証ログなどを利用します。

ここからは、クラウドネイティブを視点にKubernetesを基盤とした場合に取得するログを表で整理します。

Kubernetesへの変更はシステムコンポーネントやエコシステムを含めて全てAPIサーバを介して行われるため、どのユーザがどのようなリクエストを送っているかを記録した監査ログはセキュリティ上重要です。

次に、こうしたログをどのように取得するのかを公式ドキュメントにある「Logging Architecture」を参考に見ていきます。

アプリケーションログ
アプリケーションログを取得する方法としては、3種類あります。

• DaemonSet
• Sidecar
• Library

・DaemonSet
ログエージェントをDaemonSetとして各ノードに配置し、ログを転送する方法です。コンテナランタイムが出力するログファイルのディレクトリを監視してラベルなどの情報を付与して転送します。Kubernetesのノード単位でログを集約できます。

DaemonSet

・Sidecar
Pod内において、アプリケーションコンテナのサイドカーコンテナとしてログエージェントを配置し、ログを転送する方法です。汎用的なログエージェントコンテナを作成することで、他のシステムでもサイドカーコンテナとして流用できます。

Sidecar

・Library
アプリケーションからライブラリを利用して直接ログを転送する方法です。

Library

システムログ
Kubernetesのシステムコンポーネント、準システムコンポーネントは稼働している状況に合わせて取得します。ケースバイケースというところもありますので、下表は一例と捉えてください。

監査ログ
監査ログは、Kubernetesのシステムコンポーネントであるkube-apiserverに監査ログの出力先を設定して取得します。kube-apiserverはコントロールプレーンのコンポーネントであるため、マネージドサービスの場合はベンダーが提供する方法で取得する必要があります。

監査記録のライフサイクルはkube-apiserverコンポーネントの中で行われます。各リクエストにおける実行の段階で監査イベントが生成されます。ポリシーに従って前処理されバックエンドに書き込まれます。ポリシーは何を記録するかを決定し、バックエンドがその記録を永続化する仕組みです。バックエンドの実装はログファイルやWebhookなどあります。

監査ポリシーの内容やマニフェストの定義仕様、バックエンドの詳細については、公式ドキュメントにある「Auditing」を参照してください。

・Grafana Loki
最後に、ログアグリゲーションツールの一例としてGrafana Lokiを紹介します。Grafana Lokiはログ管理および分析をするためのOSSです。主に以下の特徴があります。

• コスト効率とスケーラビリティ: Lokiはストレージコストを低減しながら大規模なデータセットを効率的に処理できるように設計されている
• 集中管理: Lokiを使用すると複数のサーバーやアプリケーションからのログを一元的に管理して検索できる
• Grafanaとの統合: LokiはGrafanaと緊密に統合されており、ログデータの視覚化やダッシュボードの作成が容易
• ラベルによるフィルタリング: Lokiではログデータにラベルを付けられるためクエリの効率が向上

また、Grafana LokiにはPromQLから影響されたLogQLがあります。これにより、ログのラベルや演算子を使用したフィルタリングやパースなどを実行できます。

Grafana Lokiのアーキテクチャは下図の通りです。

Grafana Loki’s Architecture Components【出典】Grafana Loki’s Architecture Components

Traces

トレースはコンポーネント間を跨ぐイベントまたはトランザクションの因果連鎖の指標として、個々のアプリケーションを跨って伝送される特定リクエストの追跡データです。トレースが必要となった理由はいくつかあります。主な理由として、分散システムやマイクロサービスにおいて個々のリクエストやトランザクションがシステムまたはサービスの異なる部分をどのように通過するかを可視化して理解することや、パフォーマンスのボトルネックやエラー原因を追跡する手段などが挙げられます。

例を挙げて、もう少しトレースの中身を見ていきます。例えば、AからEの処理を実行するリクエストがある場合に、全体をTrace、各処理をSpanとして各処理で要したSpanの時間を見てパフォーマンスのボトルネック状況を確認し、処理の全体像を把握します。

Trace & Span

・Jaeger
トレースを行えるOSSはいくつかあります。発表ではJaegerを紹介しました。主に以下の特徴があります。

• 分散トレーシングのサポート: Jaegerは複数のマイクロサービスを跨いでリクエストのパスを追跡し、それぞれのサービスでのリクエストの処理時間や順序を可視化できる
• パフォーマンスのモニタリング: マイクロサービス間のリクエストの遅延や問題点を特定し、システム全体のパフォーマンスを監視できる
• エンドツーエンドのリクエスト追跡: ユーザーからの1つのリクエストがシステムのどの部分を通過したのかを一連の「スパン」(処理の断片)として追跡し、それらを結合して全体のトレースを形成する

Jaegerのアーキテクチャは下図の通りです。

Jaeger’s Architecture Components【出典】Jaeger’s Architecture Components

・OpenTelemetry
発表時はOpenCensusとOpenTracingを紹介し、標準化としてOpenTelemetryに統合されるという話をしました。現在(2024年4月時点)、OpenTelemetryは分散システムにおける観測データを収集するためのツール群と、APIを提供するオープンソースプロジェクトとなりました。そして、トレーシング、メトリクス、ログといった観測データの収集を自動化し、一貫性のある方法でこれらのデータを分析するための標準化された手段を提供しています^*1。代表的なプロダクトは以下の通りです。

• OpenTelemetry SDK: アプリケーションにトレースデータなどを公開するためのライブラリ
• OpenTelemetry Protocol(OTLP): メトリクス、ログ、トレースなどのテレメトリを転送するためのプロトコル
• OpenTelemetry Collector: メトリクス、ログ、トレースなどの各種テレメトリの送受信やデータ処理を行うコンポーネント(プラグイン方式を採用)

OpenTelemetryはクラウドネイティブなアプリケーションの監視において、より効率的で統一されたアプローチを提供しています。また、オープンソースで広いコミュニティによるサポートを受けており、多様なニーズに合わせて拡張やカスタマイズができます。