One of my earliest jobs was as an admin for an MSP. We'd routinely generate alerts that weren't actionable, lacked context, and for most of our customers, were considered noise. From a monitoring perspective, it was bad. Customers didn't trust in the alerts they received and often resorted to having some additional monitoring product installed on their systems. It's safe to say that our auto-generated tickets and emails were largely ignored.

At this point in our series, you’re likely quite familiar with the many opportunities and challenges that Kubernetes presents (especially when it comes to monitoring!). The last couple of posts take at a look at Prometheus for monitoring Kubernetes, with a side-by-side comparison with Sensu, and illustrate how they work in tandem.

At Monitorama 2018, Engineering Manager Kale Stedman shared Demonware’s journey to assisted remediation, or as he likes to call it: “How my team nearly built an auto-remediation system before we realized we never actually wanted one in the first place.” In this post, I’ll recap Kale’s Monitorama talk, highlighting the key decisions that helped his team reduce daily alerts, fix underlying problems, and establish a more engaged Monitoring Team — including the steps the

Monitorama is the event of the year if you’re in the monitoring and observability space! It’s an inclusive event for speakers, attendees, and vendors alike to network and learn from each other in a safe, comfortable, and accessible environment.

In the era of cloud-based architectures, companies have implemented multiple cloud platforms but have yet to reap the full benefits. Whether it’s Amazon Web Services (AWS), Google Cloud, or Microsoft Azure (or some combination thereof), a recent Forrester study found that nearly 86 percent of enterprises have incorporated a multi-cloud strategy.

One of the many challenges when building an application is ensuring that it's secure. Whether you're storing hashed passwords, sanitizing user inputs, or even just constantly updating package dependencies to the latest and greatest, the effort to attain a secure application is never-ending. And even though containerization has made it easier to ship better software faster, there are still plenty of considerations to take when securing your infrastructure as well.

In my last post, I talked about the evolution of infrastructure as code and its role in modern software development. To recap, let's take a quick look back at what an IaC process establishes: in a nutshell, IaC is a methodology that enables you to manage your servers and deploy your applications purely through code. Through some configuration language saved to a file, you define the resources and packages that servers need.

Infrastructure management has come a long way. (Mostly) gone are the days of manual configurations and deployments, when using SSH in a “for” loop was a perfectly reasonable way to execute server changes. Automation is a way of life. Configuration management tools like Chef, Puppet, and Ansible — once on the bleeding edge — are now used by most enterprises.

In part 1 of this series, we discuss the rise of Kubernetes and Docker for containerization and container orchestration. I also shared some of the challenges these new technologies present and what sources of data we use to monitor Kubernetes. Part 2 dives into collecting Kubernetes data with Prometheus, plus the pros and cons of that approach. As promised in the conclusion of that post, I’ll address those cons — showing how Sensu and Prometheus form a complementary solution.

Regulating access to resources is a fundamental measure for enterprises to ensure the security and reliability of a system. The last thing you need is a stolen or weak password to give up the keys to the proverbial kingdom. With role-based access control (RBAC), this risk is mitigated by providing only the necessary access so a user in your organization doesn't have more access than needed.