{"slug": "show-hn-snowglobe-a-whole-distributed-system-s-opentelemetry-from-one-binary", "title": "Show HN: Snowglobe: a whole distributed system's OpenTelemetry, from one binary", "summary": "ImmersiveFusion released Snowglobe, an Apache-2.0 open-source tool that generates synthetic OpenTelemetry data—logs, traces, and metrics—from a single binary simulating up to 28 services, including AI agentic traces under OTel GenAI semantic conventions. The tool, available as a 6.4 MB container, aims to help developers test observability backends without complex setups, and is positioned as a maintained alternative to existing generators like telemetrygen.", "body_md": "**A sealed world you can shake.**\n\nOne binary that generates a whole distributed system's telemetry: logs, traces and metrics from a topology of up to 28 services with the shapes real systems actually make. **The default ( -complexity normal) runs 20 traditional services; -complexity heavy adds the 8 AI services for 28.** Diamond dependencies, scatter-gather fan-out, sagas that compensate, timeouts that cascade. Point it at anything that speaks OTLP and watch it arrive.\n\nNo Docker Compose. No microservices to deploy. No 6GB stack to babysit. One executable, or a 6.4 MB container.\n\n```\ndocker run --rm immersivefusion/snowglobe -insecure -endpoint host.docker.internal:4317\n```\n\n**A public good for the OpenTelemetry community.** Apache-2.0, no account, no sign-up, no lock-in. The output is plain OTLP, so it works in whatever you already run: Jaeger, Tempo, Grafana, SigNoz, an OpenTelemetry Collector, or spatial tools such as DeepCube, which are one consumer among many.\n\n**How this differs from telemetrygen.**\n\n`telemetrygen`\n\ngenerates spans, and it is the official tool and good at that. Snowglobe generates a *system*: a topology with real dependency shapes, injectable failures, and AI agent spans under the OTel GenAI semantic conventions.\n\n**If you need load, use**\n\n`telemetrygen`\n\n. If you need something that looks like a production incident, that is what this is for.Most trace generators die. Their repos go quiet, the SDKs move, and the thing stops building. This one is maintained, and that is the point of it.\n\n**It has a sibling.** Snowglobe makes realistic telemetry out of nothing: **synthetic** OTel. [sos-beacon](https://github.com/ImmersiveFusion/sos-beacon) is the **organic** counterpart, a real workload doing a real job that emits real telemetry as a byproduct. Between them you can fill a backend with either kind.\n\nEvery existing trace generator falls into one of two categories:\n\n**Flat span generators**(telemetrygen, tracepusher) - produce uniform, identical spans with no service topology** Full demo apps**(OTel Astronomy Shop, Jaeger HotROD) - require Docker Compose with 15+ containers and ~6GB RAM\n\nAnd none of them generate **AI agentic traces**. The LLM observability market has no standalone tool that combines traditional APM with LLM observability. Every specialized LLM tool (Langfuse, LangSmith, Helicone, Arize, Traceloop, Portkey, Galileo) tracks token usage, model costs, and agent tool calls - but none of them provide traditional distributed tracing.\n\nThis tool generates **topology-rich, failure-injectable traces from a single binary** - covering both traditional microservice flows AND AI agentic patterns with OTel GenAI semantic conventions. One binary proves that a platform can visualize both. **The AI services and their GenAI spans are in the heavy tier, so run -complexity heavy to get them; the default emits traditional traffic only.**\n\n```\n# Download the latest release (or build from source)\ngo install github.com/ImmersiveFusion/snowglobe/cmd/snowglobe@latest\n\n# Send to a local OTLP collector (Jaeger, Tempo, etc.)\nsnowglobe -insecure\n\n# Send to a remote endpoint with auth headers\nsnowglobe -endpoint your-otlp-endpoint:443 -headers \"api-key=YOUR_KEY\"\n\n# Or set headers via the standard OTel environment variable\nexport OTEL_EXPORTER_OTLP_HEADERS=\"api-key=YOUR_KEY\"\nsnowglobe -endpoint your-otlp-endpoint:443\n```\n\n**Installed from an old path?** Releases up to v0.7.7 were published as `github.com/ImmersiveFusion/if-opentelemetry-tracegen`\n\n, and releases up to v0.8.0 as `github.com/ImmersiveFusion/opentelemetry-tracegen`\n\n. Pinned installs of those versions keep working, but `@latest`\n\non either old path stops resolving from the next release onward, so update your command to the path above. The installed binary is now named `snowglobe`\n\nrather than `tracegen`\n\n.\n\nSee it in 3D- Send traces to[DeepCube](`snowglobe -endpoint otlp.deepcube.ai:443 -headers \"api-key=YOUR_KEY\"`\n\n,[how to get a key]) to explore them as a 3D force-directed graph, drill into conventional trace waterfalls for detailed analysis, and get AI-assisted insights from[Tessa]. For a ready-made example without any setup, try[Shoebox]at[shoebox.deepcube.ai]- paste a diagram of a system, break a call in it, and fire one request through.\n\nSeven always-on demo grids stream live OpenTelemetry traces, logs and metrics into DeepCube's 3D player right now: a clean baseline, an AI-native app, a blended environment, phantom-service detection, an AI-outage, and a full incident. Each grid is this container, deployed declaratively via GitOps (Argo CD) in the Immersive Fusion cloud, multi-arch and distroless, one matrix row per grid, shipping to `otlp.deepcube.ai:443`\n\n.\n\n**Just want to look?** The grids are streamed live on Twitch at [twitch.tv/deepcubelive](https://www.twitch.tv/deepcubelive), around the clock. No account, no install, nothing to sign up for. It is running whether or not you do anything, which is the easiest way to see what this generator's output actually looks like at the other end.\n\n**See them in 3D:** the full experience is [DeepCube](https://docs.deepcube.ai/DC/3D/), the immersive 3D client: install it and open a grid to walk the live traces. On mobile or can't install right now? [DeepCube Web](https://docs.deepcube.ai/DC/Web/) runs the same grids in your browser at [portal.deepcube.ai](https://portal.deepcube.ai).\n\n** Where else does Snowglobe run?**: a community board of deployments. Add yours.\n\n| Service | Pods | Role |\n|---|---|---|\n| web-frontend | 2 | Browser client, SPA |\n| api-gateway | 3 | HTTP routing, auth |\n| order-service | 3 | Order lifecycle |\n| payment-service | 2 | Stripe integration |\n| inventory-service | 2 | Stock management |\n| notification-service | 2 | Event-driven notifications |\n| user-service | 2 | Auth, profiles |\n| cache-service | 3 | Redis cluster |\n| search-service | 2 | Elasticsearch queries |\n| scheduler-service | 1 | Cron jobs (singleton) |\n| auth-service | 3 | JWT, webhook verification |\n| recommendation-service | 2 | ML-based recommendations |\n| cart-service | 2 | Shopping cart |\n| product-service | 3 | Product catalog |\n| shipping-service | 2 | Rates, labels, tracking |\n| fraud-service | 2 | ML fraud scoring |\n| email-service | 2 | SMTP relay (SendGrid) |\n| tax-service | 1 | Tax calculation |\n| analytics-service | 3 | Event tracking (Kafka) |\n| config-service | 1 | Feature flags |\n\n| Service | Pods | Role |\n|---|---|---|\n| llm-gateway | 3 | OpenAI API routing, token tracking |\n| embedding-service | 2 | Text-to-vector operations |\n| vector-db-service | 2 | Qdrant similarity search |\n| ai-agent-service | 2 | Agent orchestration (plan/act/reflect) |\n| content-moderation-service | 2 | Safety classifiers, PII detection |\n| model-registry-service | 1 | Model versioning (singleton) |\n| feature-store-service | 2 | ML feature serving |\n| data-pipeline-service | 2 | Batch embedding, retraining |\n\nAll 59 pods are distributed across 5 AKS VMSS nodes (2 node pools) with realistic `service.instance.id`\n\nand `host.name`\n\nresource attributes.\n\n| Scenario | Graph Shape | Key Pattern |\n|---|---|---|\nCreate Order |\nLong chain (8 services, 14+ spans) | Producer/consumer with queue delays |\nSearch & Browse |\nLinear with cache | Elasticsearch + Redis |\nUser Login |\nBranching (success/failure) | Auth with session creation |\nFailed Payment |\nError chain | Stripe 402 + error propagation |\nBulk Notifications |\nFan-out (3-5 parallel) | Batch email processing |\nHealth Check |\nStar topology (6 parallel) | Concurrent health pings |\nInventory Sync |\nFan-out + reindex | Parallel cache warming |\nScheduled Report |\nHeadless chain (no UI) | Cron job entry point |\nStripe Webhook |\nHeadless chain (no gateway) | External callback entry |\nRecommendations |\nScatter-gather / bowtie | Fan-out to 3, gather, cache |\nAdd to Cart |\nCross-service with feature flags | Config service + analytics |\nFull Checkout |\nMonster chain (15 services) | Tax+shipping parallel, fraud ML |\nShipping Update |\nCarrier webhook (headless) | External webhook + email relay |\nSaga Compensation |\nForward chain + 4-way compensation fan-out | Payment retries + rollback |\nTimeout Cascade |\nBranching with circuit breaker | Stale cache fallback |\nUser Registration |\nLinear with async branch | Email verification token, duplicate detection |\nProduct Review |\nWrite + async moderation | Optimistic write + background processing |\nReturn/Refund |\nParallel reverse flow (16-18 spans) | Parallel refund + restock, reverse money flow |\nWishlist + Price Alert |\nWrite-through with async | Write-through cache, async price monitoring |\nCoupon Application |\nValidation chain | Cart recalculation, validation branch |\nGift Card Purchase |\nPayment splitting | Balance check, payment splitting |\nSubscription Management |\nWebhook-driven lifecycle | Stripe subscription, renewal webhook |\nA/B Test Exposure |\nFeature flag branch | Variant assignment, sticky session |\nRate Limiting |\nEarly termination (4-6 spans) | Redis sliding window, 429 response |\nAdmin Product CRUD |\nWrite-amplification fan-out | Cache + search reindex on write |\nOrder History |\nPaginated read | Keyset pagination, cursor-based |\nSupport Ticket |\nCross-domain trace | SLA assignment, team routing |\nMulti-Currency Checkout |\nExternal API chain | FX rate API, cache hit ratio |\n\n| Scenario | Graph Shape | Key Pattern |\n|---|---|---|\nSemantic Search (RAG) |\nLinear with 2 LLM calls (14-16 spans) | Embedding + vector search + LLM reranking |\nAI Chatbot with Tool Use |\nDouble bowtie (18-22 spans) | Plan -> fan-out tool calls -> synthesize |\nAI Content Moderation |\nParallel classifiers + 3-way branch (12-16 spans) | Safety/spam scoring, guardrail decisions |\nMulti-Step Agent |\nIterative loop (28-40 spans) | Plan -> act -> reflect cycle (3-5 iterations) |\nAI Customer Support |\nBranching with escalation (16-20 spans) | Sentiment classification, intent detection |\nAI Content Generation |\nLinear with safety filter (12-15 spans) | Temperature-controlled generation, content safety |\nEmbedding Pipeline |\nHigh fan-out batch (25-40 spans) | Batch chunking, parallel embedding, vector upsert |\nDynamic Pricing Agent |\nHeadless agent (14-18 spans) | Feature store lookup, autonomous price updates |\nFraud with Explainability |\nLinear with LLM explanation (10-12 spans) | SHAP-style feature attribution via LLM |\nInventory Reorder Agent |\nAutonomous agent (16-20 spans) | Demand forecast, autonomous purchase orders |\nModel Retraining Pipeline |\nBatch pipeline (14-18 spans) | ML training spans, model registry, quality gate |\nConversational Commerce |\nMulti-turn session (10-14 spans/turn) | Growing context tokens, session continuity |\n\nNote:Failed Payment, Saga Compensation, Timeout Cascade, lost messages, and retry storms only activate when`-errors > 0`\n\n. AI error scenarios (rate limits, hallucinated tool calls, token budget exceeded, content filter blocks) also require`-errors > 0`\n\n.\n\nEvery service emits OTel log records via OTLP alongside traces. Logs are automatically correlated with the active span context (trace_id, span_id), so your APM platform can link logs to the exact span that produced them.\n\n**ERROR** logs are emitted alongside every exception event (cache failures, DB errors, payment declines, LLM rate limits, agent failures)**WARN** logs fire on auth failures, content moderation flags, payment retries, and LLM fallbacks**INFO** logs cover request entry points, payment processing, fraud analysis, agent invocations, and iteration progress\n\nDisable with `-no-logs`\n\nto emit traces only.\n\nEvery service emits OTel metrics via OTLP alongside traces and logs. They are **derived from the spans the scenarios already produce**, so metrics and traces agree by construction: the p99 in a histogram is the same span you can click into.\n\nMetrics aggregate in process and flush on an interval, so unlike traces their volume is decoupled from `-level`\n\n. A `-level 10`\n\nrun emits roughly 350 traces/second and the *same* metric load as `-level 1`\n\n.\n\n| Metric | Type | What it shows |\n|---|---|---|\n`http.server.request.duration` |\nHistogram (s) | RED metrics per route, method and status. Semconv names, seconds, spec bucket boundaries |\n`http.server.active_requests` |\nUpDownCounter | In-flight requests, rising and falling with real scenario concurrency |\n`system.cpu.utilization` |\nGauge | Driven by each service's actual span volume, not a random walk |\n`system.memory.usage` |\nUpDownCounter | Resident memory, drifting with load. Carries `system.memory.state` |\n`db.client.connection.count` |\nUpDownCounter | Pool occupancy split `used` /`idle` , tracking real database spans |\n`tracegen.messaging.queue.depth` |\nGauge | Published minus consumed, per destination |\n`gen_ai.client.token.usage` |\nHistogram | Input and output tokens by model, system and operation |\n`gen_ai.client.operation.duration` |\nHistogram (s) | LLM call latency |\n\n**The queue depth is the one to watch.** Producer spans increment it and consumer spans decrement it, so running with `-no-consumers`\n\nmakes the backlog climb without bound while the trace graph still looks busy. That is a story traces alone can only imply.\n\n**Naming.** Where OpenTelemetry defines a metric, Snowglobe uses its name and conforms to its contract, including seconds as the unit. Everything else lives under a `tracegen.`\n\nprefix rather than extending a semconv namespace. That prefix keeps the old name on purpose: a metric name is a wire contract, and renaming it to `snowglobe.`\n\nwould break every dashboard and alert already keyed on it. Do not sweep it.\n\n**Cardinality.** `service.instance.id`\n\nis deliberately **off** by default: it multiplies every series by the pod count (up to 59 at `-complexity heavy`\n\n), and metric backends commonly bill per active series with no cardinality control on an OTLP push path. Turn it on with `-metrics-instance-id`\n\nwhen per-pod resolution is the thing you are demonstrating. Metric attributes are an explicit allowlist, never a copy of the span's attributes, so user, session and order ids never reach a metric.\n\n**Temporality.** `-metrics-temporality delta`\n\nswitches from the default cumulative. Prometheus-backed stores are cumulative-native, while some OTLP ingest paths ask producers for delta, and which behavior a given endpoint implements is often undocumented. A producer that can emit either shape on demand is the cheapest way to settle that by experiment.\n\nDisable with `-no-metrics`\n\nto emit traces and logs only.\n\nAll AI scenarios emit spans following [OTel GenAI Semantic Conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/) and matching the exact span shapes produced by [Microsoft Semantic Kernel](https://learn.microsoft.com/en-us/semantic-kernel/concepts/enterprise-readiness/observability/) and [Microsoft Agent Framework](https://learn.microsoft.com/en-us/agent-framework/agents/observability).\n\n**Span types:**\n\n| Span Name Pattern | SpanKind | Example |\n|---|---|---|\n`chat {model}` |\nCLIENT | `chat gpt-4o` |\n`embedding {model}` |\nCLIENT | `embedding text-embedding-3-small` |\n`invoke_agent {name}` |\nCLIENT | `invoke_agent CustomerSupportAgent` |\n`execute_tool {name}` |\nINTERNAL | `execute_tool get_order_status` |\n`{operation} {collection}` |\nCLIENT | `query product-embeddings` |\n\n**Attributes on every LLM span:**\n\n`gen_ai.provider.name`\n\n- LLM provider (e.g.,`openai`\n\n)`gen_ai.request.model`\n\n/`gen_ai.response.model`\n\n- model requested and used`gen_ai.usage.input_tokens`\n\n/`gen_ai.usage.output_tokens`\n\n- token consumption`gen_ai.response.finish_reasons`\n\n- completion reason (`stop`\n\n,`tool_calls`\n\n,`length`\n\n,`content_filter`\n\n)`gen_ai.response.id`\n\n- unique response identifier`gen_ai.request.temperature`\n\n,`gen_ai.request.max_tokens`\n\n- request parameters\n\n**Agent-specific attributes:**\n\n`gen_ai.agent.id`\n\n/`gen_ai.agent.name`\n\n/`gen_ai.agent.description`\n\n- agent identity`gen_ai.conversation.id`\n\n- session linking for multi-turn interactions`gen_ai.tool.name`\n\n/`gen_ai.tool.type`\n\n/`gen_ai.tool.call.id`\n\n- tool call tracking`gen_ai.data_source.id`\n\n- RAG data source identifier`gen_ai.request.embedding.dimensions`\n\n- embedding dimensions\n\nThese attributes match what every LLM observability tool on the market tracks - enabling direct comparison of visualization capabilities.\n\n| Feature | Description |\n|---|---|\nLost messages |\n5% chance per queue hop that the consumer never fires - trace ends abruptly |\nDead consumer mode |\n`-no-consumers` flag: producers fire, consumers never pick up |\nRetry storms |\nPayment retries 3x with exponential backoff before saga compensation |\nTimeout cascades |\nSearch service times out, gateway returns 504, circuit breaker serves stale cache |\nSaga compensation |\nPayment fails after order+inventory committed - triggers 4-way parallel rollback |\nLLM rate limits |\nOpenAI 429 with token budget details, fallback to text search |\nHallucinated tool calls |\nAgent requests non-existent tool, triggers error handling |\nToken budget exceeded |\nAgent exceeds iteration token limit, graceful degradation |\nContent filter blocks |\nSafety classifier blocks content, alternate flow triggered |\nTunable error rate |\n`-errors 0` (none) to `-errors 10` (chaos) with realistic .NET stack traces |\n\nThe generated traces simulate a .NET-based e-commerce platform with AI capabilities. Stack traces and library names reflect the .NET ecosystem by design.\n\n**Stack traces**: Npgsql, StackExchange.Redis, Stripe SDK, Elasticsearch.Net, System.Net.Http, OpenAI SDK, Qdrant client** Database operations**: PostgreSQL INSERT/SELECT/UPDATE with semantic conventions** Cache operations**: Redis GET/SET/HSET/MSET/DEL with TTL and key attributes** Messaging**: RabbitMQ and Kafka with producer/consumer span kinds and queue delays** External APIs**: Stripe charges, SendGrid email, UPS shipping, OpenAI chat/embeddings** LLM operations**: Chat completions, embeddings, agent tool calls with token tracking** Vector search**: Qdrant similarity search with cosine distance, dimension validation** Agent orchestration**: Plan/act/reflect loops, tool dispatch, session management** Content moderation**: Safety classifiers, PII detection, guardrail enforcement** ML inference**: Fraud detection model scoring with feature counts** Feature flags**: Config service checks that gate behavior\n\n```\nsnowglobe [flags]\n\nFlags:\n  -endpoint string     OTLP gRPC endpoint host:port (default \"localhost:4317\")\n  -headers string      OTLP headers as key=value pairs, comma-separated (or set OTEL_EXPORTER_OTLP_HEADERS)\n  -complexity string   Topology complexity: light, normal, heavy (default \"normal\")\n  -level int           Aggressiveness 1-10 (default 1)\n  -errors int          Error rate 0-10 (default 0)\n  -no-consumers        Disable all async consumers\n  -no-ai-backends      Disable LLM/AI backends (AI spans emit errors)\n  -ai-only             Only run AI agentic scenarios\n  -no-logs             Disable OTel log record emission (traces only)\n  -no-metrics          Disable OTel metric emission\n  -metrics-interval    Metric export interval (default 15s)\n  -metrics-temporality Metric aggregation temporality: cumulative or delta (default cumulative)\n  -metrics-instance-id Add service.instance.id to metrics (per-pod resolution; multiplies series count)\n  -metrics-verify      Emit tracegen.spans.emitted, the emission oracle\n  -insecure            Use plaintext gRPC (no TLS) for local backends\n  -log-level string    Console verbosity: silent, error, info, debug (default \"info\")\n  -quiet               Errors only (alias for -log-level=error); silences the periodic \"traces sent\" heartbeat\n```\n\nConsole verbosity.`silent`\n\n/`error`\n\nsuppress the periodic heartbeat. The startup banner (\"what it's doing\") and genuine errors/fatal exits always print to stderr at any level. You can also set it with the`TRACEGEN_LOG_LEVEL`\n\nenv var (handy for containers). Precedence:`-quiet`\n\n>`-log-level`\n\n>`TRACEGEN_LOG_LEVEL`\n\n> default (`info`\n\n). The published container image defaults to`TRACEGEN_LOG_LEVEL=error`\n\nso it doesn't spam logs; the bare CLI stays`info`\n\n. Override with`-e TRACEGEN_LOG_LEVEL=info`\n\n(or`-log-level`\n\n/`-quiet`\n\n).\n\n| Complexity | Services | Pods | Scenarios | Best for |\n|---|---|---|---|---|\nlight |\n10 core | ~20 (min replicas) | 6 | Clean demos, small graphs |\nnormal |\n20 traditional | ~40 | 16 | General testing, full e-commerce |\nheavy |\n28 (+ AI) | 59 | 20 (of 40 defined) | Full topology with AI agentic flows |\n\n**Light** includes only the e-commerce backbone: web-frontend, api-gateway, order-service, payment-service, inventory-service, user-service, cache-service, auth-service, product-service, and cart-service. Scenarios are limited to the core flows (Create Order, Search & Browse, User Login, Add to Cart, Full Checkout, Health Check).\n\n**Normal** (default) adds all remaining traditional services and scenarios including chaos/failure modes.\n\n**Heavy** adds all 8 AI services and 4 of the 12 AI agentic scenarios (RAG Search, AI Chatbot, Content Moderation, Multi-Step Agent).\n\n| Level | Label | Rate |\n|---|---|---|\n| 1 | whisper | ~2 traces/s |\n| 2 | gentle | ~3 traces/s |\n| 3 | calm | ~3 traces/s |\n| 4 | moderate | ~5 traces/s |\n| 5 | steady | ~7 traces/s |\n| 6 | brisk | ~15 traces/s |\n| 7 | aggressive | ~21 traces/s |\n| 8 | intense | ~40 traces/s |\n| 9 | firehose | ~83 traces/s |\n| 10 | SCREAM | ~350 traces/s |\n\n```\n# Send to a local Jaeger/Tempo/Collector (default endpoint localhost:4317)\nsnowglobe -insecure\n\n# Clean demo with minimal services - great for presentations\nsnowglobe -complexity light -level 1 -insecure\n\n# Full e-commerce topology (default)\nsnowglobe -level 1 -insecure\n\n# Everything including AI agentic scenarios\nsnowglobe -complexity heavy -level 3 -insecure\n\n# Moderate load with normal error rates\nsnowglobe -level 5 -errors 5 -insecure\n\n# Simulate dead consumers (messages pile up, consumers never fire)\nsnowglobe -level 3 -no-consumers -insecure\n\n# AI scenarios only - great for LLM observability testing\nsnowglobe -level 3 -ai-only -insecure\n\n# Simulate AI backend outage (LLM rate limits, timeouts)\nsnowglobe -level 5 -no-ai-backends -errors 5 -insecure\n\n# Chaos mode - maximum load and errors\nsnowglobe -level 10 -errors 10 -insecure\n\n# Send to a remote endpoint with authentication\nsnowglobe -endpoint otlp.example.com:443 -headers \"api-key=YOUR_KEY\"\n\n# Multiple headers via environment variable\nexport OTEL_EXPORTER_OTLP_HEADERS=\"api-key=SECRET,x-team=platform\"\nsnowglobe -endpoint otlp.example.com:443\n\n# Send to DeepCube (3D trace visualization)\nsnowglobe -endpoint otlp.deepcube.ai:443 -headers \"API-Key=YOUR_DEEPCUBE_KEY\"\n```\n\n| Capability | Snowglobe | OTel telemetrygen | OTel Astronomy Shop | Jaeger HotROD | k6 + xk6-tracing |\n|---|---|---|---|---|---|\n| Single binary, zero infra | Yes |\n1 binary | 15+ containers, ~6GB | 4 containers | k6 + extension |\n| Services | 28 |\n1 | ~22 | 4 | User-defined |\n| Pod instances | 59 |\n0 | 1/svc | 0 | 0 |\n| Scenario flows | 40 |\n0 | ~10 | 1 | User-defined |\n| AI agentic scenarios | 12 |\nNo | No | No | No |\n| OTel GenAI conventions | Yes |\nNo | No | No | No |\n| Agent tool call traces | Yes |\nNo | No | No | No |\n| RAG pipeline traces | Yes |\nNo | No | No | No |\n| Diamond dependencies | Yes |\nNo | Implicit | No | No |\n| Scatter-gather | Yes |\nNo | No | No | No |\n| Lost messages | Yes |\nNo | No | No | No |\n| Dead consumer mode | Yes |\nNo | No | No | No |\n| Saga compensation | Yes |\nNo | No | No | No |\n| Retry storms | Yes |\nNo | No | No | No |\n| Timeout cascade | Yes |\nNo | No | No | No |\n| LLM failure injection | Yes |\nNo | No | No | No |\n| Tunable error rate | 0-10 |\nNo | Fixed | No | No |\n| Tunable throughput | 2-350/s |\nRate flag | Locust | Fixed | k6 VUs |\n| Headless flows (webhook/cron) | 3 |\nNo | No | No | No |\n| Startup time | <1s |\n<1s | 3-5 min | 30s | <5s |\n\nWorks with any OTLP gRPC-compatible backend:\n\n- Any OpenTelemetry Collector\n- Datadog (with OTLP endpoint)\n- DeepCube (3D visualization)\n- Elastic APM\n- Grafana Tempo\n- Honeycomb\n- Jaeger\n- New Relic\n- Splunk Observability\n\nListed alphabetically on purpose. DeepCube is one consumer of this tool among many, and the tool is not built to favour it.\n\nThe AI agentic traces are also compatible with LLM-specialized observability tools that accept OTel input:\n\n- Langfuse (OTel-native since SDK v3)\n- Arize Phoenix (OTel instrumentation)\n- Traceloop / OpenLLMetry (built on OTel)\n\nPart of a small family of single-binary, zero-infra OTel tools, all Apache-2.0 and all usable without any Immersive Fusion account:\n\n- The[sos-beacon](https://github.com/ImmersiveFusion/sos-beacon)**organic** counterpart to this tool's synthetic output. A real workload doing a real job (surfacing people asking for help in public forums, for a human to answer), OTel-instrumented, so it emits genuine production telemetry as a byproduct. Where Snowglobe invents a system, sos-beacon*is*one.- The world you build, where Snowglobe is the world pre-made. Paste a Mermaid diagram of a system, break something in it, fire one request, and read what comes out. A snowglobe is sealed; in a shoebox you can open it up.[Shoebox](https://github.com/ImmersiveFusion/shoebox)[See both in 3D](https://shoebox.deepcube.ai).\n\n```\ngit clone https://github.com/ImmersiveFusion/snowglobe.git\ncd snowglobe\ngo build -o snowglobe ./cmd/snowglobe\n# Linux\nGOOS=linux GOARCH=amd64 go build -o snowglobe ./cmd/snowglobe\n\n# macOS (Apple Silicon)\nGOOS=darwin GOARCH=arm64 go build -o snowglobe ./cmd/snowglobe\n\n# Windows\nGOOS=windows GOARCH=amd64 go build -o snowglobe.exe ./cmd/snowglobe\n```\n\nThe LLM observability market is growing rapidly, but every specialized tool focuses exclusively on LLM workloads. No standalone LLM observability tool provides traditional APM capabilities. The only platforms addressing both are legacy APM giants (Datadog, New Relic, Dynatrace) adding LLM features to existing products.\n\nThis trace generator produces both traditional distributed traces AND AI agentic traces from the same binary - proving that a single platform can visualize both. The AI scenarios emit the exact same telemetry signals that Langfuse, LangSmith, Helicone, Arize, Traceloop, Portkey, and Galileo track.\n\nMicrosoft's Semantic Kernel and Agent Framework are the most widely adopted .NET AI frameworks. Their OTel instrumentation emits exactly three span types: `invoke_agent {name}`\n\n, `chat {model}`\n\n, and `execute_tool {function}`\n\n. Our AI scenarios produce traces structurally identical to what a real Semantic Kernel / Agent Framework application would emit - so observability platforms can be tested against realistic .NET AI workloads.\n\nThe [OTel GenAI Semantic Conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/) are being adopted across the ecosystem. Langfuse SDK v3 is OTel-native, LangSmith added OTel support, Arize Phoenix uses OTel instrumentation, and Traceloop's OpenLLMetry conventions were adopted into the official OTel spec. Building on these conventions ensures the generated traces are compatible with every tool that adopts the standard.\n\n| Source | Decision Informed |\n|---|---|\n|\n\n[OTel GenAI Agent Spans](https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-agent-spans/)[OTel GenAI Attribute Registry](https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/)`gen_ai.*`\n\nattribute list with types[MS Semantic Kernel Observability](https://learn.microsoft.com/en-us/semantic-kernel/concepts/enterprise-readiness/observability/)`gen_ai`\n\nattribute usage[MS Agent Framework Observability](https://learn.microsoft.com/en-us/agent-framework/agents/observability)`invoke_agent`\n\n, `chat`\n\n, `execute_tool`\n\n[Langfuse OTel Integration](https://langfuse.com/integrations/native/opentelemetry)[Traceloop OpenLLMetry](https://github.com/traceloop/openllmetry)[Email](mailto:info@immersivefusion.com) |\n[LinkedIn](https://www.linkedin.com/company/immersivefusion) |\n[Discord](https://discord.gg/zevywnQp6K) |\n[GitHub](https://github.com/immersivefusion) |\n[Bluesky](https://bsky.app/profile/immersivefusion.bsky.social) |\n[Twitter/X](https://twitter.com/immersivefusion) |\n[YouTube](https://www.youtube.com/@immersivefusion) |\n[Twitch](https://www.twitch.tv/immersivefusion)\n\nApache License 2.0 - see [LICENSE](/ImmersiveFusion/snowglobe/blob/main/LICENSE) for details.\n\nCopyright 2026 [ImmersiveFusion](https://immersivefusion.com)", "url": "https://wpnews.pro/news/show-hn-snowglobe-a-whole-distributed-system-s-opentelemetry-from-one-binary", "canonical_source": "https://github.com/ImmersiveFusion/snowglobe", "published_at": "2026-09-03 16:11:14+00:00", "updated_at": "2026-09-03 16:22:59.452084+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence"], "entities": ["ImmersiveFusion", "Snowglobe", "OpenTelemetry", "telemetrygen", "DeepCube", "Jaeger", "Tempo", "Grafana"], "alternates": {"html": "https://wpnews.pro/news/show-hn-snowglobe-a-whole-distributed-system-s-opentelemetry-from-one-binary", "markdown": "https://wpnews.pro/news/show-hn-snowglobe-a-whole-distributed-system-s-opentelemetry-from-one-binary.md", "text": "https://wpnews.pro/news/show-hn-snowglobe-a-whole-distributed-system-s-opentelemetry-from-one-binary.txt", "jsonld": "https://wpnews.pro/news/show-hn-snowglobe-a-whole-distributed-system-s-opentelemetry-from-one-binary.jsonld"}}