ログ解析手法の概要-php手册-php.cn

ログはコンピュータシステムにおける非常に幅広い概念です。オペレーティングシステムのカーネル、さまざまなアプリケーションサーバーなど、あらゆるプログラムがログを出力する可能性があります。ログの内容、サイズ、目的も異なるため、一般化することが困難です。

この記事で説明するログ処理方法のログは、Web ログのみを指します。実際、正確な定義はありません。これには、Apache、lighttpd、tomcat などのさまざまなフロントエンド Web サーバーによって生成されるユーザーアクセスログや、さまざまな Web アプリケーション自体によって出力されるログが含まれますが、これらに限定されません。

Web ログでは、通常、各ログはユーザーのアクセス動作を表します。たとえば、次は典型的な Apache ログです。

211.87.152.44 – - [18/Mar/2005:12:21:42 +0800] “GET / HTTP/1.1” 200 899 “http://www.baidu.com/” “Mozilla/4.0 (互換性; MSIE 6.0) ; Windows NT 5.1;

上記のログから、訪問者の IP、訪問時刻、訪問先の Web ページ、ソースアドレス、訪問者が使用したクライアントの UserAgent 情報など、多くの有用な情報を取得できます。より多くの情報が必要な場合は、他の手段を使用して情報を取得する必要があります。たとえば、ユーザーの画面の解像度を取得したい場合は、通常、js コードを使用して別のリクエストを送信する必要があります。ユーザーがアクセスした特定のニュースタイトルなどの情報を取得するには、Web アプリケーションが必要になる場合があります。プログラムは独自のコードを出力します。

なぜログを分析する必要があるのか

Web ログには、人々 (主に製品アナリスト) が興味を持つであろう大量の情報が含まれていることは間違いありません。最も単純には、Web ログで各ページの PV 値 (PageView、ページビュー) と独立した IP 番号を取得できます。ウェブサイト (つまり、重複排除後の IP 数) など、もう少し複雑な場合は、ユーザーが検索したキーワードのランキング、ユーザーが最も長く滞在したページなどを計算できます。複雑なものでは、広告クリックモデルを構築し、ユーザーの行動特性などを分析します。

これらのデータは非常に有用であるため、もちろん、awstats や Webalizer など、データの分析に役立つ既製のツールが無数にあります。これらのツールは、Web サーバーログの統計分析に特に使用される無料のプログラムです。

直接ログを解析するのではなく、ユーザーがページ内にjsコードを埋め込むことで直接データ統計を行うタイプの製品もありますし、ログを直接サーバーに出力すると考えることもできます。代表的な製品としては有名なGoogle Analyticsをはじめ、国内のcnzzやBaidu Statisticsなどが挙げられます。

この場合、なぜ自分でログを分析する必要があるのかと疑問に思う人も多いでしょう。それは当然のことです。ユーザー (製品アナリスト) のニーズは無限にありますが、上記のツールは非常に優れており強力ですが、すべてのニーズを満たすことができないことは明らかです。

ローカル分析ツールであれ、オンライン分析サービスであれ、豊富な統計分析機能が提供され、ある程度の設定は可能ですが、機能は依然として非常に限られています。もう少し複雑な分析を実行したい場合、またはログベースのデータマイニングを実行したい場合は、やはり自分で行う必要があります。

また、ほとんどのログ分析ツールは1台のマシンでしか利用できず、データ量が少し大きくなると役に立たなくなります。同時に、オンライン分析を提供するサービスには通常、単一サイトの最大トラフィック制限があり、サーバーの負荷も考慮する必要があることは容易に理解できます。

したがって、依然として多くの場合、自分自身に頼らなければなりません。

ログ分析の実行方法

これは単純な質問ではありません。「ログ」を Web ログに限定したとしても、そこには依然として数千の可能な形式とデータが含まれていますが、「分析」を定義するのはさらに難しく、統計値の単純な計算である場合もあれば、複雑なデータマイニングである場合もあります。アルゴリズム。

