Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

traceparent header doesn't get propagated from golang applications when its added as a sidecar in kubernetes #757

Open
lokesh411 opened this issue Apr 18, 2024 · 6 comments

Comments

@lokesh411
Copy link

lokesh411 commented Apr 18, 2024

Hey
I have written an API in golang (Service A using gofiber as http framework) which will call one of my services which is written in NodeJS (service B), the sidecar is only added to the service A. So when i hit the API of service A with a traceparent header, when an API call is made from this route, the traceparent header is not propagated
Please help me understand if i have misunderstood something
Thanks in advance

@grcevski
Copy link
Contributor

grcevski commented Apr 18, 2024

Hi, what you describe here should've worked. Do you mind adding BEYLA_PRINT_TRACES=1 (as environment variable) or add print_traces: true in your Beyla configuration and show us the output? It will print on the standard output what server and client calls it's capturing and what the TraceIDs are.

We haven't tested with gofiber, if you have a simple example for us to try with that doesn't work, that will also help a lot.

Thanks!

@lokesh411
Copy link
Author

Hey

beyla 2024-04-18 19:06:18.4187618 (386.604µs[386.604µs]) 200 POST /v1/traces []->[otel-trace-lb.monitoring:4318] size:563B svc=[services/profile-service go] traceparent=[00-979f230b1d3f9c1839b20877bfcc836c-0000000000000000-01]

This is the debug trace that i got in service A, the traceparent is completely different which was passed to service B
Here is the example snippet which i used to test

router.Post("/test/golang", func (c *fiber.Ctx) error {
		url := "http://b-service:3000/hello"
		method := "GET"
	
		client := &http.Client{}
		fmt.Println("The request headers for this request is :: ", c.GetReqHeaders())
		req, err := http.NewRequest(method, url, nil)
	
		if err != nil {
			fmt.Println("Error in creating a request to data-service :: ", err)
			return err
		}
		res, err := client.Do(req)
		if err != nil {
			fmt.Println("Error in making a request to data-service :: ", err)
		}
		defer res.Body.Close()
	
		body, err := io.ReadAll(res.Body)
		if err != nil {
			fmt.Println("Error in decoding the response from the API :: ", err)
			return err
		}
		fmt.Println("The response from the health-check endpoint is :: ", string(body))
	
		response:= fiber.Map{
			"success": success,
			"message": message,
			"data":    data,
		}
	
		return c.JSON(response)
	})

@lokesh411
Copy link
Author

This seems to be working well in echo http framework, would it be because gofiber is using the existing goroutines to serve HTTP calls?

@grcevski
Copy link
Contributor

Hi again, so that looks like a regular httpclient call, we should've been able to propagate the context. From the requests output we only see a call to /v1/traces, which makes me think you are not instrumenting the correct service, unless your service has the OTel SDK added and is also making those calls?

How do you select the Go process to be instrumented with Beyla? Do you use Open Port or Executable Name?

I would've expected that we see a trace for /test/golang and one for /hello. Even if we couldn't properly instrument gofiber, the client instrumentation would've caught the call to /hello.

@lokesh411
Copy link
Author

Yeah the service is also configured with OTel SDK so sends traces to collector,
I used the open port to instrument the Go process
Currently the client instrumentation doesn't propagate any incoming context to the external services (the code changes for that hasn't been done yet)

@grcevski
Copy link
Contributor

OK, thanks! I'll try to create a fiber testcase and see what happens.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants