ブログトップ 記事一覧 ログイン 無料ブログ開設

wyukawa’s blog

2016-05-16

洞爺湖マラソンいってきた

去年は3時間48分のベストを出した相性の良い大会で、今回のタイムはぎりぎりサブ4でした。

天気も良く、しそジュースうまかったです。給食はゆで卵食いました。味は普通でした。

去年と比べると受付がなくなったのと、宿はスタート地点から近かったので荷物をホテルに預けられて楽でした。

レース後にホテルの風呂にも入れてすっきりしました。

この大会は風景もいいし5000人規模の大会なのでそこまで混雑しないので良い大会だと思います。

ただ千歳空港からバスで2時間なのと、市街地じゃないので応援が少ない、最後の3kmぐらいが歩道でちょっと走りづらい、などがありますが、この時期のフルマラソンとしては数が少ないので来年も検討します。今年は黒部名水マラソンと悩んだんですけど、気温と去年の良いイメージがあったので今年も洞爺湖マラソンにしました

2016-05-06

レポーティング、モニタリング、監視で使うストレージは何が良いんだろう

題記のようなことを考えていて、レポーティング、モニタリング、監視で使うストレージは全部統一されているほうが当然運用が楽だと思うのですが、現状だと統一できなくて用途ごとに分けてHadoop, Prometheus, Elasticsearchに格納するというのが僕の今のところの見解です。


僕は日頃の仕事はログ分析基盤を構築、運用をしつつデータ加工バッチを書いたりしています。

各サービスのPV, UUといったメトリクスを日々レポーティングするのであればアクセスログ、アプリケーションログ、各サービスのマスターデータ(例:ユーザ情報、商品マスタ)などをHadoopにぶっ込んでHiveでdailyで集計すればことたります。

Hadoopの良いところはSchema on readでとりあえずデータをぶっ込んでおいて後で解析できるところです。しかも容量やCPUパワーが足りなくなったら台数ふやぜば簡単にスケールアウトできる。これはNetezza(Pure Data)のような商用DWHではできないことです。


一方でバッチ処理でレイテンシはどうしても高くなるので、うちの環境ではPrestoを使っています。

バッチ以外の要件としてリアルタイム処理があります。

例えばサービスがどこでどれぐらい盛り上がっているかリアルタイムに知りたいっては要件として理解できます。

この場合でもNorikraで集計するという手段はあるのですが、高トラフィックになると厳しいです。例えば秒間1万メッセージとかだったら無理だと思います。

その場合は何使うかというと、Storm, Flink, Spark Streaming, PipelineDBあたりが候補になると思います。

Kibanaがダッシュボードツールとしては優れているのでKibanaを使いたい場合はNorikraで集計してElasticsearchに突っ込んでKibanaで見るという形になります。

Elasticsearchで集計するという手もありますが、その場合はElasticsearchで詰まらないように気をつける必要があります。

NorikraはSQL書いて登録すれば他は何も再起動しないで集計できるので便利なのですが、そのカジュアルさの反面、スケールしないのでモニタリング用途で使うのが良いのかなと思ってます。

例えばメルカリでのNorikraの活用、 Mackerelを添えてのように。


モニタリングの話が出たので見たいものを整理します。

  • サービスごとのビジネス的なメトリクス。主に企画者が見る。
    • 売り上げ, PV, UU, 新規UU, 離脱率, 継続率など
  • サービスごとの開発者的なメトリクス。主に開発者が見る。
    • JVM, キューのサイズ, APIのリクエスト数、レスポンスタイムなど
  • マシンごとのメトリクス。主にインフラエンジニアが見る。
    • HDD使用率、CPU使用率、メモリ使用量、ネットワークトラフィックなど

これらのすべてのメトリクスをFluentdを使って収集することは可能ですが、Jenkinsをジョブ管理ツールとして使うぐらい僕には違和感があります。便利なので本来のユースケース以外のものにも適用したくなるのはわかりますが。

同じ理由でKibanaをモニタリングツールとして使うのは正直微妙だなと思ってます。ただしミドルウェア(例:Apache, HBase)のログをFluentdを使って収集してElasticsearchに突っ込んでKibanaで検索するのはアリだと思います。

