AppLog の特徴

  • 包括的な情報：AppLog はプログラマーによって提供され、主要な場所、変数、および例外をカバーします。 技術的には、本番環境の 90％ 以上のバグが AppLog に基づいて特定されます。

  • 任意の形式：1 つのコードが複数のプログラマーで開発され、それぞれが好みの形式を使用することはよくあります。 このため、形式を統一することは困難です。 スタイルの不一致は、サードパーティのデータベースから取り込んだログにも見られます。

  • AppLog 間の類似性：任意の形式にもかかわらず、複数の AppLog 間では共通点があります。 たとえば、Log4J ログには次の情報が必要です。

    • 時間
    • レベル
    • ファイルまたはクラス
    • 行番号
    • スレッド ID

AppLog の処理上の課題

  • 大量のデータ

    通常、AppLog のサイズはアクセスログのサイズよりも 1 桁大きくなります。 Web サイトには毎日 100 万の独立した PV があり、各 PV には約 20 のロジックモジュールが含まれ、各ロジックモジュールの 10 の主要なロジックポイントをログに記録する必要があるとします。

    ログの合計数は、次の式を使用して計算されます。

     1,000,000 × 20 × 10 = 2 × 10^8 entries

    各エントリの長さが 200 バイトとします。 合計ストレージサイズは、次の式を使用して計算されます。

     2 × 10^8 × 200 = 4 × 10^10 Bytes = 40 GB

    ビジネスシステムが複雑になるにつれて、データサイズが大きくなります。 中規模の Web サイトでは、毎日 100 から 200 GB のログデータが生成されるのが一般的です。

  • 複数の分散アプリケーション

    ほとんどのアプリケーションはステートレスで、次のような異なるフレームワークで実行されます。

    • サーバー
    • Docker (コンテナー)
    • Function Compute (Container Service)

    対応するインスタンスの数は、数個から数千個までさまざまです。 複数のインスタンスには、クロスサーバーログ収集方式が必要です。

  • 複雑なランタイム環境

    プログラムは、次のような異なる環境で実行されています。

    • アプリケーションログは Docker コンテナーに保存されます。
    • API ログは Function Compute に保存されます。
    • 古いシステムログは、従来の IDC に保存されます。
    • モバイル側のログは、ユーザーのモバイルデバイスに保存されます。
    • モバイル Web ログはブラウザーに保存されます。

    ログデータの全体像を把握するには、ログを 1 つの場所に統合して保存する必要があります。

方式

統合されたデータストレージ

目的：さまざまなソースから中央の場所にデータを収集して、その後の操作を容易にします。

Log Service にプロジェクトを作成して AppLog を保存できます。 Log Service は、物理サーバーでのトラッキング、モバイル Web 側での JavaScript コードの入力、サーバー上のログのエクスポートなど、30 を超える収集方法をサポートしています。

Log Service は SDK のようなメソッドを使用してログを書き込む他に、利便性、安定性、性能に優れたサーバーログ用エージェントである Logtail を提供しています。 Logtail には、Windows バージョンと Linux バージョンがあります。 マシングループを定義し、ログ収集の設定を完了すると、サーバーログをリアルタイムで収集できます。

ログ収集の設定が完了した後、プロジェクトのログを操作できます。

Logstash、Flume、FluentD、Beats など、他のログ収集エージェントと比較して、Logtail には次の利点があります。

  • 使いやすい：API、リモート管理機能、モニタリング機能を備えています。 Logtail は、100 万規模のサーバーログの収集と管理における Alibaba Group の豊富な経験をもとに設計されています。 これにより、数十万のデバイスの収集ポイントを短時間で設定できます。
  • さまざまな環境に適応：Logtail は、パブリックネットワーク、VPC、ユーザー作成 IDC をサポートします。 HTTPS と再開可能アップロード機能により、パブリックネットワーク上のデータと統合できます。
  • わずかなリソース消費で優れたパフォーマンス：長年の改良により、Logtail はパフォーマンスとリソース消費の点でオープンソースの競合他社よりも優れています。

迅速な障害特定