以下では、これらの複雑な問題について説明することは意図しておらず、ログ分析の基礎を構築する方法について一般的に説明するだけです。これらの基盤があれば、ログに基づく単純な統計分析が非常に簡単になり、複雑な分析やマイニングが可能になります。

データ量が少ない場合

まず、データサイズが比較的小さい場合 (つまり、単一マシンの処理がまだ耐えられる場合) を考えてみましょう。 awk、grep、sort、join などのさまざまな既製の Unix/Linux ツールはすべて、ログ分析のための強力なツールです。特定のページの PV を知りたい場合は、wc+grep だけで済みます。できるよ。多少複雑なロジックがある場合は、さまざまなスクリプト言語、特に Perl を使用し、優れた正規表現を使用すると、基本的にすべての問題を解決できます。

たとえば、上記の Apache ログから最もアクセス数の多い IP の上位 100 件を取得したいとします。実装は非常に簡単です。

cat logfile awk ‘{a[$1]++} END {for(b in a) print b”t”a[b]}’sort -k2 -rhead -n 100

ただし、ログを頻繁に分析する必要がある場合、上記のアプローチでは、しばらくすると、さまざまなログファイル、分析用のスクリプトファイル、crontab ファイルなどをどのように管理するかについて頭が痛くなることがあります。現時点では、データベースなどのより適切なものが必要になる場合があります。

もちろん、ログ分析にデータベースを使用するには多少のコストがかかります。最も重要なことは、さまざまな異種ログファイルをデータベースにインポートする方法です。このプロセスは通常、ETL (抽出、変換、読み込み) と呼ばれます。幸いなことに、これを行うのに役立つさまざまな既製のオープンソースや無料のツールがまだあり、ログの種類がそれほど多くない場合は、作業を完了するための簡単なスクリプトをいくつか書くことは難しくありません。たとえば、上記のログから不要なフィールドを削除して、次のデータベースにインポートできます:

次に、このデータを保存するためにどのデータベースを使用するかを検討する必要があります。 MySQL は非常に古典的なオープンソースデータベースであり、その従来のエンジン (MyISAM または InnoDB、行ストレージ) はログデータのストレージにはあまり適していない可能性がありますが、データ量が少ない場合にはそれでも十分です。さらに、この点に関しては、オープンソースの無料の Infobright や Infinidb などのより良い選択肢が存在します。これらは、列ストレージを使用し、優れたデータ圧縮を備え、数百のデータエンジンを処理します。 1 GB のデータ量は基本的に問題ありません。

データベースを使用する利点の 1 つは、優れた SQL により統計分析作業のほとんどを非常に簡単に完了できることです。PV には SELECT+COUNT のみが必要で、検索語のランキングの計算には SELECT+COUNT+GROUP+ORDER+LIMIT のみが必要です。さらに、データベース自体の構造化されたストレージモデルにより、ログデータの管理が簡素化され、運用とメンテナンスのコストが削減されます。

上記と同じ例は、単純な SQL で実行できます:

SELECT * FROM (SELECT ip, COUNT(*) AS ip_count FROM apache_log GROUP BY ip) a ORDER BY ip_count DESC LIMIT 100

パフォーマンスの問題に関しては、通常、データベースインデックスとさまざまな最適化メカニズムにより、統計分析の作業が高速化されます。また、前述の Infobright と Infinidb は、SUM や COUNT などの集計アプリケーション向けに特別に最適化されています。もちろん、絶対に速いというわけではありません。たとえば、データベースで LIKE 操作を実行するのは、通常、ファイルを grep するよりもはるかに遅くなります。

さらに、データベースベースのストレージを使用すると、OLAP (オンライン分析処理) アプリケーションを簡単に実装でき、ログからの価値のマイニングが容易になります。

データが増えたらどうするか

優れたデータベースを使用すると、物事が非常にシンプルになるように見えますが、前述のデータベースはすべてスタンドアロンデータベースであることを忘れないでください。単一マシンには、ストレージ容量と同時実行性の点で大きな制限があることは疑いの余地がありません。ログデータの特性の 1 つは、時間の経過とともに増加し続けることであり、多くの分析プロセスでは履歴データが必要になることがよくあります。短期的な増加は、サブデータベース、テーブル、またはデータ圧縮によって解決される可能性がありますが、明らかに長期的な解決策ではありません。

