Operations | Monitoring | ITSM | DevOps | Cloud

Today we released version 1.5.0 of Loki! This release comes with some really exciting news and a little bit of caution if you operate Loki installations.

A Prometheus CloudWatch exporter is a key element for anyone wanting to monitor AWS CloudWatch. Exporting CloudWatch metrics to a Prometheus server allows leveraging of the power of PromQL queries, integrating AWS metrics with those from other applications or cloud providers, and creating advanced dashboards for digging down into problems. But, who watches the watcher? Despite those advantages, using the wrong exporter or an incorrect configuration can have bad consequences in production environments.

And it starts with the company culture. Irrespective of how small or large your team is, it’s wise to invest some time in creating a good on-call onboarding plan. A humane on-call is the mark of a good engineering culture. Being on-call means that you’re expected to be reachable for any issues that may occur during your shift. It’s easy to lose any and all motivation by just anxiously anticipating that mid-dinner ping.

If you’re reading this article, chances are you’re about to start moving into Azure and want to get your cost control right from the start, or you’re already on your journey and are running into problems getting a clear view of where you’re spending your money. Moving into Azure, or any other cloud, brings with it a new set of challenges that you just don’t face on-prem, and the big one is that pretty much everything incurs its own running cost.

The promise of Kubernetes is to empower your organization to quickly deliver applications and services to your customers. Delivering fast cycle time and innovation requires developers and operators to collaborate effectively to ensure safety while moving fast. The GitOps methodology has taken hold in the Kubernetes ecosystem to deliver on this promise. What is GitOps? GitOps provides a mechanism to safely deploy Kubernetes manifests stored in a Git repository.

DevOps monitoring didn’t simply become part of the collective engineering consciousness. It was built, brick by brick, by practices that have continued to grow and flourish with each new technological innovation. Have you ever been forced to sit back in your chair, your phone buzzing incessantly, SSH windows and half-written commands dashing across your screen, and admit that you’re completely stumped? Nothing is behaving as it should and your investigations have been utterly fruitless.

I am a Puppet beginner and I’m happy to make the code manager integration happen. I like to play around with my code and test my code changes on my agent nodes. However, the way I’m testing my code is a bit tedious: Save my code change, push into remote repo, run code deploy, and run Puppet on agents. Is there a simple way to quickly test my code? Yes! The answer is using Onceover.

In his HAProxyConf 2019 presentation, William Lallemand (Senior HAProxy Developer) shows how process management in HAProxy has evolved since the beginning of the project; With the advent of systemd, new techniques had to be developed so that users could reload HAProxy safely. The Master-Worker mode simplifies the management of HAProxy processes and introduces interesting features.

Enterprise applications typically sprawl and develop inter-dependencies producing complicated solutions. Ultimately the complexity makes change management complex, error prone, difficult to troubleshoot during service issues and ultimately start impacting the business in multiple ways. To provide the right context when taking up transformation initiatives or addressing service issues one should be equipped with dependency and impact insights. In this video, Rich Lane, a Sr.

Tanay is the Head of Developer Relations at n8n. He has published books on WebVR, virtual assistants on Raspberry Pi, and FirefoxOS. He has been listed in the about:credits of the Firefox web browser for his contributions to the different open source projects of the Mozilla Foundation. I’ve been involved in the DevOps world for a while and yet I finished reading The Phoenix Project only recently. The book piqued my interest in how teams execute their incident response playbooks.