The SIEM is a central point where data is collected and correlated, and as we move to consume more cloud services and data sets the SIEM itself must also change in architecture. Architecture change is hard to make for existing products. Calling a product a ‘cloud solution’ is not the same as taking an on-premises product and hosting it for customers. It means building a new SIEM for a new world. There are a lot of reasons users seek new SIEMs.
Logz.io is proud to launch a new partnership with Microsoft that enables Azure customers to directly integrate with Logz.io’s platform from within the Azure Console. This integration importantly allows Azure developers to begin monitoring their workloads faster than ever before, using the open-source technologies that their teams love. Check out this video for a demonstration of how it works.
We just announced the creation of a new RemoteWrite SDK to support custom metrics from applications using several different languages. This tutorial will give a quick rundown of how to use the Python SDK. Using these integrations, Prometheus users can send metrics directly to Logz.io using the RemoteWrite protocol without sending them to Prometheus first. Each SDK, while for a separate language, is each capable of working with frameworks like Thanos, Cortex, and of course M3DB.
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.
