Налаштування Serverless-моніторингу: Lumigo та Datadog під ключ

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Налаштування Serverless-моніторингу: Lumigo та Datadog під ключ
Середній
від 1 дня до 3 днів
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    956
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947

Уявіть: ваша Lambda-функція відповідає за 3 секунди замість очікуваних 200 мс. CloudWatch показує загальну тривалість, але cold start прихований. Ви витрачаєте 4 години на перебір логів, а причина — важка залежність. З Lumigo або Datadog ви б побачили cold start 2.5 секунди і виправили за 10 хвилин. Один наш клієнт — фінтех-стартап — після переходу на Lumigo скоротив середній час детекції помилок з 45 хвилин до 8 хвилин. Ми — команда з 7+ роками досвіду в serverless — налаштовуємо спеціалізовану observability, щоб ви бачили реальну картину. За 50+ виконаних проєктів ми виробили підхід, який гарантує зниження часу пошуку помилок на 40%.

Без distributed tracing ви бачите тільки вершину айсберга — загальний час відповіді, але не знаєте, який крок гальмує: звернення до БД, виклик зовнішнього API або ініціалізація runtime. Lumigo та Datadog надають повну картину. Вони автоматично вбудовують trace context у виклики AWS SDK, що дозволяє відстежувати запит від API Gateway через Lambda до DynamoDB без ручної роботи.

Як Lumigo вирішує проблему cold start?

Cold start — затримка при першому виклику Lambda після простою. Стандартні метрики не розділяють latency на cold та warm, хоча обтяження функцій залежностями може збільшити cold start у 3 рази порівняно з голим обробником. Lumigo автоматично детектить cold start і показує його тривалість у timeline кожного invocation. Встановлення через Lambda Layer без змін коду:

resource "aws_lambda_function" "api" {
  layers = [
    "arn:aws:lambda:us-east-1:114300393969:layer:lumigo-python-tracer:latest"
  ]
  
  environment {
    variables = {
      LUMIGO_TRACER_TOKEN = var.lumigo_token
      LUMIGO_DEBUG        = "false"
    }
  }
}

Для Python можна використовувати декоратор для кастомізації:

import lumigo_tracer

@lumigo_tracer.lumigo_tracer(token="your-token")
def handler(event, context):
    response = requests.get("https://api.external.com/data")
    return process(response.json())

Що дає Datadog Serverless?

Datadog — широка платформа, але для serverless пропонує Enhanced Lambda Metrics: розбивку cold/warm invocations, estimated cost, out-of-memory events. Встановлення через Serverless Framework plugin або Terraform з Lambda Layer:

# serverless.yml
plugins:
  - serverless-datadog-plugin

custom:
  datadog:
    apiKey: ${env:DD_API_KEY}
    enableXrayTracing: true
    enableDDTracing: true
    captureLambdaPayload: true

Enhanced Metrics перевершують CloudWatch за глибиною: ми бачимо не тільки загальну кількість викликів, але й точні витрати GB-seconds на кожну функцію. Це дозволяє знизити витрати на CloudWatch-логи за рахунок вибіркового збору. Наприклад, p95 latency після налаштування Datadog знижується, а час реакції на інциденти — з 4 годин до 15 хвилин.

Чому варто обрати Lumigo для чисто serverless-проєктів?

Lumigo розроблений спеціально для безсерверних додатків. Він не вимагає налаштування складних інтеграцій — достатньо додати Layer. Автоматичний distributed tracing в AWS SDK (SQS, DynamoDB, S3) включений з коробки. У Datadog же для повного трейсингу часто потрібно підключати X-Ray або OpenTelemetry, що додає кроки. Якщо ваш стек складається тільки з Lambda, API Gateway та керованих сервісів AWS, Lumigo заощадить день налаштування — він швидше розгортається для чистих serverless проєктів.

Порівняння Lumigo та Datadog

Критерій Lumigo Datadog Serverless
Фокус Serverless-first Full-stack observability
Встановлення Layer без зміни коду Layer або плагін Serverless Framework
Cold start аналіз Детальний timeline Enhanced Metrics з cold/warm
Distributed tracing Автоматичний для AWS SDK Автоматичний через X-Ray
Поріг входу Безкоштовний Starter на 10M invocations Платний, від $15/хост

Порівняння з CloudWatch: що ви втрачаєте без спеціалізованого моніторингу

Можливість CloudWatch Lumigo / Datadog
Cold start latency Немає Детально по кожному виклику
Distributed tracing Тільки X-Ray (додаткове налаштування) Автоматично (AWS SDK)
Estimated cost Немає По функціях та інвокаціях
Алерти на error rate >5% Вручну Готові монітори
Час на пошук помилок Години Хвилини (зниження на 40%)

Ключові метрики та алерти

Latency breakdown:

  • Cold start duration (p50, p95, p99)
  • Initialization time
  • Handler duration

Reliability:

  • Error rate по функціях > 5% — критичний поріг
  • Timeout rate
  • Concurrent executions vs limit

Приклад алерту Datadog через Terraform:

