I've made some progress, but I haven't been able t...
# support
h
I've made some progress, but I haven't been able to resolve all the issues yet. Using the latest
opentelemetry-ruby
code I can use the following to get metrics into clickhouse (using the otel collector)
Copy code
otlp_metric_exporter = OpenTelemetry::Exporter::OTLP::MetricsExporter.new
OpenTelemetry.meter_provider.add_metric_reader(otlp_metric_exporter)
meter = OpenTelemetry.meter_provider.meter("test-rails")
counter = meter.create_counter("active_sessions_9", description: "Active Sessions", unit: "1")
counter.add(SecureRandom.random_number(10))
OpenTelemetry.meter_provider.metric_readers.each(&:pull)
I also have the node example app running and recording metrics with that. When I look at the data in clickhouse:
Copy code
select * from signoz_metrics.time_series_v2 tsv where tsv.metric_name in ('requests_count', 'active_sessions_9');
I see the following for the node app:
Copy code
{
  "__name__": "requests_count",
  "__temporality__": "Cumulative",
  "service_name": "unknown_service:node",
  "telemetry_sdk_language": "nodejs",
  "telemetry_sdk_name": "opentelemetry",
  "telemetry_sdk_version": "1.0.1"
}
And the following for the ruby code:
Copy code
{
  "__name__": "active_sessions_9",
  "__temporality__": "Delta",
  "process_command": "bin/rails",
  "process_pid": "1477990",
  "process_runtime_description": "ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]",
  "process_runtime_name": "ruby",
  "process_runtime_version": "3.2.2",
  "service_name": "test-rails",
  "telemetry_sdk_language": "ruby",
  "telemetry_sdk_name": "opentelemetry",
  "telemetry_sdk_version": "1.4.0"
}
I can also see the key
active_sessions_9
in the query builder when adding a graph. However I always end up with no data. Is there a simple fix for this? or does this come down to the temporality? or am I looking in the wrong place?
s
Since you are using the delta, you either need to pass the flag
--prefer-delta=true
for query-service or just upgrade to the latest version which does it automatically.
h
That seems to have changed something, but I still don't get any real values/graph points:
s
This is a bug. Please toggle the active sessions and see what is shows.
h
ah, kewl! Thanks a lot!
on to the next question regarding graphing 🙂 Is there a better way to get the actual values rather than using
hist_quantile_50
? The actual values are:
78, 138, 84, 40, 176, 166, 0, 168, 150, 173, 7, 186
They are sent 60 seconds apart (testing atm)
s
Sorry, I didn't understand what you mean by actual values.
h
by looking at the graph between 8:21 - 8:23 the line is flat at around ~175. However, the actual values during that time is 168, 150 & 173. Is it possible to actually map those values on the graph?
s
When you say actual values, did you mean the value recorded by your program?
h
that's correct
s
No, we can't show the raw measurements. The record values in histograms are grouped into buckets. Even though they are 168, 150, & 173. They all would be grouped under some buck like 128-256 or something similar. So we would never know the original values but only the distribution values. If you need raw measurements, then the Histogram metric is not the right choice. You probably want to choose structured log records. Please keep in mind that it's trade-off b/w storage& speed and approximation of results
The grouping happens at your application layer
h
so if I want actual values, I'd need to use something like a counter?
s
No, none of the metrics will give you the actual values. By nature, they are aggregate data and do not contain the original values. If you need the actual values, they must be sent as individual events and structured logs with OTEL is one way to do it.
h
thanks a lot @Srikanth Chekuri