Налаштування кастомних метрик та алертів (Prometheus / CloudWatch)

Уявіть: ваш інтернет-магазин втрачає замовлення, але метрики CPU та пам'яті в нормі. Де шукати проблему? Ми зіткнулися з таким кейсом: клієнт скаржився на повільне завантаження сторінки кошика. Після впровадження кастомних метрик ми виявили, що час відповіді від платіжного шлюзу перевищував 5 секунд при навантаженні. Стандартні метрики цього не показували. Кастомні метрики — єдиний спосіб побачити реальну поведінку додатку. Без них ви сліпі: інцидент може коштувати до 10% виручки за годину простою. У цій статті розберемо, які метрики варто кастомізувати, як їх налаштувати в Prometheus та CloudWatch, і скільки часу займає інтеграція. Понад 5 років досвіду в моніторингу та 50+ проектів підтверджують: кастомні метрики економлять мільйони на інцидентах.

Які метрики кастомізувати в першу чергу?

Бізнес-метрики: кількість створених замовлень на хвилину, конверсія checkout воронки, активні користувацькі сесії. Технічні метрики: розмір черги обробки задач, cache hit rate, час виконання конкретних операцій, кількість помилок за типом. Зовнішні залежності: latency до сторонніх API, доступність платіжного шлюзу, статус інтеграцій. Наприклад, конверсія впала з 3% до 1% — метрику conversion_rate ми б відстежували і били тривогу. Для швидкого виявлення проблем ми також моніторимо 99-й перцентиль часу відповіді та кількість помилок бази даних (N+1 query).

Як налаштувати кастомні метрики в Prometheus?

Для інструментування Python (FastAPI) використовуємо бібліотеку prometheus_client:

from prometheus_client import Counter, Histogram, Gauge from prometheus_fastapi_instrumentator import Instrumentator # Лічильник order_counter = Counter( 'orders_created_total', 'Total orders created', ['status', 'payment_method'] ) # Гістограма (для percentile) checkout_duration = Histogram( 'checkout_duration_seconds', 'Time spent in checkout process', buckets=[0.1, 0.5, 1.0, 2.0, 5.0, 10.0] ) # Gauge (поточне значення) queue_size = Gauge( 'task_queue_size', 'Current size of processing queue' ) # Використання в коді async def create_order(order_data: dict): with checkout_duration.time(): result = await process_order(order_data) order_counter.labels( status=result.status, payment_method=order_data['payment_method'] ).inc() return result 

Node.js (prom-client):

const client = require('prom-client') const httpDuration = new client.Histogram({ name: 'http_request_duration_ms', help: 'Duration of HTTP requests in ms', labelNames: ['method', 'route', 'code'], buckets: [1, 5, 15, 50, 100, 200, 500, 1000, 2000] }) app.use((req, res, next) => { const end = httpDuration.startTimer() res.on('finish', () => { end({ method: req.method, route: req.route?.path, code: res.statusCode }) }) next() }) 

Після додавання метрик не забудьте експортувати їх через /metrics endpoint та налаштувати збір у prometheus.yml.

Що обрати: Prometheus чи CloudWatch?

Prometheus дозволяє збирати метрики з частотою до 10 мс, що в 20 разів швидше, ніж CloudWatch. Однак CloudWatch зручніший для AWS-оточень. Для детального вивчення зверніться до документації Prometheus та CloudWatch.

Prometheus Rules: Recording та Alerting

Для швидких дашбордів та своєчасних сповіщень ми налаштовуємо recording та alerting rules. Recording rules попередньо обчислюють складні вирази (наприклад, job:request_errors:rate5m), що прискорює запити в Grafana. Alerting rules запускають сповіщення при перевищенні порогів. Приклад конфігурації:

groups: - name: app_slo interval: 30s rules: # Recording rule: попередньо обчислена метрика помилок - record: job:request_errors:rate5m expr: rate(http_requests_total{status=~"5.."}[5m]) # Alert: висока кількість помилок - alert: HighErrorRate expr: job:request_errors:rate5m > 0.05 for: 2m labels: severity: critical annotations: summary: "Error rate {{ $value | humanizePercentage }}" 

Alertmanager потім надсилає оповіщення в Slack, Telegram або PagerDuty. Це дозволяє реагувати за хвилини, а не години.

Як налаштувати CloudWatch Custom Metrics?

import boto3 cw = boto3.client('cloudwatch') def put_metric(name: str, value: float, unit: str = 'Count', dimensions: dict = None): metric_data = { 'MetricName': name, 'Value': value, 'Unit': unit } if dimensions: metric_data['Dimensions'] = [ {'Name': k, 'Value': v} for k, v in dimensions.items() ] cw.put_metric_data( Namespace='MyApp/Business', MetricData=[metric_data] ) # Використання put_metric('OrdersCreated', 1, 'Count', {'Environment': 'production'}) put_metric('CheckoutDuration', 0.85, 'Seconds', {'PaymentMethod': 'card'}) put_metric('QueueDepth', queue.size(), 'Count') 

CloudWatch Alarm на кастомній метриці:

resource "aws_cloudwatch_metric_alarm" "queue_depth" { alarm_name = "high-queue-depth" comparison_operator = "GreaterThanThreshold" evaluation_periods = 3 metric_name = "QueueDepth" namespace = "MyApp/Business" period = 60 statistic = "Maximum" threshold = 1000 alarm_description = "Task queue is backed up" dimensions = { Environment = "production" } alarm_actions = [aws_sns_topic.alerts.arn] ok_actions = [aws_sns_topic.alerts.arn] } 

Що входить в роботу?

Як ми налаштовуємо моніторинг за 3-7 днів?

Ми проходимо етапи: аудит поточних метрик, вибір інструменту, написання коду метрик, налаштування алертів, тестування, документація та навчання команди. На виході ви отримуєте дашборди Grafana (або CloudWatch Dashboard), оповіщення в Slack/Telegram/email та повну документацію. Гарантуємо SLA 99.9% на коректну роботу метрик. При необхідності інтегруємо з існуючими системами (PagerDuty, Opsgenie).

Покрокова інструкція: як додати першу кастомну метрику

1. Встановіть бібліотеку prometheus_client (Python) або prom-client (Node.js).
2. Створіть метрику потрібного типу (Counter, Histogram, Gauge).
3. Інструментуйте код: додайте виклики метрики в ключові точки.
4. Експортуйте метрики (наприклад, через /metrics endpoint).
5. Налаштуйте збір метрик в Prometheus (додайте job у prometheus.yml).

Чек-лист: що потрібно для налаштування

• Встановлений Prometheus або доступ до AWS CloudWatch
• Бібліотеки для інструментування
• Доступ до коду додатку
• Налаштований Alertmanager або SNS топік

Чому кастомні метрики економлять бюджет?

Стандартні метрики (CPU, RAM) не показують бізнес-показники. Без кастомних метрик ви витрачаєте години на пошук неіснуючих проблем. Один інцидент, виявлений із запізненням на годину, може коштувати більше, ніж рік обслуговування моніторингу. Кастомні метрики дозволяють скоротити середній час виявлення (MTTD) з годин до хвилин, а отже, знизити фінансові втрати.

Замовте налаштування кастомних метрик — отримайте повний контроль над продуктивністю та бізнес-показниками вашого додатку. Зв'яжіться з нами для безкоштовної консультації — ми оцінимо ваш проект за 1 день. Понад 50 проектів з моніторингу та 5+ років досвіду гарантують результат.