This message was deleted.

This message was deleted.

This message was deleted.

I am trying to send data from my cluster via otel agent to signoz otel collector on grpc I am seeing error in my source. My source is a default grpc otlp exporter

info	exporterhelper/queued_retry.go:423	Exporting failed. Will retry the request after interval.	{"kind": "exporter", "data_type": "logs", "name": "otlp", "error": "rpc error: code = Unavailable desc = upstream connect error or disconnect/reset before headers. reset reason: connection termination", "interval": "32.243501486s"}

and signoz Otel collector (default grpc otlp receiver ) is throwing error as:

info	zapgrpc/zapgrpc.go:178	[transport] [server-transport 0xc000ad0b60] Closing: connection error: desc = "transport: http2Server.HandleStreams received bogus greeting from client: \"POST /opentelemetry.prot\""	{"grpc_log": true}

Has anyone else faced this error?

This message was deleted.

This message was deleted.

This message was deleted.

Hello. Does anyone has a solution about that issue. API responded with 500 - Something went wrong status: error in builder queries. When I try to monitor something i got the following error on all graphs. Only Latency graph is working properly.

Hey - weird one, ref upgrades - if we're upgrading manually - can you confirm how schema evolution should work for clickhouse? Currently our process is to find your new tagged release, like 0.54.0 - identify any containers that have changed - i.e. collector, query service, migration service, ui service etc. Run a script to cache those containers locally in ECR. We then run the migration container, then redeploy the other containers using that image. It's all worked perfectly, until today.

2024-09-12T17:00:59.545Z info exporterhelper/retry_sender.go:118 Exporting failed. Will retry the request after interval. {"kind": "exporter", "data_type": "logs", "name": "clickhouselogsexporter", "error": "StatementSend:code: 10, message: Not found column attributes_bool.keys in block. There are only columns: ts_bucket_start, resource_fingerprint, timestamp, observed_timestamp, id, trace_id, span_id, trace_flags, severity_text, severity_number, body, attributes_string, attributes_number, attributes_bool, resources_string, scope_name, scope_version, scope_string: while pushing to view signoz_logs.attribute_keys_bool_final_mv (211bdbc2-196d-43ad-9f49-a31b13627556)", "interval": "3.047923669s"}

I presumed the migration service handled all that for us

for log pipelines, why do grok capture groups need to have a

p

before them? e.g.

%{YEAR}-%{MONTHNUM}-%{MONTHDAY} %{TIME} %{LOGLEVEL:level} %{NUMBER} --- \[.*\] (?P<method>.*) :

works, but

%{YEAR}-%{MONTHNUM}-%{MONTHDAY} %{TIME} %{LOGLEVEL:level} %{NUMBER} --- \[.*\] (?<method>.*) :

doesn't. Grok debugger only accepts the second syntax, so I'm curious why the first syntax is used in Signoz.