Loki is a open source log aggregation tool developed by Grafana labs. It is inspired by Prometheus and is designed to be cost-effective and easy to operate. But Loki also has some limitations, and you might want to explore some Loki alternatives for your log analytics. In this article, we will look at 11 log management tools you can use as a Loki alternative. Loki is designed to keep indexing low. It does this by making use of labels.

OpenTelemetry is the future of Observability, APM, Monitoring, whatever you want to call ‘the process of knowing what our software is doing.’ It’s becoming common knowledge that your time is better spent gaining experience with an open, standardized system for telemetry than closed-source or otherwise proprietary standard. This truth is so universally acknowledged that all the big players in the market have made announcements of how they’re embracing OpenTelemetry.

Welcome to the 28th edition of our monthly product newsletter - SigNal 28! Our team shipped many features and improvements last month. We also had an amazing team workation in Goa, India. Let’s dive in to see what humans at SigNoz were up to in the month of August 2023.

While support for logging in the OpenTelemetry Python project is listed as 'experimental,' it's completely possible to send logs from your Python application. The Opentelemetry Collector has support for numerous existing logging systems, effectively exporting log data from wherever you were sending logs currently; you can also use the filelog receiver to tail and send logs from files. The only 'experimental' portion of the Python SDK is sending logs directly from code-level instrumentation.

In this article, learn how to setup application monitoring for Python apps using an open-source solution, SigNoz.

We often get asked, what's the best place to get started with OpenTelemetry - host metrics, traces, or even logs? Hosts Nočnica Mellifera and Pranay will talk about taking your first steps to gathering OpenTelemetry data Below is the recording and an edited transcript of the conversation. Find the conversation transcript below.

This guide is for anyone who is getting started monitoring their application with OpenTelemetry, and is generating unstructured logs. As is well understood at this point, structured logs are ideal for post-hoc incident analysis and broad-range querying of your data. However, it’s not always feasible to implement highly structured logging at the code level.

Join Nočnica Mellifera and Pranay as they discuss architecting and collecting data with the OpenTelemetry Collector. We discuss using Apache Kafka queues to handle OTLP data, and why you probably shouldn't push OTel data straight to Postgres. Below is the recording and an edited transcript of the conversation. Find the conversation transcript below.👇 Nica: Hi everybody! If you're seeing this we're starting up we'll get started in just a moment here.

The team at SigNoz would like to share recent developments released this month that greatly enhance the ability to dynamically query your trace and log data. With these tools anyone can explore complex OpenTelemetry data and gain insight into their stack.

In a recent conversation on our SigNoz community Slack, a user shared their query that asks a deceptively simple question: what is the average time between two spans in a trace? The usefulness of this answer is evident if you think about how often the total trace time does not highlight the time you care about most. This could mean any number of things: that the total trace time of handling a web request might include lots of spans after a satisfying response was sent to the user.