Getting Started with OpenTelemetry: Ship Service Telemetry to JJHub Observe in 30 Minutes

The cheapest path to observability is not hand-rolled instrumentation; it's the OpenTelemetry (OTel) community standard. OTel defines a vendor-neutral way to emit traces, metrics, and logs from your application, plus a Collector that receives, processes, and forwards them. The steps below assume you already have a running service. We'll do three things: deploy a Collector, configure the exporter, and verify the data. You'll see traces and metrics without touching a single line of business code.

Prerequisites: Get the Endpoint and Token

Log in to the JJHub Observe console and open "Integration Center → OpenTelemetry". You'll see two values:

• OTLP Endpoint: https://otlp.ob.jjhub.cn:4318
• Token: used for auth, placed in the Authorization header of your config

Port 4318 is HTTP; 4317 is gRPC. Prefer gRPC inside your network — it's binary and cheaper on the wire. Use HTTP across the public internet, since it's easier to get through firewalls and proxies. Keep the token in a secret store, never in source control.

Deploy the Collector

In production, don't have every service dial the platform directly. A Collector in the middle gives you a single choke point for aggregation, redaction, and buffering. Run one with Docker:

# otel-collector.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
processors:
  batch:
    timeout: 5s
    send_batch_size: 1024
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
exporters:
  otlphttp:
    endpoint: https://otlp.ob.jjhub.cn:4318
    headers:
      Authorization: "Bearer <your-token>"
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp]

Start it:

docker run -d --name otel-collector   -v $PWD/otel-collector.yaml:/etc/otelcol/config.yaml   otel/opentelemetry-collector-contrib:latest

Reading the config top to bottom: the receivers listen on gRPC and HTTP, the processors batch telemetry and cap memory, and the exporter forwards to the platform over HTTP with your token in the header.

One common pitfall: the batch processor waits to accumulate a batch before sending. If you don't see data while testing, set timeout to 1s or drop batch temporarily. For redaction, add a redaction processor to strip credit-card numbers from span attributes before they leave your network — worth doing early, not after your first incident.

Attach the SDK to Your Service

For Java (Spring Boot), attach the agent — no code changes needed:

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

The agent auto-captures HTTP requests, database calls, and message-queue spans. Add -Dotel.resource.attributes=deployment.environment=prod so you can split prod from staging later. On the Python side it's the same idea:

pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-instrument   --service_name order-service   --exporter_otlp_endpoint http://localhost:4317   python app.py

Environment variables set the service name and endpoint; the instrumentation library wraps the frameworks for you.

Verify the Data

After deploying, open the "Tracing" page and fire a few requests. You should see traces within a minute. Check three things:

1. The trace list shows calls from order-service
2. Inside a trace, parent/child span relationships and durations look sane
3. On the "Logs" page, enable "Link to Trace" and confirm logs carry a trace_id

If traces arrive but logs don't, the log pipeline is probably missing or the app's logging library isn't wired to the OTel log bridge. For Java, check whether logback has the opentelemetry-logback-appender attached. For Python, confirm you launched with opentelemetry-instrument and a logging integration. Also confirm metrics appear on the Metrics page, keyed by service.name — the Collector reports its own metrics, but you want your service's.

Next Steps

At this point the data path is open. Add custom spans to key endpoints and put business dimensions (order ID, user ID) into attributes so you can search traces by order ID during an incident. Verify the agent captures your downstream HTTP and DB calls — most do out of the box — and add a manual span around any business logic hiding in a loop or a queue consumer, where auto-instrumentation can't see.

One more operational note: run two Collectors behind a load balancer if your service fleet is large, and set the memory limiter conservatively. A Collector that OOMs under a traffic spike will drop telemetry exactly when you need it most — right as an incident is unfolding. Monitor the Collector's own otelcol_exporter_sent_spans metric so you notice backpressure before it becomes a silent gap.