One platform, full coverage
From performance monitoring to security audit, AI-powered root cause to enterprise alert delivery — every engine-agnostic capability of SentinelDB360 in one place.
From performance monitoring to security audit, AI-powered root cause to enterprise alert delivery — every engine-agnostic capability of SentinelDB360 in one place.
TOP-N analysis from each engine's native query store (Query Store, pg_stat_statements, performance_schema, currentOp); ranking by CPU, reads, execution count and duration.
XML/JSON plan inspection, plan cache top consumers, regression detection, forced plan management (force/unforce). Query Store integration for SQL Server.
Wait stat categorization (CPU, I/O, lock, network), per-session wait stats, query memory grants and hourly wait trend charts.
Missing index suggestions (impact score), duplicate index detection, fragmentation analysis, online rebuild action, fill factor analysis.
File I/O latency (read/write ms), virtual file stats delta, disk volume usage, database file growth history, autogrow event tracking.
Active queries, sessions, blocking status, kill SPID action (system SPID protection), session input buffer and real-time WebSocket updates.
Tree of mutually waiting sessions visualized with React Flow. Path to lead session, lock type, wait time shown on each node. Sankey and list views.
SQL Server deadlock_history XE event, MySQL InnoDB deadlock log, MongoDB lock conflict — engine-specific evidence collected and presented in a normalized history.
Transactions exceeding the threshold (default 5 min) detected; locked resources, log space consumption and session detail provided in context.
One-click kill SPID, force/unforce plan, recompile procedure, update statistics, shrink log file from the UI. Audit log + confirmation dialog required.
Availability Group status, replica role, sync mode, lag KB/sec, log send queue, redo queue, AG endpoint health, listener TCP, read-only routing.
pg_stat_replication, replication slots, WAL archiver status, logical replication subscribers. Tracking archive lag and WAL bytes accumulating in slots.
Group replication members and status, replication channels, IO/SQL thread status, seconds behind master, GTID set drift.
Replica set status, oplog window, member health, election timeout, sharding balancer status, chunk distribution, mongos round-robin.
Backup history, full/diff/log chain validation, log shipping status, critical lag alarm (>1 hour). Recovery model changes are logged.
Windows Server Failover Cluster nodes, quorum type and vote status, witness disk/share/cloud health, dynamic quorum decisions.
Engine-specific CIS-style security checks: weak passwords, sysadmin sprawl, public role grants, sa account status, default ports, is audit enabled?
Transparent Data Encryption status, certificate expiry early warning, Always Encrypted column list, Dynamic Data Masking, Row Level Security coverage table.
SQL Server Audit, PostgreSQL pgAudit, MySQL audit log, MongoDB audit. Plus SQL 2022+ Ledger table verification and immutable log review.
User / role / login permissions, orphan user detection, excessive sysadmin alert, login lockout policy, password expiry configuration.
Active XE sessions, target types, ring buffer status and XE overhead alert (high event rate). Crypto provider list, AG routing.
Coverage analysis of PostgreSQL RLS policies: which tables are enabled, FORCE RLS tables, are public-role policies present?
Switch between Azure OpenAI (gpt-4o-mini default) and local Ollama with a single configuration, thanks to the LiteLLM abstraction layer. Platform-wide preference via AI_DEFAULT_PROVIDER.
With AI_LANG=tr, responses come in Turkish. DBA terminology, engine-specific references and evidence-based explanations; written, not translated.
Plan change (regression), parameter sniffing, missing statistics, missing index, tempdb contention, parallelism (CXPACKET), capacity forecasting — contextual interpretation.
In local AI (Ollama) mode no data leaves the organization. AI features fully work in air-gapped environments; query text is processed within the organization's network.
On demo.sentineldb360.com, every engine is shown concretely — lock chains, replication topology, KVKK inventory, playbook library, executive KPIs. In production the same structure runs on the organization's own data.
Sentinel generates engine-specific recommendations with Azure OpenAI or local Ollama: summary + 3–4-step action plan + confidence + estimated impact + estimated effort. The demo has 80+ sample recommendations (20 per engine).
AI_LANG)12 production-grade procedures: AG drift, frozen XID wraparound, metadata lock pt-osc, oplog flood, brute-force IP block, disk emergency, SSL renewal. Each playbook includes trigger + diagnostic + remediation + verification + rollback.
Actionable recommendations Sentinel analyzed in the last 15 minutes. For each: action SQL + rollback command + estimated impact + "one-click apply" status. Together with a confidence score.
4 production-grade incident scenarios — minute-by-minute event history. Alert → page → diagnose → playbook → resolve. With MTTR, MTTA, root cause, lessons learned and impact estimate.
12 KPIs × 90-day trend (uptime, MTTR, MTBF, P1 incidents, cost per query, compliance score, backup success, DR drill, DBA productivity). Quarterly board narrative + metrics-vs-targets table.
The demo has 4 sample multi-turn dialogues: DBA + junior DBA + compliance officer + SRE. Question → AI answer → applied action → audit trail. Gets a junior DBA going on their own.
Transparency note: the items above are shown with data in the live demo environment. In a production deployment, AI recommendations and real-time recommendations are generated automatically; the playbook and incident history build up over the organization's real usage. Automatic playbook execution is opt-in (destructive actions require DBA approval).
We delivered competitors' visible features on Sentinel's agentless framework — without installing an agent or touching the organization's DB server. Backed by 126 unit tests (108 backend + 18 frontend).
Transparency note: anomaly detection is a NumPy MAD 3σ statistical baseline — not an ML model (DataDog Watchdog LSTM/ARIMA). The widget library has 16 types; it is a subset of the Grafana plugin marketplace. Detailed comparison: comparison page.
Organize dashboards into a folder hierarchy (max 3 levels, cycle check), with team-level viewer/editor/admin permissions. Automatic version history after every save → diff + rollback. Grafana parity S4+S5.
Mute the alert pipeline during one-time or recurring (daily / weekdays / weekly + midnight crossing) maintenance windows. Per-alert 1h / 6h / 24h / 7d quick mute. RedGate parity.
De-dup (15-min hash) + frequency cap (flood guard of 10 alerts/source per 60s) + parent/child correlation (high CPU → slow query matching) + cascade snooze. RedGate noise-reduction parity.
Config-as-code: export a dashboard as JSON, import into another organization — bulk transfer (max 50 layouts), schema version control, source_id substitution map. Grafana provisioning parity.
MSSQL plan_history parity has come to PostgreSQL + MySQL. pg_stat_statements + EXPLAIN JSON parse → written to the execution_plans + plan_history collections. Same query, different plan → regression flag. Provider depth.
Users write SELECT / WITH / EXPLAIN / SHOW — server-side regex+whitelist enforcement, 30s timeout, 1000-row cap, audit log. DML/DDL 403 reject. Grafana Explore parity (S8).
A client-side pipeline on widget data: filter / rename / groupBy + aggregate / sort / calculate / join / reduce. Drag-drop ordering, preview at each step. The backend is untouched. Grafana Transform parity (S10).
Share a snapshot of a dashboard via token + QR code, with an optional IP allowlist, without logging in. 15min / 1h / 24h / 7d expiry. Read-only, audited.
Hour-of-day MAD 3-sigma residual. High CPU at Monday 09:00 is "expected", Monday 03:00 is an anomaly. Expected-band shading + anomaly dots on Recharts. NumPy-only, not ML.
3 roles (admin/editor/viewer) → 19-scope matrix. Custom grant/deny patch. Folder permission inheritance. DataDog RBAC parity.
/api/v2/rbac/scopesSave a widget config as a "Library Panel" → reference it across multiple dashboards. Edit the original → it updates in all references. Grafana parity (S6).
Hamburger menu + overlay drawer + backdrop for iPhone / Android viewports. Granular useMediaQuery breakpoint hooks. Per-page CSS sweep in a follow-up sprint.
Agentless mandate preserved: all 13 sprints work over Sentinel's existing read-only DB connections. We do not install any agent / binary on the target DB server. In government / defense / healthcare (KVKK + air-gap) environments this architectural decision is decisive.
Repeating alerts for the same root cause are merged into a single event via SHA-256 hash; one "ongoing incident" stream instead of spam.
Instance-level thresholds for 9+ fields including CPU, memory, disk, blocking, connections. Personal override layer over platform defaults.
Suppress alarm generation during patches. Cron patterns, per-engine selection, custom maintenance windows per alert type.
Email via SMTP (mail_service.py), JSON push to Slack / Teams / PagerDuty / custom services via Webhook integration. Per-channel template customization.
Failed login spike, log shipping lag critical, excessive sysadmin, XE session high overhead, replication lag, disk threshold, CPU/memory critical, blocking warning.
All operational actions like alarm trigger, threshold change, kill SPID, plan force are stored in audit_logs collection; who, when, what?
Fully async with FastAPI + Motor (async MongoDB driver). Data collection and serving are decoupled; collector / ingestor / advisor scale independently.
Data flow:
Frontend requests go to the Backend → the Collector pulls from target DBs with async drivers (pymssql · asyncpg · aiomysql · motor) pulls metrics → Ingestor writes to MongoDB → Advisor produces AI commentary.
No installation on target servers. Only DB credentials are required.
FastAPI + Motor. The event loop never blocks — high concurrency.
TTL cache + timeout + graceful degradation banner support large inventories.
Prometheus metrics, deep /healthz, X-Request-ID + log correlation.
SentinelDB360 exposes its own health to the outside world — Prometheus metric endpoint, subsystem-level readiness, request correlation IDs. Your SRE team can monitor the tool itself from Grafana.
Runtime metrics exposed via prometheus_client 0.25 — HTTP request count, latency histogram, active WebSocket connections, process cpu/memory, custom counters.
A shallow ping isn't enough for Kubernetes / docker healthchecks. /healthz tests four subsystems individually: MongoDB ping, provider factory, license signature, mail handler. If any fails, it returns 503.
Every HTTP request gets a unique ID at the middleware layer; it is injected into every log line via ContextVar. You can grep a single user complaint ("I got an error when I clicked this button") end-to-end.
ERROR / CRITICAL log levels are automatically converted to email — stack trace + context to [email protected]. SHA-256 fingerprint with 15-minute dedup; you don't get flooded by the same error. Can be disabled via opt-out env.
Time-series projections for storage growth, connection trend, CPU and memory utilization. 95% prediction interval with z-score 1.96. Backs answers like "the disk fills in 73 days, plan +200GB" with data.
Every endpoint that takes {source_id} goes through a dependency-injected tenant check (verify_source_ownership). Users cannot query sources they do not own; admin overrides are written to audit_logs.
Comprehensive health-check score per engine (A: 90+, B: 75+, C: 60+, D: 40+, F: <40). A single-letter report card you can hand to management; every check is visible underneath.
DMS report aggregation — performance score trend, top issues, open findings. Tenant-filtered, builds an executive summary screen with a single API call.
Connect to SentinelDB360 hosted on DMC infrastructure within seconds. Automatic updates, backups and scaling.
Deploy via Docker Compose + Azure Container Registry on your own servers within minutes. Air-gapped network compatible.
In a 30-minute demo session, let's discuss your team's specific needs.