ログ/メトリクストピックとログセット
ダウンロード
フォーカスモード
フォントサイズ
ログトピック
ログトピック（Log Topic）は、ログデータをCLS（Cloud Log Service）プラットフォームで収集、保存、検索、分析するための基本単位です。収集された大量のログは、ログトピックを単位として管理されます。これには、収集ルールの設定、保存期間の設定、ログの検索分析、ログのダウンロード/消費/配信などが含まれます。
1つのログトピックは通常、特定のアプリケーション/サービスに対応します。同じアプリケーション/サービスの異なるマシン上の同種のログを、同じログトピックに収集することをお勧めします。例えば、ある決済サービス（payService）が数十台のマシンにデプロイされており、アクセスログ（access_log）とエラーログ（error_log）の2種類のログが含まれています。payService_access_log_topicとpayService_error_log_topicという2つのログトピックを作成し、それぞれこの数十台のマシン上の2種類のログに対応させることができます。この2つのログトピックを通じて、数十台のマシン上のすべてのログの集中的な検索と分析を完了できます。
ログトピックとアプリケーション/サービスの間は、必ずしも厳密な1対1の対応関係ではありません。2つのサービス間でログ構造の類似度が高く、頻繁にログを集中的に分析する必要がある場合は、これら2つのサービスのログを同じログトピックに報告することもできます。
指標トピック
指標トピック（Metric Topic）は、指標データをCLS（Cloud Log Service）プラットフォームで収集、保存、検索、分析するための基本単位です。収集された指標データは、指標トピックを単位として管理されます。これには、保存期間の設定や検索分析などが含まれます。
指標トピックはPrometheus指標データモデルおよび指標クエリインターフェースと互換性があり、1つのPrometheusインスタンスに相当します。異なるアプリケーション/サービスの指標は、指標名が競合せず、指標のアップロードが25000QPSおよび250MB/sの仕様制限を超えない限り、1つの指標トピックに保存できます。実際の運用では、通常、業務システムの本番環境、テスト環境、開発環境の指標をそれぞれ異なる指標トピックに保存します。
ログセット
ログセット（Logset）はログトピックおよび指標トピックを分類するためのものです。1つのログセットには複数のログトピックと指標トピックを含めることができます。ログセット自体はログデータを一切保存せず、ユーザーがトピックを管理しやすくするためのものです。
1つのログセットは通常、社内の特定のプロジェクト/業務に対応します。あるプロジェクト/業務配下の複数のアプリケーション/サービスのログトピックを、同じログセットに帰属させることをお勧めします。例えば、社内のあるECプロジェクトに複数のサービス（決済サービス payService、ユーザーサービス userService、在庫管理サービス stockService など）が含まれている場合、ログセット e_commerce_logset を作成し、これらのサービスのログトピックをすべてこのログセットに帰属させることができます。これにより、社内に複数のプロジェクトがある場合、各プロジェクトの担当者は所属プロジェクトに対応するログセット内のログトピックのみを確認すればよく、他のプロジェクトのログトピックによる影響を受けません。
注意
トピックを新規作成する際に、そのトピックが所属するログセットを指定できます。保存後は変更できません。
シーン例
上図のように、この会社には2つの部門があります：
部門AにはECプロジェクトがあり、マイクロサービスアーキテクチャを採用しています。各サービスには、アクセスログ（access_log）とエラーログ（error_log）の2種類のログが含まれています。
部門Bには2つのプロジェクトがあります。それぞれミニプログラムゲームプロジェクトとミニプログラムソーシャルプロジェクトで、技術アーキテクチャは比較的シンプルです。いずれもNginxのアクセスログ（nginx_log）を1つ持っています。
CLSを使用して上記のアプリケーションログを監視する場合、以下のようにログセットとログトピックを作成できます：
ログセット | ログトピック | タグ |
e_commerce_logset | payService_access_log_topic | 部門：部門 A |
e_commerce_logset | payService_error_log_topic | 部門：部門 A |
e_commerce_logset | userService_access_log_topic | 部門：部門 A |
e_commerce_logset | userService_error_log_topic | 部門：部門 A |
e_commerce_logset | stockService_access_log_topic | 部門：部門 A |
e_commerce_logset | stockService_error_log_topic | 部門：部門 A |
e_commerce_logset | ...... | 部門：部門 A |
gameApplet_logset | gameApplet_nginx_log_topic | 部門：部門 B |
socialApplet_logset | socialApplet_nginx_log_topic | 部門：部門 B |
その中のTagは、ログセットおよびログトピックが属する部門を区別するために使用されます。権限ポリシーと組み合わせることで、各部門の担当者が所属部門のデータのみを閲覧できるように制御できます。
部門Aの場合、e_commerce_logsetログセットはそのECビジネス配下のすべてのサービスのログトピックをカバーしています。今後、他のプロジェクトを新規追加する場合は、新しいログセットを作成すればよいです。
部門Bの場合、現在の技術アーキテクチャは比較的シンプルで、ログは合計2種類のみですが、2つのログセットが作成されており、各ログセットにはログトピックが1つしかありません。これは以下の目的によるものです：
後続のアーキテクチャ拡張をサポートします：ビジネス規模が拡大し、技術アーキテクチャもマイクロサービスアーキテクチャへと進化した後も、現在のログセットをそのまま使用し続けることができます。現在のログセット配下にログトピックを新規追加するだけでよく、異なるプロジェクト間で互いに影響を与えることはありません。
プロジェクト調整に柔軟に対応できます：部門全体を1つのログセットとした場合、その中の特定のプロジェクトを独立した部門にする必要がある場合や、別の部門に調整する必要がある場合、ログトピックは所属するログセットを直接変更できないため、調整が非常に煩雑になり、ログを再収集する必要が生じる可能性があります。一方、プロジェクトごとにそれぞれログセットを対応させている場合はこのような状況は発生せず、ログセットとログトピックに対応するTagを調整するだけで済みます。
フィードバック