Web サイトのデータを分析したい場合は、まず Web サイトのデータがどこから来たのかを知る必要があります。
ユーザーがインターネットにアクセスすると、サービス リクエストがサーバーに送信されます。送信されたリクエストは、サーバーによって別のレコードのサーバー ログに記録されます。これは、最もオリジナルな Web サイト データ ログです。
まずはApacheのログを見てみましょう
10.1.1.95 - ユーザー [18/Mar/2005:12:21:42 +0800] “GET /stats/awstats.pl?config=user HTTP/1.1” 200 899 “http://10.1.1.1/pv/” 「Mozilla/4.0 (互換性、MSIE 6.0、Windows NT 5.1、Maxthon)」
上記はApacheの標準ログです。
このコンテンツ行は 9 つの項目で構成されています。上の例では 2 つの項目が空白ですが、コンテンツ行全体は 9 つの項目に分割されています。
· 最初の情報はリモート ホストのアドレスです。つまり、訪問者のマシンの IP です。サーバーは、この IP に基づいて応答情報を訪問者に送信します。
· 2 番目の項目は空白で、「-」プレースホルダーに置き換えられます。実際、これはほとんどの場合当てはまります。この場所は、訪問者の識別情報を記録するために使用されます。これには、訪問者のログイン名だけでなく、訪問者の電子メール アドレスやその他の一意の識別子も含まれます。この情報は identd によって返されるか、ブラウザによって直接返されます。初期の頃、この場所には視聴者の電子メール アドレスが記録されることがよくありました。しかし、一部の人々が電子メール アドレスを収集してスパムを送信するためにこの機能を使用したため、この機能は長くは続かず、市場に出回っているほとんどすべてのブラウザはずっと前にこの機能を削除しました。したがって、今日の時点では、ログの 2 番目のエントリに電子メール アドレスが表示される可能性はほとんどありません。
· 3 番目の項目も user です。この場所は、認証時に訪問者が指定した名前を記録するために使用されます。もちろん、Web サイト上の一部のコンテンツでユーザーの認証が必要な場合、この情報は空白にはなりません。ただし、ログイン検証を必要としないほとんどの Web サイトでは、ログ ファイル内のほとんどのレコードでこのエントリは空白のままです。
· ログに記録される 4 番目の項目は、リクエストの時刻です。このメッセージは角括弧で囲まれており、「共通ログ形式」または「標準英語形式」と呼ばれるものです。したがって、上記の例のログ レコードは、リクエストの時刻が 2005 年 3 月 18 日 12:21:42 であることを示しています。時刻情報の末尾にある「+0800」は、サーバーのタイムゾーンがUTCから8時間遅れていることを示しています。実際、国内サーバーの時刻は+8000です。
· ログ レコードの 5 番目の情報は、おそらくログ レコード全体の中で最も有用な情報であり、サーバーが受信したリクエストの種類を示します。この情報の一般的な形式は「メソッド リソース プロトコル」です。
上記の例では、メソッドは GET です。他によく使用されるメソッドは POST と HEAD です。法的手段としてはさまざまな方法が考えられますが、主なものは次の 3 つです。
リソースとは、ブラウザがサーバーに要求するドキュメントまたは URL を指します。この例では、ブラウザは「/stats/awstats.pl?config=user」をリクエストしました。
通常、プロトコルは HTTP で、その後にバージョン番号が続きます。
· ログに記録される 6 番目の情報はステータス コードです。リクエストが成功したかどうか、またはどのようなエラーが発生したかがわかります。ほとんどの場合、この値は 200 です。これは、サーバーがブラウザのリクエストに正常に応答し、すべてが正常であることを意味します。一般に、2 で始まるステータス コードは成功を意味し、3 で始まるステータス コードはさまざまな理由でユーザー リクエストが別の場所にリダイレクトされたことを意味し、4 で始まるステータス コードはクライアント側で何らかのエラーが発生したことを意味します。 4 で始まるステータス コードは、クライアント側で何らかのエラーが発生したことを意味します。5 で始まるステータス コードは、サーバーでエラーが発生したことを示します。
· ログ レコードの 7 番目のエントリは、クライアントに送信された合計バイト数を表します。転送が中断されたかどうか (つまり、値がファイルのサイズと同じかどうか) がわかります。ログ レコード内のこれらの値を合計すると、サーバーが 1 日、1 週間、または 1 か月に送信したデータの量がわかります。
· ログ レコードの 8 番目の項目には、顧客がリクエストを行ったときにいたディレクトリまたは URL が記録されます。今回は10.1.1.1のpvディレクトリ配下のホームページ「http://10.1.1.1/pv/」です。ほとんどの場合、ホームページは、httpd.conf の DocumentRoot ディレクティブの後に指定された種類と名前の Web ファイルになります。
· ログ レコードの 9 番目の項目は、クライアントの詳細情報を表します。
以上がApacheのログレコードの説明です。
次に、IIS ログに切り替えます。レコードは同様です。ただし、identd によって返されるログイン認証は常に空であるため、送受信される Cookie の内容になっており、追加のサブ状態の内容がいくつかあります。プロトコル。
上記からわかるように、分析したデータのほとんどは取得できますが、ユーザーがブラウザの「進む」ボタンと「戻る」ボタンをクリックすると、クライアントのブラウザが最初にキャッシュを読み取り、それを見つけるだけであるという問題がまだいくつかあります。したがって、ユーザーが「戻る」または「進む」をクリックした後にサーバーがページを記憶できるかどうかは、ページの記述方法とマシンのステータスに完全に依存します。
元のログを分析に使用する場合、ifram などの小さなページが個別にリクエストされるため、ページを開くためのリクエストの数が必ずしも 1 にならない場合があります。これは、元のログの欠点の一部でもあります。
同時に、これらの記録は主にサーバーのステータスとサーバーのセキュリティを追跡することが目的であり、一部のデータは記録されません。
・ページ間の関係は記録されず、ユーザーがどのページからアクセスしたかは関係ありません。
· 特にアクセスする必要のない Web サイトの場合、ユーザーによる特定の訪問を区別することは不可能です。
・ページ操作、特にクリック操作は記録できません。
そのため、一部の Web サイトは独自の記録方法を開発しており、通常は JS を使用するか、この情報を記録するために 1 ピクセルの画像のリクエストを使用します。
このようにして、訪問したソース ページの参照元、セッション番号、Cookie 番号、クリックによって生成されたデータなど、いくつかの情報が記録されます。これらのデータはデータベースに直接記録できます。
この方法を使用すると、分析の難易度が下がり、分析できる情報が増加しますが、ある程度の精度は犠牲になります。得もあれば損もあるとも言えます。
・1つ目は記録可能なデータで、クライアント側で生成されるため、サーバーエラーが発生するとデータが100％失われますが、どうすればデータを出力できるでしょうか。また、データを送信するためには js を起動する必要があるため、ある程度のデータは失われますが、サーバーの状態が悪くなければ、一般的に 98% の精度が許容されます。
· ページジャンプとプロトコルの関係により、ソースページのデータは依然として失われますが、さらに問題なのは、https ページは暗号化されたプロトコルを使用して送信されることです。どのような方法を使用しても、http ページでは失われます。
· ページ上の言語やプロトコル、Ajax、js などに大きく影響され、記録の精度に影響を与える可能性があります。
· 最後に、すべてのページにコードを追加する必要があります。ページ数が多い場合、そのページを忘れるとデータ全体に影響を及ぼします。
· マシンの IP が見つからない場合、複数のマシンが IP を共有している場合、記録されるのはユーザーの最終マシンの IP と異なります。インターネットアクセスルート上のIP。
以上をまとめると、Web サイトの分析は、データの取得方法と Web サイト独自のプログラミング方法との関係が比較的複雑であるため、Web サイトのデータを分析する場合には、どの時点でもデータの障害や落とし穴が発生する可能性があるため、より注意が必要です。時間。
記事ソース：ランスのノート