予期せぬクエリ、データに対してロバストにする

技術

ログ解析基盤を運用しているとユーザから予期せぬクエリやデータが来てシステムが不安定になることがあります。そういうケースに遭遇してどうハンドリングしてきたかをメモっておきます。


1回のprestoクエリの結果が100GBを超える

そんなクエリを連発されたらあっという間にDisk Fullになっちゃうので、うちの環境だとyanagishimaがpresto web uiなのでyanagshimaで、クエリ実行時間が30分を超えたら、もしくは結果サイズが1GBを超えたら、エラーを返すようにしました。

yanagishima以外でクエリを実行されるケース、例えばbatch、もあるので、query.max-run-timeを3hにしてます。つまり実行時間が3時間超えたらエラー

これデフォルトが100日になっててFacebookどういう運用しているんだろうという。。。
https://github.com/prestodb/presto/blob/0.171/presto-main/src/main/java/com/facebook/presto/execution/QueryManagerConfig.java#L54


ElasticsearchでOutOfMemoryError

以前OOMEが出た時はCircuit Breakerを強化しました。
ElasticsearchのCircuitBreaker - wyukawa’s blog

今回はJava heap space when using unique count on specific field - Elasticsearch - Discuss the Elastic Stackだったので、precision_thresholdを下げました。あとついでにindices.breaker.request.limitを1%にしました。

ほんとうはprecision_thresholdのデフォルト値をいじれれば良いと思ったのですが、できない模様でした。
https://github.com/elastic/kibana/issues/6859


KafkaでMessageSizeTooLarge
うちの環境だとfluent-plugin-kafkaでKafkaにデータを入れているのですが、サイズが大きすぎるとエラーになります。エラーになってもfluentdがリトライし続けますが、成功することは無いのでそのデータは捨てるパッチを書いてmergeされたのでこれで運用しています。
https://github.com/fluent/fluent-plugin-kafka/pull/118


KafkaでDeliveryFailed
Kafkaのtopic名に.と_が両方入っているとトラブルになる可能性が高く、エラーが出たらそのデータは捨てるパッチを書いてmergeされたのでこれで運用しています。
https://github.com/fluent/fluent-plugin-kafka/pull/126


この辺のKafkaでエラーになる場合にfluent-plugin-kafka側でそのエラーデータを破棄してロギングするだけというのは過去にもありました。
https://github.com/fluent/fluent-plugin-kafka/issues/80


そんな感じです。