Как стать автором
Обновить

Компания okmeter.io временно не ведёт блог на Хабре

Сначала показывать

Kubernetes в production: сервисы

Время на прочтение 4 мин
Количество просмотров 12K

Полгода назад мы закончили миграцию всех наших stateless сервисов в kubernetes. На первый взгляд задача достаточно простая: нужно развернуть кластер, написать спецификации приложений и вперед. Из-за одержимости в вопросе обеспечения стабильности в работе нашего сервиса пришлось сразу начать разбираться с тем, как работает k8s и тестировать различные сценарии отказов. Больше всего вопросов у меня возникало ко всему, что касается сети. Один из таких "скользких" моментов — работа сервисов (Services) в kubernetes.


В документации нам говорят:


  • выкатите приложение
  • задайте liveness/readiness пробы
  • создайте сервис
  • дальше все будет работать: балансировка нагрузки, обработка отказов итд.

Но на практике все несколько сложнее. Давайте посмотрим, как оно работает на самом деле.

Читать дальше →
Всего голосов 32: ↑31 и ↓1 +30
Комментарии 4

Анатомия инцидента, или как работать над уменьшением downtime

Время на прочтение 8 мин
Количество просмотров 7.3K

Рано или поздно в любом проекте настает время работать над стабильность/доступностью вашего сервиса. Для каких-то сервисов на начальном этапе важнее скорость разработки фич, в этот момент и команда не сформирована полностью, и технологии выбираются не особо тщательно. Для других сервисов (чаще технологические b2b) для завоевания доверия клиентов необходимость обеспечения высокого uptime возникает с первым публичным релизом. Но допустим, что момент X все-таки настал и вас начало волновать, сколько времени в отчетный период "лежит" ваш сервис. Под катом я предлагаю посмотреть, из чего складывается время простоя, и как эффективнее всего работать над его уменьшением.

Читать дальше →
Всего голосов 25: ↑25 и ↓0 +25
Комментарии 13

Тонкая настройка балансировки нагрузки

Время на прочтение 22 мин
Количество просмотров 46K
В этой статье речь пойдет о балансировке нагрузки в веб-проектах. Многие считают, что решение этой задачи в распределении нагрузки между серверами — чем точнее, тем лучше. Но мы же знаем, что это не совсем так. Стабильность работы системы куда важнее с точки зрения бизнеса.



Маленький минутрый пик в 84 RPS «пятисоток» — это пять тысяч ошибок, которые получили реальные пользователи. Это много и это очень важно. Необходимо искать причины, проводить работу над ошибками и стараться впредь не допускать подобных ситуаций.

Николай Сивко (NikolaySivko) в своем докладе на RootConf 2018 рассказал о тонких и пока не очень популярных аспектах балансировки нагрузки:

  • когда повторять запрос (retries);
  • как выбрать значения для таймаутов;
  • как не убить нижележащие серверы в момент аварии/перегрузки;
  • нужны ли health checks;
  • как обрабатывать «мерцающие» проблемы.

Под катом расшифровка этого доклада.

Всего голосов 51: ↑49 и ↓2 +47
Комментарии 17

USE, RED, PgBouncer, его настройки и мониторинг

Время на прочтение 13 мин
Количество просмотров 24K
Pgbouncer USE RED

Мы начали обновлять в нашем сервисе мониторинг для PgBouncer и решили все немного причесать. Чтобы сделать всё годно, мы притянули самые известные методологии перформанс мониторинга: USE (Utilization, Saturation, Errors) Брендана Грегга и RED (Requests, Errors, Durations) от Тома Уилки.


Под катом рассказ с графиками про то, как устроен pgbouncer, какие у него есть конфигурационные ручки и как используя USE/RED выбрать правильные метрики для его мониторинга.

Читать дальше →
Всего голосов 33: ↑33 и ↓0 +33
Комментарии 0

PostgreSQL: как и почему пухнет WAL

Время на прочтение 4 мин
Количество просмотров 22K

Чтобы сделать мониторинг полезным, нам приходится прорабатывать разные сценарии вероятных проблем и проектировать дашборды и триггеры таким образом, чтобы по ним сразу была понятна причина инцидента.


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


Сегодня будем смотреть как и почему может распухать Write-Ahead Log (WAL) постгреса. Как обычно — примеры из реальной жизни в картинках.

Читать дальше →
Всего голосов 42: ↑42 и ↓0 +42
Комментарии 4

Про износ SSD на реальных примерах

Время на прочтение 3 мин
Количество просмотров 106K

Год назад мы добавили в наш агент сбор метрик из S.M.A.R.T. атрибутов дисков на серверах клиентов. В тот момент мы не стали добавлять их в интерфейс и показывать клиентам. Дело в том, что метрики мы снимаем не через через smartctl, а дергаем ioctl прямо из кода, чтобы этот функционал работал без установки smartmontools на серверы клиентов.
Агент снимает не все доступные атрибуты, а только самые значимые на наш взгляд и наименее вендор-специфичные (иначе пришлось бы поддерживать базу дисков, аналогичную smartmontools).
Сейчас наконец дошли руки до того, чтобы проверить, что мы там наснимали. А начать было решено с атрибута "media wearout indicator", который показывает в процентах оставшийся ресурс записи SSD. Под катом несколько историй в картинках о том, как расходуется этот ресурс в реальной жизни на серверах.