例えばOutOfMemoryとかERRORとかの文字列で検索するのは便利ですよね。Elasticsearchはモニタリングツールじゃなくて検索ツールだと思ってるのでKibanaでHDD使用率とかを見るのはどうなのかなあと思ってます。

僕は今のところ、開発者やインフラエンジニアが見るメトリクスはPrometheus+Grafanaで考えています。理由はGrafanaの見た目がかっこいいことと、Prometheusがクエリ機能を持っていてKibana的に使えるから。あとPull型なので出力で詰まらないから。

Prometheusを使う場合は、マシンごとのメトリクスならnode_exporter、JVM周りのメトリクスならjmx_exporter、でことたります。それ以外は必要に応じてexporter使えば良いです。例えばRedis使っているならredis_exporterなど。

なので、企画者が見るメトリクスはHadoopに入れて、開発者やインフラエンジニアが見るメトリクスはPrometheusに入れて、ログ検索したいなら生ログをElasticsearchに入れるのが良いかなと思ってます。

この時点で3つストレージが登場してくるのがアレなわけですが、現時点では統一するのが難しいかなと思ってます。


監視についてですが、本来モニタリングと監視はセットになっているべきです。だって例えばJava Heapサイズをモニタリングしつつ監視の閾値も柔軟に変えたいでしょ。GangliaでモニタリングしてNagiosで監視とかだと別々になってしまいます。

PrometheusはAltermangerという監視機能があって一応モニタリングとセットで監視できます。一応と書いたのはAltermangerはまだexperimentalな感じだからです。例えばアラートルールを追加するWeb UIやアラート履歴を確認するWeb UIがありません。というかアラートルールはバージョン管理すべきだからWeb UI要らないというような雰囲気を感じます。それにしたってアラート履歴ぐらい欲しいよなと思うのですが、そちらは http://alerta.io/ を使えということかも。

そんなこんなで最近はモニタリング、監視をどうやるか考えてますが、今のところはPrometheus+Grafanaで考えていて、かつ足りない部分、例えばprometheus.ymlを編集するようなWeb UIを自作しようと思ってます。

2016-04-29

Ambari Meetup TokyoでLTとパネルディスカッションしてきた

Hadoopソースコードリーディング 第20回で発表してきました - wyukawa’s blogで話が出ていたAmbari MeetupがYahoo! JAPANさんのご尽力で実現しました。しかも美味しい食事とビール付きでした。なんて素晴らしいイベントなんでしょう。関係者のみなさまありがとうございました。

Ambari Meetup Tokyo #1 at Yahoo! JAPAN - connpass

僕のLTスライドはこちら

当日は残念ながらHortonworks関係者の方がいらっしゃらなかったので[AMBARI-15418] hive.server2.authentication.pam.services and hive.server2.custom.authentication.class are required at NOSASL - ASF JIRAを早く見てよってプレッシャーをかける目論見は外れましたが、楽しいイベントでした。

Yahoo! JAPANさんの大規模事例を聞いたり他の方と話してて感じるのは現時点のAmbariで数百台の規模を運用するのは厳しいということ。

てっきりAmbariって大規模向きなのかと思ってたけどそうでもないみたい。台数が多くなるとAmbariのWeb UIが重いなどいろいろ問題が出てくるらしい。

あとAmbari Metrics使わずに結局Ganglia/Nagiosを使っているというような話を聞いて、僕が小規模クラスタでAmbariを使っていてかつAmbari Metricsをインストールしていないのはだいぶ正解なんじゃないかと思えてきた。

たしかにAmbariが競合のCloudera Managerの背中を追う宿命を負っていることや、サードパーティのモニタリングシステムを使わずに自分達でコントロールするためにAmbari Metricsを自作するのは理解できます。Prestoを担がずにHive LLAPを担ぐのも同じ理由でしょう。

でも現時点ではAmbariがCloudera Managerの劣化コピーの道を歩んでいる気がして一ユーザとしては危惧を覚えているのが正直なところです。

僕としてAmbariに望んでいるのはもっとベーシックな機能が安定して動くことです。upgrade時にバグに遭遇しないとかね。

なので正直モニタリングやアラートはなくて良いと思ってます。それはこっちで別システム使ってやるから。

AmbariがもっとリッチになってAnsibleとか使わなくても良いようにしてほしいという意見もあって、確かにツールが増えるのは辛いからそういう意見も理解できるけど、僕としてはまあどうせAnsibleは必要だから別にそれはなくてもいいかなって思ってます。

