Рубрика «observability»

Все, кто работал c k8s, знают: что такое CNI, разбираются как его подключить и даже поверхностно могут понимать какой из предлагаемых на «рынке» интерфейсов лучше подходит под определенный кейс. Но между поверхностными абстракциями и пониманием того, что фактически происходит с пакетом пропасть. Пока кластер функционирует стабильно эта пропасть не мешает. Она стреляет, когда начинается полтергейст: пакеты теряются между нодами, latency скачет через раз, NetworkPolicy «отказывается работать», но по всем кажущимся метрикам все зеленое.

В этой статье я постараюсь пройти путь пакета руками:

Боль

Если вы держите on‑prem кластер на десятки или сотни нод, дальше можно не объяснять. Обновили CNI, или ядро, или драйвер сетевой карты, или просто переехали частью нод в новый сегмент. Проходит какое‑то время, и начинают капать тикеты: «у нас иногда таймаутит между подами», «DNS иногда не резолвится», «health‑check то падает, то нет».

Читать полностью »

Сначала контекст. Я делаю внутреннего read-only агента для инфраструктурных расследований: он может читать данные, но не изменять production. Инженер пишет ему в Mattermost или резервном web-чате обычный вопрос: «почему сервис отдаёт 502?», «кто выкатил эту версию?» или «что изменилось перед инцидентом?». Агент сам собирает данные из Kubernetes, VictoriaMetrics, Elasticsearch, GitLab, Grafana, GSLB и других эксплуатационных источников, а затем возвращает ответ с доказательствами и явно перечисленными пробелами.

Читать полностью »

Привет. Я делаю онлайн-сервис для скачивания видео, бэкенд на Python (FastAPI + yt-dlp). За месяц набрали ~1500 DAU и упёрлись в проблему: пользователи жалуются на «не работает», а в админке зелёные графики. История о том, как сделать видимыми ошибки, которые молча умирали в логах воркера, и почему первый же релиз пришлось переделывать из-за alert-fatigue.

TL;DR

  1. У нас 3 ноды: master (FastAPI на :443) и 2 worker’а (Docker, yt-dlp). Воркеры падали в unavailable / private / age-restricted, но эти ошибки никогда не доходили до админки — они умирали в docker logs, где их никто не читал.

  2. Сделали bridge: воркер POST’ит ошибку в master по Читать полностью »

Всем привет. В этой статье будет много текста, мало цифр с пруфами, пока что более поверхностный разбор, но я думаю тем кто упустил GrafanaCON 2026 это будет интересно.

Маленький спойлер для начала

У вас есть Grafana. Она показывает графики с Prometheus. Prometheus скрейпит метрики с ваших сервисов. Если сервис упал — вы видите красный на дашборде. Если Prometheus упал — вы не видите ничего. Дашборд замирает на последних известных значениях. Если не знать, что Prometheus лежит, можно час смотреть на «зелёный» дашборд, который на самом деле показывает данные часовой давности.

Это не гипотетика. Я видел это дважды. Первый раз — Prometheus съел диск на мониторинг-сервере (да, Prometheus хранит данные на диске, и этот диск тоже может закончиться). Второй раз — kubelet убил pod с Prometheus из-за OOM, а Pod Disruption Budget не был настроен.

Читать полностью »

В современных Data-driven компаниях Kafka называют «центральной нервной системой» данных. Но даже идеально настроенный кластер может стать причиной Data Loss, если конфигурация инфраструктуры не синхронизирована с реальностью бизнес-потоков. В этой статье я поделюсь кейсом из практики Platform Engineer: как неочевидный конфликт настроек приводил к потерям данных и как я решил это, внедрив метрику «Data Safety Window».

Проблема: «Дырки» в данных при плановых работах

Читать полностью »

Привет! Я Никита, Staff-инженер в крупном финтехе. В этой статье я хочу поделиться нашим опытом построения системы observability. Мы прошли путь от простых логов до сквозной трассировки, и я покажу, как это работает на фронтенде.

TL;DR: В статье разбираем опыт внедрения OpenTelemetry в крупном финтех-проекте.
Проблема: Логи без контекста не позволяют быстро найти причину 500-й ошибки в распределенной системе.
Решение: Сквозная трассировка (Distributed Tracing) от фронтенда до бэкенда.
Что внутри: Реализация CompositeLogger на TypeScript, патчинг fetchЧитать полностью »

Я Go-разработчик из крупной Bigtech-компании и один из основателей ИИ-помощника по налаживанию отношений Ближе. По сути это телеграм-бот, который принимает вопрос от пользователя по long-polling модели, обогащает его промтом, идёт в LLM, получает ответ, отправляет обратно пользователю. Контекст диалога и пользователи хранятся в Postgres, всего один инстанс приложения на Go, также cron, который отправляет уведомления с просьбой оставить обратную связь о продукте. Docker Compose для запуска нескольких контейнеров.

Читать полностью »

Есть типичная боль: ты вроде всё сделал правильно — контейнеры поднялись, API отвечает, UI открывается… а потом оказывается, что “не работает”. Причём не “сломано в пепел”, а именно “почти”: где-то 404, где-то таймаут, где-то UI открывается, но вкладки пустые, где-то один запрос проходит, другой — молчит.

И самое неприятное: когда начинаешь чинить “по ощущениям”, можно потратить часы, а потом выяснить, что причина была не в коде, а в порте, origin, IPv6, миграциях или в том, что UI ходит не туда.

Я перестал спорить с реальностью и сделал себе простой подход evidence-first:


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js