Posts on Jan 1970

SigNoz: A Powerful Open Source APM and Observability Tool

Diving Deep into SigNoz: A Powerful Open Source APM and Observability Tool

Good morning everyone, I’m Dimitri Bellini, and welcome back to Quadrata, the channel where we explore the fascinating world of open source and IT. As I always say, I hope you enjoy these videos, and if you haven’t already, please consider subscribing and hitting that like button if you find the content valuable!

While Zabbix always holds a special place in our hearts for monitoring, today I want to introduce something different. I’ve been getting requests from customers about how to monitor their applications, and for that, you typically need an Application Performance Monitor (APM), or as it’s sometimes fancily called, an “Observability Tool.”

Introducing SigNoz: Your Open Source Observability Hub

The tool I’m excited to share with you today is called SigNoz. It’s an open-source solution designed for comprehensive observability, which means it helps you monitor metrics, traces (the calls made within your application), and even logs. This last part is a key feature of SigNoz, as it aims to incorporate everything you might need to keep a close eye on your applications.

One of its core strengths is that it’s built natively on OpenTelemetry. OpenTelemetry is becoming an industry standard for collecting telemetry data (metrics, traces, logs) from your applications and transmitting it to a backend like SigNoz. We’ll touch on the advantages of this later.

Why Consider SigNoz?

SigNoz positions itself as an open-source alternative to paid, proprietary solutions like Datadog or New Relic, which can be quite expensive. Of course, choosing open source isn’t just about avoiding costs; it’s also about flexibility and community. For home labs, small projects, or even just for learning, SigNoz can be incredibly useful.

Key Features of SigNoz

  • Application Performance Monitoring (APM): Out-of-the-box, you get crucial metrics like P99 latency, error rates, requests per second, all neatly presented in dashboards.
  • Distributed Tracing: This allows you to follow the path of a request as it travels through your application, helping you pinpoint bottlenecks and errors.
  • Log Management: A relatively recent but powerful addition, SigNoz can ingest logs, allowing you to search and analyze them, similar to tools like Greylog (though perhaps with fewer advanced log-specific features for now).
  • Metrics and Dashboards: SigNoz provides a user-friendly interface with customizable dashboards and widgets.
  • Alerting: You can set up alerts, much like triggers in Zabbix, to get notified via various channels when something goes wrong.

Under the Hood: The Architecture of SigNoz

Understanding how SigNoz is built is fundamental to appreciating its capabilities:

  • OpenTelemetry: As mentioned, this is the core component for collecting and transmitting data from your applications.
  • ClickHouse: This is the database SigNoz uses. ClickHouse is an open-source, column-oriented database management system that’s incredibly efficient for handling and querying millions of data points very quickly. It also supports high availability and horizontal scaling even in its open-source version, which isn’t always the case with other databases.
  • SigNoz UI: The web interface that allows you to visualize and interact with the data collected by OpenTelemetry and stored in ClickHouse.

For those wanting to try it out at home, you can easily get this all running with Docker.

The Power of OpenTelemetry

OpenTelemetry is a game-changer. It’s becoming a de facto standard, with even tools like Dynatrace now able to use OpenTelemetry as a data source. The community around it is very active, making it a solid foundation for a product like SigNoz.

Key advantages of OpenTelemetry include:

  • Standardization: It provides a consistent way to instrument applications.
  • Libraries and Agents: It offers out-of-the-box libraries and agents for most major programming languages, simplifying instrumentation.
  • Auto-Instrumentation (Monkey Patching): Theoretically, OpenTelemetry can automatically inject the necessary code into your application to capture telemetry data without you needing to modify your application’s source code significantly. You just invoke your application with certain environment parameters. I say “theoretically” because while I tried it with one of my Python applications, I couldn’t get it to trace anything. Let me know in the comments if you’d like a dedicated video on this; I’m curious to dig deeper into why it didn’t work for me straight away!

Getting Started: Installing SigNoz with Docker and a Demo App

For my initial tests, I used a demo application suggested by the SigNoz team. Here’s a rundown of how you can get started with a standalone Docker setup:

1. Install SigNoz

It’s straightforward:

  1. Clone the SigNoz repository: git clone https://github.com/SigNoz/signoz.git (or the relevant path from their docs).
  2. Navigate into the directory and run Docker Compose. This will pull up four containers:

    • SigNoz Hotel Collector (OpenTelemetry Collector): Gathers data from OpenTelemetry agents.
    • SigNoz Query Service/Frontend: The graphical interface.
    • ClickHouse Server: The database.
    • Zookeeper: Manages ClickHouse instances (similar to etcd).

