今日已更新 256 条资讯 | 累计 40701 条内容
关于我们

标签:#signoz

找到 3 篇相关文章

AI 资讯

Instrumenting My MERN E-Commerce Application with SigNoz: From Zero to Full Observability

Modern applications don't just need features—they need observability . When an API becomes slow, a database query takes too long, or an unexpected error occurs, developers need answers quickly. That's where SigNoz and OpenTelemetry come in. For the Agents of SigNoz Hackathon 2026 , I integrated SigNoz into my existing MERN Stack e-commerce application called Ram Store and transformed it into a fully observable application. In this blog, I'll walk through what I built, how I instrumented it, the challenges I faced, and what I learned. About the Project Ram Store is a full-stack e-commerce platform built using the MERN Stack. Features User Authentication Product Management Categories & Subcategories Shopping Cart Address Management Order Management MongoDB Database Tech Stack React (Vite) Node.js Express.js MongoDB Docker OpenTelemetry SigNoz Winston Logger Why Observability? Before integrating SigNoz, I could only rely on: console.log() Manual debugging Browser Network tab When something failed, I had questions like: Which API is slow? Why is the response delayed? Which MongoDB query is taking time? How many requests is my backend serving? Where exactly did the error happen? Without observability, finding answers takes time. I wanted a single place where I could monitor everything. That's why I chose SigNoz . Setting Up SigNoz I self-hosted SigNoz locally using Docker. Once all the containers were running successfully, the dashboard became available. After the initial setup, the next step was instrumenting my backend. Integrating OpenTelemetry I added OpenTelemetry to my Node.js backend. Using the Node SDK together with automatic instrumentation, I configured: Express instrumentation HTTP instrumentation MongoDB instrumentation OTLP gRPC exporter Now every request automatically generates telemetry without modifying every route. Distributed Traces One of my favorite features is Distributed Tracing . Whenever I perform an action in Ram Store—like opening products or ad

2026-07-27 原文 →
AI 资讯

How I Built Triage: Turning SigNoz into a Blue Team SOC (And the Deployment Nightmares I Survived)

Most people use OpenTelemetry and SigNoz to watch their CPU usage, find memory leaks, or figure out why their API is taking 400ms instead of 200ms. But for the Agents of SigNoz Hackathon (Track 3: Observe Anything Weird), I wanted to do something completely different. I didn't want to watch hardware. I wanted to watch hackers. That is how Triage was born. It is an OpenTelemetry-powered Blue Team SOC (Security Operations Center) that tracks active cyber attacks instead of just generic application performance. The Original Vision vs. The Reality Building this sounded straightforward on paper: catch bad traffic, wrap it in an OpenTelemetry span, send it to SigNoz, and show it on a custom dashboard. But actually deploying this beast before the deadline was a completely different story. If you have ever tried to deploy a full-stack Next.js app, a Python honeypot, and an OTel pipeline while the clock is ticking, you know exactly what kind of panic I am talking about. Here is what actually happened behind the scenes. 1. The Azure VM & Docker Crash I started by spinning up an Azure virtual machine to self-host the SigNoz backend. I pulled the repo, ran docker compose up -d, and immediately watched my server completely freeze. Turns out, my free tier Azure instance (Standard_B2ats_v2) only had 1 GiB of RAM. You simply cannot run a massive ClickHouse database and a full OTel collector on 1GB of memory without it crashing instantly. I had to pivot fast and rely on the cloud endpoints. 2. The Vercel vs Localhost Trap Once I got the backend running, I hit my next wall. My Vercel Next.js dashboard kept throwing 500 Internal Server Error on the threat simulation API, and the SigNoz connection kept reading OFFLINE (fetch failed). I was staring at my logs losing my mind until it clicked. My Vercel environment variables had SIGNOZ_API_URL set to http://localhost:8080 and my Python script was looking for OTel on localhost:4318. Note to self (and everyone else): Vercel is a cloud serve

2026-07-26 原文 →