It took me a long time to get all of the parts of the solution working. There were many reasons; I was new to the environment, some things were not obvious, and some of the documentation feels like it is written by experts for experts.

I learned the debug techniques while writing the Configuring opentelemetry, Jaeger, Prometheus, Grafana 101 the basics,102 doing processing, and 103 http endpoints posts.

Topics

• Reading test data from a file
• Monitoring traffic coming out of a pipe
• Displaying network traffic between containers
• Is z/OS data capture writing data?

Opentelemetry configuration problems.

You can specify print-initial-config as in

otel/opentelemetry-collector-contrib:latest print-initial-config –config otel-config.yaml

This is useful if you have more than one –config file.

Reading test data from a file

You can have JSON data read from a file, so you do not need to have a test creating data for you. It also means you get consistent data while developing the scenario

receivers:
  otlp_json_file:
     include:
      - /fooin.file
     start_at: beginning 
...
service:
  pipelines:

    traces/a:
      receivers: [otlp_json_file]  # oltp     
      exporters: [span_metrics]    # otlp_http,debug

Monitoring traffic coming out of a pipe

The output end of the pipe is defined using an exporter. There can be more than one end point defined, you can add an exported which writes to the terminal, or writes to a file.

For example the debug writes data to the terminal log. You can use the file to write data to a file.

exporters:
  
  file/b:
      path: /b.file       
  debug:
    verbosity: detailed # Options: basic, normal, detailed
    # sampling_initial: 2
    # sampling_thereafter: 10    
service:
  pipelines:
    traces/a:
      receivers: [otlp_json_file]  # oltp     
      exporters: [span_metrics]    # otlp_http,debug
    metrics:
      receivers: [span_metrics]
      exporters: [file/b,debug]  

You can tell debug to write every row, or the first n rows, then sample the remainder.

Using docker makes it easier and harder.

Using docker it was easy to spin up the parts and get them working. All pre-reqs were installed etc.
Docker uses it’s own internal network, and getting the component to talk to each other was harder.

Displaying network traffic between containers

You can use the docker command

docker network ls

this gives information like

NETWORK ID     NAME                  DRIVER    SCOPE
26d793ac45cf   bridge                bridge    local
4e4dc158fa88   host                  host      local
0cfcba5bb0ff   none                  null      local
03617d139834   otel-jaeger-network   bridge    local

Where the docker network I was using was called otel-jaeger-network.

On Linux the ip link command gave

4: br-03617d139834: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 12:87:1d:dc:7d:9a brd ff:ff:ff:ff:ff:ff
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 9a:9f:53:76:9d:a6 brd ff:ff:ff:ff:ff:ff

with the network prefixed with br ( for bridge).

Starting wireshark gave me a list of networks including br-03617d139834. I used this to display the traffic.

You can filter the traffic using filters like

tcp.dstport==4317

which says display records where the destination port was 4317. You could also use tcp.port=4317

This will allow you to see the traffic between containers.

Is z/OS data gathered writing data?

Initially it was challenging to see if data was being sent from z/OS. I had the situation where the first data was sent from z/OS, but then no more. I had to restart the data gatherer on z/OS.

I used

IJO="$IJO -Djavax.net.debug=ssl:handshake " 

to display the TLS handshake, and the message flow.

Example output

"certificate" : {                                                      
  "version"            : "v3",                                         
  "serial number"      : "02:ba",                                      
  "signature algorithm": "SHA256withECDSA",                            
  "issuer"             : "CN=SSCA256, OU=CA, O=SSS, C=GB",             
  "not before"         : "2026-06-29 02:36:41.000 EDT",                
  "not  after"         : "2029-01-30 11:46:00.000 EST",                
  "subject"            : "CN=tempcert, O=cpwebuse2, C=GB",             
  "subject public key" : "RSA",                                        
....

javax.net.ssl|DEBUG|D2|OkHttp https://10.1.0.2:4317/...|
2026-07-10 03:05:31.784 EDT|SSLSocketOutputRecord.java:334|
WRITE: TLSv1.3 application_data, length = 4854                                                                                                       
javax.net.ssl|DEBUG|F2|OkHttp 10.1.0.2
|2026-07-10 03:05:31.789 EDT|SSLSocketInputRecord.java:214
|READ: TLSv1.2 application_data, length = 47   
...                                                                                                                         

You can also use Wireshark to monitor traffic. With TLS 1.2 you can see details in the TLS handshake. With TLS 1.3 the details of the handshake are encrypted, and you just see the flow, and the data length.