← Back to blog
Guide 4 min read 炬鲸团队

Onboard OpenTelemetry in 15 Minutes: From Collector to Trace Visualization

A step-by-step guide to deploying the OpenTelemetry Collector, exporting OTLP data to JJHub OBSERVE, and auto-instrumenting a Java service. Covers verification steps and common pitfalls so you get end-to-end tracing in about 15 minutes.

Prerequisites

Before you start, make sure of three things: JJHub OBSERVE is deployed and you have the OTLP endpoint (something like https://obs.example.com/otlp); you have a Java 8+ service to instrument; and the server can reach the Collector over the network.

The architecture is simple: the application pushes trace data to the Collector via the OTLP protocol, and the Collector handles buffering, redaction, and sampling before exporting to JJHub OBSERVE.

Deploy the Collector

Spin up an OpenTelemetry Collector. Docker is the fastest route:

receivers:
  otlp:
    protocols:
      grpc:
      http:
exporters:
  otlphttp:
    endpoint: https://obs.example.com/otlp
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp]

Mount the config and run:

docker run -p 4317:4317 -p 4318:4318 \
  -v $PWD/otel-config.yaml:/etc/otelcol/config.yaml \
  otel/opentelemetry-collector-contrib

Port 4317 is gRPC, 4318 is HTTP. For a quick trial you can skip the Collector and point the app straight at OBSERVE's OTLP endpoint. In production, keep the Collector — it's the single place where buffering, redaction, and sampling all happen.

Auto-Instrument a Java Service

Use the Java agent for zero-code instrumentation. Download opentelemetry-javaagent.jar and add it at startup:

java -javaagent:opentelemetry-javaagent.jar \
  -Dotel.service.name=order-service \
  -Dotel.exporter.otlp.endpoint=http://localhost:4317 \
  -Dotel.traces.exporter=otlp \
  -Dotel.metrics.exporter=none \
  -jar app.jar

service.name is how the service shows up in traces, so give it a meaningful name — we recommend an "environment-service" format. The agent instruments Spring MVC, HTTP clients, JDBC drivers, Redis, Kafka, and most common libraries with no business-code changes.

Verify and Troubleshoot

Fire a few requests, then open the Tracing page in OBSERVE:

  1. Filter by order-service and you should see requests.
  2. Open a trace and inspect the span tree — the entry span, database calls, and downstream HTTP calls should show clear parent-child relationships.
  3. Focus on the slowest span; that's usually your bottleneck.

Common problems:

  • Can't reach the Collector: check that port 4317 is open and that the endpoint includes the http:// prefix.
  • Traces arrive but fields are incomplete: confirm OBSERVE has data reception enabled for the service and check whether sampling is too aggressive.
  • Downstream calls missing: downstream services need the agent too, otherwise their spans never get reported.

Sampling and Cost

By default everything is sampled, which will drown you under load. Add a probabilistic_sampler in the Collector and keep 10–20%, raising it temporarily during incidents. The value of tracing is in locating the problem, not in how much you store.