Facebookでない場合は、アプリケーションがmemcachedとどのように相互作用するかを微調整する大規模な開発チームがない可能性があります。それでも、サイトのスケーラビリティを支援するためにアプリケーションをデプロイすることをお勧めします。
しかし、安全な操作を実践すれば、監視せずに本番環境に移行することは決してありません。 特に生産が依存するものは何もありません。
「しかし、本番環境はmemcachedに依存していません！」 あなたが言うのを聞きます。 「特定のルックアップをキャッシュしているmemcachedスライスがダウンしている場合、アプリはデータベースにアクセスするだけで、問題なく続行されます。」
これは本当ですが、ほとんどすべてのmemcachedスライスが起動していないのに、アプリが負荷を処理できない場合はどうなりますか？ そうすると、大量のダウンタイム、またはせいぜい恐ろしいアプリのパフォーマンスになってしまいます。
また、memcachedシステムがデータベースからオフロードしているリクエストの数をどのようにして知ることができますか？ あなたがそれらを監視していなかったなら、あなたはそうしなかったでしょう–それで、あなたがあなたがどこでそのポイントを通過したかをあなたは知らないでしょう。 必要 memcached。 （理想的には、環境内のすべてのmemcachedの集約ビューをプロットすることになります。）また、memcachedシステムのCPU負荷が、メモリではなくボトルネックになったこともわかりません。 （Facebookでない限り、おそらくそれに遭遇することはありません。）そしてもちろん、きれいなグラフ以上に、Memcachedがいつダウンするか、またはいくつのノードがダウンするかを知る必要があります。
したがって、LogicMonitorのmemcachedモニタリングを使用しない場合でも、必ず安全な操作を練習し、ある程度のモニタリングを行ってください。
監視と、環境内で安全な操作を実践する方法について詳しく知りたいですか？ LogicMonitorの試用版をセットアップし、経験豊富な運用スタッフのXNUMX人と無料で相談してください。
フリートライアル