Alertingの高度な実装方法について

[mukai]

Alertingの実装方法についてご相談させて下さい。

現在下記の要件をAlertingで実装する必要があり、実装方法に頭を悩ませております。
業務要件

現在Alertingを1万個程度作って実装する案を考えておりますが、「予算(3桁前半)」・「サーバ性能(低スペック)」・「運用フェーズ(運用困難)」を考慮すると現実的ではないのではと懸念しております。
実装案①イメージ図

何でも良いので、もし何かアドバイス等ありましたら教えて頂けないでしょうか。
・この機能を組み合わせれば良いのでは。
・外部の仕組みと組み合わせれば良いのでは。
・この機能を使えば効率化できるのでは。

よろしくお願いします。

[mnozawa (Makoto Nozawa)]

利用データというのはどれくらいの量でしょうか
その量によっては1段階目のalertingはpercolatorにして、利用データが流れてくるたびにチェックして2段階目のESに蓄積していく方が効率的かもしれません
あるいは、percolatorを使ったクエリをalertingに使うことでalertingの数自体を減らせるか、というあたりに検討の余地がありそうに感じました

どうしてもサーバスペックやデータ要件依存の側面が強いです
ただ、1時間に1回、単純なクエリであれば数千、数万というオーダーの処理はそれだけで非現実的というほどではないと思います
無責任な印象論ですが、うまく設計できればなんとかなるのではないかと

[mukai]

返信遅れてすいません。

その量によっては1段階目のalertingはpercolatorにして、利用データが流れてくるたびにチェックして2段階目のESに蓄積していく方が効率的かもしれません
あるいは、percolatorを使ったクエリをalertingに使うことでalertingの数自体を減らせるか、というあたりに検討の余地がありそうに感じました

なるほど、percolatorは知らなかったので参考にさせて頂きます。

どうしてもサーバスペックやデータ要件依存の側面が強いです
ただ、1時間に1回、単純なクエリであれば数千、数万というオーダーの処理はそれだけで非現実的というほどではないと思います
無責任な印象論ですが、うまく設計できればなんとかなるのではないかと

ありがとうございます、実際にやるのはまだ先なので、その時になったら何とかやってみようと思います。