devopsy.kinsta.cloud

Tag: nagios

  • Site24x7 Supports Nagios, Custom Plugins to Monitor Entire App Stack

    Site24x7 Supports Nagios, Custom Plugins to Monitor Entire App Stack

    Site24x7 Plugins Drive Customized, Detailed Monitoring of IT Resources

    • Supported plugins: Nagios, MySQL, Redis, MongoDB, NGINX, HAProxy, ZooKeeper, WordPress, Apache, Memcached
    • Users can create their own plugins using Python or shell scripts
    • Access Site24x7 Plugins at http://ow.ly/109LDi

    PLEASANTON, Calif — April [26], 2016 — Site24x7, the cloud infrastructure monitoring service for DevOps and IT operations, today announced Site24x7 Plugins. Available now, the new feature lets IT pros use third-party and custom-built plugins for detailed monitoring of their IT resources — all within the Site24x7 control panel. Site24x7 Plugins let users customize the set of monitored attributes for the hosts, devices, services, protocols, applications and all other resources in their environments, providing deep performance visibility into the entire application stack.

    Network and server administrators often require specific monitoring data that goes beyond the scope of vendors’ standard monitoring solutions. Acquiring such data typically requires users to extend the functionality of their existing tools with third-party and custom plugins designed to provide detailed monitoring metrics of individual resources. With Site24x7 Plugins, IT admins can now access that data using thousands of supported, pre-built plugins or create their own.

    “The new Site24x7 Plugins for server monitoring will help DevOps teams to monitor the full application stack,” said Gibu Mathew, director of product management, Site24x7. “With support for custom scripting and out-of-the-box integrations to provide additional, system-level metrics, Site24x7 Plugins extend the end-user monitoring and application troubleshooting capabilities that Site24x7 customers around the world rely on daily.”

    Out-of-the-Box Plugins Support – Site24x7 Plugins supplement Site24x7 monitoring with precise, resource-specific metrics that an IT team deems critical to the monitoring of its particular environment. For example, installing the Site24x7 MySQL plugin will let users analyze key details such as total number of used connections, number of slow queries, total aborted connections and other metrics needed to tune and troubleshoot apps that rely on MySQL.

    Nagios Plugins Without Nagios Servers – With support for Nagios, users can execute thousands of Nagios plugins in Site24x7 without the need to run a Nagios server. This means that there is no need to maintain a dedicated server for Nagios and Nagios server software, yet users can still take advantage of Nagios community scripts. Nagios plugins can be executed with a simple configuration file while the other pre-built plugins work out of the box.

    Create Your Own Plugins – Users can also create custom plugins using Python or shell scripts and analyze the performance of databases, Web servers and more with a simple script.

    In addition to MySQL, Nagios and custom plugins, Site24x7 Plugins support a wide range of out-of-the-box integrations, including Redis, MongoDB, NGINX, HAProxy, ZooKeeper, WordPress, Apache and Memcached. Site24x7 Plugins will support additional modules going forward.

    All plugin data is passed through to the Site24x7 alerting and reporting engines, so users can set threshold values for individual attributes and configure alerts if values exceed the set limit. Performance charts for custom attributes can be viewed on the Site24x7 dashboard.

    “We have been using Site24x7 for more than a year, and I should say that we are more than just satisfied,” said Aleksander Andrijenko, IT infrastructure at Marcura Group in Dubai. “Site24x7’s broad feature offerings and price point made it an obvious choice over other vendors. The product is easy to set up, and you can start monitoring your environments in just minutes. The instant alerts using [the Site24x7] Plugins feature ensures we’re on top of issues all the time.”

    Pricing and Availability

    Site24x7 Plugins is available as a standard feature along with Server Monitoring, priced at $9/month for 10 servers in the Standard pack.

    For more information about Site24x7, please visit http://www.site24x7.com/; follow the blog at http://blogs.site24x7.com/, on forums at http://forums.site24x7.com/, on Facebook at http://www.facebook.com/Site24x7, and on Twitter @Site24x7. For information on upcoming Site24x7 webinars, visit https://www.site24x7.com/webinars.html.

    About Site24x7

    Site24x7 offers unified cloud monitoring for DevOps and IT operations. Monitor the experience of real users accessing websites and applications from desktop and mobile devices. In-depth monitoring capabilities enable DevOps teams to monitor and troubleshoot applications, servers and network infrastructures, including private and public clouds. End-user experience monitoring is done from 50+ locations across the world and various wireless carriers. For more information about Site24x7, please visithttp://www.site24x7.com/.

  • Four open source tools to help keep you cooking with Chef

    Four open source tools to help keep you cooking with Chef

    If you’re even a little familiar with DevOps concepts, you’ve probably heard of Chef. If you’ve started experimenting with or implementing DevOps, there’s a pretty good chance you’re using Chef. Chef is an awesome platform for managing a DevOps environment, but it isn’t perfect.

    Thankfully, missing features or gaps in the capabilities of a platform like Chef are just opportunities for other developers to step in and save the day. For some organizations, that may be a double-edged sword. It can be overwhelming to investigate the myriad options out there, and to choose tools that add value, without also adding more complexity and headaches than they’re worth.

    Let’s take a closer look at four of the most popular open source tools you can use in conjunction with Chef to make your life easier.

    1. Foodcritic

    One of the coolest things about Chef—at least from a geek humor perspective—is how the various tools and features all seem to have food-related names that play off of Chef. For example, Foodcritic.

    The goal of Foodcritic is to make it automate checks for common problems in your Chef cookbooks. The idea is to be able to analyze code quality, and identify issues that will cause Chef to have heart failure if you try to deploy them. Foodcritic ensures that your cookbook code is clean, and flags issues before you deploy them and cause Chef to blow up.

    Foodcritic can be configured to work with continuous integration tools like Travis and Jenkins as well. Doing so enables you to combine the automated checking of Foodcritic with the automated deployment pipeline of Travis or Jenkins to keep everything running smoothly.

    2. Test Kitchen

    Continuing with the Chef / food-related naming conventions, next we have Test Kitchen. Just as restaurants and food companies have test kitchens where chefs can experiment with new flavors and recipes without disrupting food production or affecting the menu, Test Kitchen offers DevOps developers a means of executing a Chef cookbook without actually running code on the Chef Server.

    Test Kitchen has drivers and plugins that allow it work with most cloud platforms and virtualization technologies, including Amazon EC2, Blue Box, CloudStack, Digital Ocean, Rackspace, OpenStack, Vagrant, Docker, LXC Containers, and more. It is also designed to support testing frameworks like Bats, shUnit2, RSpec, and Serverspec right out of the box.

    3. Berkshelf

    The food / Chef connection is a bit more of a stretch on this one, but once you understand what it does it makes more sense. A chef typically has cookbooks, and those cookbooks are stored on a bookshelf. A Chef deployment also uses cookbooks, and those cookbooks can be managed using Berkshelf. Do you see what they did there?

    Berkshelf ensures that the right versions of Chef cookbooks are being run by managing how the cookbooks are fetched and deployed to the Chef Server. While there are some unique elements to each Chef cookbook (It wouldn’t make sense to have a completely identical cookbook), there are still common elements as well. It is tedious to manually copy those common elements every time you want to use them so Berkshelf simplifies the process.

    4. Nagios

    You might be wondering if Nagios is some exotic food, or perhaps a tool used by gourmet chefs that you’ve just never heard of. It’s not. Sadly, Nagios breaks the trend of cooking or food related naming. The name Nagios is actually a recursive acronym that stands for “Nagios Ain’t Gonna Insist On Sainthood”—a reference to its original name, NetSaint, which was changed following a legal / trademark dispute.

    Nagios is also less Chef-centric than the other tools listed here. It is an IT infrastructure monitoring tool—a pioneer of sorts in the field of continuous monitoring that is gaining in popularity now. Nagios monitors your IT infrastructure for changes in order to spot problems before they occur, and alert the appropriate personnel.

    Continuous monitoring has a variety of potential benefits. The data gathered from Nagios can help reduce downtime and business losses, or help organizations plan and budget for IT upgrades. It is also an effective tool for detecting security incidents because the continuous monitoring can identify anomalous activity or unauthorized changes and issue alerts in real-time.

    If you are using Chef in your DevOps environment, check out these four tools. As great as Chef is, you might find these tools valuable in helping to streamline and maintain a stable infrastructure.

    Find out how Rally Software uses Chef to achieve business agility at a special devopsy.kinsta.cloud webinar on September 4th!

  • Nagios is not a monitoring strategy

    Nagios is not a monitoring strategy

    When I visit clients to talk about DevOps, I usually ask them what their monitoring strategy is. Too often, the answer I hear is “We use Nagios”. I think Nagios is a great tool, but it sure is not a strategy. Nagios does a good job of monitoring infrastructure. It will alert you when you are running out of disk, CPU, or memory. I call this reactive monitoring. In other words, Nagios is telling you that your resources are getting maxed out and you are about to have issues. Proactive monitoring focuses more on the behavior of the applications and attempts to detect when metrics are starting to stray away from their normal baseline numbers. Proactive monitoring alerts you that the system is starting to experience symptoms that can lead to a degradation of performance or capacity issues which is more preferable than Nagios telling you are about to be screwed. With reactive monitoring, it is not uncommon that customers start complaining about the same time that the Nagios alerts start going off. The goal of proactive monitoring is to head off issues so that customers don’t even notice.

    The next question I ask is “What things are you monitoring?”  A typical answer usually revolves around various infrastructure assets and databases. That’s a good start but there is much more to consider. But first, let’s talk about why proactive monitoring is so critical. In the pre-cloud days we used to ship software to our customers where they would install the software, perform capacity planning tasks, manage the infrastructure, and operate the day-to-day activities. Once we shipped the code we were done. In today’s world, we are no longer shipping product. Instead we are delivering services that are always on. The customer no longer owns and operates the infrastructure and the software. Instead they pay for a service and expect that service to run reliably all the time. To meet those expectations, we need a more robust monitoring strategy. We need to monitor more than just the infrastructure.

    A good monitoring strategy starts by identifying all of the actors who needs access to data and all of the categories of data that needs to be tracked. Some metrics are monitored in real-time while others are mined from log data. Every good monitoring strategy is accompanied with a sound logging solution. In order to perform analytics to predict trends within the data, one must collect various data points ranging from customer usage activity, security controls, deployment activities, and much more. The following presentation goes into much more detail about the different areas that should be monitored and why different actors need these data points to perform their jobs.

    [slideshare id=33320431&doc=monitoringstrategies-0408014v1-140409081614-phpapp01]


    The bottom line is, before building in the cloud, it pays to invest some time into a sound monitoring strategy. I have seen too often where teams don’t think through how to support these highly distributed, always on SaaS solutions and end up delivering software that does not meet the reliability and quality expectations of  customers. Monitoring provides feedback to developers, product owners, operators, and even customers so that systems can continuously be improved. Nagios is great, but there is no single monitoring solution that can implemented to effectively operate today’s always on services.