Forwarded from DevBrain
Есть пробелы в SQL? Ничего страшного. Их можно заполнить с помощью вот этого крутого туториала от Mode Analytics — https://community.modeanalytics.com/sql/
ThoughtSpot
ThoughtSpot SQL Tutorial | ThoughtSpot
Learn to answer questions with data using SQL, no prior coding required, guiding you through foundational to advanced SQL skills.
Forwarded from DevBrain
Обширный гайд о введении в распределенные системы от инженера из Uber. Парень кровью и потом заработал свои знания пока делал масштабируемую платёжную систему внутри компании. Must read: https://goo.gl/rjnaTJ
The Pragmatic Engineer
Distributed architecture concepts I learned while building a large payments system
I joined Uber two years ago as a mobile software engineer with some backend experience. I ended up building the payments functionality in the app - and rewriting the app on the way. Afterwards, I ended up moving into engineering management, heading up the…
Forwarded from DevBrain
Хотите "вкатиться" в тему распределенных систем, но не знаете с чего начать?
Нашел небольшой гайд с полезными ресурсами на эту тему https://goo.gl/LXQnWV. Я сейчас также собираю материалы о distributed systems, скоро расшарю публично.
Нашел небольшой гайд с полезными ресурсами на эту тему https://goo.gl/LXQnWV. Я сейчас также собираю материалы о distributed systems, скоро расшарю публично.
Caitie McCaffrey
Resources for Getting Started with Distributed Systems
I’m often asked how to get started with Distributed Systems, so this post documents my path and some of the resources I found most helpful. It is by no means meant to be an exhaustive list. …
Forwarded from Українська девопсарня
Я не знаю, как вы там деплоите в Kubernetes, но автор этого поста уже чуть ли не год мечтал, чтобы Spinnaker обзавелся поддержкой Helm чартов. И как-то оно незаметно случилось, пока, правда, в alpha - https://www.spinnaker.io/guides/user/kubernetes-v2/deploy-helm/ А докучи с недавно зарелизеной Kayenta, которая дает возможность делать automated canary analysis, Spinnaker снова заявляет права на лидерство в категории тулинга для CD в Kubernetes и не только
Spinnaker
Deploy Helm Charts
Global Continuous Delivery
Forwarded from DevOps Deflope News
Полезная подборка хороших практик обеспечения безопасности Kubernetes кластера от Simon Pirschel.
https://goo.gl/LCLwvc
https://goo.gl/LCLwvc
GitHub
freach/kubernetes-security-best-practice
Kubernetes Security - Best Practice Guide. Contribute to freach/kubernetes-security-best-practice development by creating an account on GitHub.
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
Однако, поскольку в наших широтах платить за книжки как-то не принято, делюсь ещё и сборником книг 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 вылетал?
Мой товарищ написал утилитку, которая позволяет автоматически сгенерить
https://github.com/alexandrst88/terraform-variables-generator
Ну и как обычно, пул реквесты приветствуются!
Во время написания основного кода, до этого или после, или вообще захардкодить всё (нет, не надо хардкодить!)
А как часто вы делали опечатку в названии переменной и TF вылетал?
Мой товарищ написал утилитку, которая позволяет автоматически сгенерить
variables.tf файл на основании уже готовых .tf файлов в директории https://github.com/alexandrst88/terraform-variables-generator
Ну и как обычно, пул реквесты приветствуются!
GitHub
GitHub - alexandrst88/terraform-variables-generator: Simple Tool for Generate Variables file from Terraform Configuration
Simple Tool for Generate Variables file from Terraform Configuration - alexandrst88/terraform-variables-generator
Forwarded from CatOps
Чеклист от компании Gruntwork о том, готовы ли вы к выходу в продакшн на AWS. Большинство пунктов по своей идее подходят не только к AWS, просто поменяйте названия соответствующих сервисов
#aws
#aws
Medium
The Production Readiness Checklist for AWS
Are you ready to go to prod on AWS? Use this checklist to find out.
Forwarded from CatOps
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
CPU (usage, quota, throttled)
Mem (rss, cache, page faults)
Disk io (fs + device)
Open fds, threads, uptime
Делим всё на 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% от лимита - приложение упирается в ограничения
Мониторинг нужен для того, чтобы:Узнать о том, что что-то сломалось.
Быстро узнать что именно и как именно сломалось
Разные операционные задачи - оптимизации, 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-бот для создания сервиса, выдаёт репу с шаблонами описания.
Prometheus - облако и всё в нём.
Graphite/Clickhouse - метрики сервисов, монолит, доступность нод
глубокой интеграции с k8s и его service discovery
pull-модели
расширяемости через exporters
Нет 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.
Ёмкость кластера и утилизация ресурсов кластера (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
Облако в авито:
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
Google Docs
My Philosophy on Alerting
My Philosophy on Alerting based my observations while I was a Site Reliability Engineer at Google Author: Rob Ewaschuk <rob@infinitepigeons.org> Introduction Vernacular Monitor for your users Cause-based alerts are bad (but sometimes necessary) Alerting…
Forwarded from DevOps drawer
12 Open Source Projects by Alibaba — Part 1 – Alibaba Cloud – Medium
https://medium.com/@Alibaba_Cloud/12-open-source-projects-by-alibaba-part-1-ffc156e5ede6
https://medium.com/@Alibaba_Cloud/12-open-source-projects-by-alibaba-part-1-ffc156e5ede6
Medium
12 Open Source Projects by Alibaba — Part 1
Since 2011, Alibaba Group has been actively involved in building open source communities, with the number of open source projects…
Forwarded from Mike Prokopchuk
И вот тут немного простых примеров: как отсылать и своего сервиса и простенький экпортер: https://github.com/theairkit/prometheus-examples
Forwarded from Mike Prokopchuk
Еще отличный пример - haproxy_exporter, от самих prometheus: https://github.com/prometheus/haproxy_exporter
GitHub
GitHub - prometheus/haproxy_exporter: Simple server that scrapes HAProxy stats and exports them via HTTP for Prometheus consumption
Simple server that scrapes HAProxy stats and exports them via HTTP for Prometheus consumption - prometheus/haproxy_exporter
Forwarded from ДевОпс Інженер 🇺🇦 (devopsengineer bot)
▶️▶️▶️ ДевОпс Инсайт: #devops_engineer_insights
Как легче всего зайти в Kubernetes?
На реальном опыте отвечает Сергей Михно (в жизни Серенький, в телеграме @Serhii_Mikhno). Уникально и только для подписчиков канала ДевОпс Инженер.
Путь ознакомления k8s зависит от задач, которые перед Вами стоят.
Тут есть два варианта - или для галочки у себя в резюме, или когда нужно поднять существующую инфраструктуру в кубере (как было у меня).
В обоих случаях лучше начинать с тестового проекта в GKE: https://cloud.google.com/kubernetes-engine/.
Например, поднять там какой-то сервис, который Вы уже умеете готовить. Далее можно добавить HA, настроив нужное колличество реплик и добавив healthchecks, а так же заекспоузить сервисы через ingress.
Все основные примитивы и концепции Kubernetes легче и быстрее всего освоить тут: http://kubernetesbyexample.com/ (обязательно добавить в закладочки). 💡
При решении этого задания, в любом случае нужно будет опираться на документацию, и очень желательно опираться на api reference k8s: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/
Подобный подход даст не только знания сущностей и абстракций, а так же даст понимание того, какие приложения и как ложатся в концепцию кубера.
Пару слов насчет Helm. Эта штука полезная и стоит уметь ею пользоваться, но далеко не во всех случаях. Потому что это дополнительный уровень абстракции над уже существующей моделью сущностей. Это облегчает управление и группировку громоздких сервисов, но затрудняет понимание того, какие реальные манифесты уходят в исполняемую среду.
По этому плагин helm template обязателен к установке, и важно понимать реализацию go template: (https://golang.org/pkg/text/template/), он очень похож на jinja2 (как в Ansible), так что с этим проблем не будет.
Теперь по поводу CI\CD. Написано уже очень много о том, как правильно готовить процессы с кубером. Мне лично помог блог компании Флант на Хабре: https://habr.com/company/flant/ , у них есть пару хороших видосов, которые проясняют lifecycle в кубере.
Далее, когда приложение уже запущено и работает, освоены основные концепции и примитивы - можно приступать к разворачиванию всяких штук вроде istio, подкручиванию network policy, RBAC, эксперименты с разными ingress controller и тестированию оверлейных сетей.
Простой пример - мы с тремя коллегами перевезли весь прод (с большим кол-вом сервисов и зависимостей в кубер) менее чем за месяц, при этом знания о Kubernetes были на уровне - "слышал, но не трогал".
Главное помнить, что кубер, это всего лишь платформа (фреймворк) со своими требованиями, и если им следовать и знать некоторое кол-во деталей - можно внедрять крутые штуки, полезные бизнесу, хоть каждый день.
Желаю удачи в изучении Kubernetes! 💪💪💪
Как легче всего зайти в Kubernetes?
На реальном опыте отвечает Сергей Михно (в жизни Серенький, в телеграме @Serhii_Mikhno). Уникально и только для подписчиков канала ДевОпс Инженер.
Путь ознакомления k8s зависит от задач, которые перед Вами стоят.
Тут есть два варианта - или для галочки у себя в резюме, или когда нужно поднять существующую инфраструктуру в кубере (как было у меня).
В обоих случаях лучше начинать с тестового проекта в GKE: https://cloud.google.com/kubernetes-engine/.
Например, поднять там какой-то сервис, который Вы уже умеете готовить. Далее можно добавить HA, настроив нужное колличество реплик и добавив healthchecks, а так же заекспоузить сервисы через ingress.
Все основные примитивы и концепции Kubernetes легче и быстрее всего освоить тут: http://kubernetesbyexample.com/ (обязательно добавить в закладочки). 💡
При решении этого задания, в любом случае нужно будет опираться на документацию, и очень желательно опираться на api reference k8s: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/
Подобный подход даст не только знания сущностей и абстракций, а так же даст понимание того, какие приложения и как ложатся в концепцию кубера.
Пару слов насчет Helm. Эта штука полезная и стоит уметь ею пользоваться, но далеко не во всех случаях. Потому что это дополнительный уровень абстракции над уже существующей моделью сущностей. Это облегчает управление и группировку громоздких сервисов, но затрудняет понимание того, какие реальные манифесты уходят в исполняемую среду.
По этому плагин helm template обязателен к установке, и важно понимать реализацию go template: (https://golang.org/pkg/text/template/), он очень похож на jinja2 (как в Ansible), так что с этим проблем не будет.
Теперь по поводу CI\CD. Написано уже очень много о том, как правильно готовить процессы с кубером. Мне лично помог блог компании Флант на Хабре: https://habr.com/company/flant/ , у них есть пару хороших видосов, которые проясняют lifecycle в кубере.
Далее, когда приложение уже запущено и работает, освоены основные концепции и примитивы - можно приступать к разворачиванию всяких штук вроде istio, подкручиванию network policy, RBAC, эксперименты с разными ingress controller и тестированию оверлейных сетей.
Простой пример - мы с тремя коллегами перевезли весь прод (с большим кол-вом сервисов и зависимостей в кубер) менее чем за месяц, при этом знания о Kubernetes были на уровне - "слышал, но не трогал".
Главное помнить, что кубер, это всего лишь платформа (фреймворк) со своими требованиями, и если им следовать и знать некоторое кол-во деталей - можно внедрять крутые штуки, полезные бизнесу, хоть каждый день.
Желаю удачи в изучении Kubernetes! 💪💪💪
Google Cloud
Google Kubernetes Engine (GKE)
GKE is the industry's first fully managed Kubernetes service with full Kubernetes API, 4-way autoscaling, release channels, and multi-cluster support.
Forwarded from DevBrain
Классная обзорная статья форматов сериализациия данных для обмена между системами (Avro, MessagePack, Protobuf и т.д.) — http://vasters.com/blog/data-encodings-and-layout/
vasters.com
Page Not Found
Page not found. Your pixels are in another canvas.
Forwarded from DevBrain
Как вкатиться в одну из самых сложных тем Computer Science, а именно Distributed Systems? Нашел на просторах сети гайд от 2015 года от одного из девелоперов RabbitMQ, must read
https://goo.gl/VougZ8
https://goo.gl/VougZ8
Forwarded from DevOps Deflope News
unsee — дашборд для Prometheus Alertmanager от Cloudflare.
Умеет показывать, фильтровать, агрегировать и дедуплицировать алерты с разных инстансов Alertmanager.
http://amp.gs/kVFm
Умеет показывать, фильтровать, агрегировать и дедуплицировать алерты с разных инстансов Alertmanager.
http://amp.gs/kVFm
GitHub
cloudflare/unsee
Alert dashboard for Prometheus Alertmanager. Contribute to cloudflare/unsee development by creating an account on GitHub.
Forwarded from DevOps Deflope News
Отличная статья про разделение кода, структуру каталогов и хранение стейта для Terraform.
http://amp.gs/kVMd
http://amp.gs/kVMd
Medium
Terraform: Sane practices & Project Structure
what has worked in my organisation regarding the structure of terraform projects and writting infrastructure as code
Forwarded from CatOps
Segment рассказывают про своё изобретение -- Centrifuge
Тулзу для доставки сообщений на 3rd party APIs, часть из которых может быть недоступна, выдавать большой latency или ограничивать колличество запросов.
Проблема и её решение достаточно кастомные для их случая, но почитать интересно
Тулзу для доставки сообщений на 3rd party APIs, часть из которых может быть недоступна, выдавать большой latency или ограничивать колличество запросов.
Проблема и её решение достаточно кастомные для их случая, но почитать интересно
Segment
Twilio Segment Blog