サーバ・インフラエンジニア養成読本 ログ収集~可視化編 勉強会
最近、行ってきたブログばかり。。。
もうちょいがんばりたい。。。
サービス改善はログデータ解析から
すずけんさん @suzu_v adingo
- 分析はコアだ
- データの分析はチームで作るもの
そして、データを活かせるようにするエンジニアが必要 - 収集、変換、保存、分析、表示、運用
- 「ログ分析は後にして機能追加をしましょう」ありがち
- とりあえずやってると何とかなる
可視化してから考えよう - チームとして「データを活かそう」というスタンスにならないと進まない
Fluentd
よしけんさん @yoshi_ken y-ken リブセンス
- 再送処理など、ネットワーク周りの例外は任せられる
- Rubyを用いたプラグイン記述のハードルは低い
- ログ収集コストの最小化
時差もなくなる - tailプラグインはファイルのローテーションにも対応
- レイテンシの改善、帯域バーストの緩和
- ファイルやDBといった複数データストアへの保存も可能
- QoS レベル At Most One
- 変更のないシンプルな処理のみを担うといい
- 各ノードは単一責任がいい
- 転送元ノード
- 集約ノード(Aggregator)
- Processor
- Watcher
- シングル構成や複数構成も組める
- 固い運用には向き不向きがある
Elasticsearchもうちょっと入門
@johtaniさん
- サジェストもあるんだ
- クラスタの監視もできる?
- Logstash 1回 Redisにため込む!?
- aggregation
- 階層的な集計、グループ化
- 動的な集計、グループ化
- Bucket ドキュメントのある値ごとに結果をグルーピング
男性、女性など - Metric ドキュメントの持つ値を集計
ツイートの文字数の平均、最大値最小値とか
Kibana
みちいしゅんすけさん @harukasan pixiv
- 17回/1日 デプロイ
- グロースチーム
- サービスのグロースのためになんでもやる人たち
- 可視化も継続的デリバリーの手段の一つ
- fluent-plugin-elasticsearch作者
- 3割くらいが使っている
- クエリ:ログを検索
- フィルタ:すべてのクエリに適用
- パネル:どう表示するか
- Dashboard
見たい数値が1画面に収まっている
1つのデータに対して複数の面から分析する
毎日・毎週継続して変化をみることができる - タグ deployとかイベントを
Trends 1週間前との傾向
つくってから「Share」で一時URL
ミーティングなどで見るようにする- GoogleBigQueryを間にかましてデータ量を絞る
パネルディスカッション
サーバ/インフラエンジニア?
- 趣味でいれた
- ログエンジニアがいた
ログ解析
- システムモニタリング
- ビジネス側の話
前はGoogleAnalyticsとか、体系化された方法があったわけではないと。
- GrowthForecastとか
- DataWareHouse / BI (たぶろー)
- EFK は DataWareHouseのモダン版
データどうしてる?
- ため込んだやつ消してます or 閉じてしまう
- 生データはS3
- 直近版と長期版2段階構成が定番
A・Bテストしてたら数値しか見なくなった
直感というか感覚も大事。数値は一つの指標Elasticsearch使うならmemoryはつめ!
認証方法