otel metrics fix #2664
No reviewers
Labels
No labels
1week
2weeks
Failed compliance check
IP cameras
NATS
Possible security concern
Review effort 1/5
Review effort 2/5
Review effort 3/5
Review effort 4/5
Review effort 5/5
UI
aardvark
accessibility
amd64
api
arm64
auth
back-end
bgp
blog
bug
build
checkers
ci-cd
cleanup
cnpg
codex
core
dependencies
device-management
documentation
duplicate
dusk
ebpf
enhancement
eta 1d
eta 1hr
eta 3d
eta 3hr
feature
fieldsurvey
github_actions
go
good first issue
help wanted
invalid
javascript
k8s
log-collector
mapper
mtr
needs-triage
netflow
network-sweep
observability
oracle
otel
plug-in
proton
python
question
reddit
redhat
research
rperf
rperf-checker
rust
sdk
security
serviceradar-agent
serviceradar-agent-gateway
serviceradar-web
serviceradar-web-ng
siem
snmp
sysmon
topology
ubiquiti
wasm
wontfix
zen-engine
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
carverauto/serviceradar!2664
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "refs/pull/2664/head"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Imported from GitHub pull request.
Original GitHub pull request: #2284
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/pull/2284
Original created: 2026-01-14T05:14:06Z
Original updated: 2026-01-14T05:34:35Z
Original head: carverauto/serviceradar:chore/fix_otel_metrics_missing
Original base: staging
Original merged: 2026-01-14T05:34:33Z by @mfreeman451
User description
IMPORTANT: Please sign the Developer Certificate of Origin
Thank you for your contribution to ServiceRadar. Please note, when contributing, the developer must include
a DCO sign-off statement indicating the DCO acceptance in one commit message. Here
is an example DCO Signed-off-by line in a commit message:
Describe your changes
Issue ticket number and link
Code checklist before requesting a review
PR Type
Bug fix
Description
Add tenant schema support to OTEL metrics queries
Pass scope parameter to metrics query functions
Implement schema_for_scope helper for tenant resolution
Handle both tenant-aware and default schema queries
Diagram Walkthrough
File Walkthrough
index.ex
Add tenant schema support to analytics metricsweb-ng/lib/serviceradar_web_ng_web/live/analytics_live/index.ex
TenantSchemasalias for tenant schema resolutionget_hourly_metrics_stats/1to accept scope parameterschema_for_scope/1andsafe_schema_for_tenant/1helper functionsindex.ex
Add tenant schema support to log metrics queriesweb-ng/lib/serviceradar_web_ng_web/live/log_live/index.ex
TenantSchemasalias for tenant schema resolutionload_duration_stats_from_cagg/1to accept and use scopeparameter
load_sparklines/2to accept scope and pass to fetch functionfetch_sparklines/2to accept scope and build conditionalqueries with schema prefix
schema_for_scope/1andsafe_schema_for_tenant/1helper functionsImported GitHub PR comment.
Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/2284#issuecomment-3747796015
Original created: 2026-01-14T05:14:46Z
PR Compliance Guide 🔍
Below is a summary of compliance checks for this PR:
Cross-tenant data access
Description: Tenant-derived schema selection is driven by
scope(e.g.,%{tenant_id: tenant_id}/%{active_tenant: active_tenant}) and then used as an Ecto queryprefix(prefix: ^schema),which could enable cross-tenant data access if
scopecan be influenced by an untrustedclient or if
TenantSchemas.schema_for_tenant/1does not strictly validate/authorize thetenant-to-schema mapping (the same pattern also exists in
web-ng/lib/serviceradar_web_ng_web/live/log_live/index.exwhere schema is applied to bothotel_metrics_hourly_statsandotel_metricsqueries).index.ex [109-207]
Referred Code
🎫 No ticket provided
Codebase context is not defined
Follow the guide to enable codebase context checks.
Generic: Comprehensive Audit Trails
Objective: To create a detailed and reliable record of critical system actions for security analysis
and compliance.
Status: Passed
Generic: Meaningful Naming and Self-Documenting Code
Objective: Ensure all identifiers clearly express their purpose and intent, making code
self-documenting
Status: Passed
Generic: Secure Error Handling
Objective: To prevent the leakage of sensitive system information through error messages while
providing sufficient detail for internal debugging.
Status: Passed
Generic: Robust Error Handling and Edge Case Management
Objective: Ensure comprehensive error handling that provides meaningful context and graceful
degradation
Status:
Narrow rescue scope:
safe_schema_for_tenant/1rescues onlyArgumentError, so other exceptions fromTenantSchemas.schema_for_tenant/1could still crash the LiveView path instead of degradinggracefully.
Referred Code
Generic: Secure Logging Practices
Objective: To ensure logs are useful for debugging and auditing without exposing sensitive
information like PII, PHI, or cardholder data.
Status:
Exception details logged: Warning logs interpolate
inspect(e)which may include database/query details or tenantidentifiers depending on the exception, requiring verification that no sensitive data can
be emitted to logs.
Referred Code
Generic: Security-First Input Validation and Data Handling
Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent
vulnerabilities
Status:
Dynamic schema selection: The DB
prefixis derived fromscopetenant values viaTenantSchemas.schema_for_tenant/1,so verification is needed that
TenantSchemasstrictly validates/sanitizes tenant input andcannot be influenced to access unauthorized schemas.
Referred Code
Compliance status legend
🟢 - Fully Compliant🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label
Imported GitHub PR comment.
Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/2284#issuecomment-3747800053
Original created: 2026-01-14T05:15:52Z
PR Code Suggestions ✨
Explore these optional code suggestions:
✅
Refactor to eliminate widespread code duplicationSuggestion Impact:
The commit reduces some query duplication by removing the duplicated "no schema prefix" query branches and instead short-circuiting when schema is nil (logging a warning and returning a fallback value). However, it does not implement the core refactor: helpers were not centralized and composable prefixing was not introduced; in fact, a new helper (log_schema_warning_once/2) was duplicated across modules.code diff:
The PR duplicates helper functions for schema resolution and entire Ecto queries
across multiple modules. It is recommended to centralize the helper functions
and use Ecto's composable query features to apply the schema prefix
conditionally, thus avoiding code duplication.
Examples:
web-ng/lib/serviceradar_web_ng_web/live/analytics_live/index.ex [113-159]
web-ng/lib/serviceradar_web_ng_web/live/log_live/index.ex [1727-1743]
Solution Walkthrough:
Before:
After:
Suggestion importance[1-10]: 9
__
Why: The suggestion correctly identifies significant code duplication of both helper functions and entire Ecto queries, which is a major maintainability issue affecting all modified files.
✅
Prevent public schema queryingSuggestion Impact:
The commit removed the fallback query that ran without a schema prefix (public schema) and now short-circuits when schema is nil, logging a warning once and returning nil instead. This addresses the core security concern (no public schema querying), though it does not return a zeroed stats map as suggested.code diff:
To prevent potential data leaks, avoid querying the public schema when a tenant
schema is not found. Instead, return a zeroed stats map directly.
web-ng/lib/serviceradar_web_ng_web/live/analytics_live/index.ex [111-159]
[To ensure code accuracy, apply this suggestion manually]Suggestion importance[1-10]: 9
__
Why: This suggestion correctly identifies a potential security vulnerability where failing to find a tenant schema results in querying the public schema, which could lead to cross-tenant data leaks.