מדוע התראות מסד הנתונים נשארות שקטות עד לקריסה?

מדוע התראות מסד נתונים נשארות שקטות עד לקריסה?

האם שמתם לב שמסד נתונים קורס ללא אזהרה? בדרך כלל האות הראשון הוא תלונת משתמש: "האתר לא מגיב." בשלב זה, הדיסק כבר מלא, השכפול פיגר במשך שעות, ועסקאות חסומות. אנו מיישמים מערכת התראות שמודיעה לכם 72 שעות לפני אירוע קריטי.

אנו מגדירים את מחזור החיים המלא של ניטור מדדי מסד נתונים: CPU, זיכרון, דיסק, חיבורים, שכפול, שאילתות ארוכות. אנו משתמשים ב-Prometheus, Alertmanager, Grafana. אנו משלבים התראות ב-Telegram או Slack. הכללים שלנו מכסים 15+ מדדים קריטיים עבור PostgreSQL, MySQL ו-MongoDB. התראות חיזוי באמצעות predict_linear יעילות פי 3 יותר מכללי סף פשוטים — הן נותנות לכם זמן להגיב במקום לציין קריסה. לפי תיעוד Prometheus, predict_linear מבוסס על רגרסיה לינארית. הלקוחות שלנו חווים 90% פחות זמן השבתה בהשוואה לאלה ללא ניטור פרואקטיבי, ועייפות ההתראות מופחתת ב-80% באמצעות כוונון מדויק.

הגדרת התראות Prometheus עבור PostgreSQL ו-MySQL

מדוע התראות מסד נתונים סטנדרטיות לא עובדות

ללא כללי חיזוי, אתם מגלים על בעיה כשכבר מאוחר מדי. לדוגמה, התראה "דיסק 95% מלא" היא קריסה. אבל "דיסק 75% מלא, גידול 2 GB ליום" נותן לכם 10 ימים להרחיב את האחסון. Prometheus יכול לחזות מגמות באמצעות predict_linear, אבל מעטים מגדירים זאת. טעות נפוצה נוספת היא התעלמות משכפול. פיגור של 60 שניות יכול להוביל לאובדן נתונים אם השרת הראשי נופל. אנו כוללים התראת PostgreSQLReplicationLag עם סף קריטי. עם ניסיון של למעלה מ-6 שנים בניטור מסדי נתונים ו-50+ פרויקטים מוצלחים, אנו מבטיחים התראות אמינות. הלקוחות שלנו חוסכים בממוצע $15,000 בשנה על ידי מניעת זמן השבתה.

ניטור PostgreSQL ו-MySQL עם התראות Prometheus

התקנת Exporters (Docker)

# PostgreSQL
docker run -d --name postgres_exporter \
  -e DATA_SOURCE_NAME="postgresql://monitoring:password@localhost:5432/postgres?sslmode=disable" \
  -p 9187:9187 \
  quay.io/prometheuscommunity/postgres-exporter:latest

# MySQL
docker run -d --name mysqld_exporter \
  -e DATA_SOURCE_NAME="monitoring:password@(localhost:3306)/" \
  -p 9104:9104 \
  prom/mysqld-exporter:latest

# Node Exporter
docker run -d --name node_exporter \
  --pid="host" \
  -v /:/host:ro,rslave \
  -p 9100:9100 \
  quay.io/prometheus/node-exporter:latest \
  --path.rootfs=/host

משתמש לניטור PostgreSQL (הרשאות מינימליות): # PostgreSQL docker run -d --name postgres_exporter \ -e DATA_SOURCE_NAME="postgresql://monitoring:password@localhost:5432/postgres?sslmode=disable" \ -p 9187:9187 \ quay.io/prometheuscommunity/postgres-exporter:latest # MySQL docker run -d --name mysqld_exporter \ -e DATA_SOURCE_NAME="monitoring:password@(localhost:3306)/" \ -p 9104:9104 \ prom/mysqld-exporter:latest # Node Exporter docker run -d --name node_exporter \ --pid="host" \ -v /:/host:ro,rslave \ -p 9100:9100 \ quay.io/prometheus/node-exporter:latest \ --path.rootfs=/host

כללי התראה (Prometheus Rules)

קובץ CREATE USER monitoring WITH PASSWORD 'monitoring_password'; GRANT pg_monitor TO monitoring;:

