Observability is a hot topic in the IT world these days. It is oftentimes discussed through the lens of the “three pillars of observability”: Logs, Metrics and Traces. Indeed these telemetry signal types help us understand what happened, where it happened and why it happened in our system.

We all know that observability is a must-have for operating systems in production. But we often neglect our own backyard — our software release process. We noticed we made that mistake here at Logz.io. We were wasting time and energy in handling failures in the CI/CD pipeline, and made our Developer-on-Duty (DoD) shifts tedious. That’s why it’s critical to incorporate your observability practices into your CI/CD pipeline.

Every security operations center (SOC) team is different, and for smaller teams, even small challenges can seem big. I started my career in cybersecurity as part of a smaller team, and eventually grew into a SOC role. During that time, I gained a good deal of knowledge about the dos and don’ts of what a small SOC team needs to do in order to be successful.

So far in our series on scaling observability for game launches, we’ve discussed ways to 1) quickly analyze large volumes of telemetry data and, 2) ensure high-quality telemetry data for more effective analysis at lower costs. The best practices in these blogs outline best practices for scaling observability during game launch day – which is necessary to ensure high performance across all infrastructure components – to ensure no lag, no glitches, and no bugs.

HashiCorp Consul began as an open-source project for service discovery. It has evolved to provide other valuable functionality like secure service mesh to help secure microservice architectures based on service identity, but also the ability to achieve repeatable application deployment lifecycles via Network Infrastructure Automation and control access to the service mesh via Consul API Gateway.These features are considered the four core pillars of Consul service networking.

If you’re wondering if that classic car you’ve been scoping out on Bring a Trailer or eBay Motors is as authentic as posited by the seller – specifically re: the common claims of “original paint” or “high quality respray” – you’re going to want to take a closer look around the edges. This is because a talented painter can make a second or 30th-hand vehicle look pretty snazzy with a well-affected, if not super high-quality, repaint.

In Part I in our series outlining best practices for scaling observability, we reviewed the data analysis capabilities that can help engineers troubleshoot faster during high pressure situations during a game launch. Nobody wants lag time or crashes in their game launch. Similarly, no one wants terminated sessions or for your gamer customers to log off and play a competitor’s game.

We believe that one of the most powerful capabilities added to the Logz.io Observability Platform in recent months is our new Service Performance Monitoring (SPM) feature set. As you may have seen earlier this year, Logz.io was named a Visionary in the 2022 Gartner® Magic Quadrant(™) for Application Performance Monitoring and Observability. To that end, SPM is a cornerstone for our related solutions.

After months–or potentially, years–of hard work by teams across a gaming enterprise, when the day arrives for a game launch, the last thing your enterprise needs is slowdowns, glitches, outages or poor performance. It’s the death knell for any game, because for your avid gaming customers, there’s always something else (read: a game that isn’t yours) to check out.