Today we’re excited to announce Logz.io Telemetry Collector – an agent that can send logs, metrics, and traces to Logz.io in a single installation as part of our Open 360™ platform. With Telemetry Collector, customers can get started monitoring their services with Logz.io faster than ever by simplifying the data collection process.
Our product strategy this year was relatively simple. Many observability practitioners we spoke with complained that observability was oftentimes slow, heavy, complex, and costly – which can be summed up in our CEO’s recent blog on modern observability challenges. While our customers didn’t report similar challenges, we wanted to further distance ourselves from this typical observability experience.
Today, I’m thrilled to announce the introduction of Logz.io Open 360™. This is a major step in our journey. Open 360 is a unified platform for modern engineering teams requiring end-to-end observability across logs, metrics and traces—delivered in an intuitive user interface. Open 360™ is specifically designed to enable engineers to have deep monitoring and insights into distributed systems.
What’s the ultimate goal of bringing observability into an organization? Is it just to chase down things when they’re broken and not working? Or can it be used to truly enable developers to innovate faster? That’s a topic I recently discussed with David Ostrovsky, a software engineer at Meta, the parent company of social media networks Facebook and Instagram among others. He was my guest on the most recent episode of the OpenObservability Talks podcast.
OpenSearch was created by the community for the community to continue to keep an open-source alternative to ElasticSearch and Kibana. The project has been hard at work for the last 1.5 years building, launching and iterating on this important initiative. Some remarkable milestones have been achieved, including over 5,800 stars on GitHub with 19 different community-led projects.
In an era where there’s no shortage of established best practices and tools, engineering teams are consistently finding their ability to prevent, detect and resolve production issues is only getting harder. Why is this the case? Our most recent DevOps Pulse Survey highlighted alarming trends to this end.
Today’s Managed Security Service Providers (MSSPs) are trying to grow their business quickly, improving margins and onboarding customers with high-quality tool sets that scale with the business. This means reducing cost, improving onboarding time and building the next generation of Managed Detection and Response (MDR) to deal with threats that are increasing in volume and sophistication.
Everyone’s talking about Platform Engineering these days. Even Gartner recently featured it in its Hype Cycle for Software Engineering 2022. But what is Platform Engineering really about? Is it the next stage in the evolution of DevOps? Is it just a fancy rebrand for DevOps or SRE? As a veteran of the PaaS (Platform as a Service) discipline about a decade ago, and a DevOps enthusiast at present, I decided to delve into this topic, peel off the hype, and see what it’s about in practice.
Microservices architecture is the new norm for building products these days. An application made up of hundreds of independent services enables teams to work independently and accelerate development. However, such highly distributed applications are also harder to monitor. When hundreds of services are traversed to satisfy a single request, it becomes difficult to investigate system issues.
Ask any cloud software team using Kubernetes (and most do); this powerful container orchestration technology is transformative, yet often truly challenging. There’s no question that Kubernetes has become the de-facto infrastructure for nearly any organization these days seeking to achieve business agility, developer autonomy and an internal structure that supports both the scale and simplicity required to maintain a full CI/CD and DevOps approach.
