第二回iot関連技術勉強会 ログ収集編
Post on 12-Jan-2017
220 Views
Preview:
TRANSCRIPT
なぜログデータを収集するのか?• Webサービスにおける各イベント(アクセスした、ログインした、APIを叩いた、ページを離脱した、、、等)の情報が集められている• アクセスログ(Google Analytics、Apache/Nginx)• 購買履歴• アクティビティログ(ユーザの行動履歴)• クリックレート、コンバージョンレート
• 各イベント情報が入っているログを分析して新しい知見を得たい• サービス内容の改善(UI/UX、コンテンツのニーズ、仮説検証)• パフォーマンスの改善(レスポンス時間)
• アクセスのリアルタイムなモニタリング• システム障害の改善(障害検知、死活監視)• 不正なアクセスのブロック(Firewall的な役割)
リアルタイム vs バッチ
リアルタイム(ストリーム)• 少量データを逐次転送
※ストリーミング処理とか聞いたときは、リアルタイムにデータを処理している、と理解すればOK
バッチ• 任意の時間に起動• 大量データを一括転送
ログ収集に関する一般的な課題
• データの入力/出力方式がシステムによって様々• データフォーマット• 通信プロトコル
• ネットワーク/サーバ等の障害発生時のリカバリーの検討(リトライ処理等)
• データ量が増えた場合のスケーラビリティの検討(システムの柔軟性)
• リアルタイムで分析したい
Fluentd• ストリーム(リアルタイム)なログコレクタ(転送・集約)※ログ用のETL• C+RubyなOSS• Pluggable• シンプルな設定ファイル(Apacheに似ている)• Bufferingによる信頼性、Retry処理• 柔軟なシステム構成• TreasureDataが担っているOSS
出典: http://www.fluentd.org/architecture
Pluggable• プラグインをインストールするだけで、任意のプロトコル/ソフトウェアに対して入出力可能になる。• プラグイン自体もOSSなので、自由に利用・公開できる。→最近良く聞くエコシステムってやつ ※ちなみにSalesforceのpluginもあるよ
出典: http://www.fluentd.org/architecture
柔軟なシステム構成Aggregatorを介した多段構成(出力先を柔軟に変更可能)
キューを介したスケールするシステム構成
出典: http://repeatedly.github.io/ja/2014/07/fluentd-and-log-forwarding-patterns/
簡単な例ログデータをS3に格納(出力設定) Twitterのツイートデータを収集(入力設定)
<source>@type twitterconsumer_key {CONSUMER_KEY}consumer_secret {CONSUMER_SECRET}oauth_token {OAUTH_TOKEN}oauth_token_secret {OAUTH_TOKEN_SECRET}tag input.twitter.samplingtimeline trackingkeyword あああ,いいいoutput_format flat
</source>
<match input.twitter.sampling>@type s3
aws_key_id {AWS_ACCESS_KEY_ID}aws_sec_key {AWS_SECRET_KEY}s3_bucket {S3_BUCKET}s3_region ap-northeast-1path sakamichi/buffer_path /var/log/td-agent/s3time_slice_format %Y%m%d
s3_object_key_format %{path}%{time_slice}_%{index}.%{file_extension}
time_slice_wait 10mutcformat jsoninclude_time_key trueinclude_tag_key truebuffer_chunk_limit 8m
</match>
• プラガブルなので、さまざまなソースからのイベントをさまざまな媒体に出力できる
• ログの内容がJSON(MessagePack)形式で扱いやすい
fluentd vs syslogd
syslog(rsyslog)• サービスがログを記録するための規格、プログラム• ログの入出力を制御可能(Facility/Severity)• ネットワーク転送して別のサーバにログを集約可能
• Exactly Onceなデータ転送• 欠損も重複も一切ダメ→ストリーム処理でExactly Onceを保証するのは難しい(らしい)
ただし、大抵はExactly Onceでなくても上手くいく(らしい)↓http://docs.fluentd.org/articles/high-availability
• 負荷のかかるフィルタリング(fluentd自体がマルチプロセス対応しそうなので、それを待てば良い?)
• モニタリング(死活監視)→プラグインにZabbix, Nagios, Norikra等あるので、そちらに流し込んでモニタリングする。fluentdはデータのハブとして利用する。
Fluentdが適していないもの
• Fluentdのバッチ版
• 並列処理をすることで高速なアップロードを実現
• Fluentd同様プラガブルなアーキテクチャ→Salesforceのプラグインもあるよ
• リトライ/エラーハンドリング→利用するプラグインに依存するけど…
• 設定ファイルをある程度自動的に作成してくれる仕組み(guess)
• TreasureDataが担っているOSS
Embulk
バッチ実行は $ embulk run config.yml を叩くだけ!
Embulkの設定例in:
type: s3bucket: {backet_name}path_prefix: sakamichi/2016/05/01endpoint: s3-ap-northeast-1.amazonaws.comaccess_key_id:{AWS_ACCESS_KEY_ID}secret_access_key: {AWS_SECRET_ACCESS_KEY}decoders:- {type: gzip}parser:
type: jsonlcharset: UTF-8newline: CRLFcolumns:- {name: id_str, type: string}- {name: text, type: string- {name: favorited, type: boolean}
filters:- type: typecast
columns:- {name: timestamp_ms, type: long}
out:type: tdapikey: {TREASURE_DATA_API_KEY}endpoint: api.treasuredata.comdatabase: test_sakamichitable: testtime_column: timestamp_msunix_timestamp_unit: milli
• Fluentd/Embulkはログデータのデータ転送/集約系のOSSである
• Fluentdはリアルタイム、Embulkはバッチ
• どちらもプラガブルなアーキテクチャでエコシステムを形成→開発者はプラグインを作る or エンハンスしていきましょう!
まとめ
• Fluentの概要http://www.slideshare.net/treasure-data/the-basics-of-fluentd-35681111
• Fluentdのデザインパターンhttp://www.slideshare.net/y-ken/fluentd-system-design-patternhttp://repeatedly.github.io/ja/2014/07/fluentd-and-log-forwarding-patterns/
• AWS Summit 2016で登壇されていたcookpadさんの資料https://speakerdeck.com/kanny/miao-jian-shu-mo-falseroguwoiigan-zinisuruakitekutiya
• Embulkの概要http://www.slideshare.net/frsyuki/embuk-making-data-integration-works-relaxed
参考URL
top related