Комментарии 4
Мне кажется вы используете слишком много инструментов для достижения одной цели, и каждый из них добавляет свой собственный maintenance overhead. В плане что вы говорите взять эластик для логов, егерь для apm, пром для метрик и графану для визуализации. Хотя по факту можно взять эластик для логов, его же для apm, в него же лить метрики и им же делать визуализацию. Да, придётся брать облако и подписку (либо opensearch), и часть вещей заменить не выйдет (sentry работает с ошибками куда лучше), но в итоге у вас будет единая система мониторинга с меньшим количеством точек отказа и гораздо более простой поддержкой
Ну и вы упомянули бизнес метрики рядом с техническими. По личному опыту это прямой путь в ад. Продукту проше дать ro на базу (и возможно отдельные вьюхи) и настругать event'ы на каждый чих, а дальше пусть сами берут себе airflow, metabase, tableau, хоть черта лысого - это не ваша зона ответственности, и вы не бизнес-аналитик, вы девопс. Вы просто следите чтоб эвенты капали и база жила, а продукт может крутить чего хочет
Мне кажется вы используете слишком много инструментов для достижения одной цели, и каждый из них добавляет свой собственный maintenance overhead. В плане что вы говорите взять эластик для логов, егерь для apm, пром для метрик и графану для визуализации. Хотя по факту можно взять эластик для логов, его же для apm, в него же лить метрики и им же делать визуализацию. Да, придётся брать облако и подписку (либо opensearch), и часть вещей заменить не выйдет (sentry работает с ошибками куда лучше), но в итоге у вас будет единая система мониторинга с меньшим количеством точек отказа и гораздо более простой поддержкой
Да, в целом согласен. Для небольшой собственной команды из 1-3х инженеров использовать 1 инструмент, пусть и с некоторыми ограничениями - то что надо, но мы DevOps аутсорс, мы можем выделить достаточно много времени на готовку и отладку + ожидания от нас повыше
Ну и вы упомянули бизнес метрики рядом с техническими. По личному опыту это прямой путь в ад. Продукту проше дать ro на базу (и возможно отдельные вьюхи) и настругать event'ы на каждый чих, а дальше пусть сами берут себе airflow, metabase, tableau, хоть черта лысого - это не ваша зона ответственности, и вы не бизнес-аналитик, вы девопс. Вы просто следите чтоб эвенты капали и база жила, а продукт может крутить чего хочет
Тут я больше имел в виду те бизнес метрики, которые потенциально сильно коррелируют с состоянием инфраструктуры (кол-во платежей, кол-во регистраций, кол-во входов). Метрики вроде среднего чека уже явно не наша зона, не могу не согласиться
кол-во платежей, кол-во регистраций, кол-во входов
Даже это лучше эвентами лить бизнес-аналитикам а дальше пусть сами. Иначе сходу на шею сядут
мы DevOps аутсорс
А можете плз подробнее рассказать? Или хотя бы дать ссылку на сайт/портфолио. Интересует с чем работаете (кубы, базы, kv, ёлка), какое ценообразование, sla, заключаете ли всякие baa/nda, есть ли опыт сопровождения инфраструктуры под iso27001, делаете ли обучение и т.д. Короче чем больше информации тем лучше. И главный вопрос - работаете ли с Европой (включая геморрой с платежами, английский и прочее).
Работа проделана немаленькая, где-то подсвечены некоторые интересные и в чём-то важные моменты. Только при этом есть определённые неточности, кое-где переходящие в ошибки. Своим комментарием хочу внести ясность, чтобы начинающие или уже имеющие определённый опыт специалисты Devops не совершали возможных ошибок.
Хочу начать с простенького определения Operational Excellence (OpEx) в контексте методологии Devops. Кратко можно сказать, что данная практика направлена на автоматизацию процессов, для того чтобы уменьшить фактор человеческой ошибки. Опирается на две концепции:
Operations as Code (Infrastructure as a Code)
Observability (Analytics, Metrics, Actions)
Если оставить в стороне рассмотрение Operations as Code, то Observability можно определить как создание, сбор, объединение и использование метрик, которые позволяют получить представление о состоянии системы. Грубо говоря это наши органы чувств, которые позволяют знать, как себя чувствует наша система.
Грамотная стратегия мониторинга решает три ключевые проблемы
Вообще Google говорит о четырёх золотых сигналах
Мы внедряем DevOps-практики так, чтобы ваша инфраструктура не просто «работала», а давала вам конкурентное преимущество. И делаем это без лишнего шума: наши решения интегрируются в ваши процессы, а не ломают их
Ну это как бы основное свойство практически всех систем мониторинга))
Почему мониторинг инфраструктуры не справляется с микросервисами и облаками?
Он не должен с ними никак справляться)) Да и зачем экспортёру инфраструктурных метрик лазить за данными managed services облака? Это задача специально заточенных для этого экспортёров метрик
Классический мониторинг, который фокусируется только на инфраструктурных метриках (CPU, RAM, дисковое пространство), не успевает за этими изменениями. Вот основные проблемы:
Слепота к бизнес-логике: вы знаете, что сервер «живой», но не видите, почему падает конверсия платежей или тормозит API.
Неспособность найти корень проблемы: при сбое в цепочке из 10 микросервисов метрики CPU не скажут, где именно произошла ошибка.
Аналогично тому что было в абзаце выше: мониторинг Operations параметров системы - это мониторинг физических ресурсов системы и к бизнес категориям имеет исчезающе мало отношений. Это история про Node and machine чем про Root cause, если говорить про разбор полётов микросервисов.
Ручная работа: настройка алертов для каждого сервиса отдельно — это часы рутинных задач
Иногда это часы рутинных созвонов, когда надо вытащить и выяснить на какое приложение (микросервис) и какие алерты ставить. С Operations alerts как раз всё намного проще.
Инфраструктурные метрики (Prometheus) + трейсы (Jaeger) + логи (EFK: Elastic + Fluentd + Kibana)
Prometheus - это уже не просто база данных временных рядов и не только стек для мониторинга по умолчанию рекомендуемый для Kubernetes. Это не только целая экосистема со своими экспортёрами, которые ориентированы на Operations monitoring и Operations alerts, но и система позволяющая хранить и обрабатывать метрики "бизнес-логики" и метрики "микросервисов". Очень многие вещи делает буквально из коробки. Очень легко и плотно дружит с системой отображения данных Grafana, с которой неплохо дружит Jaeger.
А вот выбор стека EFK не совсем понятен. Потому что хранить и обрабатывать 1 ТБ логов (примерно столько выдаёт на гора один стенд за неделю) в S3 bucket (в случае стека Loki + Promtail) и в Elastic вещи немного разные как по цене, так и по удобству администрирования - увеличить размер бакета на живую обходится правкой одной строки в манифесте Terraform, в случае с эластиком действий будет намного больше чем просто указания нового размера диска в том же манифесте Terraform.
Какие метрики критичны для успешного мониторинга?
Service Metrics
Reliability – mean time between failure (MTBF)
Availability – Uptime, expressed as a meaningful percentage of demand
Serviceability – Mean time to repair (MTTR)IT Metrics
Capacity
Latency
Bandwidth
Response timeStrategic Metrics
Business agility
Customer engagement
Customer reach
Financial impact
Solution performance
Особенности для микросервисов:
балансировка нагрузки (например, процент ошибок в Istio или Nginx);
статус подов в Kubernetes (количество рестартов, фейлов по readiness/liveness проб);
трассировка запросов между сервисами (Jaeger): время выполнения каждого этапа.
Для Kubernetes используйте метрику kube_pod_status_ready в Prometheus — это помогает быстро находить «битые» поды без ручного проверки логов.
Грамотный мониторинг — это не просто сбор данных, а продуманная система быстрого реагирования. Мы выстраиваем процессы так, чтобы клиенты спали спокойно даже в пиковые нагрузки
Это может выполняться только при грамотной и протестированной программной и инфраструктурной архитектуре. А так ни один мониторинг не спасёт от неработающего мастабирования при росте нагрузке и сбоев в коде приложений.
Мониторинг должен не только сообщать о проблемах, но и подсказывать, что делать. Мы настраиваем его так, чтобы ваша команда тратила время на развитие, а не на тушение пожаров.
Система мониторинга должна отвечать на два вопроса: "что сломалось" и "почему сломалось". "Что сломалось" говорит о симптоме, а "почему сломалось" о причине.
Observability — это не просто «продвинутый мониторинг», а способность системы отвечать на вопросы, которые вы даже не успели задать. Если мониторинг говорит: «Сервер упал», то observability объясняет: «Сервер упал из-за исчерпания памяти в поде Kubernetes, который обрабатывал очередь сообщений с задержкой в 5 секунд из-за проблем с сетью в облаке»
Это будущее агентов ИИ для систем мониторинга)) А пока к таким удобоваримым и понятным объяснениям надо приходить самостоятельно. И ещё потом доказывать службе поддержки облачного провайдера.
Допустим, вы видите в Grafana рост времени ответа API. Вместо ручного поиска причин, observability-стек позволяет мгновенно перейти к связанным трейсам в Jaeger и обнаружить, что 70% задержки возникают в сервисе кэширования. Анализ логов покажет, что ошибки «Connection timeout» начались после обновления версии Redis.
Звучит красиво, но обычно ни один observability-стек ничего не знает об обновлении версий Redis. Ну и анализ логов, обычно ручная операция.
Но observability — это не только инструменты, а культура работы с данными.
Можете более расширено раскрыть про культуру работы с данными (у нас их много и разных этих данных) в контексте observability?
Для настройки трейсинга можно использовать OpenTelemetry — это универсальный стандарт, который применяется даже в сложных .NET-средах.
Как быть людям на проектах без .NET-сред или с ещё более сложными средами такими как С++ или Haskell?
Эффективный мониторинг — это всегда баланс между инфраструктурой, бизнес-логикой и пользовательским опытом
Здесь надо бы добавить уточнение, чтобы было понимание.
Мониторинг White-box - Мониторинг, основанный на показателях, отображаемых внутренними компонентами системы
Мониторинг Black-box - Тестирование поведения приложения с точки зрения пользователя (тот самый пользовательский опыт и у вас в статье про него ничего нет)
P.S.
перезапуск подов в Kubernetes при превышении лимитов CPU
Kubernetes не будет перезапускать под при превышении лимитов CPU. OOMKill приходит по памяти, для CPU другая стратегия поведения. Поправьте, пожалуйста.
Эффективная стратегия мониторинга: ключевые метрики для успешного наблюдения