読者です 読者をやめる 読者になる 読者になる

はやさがたりない。

へっぽこぷろぐらまのメモログ

サーバ・インフラエンジニア養成読本 ログ収集~可視化編 勉強会

最近、行ってきたブログばかり。。。
もうちょいがんばりたい。。。

サービス改善はログデータ解析から

すずけんさん @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はつめ!

  • 認証方法

    • LDAP認証
    • メソッドをふさぐ
    • @typesterさん Googleアカウントでできる認証Proxyを作ったのでそれを使うのもあり