Читать дальше →
Всего голосов 102: ↑97 и ↓5 +92
Комментарии 169

Простые метрики и способ сэкономить время при поиске проблем в инфраструктуре

Время на прочтение 2 мин
Количество просмотров 9.7K
Не так давно в датацентре, в котором мы арендуем серверы случился очередной мини-инцидент. Никаких серьезных последствий для нашего сервиса в итоге не было, по имеющимся метрикам нам удалось понять что происходит буквально за минуту. А потом я представил, как пришлось бы ломать голову, если бы не хватало всего 2х простеньких метрики. Под катом коротенькая история в картинках.
Читать дальше →
Всего голосов 36: ↑36 и ↓0 +36
Комментарии 10

MathOps или математика в мониторинге

Время на прочтение 18 мин
Количество просмотров 11K
То, о чем я хочу рассказать, началось 30 декабря 2010 года, когда компания Etsy выложила на GitHub первый коммит своей системы StatsD. Эта, сейчас уже, суперпопулярная система, написанная на JavaScript (хипстеры ликуют), в которую можно отправлять метрики, замеры исполнения кусков вашего кода, а она их агрегирует и отправляет уже агрегированными в систему хранения time-series.



На фоне популярности StatsD и других time-series систем появилась идея «Monitor Everything»: чем больше различных вещей в системе измеряется, тем лучше, потому что в случае неожиданной ситуации будет возможно найти нужную, уже собранную метрику, которая позволит во всем разобраться.

Давайте вообще все, что можно, мониторить — и будет классно!

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

И так получилось, что есть много проблем со всем этим, про которые, собственно, нам и расскажет Павел Труханов ( tru_pablo ).
Всего голосов 47: ↑46 и ↓1 +45
Комментарии 0

DevOps придумали разработчики, чтобы админы больше работали

Время на прочтение 9 мин
Количество просмотров 42K

Еще 4 года назад использование контейнеров в production было экзотикой, но сейчас это уже норма как для маленьких компаний, так и для больших корпораций. Давайте попробуем посмотреть на всю эту историю с devops/контейнерами/микросервисами ретроспективно, взглянуть еще раз свежим взглядом на то, какие задачи мы изначально пытались решить, какие решения у нас есть сейчас и чего не хватает для полного счастья?


Я буду в большей степени рассуждать про production окружение, так как основную массу нерешенных проблем я вижу именно там.

Читать дальше →
Всего голосов 95: ↑91 и ↓4 +87
Комментарии 62

Docker, или Туда и обратно

Время на прочтение 5 мин
Количество просмотров 17K

С появлением docker у нас, как у сервиса мониторинга немного усложнилась жизнь. Как я писал ранее, одна из фишек нашего сервиса — автодетект сервисов, то есть агент сам находит запущенные на сервере сервисы, читает их конфиги и начинает сбор метрик.


Но в какой-то момент в production у наших клиентов начал появляться докер, и наш автодетект перестал работать. Процессу, который запускается через докер, проставляются различные namespace (mnt, net, user, pid), это достаточно сильно усложняет работу извне контейнера с файлами и сетью внутри контейнера.


Под катом я расскажу, как мы решали эту проблему, какие варианты пробовали, и что в итоге заработало.

Читать дальше →
Всего голосов 33: ↑30 и ↓3 +27
Комментарии 9

Материализуем результаты поиска, или как мы освободили 25 процессорных ядер

Время на прочтение 7 мин
Количество просмотров 11K


Не так давно мы решали задачу оптимизации потребления ресурсов нашего кластера elasticsearch. Неосилив настроить сам эластик, мы сделали что-то типа кэша результатов поиска, использовав при этом подход называемый "обратным" поиском или перколятором. Под катом рассказ про то, как мы работаем с метаданными метрик и собственно перколятор.

Читать дальше →
Всего голосов 16: ↑16 и ↓0 +16
Комментарии 5

Советы по Postgres для Rails разработчиков

Время на прочтение 4 мин
Количество просмотров 8.7K

В апреле на RailsConf в Фениксе мы обсудили огромное количество советов по использованию Postgres с Rails, и подумали, что будет полезно их записать и поделиться с более широкой аудиторией. Здесь вы найдете некоторые из них, касающиеся отладки и улучшения производительности базы данных вашего Rails приложения.

Читать дальше →
Всего голосов 16: ↑16 и ↓0 +16
Комментарии 0

Построение правильной системы алертинга — реагируй только на бизнес-критичные проблемы

Время на прочтение 3 мин
Количество просмотров 8.6K
Перевод статьи директора по инфраструктуре @Synthesio — крик души про усталось от алертов и боль от не cloud-ready мониторинга.

