Hi team, for the `troubleshooting` script, is it o...
# support
p
Hi team, for the
troubleshooting
script, is it only binded to port 4317? seems when we run
./troubleshoot checkEndpoint --endpoint <http://ourloadbalancer-name.elb.us-east-1.amazonaws.com:4317|ourloadbalancer-name.elb.us-east-1.amazonaws.com:4317>
it comes back fine but when appended with port
4318
it fails even though the lb is set to accept both and service is listening on both ports in cluster. Seems the troubleshooting script is only testing the grpc port and not htttp? Can someone confirm this?
Ok I was able confirm that the
troubleshooting
tool is set to only test
grpc
and NOT
http
Looking at the commit here https://github.com/SigNoz/troubleshoot/blob/main/checkEndpoint/checkEndpoint.go one can see it’s set to only spit out a grpc troubleshooter.
Copy code
package checkEndpoint

import (
	"context"
	"fmt"
	"time"

	"<http://github.com/spf13/cobra|github.com/spf13/cobra>"
	"<http://go.opentelemetry.io/otel/exporters/otlp/otlptrace|go.opentelemetry.io/otel/exporters/otlp/otlptrace>"
	"<http://go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc|go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc>"
	"<http://go.opentelemetry.io/otel/sdk/trace/tracetest|go.opentelemetry.io/otel/sdk/trace/tracetest>"
	"<http://go.uber.org/zap|go.uber.org/zap>"
)
I was able to modify the
checkEndpoint.go
for my needs to test port 4318 successfully. I think it would make sense to have the option of testing both ports via this tool. Is this something the team would want a PR for or not worth it? Thanks!
a
a PR would be welcomed @Pocho POV