近年、ステートレスプログラミング、コンテナ、サーバレスプログラミングの登場により、ソフトウェアの配信とデプロイの効率が大幅に向上しました。 アーキテクチャの進化に伴い、次の変化がみられます。

  • アプリケーションのアーキテクチャは、単一のシステムから、マイクロサービス間の呼び出しとリクエストに移行しています。
  • 従来型の物理サーバーから、仮想リソースに移行しています。
図 1. 図 1.アーキテクチャの進化
上述の 2 つの変化より、柔軟な標準化されたアーキテクチャの、運用管理 (O＆M) と診断の要件がますます複雑化していることを示しています。 10 年前は、サーバーにログインすればすぐにログを取得することができました。 しかし、アタッチプロセスモードは、もはや存在しません。現在直面しているのは、標準化されたブラックボックスです。
図 2. 図 2. トレンドの変化

この変化に対応するために、DevOps 向けに、一連の診断および分析ツールが登場しました。 集中モニタリング、集中ログシステム、さまざまな SaaS 導入、モニタリング、およびその他のサービスがあります。

ログを一元化すると、これらの問題が解決します。 これを行うために、アプリケーションがログを生成したら、ログはリアルタイム (または準リアルタイム) に中央ノードサーバーに送信されます。 しばしば、Syslog、Kafka、ELK、および HBase を使用して集中ストレージを実行します。

一元管理の利点

  • 使いやすさ：Grep を使用して、ステートレスアプリケーションログを照会するのは面倒です。 集中型ストレージでは、以前の長いプロセスが、検索コマンドを実行することによって置き換えられます。
  • 独立したストレージとコンピューティング：マシンのハードウェアをカスタマイズするときは、ログ用のストレージスペースを考慮する必要はありません。
  • コストの削減：集中型ログストレージでは、より多くのリソースを予約するためにロードシフティングを実行できます。
  • セキュリティ：ハッカーの侵入や災害の場合、重要なデータは証拠として保持されます。
図 3. 図 3. 集中化の利点

Collector (Java 系列)

Log Service は、サーバー、モバイル端末、組み込み機器、およびさまざまな開発言語向けに 30 以上のデータ収集方法と包括的なアクセスソリューションを提供します。 Java 開発者は、使い慣れたログフレームワークである Log4j、Log4j2、および Logback Appender が必要です。

Java アプリケーションには現在、主に 2 つのログ収集ソリューションがあります。

  • Java プログラムは、ログをディスクにフラッシュし、Logtail をリアルタイム収集に使用します。
  • Java プログラムは、 Log Service によって提供される Appender を直接設定します。 プログラムが実行されると、ログはリアルタイムで Log Service に送信されます。

2 つの違い

ログをディスクに書き出す + Logtail を使ってログを収集する 直接送信に Appender を使用する
適時性 ログはファイルに書き込まれ、Logtail を使用して収集される。 ログは Log Service に直接送信される。
スループット 大きい 大きい
再開可能なアップロード サポート。 Logtail の設定によって異なる。 サポート。 メモリサイズによって異なる。
アプリケーションの場所にセンシティブ 収集マシングループを設定するときに必要。 不要。 ログは自発的に送信される。
ローカルログ サポート サポート
収集を無効にする Logtail の設定を削除。 Appender の設定を変更してアプリケーションを再起動。

Appender を使用すると、Config を使用して、コードを変更せずにリアルタイムなログ収集を簡単に完了できます。Log Service によって提供される Java 系列 Appender には、次の利点があります。

  • プログラムを変更することなく、設定変更が反映される
  • 非同期 +ブレークポイントの送信 ー I/O はメインスレッドに影響を与えることなく、ネットワーク障害およびサービス障害への耐障害
  • 高度に並行実行 ー 大量のログ書き込みに対応
  • コンテキスト照会が可能 − Log Service の元のプロセスで、ログのコンテキスト (ログの前後の N 個のログ) を正確に復元できます。

Appender の概要と使い方

以下の Appender が用意されています。データの書き込みには、すべて aliyun-log-producer-java が使用されています。

相違点

