Connecting OpenTelemetry to Jujing OBSERVE: A Zero-Instrumentation Walkthrough

Why use a Collector instead of connecting directly

The most common mistake when onboarding an observability platform is pointing SDKs straight at the backend. The moment you need to switch backends, add filtering, or scrub sensitive fields, you have to touch application code. The right approach is to put an OpenTelemetry Collector in the middle: applications only send data to a local Collector, and routing, sampling, scrubbing, and export all happen there.

The Collector also decouples your applications from your vendor. Swap the exporter and you have moved to another backend without redeploying a single service. It buffers data during network blips, applies consistent sampling across all services, and gives you one place to strip secrets from logs before they leave the building. Below we go through three steps, deploy the Collector, auto-instrument, verify, without changing any business code.

Step 1: Deploy the Collector

Download the binary or container image for your platform, then focus on the config file otelcol-config.yaml. Pointing at Jujing OBSERVE's OTLP endpoint looks like this:

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://ob.jjhub.cn/otel/v1/traces
    headers:
      Authorization: "Bearer <your token>"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp]

A few notes on the config. memory_limiter keeps a traffic spike from crashing the Collector; set limit_mib to about half the machine's RAM. batch groups spans before sending to cut network overhead, and a 1-5 second timeout is a good balance between freshness and efficiency. The token is generated under "Access Management" in the OBSERVE console and is scoped per team, so each team's data stays separated even though they share one endpoint.

Step 2: Auto-instrument without touching business code

For a Java service, add a single agent argument to the startup command:

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

Python uses the SDK packages:

pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install
opentelemetry-instrument   --traces_exporter otlp   --metrics_exporter otlp   --exporter_otlp_endpoint http://localhost:4317   python app.py

Go uses compile-time injection or runtime auto-instrumentation, and Node.js loads via --require. The common thread is that the exporter points at the local Collector (localhost:4317) rather than the platform directly. Logs and metrics work the same way: for metrics, run the OTLP exporter alongside a Prometheus scraper or let your existing Prometheus remote-write to OBSERVE; for logs, use the Collector's Filelog receiver to tail files, or send structured logs straight over OTLP.

Step 3: Verify the data actually arrived

Once connected, first check the Collector's own logs for errors, then open the Tracing page in OBSERVE, filter by service name over the last five minutes, and confirm traces are landing. Go one step further: trigger a request, capture its traceId, and search logs with traceId = 'xxx'. If the request's context logs come back, logs and traces are already correlated.

For metrics, open the service's dashboard and confirm the golden signals such as request rate, error rate, and latency show a live line rather than a flat zero. If metrics are empty but traces are fine, the usual cause is a missing metrics pipeline in the Collector config or the exporter pointed at the wrong endpoint.

Common issues

• Traces arrive but logs don't match: check whether your logs carry a trace_id field and whether the parsing rules have structured it.
• High latency: usually the batch timeout is too large; drop it below one second.
• Collector memory keeps climbing: set memory_limiter.limit_mib to about half the machine's RAM and confirm no exporter is buffering redundantly.
• Metrics empty while traces flow: you likely forgot the metrics pipeline in the Collector config.

Work through this flow and logs, metrics, and traces will all be flowing into the platform, ready for alerting and topology analysis. The natural next step is to promote a few critical queries into alerts and turn on the service topology view to see how your services actually depend on each other. When you are happy with a single service, roll the same Collector config out across the fleet: because it runs locally on each node, adding more services is just a matter of pointing them at the node's Collector, not reconfiguring a central pipeline.