Operations | Monitoring | ITSM | DevOps | Cloud

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.

In my last blog post, Building a Cost-Effective Full Observability Solution Around Open APIs and CNCF Projects, we introduced using ChaosSearch in combination with the most popular open source front- and back-ends in the application observability space. In case you missed it, the TL;DR version is that you can use a variety of open source projects and open API-based components to build the best-of-breed observability stack of your choice rather than relying on expensive, all-in-one solutions.

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.

Monitor Oracle DB in Google Cloud Platform with the Google Ops Agent. The Ops Agent is available on GitHub, and makes it easy to collect and ship telemetry from dozens of sources directly to your Google Cloud Platform. You can check it out here! Below are steps to get up and running quickly with observIQ’s Google Cloud Platform integrations, and monitor metrics and logs from Oracle DB in your Google Cloud Platform.

Building modern, cloud-native applications introduces new challenges to teams and organizations. As these systems grow and scale, struggles abound: inconsistent performance monitoring experiences across siloed tools, wasteful performance management practices with duplicated efforts, and mounting frustration from colleagues and customers. Surmounting these challenges requires multiple sources of data and truly unified observability.

Since introducing BindPlane OP earlier this year, we’ve received a lot of feedback asking for the enterprise features you require to deploy in production. With functionality like SSO, RBAC, and Audit reporting all surfacing to the top of that list. Today we’re launching BindPlane OP Enterprise in beta, which introduces support for LDAP and AD authentication. We’d love for you to try it out and let us know what you think.

Depending on your business, MTTR stands for mean time to repair or mean time to recovery – but it can also mean resolution, resolve, or restore. No matter how you define it, the basic measurement is the same: it’s the time it takes from when something goes down to when it is back and fully functional. This includes everything from finding the problem to fixing it. For ITOps teams, keeping MTTR to an absolute minimum is crucial.

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.