データ規模の増大によって生じる問題を完全に解決したい場合、上記の結論に基づいて、分散テクノロジーの使用を考えるのは自然なことです。分散データベースを使用することは、完全に透過的である可能性があります。エンドユーザー。これは確かに理想的な状況ですが、現実はしばしば残酷です。

まず、比較的完璧な分散データベース (CAP 原則によって制限される) の実装は非常に複雑な問題です。したがって、スタンドアロンデータベースとは異なり、ここで利用できるオープンソースの優れたものはそれほど多くなく、商用のデータベースでさえありません。過度に。もちろん、それが絶対というわけではありませんが、お金に余裕があれば、Oracle RAC や Greenplum などを検討することもできます。

第二に、分散データベースの大部分は NoSQL であるため、基本的に SQL の利点を引き続き使用することは期待できず、代わりに、いくつかのシンプルで使いにくいインターフェイスに置き換えられます。この観点だけからしても、これらのデータベースを使用する価値は大幅に減少しています。

したがって、データ規模が小さい場合のように分析を簡単にする方法を考えるのではなく、まず現実的に考えて、非常に大規模なログの分析問題を解決する方法を一歩下がって検討することをお勧めします。これをやりたいだけでは、現時点ではそれほど難しいことではないようです、そして、無料で食べられるランチはまだあります。

Hadoop は偉大な Apache Foundation の下にある分散システムであり、分散ファイルシステム (HDFS)、MapReduce コンピューティングフレームワーク、HBase、その他多くのコンポーネントが含まれています。これらは基本的に Google の GFS/MapReduce/BigTable のクローンです。

数年間の開発を経て、Hadoop は、特に HDFS および MapReduce コンピューティングフレームワークコンポーネントにおいて非常に成熟しました。数百台のマシンからなるクラスターは、ペタバイト規模のデータを処理できることが証明されています。

Hadoop プロジェクトの HBase は、列に格納された NoSQL 分散データベースであり、提供される関数とインターフェイスは非常に単純で、単純な K-V クエリのみを実行できるため、ほとんどのログ分析アプリケーションには直接適していません。したがって、Hadoop をログ分析に使用する場合は、まずログを HDFS に保存し、次に HDFS が提供する MapReduce API を使用してログ分析プログラムを作成する必要があります。

MapReduce は分散プログラミングモデルであり、習得は難しくありませんが、これを使用してログを処理するコストは、スタンドアロンスクリプトや SQL よりも依然としてはるかに高いことは明らかです。単語頻度統計の単純な計算には、複雑な環境の準備と起動スクリプトに加えて、わずか 1 行の SQL だけで数百のコードが必要になる場合があります。

たとえば、上記と同じ例では、実装ははるかに複雑で、通常、完了するまでに 2 ラウンドの MapReduce が必要です。まず、マッパーの最初のラウンドでいくつかの IP のアクセス時間の合計を計算し、IP をキーとして出力します。

//入力を走査し、結果を集計します

foreach(入力に記録) {

ip = 記録.ip;

dict[ip]++;

}

//出力にエミットを使用します。最初のパラメータはキーで、配布を減らすために使用されます

foreach( 辞書内) {,>

Emit(ip, count);

}

次に、reduce の最初のラウンドで、各 IP の完全な数を取得し、それを並べ替えて、最初の 100 個だけを保持することができます。

カウント = 0;

//各キー (ip) について、すべての値 (カウント) を走査し、累積します

while(input.values.hasNext()) {

カウント += input.values.next();

}

// サイズ 100 のヒープに挿入

heap_insert(input.key, count);

Reduce の最後の出力:

//現在のreduceで最大数の100個のIPを出力します

foreach( 辞書内) {,>

Emit(ip, count);

}

一般にリデューサーが多数あるため、最終的な上位 100 個の IP と対応する訪問数を取得するには、すべてのリデューサーの出力をマージして並べ替える必要があります。

