Conversation
lovasoa
commented
Mar 14, 2026
- feat(telemetry): initialize OpenTelemetry metrics provider
- feat(metrics): implement and integrate HTTP request duration metrics
- feat(metrics): instrument database query durations
- refactor(database): add OTel name mapping helper
- feat(metrics): instrument database connection pool
- feat(telemetry): update OTel collector to receive OTLP metrics
- feat(telemetry): add metrics panels to Grafana dashboard
…eusing discovery logic
…y to pool callbacks
…avor of constants
…fig to fix parsing error
…e latency measurement
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9fe421d0bc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let route = req | ||
| .match_pattern() | ||
| .unwrap_or_else(|| req.path().to_string()); |
There was a problem hiding this comment.
Use bounded HTTP route labels in request-duration metric
Falling back to req.path() here makes http.server.request.duration cardinality depend on raw URL paths, so each distinct path creates a separate time series. Because SQLPage serves most requests through default_service (src/webserver/http.rs), match_pattern() can be absent and this fallback will emit unbounded labels from normal dynamic URLs and random-path probes, which can quickly overload OTEL/Prometheus storage and degrade dashboards.
Useful? React with 👍 / 👎.
| opentelemetry::KeyValue::new(otel::DB_SYSTEM_NAME, self.db_system_name), | ||
| opentelemetry::KeyValue::new(otel::DB_OPERATION_NAME, self.operation_name.clone()), | ||
| opentelemetry::KeyValue::new(otel::OTEL_STATUS_CODE, "ERROR"), | ||
| opentelemetry::KeyValue::new(otel::ERROR_TYPE, error.to_string()), |
There was a problem hiding this comment.
Keep db error_type metric labels low-cardinality
Recording error.to_string() as error.type makes metric labels include full error messages, and these messages can contain query-specific SQL/context from database failures. That creates high-cardinality db.client.operation.duration error series (often one label per failing query/input), which hurts metrics backend performance; this attribute should use a stable error class instead of the full message text.
Useful? React with 👍 / 👎.