https://signoz.io
Join Slack
This message was deleted.
# general
s
This message was deleted.
s
You will probably have to enable unencrypted client something like this https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/examples/Console/TestOtlpExporter.cs#L61
b
hmmm. that didn't seem to have any effect. I note, too, that the console exporter doesn't show anything. Should I not be expecting the raw requests to show up in the telemetry?
s
If you are not seeing anything in the console exporter as well then there is an issue with pipeline setup.
b
ok... but there's nothing different here than the backend microservices, which are correctly sending their telemetry
from the collector logs:
Copy code
2022-07-21T13:19:39.262Z	error	clickhousetracesexporter/writer.go:101	Could not write a batch of spans	{"kind": "exporter", "name": "clickhousetraces", "error": "clickhouse: dateTime overflow. timestamp must be between 1925-01-01 00:00:00 and 2283-11-11 00:00:00"}
<http://github.com/open-telemetry/opentelemetry-collector-contrib/exporter/clickhousetracesexporter.(*SpanWriter).backgroundWriter|github.com/open-telemetry/opentelemetry-collector-contrib/exporter/clickhousetracesexporter.(*SpanWriter).backgroundWriter>
	/src/exporter/clickhousetracesexporter/writer.go:101
s
That's strange. Can you get the console exporter working? How does the data look like for values using that?
b
do you know how I can capture the data going to the collector?
I have tried purging the volume to see if there's just something weird stuck in the queue
s
I am aware of such hooks. If you want to see the data I think the best option is to use console exporter.
b
ok
but it never showed the spans it was trying to send...
when I purged the volumes, the error went away, but the data is still not showing up in either exporter
can I attach all logs here for someone to look at?
s
I want to understand if the issue with the collector or your app instrumented with SDK. First step is to verify application produces telemetry with console exporter.
b
yeah, I can understand that
but it should be working out of the box with the C# DI code I posted, shouldn't it?
s
i don't remember the exact setting but otel dotnet sdk has setting to enable to diagnostic logging,, did you try that
b
I will see if I can find how to do that
Copy code
otel-collector_1          | Error: cannot build exporters: error creating clickhousetraces exporter: error connecting to primary db: dial tcp: lookup clickhouse on 127.0.0.11:53: no such host
otel-collector_1          | 2022/07/21 17:14:38 collector server run finished with error: cannot build exporters: error creating clickhousetraces exporter: error connecting to primary db: dial tcp: lookup clickhouse on 127.0.0.11:53: no such host
hmmm that looks like a good place to start
s
How are you deploying the signoz?
b
as per the docs: 
docker-compose -f docker/clickhouse-setup/docker-compose.yaml
I modified the compose to use an external network, but that's it
s
It's unable to connect to clickhouse db
b
btw, the hostname lookup error was just a typo on my part. I've fixed it and I'm back to square one. no errors but no console export either.
dumb question maybe, but .NET 6 is supported?
s
Yes
b
ok it is showing in the console log now. It looks like 
AddRedisInstrumentation()
was throwing an exception. Removing it has logged the activities to the console.
but it is still not making it to the collector
I have tried both Jaeger and Signoz collectors, and Signoz using both HttpProtobuf and gRPC (and the appropriate port)
I can see no sign that any attempt is being made to send the data...
s
Can you share the endpoint you are setting?
b
sorry, I don't quite understand
you mean the value of Telemetry:CollectorUrl?
I have been using http://otel-collector:4317 (for gRPC) or :4318 (for HttpProtobuf)
I've connected to the web api and verified that otel-collector resolves correctly
s
Where is you testing app running? Wouldn't the url be 
<http://localhost:4317>
or 
<http://localhost:4318>
?
b
no, it is running in docker container
and collector is running in a different container on same network
s
So you are seeing the spans on console but not when you OTLP exporter?
b
that's correct
but I guess that's not a Signoz problem
s
Yes, can you run a very basic app locally and send data at 
<http://localhost:4317>
and see if it is successful?
b
I'm sure it does
however, I think I've taken up enough of your time
s
Haha It's hard to debug remotely. I suspect there is something wrong with OTLP setup in the app.
b
well, as I have said, I am using the exact same setup in the worker service as the web api, and the worker service logs traces and the web api does not
but, it is an OLTP issue and I won't bother you with it any further. I only avoid making a "test" application on localhost because it proves nothing and doesn't really enlighten me as to the cause
I was only looking for some insight as to what might be wrong with the DI declaration (solved), but now we end up with a different problem. As you say, you cannot debug remotely.
26 Views
Open in Slack
PreviousNext
Powered by

SigNoz Community

SigNoz is an open-source APM. It helps developers monitor their applications & troubleshoot problems, an open-source alternative to DataDog, NewRelic, etc.

Powered by