groups:
  - name: postgresql_critical
    rules:
      - alert: PostgreSQLDown
        expr: pg_up == 0
        for: 30s
        labels:
          severity: critical
        annotations:
          summary: "PostgreSQL недоступен на {{ $labels.instance }}"
      - alert: DiskSpaceHigh
        expr: |
          (node_filesystem_size_bytes{mountpoint="/var/lib/postgresql"} - node_filesystem_free_bytes{mountpoint="/var/lib/postgresql"}) / node_filesystem_size_bytes{mountpoint="/var/lib/postgresql"} * 100 > 85
        for: 5m
        labels:
          severity: warning
      - alert: DiskSpaceCritical
        expr: |
          (node_filesystem_size_bytes{mountpoint="/var/lib/postgresql"} - node_filesystem_free_bytes{mountpoint="/var/lib/postgresql"}) / node_filesystem_size_bytes{mountpoint="/var/lib/postgresql"} * 100 > 95
        for: 1m
        labels:
          severity: critical
      - alert: PostgreSQLTooManyConnections
        expr: pg_stat_activity_count / pg_settings_max_connections * 100 > 80
        for: 2m
        labels:
          severity: warning
      - alert: PostgreSQLLongRunningTransaction
        expr: pg_stat_activity_max_tx_duration{state="active"} > 600
        for: 1m
        labels:
          severity: warning
      - alert: PostgreSQLReplicationLag
        expr: pg_replication_lag > 60
        for: 2m
        labels:
          severity: critical
  - name: postgresql_warning
    rules:
      - alert: PostgreSQLLowCacheHitRate
        expr: |
          (sum(pg_stat_database_blks_hit) / (sum(pg_stat_database_blks_hit) + sum(pg_stat_database_blks_read))) * 100 < 99
        for: 10m
        labels:
          severity: warning
      - alert: HighCPUUsage
        expr: |
          100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
      - alert: LowFreeMemory
        expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100 < 10
        for: 5m
        labels:
          severity: warning
  - name: mysql_alerts
    rules:
      - alert: MySQLDown
        expr: mysql_up == 0
        for: 30s
        labels:
          severity: critical
      - alert: MySQLSlowQueries
        expr: rate(mysql_global_status_slow_queries[5m]) > 5
        for: 2m
        labels:
          severity: warning
      - alert: MySQLInnoDBBufferPoolHitRateLow
        expr: |
          (mysql_global_status_innodb_buffer_pool_read_requests - mysql_global_status_innodb_buffer_pool_reads) / mysql_global_status_innodb_buffer_pool_read_requests * 100 < 99
        for: 10m
        labels:
          severity: warning
      - alert: MySQLReplicationLag
        expr: mysql_slave_status_seconds_behind_master > 30
        for: 1m
        labels:
          severity: critical
  - name: mongo_alerts
    rules:
      - alert: MongoDBReplicationLag
        expr: mongodb_rs_member_replication_lag_seconds > 60
        for: 2m
        labels:
          severity: critical
  - name: predictive_alerts
    rules:
      - alert: DiskWillFillSoon
        expr: predict_linear(node_filesystem_free_bytes{mountpoint="/var/lib/postgresql"}[6h], 3*24*3600) < 0
        for: 1h
        labels:
          severity: warning

Alertmanager: כיצד להגדיר Telegram

# /etc/alertmanager/alertmanager.yml
global:
  resolve_timeout: 5m
route:
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: telegram-critical
  routes:
    - match:
        severity: critical
      receiver: telegram-critical
      repeat_interval: 30m
    - match:
        severity: warning
      receiver: telegram-warning
      repeat_interval: 4h
receivers:
  - name: telegram-critical
    telegram_configs:
      - api_url: "https://api.telegram.org"
        bot_token: "BOT_TOKEN"
        chat_id: -1001234567890
        message: |
          \U0001f534 *{{ .GroupLabels.alertname }}*
          {{ range .Alerts }}
          *{{ .Annotations.summary }}*
          {{ .Annotations.description }}
          Время: {{ .StartsAt.Format "15:04:05" }}
          {{ end }}
        parse_mode: "Markdown"
  - name: telegram-warning
    telegram_configs:
      - api_url: "https://api.telegram.org"
        bot_token: "BOT_TOKEN"
        chat_id: -1001234567891
        message: |
          \U000026a0 *{{ .GroupLabels.alertname }}*
          {{ range .Alerts }}{{ .Annotations.summary }}{{ end }}
        parse_mode: "Markdown"

התראות חיזוי: פי 3 טובות יותר מכללי סף