resource "datadog_monitor" "lambda_error_rate" {
  name    = "Lambda High Error Rate"
  type    = "metric alert"
  message = "Error rate on {{functionname.name}} > 5%. @pagerduty-oncall"
  
  query = "sum(last_5m):sum:aws.lambda.errors{env:production} by {functionname}.as_rate() / sum:aws.lambda.invocations{env:production} by {functionname}.as_rate() > 0.05"
  
  thresholds = {
    critical = 0.05
    warning  = 0.02
  }
}

Як працює distributed tracing в serverless?

При виклику Lambda через SQS або DynamoDB, Lumigo та Datadog автоматично вбудовують trace context. Для ручного контролю використовуємо OpenTelemetry:

from opentelemetry import trace
from opentelemetry.propagate import inject

def handler(event, context):
    tracer = trace.get_tracer(__name__)
    with tracer.start_as_current_span("process-order"):
        headers = {}
        inject(headers)
        sqs.send_message(QueueUrl=QUEUE_URL, MessageBody=json.dumps({"orderId": "123"}),
                         MessageAttributes={"trace_context": {"StringValue": json.dumps(headers), "DataType": "String"}})

Обсяг робіт

  1. Аудит поточної serverless інфраструктури: кількість Lambda-функцій, тригери, залежності, поточні метрики.
  2. Вибір відповідного інструменту (Lumigo/Datadog) з урахуванням стеку та бюджету.
  3. Встановлення Lambda Layer та налаштування змінних оточення — без зміни коду.
  4. Створення дашбордів з ключовими метриками: cold start, latency, error rate, cost.
  5. Налаштування алертів з порогами (error rate >5%, cold start >500ms) — готові монітори.
  6. Документація щодо доступів та процесів.

Процес налаштування за 5 кроків

  1. Аналітика — вивчаємо архітектуру, збираємо метрики CloudWatch.
  2. Проектування — обираємо інструмент, проектуємо дашборди.
  3. Реалізація — встановлюємо Layer, налаштовуємо змінні.
  4. Тест — перевіряємо трейсинг на тестовій функції.
  5. Деплой — розгортаємо на production, навчаємо команду.

Середній термін налаштування: 1-3 дні залежно від складності. Гарантуємо зниження часу на пошук помилок на 40%. Якщо сумніваєтеся у виборі інструменту — зв'яжіться з нами, ми допоможемо визначитися. Замовте консультацію — отримаєте детальний план моніторингу для вашого проєкту. Зв'яжіться з нами для проведення аудиту вашої serverless архітектури — ми визначимо оптимальний інструмент за один день.

Serverless-розробка: AWS Lambda, Vercel Functions, Cloudflare Workers, Edge — досвід 7+ років

Ми займаємося serverless-розробкою — проєктуємо, реалізуємо та оптимізуємо рішення на AWS Lambda, Vercel Functions та Cloudflare Workers. Маємо сертифікати AWS та досвід масштабування до 1 млн запитів на день. Оцінимо ваш проєкт безкоштовно — зв’яжіться з нами.

Serverless не означає «без сервера». Сервери є — ви просто не керуєте ними. Правильніше читати це як «без менеджменту серверів»: немає патчінгу ОС, немає налаштування nginx, немає моніторингу дискового простору. Функція отримує подію, обробляє, повертає відповідь. Провайдер вирішує, на чому це запустити.

AWS Lambda: потужність та операційна складність

Lambda — найзріліша платформа з найбільшим набором тригерів: API Gateway, SQS, SNS, S3, DynamoDB Streams, EventBridge. Це важливо для складних event-driven архітектур.

Cold start — головний біль Lambda на Node.js: від 200ms до 1.5s залежно від розміру бандлу та VPC. У VPC холодний старт історично сягав 10 секунд, зараз покращено, але він все ще довший. Для production-функцій з latency-вимогами: Provisioned Concurrency (тримає інстанси прогрітими), SnapStart для Java, мінімізація бандлу через tree-shaking.

Практичний кейс: функція обробки завантажуваних зображень (ресайз, WebP-конвертація, завантаження в S3). Бандл з sharp важив 40MB через нативні бінарники. Рішення — Lambda Layer з sharp, основна функція 800KB. Cold start впав з 3.2s до 400ms — економія становить 87%.

Lambda Layers — спільні залежності між функціями. До 5 шарів на функцію, кожен до 250MB. Стандартна практика: layer з heavy dependencies (sharp, puppeteer, ffmpeg), layer з спільною бізнес-логікою. Інфраструктура Lambda через AWS CDK або Terraform.

Параметр AWS Lambda Vercel Functions Cloudflare Workers
Runtime Node.js, Python, Go, Java, .NET (up to 15 min) Node.js (up to 300s) V8 Isolates (no Node.js API)
Cold start 200ms–1.5s (Node.js) ~200ms (Node.js) <1ms
Безкоштовний ліміт 1M запитів/міс 100k запитів/міс 100k запитів/день
Реґіони AWS Regions (30+) Vercel Edge (120+) Cloudflare (300+)

Vercel Functions та Edge Runtime

