Մոնիթորինգ, alerting և backup-ներ

01Մետրիկաներ, լոգեր և trace-եր՝ մեկ համակարգի երեք տեսանկյուն

Մետրիկաները ժամանակի ընթացքում թվեր են՝ վայրկյանում հարցումներ, սխալների մակարդակ, պատասխանի ժամանակ, CPU, ազատ դիսկ, հերթի երկարություն։ Դրանք էժան են պահել և կատարյալ են dashboard-ների և alert-ների համար, բայց ասում են, որ ինչ-որ բան սխալ է, ոչ թե կոնկրետ ինչ։ Լոգերը մանրամասներով, timestamp-ով իրադարձություններ են՝ այս հարցումը, այս օգտատերը, այս exception-ը և stack trace-ը։ Դրանք պատասխանում են, թե ինչ է պատահել, բայց մեծ մասշտաբով որոնելը թանկ է, ուստի դրանք կառուցվածքավորիր որպես JSON՝ հետևողական դաշտերով։ Trace-երը հետևում են մեկ հարցմանը service-ների միջով՝ API կանչ, բազայի query-ներ, վճարման մատակարարին կանչ, յուրաքանչյուրը իր տևողությամբ, այնպես որ տեսնում ես, թե ուր է գնացել ժամանակը։ OpenTelemetry-ն vendor-ից անկախ ստանդարտ է բոլոր երեքն արտադրելու համար։ Սկսիր մետրիկաներից և լոգերից, իսկ tracing ավելացրու, երբ ունենաս մի քանի իրար հետ խոսող service-ներ։

• Մետրիկաներ՝ առողջ է՞ (ագրեգացված թվեր)
• Լոգեր՝ կոնկրետ ի՞նչ է պատահել (առանձին իրադարձություններ)
• Trace-եր՝ որտե՞ղ է այս հարցումը ծախսել իր ժամանակը (մեկ հարցում, բազմաթիվ hop-եր)

02Prometheus, Grafana և Loki

Prometheus-ը time-series տվյալների բազա է, որը մի քանի վայրկյանը մեկ HTTP-ով քաշում (scrape է անում) մետրիկաները target-ներից։ Exporter-ները մետրիկաներ են տրամադրում այն բաների համար, որոնք դու չես գրել՝ node_exporter՝ CPU-ի, հիշողության և դիսկի համար, postgres_exporter՝ բազայի համար, իսկ քո սեփական հավելվածը կարող է բացել /metrics endpoint։ Հարցումներ ես անում PromQL-ով և սահմանում alert կանոններ․ այնուհետև Alertmanager-ը խմբավորում է, կրկնօրինակները հեռացնում և այդ alert-ներն ուղղորդում email, Slack կամ pager։ Grafana-ն dashboard-ներ է նկարում Prometheus-ի և շատ այլ աղբյուրների վրա։ Loki-ն լոգերն էժան է պահում՝ index անելով միայն label-ները, ինչպիսիք են app-ը, environment-ը և level-ը, ոչ թե ամբողջ տեքստը, իսկ Grafana Alloy-ը collector է, որը լոգերն ու մետրիկաները ուղարկում է դրան։ Միասին դրանք տալիս են self-hosted stack, որը հանգիստ աշխատում է Docker Compose հավելվածի կողքին։

1groups:
2  - name: host
3    rules:
4      - alert: DiskAlmostFull
5        expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.15
6        for: 15m
7        labels: { severity: warning }
8        annotations:
9          summary: "Less than 15% disk left on {{ $labels.instance }}"
10      - alert: HighErrorRate
11        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
12        for: 10m
13        labels: { severity: critical }

03Uptime check-եր, error tracking և alert-ներ, որոնք spam չեն անում

