в общем, как к успеху пришли (:

Присылай развернутые тезисы/план, глянем и подумаем :)

Спасибо докладчикам и оргам за запись! Смотрю -- прекрасные доклады. 👍

Привет, Михаил.

В чатике одни и те же лица.

+1

Как держать развесистую инфру на ансе и быстро катить роли, как обновлять ансибл и не ломаться. Это навскидку.

Про использование дайнамик инвентори ещё интересно. Кто как использует

Как тестировать свои плейбуки. Точнее как их писать, чтобы их можно было бы тестировать

Спасибо, потыкаю

Молекулой)

таки да

Заметки по первому докладу о прометеусе в авито.

Облако в авито:

k8s, 4 кластера - 2 x prod (baremetal), dev (vm) staging (vm)
50 нод в каждом, 2000 pod в dev
100 релизов в день в prod (разработчики катят сами)
Используют helm, teamcity. Есть линтер для кубера, который проверяет аннотации и правильность описания. Есть slack-бот для создания сервиса, выдаёт репу с шаблонами описания.

2 стека мониторинга в Avito:

Prometheus - облако и всё в нём.
Graphite/Clickhouse - метрики сервисов, монолит, доступность нод

Выбрали prometheus из-за:

глубокой интеграции с k8s и его service discovery
pull-модели
расширяемости через exporters

Минусы prometheus:

Нет HA (и не будет, судя по всему)
Не про долгосрочное хранение метрик

Разное:

Для долгосрочного хранения метрик есть remote-storage адаптер для graphite.
Сейчас экспериментируют с ним. Лаг поступлления метрик - около минуты. Минус - нет фильтрации, можно выгружать только ВСЕ метрики, которые есть в prometheus.
Не используют prometheus operator для k8s, делают простой деплоймент.
Используют cross-monitoring между кластерами, каждый prometheus мониторит prometheus в соседних кластерах.
Используют prometheus federation (hierarchical) для некоторых типов метрик (пока не запустили долгосрочный сторадж на graphite)

Ресурсы:

CPU - простой запрос с агрегацией данных по нодам занимает 5s cpu. Если положить много подобных запросов в графану и открыть несколько дашбордов... Решение - recording-rules - прекомпилированные запросы. Крайне рекомендуют делать для всех запросов на дашбордах.
MEM RSS - До 2.2.1-release были утечки памяти. Огребали OOM на деве из-за множества сущностей и retention в 24h. Решение - уменьшать размер датасета с метриками (уменьшать retention, увеличивать scrape-интервал)
MEM VSZ - tsdb активно использует mmap, все данные в pagecache. Важно мониторить наличие свободных страниц в pagecache.
Статистика по дев-кластеру:
1,2m метрик, размер датасета 5Gb, Retention 2h.
CPU 300%, RSS 9Gb, VSZ 12Gb.

Алертинг:

K8S и облачные сервисы мониторят через Grafana -> slack.
Бизнес-метрики/легаси/доступность через Moira -> slack/sms.
Не используют alert-manager, потому-что уже есть moira.

Что мониторить в k8s:

Ёмкость кластера и утилизация ресурсов кластера (cpu/ram/net), тренд утилизации.
Доступные ноды, kube-apiserver rps и latency, подов на ноду, подов не в running.
Requests/limits подов, usage подов.
Blackbox - http code, latency. TODO - docker pull, go get, etc.

Полезные ссылки:

https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/edit
http://fabxc.org/tsdb

2 доклад был про okmeter, он в целом бесполезен, так как самостоятельно вы такое реализовывать просто утомитесь.
3 доклад был про отдел мониторинга в баду. Полезного не было, смешное было, что человек очень извинялся за то, что у них заббикс :)

Ну мне понравилось про подсказки от мониторинга что надо замонитонить. В остальном согласен.

Второй доклад хорош тем, что там прямо четко рассказали что надо мониторить и как

Можно как чек-лист использовать

Полезная часть от okmeter.
Мониторинг нужен для того, чтобы:
Узнать о том, что что-то сломалось.
Быстро узнать что именно и как именно сломалось
Разные операционные задачи - оптимизации, capacity, etc.

Самое главное в системе мониторинга - метрики.
Хорошие графики - это оптимизация над метриками.
Хорошие триггеры - оптимизация над графиками.

Системные метрики:
CPU: usage, core_throttle_count, logical_cores
Mem: usage, swap, errors, numa
Disk: usage, inodes, io, latency, raid+bbu, SMART, fs errors
Net: interfaces metrics+errors, TCP/IP metrics (retrans, overflows, etc), conntrack table
Метрики процессов/контейнеров/cgroups:
CPU (usage, quota, throttled)
Mem (rss, cache, page faults)
Disk io (fs + device)
Open fds, threads, uptime
Net:
Делим всё на in/out
Группируем по listen_ip, listen_port, remote_ip
Снимаем states (count), rtt, rqueue/wqueue
Listen - status, backlog current/max
Навигация при факапе:
1. Даш уровня пользовательского опыта (есть проблема или нет)
2. Summary по сервисам - топ ошибок, времени ответа и т.д. (в каком сервисе проблема)
3. Детализация сервиса (в чём проблема - сервис, база, соседний сервис)
4. Детализация инфраструктуры под сервисом (базы, очереди, сервера)
Автотриггеры на любые сущности:
TCP: backlog/max > 90% - приложение затупило.
Process: max_cpu_per_thread > 90% - тред упёрся в ядро
cgroup: cpu_usage > 90% от лимита - приложение упирается в ограничения

Не удивительно)

Одни и теже балоболы)

Напоминаю, что оставить обратную связь докладчикам и митапу в целом можно по форме обратной связи в почте :)