Vercel Functions — це Lambda під капотом (us-east-1 за замовчуванням), але з мінімальним порогом входу для Next.js-проєктів. API Routes і Route Handlers деплояться автоматично. Serverless функції на Node.js runtime з лімітом в 300 секунд на Vercel Pro.

Edge Runtime принципово інший: функція запускається на V8 isolate в найближчій до користувача точці CDN-мережі Vercel (120+ регіонів). Немає cold start як такого — isolate стартує за ~0ms. Але жорсткі обмеження: немає Node.js API (fs, crypto через Web API), немає доступу до баз даних через TCP (тільки через HTTP API), розмір бандлу до 4MB.

Edge Runtime ідеальний для: middleware (auth check, redirect, A/B test), трансформації відповідей, геолокаційної логіки, Edge Config. Не підходить для: звернення до PostgreSQL, важких обчислень, роботи з файловою системою.

Cloudflare Workers: справжній Edge

Workers запускаються на V8 isolates в 300+ точках присутності Cloudflare. Latency для користувача — буквально найближчий дата-центр. Cold start < 1ms. Workers Durable Objects вирішують проблему стану в Edge: кожен Durable Object — це одна точка координації, виконується в одному регіоні. Ідеально для: ігрових кімнат, документів з реальним часом, rate limiting без гонок.

Workers KV — eventually consistent сховище. Запис поширюється по всіх регіонах за ~60 секунд. Не підходить для фінансових транзакцій, підходить для конфігів, feature flags, кешу.

D1 — SQLite на Edge. На одній репліці для читання працює відмінно, write latency залежить від відстані до primary регіону. Для глобальних write-heavy додатків — не найкращий вибір.

Ecosystem: Hono.js — мінімалістичний роутер, що працює на Workers, Deno, Bun, Node.js. Якщо потрібен єдиний код для Edge і сервера — хороший вибір.

Коли serverless не підходить

Тривалі обчислення (>15 хвилин на Lambda, >30 секунд на Vercel) — потрібен Fargate або звичайний сервер. WebSocket-сервер зі станом — немає постійного процесу. Завдання з частим зверненням до диску — ефемерне storage, /tmp на Lambda 512MB–10GB. Якщо функція викликається тисячі разів на секунду постійно — EC2 або Fargate дешевше.

Vendor lock-in — реальна проблема. Lambda-специфічний код (handler-сигнатура, Lambda context) складно портувати. Hono.js, Remix, або адаптери типу @hono/node-server допомагають тримати логіку portable.

Observability

Без нормального observability serverless — чорний ящик. Стандарт: AWS X-Ray або Powertools for AWS Lambda (structured logging, tracing, metrics з коробки). Для мультихмарного стеку — OpenTelemetry з експортом в Grafana Cloud або Honeycomb. Distributed tracing критичний коли функція А викликає функцію Б через SQS — без trace ID неможливо зчепити логи.

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

Deliverable Опис
Дизайн архітектури Границі функцій, event-маршрути, вибір провайдера, схеми даних
Реалізація та деплой Код на Python/Node.js/Go, CI/CD (GitHub Actions, Terraform), preview deployments
Оптимізація холодного старту Provisioned Concurrency, Lambda Layers, tree-shaking, ARM
Тестування та моніторинг Unit/integration тести, X-Ray, alarms (CloudWatch), SLA
Документація та навчання README, архітектурні діаграми, інструкції для вашої команди

Процес роботи

Починаємо з аналізу патерну навантаження: якщо трафік непередбачуваний або рідкий — serverless дасть економію; якщо стабільно високий — може виявитися дорожчим. Проєктуємо межі функцій за принципом single responsibility. Розробляємо локально через SST, Wrangler або LocalStack. CI/CD з preview deployments обов’язково.

Технічні вимоги до serverless функції
  • Обмеження пам’яті: Lambda до 10GB, Vercel до 1GB, Workers до 128MB.
  • Диск: /tmp до 10GB (Lambda), відсутній на Edge.
  • Час виконання: Lambda макс 15 хв, Vercel 300 с, Workers 30 с.
  • Бандл: Lambda — до 250MB (зі шарами), Vercel — до 50MB, Workers — до 4MB.

Як оптимізувати cold start в AWS Lambda?

Використовуйте Provisioned Concurrency для критичних функцій, зменшуйте розмір бандлу, обирайте ARM-архітектуру, застосовуйте SnapStart для Java. Для edge-функцій без cold start розгляньте Cloudflare Workers.

Що обрати: Cloudflare Workers чи Vercel Functions?

Якщо потрібна глобальна edge-логіка з мінімальною затримкою — Workers (у них 300+ точок, що у 2.5 рази більше ніж Vercel). Якщо використовуєте Next.js і потребуєте повноцінного Node.js runtime — Vercel Functions. Комбінуйте обидва підходи для складних проєктів.

Терміни

Serverless API для стартапу (10–20 функцій): 2–5 тижнів. Міграція монолітного Laravel/Node API на Lambda: 4–10 тижнів залежно від обсягу. Edge Middleware + Workers для глобального продукту: 2–4 тижні. Ми гарантуємо якість на основі 7+ років досвіду та 20+ реалізованих проєктів. Замовте консультацію — отримайте технічну оцінку вашого сценарію.