Uptime check-ը քո կայքը ստուգում է դրսից, ամեն րոպե, այնպես, ինչպես օգտատերը կաներ․ արդյո՞ք գլխավոր էջը վերադարձնում է 200, արդյո՞ք TLS սերտիֆիկատը վավեր է ևս երկու շաբաթից ավելի, արդյո՞ք health endpoint-ը հաստատում է, որ բազան պատասխանում է։ Uptime Kuma-ի նման գործիքները կարելի է self-host անել, իսկ hosted checker-ները ստուգում են մի քանի տարածաշրջանից։ Error tracking-ը (Sentry՝ վեբի և backend-ի համար, Firebase Crashlytics՝ mobile-ի համար) խմբավորում է exception-ներն ու crash-երը, ցույց է տալիս stack trace-ը, release-ը և տուժած օգտատերերին։ Alert-ների համար մարդուն page արա միայն այն ախտանիշների համար, որոնք զգում են օգտատերերը (կայքը չի աշխատում, սխալների մակարդակը բարձր է, checkout-ը ձախողվում է), իսկ պատճառները, օրինակ՝ բարձր CPU-ն, ուղարկիր dashboard կամ ցածր առաջնահերթության ալիք։ Պահանջիր, որ պայմանը տևի մի քանի րոպե՝ նախքան alert-ը կաշխատի, խմբավորիր կապված alert-ները, և յուրաքանչյուր alert պետք է հղում ունենա runbook-ի, որը բացատրում է, թե ինչ ստուգել առաջինը։

• Alert արա ախտանիշների վրա, ուսումնասիրիր պատճառները։
• Յուրաքանչյուր page պետք է գործողության կոչ լինի․ եթե ոչ ոք չպետք է գործի, դա page չէ։
• Ամեն ամիս վերանայիր աղմկոտ alert-ները և ջնջիր կամ կարգավորիր դրանք։

04Backup-ներ՝ 3-2-1 կանոնը, snapshot-ներ ընդդեմ իրական backup-ների

3-2-1 կանոնը՝ պահիր քո տվյալների երեք պատճեն, երկու տարբեր տեսակի կրիչների վրա, որից մեկ պատճենը՝ off-site։ Ժամանակակից ընդլայնումը ավելացնում է մեկ պատճեն, որն անփոփոխ (immutable) է կամ offline, որպեսզի ransomware-ը կամ գողացված admin key-ը չկարողանան այն ջնջել, և զրո սխալ՝ ստուգված restore-ից հետո։ Մատակարարի snapshot-ը պատճենում է ամբողջ դիսկը ժամանակի որոշակի պահին։ Դրանով ամբողջ սերվերը արագ է վերականգնվում, բայց այն սովորաբար ապրում է մատակարարի նույն account-ում, իսկ աշխատող բազայի snapshot-ը կարող է անհետևողական լինել։ Իրական backup-ը հետևողական, հավելվածի մակարդակի պատճեն է, օրինակ՝ pg_dump-ի կամ mysqldump-ի արդյունքը՝ գումարած վերբեռնված ֆայլերը, որը պահվում է այլ տեղ և գաղտնագրված է։ Օգտագործիր երկուսն էլ՝ snapshot-ներ՝ ամբողջ սերվերի արագ վերականգնման համար, տրամաբանական backup-ներ՝ տվյալների ճշգրիտ, տեղափոխելի restore-ի համար։

1#!/usr/bin/env bash
2set -euo pipefail
3STAMP=$(date +%F_%H%M)
4pg_dump -Fc -U app appdb > /backups/appdb_$STAMP.dump
5 
6# encrypted, deduplicated, off-site copy (S3-compatible storage)
7export RESTIC_REPOSITORY=s3:https://s3.example.com/your-backup-bucket
8restic backup /backups /var/www/app/shared/storage
9restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
10restic check

05Restore-ների թեստավորում, RPO և RTO

Երկու թիվ է սահմանում backup-ի ռազմավարությունը, և դրանք պետք է համաձայնեցվեն բիզնեսի հետ, ոչ թե գուշակվեն ինժեներների կողմից։ RPO-ն՝ recovery point objective, այն է, թե որքան տվյալ կարող ես թույլ տալ կորցնել՝ չափված ժամանակով․ գիշերային dump-երի դեպքում քո RPO-ն մինչև 24 ժամ է, իսկ շարունակական WAL archiving-ի կամ binlog shipping-ի դեպքում կարող է լինել րոպեներ։ RTO-ն՝ recovery time objective, այն է, թե որքան կարող ես չաշխատել վերականգնման ընթացքում։ Ապա ապացուցիր, որ կարող ես դրանց հասնել։ Ժամանակացույցով վերականգնիր վերջին backup-ը փորձնական բազայի կամ ժամանակավոր սերվերի մեջ, գործարկիր մի քանի ստուգիչ query, ստուգիր, որ վերբեռնված ֆայլերը բացվում են, և չափիր ամբողջ պրոցեսի ժամանակը։ Քայլերը գրի առ որպես runbook, որպեսզի թիմի ցանկացած անդամ կարողանա դա անել սթրեսի տակ։