おそらくAmbariにさける開発パワーはそれほど多くないと思うので、本当に必要な機能に絞って開発してほしいなと思ってます。

2016-04-17

長野マラソンを走ってきた

Garminを見ると記録は4時間15分だった。

花粉が多かったのと、スタート前は暑かったけど、途中で雨、風が強くなり、後半は晴れて暑かった。

めっちゃきつかった。そろそろサブ4出せるかなと思ったけど全然だった。記録面は完全に停滞期です。

2016-04-06

アクセスログをfluent-plugin-prometheusで集計してGrafanaで表示する

アクセスログをfluent-plugin-prometheusで集計してgrafanaで表示するというのを試したのでメモがてら書いておきます。

現状fluent-agent-liteでアクセスログを収集してサンプリングや集計をして最終的にGrowthforecastで表示する仕組みが社内にあります。

イメージはこんな感じ

fluent-plugin-sampling-filter and fluent-plugin-datacounter released! #fluentd - たごもりすメモ

これはこれで問題なく動いているんですが、例えばhttp status 201がどれぐらいあるか知りたい!ってなった時はfluentdの設定を変えて再起動する必要があります。や、そんなユースケース今までなかったですけどw

その辺の柔軟性が欲しい場合は別の仕組みが必要だろうと思っていて、一つの手段としてはNorikraに集計を任せるというのがあります。

別のやり方としてPrometheusでクエリ書いてGrafanaで表示する手があると思ったので試してみました。

fluentdクラスタがすでにあるので、fluent-plugin-prometheusを使えば簡単にPrometheus化できるかもと思ってこのプラグインを試しました。

使い方は下記にあります。

GitHub - kazegusuri/fluent-plugin-prometheus: A fluent plugin that collects metrics and exposes for Prometheus.

fluent-plugin-prometheusをリリースしました - Qiita

試そうとしてわかったことはこのプラグインはfluentdの非公開APIを使っているので普通に使おうとしてもエラーになると思います。詳細は下記参照

Fluentd dies when executing example ? Issue #2 ? kazegusuri/fluent-plugin-prometheus ? GitHub

fluentd 0.12.19もしくはfluentd v0.14.0.pre.1なら動きます。

僕は最終的にはfluentd 0.12.19で動かしました。

fluentdの設定はこんな感じ。

これでhttp://host:24231/metricsをprometheus serverからpullするようにします。

<source>
    type prometheus
  </source>
  <filter accesslog.**>
    type prometheus
    <labels>
      tag ${tag}
      host ${hostname}
      method ${method}
      status ${status}
    </labels>
    <metric>
      name accesslog_counts
      type counter
      desc the number of emited record
    </metric>
  </filter>
  <match accesslog.**>
    type null
  </match>

Prometheusにはメトリクスのタイプがcounter, gauge, histogram, summaryとあります。

no title

Prometheusのruby clientだとhistogram実装が無いので使えるのはcounter, gauge, summaryです。

http response timeのところでsummaryを使おうとしたんですけど、そうするとCPU使用率が100%になるのでやめました。

この状態でaccesslog_countsというクエリをPrometheusで実行すると下記のようになります。

accesslog_counts{host="...",instance="...:24231",job="...",method="GET",status="200",tag="..."}
...

http status code別の1秒間の件数を1分のwindowで見たい場合のクエリは下記の通り。これで合っているはず。。。

sum(rate(accesslog_counts{tag="..."}[1m])) by (status)

これをGrafanaに登録してグラフ化すると下記のようになります。

f:id:wyukawa:20160406183748p:image

さらに割合も見たいのでクエリを下記のようにします。

sum(rate(accesslog_counts{tag="..."}[1m])) by (status, job) / on(job) group_left(status) sum(rate(accesslog_counts{tag="..."}[1m])) by (job)

この辺難しくてno titleとかHow To Query Prometheus on Ubuntu 14.04 Part 1 | DigitalOceanを読んでなんとか書きました。これで合っているはず。。。

これをGrafanaに登録してグラフ化すると下記のようになります。

f:id:wyukawa:20160406183749p:image

レスポンスタイム別の結果をグラフ化するのはこの仕組みだと難しい気がしますが、単純なカウントならこれでもいけるかなというところです。