AWS Athenaは表題の通り、S3にあるファイルをSQLで検索できるAWSのサービスで、
内部にはPrestoが使用されているそうです。
Athenaの利用
Athenaは東京リージョン(ap-northeeast-1)に対応していないので、東京リージョンからAthenaを選択すると、
と出ますが、対応しているリージョンを選択すればいいので使用することに問題はありません。
Atenaを利用するリージョンと異なるリージョンにあるS3バケットも、検索の対象にすることができます。
注意：
AthenaのリージョンとS3のリージョンが異なる場合、リージョン間通信料金がかかります。
詳しくは、S3の料金についてを参照ください。
テーブルの作成
今回は、米国東部リージョンを利用しました。
Athenaが利用可能だと以下のような画面が表示されます。
Query実行欄があるので直接Queryを書いてテーブルを作ることもできますが、
Hiveの記法で書く必要があり、Hiveを知らないので、
CatalogManagerに従ってテーブルを作成します。
CatalogManagerを押下して遷移する以下の画面で、Add tableを押下します。
Name & Location
この画面では、作成するテーブルを配置するデータベースやテーブル名、
およびテーブルの元になるS3バケットのパスを指定します。
今回、テーブルを作成した時のバケット構成は以下の通りです。
(CloudWatch Logs ＋ AWS Lambda で日付ごとインスタンス毎のログが.gzファイルに入っています。)
s3://xxxxxxxxxx-var-log-mssages/
┣━2016-12-29
┃ ┣━aws-logs-write-test
┃ ┗━5ce6a99c-bc8a-4af7-b818-061ed575183f
┃ ┣━i-03e629e997aa95f18
┃ ┃ ┗━000000.gz
┃ ┗━i-074549fdee10c46bc
┃ ┗━000000.gz
┗━2016-12-30
┣━aws-logs-write-test
┗━6c868fe1-d6ef-4d03-a6e0-4b2c89d1b44b
┣━i-03e629e997aa95f18
┃ ┗━000000.gz
┗━i-074549fdee10c46bc
┗━000000.gz
S3バケットで指定したパス以下にあるファイルがQuery対象のファイルになるので、
s3://xxxxxxxxxx-var-log-mssages/ 以下にあるファイルがQuery対象です。
Data Format
ここでは、テキストをテーブルの列として扱うために、
どのようなフォーマットで列を区切るか指定します。
CSVやTSV、正規表現等が使えます。
今回Athenaで検索対象とするテキストは以下のように記載されているため、
2016-12-30T13:46:43.279Z Dec 30 22:46:42 ip-172-16-2-115 dhclient[2069]: bound to 172.16.2.115 -- renewal in 1663 seconds.
2016-12-30T13:46:43.279Z Dec 30 22:46:42 ip-172-16-2-115 ec2net: [get_meta] Trying to get http://169.254.169.254/latest/meta-data/network/interfaces/macs/06:65:2d:4e:6d:cf/local-ipv4s
2016-12-30T13:46:43.280Z Dec 30 22:46:42 ip-172-16-2-115 ec2net: [rewrite_aliases] Rewriting aliases of eth0
先頭の時刻部分(CloudWatch Logsの時刻)とDec 30以降の部分(ログファイルの本体)との2列になるよう、
以下の正規表現で列の区切りを設定しました。
([0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}.[0-9]{3}Z) (.*)
Columns
Data Formatで設定した列の区切りに対して、列名と型を設定します。
今回の列の区切りでは、1列目と2列目を文字列とするため、
以下のように設定しました。
Partitions
テーブルのパーティショニングを行うかどうかの設定ですが、
今回はお試しなのでパーティショニングは設定しません。
（Athenaはスキャン量に応じて課金されるので、
実際に運用する場合はスキャン量を減らすためにパーティショニングをしたほうがよいそうです。）
テーブル作成
PartitionsでCreate tableを押下すると、
Query画面に戻され、先ほどまで設定した内容に基づいてSQLを作成・発行します。
検索
テーブルができましたので、
log_bodyにerrorの文字列が存在するものを検索します。
SELECT * FROM messages_log where log_body like '%error%' order by log_time desc;
従来のSQLの書き方で、ログファイルにerrorの文字が存在するものを抜き出すことができました。
最後に
使った感想ですが、やはりログファイルをSQLで検索できるのは、
エラー頻度やエラー解析を行うには便利なように感じました。
ただ、クエリでスキャンしたデータ量に対して課金されるので、
エラー解析のためにガンガンSQLを実行するのは難しいかと思います。