この記事はAltplus Advent Calendar 2017の9日目のエントリです。
こんにちは、サービスのインフラ周りの対応をしている橋本です。
ログの可視化や集計などで、複数サービスに適用を始めたので、
現在のログ運用の構成を書きたいと思います。
ログ運用について
構成
- fluend
- KinesisFirehose
- S3
- Athena + redash
ログ流れ
fluentd -> KinesisFirehose -> S3
ログ参照
redash -> athena -> s3
aws-cli -> athena -> s3
web -> athena
監視について
アラート用でボトルネックになる部分とAWSサービス側障害用で下記を監視しております。
- kinesisFirehose
- レコード取り込み数
- fluentd
- リトライ数
ログフォーマットについて
他のところにも使うかもしれなかったので加工複数の環境に対応できるよう、JSONフォーマットでの書き出しを行っています。
集計時
- DBのデータとのJOINしたいとき
- DBデータをTSV出力し、S3アップ後、Athenaのテーブル作成
テーブル
- kinesisFirehoseでS3保存時に作成されるディレクトリの日付毎でパーティションを何年分かを設定しています。
困ったところ
Athenaのテーブル設定でパーティションを始め、年、月、日で分けていたのですが、クエリを書きずらかったため、
20171212 などひとつのカラムに年月日の形で入れたほうがクエリが簡単になり便利でした
懸念
今後、Athenaで参照するデータがだいぶ増えた場合にクエリにだいぶ時間がかかるようにならないか心配で、
なったときは、bigqueryのほうに引っ越しを考えています。
クエリ
はじめ bigquery で運用していて、S3のログをGCS転送後そちらを bigqueryにロードするよう設定していました。
Athena側に移行する際に、日付パーティションの指定部分の違いとタイムゾーンの切り替えのところで少し悩んでいたので
where句のところをメモで残せればと思います。
- athena
# タイムゾーンのほう
SELECT date_format(time AT TIME ZONE 'Asia/Tokyo' , '%Y%m%d') as event_at,
# パーティションのほう
dt(パーティションのカラム) >= date_format((now() + interval '-30' DAY) AT TIME ZONE 'Asia/Tokyo' , '%Y-%m-%d') )
- bigquery
# タイムゾーンのほう
SELECT FORMAT_TIMESTAMP('%Y%m', time, 'Asia/Tokyo') AS date_time
# パーティションのほう
_TABLE_SUFFIX >= FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 365 DAY))
所感
- ログを集約して転送する部分のサーバがなく少し運用が楽になりました
- まだそこまでのログ量はないのですが、S3にデータを保存するのだと、 圧縮した状態で配置できるので、bigqueryに保存するよりもログ量が増えた際にお得になっていきそうに思います。