1# monthly restore drill into a throwaway database
2createdb restore_test
3pg_restore --no-owner -d restore_test /backups/appdb_latest.dump
4psql -d restore_test -c "SELECT count(*), max(created_at) FROM orders;"
5dropdb restore_test

06SLI, SLO, error budget և burn rate-ի վրա հիմնված alert-ներ

Ծառայության մակարդակի ցուցանիշը (SLI) լավ իրադարձությունների չափված հարաբերությունն է բոլոր իրադարձություններին, օրինակ՝ այն հարցումների բաժինը, որոնց հաջողությամբ պատասխանվել է 500 մվ-ից արագ։ Ծառայության մակարդակի նպատակը (SLO) դրա թիրախն է որոշակի պատուհանում, ասենք՝ 99.9% 30 օրվա ընթացքում։ Մնացած 0.1%-ը error budget-ն է՝ ամսական մոտ 43 րոպե ամբողջական անջատում կամ ավելի երկար ժամանակահատված՝ մասնակի սխալներով։ Ֆիքսված սխալների տոկոսի վրա alert դնելու փոխարեն alert դիր այն բանի վրա, թե որքան արագ է «այրվում» բյուջեն։ 1 burn rate-ը ամբողջ բյուջեն ծախսում է ճիշտ 30 օրում․ 14.4 burn rate-ը, եթե պահպանվում է մեկ ժամ, ուտում է ամսական բյուջեի 2%-ը և արժանի է page-ի։ Google-ի SRE workbook-ի multiwindow մոտեցումը ստուգում է երկար պատուհանը՝ համոզվելու, որ խնդիրն իրական է, և կարճ պատուհանը՝ համոզվելու, որ այն դեռ շարունակվում է, այնպես որ alert-ները արագ են միանում և արագ են անջատվում։

1# page: 2% of a 30-day 99.9% budget burned in 1 hour
2- alert: ErrorBudgetFastBurn
3  expr: |
4    (sum(rate(http_requests_total{status=~"5.."}[1h])) / sum(rate(http_requests_total[1h])) > 14.4 * 0.001)
5    and
6    (sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 14.4 * 0.001)
7  labels: { severity: page }
8  annotations: { runbook: "https://wiki.example.com/runbooks/error-budget" }

07Prometheus-ի ներսում․ series-ներ, cardinality և histogram-ներ

Prometheus-ը metric-ի անվան և label-ների արժեքների յուրաքանչյուր եզակի համակցության համար պահում է առանձին time series։ http_requests_total-ը method, route և status label-ներով կարող է տալ մի քանի հարյուր series, և դա նորմալ է։ Ավելացրու user_id կամ ամբողջական URL label, և կստանաս մեկ series յուրաքանչյուր օգտատիրոջ կամ URL-ի համար․ հիշողությունը պայթում է, query-ները սողում են։ Սա cardinality-ի խնդիրն է, և Prometheus-ը կոտրելու ամենատարածված ձևը։ Label-ները պահիր փոքր, սահմանափակ բազմություններում, իսկ բարձր cardinality ունեցող մանրամասները տար log-եր կամ trace-եր։ Latency-ի համար օգտագործիր histogram-ներ․ հավելվածը հարցումները բաշխում է bucket-ների մեջ, իսկ histogram_quantile-ը query-ի պահին գնահատում է p95-ը կամ p99-ը՝ բոլոր instance-ների վրա։ Միջին արժեքները թաքցնում են դանդաղ «պոչը», որն իրականում զգում են օգտատերերը։ Dashboard-ներում և alert-ներում օգտագործվող ծանր query-ները պետք է դառնան recording rule-եր, որոնք հաշվվում են մեկ անգամ յուրաքանչյուր ինտերվալում։ Լռելյայն Prometheus-ը պահում է 15 օր․ երկարաժամկետ պահպանումը սովորաբար գնում է Thanos, Mimir կամ hosted backend՝ remote_write-ի միջոցով։

