CloudWatchEvents + Lambdaを使ったfluentdインスタンスのローリングアップデート - Qiita
はじめに リクルートライフスタイル Advent Calendar 2016の2日目の記事ではELB経由のfluentd Aggregatorを安定化するためにやった3つの対策について書きました。 前記事で書いたようにAggregatorクラスタの数が増えて手動で行っていたデプロイが大変になってきました。また開発メンバーが増えたときに、デプロイ方法を共有してミスなく行えるようにするのも大変です。 そこでfluentd Aggregatorのローリングアップデートを自動化したくなり、CloudWatchEvents + Lambda + SQSで仕組みを作りました。 fluentdのデプロイ時に気をつけること fluentdはローカル上にバッファを持っているため、それを出力し終える前にインスタンスを落としてしまうと、ログのロストが発生します。 それを防ぐためにはバッファがなくなるまで待って、
Fluentd&Kinesis&Lambdaによる柔軟で高可用性なログ収集基盤の構築 - Qiita
概要 Fluentdによるログ収集基盤を、Lambda&Kinesisを利用した形で構成を変更したので、その時のメモ。 先に一言で感想を述べるのであれば、巷の噂通り、Kinesis&Lambdaは素敵でした。 Fluentd Aggregatorが抱える問題点 ログデータをFluentdのForwarder & Aggregatorを経由し、S3とRedshiftに保存するような構成でしたが、Aggregatorは冗長化しづらくボトルネックとなっていました。 ログ収集に求める要件 ログ収集の構成を改善するにあたり、先に挙げた目の前の問題点を解決するのは勿論ですが、他にも様々な要件があり、大別すると以下4つ。 信頼性: データをロスなく収集することができる。 安定性: ログ量に関係なく安定的なパフォーマンスを維持できる。 冗長性: 安全かつ簡単にスケーリングが可能 汎用性: 複数ログを複数サ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
