ガイド

生のIPアドレスのログからヒートマップを作成する

IPアドレスが並ぶアクセスログには実際の地理情報が埋もれていますが、それが使えるのは、各アドレスが地図ツールで実際に描画できる座標に解決されてからです。

ログからアドレスを抽出する

ログの行を1行ずつ個別に検索するのではなく、まずログファイルから一意のIPアドレスを取り出してください。同じ訪問者のアドレスは1つのセッションの中で何度も現れるのが普通であり、同じ検索に繰り返し料金を払う理由はないからです。

sort logfile.txt | awk '{print $1}' | sort -u > unique_ips.txt

一括で解決する

一意のアドレスのリストを一括POSTの配列として/v1/ipに送信します。

POST /v1/ip
Content-Type: application/json

["203.0.113.10", "198.51.100.25", "192.0.2.44"]
{
  "status": "ok",
  "results": [
    {"ip": "203.0.113.10", "version": 4, "found": true, "country": "Germany", "country_code": "DE", "region": "Berlin", "city": "Berlin", "postcode": "10115", "lat": 52.5300, "lon": 13.3800, "timezone": "Europe/Berlin", "asn": 1111, "org": "Example ISP"},
    {"ip": "198.51.100.25", "version": 4, "found": true, "country": "Spain", "country_code": "ES", "region": "Madrid", "city": "Madrid", "postcode": "28001", "lat": 40.4168, "lon": -3.7038, "timezone": "Europe/Madrid", "asn": 2222, "org": "Example Networks"},
    {"ip": "192.0.2.44", "version": 4, "found": false}
  ]
}

ヒートマップのデータセットを作る

返された各latとlonを、ログ内での元のアドレスの出現回数と組み合わせます。そうすれば、ログに100回現れる訪問者は、1回しか現れない訪問者よりも比例して大きな重みを持ちます。こうしてできた重み付きの座標点のリストを、ヒートマップの描画に使う地図ツールやグラフツールに渡します。

2つ目の例:代わりに国別の内訳を作る

1点ずつの正確なヒートマップが必要以上に詳細な場合は、生の座標ではなくcountry_codeで集計すると、点が散らばった雲ではなく国ごとに1つの数値を示す、よりシンプルなコロプレス風の表示になります。これはまったく同じ一括検索を使い、結果が返ってから別の方法でグループ化するだけなので、同じ解決済みデータから両方の表示を作っても追加のコストはかかりません。

解決できないアドレスの扱い

上の3番目の結果のようにfound: falseとなった項目は、初期値の場所に描画するのではなく、単にヒートマップから除外してください。これを含めると、解決できなかったトラフィックが、実際の発信元とは関係のない地図上のどこかに集まり、誤解を招くからです。

避けるべきよくある間違い

一意のアドレスのリストを作る前に、固定のアドレスからサーバーに絶えずアクセスする社内のヘルスチェックや監視サービスなど、明らかに訪問者ではないトラフィックを除外する手順を省かないでください。毎分ポーリングする監視サービスは、実際の訪問者の地理とは関係のないログの行を不釣り合いに多く積み上げることがあります。重複を除けば解決される点は1つに限られますが、その1つの点でも、それが表す実際のトラフィックのパターンに見合わないほど、ヒートマップの見た目を支配してしまうことがあります。

エッジケース:ホスティングやデータセンターからのトラフィック

解決したアドレスのorgフィールドからは、トラフィックが家庭やモバイルの接続ではなく、データセンターやクラウドホスティングの範囲から来ていることがわかる場合がよくあります。これは、実際の訪問者の所在地を表すためのヒートマップを歪める前に、ボットやスクレイパーのトラフィックを除外するための妥当な手がかりです。

コスト

ログの行をすべて解決するのではなく一意のアドレスを解決することが、コストを抑える鍵です。リクエストのコストはログの1行ごとではなく、一意のアドレスごとに1件だからです。100万行あっても一意の訪問者のアドレスが数千件しかないログのコストは、100万リクエストではなく数千リクエストです。大規模なサイトならプリペイドクレジットやUnlimitedパッケージで十分に管理でき、小規模なサイトなら無料の割り当ての範囲内に収まることもよくあります。大きなバッチジョブの実行中にX-Quota-Usedヘッダーを見ておけば、ジョブが終わる前に利用量が想定どおりに推移しているかを簡単に確認できます。

解決する前に重複を除くことが、ログを基にしたヒートマップのコストを抑えるための最大の手段です。一括リクエストの形式の詳細はIPv4検索のドキュメントで説明しています。