Перевод статьи директора по инфраструктуре @Synthesio — крик души про усталось от алертов и боль от не cloud-ready мониторинга.
В прошлом году я и мой коллега Гийом провели два авральных месяца, когда только мы вдвоем остались на поддержке. Мы отработали более 300 часов сверхурочно, что в 4 раза больше обычного и вдвое больше по сравнению с самым загруженным месяцем с тех пор как мы работаем в компании.
Читать полностью »
Это перевод обзора статьи «Gorilla: A fast, scalable, in-memory time series database» Pelkonen et al. VLDB 2015
Чуваки из фейсбука сделали высокопроизводительный движок для мониторинговых данных. Мне понравился обзор этой статьи в блоге "The morning paper" — особенно про алгоритмы сжатия, и вот перевод.
Стиль — авторский.
Количество ошибок на одном из серверов Facebook зашкаливало. Читать полностью »
Я уже рассказывал про мониторинг запросов postgresql, в тот момент мне казалось, что я полностью разобрался, как postgresql работает с различными ресурсами сервера.
При постоянной работе со статистикой по запросам постгреса мы начали замечать некоторые аномалии. Я полез разбираться, заодно очередной раз восхитился понятностью исходного кода постгреса:)
Под катом небольшой рассказ о неочевидном поведении postgresql.
Это перевод обзора статьи «MemC3: Compact and Concurrent MemCache with Dumber Caching and Smarter Hashing» Fan et al. в Proceedings of the 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI’13), pdf тут
Чуваки (бывший гугловец, чувак из университета Карнеги Меллон и еще один из Интел лабс) сделали улучшенный Memcached-совместимый кеш (по факту просто допилили мемкеш), и у них классные результаты производительности. Мне очень понравился обзор этой статьи в блоге "The morning paper" — описание алгоритмов и прочее.
Мы наконец допинали функционал мониторинга elasticsearch до публичного релиза. Суммарно мы переделывали его три раза, так как результат нас не устраивал и не показывал проблемы, которые мы огребали на нашем кластере ES.
Под катом история про наш production кластер, наши проблемы и наш новый мониторинг ES.
Сейчас существует достаточно много систем для хранения и обработки метрик (timeseries db), но ситуация с агентами (софтом, который собирает метрики) сложнее. Не так давно появился telegraf, но все равно выбор не велик.
При этом практически все облачные сервисы мониторинга разрабатывают свои агенты и мы не исключение. Мотивация достаточно простая — есть много специфичных требований, которые слабо вписываются в архитектуру существующих решений.
Основные наши специфичные требования:
Под катом расскажу несколько аспектов разработки агента для сбора метрик.
В 2008 году в списке рассылки pgsql-hackers началось обсуждение расширения по сбору статистики по запросам. Начиная с версии 8.4 расширение pg_stat_statements входит в состав постгреса и позволяет получать различную статистику о запросах, которые обрабатывает сервер.
Обычно это расширение используется администраторами баз данных в качестве источника данных для отчетов (эти данные на самом деле являются суммой показателей с момента сброса счетчиков). Но на основе этой статистики можно сделать мониторинг запросов — посмотреть на статистику во времени. Это оказывается крайне полезно для поиска причин различных проблем и в целом для понимания, что происходит на сервере БД.
Я расскажу, какие метрики по запросам собирает наш агент, как мы их группируем, визуализируем, так же расскажу о некоторых граблях, по которым мы прошли.
Основным хранилищем метрик у нас является cassandra, мы используем её уже более трех лет. Для всех предыдущих проблем мы успешно находили решение, используя встроенные средства диагностики кассандры.
В кассандре достаточно информативное логгирование (особенно на уровне DEBUG, который можно включить на лету), подробные метрики, доступные через JMX и богатый набор утилит (nodetool, sstable*).
Но недавно мы столкнулись с одной достаточно интересной проблемой, и нам пришлось серьезно поломать голову, почитать исходный код кассандры, чтобы разобраться, что происходит.
Часто мониторинг сетевой подсистемы операционной системы заканчивается на счетчиках пакетов, октетов и ошибок сетевых интерфейсах. Но это только 2й уровень модели OSI!
С одной стороны большинство проблем с сетью возникают как раз на физическом и канальном уровнях, но с другой стороны приложения, работающие с сетью оперируют на уровне TCP сессий и не видят, что происходит на более низких уровнях.
Я расскажу, как достаточно простые метрики TCP/IP стэка могут помочь разобраться с различными проблемами в распределенных системах.
Использование монги в production — достаточно спорная тема.
С одной стороный все просто и удобно: положили данные, настроили репликацию, понимаем как шардировать базу при росте объема данных. С другой стороны существует достаточно много страшилок, Aphyr в своем последнем jepsen тесте сделал не очень позитивные выводы.
По факту оказывается, что есть достаточно много проектов, где mongo является основным хранилищем данных, и нас часто спрашивали про поддержку mongodb в окметр. Мы долго тянули с этой задачей, потому что сделать "осмысленный" мониторинг на порядок сложнее, чем просто собрать какие-то метрики и настроить какие-нибудь алерты. Нужно сначала разобраться в особенностях поведения софта, чтобы понять, какие именно показатели отслеживать.
Как раз про сложности и проблемы я и хочу рассказать на примере реализации мониторинга запросов к mongodb.