Appender 名 説明
aliyun-log-log4j-appender Log4j 1.x 用 Appender (アプリケーションがログのフレームワークに Log4j 1.x を採用している場合の推奨 Appender)
aliyun-log-log4j2-appender Log4j 2.x 用 Appender (アプリケーションがログのフレームパークに Log4j 2.x を採用している場合の推奨 Appender)
aliyun-log-logback-appender Logback 用 Appender (アプリケーションがログフレームワークに Logback を採用している場合の推奨 Appender)
aliyun-log-producer-java Java アプリケーション向けの LogHub クラスライブラリで、並行書き込みに使用されます。上記の Appender はすべて、本 Appender を使用してデータを書き込みます。なお、LogHub に書き込まれるデータのフィールドとフォーマットを指定することもできます。上記 Appender が要件を満たさない場合は、本 Appender を使用してログ収集プログラムを開発します。

手順 1. Appender と接続

「aliyun-log-log4j-appender」に記載の手順に従って、Appender と接続します。

設定ファイルlog4j.propertiesの内容は次のとおりです。 

log4j.rootLogger=WARN,loghub
log4j.appender.loghub=com.aliyun.openservices.log.log4j.LoghubAppender
# Log Service project name (required parameter)
log4j.appender.loghub.projectName=[your project]
# Log Service LogStore name (required parameter)
log4j.appender.loghub.logstore=[your logstore]
#Log Service HTTP address (required parameter)
log4j.appender.loghub.endpoint=[your project endpoint]
#(Mandatory) User identity
log4j.appender.loghub.accessKeyId=[your accesskey id]
log4j.appender.loghub.accessKey=[your accesskey]

手順 2. 照会/分析

上記の手順どおりに Appender を設定すると、Java アプリケーションの生成するログは自動的に Log Service に送信されます。LogSearch/Analyticsで、リアルタイムにログを照会/分析できます。例で使用するログフォーマットは次のとおりとなります。

  • ログイン操作が記録されたログ 
    level: INFO  
location: com.aliyun.log4jappendertest.Log4jAppenderBizDemo.login(Log4jAppenderBizDemo.java:38)
message: User login successfully. requestID=id4 userID=user8  
thread: main  
time: 2018-01-26T15:31+0000
  • 購入操作が記録されたログ 
    level: INFO  
location: com.aliyun.log4jappendertest.Log4jAppenderBizDemo.order(Log4jAppenderBizDemo.java:46)
message: Place an order successfully. requestID=id44 userID=user8 itemID=item3 amount=9  
thread: main  
time: 2018-01-26T15:31+0000

手順 3. 照会/分析を有効化

データを照会/分析する前に、照会/分析機能を使用可能にします。次の手順に従って機能を有効にします。

  1. Log Service コンソールにログインします。
  2. プロジェクト一覧ページで、プロジェクト名をクリックします。
  3. Logstore の右側の検索をクリックします。
  4. 右上の有効化 > 変更を順にクリックします。
  5. 既にインデックスを有効にしている場合は、インデックス属性 > 変更を順にクリックします。検索/分析ページが表示されます。
図 4. 図 4. クエリフィールドの指定

手順 4. ログ分析

  1. 1 時間以内にエラーが最も発生した上位 3 箇所を出力 
    level: ERROR | select location ,count(*) as count GROUP BY location ORDER BY count DESC LIMIT 3
  2. 直近 15 分以内のログレベルごとに、生成されたログの数を算出 
    | select level ,count(*) as count GROUP BY level ORDER BY count DESC
  3. ログ内容を照会

    どのログに対しても、元のログファイルのコンテキスト情報を正確に再構築できます。 詳細については、「コンテキスト照会」をご参照ください。

  4. 1 時間以内にログイン回数の最も多かったユーザー 3 名を出力 
    Login | select maid (message, 'userid = (? <userID>[a-zA-Z\d]+)', 1) AS userID, count(*) as count GROUP BY userID ORDER BY count DESC LIMIT 3
  5. 各ユーザーの直近 15 分以内の支払い総額を算出 
    order | SELECT regexp_extract(message, 'userID=(? <userID>[a-zA-Z\d]+)', 1) AS userID, sum(cast(regexp_extract(message, 'amount=(? <amount>[a-zA-Z\d]+)', 1) AS double)) AS amount GROUP BY userID