Skip to content

Latest commit

 

History

History
39 lines (22 loc) · 5.72 KB

monitoring.russian.md

File metadata and controls

39 lines (22 loc) · 5.72 KB

Мониторинг!



Объяснение в один абзац

На самом базовом уровне мониторинг означает, что вы можете легко определить, когда на производстве происходят плохие вещи. Например, получая уведомления по электронной почте или Slack. Задача состоит в том, чтобы выбрать правильный набор инструментов, который удовлетворит ваши требования, не нарушая ваш банк. Позвольте мне начать с определения базового набора метрик, которые необходимо отслеживать для обеспечения работоспособного состояния - ЦП, ОЗУ сервера, ОЗУ процесса узла (менее 1,4ГБ), количество ошибок в последнюю минуту, количество перезапусков процесса, среднее время ответа. Затем перейдите к некоторым дополнительным функциям, которые вам могут понравиться, и добавьте их в свой список пожеланий. Некоторые примеры функции мониторинга класса "люкс": профилирование БД, межсервисное измерение (то есть измерение бизнес-транзакций), интеграция с внешним интерфейсом, предоставление необработанных данных для пользовательских клиентов BI, уведомления Slack и многие другие.

Для реализации расширенных функций требуется длительная настройка или покупка коммерческого продукта, такого как Datadog, NewRelic и тому подобное. К сожалению, достижение даже базовых знаний - это не прогулка в парке, поскольку некоторые метрики связаны с аппаратным обеспечением (ЦП), а другие живут в процессе узла (внутренние ошибки), поэтому все простые инструменты требуют некоторой дополнительной настройки. Например, решения мониторинга облачных поставщиков (например, AWS CloudWatch, Google StackDriver) скажут вам непосредственно о метриках оборудования, но не о внутреннем поведении приложения. С другой стороны, решениям на основе журнала, таким как ElasticSearch, по умолчанию не хватает аппаратного представления. Решение состоит в том, чтобы дополнить ваш выбор отсутствующими метриками, например, популярным выбором является отправка журналов приложений в Elastic stack и настройка некоторого дополнительного агента (например, Beat) для обмена информацией об оборудовании, чтобы получить полную картину.



Пример мониторинга: панель инструментов AWS cloudwatch по умолчанию. Трудно извлечь метрики в приложении

AWS cloudwatch default dashboard. Hard to extract in-app metrics



Пример мониторинга: панель мониторинга по умолчанию для StackDriver. Трудно извлечь метрики в приложении

StackDriver default dashboard. Hard to extract in-app metrics



Пример мониторинга: Grafana как слой пользовательского интерфейса, который визуализирует необработанные данные

Grafana as the UI layer that visualizes raw data



Что говорят другие блоггеры

Из блога Rising Stack:

… Мы рекомендуем вам смотреть эти сигналы для всех ваших услуг: Частота ошибок: потому что ошибки связаны с пользователем и сразу же влияют на ваших клиентов. Время отклика: потому что задержка напрямую влияет на ваших клиентов и бизнес. Пропускная способность: трафик помогает вам понять контекст повышенной частоты ошибок и задержки. Нагрузка: говорит о том, насколько "нагружен" ваш сервис. Если загрузка процессора составляет 90%, может ли ваша система обрабатывать больше трафика? ...