As an industry analyst at Gartner, we would often discuss whether people were in a centralized or decentralized cycle. In business, it’s normal to investigate options for creating innovation and moving quickly, or focus on reducing cost and optimizing teams and technologies.
The popularity of Prometheus speaks for itself. The project doesn’t post official numbers, but there are at least 500,000 companies using this project today as one of the most mature CNCF projects – one that has over 40k Github stars as of the writing of this blog. And since Prometheus is highly interoperable, compatibility is key. This comes into play not only with the exporters, but also with long-term storage options and alerting systems.
Windows applications constitute a large portion of the services and applications that run in many organizations. When moving to a Kubernetes-based architecture, there is a need to support these as well. Up until April 2020, the lack of container support within the Windows operating system left Linux container images as the only viable option for Kubernetes container deployment.
You have probably heard of Log4Shell, the security vulnerability that has ‘earned’ itself an NIST rank of 10: In this post I will show a really basic example of how this vulnerability actually works. I will walk you through some basic usage of the Log4J library and then show how some fairly basic inputs into this library can cause truly unexpected, and potentially disastrous, outcomes.
Amazon Elastic Compute Cloud (a.k.a., EC2), is no doubt the core current computing infrastructure. It sits at the heart of AWS, the main kind of structure for housing virtual machines and containers for development and operations. Applying standards of observability with EC2 logs and obviously EC2 metrics (or any kind of AWS metrics for that matter) will inform you on if you have the right sorts of instances in place (and the appropriate size of those instances).
In this tutorial, we will go through a working example of a Node.js application auto-instrumented with OpenTelemetry. In our example we’ll use Express, the popular Node.js web application framework. Our example application is based on two locally hosted services sending data to each other. We will instrument this application with OpenTelemetry’s Node.js client library to generate trace data and send it to an OpenTelemetry Collector.
During Logz.io’s ScaleUp 2021 user conference, we announced that Unified Dashboards were coming to you soon. And now it’s finally here for anyone to try during the Public Beta. Unified Dashboards will allow Logz.io customers to analyze and filter their logs, metrics, and traces side-by-side on a single monitoring dashboard. Check out our recent blog to learn about why we built Unified Dashboards and the value they bring to customers.
Logz.io has dedicated itself to encouraging and supporting cloud-native development. That has meant doubling down on support for AWS and Azure, but also increasing our tie-ins with Google Cloud Platform – GCP. Recently, our team added dozens of new integrations for metrics covering the gamut of products in the GCP ecosystem.
In the domain of cyber threat response, there’s a critical resource that every organization is desperately seeking to maximize: time. It’s not like today’s DevOps teams aren’t already ruthlessly focused on optimizing their work to unlock the greater potential of their human talent. Ensuring your organization to identify and address production issues faster – and increase focus on innovation – is the primary reason why Logz.io and its observability platform exist.
