2016-05-06 2 views
0

私は自分のシステムで<チェックを実行します。サーバは頻繁に負荷がかかりません。負荷平均は、通常の動作中は1以下に保たれます。Sensuスケジューラの奇妙さ

高負荷の原因がないシステムでは、チェック・キューのチェックが高負荷の平均をトリガし始める再発生の問題に気づきました。さらなる調査では、高負荷レポートは実際には他のチェックと並行して実行されるcheck-cpuスクリプトによるものであることが示されました。実行されているチェックの外側では、CPU負荷は正常でした。

私はsensu 0.20から0.23にアップグレードし、同じ問題を継続して観察しました。

sensus-serverサービスとsensu-clientサービスを再開すると、問題が一定期間(約24時間)解決され、その後復旧することがわかりました。

私たちはこの時点で理論化しましたが、このオーバーラップが最終的に発生する原因となるホスト上のチェックのディスパッチ/実行に何らかの時間遅延が存在する必要があります。

すべてのチェックは、私が83に確認CPUチェックの間隔を設定することを決めた、と問題があるため発生していない30または60

の間隔で実行するように設定されています。おそらくチェックcpuのチェックは他のものと一致しないので、その短い瞬間にCPU負荷が高いとは見当たりません。

これはsensuに固有のスケジューリングの問題ですか?適切なスペーシングで小切手を発送する方法を知っているのでしょうか、これは間隔パラメータで制御する必要がありますか?

ありがとうございます!

+0

私たちは同様の理由で、異なる、整列していない間隔で小切手を発行します。 30秒ごとの代わりに。 –

答えて

2

私は、チェックが実行時にドリフトすることに気付きました。 30秒ごとに正確に実行されるのではなく、30.001秒ごとに実行されます。私はドリフトが異なるチェックで異なるかもしれないと思います。最終的には、チェックが同期してすべて同時に実行されるという問題にぶつかり、問題を引き起こします。定期的な間隔(30秒、60秒など)でより多くのチェックを実行すると、この問題が頻繁に発生します。この問題を変更するには、sensu directlyに報告する必要があります。システムをスケーラブルにしたいと思っているので、最終的に修正するかもしれないと思う。

+1

入力いただきありがとうございます!これは非常に役に立ちます。 Sensuでこの問題を公開しました:https://github.com/sensu/sensu/issues/1260 – dank