Тек ҚР

Ақша сомасы: 0

Өтінімдер саны: 0

Тапсырыс беруші
... дейн шешім қабылдау

09.09.25

Марапаттау нысаны

Возможность трудоустройства в компании

Өнім күйі

Дайын өнім

Тапсырма түрі

Задачи ИКТ

Сфера применения

Медиасфера

Область задачи

Заттар интернеті

Өнім түрі

БҚ/АЖ

Потоковая аналитика логов

Мәселенің сипаттамасы

Функциональные требования Сбор и нормализация Приём логов из 3 источников (HTTP Ingest + Kafka Topic + локальные файлы для backfill). Приведение timestamp к единому формату UTC, корректная обработка задержек/опоздавших событий (late events window настраиваемая). Унификация полей (service, env, level, traceId, message, meta{}). Обогащение Джойнить события с реестром сервисов (service → owner, oncall, критичность). Георезолвинг IP → страна/регион (можно локальный geo‑db файл). Детекция инцидентов Минимум два метода: (a) пороговые правила (например, ERROR‑rate > X% за Y минут), (b) статистическая аномалия (z‑score или EWM‑дисперсия) по количеству событий/латентности. Генерация «инцидента» с атрибутами (id, нач.время, сервис, метрика, доказательства, статус: open/resolved). Поиск и хранение Индексирование логов (полнотекст + фильтры по полям). Допустимы Elasticsearch/OpenSearch/SQLite FTS/Whoosh — выбор аргументируйте. Ретеншн‑политика (горячее/холодное хранение): горячие 3 дня, холодные 30 дней (эмулируйте). API и UI (минимально) REST/gRPC для: (a) ingest (для теста), (b) поисковых запросов, (c) списка инцидентов, (d) закрытия инцидента. Простейшая веб‑страница поиска (поисковая строка, фильтры service/env/level, пагинация, просмотр деталей события). Надёжность Идемпотентный приём (dedup по traceId+ts или hash(message)). Обработка пиков/бэкпрешсур: очереди/буфер, ретраи с экспоненциальной задержкой. Нефункциональные требования Производительность: ≥ 10 000 событий/сек на обычной машине (обоснуйте замеры и упрощения). Задержка от приёма до поиска: P95 ≤ 2 секунды при 5k evt/s. Надёжность: не терять события при рестарте одного воркера (демонстрация через локальный персистентный буфер). Наблюдаемость: метрики (ingest rate, lag, error rate), health‑эндпойнт, структурированные логи самого сервиса. Ограничения и вводные Язык и стек: [ЗАМЕНИТЕ ПО ФОТО] (по умолчанию: Go/Java/Python + Kafka + любой поисковый движок). Развёртывание: Docker Compose или Kubernetes (minikube/kind). CI — [ЗАМЕНИТЕ ПО ФОТО]. Без внешних платных сервисов. Данные для теста Сгенерируйте симулятор 3 сервисов: checkout, catalog, auth (разные уровни ERROR/latency). Добавьте шум и опоздавшие события (до 90 секунд). Приложите 1–2 файла с логами (JSON/CEF), образец HTTP ingest. Что предоставить (Deliverables) Архитектурная схема (диаграмма потоков данных, очереди, индексация, компоненты). Репозиторий с кодом, Dockerfile, docker‑compose/k8s манифесты. README с шагами запуска, параметрами и профилированием производительности. Набор тестов (юнит + нагрузочные/скрипт генерации событий). Короткое тех.обоснование выбора хранилища поиска, окна опоздания, дедупликации. Критерии оценки (рубрика) Архитектура и масштабируемость — 30% Качество кода и тестов — 20% Наблюдаемость и эксплуатация — 15% Корректность детекции инцидентов — 20% UX поиска и API‑дизайн — 10% Документация и reproducibility — 5% Бонус‑задания (опционально) Корреляция событий по traceId/spanId (упрощённый трейсинг). Инкрементальные снапшоты «горячее→холодное» с дешёвым форматом (Parquet на локальном/облачном бакете — эмуляция). Live‑алерты в Slack/Telegram (webhook‑эмулятор).

Күтілетін әсер

Архитектурная схема (диаграмма потоков данных, очереди, индексация, компоненты). Репозиторий с кодом, Dockerfile, docker‑compose/k8s манифесты. README с шагами запуска, параметрами и профилированием производительности. Набор тестов (юнит + нагрузочные/скрипт генерации событий). Короткое тех.обоснование выбора хранилища поиска, окна опоздания, дедупликации.

Жауапты тұлғаның ТАӘ

Даурен Арипов

Тапсырманың (жобаның) мақсаты мен сипаттамасы

Контекст - маркетплейс ежедневно обрабатывает миллиарды событий. Возникла проблема: разные микросервисы ведут логи в разных форматах и разных часовых поясах, а SLA мониторинга часто пропускает аномалии. Нужно построить сервис, который в реальном времени агрегирует логи, нормализует их, выявляет инциденты и предоставляет быстрый полнотекстовый поиск. Цель - спроектировать и реализовать минимально жизнеспособный продукт (MVP) потоковой аналитики логов с триггерами инцидентов и API/интерфейсом для поиска.