You can usually find the exact commands in the official SigNoz documentation under the Docker deployment section.

2. Set Up the Sample FastAPI Application

To see SigNoz in action, I used their “Sample FastAPI App”:

  1. Clone the demo app repository: (You’ll find this on the SigNoz GitHub or documentation).
  2. Create a Python 3 virtual environment: It’s always good practice to isolate dependencies.
    python3 -m venv .venv
    source .venv/bin/activate

  3. Install dependencies:
    pip install -r requirements.txt

  4. Install OpenTelemetry components for auto-instrumentation:
    pip install opentelemetry-distro opentelemetry-exporter-otlp

  5. Bootstrap OpenTelemetry (optional, for auto-instrumentation):
    opentelemetry-bootstrap --action=install

    This attempts to find requirements for your specific application.

  6. Launch the application with OpenTelemetry instrumentation:

    You’ll need to set a few environment variables:

    • OTEL_RESOURCE_ATTRIBUTES: e.g., service.name=MyFastAPIApp (This name will appear in SigNoz).
    • OTEL_EXPORTER_OTLP_ENDPOINT: The address of your SigNoz collector (e.g., http://localhost:4317 if running locally).
    • OTEL_EXPORTER_OTLP_TRACES_EXPORTER: Set to otlp.
    • OTEL_EXPORTER_OTLP_PROTOCOL: Can be grpc or http/protobuf.

    Then, run your application using the opentelemetry-instrument command:

    OTEL_RESOURCE_ATTRIBUTES=service.name=FastApp OTEL_EXPORTER_OTLP_ENDPOINT="http://:4317" OTEL_EXPORTER_OTLP_TRACES_EXPORTER=otlp OTEL_EXPORTER_OTLP_PROTOCOL=grpc opentelemetry-instrument uvicorn main:app --host 0.0.0.0 --port 8000

    (Replace with the actual IP where SigNoz is running).
    The opentelemetry-instrument part is what attempts the “monkey patching” or auto-instrumentation. The application itself (uvicorn main:app...) starts as it normally would.

A Quick Look at SigNoz in Action

Once the demo app was running and sending data, I could see traces appearing in my terminal (thanks to console exporter settings). To generate some load, I used Locust with a simple configuration to hit the app’s HTTP endpoint. This simulated about 10 users.

Navigating to the SigNoz UI (typically on port 3301, or as configured, if you’re using the Docker setup that forwards to 8080 or another port for the frontend, but the collector often listens on 4317/4318), the dashboard immediately showed my “FastApp” service. Clicking on it revealed:

  • Latency, request rate, and error rate graphs.
  • A list of endpoints called.

Drilling down into the traces, I could see individual requests. For this simple “Hello World” app, the trace was trivial, just showing the HTTP request. However, if the application were more complex, accessing a database, for example, OpenTelemetry could trace those interactions too, showing you the queries and time taken. This is where it gets really interesting for debugging and performance analysis.

The SigNoz interface felt responsive and well-designed. I was quite impressed with how smoothly it all worked.

Final Thoughts and What’s Next

I have to say, SigNoz seems like a very capable and well-put-together tool. It’s definitely worth trying out, especially if you’re looking for an open-source observability solution.

I plan to test it further with a more complex application, perhaps one involving a database, to see how it handles more intricate call graphs and to really gauge if it can be a strong contender against established players for more demanding scenarios.

It’s also interesting to note that Zabbix has APM features on its roadmap, potentially for version 8. So, the landscape is always evolving! But for now, SigNoz is a noteworthy project, especially for those interested in comprehensive observability that includes metrics, traces, AND logs in one package. This log management capability could make it a simpler alternative to setting up a separate, more complex logging stack for many use cases, particularly in home labs or smaller environments.

So, what do you think? Have you tried SigNoz or other APM tools? Let me know in the comments below! If there’s interest, I can certainly make more videos exploring its features or trying out more complex scenarios.

Thanks for watching, and I’ll see you next week. A greeting from me, Dimitri!

Stay Connected with Quadrata:

📺 Subscribe to Quadrata on YouTube

💬 Join the Zabbix Italia Telegram Channel (Also great for general monitoring discussions!)

Read More
Red Hat Enterprise Linux 10 and Its Clones: What’s New and Which to Choose?

Red Hat Enterprise Linux 10 is Here: A Look at the New Release and Its Impact on Clones

Good morning everyone, I’m Dimitri Bellini, and welcome back to Quadrata, my channel dedicated to the world of open source and IT. This week, we’re shifting focus from our usual Zabbix discussions to something that’s recently made waves in the Linux world: the release of Red Hat Enterprise Linux 10 (RHEL 10)!

The arrival of a new RHEL version is always significant, especially for the enterprise sector. So, let’s dive into what RHEL 10 brings to the table and, crucially, how its popular clones – AlmaLinux, Rocky Linux, and Oracle Linux – are adapting to this new landscape. If you find this content useful, don’t forget to put a like and subscribe to the channel if you haven’t already!

What’s New in Red Hat Enterprise Linux 10?

Red Hat Enterprise Linux is renowned as the most important distribution in the enterprise world, where companies pay for official support and long-term stability. RHEL versions are designed to be stable over time, offer excellent hardware and software support, and typically come with at least 10 years of support. This makes it ideal for server and enterprise environments, rather than your everyday desktop.

With RHEL 10, Red Hat continues to build on this foundation while embracing new IT trends. Here are some of the key highlights:

Key Highlights of RHEL 10:

  • Kernel 6.12 (as mentioned): While the video mentions kernel 6.12, Red Hat typically focuses on stability for its enterprise releases. This means they select a mature kernel and then backport necessary bug fixes and feature advancements from newer kernels to their chosen stable version.
  • Image Mode with BootC: This is an interesting development that transforms the standard operating system concept towards an immutable distro model. Instead of traditional package management like RPM for updates, you create an OS image with everything needed. Updates involve deploying a new image, allowing for easy rollback to a previous version upon reboot. This simplifies OS updates significantly in certain contexts.
  • Wayland by Default: RHEL 10 moves decisively towards Wayland, with support for Xorg being removed, at least as the main desktop environment.
  • RDP for Remote Access: For remote access to RHEL 10 workstations, the system has transitioned from VNC to RDP (Remote Desktop Protocol), the well-known protocol from the Windows world, aiming for a more standard and efficient solution.
  • Architecture Upgrade to x86-64-v3: RHEL 10 has moved its baseline architecture level from x86-64-v2 to v3 during compilation. This means it embraces newer instruction sets in modern AMD and Intel processors but, importantly, drops support for older CPUs that don’t meet the v3 specification. If you’re running older hardware, this is a critical change.

The RHEL Clones: Navigating the Landscape After CentOS

As many of you know, Red Hat’s decision to shift CentOS from a direct RHEL rebuild to CentOS Stream (a rolling-release version that’s upstream of RHEL) led to the rise of several community-driven distributions aiming to fill the gap. The most prominent among these are AlmaLinux, Rocky Linux, and Oracle Linux, each striving to provide an enterprise-grade, RHEL-compatible experience.

With RHEL 10 out, these clones are now releasing their own version 10s. Let’s see how they’re approaching it.

AlmaLinux 10 “PurpleLion” – The Swift Innovator

AlmaLinux was quick to respond, releasing its version 10 (codename PurpleLion) just about a week after RHEL 10’s announcement. AlmaLinux is community-driven and has made some distinct choices:

  • Shift in Philosophy: While previously focused on “bug-for-bug” compatibility, AlmaLinux 10 aims for “Application Binary Interface (ABI)” compatibility with RHEL. This means it ensures applications compiled for RHEL will run on AlmaLinux, but it allows AlmaLinux to introduce its own improvements and not be 100% identical to RHEL.
  • Key Differentiators:

    • Kernel with Frame Pointers: AlmaLinux 10 tunes its kernel by enabling Frame Pointers. This can simplify debugging and profiling of the OS and applications, though it might introduce a slight performance overhead (around 1-2%).
    • Broader Hardware Support (x86-64-v2 and v3): Unlike RHEL 10’s default, AlmaLinux 10 provides options for both x86-64-v2 and x86-64-v3 architectures, offering kernels for older CPUs.
    • Continued SPICE Support: They continue to support the SPICE protocol for remote access to virtual machines, which was dropped in RHEL 9 and 10.
    • Additional Device Drivers: AlmaLinux 10 includes over 150 device drivers that Red Hat has dropped in its current version.
    • EPEL for v2: AlmaLinux is taking on the task of compiling EPEL (Extra Packages for Enterprise Linux) packages for the x86-64-v2 architecture, given their continued support for it.

  • Release Strategy: Aims to release major and minor versions as quickly as possible, gathering sources from various places.

Rocky Linux 10 – The Staunch Loyalist

Rocky Linux is known for its purist approach, aiming for 100% bug-for-bug compatibility with RHEL.

  • The Purist’s Choice: If you want a distribution that is as close to RHEL as possible, Rocky Linux is your go-to. The packages are intended to be bit-for-bit identical.
  • Release Strategy: More conservative. Rocky Linux typically waits for the general availability (GA) of the RHEL version before releasing its corresponding version to ensure full compatibility. As of this writing, Rocky Linux 10 has nightly builds available but is not yet officially released.
  • Kernel: The kernel is not altered and remains the same as in RHEL 10.
  • Architecture Support: Following RHEL’s lead, Rocky Linux 10 will focus on the x86-64-v3 architecture, meaning no default support for older v2 CPUs unless they decide to provide an alternative kernel.

Oracle Linux 10 – The Enterprise Powerhouse

Oracle Linux also maintains bug-for-bug compatibility with RHEL and is a strong contender, especially in enterprise environments.

  • Enterprise Focus: Offers 100% RHEL compatibility and the backing of a major vendor, Oracle, which also provides official support options.
  • Unbreakable Enterprise Kernel (UEK): A key differentiator is the option to use Oracle’s UEK. This is an Oracle-tuned kernel designed for better performance and efficiency, particularly for enterprise workloads and, naturally, Oracle’s own database products. Users can choose between the RHEL-compatible kernel or the UEK.
  • Release Timing: Oracle Linux releases typically follow RHEL’s official upstream release, as they need the sources to compile and verify. Version 10 is not yet available.

OpenELA: A Collaborative Effort for Enterprise Linux

After Red Hat changed how it provided sources, a new initiative called OpenELA (Open Enterprise Linux Association) was formed. This non-profit collaboration involves CIQ (the company behind Rocky Linux), Oracle, and SUSE. Their primary goal is to work together to obtain RHEL sources and continue to provide free and open enterprise Linux versions based on RHEL. Notably, AlmaLinux has chosen its own path and is not part of OpenELA.

Choosing Your Champion: AlmaLinux vs. Rocky Linux vs. Oracle Linux

So, with these options, which one should you choose?

  • AlmaLinux 10: Might be your pick if you appreciate faster release cycles, need support for older hardware (x86-64-v2), value features like enabled Frame Pointers, or require specific drivers/software (like SPICE) that RHEL has dropped. You’re okay with a distribution that’s binary compatible but not strictly bug-for-bug identical to RHEL.
  • Rocky Linux 10: If your priority is unwavering stability and 100% bug-for-bug compatibility with Red Hat Enterprise Linux, and you prefer a purely community-driven approach, Rocky Linux is likely the best fit.
  • Oracle Linux 10: If you’re operating in a large enterprise, might need commercial support, or could benefit from the potentially optimized performance of the Unbreakable Enterprise Kernel (UEK) for specific workloads, Oracle Linux is a strong contender.

The speed of release is also a factor for some. AlmaLinux tends to be the fastest, while Rocky Linux and Oracle Linux are a bit more measured. However, whether a release comes out a few weeks sooner or later might not be critical for many, as long as it’s timely.

My Perspective: Why Standardization Matters in the Enterprise

Personally, I’ve decided to stabilize on Red Hat and its derivatives for enterprise environments because standardization is fundamental. When you’re working in complex systems, introducing too many variables can lead to unpredictable problems.

I encountered a situation a while ago that illustrates this. We were setting up synthetic monitoring using a Selenium Docker container. It worked perfectly in our environment. However, for our client, who was using Podman (common in RHEL environments) instead of Docker as the container engine, the same setup was incredibly slow after just a few concurrent connections – the CPU would max out, and it was a complete mess. Understanding that subtle difference was key to resolving the issue.

This is why, for certain enterprise scenarios, I lean towards RHEL-based systems. They are often more rigorously tested and standardized for such environments, which can save a lot of headaches down the line.

Conclusion

The Linux distribution landscape is ever-evolving, and the release of RHEL 10 alongside new versions from its clones is a testament to this dynamism. Each distribution we’ve discussed offers a solid RHEL-compatible experience but caters to slightly different needs and philosophies.

I hope this overview has been interesting and helps you understand the current state of play. The choice ultimately depends on your specific requirements, whether it’s cutting-edge innovation, purist compatibility, or enterprise-grade support.

What are your thoughts on RHEL 10 and its clones? Which distribution are you leaning towards, or currently using, and why? Let me know in the comments below! The battle of distributions is always a hot topic!

Thanks for reading, and if you enjoyed this, please share it and make sure you’re subscribed to Quadrata on YouTube for more content like this. You can also join the conversation on our ZabbixItalia Telegram Channel.

A big greeting from me, Dimitri Bellini. Bye everyone, and I’ll see you next week!


Follow Quadrata:

Read More