>I was at first implementing otel throughout my api, but ran into some minor headaches and a lot of boilerplate
OTeL also has numerous integrations https://opentelemetry.io/ecosystem/registry/. In contrast, Sentry lacks traditional metrics and other capabilities that OTeL offers. IIRC, Sentry experimented with "DDM" (Delightful Developer Metrics), but this feature was deprecated and removed while still in alpha/beta.
Sentry excels at error tracking and provides excellent browser integration. This might be sufficient for your needs, but if you're looking for the comprehensive observability features that OpenTelemetry provides, you'd likely need a full observability platform.
SigNoz also follows a similar approach since the attributes can be arbitrary, and ClickHouse needs a fixed schema ahead. The options are map, parried arrays etc.. but they all are slow depending on the object unpacking ClickHouse needs to do. ClickHouse does its best on the regular columns as it's built for it. If the access is on Map/Array types, it is faster than other DB systems but slower than regular columns.
OTeL also has numerous integrations https://opentelemetry.io/ecosystem/registry/. In contrast, Sentry lacks traditional metrics and other capabilities that OTeL offers. IIRC, Sentry experimented with "DDM" (Delightful Developer Metrics), but this feature was deprecated and removed while still in alpha/beta.
Sentry excels at error tracking and provides excellent browser integration. This might be sufficient for your needs, but if you're looking for the comprehensive observability features that OpenTelemetry provides, you'd likely need a full observability platform.