Dev0ps
40 subscribers
211 photos
3 videos
50 files
3.33K links
Download Telegram
Forwarded from CatOps
Я начинаю потихоньку разгребать свой загашник сохраненных статей. И сегодня будет парочку от Netflix.

Во-первых, Netflix FlameScope -- логическое дополнение FlameGraphs. FlameScope позволяет строить хитмап ивентов, где по оси X время в секундах, по оси Y -- фракции секунды (я не уверен, что я правильно перевел это), а "температура" показывает колличество ивентов, которые пришлись на это время.

Выбрав определенный сегмент хитмапа, можно сразу же перейти к флеймграфу того, что происходило в данный момент. Более доступно это показано на видео:

https://www.youtube.com/watch?time_continue=82&v=cFuI8SAAvJg

#performance
Forwarded from DevOps Deflope News
Netflix выпустили в opensource Kayenta, утилиту для автоматического анализа базовых метрик при канареечном релизе. Kayenta тесно интегрируется со Spinnaker и помогает Netflix получать максимально точную и быструю обратную связь по своим выкаткам.

https://goo.gl/f9BDzB
​​Если вы пропустили онлайн трансляцию пленарных докладов с Kafka Summit London 2018, выкладываю, чтобы на выходных было что посмотреть
Вот и подоспели все видосы с Kafka Summit London 2018
Forwarded from CatOps
Шпаргалка по high availability от Netflix

Вкратце:
- Деплойте по регионам, а не везде сразу
- Blue/green (red/black) деплои
- Временные окна для деплоев (чтобы в пиковую нагрузку не попасть)
- Автоматизированные деплои хорошо, но убедитесь, что они не происходят во время, когда никого нет в офисе/у компа, чтобы подхватить прод, если что-то пойдёт не по плану
- Хаос инжиниринг (ну Нетфликс же)
- Прогоняйте все тесты, которые у вас есть перед выкаткой на прод (ваш Кэп)
- Трезво оценивайте баланс между автоматизацией и ручными действиями. Есть вещи, которые не стыдно потыкать ручками
- Регулярно ревьювьте настройки алертов/пейджинга
- Убедитесь, что можете в roll back
- Останавливайте деплой, если хосты не поднимаются
- При автоматическом деплое отправляйте сообщения ответственным командам
- Автоматизируйте не только сценарии, в которых всё хорошо, но и сценарии, когда что-то идёт не по плану
- Собирайте информацию о зависимостях перед деплоем, а не угадывайте состояние related сервисов
Forwarded from DevBrain
Есть пробелы в SQL? Ничего страшного. Их можно заполнить с помощью вот этого крутого туториала от Mode Analytics — https://community.modeanalytics.com/sql/
Forwarded from DevBrain
Обширный гайд о введении в распределенные системы от инженера из Uber. Парень кровью и потом заработал свои знания пока делал масштабируемую платёжную систему внутри компании. Must read: https://goo.gl/rjnaTJ
Forwarded from DevBrain
Хотите "вкатиться" в тему распределенных систем, но не знаете с чего начать?

Нашел небольшой гайд с полезными ресурсами на эту тему https://goo.gl/LXQnWV. Я сейчас также собираю материалы о distributed systems, скоро расшарю публично.
Я не знаю, как вы там деплоите в Kubernetes, но автор этого поста уже чуть ли не год мечтал, чтобы Spinnaker обзавелся поддержкой Helm чартов. И как-то оно незаметно случилось, пока, правда, в alpha - https://www.spinnaker.io/guides/user/kubernetes-v2/deploy-helm/ А докучи с недавно зарелизеной Kayenta, которая дает возможность делать automated canary analysis, Spinnaker снова заявляет права на лидерство в категории тулинга для CD в Kubernetes и не только
Forwarded from DevOps Deflope News
Полезная подборка хороших практик обеспечения безопасности Kubernetes кластера от Simon Pirschel.

https://goo.gl/LCLwvc
Forwarded from CatOps
У меня недавно проскакивала ссылка на прекрасный ресурс -- Humble Bundle, где за небольшие деньги продавали книги относящиеся к DevOps штукам. Более того, часть денег (вы сами указываете какая) идёт на благотворительность

Однако, поскольку в наших широтах платить за книжки как-то не принято, делюсь ещё и сборником книг for free:

https://github.com/TechBookHunter/Free-DevOps-Books

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

P.S.: Hubmble Bundle ещё доступен, кстати:
https://www.humblebundle.com/books/devops-books

#books
Forwarded from CatOps
В жизни каждого человека, который писал Terraform код встаёт вопрос: когда оглашать переменные?
Во время написания основного кода, до этого или после, или вообще захардкодить всё (нет, не надо хардкодить!)
А как часто вы делали опечатку в названии переменной и TF вылетал?

Мой товарищ написал утилитку, которая позволяет автоматически сгенерить variables.tf файл на основании уже готовых .tf файлов в директории

https://github.com/alexandrst88/terraform-variables-generator

Ну и как обычно, пул реквесты приветствуются!
Forwarded from CatOps
Чеклист от компании Gruntwork о том, готовы ли вы к выходу в продакшн на AWS. Большинство пунктов по своей идее подходят не только к AWS, просто поменяйте названия соответствующих сервисов

#aws
Forwarded from CatOps
Стайлгайд по тому, как писать на Bash от Google:

https://google.github.io/styleguide/shell.xml

Отакот
Forwarded from Dmitry 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% от лимита - приложение упирается в ограничения
Forwarded from Dmitry 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
Forwarded from Mike Prokopchuk
И вот тут немного простых примеров: как отсылать и своего сервиса и простенький экпортер: https://github.com/theairkit/prometheus-examples