したがって、ログ分析に Hadoop を使用することは明らかに簡単な問題ではありませんが、追加の学習コストと運用保守コストがかかりますが、少なくとも超大規模なログ分析が可能になります。

シンプルになる方法

ログ分析を含め、超大規模なデータに対して何かを行うのは簡単ではありませんが、分散ログ分析では MapReduce コードを作成する必要があるというわけではありません。アプリケーションを使用すると、作業が簡単になります。

SQLを使ってHadoop上のデータを操作できたらいいのに、と自然に考える人もいるかもしれません。実はそう思っているのはあなただけではなく、多くの人がそう思っていて、その考えに気づいてHiveが誕生したのです。

Hive は、Hadoop プロジェクトのサブプロジェクトにもなりました。これにより、SQL インターフェイスを使用して MapReduce を実行できるようになり、JDBC および ODBC インターフェイスも提供されます。これにより、Hadoop は基本的にデータベースにパッケージ化されます。もちろん、Hive の SQL は実際には実行のために最終的に MapReduce コードに変換されるため、最も単純な SQL であっても実行には数十秒かかる場合があります。幸いなことに、通常のオフラインログ分析では、この時間はまだ許容範囲内です。さらに重要なのは、上記の例では、同じ SQL を使用して分析タスクを完了できることです。

もちろん、Hive は SQL 構文と完全に互換性があるわけではなく、ユーザーを詳細から完全に守ることはできません。多くの場合、実行パフォーマンスを最適化するには、ユーザーが MapReduce の基本的な知識を理解し、独自のアプリケーションモードに従っていくつかのパラメーターを設定する必要があります。そうしないと、クエリの実行が非常に遅くなるか、まったく実行できない場合があります。。

さらに、Hive がすべての要件をカバーできないことは明らかなので、拡張用に元の MapReduce コードを挿入するためのインターフェイスがまだ保持されています。

その他の質問

Hive のようなデータベースのようなものがあっても、やるべきことはまだたくさんあります。たとえば、時間の経過とともに、定期的に実行する必要がある SQL が増え、これらの SQL の一部は反復的な処理を行う可能性があり、実行効率が非常に低いものもあり、すべてのコンピューティングリソースがいっぱいになると、複雑な SQL が発生する可能性があります。。このようなシステムの保守はますます困難になり、ある日、日常的な SQL が実行できなくなるでしょう。エンドユーザーは、これらのことを気にしないことが多く、送信したクエリが即座に応答を得ることができるかどうか、およびできるだけ早く結果を取得する方法だけを気にします。

簡単な例を挙げると、apache_log を使用するすべてのクエリで user_agent フィールドを使用している人がほとんどいないことが判明した場合、このフィールドを完全に削除するか、2 つのテーブルに分割して、ほとんどのクエリの IO 時間を短縮し、実行効率を向上させることができます。

これらの問題を体系的に解決するには、日常的なタスクにスケジューリングメカニズムを導入する必要がある場合があります。また、すべての SQL を分析して、どの SQL をマージできるか、どのパフォーマンスを最適化する必要があるか、使用するデータテーブルにマージが必要かどうかを確認する必要がある場合があります。水平サブテーブルまたは垂直サブテーブルなどになります。実際の状況に応じて、手動で作業を行うことも、自動的に分析して調整するプログラムを作成することもできます。

さらに、ログの種類と分析のニーズは継続的に増加しています。必要なデータがどのログに含まれているかを見つけるのが難しい、またはログ形式の変更により正常に実行されていたクエリが突然使用できなくなったと不満を抱くユーザーがますます増えています。また、上記の ETL プロセスも複雑になり、単純な変換およびインポートスクリプトでは問題を解決できない可能性があります。現時点では、データ管理システムを構築するか、いわゆるデータウェアハウスの構築を検討する必要があるかもしれません。

つまり、ログデータの量、ログの種類、ユーザー数、分析ニーズなどが増加するにつれて、ログ分析は当初考えられていたほど単純ではなくなる可能性があります。ますます価値があり、挑戦的なものになります。