| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
- Added getMetricByLabels() helper for multi-label metric queries
- Split 'Authorized' metric into:
- Auth Writes: requests_total{method=EVENT, status=authorized}
- Auth Reads: requests_total{method=REQ, status=authorized}
- Provides clearer visibility into authenticated read vs write operations
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add 'authorized' status for requests that complete successfully after
authentication. This complements the existing 'unauthenticated' (pre-auth)
status tracking.
Now the dashboard shows:
- Authorized: Authenticated requests that succeeded
- Unauthorized: Authenticated requests rejected (not in allowlist)
- Pre-Auth: Requests sent before authentication
This gives full visibility into the auth flow:
1. Challenges: How many clients authenticated
2. Authorized: How many authenticated requests succeeded
3. Unauthorized: How many were rejected despite valid auth
4. Pre-Auth: How many tried before authenticating
Updated metrics:
- requests_total{status="authorized"} - authenticated successes
- requests_total{status="ok"} - unauthenticated successes (when no auth)
|
| |
|
|
|
|
|
|
|
|
| |
Updated metrics dashboard to show:
- Unauthorized: Requests rejected due to pubkey not in allowlist
- Pre-Auth: Requests sent before authentication completed
- Challenges: Successful AUTH challenge completions
This surfaces the new 'unauthorized' and 'unauthenticated' request
status metrics on the dashboard for easier monitoring of auth issues.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Track and display blocked event counts with per-kind breakdown.
- Add events_blocked_total counter with kind label
- Add RecordBlockedEvent method to metrics
- Display blocked count in dashboard Storage section
- Call metric when rejecting non-core protocol kinds
Allows monitoring spam patterns and verifying kind filter effectiveness.
Raw metrics show breakdown by kind (e.g., kind=20001, kind=30311).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Transform metrics dashboard from dark modern theme to classic beige
theme matching the index page.
Changes:
- Background: dark (#0a0a0a) → beige (#f5f0e8)
- Font: sans-serif → Courier New (monospace)
- Colors: vibrant gradients → simple black/brown
- Cards: dark (#1a1a1a) → white with black borders
- Layout: max-width 1200px → 960px (matches index)
- Typography: modern sizing → classic smaller fonts
- Logo: Add muxstr SVG logo matching index page
- Dividers: Add horizontal rules for section breaks
- Status badge: Green gradient → orange/brown (#c97556)
- Removed: Color coding (success/error/warning classes)
Result: Clean, classic, brutalist aesthetic consistent with index page.
The dashboard now feels like part of the same relay, not a separate app.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Track and display storage and performance metrics that were previously
showing zeros.
Storage metrics:
- Add GetStats() method to storage returning event count and DB size
- Store database file path for size calculation
- Update metrics every 30 seconds via goroutine in main.go
- Display event count and DB size (MB) in dashboard
Performance metrics:
- Calculate average latency from histogram sum/count metrics
- Display as milliseconds in dashboard
- Formula: (duration_sum / duration_count) * 1000
Missing metrics (deferred):
- Connections: requires connection lifecycle tracking (gRPC + WebSocket)
- Deletions: count would need API change to ProcessDeletion
Dashboard now shows accurate storage stats and request latency!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug: Dashboard showed zeros because it detected "go" as the prefix instead
of "muxstr" when Go runtime metrics appeared first in the metrics list.
Fix: Search for the first metric containing "_relay_" to properly detect
the namespace (muxstr, nostr-grpc, etc.) instead of using the first metric
in the alphabetical list.
Before: Object.keys(metrics)[0] → "go_gc_..." → prefix = "go"
After: Find metric with "_relay_" → "muxstr_relay_..." → prefix = "muxstr"
This fixes the dashboard displaying zeros when metrics data is present.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two critical fixes for metrics:
1. Fix interceptor chaining
- Changed from mixed grpc.UnaryInterceptor/ChainUnaryInterceptor to
proper chaining with grpc.ChainUnaryInterceptor
- Metrics interceptor now runs first (as intended)
- All interceptors properly chained in order: metrics → auth → ratelimit
- This fixes metrics not being recorded for any requests
2. Fix dashboard uptime calculation
- Changed from page load time to process_start_time_seconds metric
- Uptime now persists correctly across page refreshes
- Uses Prometheus standard process_start_time_seconds gauge
Before: Metrics showed 0 for all requests, uptime reset on refresh
After: Metrics properly record all gRPC requests, uptime shows actual relay uptime
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move metrics dashboard and Prometheus endpoint to the main HTTP server
for simplified deployment and single ingress configuration.
Changes:
- Add PrometheusHandler() and DashboardHandler() methods to Metrics
- Serve /dashboard on main HTTP port (was root on separate port)
- Serve /metrics on main HTTP port (was /metrics on separate port)
- Remove separate metrics server goroutine
- Update logging to show metrics paths on main HTTP port
Benefits:
- Single port/ingress needed for all HTTP traffic
- Simpler reverse proxy configuration
- Dashboard accessible alongside main relay endpoints
Endpoints on port 8080:
- / - WebSocket/index
- /nostr.v1.NostrRelay/* - Connect (gRPC-Web)
- /dashboard - Metrics dashboard (HTML)
- /metrics - Prometheus metrics (text)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a real-time metrics dashboard accessible at the metrics server root.
The dashboard displays relay statistics in a human-readable format with
auto-refresh every 5 seconds.
Features:
- Active connections and subscriptions
- Request counts (total, success, errors)
- Authentication stats (success/failure)
- Rate limiting hits
- Storage metrics (events, DB size, deletions)
- Clean, dark-themed UI with gradient accents
- Auto-refresh and live uptime counter
The dashboard is embedded using go:embed and served at / while
Prometheus metrics continue to be available at /metrics.
Example: http://localhost:9090/ for dashboard
http://localhost:9090/metrics for raw metrics
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for loading configuration from YAML file via -config flag.
Wire up auth, rate limiting, and metrics interceptors based on config.
Changes:
- Add -config flag to relay command
- Use config types directly in auth package (AuthOperationConfig)
- Add conversion methods: RateLimitConfig.ToRateLimiter(), MetricsConfig.ToMetrics()
- Add Metrics.Serve() method for prometheus HTTP endpoint
- Update main.go to initialize interceptors from config
- Fix type naming: OperationAuthConfig -> AuthOperationConfig for consistency
Config now supports complete relay setup including auth read/write
allowlists, rate limiting, and prometheus metrics.
|
|
|
## Metrics Package
Comprehensive Prometheus metrics for production observability:
Metrics tracked:
- Request rate, latency, size per method (histograms)
- Active connections and subscriptions (gauges)
- Auth success/failure rates (counters)
- Rate limit hits (counters)
- Storage stats (event count, DB size)
- Standard Go runtime metrics
Features:
- Automatic gRPC instrumentation via interceptors
- Low overhead (~300-500ns per request)
- Standard Prometheus client
- HTTP /metrics endpoint
- Grafana dashboard examples
## Config Package
YAML configuration file support with environment overrides:
Configuration sections:
- Server (addresses, timeouts, public URL)
- Database (path, connections, lifetime)
- Auth (enabled, required, timestamp window, allowed pubkeys)
- Rate limiting (per-method and per-user limits)
- Metrics (endpoint, namespace)
- Logging (level, format, output)
- Storage (compaction, retention)
Features:
- YAML file loading
- Environment variable overrides (MUXSTR_<SECTION>_<KEY>)
- Sensible defaults
- Validation on load
- Duration and list parsing
- Save/export configuration
Both packages include comprehensive README with examples, best
practices, and usage patterns. Config tests verify YAML parsing,
env overrides, validation, and round-trip serialization.
|
