データの活用が当然のことのようになってエンジニア以外でもSQL書いてデータ抽出するのが一般的になってきました。さらにデータサイエンティストの登場により高度な分析もされるようになってきて、顕在化してきたのがHadoopクラスタの無法地帯化とエンジニアの疲弊なんじゃないかと最近思っております。なおHadoopに限らずElasticsearchでも言えたりします。 これって要はユーザと管理者のバランスの問題で、Hadoopエンジニアを採用するのが難しいというのが背景にあります。 SQL書ける人はそれなりにいるけど、インフラ側の人材不足ですね。この状態でデータの民主化が進むとどうなるかというと、 クエリの数が増える -> なかにも重いクエリも結構ある -> 管理者がそれをチェックするのに疲れて放置するようになる -> クラスタの負荷が増えて障害も出るようになる -> クエリ実行にも時間かかるように

fluentdは基本的には安定して動くソフトウェアだけど規模が大きくなってユースケースが増えてくるとトラブルに遭遇することもある。今回は運用周り、例えばトラブルシューティングとかモニタリング周りについてちょっと書いてみたい。 前提として僕の環境ではtd-agentは使わず素のfluentd 0.12系を使っており、xbuildでrubyをインストールし、supervisordでプロセス管理している。 また僕はfluentdクラスタを運用する立場であり、このクラスタに対して社内のメンバーが自由にfluentdを使ってログを送信するという形になっている。 なので末端のfluentdの管理は僕ではなく各自でやってもらうということになっているのだが、そこで問題が出ることもある。 fluentdのバージョン管理問題 例えば、とあるfluent pluginをインストール or アップデートしたらfl

うちの環境ではkafkaに入ってるログをkafka-fluentd-consumer 0.3.0でconsumeしたのちにfluent-plugin-elasticsearch 1.9.0経由でElasticsearchになげるということをしています。 fluent-plugin-elasticsearchは8プロセス動いていて各プロセスがメモリを5〜8GB使っている状態でした。マシンのメモリは64GBだったので割とメモリがかつかつな状態だったせいか、以下のようなログをはいてkafka-fluentd-consumerが落ちるという状況が発生していました。 failed; error='Cannot allocate memory' (errno=12) # # Native memory allocation (mmap) failed to map 555745280 bytes fo

Prometheus Casual Talks #1 - connpass 発表者、参加者の皆様おつかれさまでした。ありがとうございました。 Prometheusは日本ではあんまり使われていないと思うのでそんなに人集まらないと思ってたんですが、connpassに公開したその日にすぐ定員はうまるぐらい人気でした。 ただ97人の申し込みに対して実際に来たのは66人で、入退室の面倒くささを考えると今後はdotsを使うのが正しい気がしてきました。 参加者がどういうモニタリング、監視ソフトを使っているのか興味があったので、 事前に任意で「現在業務で使っているモニタリング、監視ソフトは何ですか？」という複数回答可のアンケートを実施したのですがその結果が下記です。 Zabbix 66 Nagios 48 Cloudwatch 34 Kibana 33 Elasticsearch 28 Cacti 26