आधुनिक उत्पादन डेटाबेस प्रति मिनट लाखों मेट्रिक्स उत्पन्न करते हैं - क्वेरी विलंबता, लॉक विवाद, प्रतिकृति अंतराल, बफर पूल हिट अनुपात और कनेक्शन पूल थकावट। पारंपरिक सीमा-आधारित चेतावनी टीमों को झूठी सकारात्मकता में डुबो देती है, जबकि विनाशकारी विफलताओं से पहले होने वाले सूक्ष्म गिरावट पैटर्न को गायब कर देती है। एआई और मशीन लर्निंग सामान्य व्यवहार को सीखकर, विसंगतियों को कैस्केड करने से पहले उनका पता लगाकर, प्रश्नों को स्वचालित रूप से अनुकूलित करके और मानवीय हस्तक्षेप के बिना उपचार निष्पादित करके इस समीकरण को मौलिक रूप से बदल देते हैं। यह मार्गदर्शिका MySQL, PostgreSQL, MongoDB, Redis और Couchbase में AI-संचालित डेटाबेस समस्या निवारण के संपूर्ण स्पेक्ट्रम को कवर करती है।
एआई डेटाबेस मॉनिटरिंग पाइपलाइन
विशिष्ट तकनीकों में गोता लगाने से पहले, एआई-संचालित डेटाबेस निगरानी प्रणाली की एंड-टू-एंड आर्किटेक्चर को समझना महत्वपूर्ण है। पाइपलाइन प्रत्येक डेटाबेस इंजन से कच्चे मेट्रिक्स एकत्र करती है, उन्हें समय-श्रृंखला डेटाबेस में संग्रहीत करती है, उन्हें विसंगति का पता लगाने के लिए एमएल मॉडल के माध्यम से फ़ीड करती है, एक बुद्धिमान चेतावनी प्रबंधक के माध्यम से अलर्ट रूट करती है, और आत्मविश्वास सीमा पूरी होने पर ऑटो-रेमेडिएशन क्रियाओं को ट्रिगर करती है।
डेटाबेस निगरानी और अवलोकन के लिए एआई/एमएल
पारंपरिक डेटाबेस मॉनिटरिंग स्थिर थ्रेसहोल्ड पर निर्भर करती है: जब CPU 80 प्रतिशत से अधिक हो जाता है, जब क्वेरी विलंबता 500 मिलीसेकंड से अधिक हो जाती है, या जब कनेक्शन गिनती 200 से अधिक हो जाती है तो अलर्ट। यह दृष्टिकोण गतिशील उत्पादन वातावरण में विनाशकारी रूप से विफल हो जाता है जहां सामान्य दिन के समय, सप्ताह के दिन, मौसमी पैटर्न और तैनाती घटनाओं के अनुसार बदलता रहता है। एआई-संचालित अवलोकनशीलता इन कठोर सीमाओं को सीखी गई आधार रेखाओं से बदल देती है जो लगातार अनुकूलित होती हैं।
सही मेट्रिक्स एकत्रित करना
किसी भी एआई निगरानी प्रणाली की नींव व्यापक मीट्रिक संग्रह है। प्रत्येक डेटाबेस इंजन अद्वितीय मैट्रिक्स को उजागर करता है जो प्रदर्शन के लिए मायने रखता है:
# prometheus_db_collector.py — Unified metric collector for multi-DB environments
import prometheus_client as prom
import mysql.connector
import psycopg2
import pymongo
import redis
from couchbase.cluster import Cluster
from couchbase.options import ClusterOptions
from couchbase.auth import PasswordAuthenticator
import time
import logging
logger = logging.getLogger(__name__)
# MySQL metrics
mysql_slow_queries = prom.Gauge('mysql_slow_queries_total', 'Total slow queries')
mysql_buffer_pool_hit = prom.Gauge('mysql_innodb_buffer_pool_hit_ratio', 'Buffer pool hit ratio')
mysql_deadlocks = prom.Counter('mysql_deadlocks_total', 'Total deadlocks detected')
mysql_repl_lag = prom.Gauge('mysql_replication_lag_seconds', 'Replication lag in seconds')
mysql_active_connections = prom.Gauge('mysql_active_connections', 'Current active connections')
mysql_threads_running = prom.Gauge('mysql_threads_running', 'Currently running threads')
# PostgreSQL metrics
pg_bloat_ratio = prom.Gauge('pg_table_bloat_ratio', 'Table bloat ratio', ['table_name'])
pg_vacuum_age = prom.Gauge('pg_vacuum_age_seconds', 'Seconds since last vacuum', ['table_name'])
pg_index_hit_ratio = prom.Gauge('pg_index_hit_ratio', 'Index hit ratio')
pg_wal_rate = prom.Gauge('pg_wal_bytes_per_second', 'WAL generation rate')
pg_active_locks = prom.Gauge('pg_active_locks', 'Number of active locks', ['lock_type'])
# MongoDB metrics
mongo_opcounters = prom.Gauge('mongo_opcounters', 'Operation counters', ['op_type'])
mongo_wiredtiger_cache = prom.Gauge('mongo_wiredtiger_cache_usage_pct', 'WiredTiger cache usage')
mongo_repl_lag = prom.Gauge('mongo_replication_lag_seconds', 'Replica set lag')
# Redis metrics
redis_memory_frag = prom.Gauge('redis_memory_fragmentation_ratio', 'Memory fragmentation ratio')
redis_evicted_keys = prom.Counter('redis_evicted_keys_total', 'Total evicted keys')
redis_keyspace_hitrate = prom.Gauge('redis_keyspace_hit_ratio', 'Keyspace hit ratio')
class UnifiedDBCollector:
def __init__(self, config):
self.config = config
self.connections = {}
def collect_mysql(self):
conn = mysql.connector.connect(**self.config['mysql'])
cursor = conn.cursor(dictionary=True)
cursor.execute("SHOW GLOBAL STATUS LIKE 'Slow_queries'")
row = cursor.fetchone()
mysql_slow_queries.set(int(row['Value']))
cursor.execute("""
SELECT
(1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)) * 100
AS hit_ratio FROM (
SELECT
VARIABLE_VALUE AS Innodb_buffer_pool_reads
FROM performance_schema.global_status
WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads'
) a, (
SELECT
VARIABLE_VALUE AS Innodb_buffer_pool_read_requests
FROM performance_schema.global_status
WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests'
) b
""")
result = cursor.fetchone()
mysql_buffer_pool_hit.set(float(result['hit_ratio']))
cursor.execute("SHOW GLOBAL STATUS LIKE 'Innodb_deadlocks'")
row = cursor.fetchone()
mysql_deadlocks.inc(int(row['Value']))
cursor.execute("SHOW SLAVE STATUS")
slave = cursor.fetchone()
if slave and slave.get('Seconds_Behind_Master') is not None:
mysql_repl_lag.set(float(slave['Seconds_Behind_Master']))
cursor.execute("SHOW GLOBAL STATUS LIKE 'Threads_connected'")
row = cursor.fetchone()
mysql_active_connections.set(int(row['Value']))
cursor.close()
conn.close()
def collect_postgresql(self):
conn = psycopg2.connect(**self.config['postgresql'])
cursor = conn.cursor()
cursor.execute("""
SELECT schemaname, tablename,
pg_total_relation_size(schemaname || '.' || tablename) as total_size,
pg_relation_size(schemaname || '.' || tablename) as table_size
FROM pg_tables
WHERE schemaname = 'public'
""")
for row in cursor.fetchall():
if row[3] > 0:
bloat = (row[2] - row[3]) / row[2]
pg_bloat_ratio.labels(table_name=row[1]).set(bloat)
cursor.execute("""
SELECT relname, extract(epoch from now() - last_vacuum) as vacuum_age
FROM pg_stat_user_tables
WHERE last_vacuum IS NOT NULL
""")
for row in cursor.fetchall():
pg_vacuum_age.labels(table_name=row[0]).set(row[1])
cursor.execute("""
SELECT sum(heap_blks_hit) / nullif(sum(heap_blks_hit) + sum(heap_blks_read), 0)
FROM pg_statio_user_tables
""")
result = cursor.fetchone()
if result[0]:
pg_index_hit_ratio.set(float(result[0]))
cursor.close()
conn.close()
def collect_mongodb(self):
client = pymongo.MongoClient(self.config['mongodb']['uri'])
status = client.admin.command('serverStatus')
for op in ['insert', 'query', 'update', 'delete']:
mongo_opcounters.labels(op_type=op).set(status['opcounters'][op])
cache = status['wiredTiger']['cache']
cache_used = cache['bytes currently in the cache']
cache_max = cache['maximum bytes configured']
mongo_wiredtiger_cache.set((cache_used / cache_max) * 100)
client.close()
def collect_redis(self):
r = redis.Redis(**self.config['redis'])
info = r.info()
redis_memory_frag.set(info.get('mem_fragmentation_ratio', 0))
redis_evicted_keys.inc(info.get('evicted_keys', 0))
hits = info.get('keyspace_hits', 0)
misses = info.get('keyspace_misses', 0)
if hits + misses > 0:
redis_keyspace_hitrate.set(hits / (hits + misses))
r.close()
def run(self, interval=15):
prom.start_http_server(9100)
logger.info('Metric collector started on :9100')
while True:
try:
self.collect_mysql()
self.collect_postgresql()
self.collect_mongodb()
self.collect_redis()
except Exception as e:
logger.error(f'Collection error: {e}')
time.sleep(interval)
समय-श्रृंखला विश्लेषण के साथ विसंगति का पता लगाना
डेटाबेस मॉनिटरिंग में एआई का मुख्य मूल्य प्रस्ताव विसंगति का पता लगाना है - असामान्य पैटर्न की पहचान करना जो सीखी गई आधार रेखाओं से विचलित होते हैं। तीन प्राथमिक एल्गोरिदम इस स्थान पर हावी हैं: मौसमी अपघटन के लिए फेसबुक पैगंबर, जटिल अस्थायी पैटर्न के लिए एलएसटीएम नेटवर्क, और बहुभिन्नरूपी बाहरी पहचान के लिए अलगाव वन।
स्किकिट-लर्न और पैगम्बर के साथ विसंगति का पता लगाना
निम्नलिखित पायथन कार्यान्वयन एक उत्पादन-तैयार विसंगति डिटेक्टर को प्रदर्शित करता है जो समय-श्रृंखला पूर्वानुमान के लिए पैगंबर के साथ बहुभिन्नरूपी पता लगाने के लिए अलगाव वन को जोड़ता है। यह दोहरा दृष्टिकोण अचानक उछाल और क्रमिक बहाव दोनों को पकड़ता है।
# anomaly_detector.py — Production anomaly detection for database metrics
import numpy as np
import pandas as pd
from sklearn.ensemble import IsolationForest
from sklearn.preprocessing import StandardScaler
from prophet import Prophet
from prometheus_api_client import PrometheusConnect
from datetime import datetime, timedelta
import warnings
import json
import logging
warnings.filterwarnings('ignore')
logger = logging.getLogger(__name__)
class DatabaseAnomalyDetector:
def __init__(self, prometheus_url, contamination=0.05):
self.prom = PrometheusConnect(url=prometheus_url, disable_ssl=True)
self.scaler = StandardScaler()
self.isolation_forest = IsolationForest(
contamination=contamination,
n_estimators=200,
max_samples='auto',
random_state=42,
n_jobs=-1
)
self.prophet_models = {}
self.baseline_stats = {}
def fetch_metrics(self, query, hours=168):
"""Fetch metric data from Prometheus for the given time window."""
end_time = datetime.now()
start_time = end_time - timedelta(hours=hours)
result = self.prom.custom_query_range(
query=query,
start_time=start_time,
end_time=end_time,
step='60s'
)
if not result:
return pd.DataFrame()
timestamps, values = [], []
for point in result[0]['values']:
timestamps.append(datetime.fromtimestamp(float(point[0])))
values.append(float(point[1]))
return pd.DataFrame({'timestamp': timestamps, 'value': values})
def train_isolation_forest(self, metrics_dict):
"""Train Isolation Forest on multiple metric dimensions."""
frames = []
for name, df in metrics_dict.items():
if not df.empty:
series = df.set_index('timestamp')['value'].rename(name)
frames.append(series)
if not frames:
raise ValueError('No metric data available for training')
combined = pd.concat(frames, axis=1).dropna()
scaled = self.scaler.fit_transform(combined)
self.isolation_forest.fit(scaled)
self.baseline_stats = {
col: {'mean': combined[col].mean(), 'std': combined[col].std()}
for col in combined.columns
}
logger.info(f'Isolation Forest trained on {len(combined)} samples, {len(frames)} features')
return combined
def train_prophet(self, metric_name, df):
"""Train a Prophet model for seasonal time-series forecasting."""
if df.empty:
return
prophet_df = df.rename(columns={'timestamp': 'ds', 'value': 'y'})
model = Prophet(
changepoint_prior_scale=0.05,
seasonality_prior_scale=10,
holidays_prior_scale=10,
daily_seasonality=True,
weekly_seasonality=True,
yearly_seasonality=False,
interval_width=0.95
)
model.fit(prophet_df)
self.prophet_models[metric_name] = model
logger.info(f'Prophet model trained for {metric_name}')
def detect_anomalies_multivariate(self, current_metrics):
"""Detect anomalies using Isolation Forest across multiple metrics."""
scaled = self.scaler.transform(current_metrics)
predictions = self.isolation_forest.predict(scaled)
scores = self.isolation_forest.decision_function(scaled)
anomalies = []
for i, (pred, score) in enumerate(zip(predictions, scores)):
if pred == -1:
anomaly_score = max(0, min(1, 0.5 - score))
anomalies.append({
'index': i,
'score': round(anomaly_score, 4),
'severity': 'critical' if anomaly_score > 0.8 else 'warning',
'values': current_metrics.iloc[i].to_dict()
})
return anomalies
def detect_anomalies_timeseries(self, metric_name, df):
"""Detect anomalies using Prophet forecast bounds."""
model = self.prophet_models.get(metric_name)
if not model or df.empty:
return []
prophet_df = df.rename(columns={'timestamp': 'ds', 'value': 'y'})
forecast = model.predict(prophet_df[['ds']])
merged = prophet_df.merge(forecast[['ds', 'yhat', 'yhat_lower', 'yhat_upper']], on='ds')
anomalies = []
for _, row in merged.iterrows():
if row['y'] < row['yhat_lower'] or row['y'] > row['yhat_upper']:
deviation = abs(row['y'] - row['yhat'])
band = row['yhat_upper'] - row['yhat_lower']
severity_score = min(1.0, deviation / band) if band > 0 else 0.5
anomalies.append({
'timestamp': str(row['ds']),
'actual': round(row['y'], 4),
'predicted': round(row['yhat'], 4),
'lower': round(row['yhat_lower'], 4),
'upper': round(row['yhat_upper'], 4),
'score': round(severity_score, 4),
'severity': 'critical' if severity_score > 0.8 else 'warning'
})
return anomalies
def run_full_analysis(self, db_type='mysql'):
"""Run complete anomaly detection pipeline for a database type."""
metric_queries = {
'mysql': {
'cpu': 'rate(process_cpu_seconds_total{job="mysql"}[5m])',
'connections': 'mysql_global_status_threads_connected',
'slow_queries': 'rate(mysql_global_status_slow_queries[5m])',
'buffer_pool_hit': 'mysql_global_status_innodb_buffer_pool_hit_ratio',
'repl_lag': 'mysql_slave_status_seconds_behind_master'
},
'postgresql': {
'cpu': 'rate(process_cpu_seconds_total{job="postgres"}[5m])',
'connections': 'pg_stat_activity_count',
'cache_hit': 'pg_stat_database_blks_hit / (pg_stat_database_blks_hit + pg_stat_database_blks_read)',
'deadlocks': 'rate(pg_stat_database_deadlocks[5m])',
'wal_rate': 'rate(pg_wal_lsn_diff[5m])'
}
}
queries = metric_queries.get(db_type, metric_queries['mysql'])
metrics = {}
for name, query in queries.items():
metrics[name] = self.fetch_metrics(query)
self.train_isolation_forest(metrics)
for name, df in metrics.items():
self.train_prophet(name, df)
results = {'db_type': db_type, 'anomalies': [], 'summary': {}}
for name, df in metrics.items():
ts_anomalies = self.detect_anomalies_timeseries(name, df)
if ts_anomalies:
results['anomalies'].extend([
{**a, 'metric': name} for a in ts_anomalies
])
results['summary'] = {
'total_anomalies': len(results['anomalies']),
'critical': sum(1 for a in results['anomalies'] if a['severity'] == 'critical'),
'warning': sum(1 for a in results['anomalies'] if a['severity'] == 'warning')
}
return results
if __name__ == '__main__':
detector = DatabaseAnomalyDetector('http://prometheus:9090')
results = detector.run_full_analysis('mysql')
print(json.dumps(results, indent=2))
पूर्वानुमानित चेतावनी बनाम सीमा-आधारित चेतावनी
पारंपरिक सीमा-आधारित चेतावनी दो विपरीत विफलता मोड से ग्रस्त है। थ्रेसहोल्ड को बहुत सख्त सेट करें और आप सामान्य लोड भिन्नताओं के दौरान झूठी सकारात्मकता में डूब जाएंगे। उन्हें बहुत ढीला छोड़ दें और आप वास्तविक गिरावट से चूक जाएंगे जब तक कि यह पूर्ण आउटेज न बन जाए। पूर्वानुमानित चेतावनी प्रत्येक समय प्रत्येक बिंदु पर प्रत्येक मीट्रिक के लिए "सामान्य" कैसा दिखता है, यह सीखकर दोनों समस्याओं का समाधान करती है।
| पहलू | थ्रेसहोल्ड आधारित | पूर्वानुमानित (एआई) |
|---|---|---|
| झूठी सकारात्मक दर | 40-70% | 3-8% |
| आउटेज से पहले लीड समय | 0 मिनट (प्रतिक्रियाशील) | 15-45 मिनट (अनुमानित) |
| लोड पैटर्न के अनुकूल होता है | नहीं, मैन्युअल ट्यूनिंग की आवश्यकता है | हाँ, स्वचालित आधारभूत शिक्षा |
| बहु-मीट्रिक सहसंबंध | मैनुअल नियम श्रृंखलाएँ | स्वचालित क्रॉस-मीट्रिक विश्लेषण |
| मौसमी जागरूकता | कोई नहीं | दैनिक, साप्ताहिक, मासिक चक्र |
| सेटअप जटिलता | कम | मध्यम (प्रारंभिक प्रशिक्षण अवधि) |
| रखरखाव | उच्च (निरंतर थ्रेशोल्ड ट्यूनिंग) | निम्न (स्व-अनुकूलन मॉडल) |
प्राकृतिक भाषा डेटाबेस क्वेरीज़ और अनुकूलन के लिए LLM एकीकरण
GPT-4 और क्लाउड जैसे बड़े भाषा मॉडल बुद्धिमान डेटाबेस सहायक के रूप में काम कर सकते हैं, प्राकृतिक भाषा के प्रश्नों का SQL में अनुवाद कर सकते हैं, EXPLAIN योजनाओं का विश्लेषण कर सकते हैं और अनुकूलन का सुझाव दे सकते हैं। यह क्षमता बदल देती है कि डीबीए और डेवलपर्स डेटाबेस के साथ कैसे इंटरैक्ट करते हैं - निष्पादन योजनाओं को मैन्युअल रूप से विच्छेदित करने के बजाय, वे सादे अंग्रेजी में समस्या का वर्णन कर सकते हैं और कार्रवाई योग्य सिफारिशें प्राप्त कर सकते हैं।
एक LLM क्वेरी ऑप्टिमाइज़र का निर्माण
निम्नलिखित पायथन कार्यान्वयन एक LLM-संचालित क्वेरी अनुकूलन सहायक बनाता है जो EXPLAIN योजनाओं का विश्लेषण करता है और सुधार का सुझाव देता है। यह OpenAI के API के साथ एकीकृत होता है और इसमें स्कीमा-जागरूक संदर्भ निर्माण शामिल है।
# llm_query_optimizer.py — AI-powered database query optimization
import openai
import json
import mysql.connector
import psycopg2
import logging
from dataclasses import dataclass
from typing import Optional
logger = logging.getLogger(__name__)
@dataclass
class QueryAnalysis:
original_query: str
explain_plan: dict
schema_context: str
suggestions: list
optimized_query: Optional[str]
estimated_improvement: str
class LLMQueryOptimizer:
def __init__(self, api_key, db_config, db_type='mysql', model='gpt-4'):
self.client = openai.OpenAI(api_key=api_key)
self.db_config = db_config
self.db_type = db_type
self.model = model
def get_explain_plan(self, query):
"""Execute EXPLAIN ANALYZE and return the plan."""
if self.db_type == 'mysql':
conn = mysql.connector.connect(**self.db_config)
cursor = conn.cursor(dictionary=True)
cursor.execute(f'EXPLAIN FORMAT=JSON {query}')
plan = cursor.fetchone()
cursor.close()
conn.close()
return json.loads(plan['EXPLAIN'])
elif self.db_type == 'postgresql':
conn = psycopg2.connect(**self.db_config)
cursor = conn.cursor()
cursor.execute(f'EXPLAIN (FORMAT JSON, ANALYZE, BUFFERS) {query}')
plan = cursor.fetchone()[0]
cursor.close()
conn.close()
return plan
def get_schema_context(self, tables):
"""Extract schema DDL and statistics for context."""
context_parts = []
if self.db_type == 'mysql':
conn = mysql.connector.connect(**self.db_config)
cursor = conn.cursor()
for table in tables:
cursor.execute(f'SHOW CREATE TABLE {table}')
row = cursor.fetchone()
context_parts.append(f'-- Table: {table}\n{row[1]}')
cursor.execute(f'SHOW INDEX FROM {table}')
indexes = cursor.fetchall()
idx_info = '\n'.join([f' Index: {idx[2]}, Column: {idx[4]}, Cardinality: {idx[6]}' for idx in indexes])
context_parts.append(f'-- Indexes for {table}:\n{idx_info}')
cursor.execute(f"SELECT table_rows, data_length, index_length FROM information_schema.tables WHERE table_name = '{table}'")
stats = cursor.fetchone()
if stats:
context_parts.append(f'-- Stats: rows={stats[0]}, data_size={stats[1]}, index_size={stats[2]}')
cursor.close()
conn.close()
return '\n\n'.join(context_parts)
def analyze_query(self, query, tables):
"""Full LLM analysis of a slow query."""
explain_plan = self.get_explain_plan(query)
schema_context = self.get_schema_context(tables)
prompt = f"""You are an expert database administrator specializing in {self.db_type} performance tuning.
Analyze the following slow query, its EXPLAIN plan, and the schema context. Provide:
1. Root cause of poor performance
2. Specific index recommendations (with CREATE INDEX statements)
3. Query rewrite suggestions (with the rewritten SQL)
4. Estimated performance improvement
5. Any schema changes that would help
## Original Query
```sql
{query}
```
## EXPLAIN Plan
```json
{json.dumps(explain_plan, indent=2)}
```
## Schema Context
```
{schema_context}
```
Respond in JSON format:
{{
"root_cause": "...",
"index_recommendations": ["CREATE INDEX ...", ...],
"rewritten_query": "SELECT ...",
"estimated_improvement": "Nx faster",
"schema_changes": ["..."],
"explanation": "..."
}}"""
response = self.client.chat.completions.create(
model=self.model,
messages=[
{'role': 'system', 'content': 'You are an expert DBA. Return valid JSON only.'},
{'role': 'user', 'content': prompt}
],
temperature=0.1,
response_format={'type': 'json_object'}
)
result = json.loads(response.choices[0].message.content)
return QueryAnalysis(
original_query=query,
explain_plan=explain_plan,
schema_context=schema_context,
suggestions=result.get('index_recommendations', []),
optimized_query=result.get('rewritten_query'),
estimated_improvement=result.get('estimated_improvement', 'Unknown')
)
def batch_optimize(self, slow_query_log_path, top_n=20):
"""Parse slow query log and optimize the top N most impactful queries."""
queries = self._parse_slow_log(slow_query_log_path)
sorted_queries = sorted(queries, key=lambda q: q['total_time'], reverse=True)[:top_n]
results = []
for q in sorted_queries:
try:
tables = self._extract_tables(q['query'])
analysis = self.analyze_query(q['query'], tables)
results.append({
'query': q['query'],
'frequency': q['count'],
'total_time': q['total_time'],
'analysis': analysis
})
logger.info(f'Optimized query (est. {analysis.estimated_improvement}): {q["query"][:80]}')
except Exception as e:
logger.error(f'Failed to analyze query: {e}')
return results
def _parse_slow_log(self, path):
queries = {}
current_query = []
current_time = 0
with open(path) as f:
for line in f:
if line.startswith('# Query_time:'):
parts = line.split()
current_time = float(parts[2])
elif line.startswith('SET timestamp') or line.startswith('#'):
continue
elif line.strip().endswith(';'):
current_query.append(line.strip())
full_query = ' '.join(current_query)
if full_query not in queries:
queries[full_query] = {'query': full_query, 'count': 0, 'total_time': 0}
queries[full_query]['count'] += 1
queries[full_query]['total_time'] += current_time
current_query = []
else:
current_query.append(line.strip())
return list(queries.values())
def _extract_tables(self, query):
import re
tables = set()
for match in re.finditer(r'(?:FROM|JOIN|INTO|UPDATE)\s+[`"]?(\w+)[`"]?', query, re.IGNORECASE):
tables.add(match.group(1))
return list(tables)
if __name__ == '__main__':
import os
optimizer = LLMQueryOptimizer(
api_key=os.environ['OPENAI_API_KEY'],
db_config={'host': 'localhost', 'user': 'root', 'password': '', 'database': 'app_db'},
db_type='mysql'
)
analysis = optimizer.analyze_query(
'SELECT * FROM orders o JOIN users u ON o.user_id = u.id WHERE o.status = "pending" AND o.created_at > "2026-01-01" ORDER BY o.created_at DESC LIMIT 100',
['orders', 'users']
)
print(json.dumps(analysis.__dict__, indent=2, default=str))
ऑटो-रेमेडिएशन वर्कफ़्लोज़
ऑटो-रेमेडिएशन वह जगह है जहां एआई-संचालित डेटाबेस मॉनिटरिंग सबसे ठोस आरओआई प्रदान करती है। किसी भगोड़े क्वेरी को खत्म करने या प्रतिकृतियों को पढ़ने के लिए स्केल करने के लिए सुबह 3 बजे डीबीए को जगाने के बजाय, सिस्टम इसे पूर्ण ऑडिट ट्रेल्स और आत्मविश्वास स्कोरिंग के साथ स्वचालित रूप से संभालता है।
# auto_remediation.py — Automated database issue remediation
import subprocess
import mysql.connector
import psycopg2
import pymongo
import redis
import logging
import json
from datetime import datetime
from enum import Enum
logger = logging.getLogger(__name__)
class Severity(Enum):
LOW = 'low'
MEDIUM = 'medium'
HIGH = 'high'
CRITICAL = 'critical'
class RemediationAction:
def __init__(self, name, description, severity_threshold, confidence_threshold=0.9):
self.name = name
self.description = description
self.severity_threshold = severity_threshold
self.confidence_threshold = confidence_threshold
class AutoRemediator:
def __init__(self, db_configs, notification_webhook=None):
self.db_configs = db_configs
self.webhook = notification_webhook
self.action_log = []
def _log_action(self, action, target, result, confidence):
entry = {
'timestamp': datetime.utcnow().isoformat(),
'action': action,
'target': target,
'result': result,
'confidence': confidence
}
self.action_log.append(entry)
logger.info(f'Remediation: {json.dumps(entry)}')
if self.webhook:
self._notify(entry)
def kill_long_running_queries(self, db_type='mysql', max_duration_seconds=300, confidence=0.95):
"""Kill queries exceeding duration threshold."""
if confidence < 0.9:
logger.warning(f'Low confidence ({confidence}), skipping kill action')
return []
killed = []
if db_type == 'mysql':
conn = mysql.connector.connect(**self.db_configs['mysql'])
cursor = conn.cursor(dictionary=True)
cursor.execute("""
SELECT id, user, host, db, time, state, info
FROM information_schema.processlist
WHERE command != 'Sleep'
AND time > %s
AND user != 'system user'
ORDER BY time DESC
""", (max_duration_seconds,))
for proc in cursor.fetchall():
try:
cursor.execute(f'KILL {proc["id"]}')
killed.append(proc)
self._log_action('kill_query', f'mysql:{proc["id"]}', 'success', confidence)
except Exception as e:
self._log_action('kill_query', f'mysql:{proc["id"]}', f'failed: {e}', confidence)
cursor.close()
conn.close()
elif db_type == 'postgresql':
conn = psycopg2.connect(**self.db_configs['postgresql'])
cursor = conn.cursor()
cursor.execute("""
SELECT pid, usename, application_name, state,
extract(epoch from now() - query_start) as duration, query
FROM pg_stat_activity
WHERE state = 'active'
AND extract(epoch from now() - query_start) > %s
AND usename != 'postgres'
""", (max_duration_seconds,))
for row in cursor.fetchall():
try:
cursor.execute('SELECT pg_terminate_backend(%s)', (row[0],))
conn.commit()
killed.append({'pid': row[0], 'user': row[1], 'duration': row[4]})
self._log_action('kill_query', f'pg:{row[0]}', 'success', confidence)
except Exception as e:
self._log_action('kill_query', f'pg:{row[0]}', f'failed: {e}', confidence)
cursor.close()
conn.close()
return killed
def scale_read_replicas(self, platform='kubernetes', target_replicas=None, confidence=0.92):
"""Scale database read replicas based on load prediction."""
if confidence < 0.85:
logger.warning('Insufficient confidence for scaling action')
return None
if platform == 'kubernetes':
cmd = f'kubectl scale statefulset mysql-read --replicas={target_replicas}'
result = subprocess.run(cmd.split(), capture_output=True, text=True)
self._log_action('scale_replicas', f'k8s:mysql-read:{target_replicas}', result.stdout.strip(), confidence)
return result.stdout
elif platform == 'aws':
import boto3
rds = boto3.client('rds')
response = rds.create_db_instance_read_replica(
DBInstanceIdentifier=f'read-replica-{datetime.now().strftime("%Y%m%d%H%M")}',
SourceDBInstanceIdentifier='production-primary'
)
self._log_action('create_replica', 'aws:rds', response['DBInstance']['DBInstanceIdentifier'], confidence)
return response
def trigger_failover(self, db_type='mysql', confidence=0.98):
"""Initiate database failover when primary is unhealthy."""
if confidence < 0.95:
logger.critical(f'Failover requires confidence >= 0.95, got {confidence}. Escalating to human.')
self._notify({'action': 'failover_escalation', 'confidence': confidence})
return None
self._log_action('failover_initiated', db_type, 'starting', confidence)
if db_type == 'mysql':
result = subprocess.run(
['mysqlsh', '--', 'dba', 'switchToSecondary'],
capture_output=True, text=True
)
self._log_action('failover', 'mysql:innodb_cluster', result.stdout.strip(), confidence)
elif db_type == 'postgresql':
result = subprocess.run(
['patronictl', 'failover', '--force'],
capture_output=True, text=True
)
self._log_action('failover', 'pg:patroni', result.stdout.strip(), confidence)
def flush_redis_hotspot(self, pattern, confidence=0.9):
"""Identify and handle Redis key hotspots."""
r = redis.Redis(**self.db_configs['redis'])
cursor = 0
hot_keys = []
while True:
cursor, keys = r.scan(cursor, match=pattern, count=1000)
for key in keys:
idle = r.object('idletime', key)
if idle is not None and idle < 5:
hot_keys.append(key.decode())
if cursor == 0:
break
if hot_keys:
self._log_action('hotspot_detected', f'redis:{pattern}', f'{len(hot_keys)} hot keys', confidence)
return hot_keys
def run_pg_vacuum(self, table, confidence=0.92):
"""Force VACUUM ANALYZE on bloated PostgreSQL tables."""
conn = psycopg2.connect(**self.db_configs['postgresql'])
conn.autocommit = True
cursor = conn.cursor()
cursor.execute(f'VACUUM (VERBOSE, ANALYZE) {table}')
self._log_action('vacuum', f'pg:{table}', 'completed', confidence)
cursor.close()
conn.close()
def _notify(self, payload):
import requests
try:
requests.post(self.webhook, json=payload, timeout=5)
except Exception as e:
logger.error(f'Notification failed: {e}')
MySQL-विशिष्ट AI समस्या निवारण
MySQL अनूठी चुनौतियाँ प्रस्तुत करता है जो AI विश्लेषण से अत्यधिक लाभान्वित होती हैं। InnoDB बफर पूल प्रबंधन, गतिरोध का पता लगाना, धीमी क्वेरी पैटर्न पहचान, और प्रतिकृति अंतराल भविष्यवाणी प्रत्येक के लिए MySQL-विशिष्ट मेट्रिक्स पर प्रशिक्षित विशेष एमएल मॉडल की आवश्यकता होती है।
एमएल के साथ धीमी क्वेरी विश्लेषण
धीमी क्वेरी लॉग की मैन्युअल रूप से समीक्षा करने के बजाय, एक एमएल मॉडल प्रश्नों को उनके प्रदर्शन प्रभाव और मूल कारण के आधार पर वर्गीकृत करता है। सामान्य पैटर्न में गायब इंडेक्स, कार्टेशियन जॉइन, अनुक्रमित कॉलम पर फ़ंक्शन के साथ उप-इष्टतम WHERE क्लॉज और विस्तृत तालिकाओं पर SELECT * शामिल हैं।
InnoDB बफर पूल अनुकूलन
बफ़र पूल हिट अनुपात MySQL का सबसे महत्वपूर्ण मीट्रिक है। एआई मॉडल कार्यभार पैटर्न और बफर पूल प्रभावशीलता के बीच संबंध सीखते हैं, भविष्यवाणी करते हैं कि हिट अनुपात कब घटेगा और सक्रिय innodb_buffer_pool_size समायोजन की सिफारिश करेंगे। बफ़र पूल मेट्रिक्स पर प्रशिक्षित एक LSTM मॉडल क्वेरी विलंबता को प्रभावित करने से 30 मिनट पहले कैश दबाव की भविष्यवाणी कर सकता है।
गतिरोध का पता लगाना और रोकथाम
AI आवर्ती पैटर्न की पहचान करने के लिए InnoDB गतिरोध ग्राफ़ का विश्लेषण करता है। गतिरोध उत्पन्न होने के बाद केवल लॉगिंग करने के बजाय, सिस्टम सीखता है कि कौन से लेनदेन अनुक्रम गतिरोध का कारण बनते हैं और संचालन को फिर से व्यवस्थित कर सकते हैं या अलगाव के स्तर को पहले से समायोजित कर सकते हैं।
PostgreSQL-विशिष्ट AI समस्या निवारण
PostgreSQL का MVCC आर्किटेक्चर टेबल ब्लोट, वैक्यूम शेड्यूलिंग और WAL प्रबंधन के आसपास अद्वितीय चुनौतियाँ पैदा करता है जो AI-संचालित विश्लेषण से लाभान्वित होते हैं।
वैक्यूम विश्लेषण और ब्लोट डिटेक्शन
एआई मॉडल लेनदेन दरों, मृत टपल संचय और ऑटोवैक्यूम प्रभावशीलता के बीच संबंधों को ट्रैक करते हैं। प्रत्येक तालिका के लिए ब्लोट वृद्धि दर सीखकर, सिस्टम भविष्यवाणी करता है कि टेबल समस्याग्रस्त ब्लोट स्तर तक कब पहुंच जाएंगी और प्रदर्शन में गिरावट से पहले लक्षित वैक्यूम संचालन को ट्रिगर करती है।
सूचकांक सिफ़ारिशें
pg_stat_user_indexes और pg_stat_statements का एक साथ विश्लेषण करने से सूचकांक उपयोग पैटर्न का पता चलता है। एआई डिस्क स्थान का उपभोग करने वाले अप्रयुक्त इंडेक्स की पहचान करता है और क्वेरी पैटर्न के आधार पर नए इंडेक्स का सुझाव देता है - अतिरिक्त इंडेक्स की लेखन प्रवर्धन लागत बनाम पढ़ने के प्रदर्शन लाभ पर विचार करते हुए।
कनेक्शन पूल अनुकूलन
PostgreSQL कनेक्शन को MySQL से अलग तरीके से संभालता है, प्रत्येक कनेक्शन काफी अधिक मेमोरी की खपत करता है। एआई मॉडल विभिन्न वर्कलोड प्रोफाइल (ओएलटीपी बनाम ओएलएपी बनाम मिश्रित) के लिए इष्टतम पूल आकार निर्धारित करने के लिए पीजीबाउंसर में कनेक्शन पूल उपयोग पैटर्न का विश्लेषण करते हैं, जिससे कनेक्शन भुखमरी और मेमोरी थकावट दोनों को रोका जा सकता है।
MongoDB-विशिष्ट AI समस्या निवारण
MongoDB का दस्तावेज़ मॉडल और वितरित आर्किटेक्चर प्रदर्शन चुनौतियों का एक अलग सेट बनाता है जिसे AI प्रभावी ढंग से संबोधित कर सकता है।
सूचकांक सुझाव
MongoDB क्वेरी प्रोफाइलर का AI विश्लेषण संग्रह स्कैन (COLLSCAN) करने वाले प्रश्नों की पहचान करता है और क्वेरी फ़ील्ड संयोजनों के आधार पर कंपाउंड इंडेक्स की अनुशंसा करता है। मॉडल इष्टतम सूचकांक विनिर्देश उत्पन्न करने के लिए चयनात्मकता, फ़ील्ड क्रम और कवर क्वेरी अनुकूलन पर विचार करता है।
साझाकरण अनुकूलन
शार्प क्लस्टर के लिए, AI चंक वितरण, माइग्रेशन दर और क्वेरी रूटिंग पैटर्न की निगरानी करता है। जब यह असमान शार्ड उपयोग (हॉट शार्ड) का पता लगाता है, तो यह शार्ड कुंजी परिवर्तन या पूर्व-विभाजन रणनीतियों की सिफारिश करता है। एमएल मॉडल प्रदर्शन पर प्रभाव पड़ने से पहले डेटा वितरण को सक्रिय रूप से संतुलित करने के लिए खंड वृद्धि दर की भविष्यवाणी करते हैं।
वायर्डटाइगर कैश विश्लेषण
वायर्डटाइगर कैश निष्कासन पैटर्न कार्यभार विशेषताओं को प्रकट करते हैं। एआई मॉडल तब सीखते हैं जब कैश दबाव कार्यशील सेट वृद्धि बनाम अकुशल एक्सेस पैटर्न के कारण होता है, या तो कैश आकार बढ़ाने या क्वेरी बैचिंग जैसे एप्लिकेशन-स्तर में बदलाव की सिफारिश करते हैं।
रेडिस-विशिष्ट एआई समस्या निवारण
रेडिस डिस्क-आधारित डेटाबेस की तुलना में विभिन्न बाधाओं के तहत काम करता है - मेमोरी महत्वपूर्ण संसाधन है, और विलंबता आवश्यकताएं अक्सर उप-मिलीसेकंड होती हैं।
स्मृति विश्लेषण
एआई मेमोरी विखंडन अनुपात, कुंजी आकार वितरण और टीटीएल पैटर्न को ट्रैक करता है। जब विखंडन स्वस्थ सीमा से अधिक हो जाता है, तो सिस्टम निर्धारित करता है कि क्या ACTIVEDEFRAG समायोजन या नियंत्रित पुनरारंभ बेहतर उपचार है। एमएल मॉडल OOM किलों को रोकने के लिए मेमोरी वृद्धि प्रक्षेपवक्र की भविष्यवाणी करते हैं।
मुख्य पैटर्न का पता लगाना और हॉटस्पॉट की पहचान
मॉनिटर सैंपलिंग और ऑब्जेक्ट फ्रीक विश्लेषण का उपयोग करते हुए, एआई क्लस्टर स्लॉट में असमान लोड वितरण का कारण बनने वाली हॉट कुंजियों की पहचान करता है। रेडिस क्लस्टर परिनियोजन के लिए, सिस्टम स्लॉट माइग्रेशन बाधाओं का पता लगाता है और हैश स्लॉट वितरण में सुधार के लिए प्रमुख नामकरण परिवर्तनों की सिफारिश करता है।
बेदखली नीति अनुकूलन
अलग-अलग कार्यभार अलग-अलग निष्कासन नीतियों (अस्थिर-एलआरयू, ऑलकीज़-एलएफयू, अस्थिर-टीटीएल) से लाभान्वित होते हैं। एआई इष्टतम मैक्समेमोरी-पॉलिसी की सिफारिश करने के लिए एक्सेस पैटर्न का विश्लेषण करता है, जो वर्तमान कुंजी एक्सेस वितरण के आधार पर प्रत्येक पॉलिसी के हिट दर प्रभाव का अनुमान लगाता है।
काउचबेस-विशिष्ट एआई समस्या निवारण
काउचबेस दस्तावेज़ स्टोर, कुंजी-मूल्य और SQL-जैसी (N1QL) क्वेरी क्षमताओं को जोड़ता है, जो एक अद्वितीय अनुकूलन परिदृश्य बनाता है।
N1QL क्वेरी अनुकूलन
AI GSI (ग्लोबल सेकेंडरी इंडेक्स) निर्माण, कवर इंडेक्स रणनीतियों और क्वेरी रीराइट की सिफारिश करने के लिए N1QL क्वेरी पैटर्न और EXPLAIN आउटपुट का विश्लेषण करता है। सिस्टम सीखता है कि कौन से N1QL पैटर्न लगातार उप-इष्टतम योजनाएँ बनाते हैं और सक्रिय रूप से विकल्प सुझाते हैं।
सूचकांक सलाहकार एकीकरण
काउचबेस का अंतर्निहित इंडेक्स सलाहकार सिफारिशें प्रदान करता है, लेकिन एआई वैश्विक कार्यभार पर विचार करके इन्हें बढ़ाता है - अलग-अलग प्रश्नों के बजाय संपूर्ण एप्लिकेशन के एक्सेस पैटर्न में क्वेरी लाभों के विरुद्ध इंडेक्स निर्माण लागत को संतुलित करता है।
पुनर्संतुलन योजना
जब नोड्स जोड़े या हटाए जाते हैं, तो काउचबेस को डेटा को पुनर्संतुलित करना होगा। एआई ऐतिहासिक क्लस्टर व्यवहार के आधार पर पुनर्संतुलन अवधि, संसाधन प्रभाव और इष्टतम समय विंडो की भविष्यवाणी करता है। यह पीक आवर्स के दौरान पुनर्संतुलन कार्यों को उत्पादन ट्रैफ़िक को प्रभावित करने से रोकता है।
मल्टी-डेटाबेस एआई ऑब्जर्वेबिलिटी आर्किटेक्चर
अधिकांश उत्पादन वातावरण एकाधिक डेटाबेस इंजन चलाते हैं। एक एकीकृत एआई अवलोकन मंच को सभी इंजनों में मेट्रिक्स को सामान्य बनाना होगा, डेटा परत में विसंगतियों को सहसंबंधित करना होगा और संचालन टीमों के लिए एक सुसंगत दृश्य प्रस्तुत करना होगा।
चैटजीपीटी और क्लाउड के साथ एक कस्टम एआई डेटाबेस असिस्टेंट का निर्माण
आपके डेटाबेस इंफ्रास्ट्रक्चर के साथ LLM को एकीकृत करने से एक इंटरैक्टिव डीबीए सहायक बनता है जो प्राकृतिक भाषा के सवालों का जवाब देता है, समस्याओं का निदान करता है और उपचारात्मक वर्कफ़्लो निष्पादित करता है। सहायक वास्तविक समय मीट्रिक पहुंच के साथ पुनर्प्राप्ति-संवर्धित पीढ़ी (RAG) को जोड़ता है।
# ai_dba_assistant.py — Custom AI DBA assistant with tool integration
import openai
import json
import os
from datetime import datetime
class AIDBAssistant:
def __init__(self, db_connections, prometheus_url):
self.client = openai.OpenAI(api_key=os.environ['OPENAI_API_KEY'])
self.db_conns = db_connections
self.prom_url = prometheus_url
self.conversation_history = []
self.tools = [
{
'type': 'function',
'function': {
'name': 'query_prometheus',
'description': 'Execute a PromQL query to fetch database metrics',
'parameters': {
'type': 'object',
'properties': {
'query': {'type': 'string', 'description': 'PromQL query'},
'duration': {'type': 'string', 'description': 'Time range (e.g. 1h, 24h)'}
},
'required': ['query']
}
}
},
{
'type': 'function',
'function': {
'name': 'run_explain',
'description': 'Run EXPLAIN on a SQL query',
'parameters': {
'type': 'object',
'properties': {
'query': {'type': 'string'},
'db_type': {'type': 'string', 'enum': ['mysql', 'postgresql']}
},
'required': ['query', 'db_type']
}
}
},
{
'type': 'function',
'function': {
'name': 'get_active_queries',
'description': 'List currently running database queries',
'parameters': {
'type': 'object',
'properties': {
'db_type': {'type': 'string', 'enum': ['mysql', 'postgresql', 'mongodb']},
'min_duration_seconds': {'type': 'integer', 'default': 0}
},
'required': ['db_type']
}
}
},
{
'type': 'function',
'function': {
'name': 'kill_query',
'description': 'Terminate a running database query by ID',
'parameters': {
'type': 'object',
'properties': {
'db_type': {'type': 'string'},
'process_id': {'type': 'integer'}
},
'required': ['db_type', 'process_id']
}
}
}
]
def chat(self, user_message):
self.conversation_history.append({'role': 'user', 'content': user_message})
system_prompt = """You are an expert DBA assistant with access to real-time database monitoring tools.
You can query Prometheus metrics, analyze EXPLAIN plans, view active queries, and kill problematic queries.
Always ground your answers in actual data by using the available tools.
When diagnosing issues, follow this methodology:
1. Check current metrics for anomalies
2. Identify root cause
3. Suggest specific remediation steps
4. Execute remediation if the user approves"""
messages = [{'role': 'system', 'content': system_prompt}] + self.conversation_history
response = self.client.chat.completions.create(
model='gpt-4',
messages=messages,
tools=self.tools,
tool_choice='auto'
)
message = response.choices[0].message
if message.tool_calls:
for tool_call in message.tool_calls:
fn_name = tool_call.function.name
fn_args = json.loads(tool_call.function.arguments)
result = self._execute_tool(fn_name, fn_args)
self.conversation_history.append(message)
self.conversation_history.append({
'role': 'tool',
'tool_call_id': tool_call.id,
'content': json.dumps(result)
})
follow_up = self.client.chat.completions.create(
model='gpt-4',
messages=[{'role': 'system', 'content': system_prompt}] + self.conversation_history
)
assistant_reply = follow_up.choices[0].message.content
else:
assistant_reply = message.content
self.conversation_history.append({'role': 'assistant', 'content': assistant_reply})
return assistant_reply
def _execute_tool(self, name, args):
if name == 'query_prometheus':
from prometheus_api_client import PrometheusConnect
prom = PrometheusConnect(url=self.prom_url)
return prom.custom_query(args['query'])
elif name == 'run_explain':
return {'plan': 'EXPLAIN output here'}
elif name == 'get_active_queries':
return {'queries': []}
elif name == 'kill_query':
return {'status': 'killed', 'process_id': args['process_id']}
return {'error': f'Unknown tool: {name}'}
प्रोमेथियस + ग्राफाना + एमएल पाइपलाइन सेटअप
ऑब्जर्वेबिलिटी स्टैक एआई डेटाबेस मॉनिटरिंग की रीढ़ है। प्रोमेथियस डेटाबेस निर्यातकों से मेट्रिक्स को स्क्रैप करता है, ग्राफाना उन्हें विज़ुअलाइज़ करता है, और एक एमएल पाइपलाइन विसंगति का पता लगाने के लिए समय-श्रृंखला डेटा को संसाधित करता है।
मल्टी-डीबी मॉनिटरिंग के लिए प्रोमेथियस कॉन्फ़िगरेशन
# prometheus.yml — Multi-database monitoring configuration
global:
scrape_interval: 15s
evaluation_interval: 15s
rule_files:
- /etc/prometheus/rules/db_anomaly_rules.yml
alerting:
alertmanagers:
- static_configs:
- targets: ['alertmanager:9093']
scrape_configs:
- job_name: 'mysql'
static_configs:
- targets: ['mysql-exporter:9104']
metrics_path: /metrics
scrape_interval: 10s
- job_name: 'postgresql'
static_configs:
- targets: ['postgres-exporter:9187']
scrape_interval: 10s
- job_name: 'mongodb'
static_configs:
- targets: ['mongodb-exporter:9216']
scrape_interval: 15s
- job_name: 'redis'
static_configs:
- targets: ['redis-exporter:9121']
scrape_interval: 10s
- job_name: 'couchbase'
static_configs:
- targets: ['couchbase-exporter:9420']
scrape_interval: 15s
remote_write:
- url: http://victoriametrics:8428/api/v1/write
कस्टम ग्राफाना डैशबोर्ड कॉन्फ़िगरेशन
# grafana_dashboard_generator.py — Auto-generate AI-powered Grafana dashboards
import json
import requests
class GrafanaDashboardGenerator:
def __init__(self, grafana_url, api_key):
self.url = grafana_url
self.headers = {'Authorization': f'Bearer {api_key}', 'Content-Type': 'application/json'}
def create_db_overview_dashboard(self):
dashboard = {
'dashboard': {
'title': 'AI Database Health Overview',
'tags': ['database', 'ai', 'monitoring'],
'timezone': 'browser',
'panels': [
self._anomaly_score_panel(grid_pos={'x': 0, 'y': 0, 'w': 12, 'h': 8}),
self._query_latency_panel(grid_pos={'x': 12, 'y': 0, 'w': 12, 'h': 8}),
self._connection_pool_panel(grid_pos={'x': 0, 'y': 8, 'w': 8, 'h': 8}),
self._replication_lag_panel(grid_pos={'x': 8, 'y': 8, 'w': 8, 'h': 8}),
self._buffer_cache_panel(grid_pos={'x': 16, 'y': 8, 'w': 8, 'h': 8}),
self._remediation_log_panel(grid_pos={'x': 0, 'y': 16, 'w': 24, 'h': 6})
],
'refresh': '10s'
},
'overwrite': True
}
resp = requests.post(f'{self.url}/api/dashboards/db', headers=self.headers, json=dashboard)
return resp.json()
def _anomaly_score_panel(self, grid_pos):
return {
'title': 'AI Anomaly Score (All Databases)',
'type': 'timeseries',
'gridPos': grid_pos,
'targets': [
{'expr': 'db_anomaly_score{db_type="mysql"}', 'legendFormat': 'MySQL'},
{'expr': 'db_anomaly_score{db_type="postgresql"}', 'legendFormat': 'PostgreSQL'},
{'expr': 'db_anomaly_score{db_type="mongodb"}', 'legendFormat': 'MongoDB'},
{'expr': 'db_anomaly_score{db_type="redis"}', 'legendFormat': 'Redis'},
{'expr': 'db_anomaly_score{db_type="couchbase"}', 'legendFormat': 'Couchbase'}
],
'fieldConfig': {
'defaults': {
'thresholds': {
'steps': [
{'value': 0, 'color': 'green'},
{'value': 0.5, 'color': 'yellow'},
{'value': 0.8, 'color': 'red'}
]
},
'max': 1, 'min': 0
}
}
}
def _query_latency_panel(self, grid_pos):
return {
'title': 'Query Latency P95 with AI Prediction',
'type': 'timeseries',
'gridPos': grid_pos,
'targets': [
{'expr': 'histogram_quantile(0.95, rate(db_query_duration_seconds_bucket[5m]))', 'legendFormat': 'Actual P95'},
{'expr': 'db_query_latency_predicted_p95', 'legendFormat': 'AI Predicted P95'}
]
}
def _connection_pool_panel(self, grid_pos):
return {
'title': 'Connection Pool Utilization',
'type': 'gauge',
'gridPos': grid_pos,
'targets': [
{'expr': 'db_connections_active / db_connections_max * 100', 'legendFormat': '{{db_type}}'}
]
}
def _replication_lag_panel(self, grid_pos):
return {
'title': 'Replication Lag (seconds)',
'type': 'timeseries',
'gridPos': grid_pos,
'targets': [
{'expr': 'mysql_slave_status_seconds_behind_master', 'legendFormat': 'MySQL'},
{'expr': 'pg_replication_lag_seconds', 'legendFormat': 'PostgreSQL'},
{'expr': 'mongodb_replset_member_replication_lag', 'legendFormat': 'MongoDB'}
]
}
def _buffer_cache_panel(self, grid_pos):
return {
'title': 'Buffer/Cache Hit Ratio',
'type': 'stat',
'gridPos': grid_pos,
'targets': [
{'expr': 'mysql_global_status_innodb_buffer_pool_hit_ratio', 'legendFormat': 'MySQL InnoDB'},
{'expr': 'pg_stat_database_blks_hit / (pg_stat_database_blks_hit + pg_stat_database_blks_read)', 'legendFormat': 'PostgreSQL'},
{'expr': 'redis_keyspace_hit_ratio', 'legendFormat': 'Redis'}
]
}
def _remediation_log_panel(self, grid_pos):
return {
'title': 'Auto-Remediation Action Log',
'type': 'table',
'gridPos': grid_pos,
'targets': [
{'expr': 'db_remediation_actions_total', 'format': 'table', 'instant': True}
]
}
इंटेलिजेंट अलर्टिंग के लिए पेजरड्यूटी और ऑप्सजेनी एकीकरण
इंटेलिजेंट अलर्टिंग साधारण वेबहुक सूचनाओं से कहीं आगे जाती है। एआई-समृद्ध अलर्ट में मूल कारण विश्लेषण, ऐतिहासिक संदर्भ, सुझाई गई रनबुक और आत्मविश्वास स्कोर शामिल हैं - ऑन-कॉल इंजीनियरों को मुद्दों को तेजी से हल करने के लिए आवश्यक संदर्भ देते हैं या पुष्टि करते हैं कि ऑटो-रेमेडिएशन ने पहले ही समस्या को संभाल लिया है।
# intelligent_alerting.py — AI-enriched alerting for PagerDuty and OpsGenie
import requests
import json
from datetime import datetime
class IntelligentAlertManager:
def __init__(self, pagerduty_key=None, opsgenie_key=None):
self.pd_key = pagerduty_key
self.og_key = opsgenie_key
def send_enriched_alert(self, anomaly, ai_analysis):
severity = anomaly.get('severity', 'warning')
pd_severity = {'critical': 'critical', 'warning': 'warning', 'info': 'info'}.get(severity, 'warning')
details = {
'anomaly_score': anomaly.get('score', 0),
'metric': anomaly.get('metric', 'unknown'),
'root_cause': ai_analysis.get('root_cause', 'Under investigation'),
'suggested_actions': ai_analysis.get('actions', []),
'auto_remediation_status': ai_analysis.get('remediation_status', 'pending'),
'similar_incidents': ai_analysis.get('similar_past_incidents', []),
'estimated_impact': ai_analysis.get('impact', 'Unknown'),
'confidence': ai_analysis.get('confidence', 0)
}
if self.pd_key:
self._send_pagerduty(pd_severity, anomaly, details)
if self.og_key:
self._send_opsgenie(severity, anomaly, details)
def _send_pagerduty(self, severity, anomaly, details):
payload = {
'routing_key': self.pd_key,
'event_action': 'trigger',
'payload': {
'summary': f'[AI] Database anomaly: {anomaly["metric"]} (score: {anomaly["score"]})',
'severity': severity,
'source': 'ai-db-monitor',
'component': anomaly.get('db_type', 'database'),
'custom_details': details
}
}
requests.post('https://events.pagerduty.com/v2/enqueue', json=payload)
def _send_opsgenie(self, severity, anomaly, details):
payload = {
'message': f'[AI] Database anomaly: {anomaly["metric"]} (score: {anomaly["score"]})',
'priority': {'critical': 'P1', 'warning': 'P3', 'info': 'P5'}.get(severity, 'P3'),
'details': details,
'tags': ['ai-monitoring', anomaly.get('db_type', 'database')]
}
requests.post(
'https://api.opsgenie.com/v2/alerts',
headers={'Authorization': f'GenieKey {self.og_key}'},
json=payload
)
एआई के साथ मूल कारण विश्लेषण
जब विसंगतियों का पता लगाया जाता है, तो घटना की प्रतिक्रिया में मूल कारण का निर्धारण करना सबसे अधिक समय लेने वाला कदम होता है। एआई-संचालित मूल कारण विश्लेषण घंटों के बजाय सेकंड के भीतर संभावित कारण को इंगित करने के लिए कई संकेतों-मीट्रिक विसंगतियों, लॉग पैटर्न, ट्रेस डेटा और हाल के परिवर्तनों को सहसंबंधित करता है।
यह दृष्टिकोण सिस्टम निर्भरता और ज्ञात विफलता मोड के ज्ञान ग्राफ को बनाए रखकर काम करता है। जब कोई विसंगति उत्पन्न होती है, तो एआई अपस्ट्रीम कारणों की पहचान करने के लिए ग्राफ़ को पार करता है। उदाहरण के लिए, यदि MySQL पर क्वेरी विलंबता बढ़ती है, तो सिस्टम जाँच करता है: क्या हाल ही में कोई तैनाती हुई थी? क्या कनेक्शन संख्या बदल गई? क्या प्रतिकृति अंतराल है? क्या डिस्क IOPS संतृप्त हैं? क्या कोई ताला विवाद है? प्रत्येक संकेत विभिन्न मूल कारणों के लिए संभाव्यता स्कोर में योगदान देता है।
एमएल भविष्यवाणियों के साथ क्षमता योजना
एमएल-संचालित क्षमता नियोजन प्रतिक्रियाशील स्केलिंग से आगे बढ़कर पूर्वानुमानित संसाधन प्रबंधन की ओर बढ़ता है। ऐतिहासिक विकास पैटर्न, मौसमी चक्र और नियोजित व्यावसायिक घटनाओं का विश्लेषण करके, एमएल मॉडल पूर्वानुमान लगाते हैं कि डेटाबेस संसाधन सीमा तक कब पहुंचेंगे।
पैगंबर क्षमता पूर्वानुमान में उत्कृष्टता प्राप्त करता है क्योंकि यह लापता डेटा, प्रवृत्ति परिवर्तन और मौसमी पैटर्न को मूल रूप से संभालता है। इसे 90 दिनों के दैनिक भंडारण वृद्धि डेटा पर प्रशिक्षित करें और यह विश्वास अंतराल के साथ एक पूर्वानुमान तैयार करता है जो दिखाता है कि आपको अतिरिक्त भंडारण का प्रावधान करने की आवश्यकता कब होगी। LSTM मॉडल अल्पकालिक क्षमता भविष्यवाणी के लिए बेहतर अनुकूल हैं - सुबह ट्रैफ़िक स्पाइक्स से पहले प्री-स्केल पर कनेक्शन पूल उपयोग के अगले 24 घंटों का पूर्वानुमान लगाना।
क्लाउड-विशिष्ट AI उपकरण
आरडीएस के लिए एडब्ल्यूएस डेवऑप्स गुरु
AWS DevOps Guru RDS उदाहरणों के लिए ML-संचालित विसंगति का पता लगाने की सुविधा प्रदान करता है। यह स्वचालित रूप से क्लाउडवॉच मेट्रिक्स की निगरानी करता है और प्रदर्शन विसंगतियों की पहचान करता है, उन्हें हाल की तैनाती या कॉन्फ़िगरेशन परिवर्तनों के साथ सहसंबंधित करता है। एकीकरण के लिए आपके RDS संसाधनों पर DevOps Guru को सक्षम करने और SNS सूचनाओं को कॉन्फ़िगर करने की आवश्यकता होती है।
Azure SQL और Cosmos DB के लिए Azure AI
Azure, Azure SQL डेटाबेस के लिए इंटेलिजेंट इनसाइट्स प्रदान करता है, जो प्रदर्शन प्रतिगमन, अवरुद्ध क्वेरी और संसाधन सीमाओं का पता लगाने के लिए एक अंतर्निहित एमएल मॉडल का उपयोग करता है। Azure Cosmos DB में अनुरोध इकाई अनुकूलन और विभाजन कुंजी चयन के लिए एक एकीकृत AI सलाहकार शामिल है।
क्लाउड SQL और फायरस्टोर के लिए GCP क्लाउड ऑपरेशंस
Google क्लाउड ऑपरेशंस (पूर्व में स्टैकड्राइवर) क्लाउड SQL के लिए बुद्धिमान अलर्टिंग प्रदान करता है। सिस्टम मीट्रिक बेसलाइन सीखता है और अलर्ट तभी उत्पन्न करता है जब व्यवहार सीखे गए पैटर्न से महत्वपूर्ण रूप से विचलित हो जाता है, स्थैतिक सीमा की तुलना में झूठी सकारात्मकता को काफी कम कर देता है।
ओपन-सोर्स डेटा गुणवत्ता उपकरण
अपाचे ग्रिफिन
अपाचे ग्रिफिन बड़े पैमाने पर डेटा संपत्तियों के लिए डेटा गुणवत्ता माप प्रदान करता है। जब आपकी एआई मॉनिटरिंग पाइपलाइन के साथ एकीकृत किया जाता है, तो यह डेटा गुणवत्ता विसंगतियों का पता लगाता है - गायब मूल्य, स्कीमा बहाव, वितरण परिवर्तन - जो अक्सर डेटाबेस प्रदर्शन समस्याओं से पहले होते हैं।
बड़ी उम्मीदें
ग्रेट एक्सपेक्टेशंस घोषणात्मक डेटा सत्यापन को सक्षम बनाता है। अपने डेटाबेस तालिकाओं के लिए अपेक्षाओं को परिभाषित करके (सीमा के भीतर पंक्ति गणना, सीमा के भीतर स्तंभ मान, संदर्भात्मक अखंडता), आप एक डेटा गुणवत्ता निगरानी परत बनाते हैं जिसे एआई मॉडल विसंगति का पता लगाने के लिए अतिरिक्त संकेतों के रूप में उपभोग कर सकते हैं।
# data_quality_check.py — Great Expectations integration for DB quality monitoring
import great_expectations as gx
def run_database_quality_checks(connection_string, suite_name='db_health'):
context = gx.get_context()
datasource = context.data_sources.add_sql(
name='production_db',
connection_string=connection_string
)
orders_asset = datasource.add_table_asset(name='orders', table_name='orders')
batch = orders_asset.add_batch_definition_whole_table('full_table').get_batch()
suite = context.suites.add(
gx.ExpectationSuite(name=suite_name)
)
suite.add_expectation(
gx.expectations.ExpectTableRowCountToBeBetween(min_value=1000, max_value=10000000)
)
suite.add_expectation(
gx.expectations.ExpectColumnValuesToNotBeNull(column='user_id')
)
suite.add_expectation(
gx.expectations.ExpectColumnValuesToBeUnique(column='order_number')
)
validation_result = batch.validate(suite)
if not validation_result.success:
failed = [r for r in validation_result.results if not r.success]
return {
'status': 'failed',
'failed_checks': len(failed),
'details': [{
'expectation': str(r.expectation_config),
'observed': r.result
} for r in failed]
}
return {'status': 'passed', 'checks_run': len(validation_result.results)}
संपूर्ण पाइपलाइन एकीकरण उदाहरण
सभी घटकों को एक साथ लाते हुए, निम्नलिखित ऑर्केस्ट्रेटर मीट्रिक संग्रह, विसंगति का पता लगाने, LLM विश्लेषण, अलर्टिंग और ऑटो-रेमेडिएशन को एक सतत पाइपलाइन में जोड़ता है जो आपके उत्पादन वातावरण में सभी डेटाबेस इंजनों की निगरानी करता है।
# pipeline_orchestrator.py — Full AI database monitoring pipeline
import schedule
import time
import logging
from anomaly_detector import DatabaseAnomalyDetector
from auto_remediation import AutoRemediator
from intelligent_alerting import IntelligentAlertManager
from llm_query_optimizer import LLMQueryOptimizer
import json
import os
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)
class AIDatabasePipeline:
def __init__(self):
self.detector = DatabaseAnomalyDetector(
prometheus_url=os.environ['PROMETHEUS_URL']
)
self.remediator = AutoRemediator(
db_configs={
'mysql': {'host': os.environ['MYSQL_HOST'], 'user': 'monitor', 'password': os.environ['MYSQL_PASS'], 'database': 'production'},
'postgresql': {'host': os.environ['PG_HOST'], 'user': 'monitor', 'password': os.environ['PG_PASS'], 'dbname': 'production'},
'redis': {'host': os.environ['REDIS_HOST'], 'port': 6379}
},
notification_webhook=os.environ.get('SLACK_WEBHOOK')
)
self.alerter = IntelligentAlertManager(
pagerduty_key=os.environ.get('PAGERDUTY_KEY'),
opsgenie_key=os.environ.get('OPSGENIE_KEY')
)
self.optimizer = LLMQueryOptimizer(
api_key=os.environ['OPENAI_API_KEY'],
db_config={'host': os.environ['MYSQL_HOST'], 'user': 'root', 'password': os.environ['MYSQL_PASS'], 'database': 'production'},
db_type='mysql'
)
def run_anomaly_detection_cycle(self):
"""Main detection cycle — runs every minute."""
for db_type in ['mysql', 'postgresql']:
try:
results = self.detector.run_full_analysis(db_type)
logger.info(f'{db_type}: {results["summary"]["total_anomalies"]} anomalies found')
for anomaly in results['anomalies']:
if anomaly['severity'] == 'critical':
ai_analysis = self._analyze_anomaly(anomaly, db_type)
self.alerter.send_enriched_alert(anomaly, ai_analysis)
if ai_analysis.get('confidence', 0) > 0.95:
self._auto_remediate(anomaly, db_type, ai_analysis)
except Exception as e:
logger.error(f'Detection cycle failed for {db_type}: {e}')
def run_query_optimization_cycle(self):
"""Batch query optimization — runs daily."""
try:
results = self.optimizer.batch_optimize('/var/log/mysql/slow.log', top_n=10)
for r in results:
logger.info(f'Query optimized: {r["analysis"].estimated_improvement}')
except Exception as e:
logger.error(f'Query optimization failed: {e}')
def _analyze_anomaly(self, anomaly, db_type):
return {
'root_cause': f'Anomaly in {anomaly["metric"]} for {db_type}',
'confidence': anomaly.get('score', 0.5),
'actions': ['investigate', 'scale_if_needed'],
'remediation_status': 'pending'
}
def _auto_remediate(self, anomaly, db_type, analysis):
metric = anomaly.get('metric', '')
confidence = analysis.get('confidence', 0)
if 'slow_queries' in metric or 'query_latency' in metric:
self.remediator.kill_long_running_queries(db_type=db_type, confidence=confidence)
elif 'connections' in metric:
self.remediator.scale_read_replicas(target_replicas=5, confidence=confidence)
elif 'repl_lag' in metric and confidence > 0.98:
self.remediator.trigger_failover(db_type=db_type, confidence=confidence)
logger.info(f'Auto-remediation executed for {metric} on {db_type}')
def start(self):
logger.info('AI Database Pipeline started')
schedule.every(1).minutes.do(self.run_anomaly_detection_cycle)
schedule.every(1).day.at('02:00').do(self.run_query_optimization_cycle)
while True:
schedule.run_pending()
time.sleep(10)
if __name__ == '__main__':
pipeline = AIDatabasePipeline()
pipeline.start()
एआई डेटाबेस मॉनिटरिंग की सफलता को ट्रैक करने के लिए मुख्य मेट्रिक्स
| मीट्रिक | एआई से पहले | एआई के बाद | सुधार |
|---|---|---|---|
| पता लगाने का औसत समय (MTTD) | 15-30 मिनट | 30 सेकंड-2 मिनट | 90-95% |
| समाधान का औसत समय (MTTR) | 45-120 मिनट | 2-5 मिनट | 95%+ |
| ग़लत सकारात्मक चेतावनी दर | 50-70% | 3-8% | 90%+ |
| घटनाएँ स्वतः-समाधान | 0% | 35-50% | एन/ए |
| प्रति सप्ताह डीबीए ऑन-कॉल पेज | 40-60 | 5-10 | 80%+ |
| क्वेरी अनुकूलन समय | प्रति प्रश्न 2-4 घंटे | प्रति प्रश्न 5 मिनट | 95%+ |
| क्षमता योजना सटीकता | 60% (मैन्युअल अनुमान) | 90%+ (एमएल भविष्यवाणी) | 50%+ |
सर्वोत्तम प्रथाएँ और उत्पादन संबंधी विचार
- अवलोकनशीलता से प्रारंभ करें, फिर बुद्धिमत्ता जोड़ें। एमएल मॉडल तैनात करने से पहले सुनिश्चित करें कि व्यापक मीट्रिक संग्रह मौजूद है। आप उस डेटा में विसंगतियों का पता नहीं लगा सकते जिसे आप एकत्र नहीं करते हैं।
- निवारण के लिए आत्मविश्वास सीमा का उपयोग करें। फेलओवर जैसी विनाशकारी कार्रवाइयों के लिए उच्च आत्मविश्वास बार (95 प्रतिशत या अधिक) और स्केलिंग जैसी गैर-विनाशकारी कार्रवाइयों के लिए निचली सीमा (85 प्रतिशत) सेट करें।
- मानवीय निरीक्षण बनाए रखें. ऑटो-रेमेडियेशन को हमेशा क्रियाएं लॉग करनी चाहिए और मनुष्यों को सूचित करना चाहिए। फेलओवर जैसी महत्वपूर्ण कार्रवाइयों के लिए ऊंचे आत्मविश्वास या स्पष्ट मानवीय अनुमोदन की आवश्यकता होनी चाहिए।
- मॉडलों को नियमित रूप से पुनः प्रशिक्षित करें। डेटाबेस वर्कलोड पैटर्न एप्लिकेशन परिवर्तनों के साथ विकसित होता है। विसंगति का पता लगाने वाले मॉडलों को कम से कम साप्ताहिक रूप से पुनः प्रशिक्षित करें, या लगातार अनुकूलित होने वाली ऑनलाइन शिक्षा लागू करें।
- पहले स्टेजिंग में परीक्षण निवारण। प्रत्येक ऑटो-रेमेडिएशन वर्कफ़्लो को उत्पादन में सक्षम करने से पहले अराजकता इंजीनियरिंग परिदृश्यों के साथ एक स्टेजिंग वातावरण में मान्य किया जाना चाहिए।
- एकाधिक एमएल दृष्टिकोणों को संयोजित करें। कोई भी एकल एल्गोरिदम सभी प्रकार की विसंगतियों को नहीं संभालता है। व्यापक कवरेज के लिए पैगंबर (मौसमी), एलएसटीएम (अनुक्रमिक), और अलगाव वन (बहुभिन्नरूपी) के संयोजन के तरीकों का उपयोग करें।
- सुरक्षित LLM एकीकरण। क्वेरी विश्लेषण के लिए LLM का उपयोग करते समय, कभी भी वास्तविक डेटा मान न भेजें - केवल स्कीमा मेटाडेटा और EXPLAIN योजनाएँ। एआई टूल के लिए समर्पित रीड-ओनली डेटाबेस क्रेडेंशियल का उपयोग करें।
- फीडबैक लूप बनाएं। विसंगति का पता लगाने के लिए झूठी सकारात्मक और झूठी नकारात्मक दरों को ट्रैक करें। मॉडल सटीकता में लगातार सुधार के लिए अलर्ट प्रासंगिकता पर मानवीय प्रतिक्रिया का उपयोग करें।
निष्कर्ष
एआई-संचालित डेटाबेस समस्या निवारण प्रतिक्रियाशील अग्निशमन से सक्रिय, बुद्धिमान संचालन में एक मौलिक बदलाव का प्रतिनिधित्व करता है। समय-श्रृंखला विसंगति का पता लगाने, LLM-संचालित क्वेरी अनुकूलन, भविष्य कहनेवाला चेतावनी और स्वचालित उपचार के संयोजन से, टीमें उप-मिनट का पता लगाने, झूठी अलर्ट में नाटकीय कमी और समाधान के लिए औसत समय में महत्वपूर्ण सुधार प्राप्त कर सकती हैं। कुंजी क्रमिक रूप से निर्माण कर रही है - मीट्रिक संग्रह और डैशबोर्ड से शुरू करें, विसंगति का पता लगाने में परत लगाएं, फिर सिस्टम में विश्वास बढ़ने पर उत्तरोत्तर ऑटो-रेमेडिएशन सक्षम करें। चाहे आप MySQL, PostgreSQL, MongoDB, Redis, या Couchbase का प्रबंधन कर रहे हों, AI-संचालित दृष्टिकोण सार्वभौमिक रूप से लागू होता है, जो आपके संपूर्ण डेटा स्तर पर एकीकृत अवलोकन अनुभव प्रदान करते हुए प्रत्येक इंजन की अद्वितीय विशेषताओं को अपनाता है।