We’re proud to announce the creation of a new RemoteWrite SDK to support custom metrics from applications using Golang (Go), Python, and Java, with many more on the way. Each SDK will have automatic, continuous deployment of updates. Using these integrations, Prometheus users can send metrics directly to Logz.io using the RemoteWrite protocol without sending them to Prometheus first.
In this post we will discuss some key considerations and strategies to monitor your AWS Lambda functions. This will include: which Lambda metrics you’ll want to monitor, how to collect AWS Lambda metrics with Prometheus and Logz.io, how to create a monitoring dashboard with alerts, and how to search and visualize your metrics.
Current observability practice is largely based on manual instrumentation, which requires adding code in relevant points in the user’s business logic code to generate telemetry data. This can become quite burdensome and create a barrier to entry for many wishing to implement observability in their environment. This is especially true in Kubernetes environments and microservices architecture.
I’m thrilled to say that OpenSearch has reached general availability (GA) with the release of version 1.0. This release represents a significant milestone and noteworthy accomplishment for a new open source initiative that was only launched a few months ago. I vividly remember that moment at the beginning of the year when we all woke up to Elastic’s announcement that it would take Elasticsearch and Kibana off the Apache 2.0 OSS license.
Crowdstrike is an innovator in the endpoint protection market with innovative approaches for the last decade. They specialize in depth of data collection and have uncovered many forensic mysteries in security over the last 10 years. We have many mutual customers with CrowdStrike, which is why we began working with them on a solution to analyze and correlate their data within Logz.io.
OpenSearch is a community response to the recent relicensing of Elasticsearch as a non-Open Source platform. AWS, Logz.io, and a number of partners have been working for months not only to make this merely compatible with Elasticsearch as a functional replacement, but also seeking to create an independent project roadmap.
When Logz.io was founded in 2015, we set out to simplify logging with the ELK Stack by delivering Elasticsearch and Kibana as a managed cloud service. But logs only tell part of the story – DevOps teams also need metric and trace data to better monitor the health and performance of their environment and quickly pinpoint the root cause of new problems. Importantly, using multiple tools to collect and analyze this data adds complexity and extra work.
Game development is an entirely different beast to other industries. Marketing, development, and release are more tightly interwoven than in other sectors, with a lot of pressure to meet community-anticipated milestones and launch. As such, it’s important to have game engine logging and monitoring pipelines set up for your projects. In other platforms, version upgrades and roll-outs tend to be sudden, with no definitive date set.
In this post, we will discuss some key considerations and strategies to collect and analyze your AWS Lambda logs. This will include 1) what to know about logging Lambda functions, 2) how to ship log data to a centralized logging solution, and 3) how to search and visualize log data on monitoring dashboards.
The aim of this article is to demonstrate how you can instrument a Java application using Opentelementry and Jaeger. In this example, we will be instrumenting our Java application using OpenTelemetry and the OpenTelemetry Java client, and the tracing data will be exported and visualized using Jaeger. We will use the Logz.io Jaeger backend as it is compatible with common tracing standards like Zipkin, OpenTelemetry, and OpenTracing.