目的：データ量の増加やサーバーのデプロイ方法に関係なく、問題を特定するまでの時間が一定になるようにします。
たとえば、週ごとの TB レベルのデータから注文エラーや長い遅延問題をすばやく特定します。 このプロセスには、複数の条件に基づいたフィルタリングと調査も含まれます。
  1. たとえば、遅延が 1 秒を超えるリクエストで、なおかつ Post で始まるメソッドに関する遅延の詳細を AppLog で調査できます。 
    Latency > 1000000 and Method=Post*
  2. キーワード "error" を含み、キーワード "merge" を含まないログを検索します。

    • 1 日の結果

    • 1 週間の結果

    • より大きな期間の結果

      任意の期間の結果は、1 秒以内に返されます。

アソシエーション分析

アソシエーションには、イントラプロセスアソシエーションとインタープロセスアソシエーションの 2 つのタイプがあります。 2 つのタイプの違いは次のとおりです。
  • イントラプロセスアソシエーション：このタイプのアソシエーションは単純です。関数の古いログと新しいログが同じファイルに保存されるためです。 マルチスレッドプロセスでは、スレッド ID でログをフィルタリングできます。
  • インタープロセスアソシエーション：通常、複数のプロセスのログを処理する場合、明確な手がかりを見つけるのは困難です。 一般的に、アソシエーションは TracerId パラメーターをリモートプロシージャコール (RPC) に渡して実行されます。
  • コンテキストのアソシエーション

    Log Service コンソールでキーワードベースのクエリを実行して、エラーログを特定します。

    [コンテキスト表示] をクリックし、前後の結果を確認します。

    • より多くの結果を得るには、[古い] と [新しい] をクリックします。
    • キーワードを入力して結果を強調表示することもできます。
  • クロスプロセスアソシエーション

    クロスプロセスアソシエーション (トレーシング) の概念は、2010 年に Google が発表した有名な論文『Dapper, a Large-Scale Distributed Systems Tracing Infrastructure』までさかのぼることができます。 この論文に触発されて、オープンソース部門の開発者は、手頃な価格のトレーサーを数多く作成しました。 次のバージョンがよく知られています。

    • Dapper (Google)：すべてのトレーサーの基盤。
    • StackDriver Trace (Google)：ZipKin と互換性があります。
    • Zipkin：Twitter のオープンソーストレーシングシステム。
    • Appdash：Golang バージョンのトレーサー。
    • Hawkeye：Alibaba Group の Middleware Technology Department で開発されました。
    • X-ray：AWS re:Invent 2016 で発表されました。

    既存のシステムではトレーサーを適用する際のコストと課題があるため、トレーサーをゼロから適用する方が簡単です。

    Log Service をベースとして、基本的なトレーシング機能を実装できます。 必要なすべてのログを取得するには、異なるモジュールのログの相関フィールド (Request_id や OrderId など) を記録し、さまざまな Logstore のフィールドを検索します。

    たとえば、SDK を使用して、フロントエンドサーバー、バックエンドサーバー、支払いシステム、注文システムのログを検索できます。 結果が返されたら、フロントエンドにページを作成して、クロスプロセスコールを関連付けることができます。 次の図は、Log Service をベースに構築されたトレーシングシステムを示します。

統計分析

ログが特定された後、オンラインエラーログの種類の計算など、ログを分析できます。

  1. __level__ でログをクエリできます。 たとえば、1 日に 20 個のエラーが見つかっています。 
    __level__:error
  2. 固有のログタイプを判別するには、file フィールドと line フィールドに基づいてデータを分析、集計します。 
    __level__:error | select __file__, __line__, count(*) as c group by __file__, __line__ order by c desc

    エラーのすべてのタイプと場所の結果が返されます。

また、特定のエラーコードや高遅延の IP アドレスを特定し、分析できます。

他の機能

  • 監査のログバックアップ

    ストレージコストの低い Infrequent Access (IA) ストレージである OSS、または MaxCompute にログをバックアップできます。

  • キーワードアラート
  • ログクエリ権限管理

    RAM ユーザーまたはユーザーグループに権限を付与して、開発環境と本番環境を分離できます。

    価格とコスト：この方式では、AppLog は主に Log Service の LogHub と LogSearch を使用します。 オープンソース方式と比較して、この方式は使いやすく、オープンソース方式のわずか 25％のコストです。 これにより、開発効率が向上します。