Norikra meetup #2 に行ってきた

Norikra meetup #2に行ってきたので、そのまとめです。

全体のまとめ

  • Norikraを使うと、開発者が手軽に欲しいデータをまとめることができる。
  • Norikraをつかったシステムでログが増えてきた時の構成
    • メモリを大量に積んだマシンを用意するパターン
      • パーセンタイルや中央値が必要であれば、このパターンを選ぶことになる。
    • Norikraを複数サーバーに用意して、1次集計・2次集計という形で多段構成にする。
      • 和や平均値ならこのパターンでできる。
  • Norikraの監視
    • どの発表でもJVM周りの監視をしていたが、監視方法は分かれていた。
  • Norikraがたまに不安定になる。
    • 今後の原因究明待ち。
  • Listnerプラグインを書くと複雑なクエリを簡潔にできそう。

各発表のまとめ

メルカリでのNorikraの活用、Mackerelを添えて

資料: メルカリでのNorikraの活用、 Mackerelを添えて @kazeburo さん

  • 本番環境にログインできない開発者が、欲しいデータを自ら設定できるようにしたい。
    • Norikra + Mackerel
      • SQLを登録して、Mackerelでグラフ化、しきい値を設定してアラートを出す。
      • fluentdでnorikra plugin + mackerel pluginを組み合わせて実現。
  • Norikraの構成
  • Norikraが落ちる問題
    • GCの途中で落ちている?
  • Norikraの活用例
    • ステータスコードの監視、監視エージェントからのアクセスがあるか。
      • Mackerelはどの系列を表示するか選択できるので数値の大きい系列があっても問題なし。
      • norikra-udf-percentileの結果をflatten_hashしている。
        • 95%でAlert設定
          • 平均値だと他の値に引きずられる。
      • time_length_batchで集計サンプル数の上限を固定している。
        • time windowは基本1分、長くても5分。

ログ解析にNorikraを導入する

資料: Norikra to realtime log analytics // Speaker Deck @harukasan さん

  • Norikraをリアルタイムログ解析に使う。
  • バッチ処理 vs ストリーム処理
    • バッチ処理はデイリー・マンスリーなどwindow幅の大きい集計
    • 分単位でのアラートを出したいなど、バッチ処理では重たい処理はストリーム処理でやるべき。
  • Norikraの活用例
    • ステータスコードの監視やエラーログの行数でアラート
      • fluentd → Norikra → fluentd → 可視化ツール
        • どこに送るかは query_group でルーティングしている。
  • Norikra部分がSPOFになっているので困っている。
  • JVMは1.7系。jRubyはxbuildでビルド。
  • デーモン化はsupervisordでやっている。
  • engine.statics というAPIを叩いて監視している。JVMの状態もとれる。
  • window幅は1分。

NorikraでWebサービスを守る

資料: Norikra defends web service // Speaker Deck @fujiwara さん

  • 集計をfluent-pluginからNorikraに切り替えた。
  • 10,000 events/sec
    • メモリ割り当て23GB
      • 10GB〜20GBくらい使っているのでちょうど良い。
    • スレッド数は --small オプションで指定している。
    • クエリが20個くらい。CPUは75%くらいは使っている。
  • Norikra活用例
    • WebバージョンをリリースしたらSpamが多くなったので、それを検知して自動で制限する。
      • とあるAPIに一定時間内に同じホストからアクセスしてきたらスパムとみなす。
        • Norikraが詰まる可能性があるので、ログの出力時刻の最小値と最大値をクエリに含めて、ログ出力時刻ベースでの一定時間で計測している。
        • 自作のfluentプラグインでmemcacheに保存してアクセス制限する。引っかかった回数が多いとだんだん制限時間を伸ばすのもやっている。

GunosyのNorikraを用いたアドネットワークのリアルタイム集計

資料: Norikra in Gunosy Network Ads@Norikra meetup #2 // Speaker Deck @shunsukeaihara さん

  • アドネットワークでのNorikraの利用
    • Norikraには1000〜1500 req/secくらい
  • Redshiftでやっていたが運用が大変だった。
    • Spark StreamingやStorm使うほどでもない。
      • なのでNorikraで。
  • 2 〜 3台のAPIサーバーに対して1Norikraを割り当てている。
    • 多段Norikraにしている。
      • 急なサーバー数の拡張に対応できるようにするため。
        • サーバー数が増えた分だけ1段目のNorikraを増やせば対応できる。
    • 最終段でのNorikraで数値をサマって、Kibanaに流して可視化する。
  • 監視はDatadogで。
    • JVMのオプションをとれるように手を加えてある。
      • fullGCが走ると通知。

Norikra Recent updates

資料: Norikra Recent Updates @tagomoris さん

  • ここ1年間でNorikraに追加された機能の紹介。
    • Supended Query
      • クエリを一時停止できる機能
        • statsファイルには保存されないので注意。
    • NULLABLEフィールド
      • 集計したいフィールドがないときに、Norikra側でnull扱いにしてくれる。
        • 通常、クエリに指定したフィールドがないイベントは集計対象外になるが、NULLABLEにするとそのフィールドがなくても集計対象になる。
      • フィールドをNULLABLE(フィールド名)でくくるだけ。
        • クエリ内で1つ書けば、そのクエリ内ですべてnull扱いになる。
    • Listener
      • Esperからの出力を直接扱うことができる。
        • filter, sampling, push, send などに使える。
      • ListenerプラグインjRuby で書ける。
    • プラグインの動的ロード
    • 他、Norikraの状態をとれるAPIなどが追加された。