Size: a a a

Пятничный деплой

2018 May 16
Пятничный деплой
👨🏼‍💻 DevOps Moscow meetup.

Вторая встреча DevOps Moscow meetup проходит прямо сейчас. Прямая трансляция доступна по ссылке:

https://www.youtube.com/watch?v=zdPbQ5DMAPE

Доставайте печеньки, присоединяйтесь. 🙂

#devops #видео
YouTube
DevOps Moscow Meetup live: Мониторинг // 16-05-2018
Вторая после долгого перерыва встреча, которая пройдет в офисе Авито, будет посвящена мониторингу. В программе — доклады как про инструментарий мониторинга, так и про инцидент-менеджмент в целом. Выступят представители Авито, Okmeter.io и Badoo.

Программа:

19:00 — 19:10 — Приветственное слово

19:10 — 19:50 — «Мониторинг облачной инфраструктуры», Михаил Прокопчук (Авито)

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

19:50 — 20:10 — Перерыв

20:10 — 20:50 — «Автодискавери в мониторинге: как надёжно обеспечить полноту мониторинга», Николай Сивко (okmeter.io)

Поговорим о наполнении мониторинга — метриках. Расскажу, как обычно настраивается сбор метрик в системах мониторинга и на какие грабли можно при этом наступить. Также расскажу о нашем подходе к автоматическому сбору метрик: как это работает, какие именно метрики мы снимаем…
источник
Пятничный деплой
Интересная альтернатива crond
#cron
https://github.com/dshearer/jobber
источник
Пятничный деплой
Касательно митапа в Авито. Очень хороший доклад от хозяев, а в докладе от окметр очень четко прописано что мониторить в современных системах. Слайды можно использовать как чек-лист для вашего мониторинга #avito #meetup
источник
2018 May 17
Пятничный деплой
источник
Пятничный деплой
Ну и сама запись собственно
источник
Пятничный деплой
Переслано от Александр 🐎...
источник
Пятничный деплой
Спасибо Дмитрию за конспекты
источник
Пятничный деплой
Переслано от Dmitriy Zaytsev
Заметки по первому докладу о прометеусе в авито.
Облако в авито:

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
источник
Пятничный деплой
Переслано от Dmitriy Zaytsev
Полезная часть от 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% от лимита - приложение упирается в ограничения
источник
Пятничный деплой
Подборка хаутушек по golang #golang #howto https://github.com/gyuho/learn
источник
Пятничный деплой
https://github.com/theairkit/prometheus-examples #prometheus #exporter Примеры написания экспортеров для прометея
источник
Пятничный деплой
Теперь можно!
источник
Пятничный деплой
Кароче, помнишь менеджер говорил: «Нет стайл гайда – мы на этом не пишем»?
Так вот гугловый стайл гайд для баша: https://google.github.io/styleguide/shell.xml.
Теперь законно!
источник
Пятничный деплой
Переслано от Vit
Событие hangops_ru в fb на сегодня вечер:
https://www.facebook.com/events/615571538810319/

ссылка на просмотр трансляции: https://www.youtube.com/watch?v=VdwxfocVqcM

Ссылка для очного участия будет ближе к делу. Количество мест в hangout ограничено, поэтому приходие кто хочет подискутировать и задавтаь вопросы, если просто послушать - лучше трансляцию, или в чат кидать (может Олег будет читать)
источник
2018 May 18
Пятничный деплой
[Перевод] Kubernetes NodePort vs LoadBalancer vs Ingress? Когда и что использовать?
https://habr.com/post/358824/
Tags: Системное администрирование, DevOps, Блог компании Southbridge, Kubernetes, Microservices, Services, Load Balancing, Ingress
Author olemskoi on #habrahabr
источник
Пятничный деплой
источник
Пятничный деплой
Небольшой cheatsheet по k8s
#k8s #cheatsheet
источник
Пятничный деплой
источник
Пятничный деплой
Амазон юзеры могут ликовать - к ним завезли GKE
источник
Пятничный деплой
Между делом случилось наконец-то то, что мы так долго ждали.

Блаженный сервис Fargate теперь доступен в регионе eu-west-1. А значит вся моя исследовательская деятельность по Terraform, DCOS и прочему может лететь в мусорный бак, потому что пора адаптировать все под “serverless” контейнерную оркестрацию.

Как же я люблю ИТ. ^^
источник