התראות חיזוי באמצעות /etc/prometheus/rules/database.yml נותנות לכם זמן להגיב: הדיסק ייגמר בעוד 3 ימים — יש לכם זמן להרחיב את האחסון. העלות של שעת השבתה אחת של מסד נתונים יכולה להיות משמעותית. ההשקעה בהגדרת ניטור מחזירה את עצמה תוך 1-2 חודשים. עם הגישה שלנו, אנו משיגים 99.9% שיעור מסירת התראות וזמן תגובה מתחת ל-5 דקות עבור התראות קריטיות.

תהליך העבודה: מבקשה ועד פריסה

1. ביקורת תשתית — אנו אוספים את סכימת מסד הנתונים, גרסאות, עומס, ומזהים צווארי בקבוק.
2. פיתוח תצורה — אנו בוחרים exporters, כללי התראה, ערוצי הודעות. אנו מגדירים ספים על סמך נתונים היסטוריים: לדוגמה, 80% CPU למשך 5 דקות — אזהרה, 95% — קריטי.
3. התקנה ותצורה — אנו פורסים את הערימה (Prometheus, Alertmanager, Grafana) ב-Docker או על שרת פיזי.
4. אינטגרציה עם Telegram/Slack/PagerDuty — אנו מגדירים תבניות הודעות, ניתוב לפי חומרה.
5. בדיקות — אנו מאלצים התראות, בודקים מסירה, מכווננים רגישות.
6. תיעוד והדרכה — אנו מעבירים הוראות וגישה.
7. תמיכה לאחר השחרור — אנו מתאימים ספים במידת הצורך, מוסיפים מדדים חדשים.

מה כלול בעבודה

• התקנה ותצורה של Prometheus + Alertmanager + Grafana.
• תצורה של exporters עבור PostgreSQL/MySQL/MongoDB.
• כתיבת מערכת כללים (קריטי, אזהרה, חיזוי).
• הגדרת התראות ב-Telegram/Slack.
• יצירת לוח מחוונים ב-Grafana עם מדדים מרכזיים (CPU, זיכרון, דיסק, חיבורים, שכפול).
• תיעוד תפעולי ותחזוקתי.
• תמיכה באחריות לאחר היישום.

לוחות זמנים ומחירים

העלות תלויה במורכבות התשתית, מספר מסדי הנתונים ודרישות ההתראות. אנו מעריכים פרויקטים לאחר תדרוך. צרו קשר — נשלח הצעה מסחרית. רוב הלקוחות מחזירים את ההשקעה תוך חודשיים על ידי מניעת אירוע גדול אחד בלבד.

אימות פונקציונליות ההתראות

לאחר התצורה, אנו שולחים התראת בדיקה דרך ה-API של Alertmanager:

curl -H "Content-Type: application/json" -d '[{"labels": {"alertname": "TestAlert", "severity": "warning"}, "annotations": {"summary": "Test alert from setup verification"}}]' http://localhost:9093/api/v1/alerts 

אנו בודקים קבלת הודעה ב-Telegram. אנו פותחים את Grafana וצופים בלוחות המחוונים.

הניסיון שלנו — למעלה מ-5 שנים בניטור תשתית, 50+ פרויקטים מיושמים. עם ניסיון של 6+ שנים ממוקדות בניטור מסדי נתונים, סיפקנו 50+ פרויקטים מוצלחים. כתבו לנו — נעזור להקים ניטור מסדי נתונים במפתח מלא תוך 1-2 ימים. קבלו ייעוץ. תחסכו בממוצע $15,000 בשנה על ידי מניעת זמן השבתה.

טעויות נפוצות בעשייה עצמית

• שוכחים משכפול — התראות רק על השרת הראשי. שכפול מפגר, נתונים אובדים.
• אין כללי חיזוי — אתם לומדים על בעיה כשהדיסק כבר מלא.
• יותר מדי התראות — אזהרה על כל דבר קטן. אנו מגדירים רק ספים משמעותיים.
• לא בודקים התראות — הבוט לא ישלח בגלל שגיאת token. אנו בודקים כל ערוץ.

אירוע אחד שנמנע חוסך סכום משמעותי. ההשקעה בהגדרת ניטור מחזירה את עצמה תוך 1-2 חודשים. הזמינו הגדרת התראות מסד נתונים ושכחו מקריסות בלתי צפויות. עם העזרה שלנו, זמן ההשבתה יורד ב-90% ורעש ההתראות ב-80%.