Assuming you’re not Facebook, you probably don’t have large development teams to tweak how your application interacts with memcached, you may still want to deploy it to help your site’s scalability.
But if you practice safe operations, you will never put anything into production without monitoring. Particularly nothing that production depends on.
“But production is not dependent on memcached!” I hear you say. “If the memcached slice that is caching a particular lookup is down, the app will just hit the database, and carry on happily.”
This is true, but what happens when your app is not able to deal with the load in the absence of almost all the memcached slices being up? Then you end up with a big dose of downtime, or horrendous app performance at best.
And how would you know how many requests your memcached systems are offloading from your database? If you weren’t monitoring them, you wouldn’t – so you wouldn’t know when you’d passed that point where you need memcached. (Ideally you’d be plotting the aggregated view of all the memcached’s in your environment.) Nor would you know when CPU load on your memcached systems has become the bottleneck, rather than memory. (Although unless you are Facebook, you probably won’t run into that.) And of course, more than pretty graphs, you need to know when Memcached is down, or how many nodes are down.
So even if you don’t use LogicMonitor’s memcached monitoring, be sure to practice safe ops, and get some monitoring.
Want to learn more about monitoring, and how to practice safe operations in your environment? Setup a trial of LogicMonitor and get a free consultation with one of our experienced operations staff.
Free Trial