В прошлом году я и мой коллега Гийом провели два авральных месяца, когда только мы вдвоем остались на поддержке. Мы отработали более 300 часов сверхурочно, что в 4 раза больше обычного и вдвое больше по сравнению с самым загруженным месяцем с тех пор как мы работаем в компании.
Читать дальше →
Всего голосов 10: ↑10 и ↓0 +10
Комментарии 3

Gorilla: быстрая, масштабируемая in-memory time-series база данных

Время на прочтение 8 мин
Количество просмотров 8.2K

Это перевод обзора статьи «Gorilla: A fast, scalable, in-memory time series database» Pelkonen et al. VLDB 2015


Чуваки из фейсбука сделали высокопроизводительный движок для мониторинговых данных. Мне понравился обзор этой статьи в блоге "The morning paper" — особенно про алгоритмы сжатия, и вот перевод.


Стиль — авторский.


Количество ошибок на одном из серверов Facebook зашкаливало.
Читать дальше →
Всего голосов 18: ↑18 и ↓0 +18
Комментарии 8

Запись при чтении в postgresql: скандалы, интриги, расследования

Время на прочтение 3 мин
Количество просмотров 25K

Я уже рассказывал про мониторинг запросов postgresql, в тот момент мне казалось, что я полностью разобрался, как postgresql работает с различными ресурсами сервера.


При постоянной работе со статистикой по запросам постгреса мы начали замечать некоторые аномалии. Я полез разбираться, заодно очередной раз восхитился понятностью исходного кода постгреса )


Под катом небольшой рассказ о неочевидном поведении postgresql.

Читать дальше →
Всего голосов 40: ↑38 и ↓2 +36
Комментарии 4

MemC3 — компактный Memcache с повышенной параллельностью — за счет более тупого кэширования и более умного хэширования

Время на прочтение 8 мин
Количество просмотров 6.9K

Это перевод обзора статьи «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" — описание алгоритмов и прочее.


Читать дальше →
Всего голосов 27: ↑26 и ↓1 +25
Комментарии 4

Мониторинг Elasticsearch через боль и страдания

Время на прочтение 7 мин
Количество просмотров 30K

Мы наконец допинали функционал мониторинга elasticsearch до публичного релиза. Суммарно мы переделывали его три раза, так как результат нас не устраивал и не показывал проблемы, которые мы огребали на нашем кластере ES.


Под катом история про наш production кластер, наши проблемы и наш новый мониторинг ES.

Читать дальше →
Всего голосов 34: ↑34 и ↓0 +34
Комментарии 6

Мониторинговый агент: простая штука или нет?

Время на прочтение 5 мин
Количество просмотров 8.8K

Сейчас существует достаточно много систем для хранения и обработки метрик (timeseries db), но ситуация с агентами (софтом, который собирает метрики) сложнее. Не так давно появился telegraf, но все равно выбор не велик.


При этом практически все облачные сервисы мониторинга разрабатывают свои агенты и мы не исключение. Мотивация достаточно простая — есть много специфичных требований, которые слабо вписываются в архитектуру существующих решений.


Основные наши специфичные требования:


  • надежность доставки метрик в облако
  • непростая логика плагинов: они взаимодействуют друг с другом
  • диагностика: мы должны уметь понимать, почему агент не может собрать те или иные метрики
  • агент должен потреблять как можно меньше ресурсов клиентского сервера

Под катом расскажу несколько аспектов разработки агента для сбора метрик.

Читать дальше →
Всего голосов 18: ↑18 и ↓0 +18
Комментарии 7

Мониторинг Postgresql: запросы

Время на прочтение 6 мин
Количество просмотров 56K

В 2008 году в списке рассылки pgsql-hackers началось обсуждение расширения по сбору статистики по запросам. Начиная с версии 8.4 расширение pg_stat_statements входит в состав постгреса и позволяет получать различную статистику о запросах, которые обрабатывает сервер.


Обычно это расширение используется администраторами баз данных в качестве источника данных для отчетов (эти данные на самом деле являются суммой показателей с момента сброса счетчиков). Но на основе этой статистики можно сделать мониторинг запросов — посмотреть на статистику во времени. Это оказывается крайне полезно для поиска причин различных проблем и в целом для понимания, что происходит на сервере БД.


Я расскажу, какие метрики по запросам собирает наш агент, как мы их группируем, визуализируем, так же расскажу о некоторых граблях, по которым мы прошли.

Читать дальше →
Всего голосов 27: ↑27 и ↓0 +27
Комментарии 8

Как мы неделю чинили compaction в Cassandra

Время на прочтение 7 мин
Количество просмотров 12K

Основным хранилищем метрик у нас является cassandra, мы используем её уже более трех лет. Для всех предыдущих проблем мы успешно находили решение, используя встроенные средства диагностики кассандры.


В кассандре достаточно информативное логгирование (особенно на уровне DEBUG, который можно включить на лету), подробные метрики, доступные через JMX и богатый набор утилит (nodetool, sstable*).


Но недавно мы столкнулись с одной достаточно интересной проблемой, и нам пришлось серьезно поломать голову, почитать исходный код кассандры, чтобы разобраться, что происходит.

Читать дальше →
Всего голосов 43: ↑42 и ↓1 +41
Комментарии 13
1