1# p95 latency per route over 5 minutes
2histogram_quantile(0.95,
3  sum by (le, route) (rate(http_request_duration_seconds_bucket[5m])))
4 
5# recording rule: compute once, reuse in dashboards and alerts
6- record: route:http_request_duration_seconds:p95_5m
7  expr: histogram_quantile(0.95, sum by (le, route) (rate(http_request_duration_seconds_bucket[5m])))
8 
9# find the metrics with the most series
10topk(10, count by (__name__) ({__name__=~".+"}))

08Point-in-time recovery PostgreSQL-ի համար

Գիշերային dump-ը տալիս է մինչև մեկ օր RPO։ Point-in-time recovery-ն (PITR) այն իջեցնում է մինչև րոպեներ։ PostgreSQL-ը յուրաքանչյուր փոփոխություն գրում է իր write-ahead log-ում (WAL)՝ նախքան այն կիրառելը։ Եթե պահում ես պարբերական base backup՝ տվյալների դիրեկտորիայի ֆիզիկական պատճեն, գումարած դրանից հետո WAL-ի բոլոր segment-ները, կարող ես վերականգնել base backup-ը և WAL-ը «վերարտադրել» մինչև ցանկացած պահ, օրինակ՝ մեկ րոպե առաջ, քան ինչ-որ մեկը կգործարկեր DELETE առանց WHERE-ի։ Այն միացվում է archive_mode-ով և archive command-ով, որն ամեն ավարտված segment ուղարկում է սերվերից դուրս։ Գործնականում օգտագործիր հատուկ գործիք, օրինակ pgBackRest կամ WAL-G, որոնք քո փոխարեն կարգավորում են սեղմումը, գաղտնագրումը, retention-ը, զուգահեռ վերականգնումը և ստուգումը, և ամեն ինչ ուղարկում են object storage։ Վերականգնելու համար տեղադրիր base backup-ը, սահմանիր recovery_target_time և ստեղծիր recovery.signal ֆայլ։ Managed բազաները նույն հնարավորությունը տալիս են մեկ կոճակով, բայց այն միևնույն է պետք է փորձարկել։

1# postgresql.conf (with pgBackRest)
2wal_level = replica
3archive_mode = on
4archive_command = 'pgbackrest --stanza=app archive-push %p'
5archive_timeout = 60          # ship at least once a minute
6 
7# restore to just before the mistake
8pgbackrest --stanza=app --type=time \
9  --target="2026-11-05 14:31:00+00" --target-action=promote restore

09Հենց backup-ների պաշտպանությունը

Ժամանակակից ransomware-ը և չարամիտ insider-ները առաջինը թիրախավորում են backup-ները, ուստի ենթադրիր, որ սերվերի credential-ներն ունեցող հարձակվողը կփորձի ջնջել դրանք։ Երեք պաշտպանություն աշխատում են միասին։ Առանձին credential-ներ․ սերվերը պետք է կարողանա նոր backup-ներ ավելացնել, բայց ոչ հները ջնջել։ restic-ի rest-server-ն ունի append-only ռեժիմ, իսկ object storage-ը կարող է տալ գրելու իրավունք առանց ջնջելու։ Անփոփոխելիություն․ S3 Object Lock-ը (այն առաջարկում են նաև մի քանի S3-համատեղելի մատակարարներ) object-ները պահում է write-once ռեժիմում retention-ի ժամկետով․ compliance ռեժիմում ոչ ոք, նույնիսկ account-ի root-ը, չի կարող այն կրճատել։ Անկախ մոնիթորինգ․ dead man's switch-ը սպասում է ping յուրաքանչյուր հաջող backup-ից հետո և alert է ուղարկում, երբ այն բացակայում է, ինչը բռնում է «լուռ» կոտրված cron job-երը։ Գաղտնագրման key-ը կամ գաղտնաբառը պահիր սերվերից առանձին, օրինակ՝ password manager-ում, որովհետև առանց key-ի գաղտնագրված backup-ը պարզապես աղմուկ է։

1# bucket must have versioning; lock new objects for 30 days
2aws s3api put-object-lock-configuration --bucket example-backups \
3  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'
4 
5# end of backup script: report success to a dead man's switch
6restic backup /backups && curl -fsS -m 10 --retry 3 https://hc-ping.example.com/your-check-id