Коллеги, всем привет!)
Готовлюсь к митапу (анонс сделаю немного позже), собираю в своем докладе все грабли/костыли/косяки которые мы ловили с мониторингом/логированием/трейсингом
И вспомнил про самый "веселый" прикол с которым сталкивался (смотри мем)
А какие интересные проблемы вы решали в своем observability?=)
Готовлюсь к митапу (анонс сделаю немного позже), собираю в своем докладе все грабли/костыли/косяки которые мы ловили с мониторингом/логированием/трейсингом
И вспомнил про самый "веселый" прикол с которым сталкивался (смотри мем)
А какие интересные проблемы вы решали в своем observability?=)
😁13🔥5👏1
Коллеги, всем привет!=)
Задумался я тут о том, что пора превратить нашу Grafana в Grafana HA (это не ha-ha-ha classic, а Grafana High Abailability)
Кажется, что все достаточно просто, Grafana живет в k8s, проставишь в чарте
И сразу же начинают всплывать определенные нюансы
Основной нюанс заключается в том что наша Grafana иногда отправляет алерты которые настраивали команды разработки и если просто увеличить количество реплик с ооооочень большой вероятностью мы получим х3 алертов, что не очень весело
Отправил читать документацию, HA режим для алертов доступен и может работать как с "отдельно стоящим" Redis, так и с самой Grafana
Вариант когда инстансы Grafana синхронизируются между собой, показался более привлекательным, так как нет необходимости в доп компоненте
Конфиг для Grafana выглядит следующий образом
Так же нам нужен сервис, что бы Grafana`ы могли найти друг друга
Благодаря этому мы получаем Grafana HA, что добавляет нам "выживаемости" в случае внештатных ситуаций с инфрой
Ну и напоследок, как сказать Grafana, что бы она расползалась по разным нодам и зонам кластера
PS - для Grafana у нас поднят отдельно стоящий кластер PG
Задумался я тут о том, что пора превратить нашу Grafana в Grafana HA (это не ha-ha-ha classic, а Grafana High Abailability)
Кажется, что все достаточно просто, Grafana живет в k8s, проставишь в чарте
replicas: 3и дело к стороне
И сразу же начинают всплывать определенные нюансы
Основной нюанс заключается в том что наша Grafana иногда отправляет алерты которые настраивали команды разработки и если просто увеличить количество реплик с ооооочень большой вероятностью мы получим х3 алертов, что не очень весело
Отправил читать документацию, HA режим для алертов доступен и может работать как с "отдельно стоящим" Redis, так и с самой Grafana
Вариант когда инстансы Grafana синхронизируются между собой, показался более привлекательным, так как нет необходимости в доп компоненте
Конфиг для Grafana выглядит следующий образом
grafana.ini:
unified_alerting:
enabled: true
ha_listen_address: "${POD_IP}:9094"
ha_peers: "grafana-alerting.grafana:9094"
ha_advertise_address: "${POD_IP}:9094"
ha_peer_timeout: 15s
ha_reconnect_timeout: 2m
Так же нам нужен сервис, что бы Grafana`ы могли найти друг друга
apiVersion: v1
kind: Service
metadata:
name: grafana-alerting
namespace: grafana
labels:
app.kubernetes.io/name: grafana-alerting
app.kubernetes.io/part-of: grafana
spec:
type: ClusterIP
clusterIP: 'None'
ports:
- port: 9094
selector:
app.kubernetes.io/name: grafana
Благодаря этому мы получаем Grafana HA, что добавляет нам "выживаемости" в случае внештатных ситуаций с инфрой
Ну и напоследок, как сказать Grafana, что бы она расползалась по разным нодам и зонам кластера
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app.kubernetes.io/name
operator: In
values:
- grafana
topologyKey: topology.kubernetes.io/zone
- weight: 99
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app.kubernetes.io/name
operator: In
values:
- grafana
topologyKey: topology.kubernetes.io/hostname
PS - для Grafana у нас поднят отдельно стоящий кластер PG
🔥9👍6❤2⚡1🤔1
Коллеги, всем пятнички!=)
Как то мимо меня прошла новость о том что в бету вышел Prometheus 3 (спойлер - скорее всего у вас 2.x)
Что там нового:
-- Новый интерфейс, добавили темную тему - не ну такое срочно в прод надо💃
-- Новый интерфейс для графиков и алертов - вцелом, я всегда использовал интерфейс Prometheus для дебага чего либо, если новый интерфейс позволит делать это удобнее/быстрее - отлично =)
-- Remote Write 2.0 - многие используют remote write что бы "сливать" метрики в какую то большую хранилку, интересно что добавили отсылку exemplars и тд
-- Поддержка OpenTelemetry - а вот это уже действительно круто, так как OpenTelemetry врывается в индустрию и очень скоро станет стандартом, предполагаю что будет возможность пушить метрички напрямую в Prometheus, это точно будет удобно для каких нибудь CronJob
Чего лично мне не хватило, с Prometheus вот все хорошо, кроме потребления ресурсов, особеноо в кластерах в большим количеством сервисов, и потребление ресурсов у Prometheus просто невероятное. Если вопрос потребления ресурсов каким либо образом "порешают", будет вообще пушка-гонка-красота =)
Оригинальный пост вы можете прочитать тут
Ииии всем хорошей пятнички =)
Как то мимо меня прошла новость о том что в бету вышел Prometheus 3 (спойлер - скорее всего у вас 2.x)
Что там нового:
-- Новый интерфейс, добавили темную тему - не ну такое срочно в прод надо
-- Новый интерфейс для графиков и алертов - вцелом, я всегда использовал интерфейс Prometheus для дебага чего либо, если новый интерфейс позволит делать это удобнее/быстрее - отлично =)
-- Remote Write 2.0 - многие используют remote write что бы "сливать" метрики в какую то большую хранилку, интересно что добавили отсылку exemplars и тд
-- Поддержка OpenTelemetry - а вот это уже действительно круто, так как OpenTelemetry врывается в индустрию и очень скоро станет стандартом, предполагаю что будет возможность пушить метрички напрямую в Prometheus, это точно будет удобно для каких нибудь CronJob
Чего лично мне не хватило, с Prometheus вот все хорошо, кроме потребления ресурсов, особеноо в кластерах в большим количеством сервисов, и потребление ресурсов у Prometheus просто невероятное. Если вопрос потребления ресурсов каким либо образом "порешают", будет вообще пушка-гонка-красота =)
Оригинальный пост вы можете прочитать тут
Ииии всем хорошей пятнички =)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥3❤1
Коллеги, всем привет!=)
Не так давно писал про то как мы накручивали отказоустойчивость у Grafana
И там мы использовали affinity rules
В k8s есть множество различных возможностей для управления тем как поды будут размещены внутри кластера
К примеру, у нас есть 3 зоны доступности A,B,D (особенно внимательные наверняка увидели Yandex Cloud) и нам нужно сделать так что бы 3 пода "разъехались" гарантированно по трем разным зонам, при этом если одна зона не доступна под не мигрировал в другую
Зачем - кейс с blackbox экспортером и мониторингом каких то "внешних" ресурсов из разных зон доступности, дублировать проверки из одной и той же зоны мы не хотим
Для решения этой задачи нам прекрасно подойдет Pod Topology Spread Constraints
Доп конфигурация для официального helm чарта может выглядеть следующим образом:
Что произойдет:
-- мы поставили 3 реплики
-- поды разъедутся по одному в каждую зону
-- если какая то зона отвалится, под будет висеть в статусе Pending
Благодаря этому поды разъезжаются по разным зонам, в случае тотального падения зоны под не переезжает в доступную зону и метрики не дублируются =)
Не так давно писал про то как мы накручивали отказоустойчивость у Grafana
И там мы использовали affinity rules
В k8s есть множество различных возможностей для управления тем как поды будут размещены внутри кластера
К примеру, у нас есть 3 зоны доступности A,B,D (особенно внимательные наверняка увидели Yandex Cloud) и нам нужно сделать так что бы 3 пода "разъехались" гарантированно по трем разным зонам, при этом если одна зона не доступна под не мигрировал в другую
Зачем - кейс с blackbox экспортером и мониторингом каких то "внешних" ресурсов из разных зон доступности, дублировать проверки из одной и той же зоны мы не хотим
Для решения этой задачи нам прекрасно подойдет Pod Topology Spread Constraints
Доп конфигурация для официального helm чарта может выглядеть следующим образом:
replicas: 3
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app.kubernetes.io/name: prometheus-blackbox-exporter
Что произойдет:
-- мы поставили 3 реплики
-- поды разъедутся по одному в каждую зону
-- если какая то зона отвалится, под будет висеть в статусе Pending
Благодаря этому поды разъезжаются по разным зонам, в случае тотального падения зоны под не переезжает в доступную зону и метрики не дублируются =)
👍5🔥5❤1
Коллеги, всем привет!=)
Как восстанавливливать дашборды Grafana если они "внезапно" испарились?0_o
Пришли к нам разработчики с вопросом - "Мы тут наводили порядок в своей директории и парочка важных дашбордов у нас испарилась, спасите, помогите!!!"
Вцелом то ничего страшного, в качестве бекэнда у нас используется Postgresql который к слову бекапится и все такое
Подумали, что достаточно развернуть базe из бекапа, завести вторую Grafana и вытащить Json, ну а дальше его импортнуть
Но все оказалось сильно проще💻
В базе Grafana есть табличка dashboard в которой как раз и хранятся наши дашборды в Json формате, то есть поднимать вторую Grafana уже и не надо, достаточно просто "вытащить" нужный нам дашборд, а потом импортировать. Grafana у нас 11.3.0 версии, у предыдущих версий думаю хранение организовано так же
Вот так мы сэкономили немного вермени, пользуйтесь, коллеги!^_^
Как восстанавливливать дашборды Grafana если они "внезапно" испарились?0_o
Пришли к нам разработчики с вопросом - "Мы тут наводили порядок в своей директории и парочка важных дашбордов у нас испарилась, спасите, помогите!!!"
Вцелом то ничего страшного, в качестве бекэнда у нас используется Postgresql который к слову бекапится и все такое
Подумали, что достаточно развернуть базe из бекапа, завести вторую Grafana и вытащить Json, ну а дальше его импортнуть
Но все оказалось сильно проще
В базе Grafana есть табличка dashboard в которой как раз и хранятся наши дашборды в Json формате, то есть поднимать вторую Grafana уже и не надо, достаточно просто "вытащить" нужный нам дашборд, а потом импортировать. Grafana у нас 11.3.0 версии, у предыдущих версий думаю хранение организовано так же
Вот так мы сэкономили немного вермени, пользуйтесь, коллеги!^_^
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥4⚡1
Коллеги, всем привет!=)
Рубрика "мамая, я в телевизоре"
23 октября выступал на Observability Days в Т-банке где рассказывал про наши приключения с Observability в Магнит Омни
Собрал большое количество различных приколов, костылей и мемов в своем докладе
Записи всех докладов доступны тут, Enjoy!
PS - сегодня будет еще один анонс, я надеюсь =)
Рубрика "мамая, я в телевизоре"
23 октября выступал на Observability Days в Т-банке где рассказывал про наши приключения с Observability в Магнит Омни
Собрал большое количество различных приколов, костылей и мемов в своем докладе
Записи всех докладов доступны тут, Enjoy!
PS - сегодня будет еще один анонс, я надеюсь =)
🔥12👍4❤1
Коллеги, всем добрый вечер!=)
Иииии очередной анонс про который я писал немного ранее
13-11-2024 буду на DevOops Conf 2024
Вместе с Иваном мы расскажем про Cluster API, что это такое, как его можно использовать, как можно катать свои k8s кластера на виртуалках и на железе, да причем тут целая куча k8s операторов
Ссылка на страничку доклада
PS - да, да, я умею не только в Observability ^_^
Иииии очередной анонс про который я писал немного ранее
13-11-2024 буду на DevOops Conf 2024
Вместе с Иваном мы расскажем про Cluster API, что это такое, как его можно использовать, как можно катать свои k8s кластера на виртуалках и на железе, да причем тут целая куча k8s операторов
Ссылка на страничку доклада
PS - да, да, я умею не только в Observability ^_^
🔥10❤2👍1
Поиграл в рулетку где надо рассказать про инструмент который выпадет))
Кажется организаторы что-то знают обо мне😂😂😂
Кажется организаторы что-то знают обо мне😂😂😂
😁6👍3👏1
Расширяем возможности clusterapi.pdf
28.2 MB
Коллеги, всем отличной субботы!=)
DevOops 2024 прошел, было интересно, было много крутых докладов =)
А в этом посте я выкладываю презентацию Ивана, именно на его докладе я был тех экспертом =)
Спойлер1 - где то там, на видео, будет шутка про пшеничный смузи =)
Спойлер2 - как только появится возможножность выложить доклад, я обязательно это сделаю =)
DevOops 2024 прошел, было интересно, было много крутых докладов =)
А в этом посте я выкладываю презентацию Ивана, именно на его докладе я был тех экспертом =)
Спойлер1 - где то там, на видео, будет шутка про пшеничный смузи =)
Спойлер2 - как только появится возможножность выложить доклад, я обязательно это сделаю =)
👍9🔥7❤2
Коллеги, всем привет =)
Небольшая заметка про oci registry и хранения всякого внутри. Для начала давайте разберемся, что такое OCI.
OCI - это Open Container Initiative и эта организация занимается “описыванием/написанием” правил игры для разработки cloud native продуктов.
Иииии OCI реджестри как раз и использую стандарт организации.
В рамках реджестри мы подразумеваем хранение докер образов, НО если реджестри OCI совмести (назовем это так), в реджестри можно хранить хельм чарты и !!!ВНИМАНИЕ!!! файлы (файлы в дальнейшем будут называться артифактами)
Если докер образами все понятно, с хельм чартами есть некоторые различия между реждестри:
— в “дефолтном” реджестри для хранения создается индексный файл в котором описывается содержимое хельм реджестри
— в OCI совместимом его нет и формат взаимодействия отличается, например
Что там и причем тут файлы? А разбираться я начал, когда пошел реконфигурировать Trivy по мотивам вот этой истории
Выполнив стандартный докер пул из реджестри я получил ошибку
И пошел разбираться. Оказалось, что Trivy хранит свои базы в условновном докер реджестри и это не просто докер образ, а просто файл, что уже интересно.
Для того что бы все таки получить “файлик” мы можем использовать oras
Выполнив команду
Мы успешно скачаем последнюю доступную базу Trivy
Кстати говоря, если у вас уже есть harbor для dockerhub настроенный в режиме кэширующего прокси, он будет из коробки проксировать и артифакты =)
Небольшая заметка про oci registry и хранения всякого внутри. Для начала давайте разберемся, что такое OCI.
OCI - это Open Container Initiative и эта организация занимается “описыванием/написанием” правил игры для разработки cloud native продуктов.
Иииии OCI реджестри как раз и использую стандарт организации.
В рамках реджестри мы подразумеваем хранение докер образов, НО если реджестри OCI совмести (назовем это так), в реджестри можно хранить хельм чарты и !!!ВНИМАНИЕ!!! файлы (файлы в дальнейшем будут называться артифактами)
Если докер образами все понятно, с хельм чартами есть некоторые различия между реждестри:
— в “дефолтном” реджестри для хранения создается индексный файл в котором описывается содержимое хельм реджестри
— в OCI совместимом его нет и формат взаимодействия отличается, например
helm pull oci://cr.yandex/myregistry/charts/chart-name --version 0.0.1
Что там и причем тут файлы? А разбираться я начал, когда пошел реконфигурировать Trivy по мотивам вот этой истории
Выполнив стандартный докер пул из реджестри я получил ошибку
unsupported media type application/vnd.oci.empty.v1+json
И пошел разбираться. Оказалось, что Trivy хранит свои базы в условновном докер реджестри и это не просто докер образ, а просто файл, что уже интересно.
Для того что бы все таки получить “файлик” мы можем использовать oras
Выполнив команду
oras pull registry-1.docker.io/aquasec/trivy-db:2
Мы успешно скачаем последнюю доступную базу Trivy
Кстати говоря, если у вас уже есть harbor для dockerhub настроенный в режиме кэширующего прокси, он будет из коробки проксировать и артифакты =)
Хабр
GitHub ограничивает доступ к базе уязвимостей Trivy
В последний месяц разработчики, использующие Trivy для сканирования контейнеров, столкнулись с серьёзной проблемой: при попытке загрузить базу данных уязвимостей из GitHub Container Registry ( ghcr.io...
👍4🤔3🔥2
Коллеги, всем привет! =)
Небольшой экскурс про то как катить миграции баз данных приложений которые развернуты в k8s.
Очень часто на просторах интернетов вы можете столкнуться к тем, что катить миграции предлагают при помощи инит контайнеров в подах. План надежный как швейцарские часы, но есть одно большое НО😤
Миграции в случае использования инит контейнеров будут прокатываться всегда, например когда вы поскейлили количество подов или отработал HPA. И потенциально миграции могут приводить к локам таблиц БД, что в проде, да еще в рабочее время максимально не весело.
Как еще есть варианты?
Конечно же использовать jobs в k8s.
Суть заключается в том, что “джоба” эта такая сущность, которая может отработать только один раз. Соотвественно у нас не будет проблем с повторной накаткой миграций.
Ну сделали мы джобу, а дальше то что? Как сделать так что бы джоба отрабатывала перед началом, к примеру обновления, самого приложения?
В случае с helm нам на помощь придут helm hooks
В нашем случае, нам прекрасно подойдет pre-install и pre-upgrade.
И если вы проставите эти хуки в аннотация соотвествующих ресурсов, а мы с вами говорим про джобы, то эти ресурсы будут задеплоины первыми и уже после них будут задеплоины оставшиеся ресурсы.
Зачем я это пишу - обновлял я тут defectdojo в k8s и что-то пошло не так. Посмотрел, хуки на месте, install и upgrade. Посмотрел внимательно, а хуки то post-install и post-upgrade, то есть миграции defectdojo исходя из конфига должны отрабатывать после всех действий. И все благополучно падало =)
Небольшой экскурс про то как катить миграции баз данных приложений которые развернуты в k8s.
Очень часто на просторах интернетов вы можете столкнуться к тем, что катить миграции предлагают при помощи инит контайнеров в подах. План надежный как швейцарские часы, но есть одно большое НО
Миграции в случае использования инит контейнеров будут прокатываться всегда, например когда вы поскейлили количество подов или отработал HPA. И потенциально миграции могут приводить к локам таблиц БД, что в проде, да еще в рабочее время максимально не весело.
Как еще есть варианты?
Конечно же использовать jobs в k8s.
Суть заключается в том, что “джоба” эта такая сущность, которая может отработать только один раз. Соотвественно у нас не будет проблем с повторной накаткой миграций.
Ну сделали мы джобу, а дальше то что? Как сделать так что бы джоба отрабатывала перед началом, к примеру обновления, самого приложения?
В случае с helm нам на помощь придут helm hooks
В нашем случае, нам прекрасно подойдет pre-install и pre-upgrade.
И если вы проставите эти хуки в аннотация соотвествующих ресурсов, а мы с вами говорим про джобы, то эти ресурсы будут задеплоины первыми и уже после них будут задеплоины оставшиеся ресурсы.
Зачем я это пишу - обновлял я тут defectdojo в k8s и что-то пошло не так. Посмотрел, хуки на месте, install и upgrade. Посмотрел внимательно, а хуки то post-install и post-upgrade, то есть миграции defectdojo исходя из конфига должны отрабатывать после всех действий. И все благополучно падало =)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤3😁2👍1
Коллеги, всем привет! =)
В одном из чатиков проскочила вот такая вот штука Kafka Visualization
Softwaremill сделали наглядный визуализатор того, что происходит внутри Kafka
Можно посмотреть/понастраивать:
-- Конфигурацию топика, его репликейшин фактор и партиционирование
-- Количество брокеров сообщений (именно они хранят и обрабатывают сообщения)
-- Количество консюмеров и их группы (именно они ходят за сообщения)
Вцелом выглядит очень наглядно и будет точно полезно тем кто хочет посмотреть, а как оно там вообще =)
В одном из чатиков проскочила вот такая вот штука Kafka Visualization
Softwaremill сделали наглядный визуализатор того, что происходит внутри Kafka
Можно посмотреть/понастраивать:
-- Конфигурацию топика, его репликейшин фактор и партиционирование
-- Количество брокеров сообщений (именно они хранят и обрабатывают сообщения)
-- Количество консюмеров и их группы (именно они ходят за сообщения)
Вцелом выглядит очень наглядно и будет точно полезно тем кто хочет посмотреть, а как оно там вообще =)
🔥10👍9❤3
Коллеги, всем привет! =)
У ребят из Flant вышла интересная статья про то как они решали проблему 3 way merge при развертывании ресурсов при помощи Helm.
Не то что бы я был фанатом Werf, но почитать про 3 way merger, для освежения памяти было интересно =)
Проблема кроется в том, что некоторые ресурсы могут появляться в кластере и Helm про них может сооовсем ничего не знать. Например у нас есть deployment и при помощи аннотации мы добавляем Istio Sidecar в pod нашго deployment. Обычно при выполнение helm upgrade проблем не возникает, чаще всего проблемы могут возникнуть если мы выполнили helm rollback или “стопнули” helm upgrade —install.
Как работает 3 way merge:
1 - Получаем манифесты ресурса из релиза который установлен в кластере k8s
2 - Получаем манифесты из чарта который хотим установить/обновить
3 - Получаем манифест из кластера k8s (самый спорный пункт, много думал)
4 - Собираем в кучу все 3 манифеста и мержим их
5 - Отправляем PATCH запрос в k8s
Что бы решить проблему 3WM, пришел новый механизм под названием Server-Side Apply или SSA
Он “из коробки” лишен недостатков 3WM и выполняет гораздо меньше действий с ресурсами:
1 - Получаем манифесты из чарта
2 - Отправляем PATCH запрос в k8s
Ииии у нас все работает хорошо =)
А если вы давно пользуетесь ArgoCD, скорее всего server-side apply включен у вас для большинства ресурсов =)
ЗЫ - с приколами 3WM периодически сталкиваемся, решений обычно два, отправиться править ресурсы руками внутри k8s, сделать helm uninstall и развернуть приложение заново.
У ребят из Flant вышла интересная статья про то как они решали проблему 3 way merge при развертывании ресурсов при помощи Helm.
Не то что бы я был фанатом Werf, но почитать про 3 way merger, для освежения памяти было интересно =)
Проблема кроется в том, что некоторые ресурсы могут появляться в кластере и Helm про них может сооовсем ничего не знать. Например у нас есть deployment и при помощи аннотации мы добавляем Istio Sidecar в pod нашго deployment. Обычно при выполнение helm upgrade проблем не возникает, чаще всего проблемы могут возникнуть если мы выполнили helm rollback или “стопнули” helm upgrade —install.
Как работает 3 way merge:
1 - Получаем манифесты ресурса из релиза который установлен в кластере k8s
2 - Получаем манифесты из чарта который хотим установить/обновить
3 - Получаем манифест из кластера k8s (самый спорный пункт, много думал)
4 - Собираем в кучу все 3 манифеста и мержим их
5 - Отправляем PATCH запрос в k8s
Что бы решить проблему 3WM, пришел новый механизм под названием Server-Side Apply или SSA
Он “из коробки” лишен недостатков 3WM и выполняет гораздо меньше действий с ресурсами:
1 - Получаем манифесты из чарта
2 - Отправляем PATCH запрос в k8s
Ииии у нас все работает хорошо =)
А если вы давно пользуетесь ArgoCD, скорее всего server-side apply включен у вас для большинства ресурсов =)
ЗЫ - с приколами 3WM периодически сталкиваемся, решений обычно два, отправиться править ресурсы руками внутри k8s, сделать helm uninstall и развернуть приложение заново.
🔥8👍4❤2
Grafana Tempo - бьем рекорды, весело чиним упавшее
Коллеги, всем привет!)
#Рубрика - по горячим следам
Пятница, новый год, что еще может быть лучше?=)
В очередной раз побили рекорд по трейсам и все бы ничего, но пришлось нашему Grafana Tempo немного полежать. Ingester не пережил пиковой нагрузки, отвалился по OOM, а потом не смог стартануть. С OOM все более менее понятно, выросла нагрузка - подкинь ресурсы, но приключения только начались.
Основная ошибка у нас была следующая:
О чем она - Ingester и Distributor при помощи протокола Gossip Ring собираются в кластера для синхронизации, обмена информацией и балансировки нагрузки. И для Ingester кластер развалился. Ну развалился и развалился, можно все почистить и собрать заново, данные то не критичные. А как это сделать?
1 - перезапустить поды Ingester`а (ууупс, ошибка на месте =))
2 - почистить PV (Ошибка снова на месте =))
3 - пойти почитать документацию (Надо было сделать это сразу)
Оказалось что у Distibutor есть свой api через который вы сможете посмотреть “что-где-куда” и посмотреть что с Ring Status. Доступен api по следующем эндпоинтам:
Благодаря этому мы сможем увидеть общее состояние кластера Ingester и в случае если в кластере есть проблемные ноды Ingester`а удалить их. После этого кластер благополучно соберется снова =)
ЗЫ - на скриншоте в пике 1.33kk трейсов в секунду =)
Коллеги, всем привет!)
#Рубрика - по горячим следам
Пятница, новый год, что еще может быть лучше?=)
В очередной раз побили рекорд по трейсам и все бы ничего, но пришлось нашему Grafana Tempo немного полежать. Ingester не пережил пиковой нагрузки, отвалился по OOM, а потом не смог стартануть. С OOM все более менее понятно, выросла нагрузка - подкинь ресурсы, но приключения только начались.
Основная ошибка у нас была следующая:
found an existing instance(s) with a problem in the ring, this instance cannot become ready until this problem is resolved. The /ring http endpoint on the distributor (or single binary) provides visibility into the ring
О чем она - Ingester и Distributor при помощи протокола Gossip Ring собираются в кластера для синхронизации, обмена информацией и балансировки нагрузки. И для Ingester кластер развалился. Ну развалился и развалился, можно все почистить и собрать заново, данные то не критичные. А как это сделать?
1 - перезапустить поды Ingester`а (ууупс, ошибка на месте =))
2 - почистить PV (Ошибка снова на месте =))
3 - пойти почитать документацию (Надо было сделать это сразу)
Оказалось что у Distibutor есть свой api через который вы сможете посмотреть “что-где-куда” и посмотреть что с Ring Status. Доступен api по следующем эндпоинтам:
#localhost в данном случае "форвартнутый" сервис k8s distibutor
http://localhost:3200/status #общий статус
http://localhost:3200/ingester/ring #Ingester Gossip Ring Status
Благодаря этому мы сможем увидеть общее состояние кластера Ingester и в случае если в кластере есть проблемные ноды Ingester`а удалить их. После этого кластер благополучно соберется снова =)
ЗЫ - на скриншоте в пике 1.33kk трейсов в секунду =)
🔥9👍3
Коллеги, всем привет!=)
От всей души поздравляю вас с наступившим Новым Годом🎄
Во многих каналах вчера подводились итоги года, у себя я это делать не стал
Лучше я напишу про планы на 2025, а "их есть меня" (с)
— DevOps Conf 2025 Гибкое управление доступами для распределенной инфраструктуры - ооо, это будет весело =)
— Мы с коллегами планируем организовать большой митап основная тема которого будет связана с инфраструктурой для сервисов (да-да, ко многим из вас я буду приходить в личку и зазывать что нибудь рассказать)
— С коллегой планируем сделать подкаст про нелегкую жизнь DevOps/Platform engineer
— Думаю, что получится стать членом программного комитета одной большой конференции и сделать ее еще круче ^_^
— Надеюсь что у меня получится писать сюда больше различных, полезных заметок =)
Ииииии, это только те планы которые есть сейчас, дальше-больше =)
ЗЫ - спасибо вам большое, что остаетесь со мной, читаете мои посты, пишите комментарии =)
От всей души поздравляю вас с наступившим Новым Годом
Во многих каналах вчера подводились итоги года, у себя я это делать не стал
Лучше я напишу про планы на 2025, а "их есть меня" (с)
— DevOps Conf 2025 Гибкое управление доступами для распределенной инфраструктуры - ооо, это будет весело =)
— Мы с коллегами планируем организовать большой митап основная тема которого будет связана с инфраструктурой для сервисов (да-да, ко многим из вас я буду приходить в личку и зазывать что нибудь рассказать)
— С коллегой планируем сделать подкаст про нелегкую жизнь DevOps/Platform engineer
— Думаю, что получится стать членом программного комитета одной большой конференции и сделать ее еще круче ^_^
— Надеюсь что у меня получится писать сюда больше различных, полезных заметок =)
Ииииии, это только те планы которые есть сейчас, дальше-больше =)
ЗЫ - спасибо вам большое, что остаетесь со мной, читаете мои посты, пишите комментарии =)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥10❤3
Infrastructure meetup
Коллеги, всем привет! =)
Рассказывая про планы на 2025 год я упоминал, что мы планируем сделать большой онлайн/офлайн митап посвященный инфраструктуре
Рабочее название “Infrastructure meetup”, да-да название в процессе может измениться, но суть и цель останутся неизменными
А суть и цели следующие, рассказать/поделиться опытом о:
— Построение отказоустойчивой инфраструктуры
— Chaos Engineering - тестирование отказоустойчивости инфраструктуры
— Резервные площадки и мультиклауд
— “Отказоустойчивость поверх отказоустойчивости облака”
В рамках митапа мы, сейчас я про Magnit OMNI, поделимся как устроена наша инфраструктура для бизнес сервисов и вспомогательных компонентов, как мы обеспечиваем отказоустойчивость инфраструктуры, Observability в рамках распределенной инфраструктуры, какие у нас есть вспомогательные протоколы в случае если у нас все идет ну совсем не так
Если у вас есть предложения/пожелания/темы - велкам в комментарии или в лс
ЗЫ - а еще я очень скоро начну ходить к некоторым в личку и зазывать в спикеры =)
Коллеги, всем привет! =)
Рассказывая про планы на 2025 год я упоминал, что мы планируем сделать большой онлайн/офлайн митап посвященный инфраструктуре
Рабочее название “Infrastructure meetup”, да-да название в процессе может измениться, но суть и цель останутся неизменными
А суть и цели следующие, рассказать/поделиться опытом о:
— Построение отказоустойчивой инфраструктуры
— Chaos Engineering - тестирование отказоустойчивости инфраструктуры
— Резервные площадки и мультиклауд
— “Отказоустойчивость поверх отказоустойчивости облака”
В рамках митапа мы, сейчас я про Magnit OMNI, поделимся как устроена наша инфраструктура для бизнес сервисов и вспомогательных компонентов, как мы обеспечиваем отказоустойчивость инфраструктуры, Observability в рамках распределенной инфраструктуры, какие у нас есть вспомогательные протоколы в случае если у нас все идет ну совсем не так
Если у вас есть предложения/пожелания/темы - велкам в комментарии или в лс
ЗЫ - а еще я очень скоро начну ходить к некоторым в личку и зазывать в спикеры =)
🔥13👍5❤3
Что-то моргнуло
Коллеги, всем привет!)
Многие из вас на своей шкуре вчера в 17-00 ощутили падение буквально всего
В нашем случае это выразилось в том, что как будто бы большая часть наших клиентов “испарилась”
Конечно же мы пошутили всякие разные шутки про DNS, BGP, уборщицу в серверной и все такое и стали следить за ситуацией и думать, а что же все таки произошло и что делать
По итогу через примерно через 30 минут “все отлегло”
На графике который я приложил видно как раз этот инцидент
Обычной историей в такой ситуации является burst нагрузка, проще говоря клиенты сидели/ждали, все починилось и они резко начали пользоваться приложением
По итогу мы получили +10к RPS к привычным RPS в это время года/суток/etc.
Burst нагрузку мы пережили без проблем, автомасштабирование и вот это вот все
В ситуациях когда по какой либо причине мы перестаем быть доступными для клиентов и потом восстанавливаемся всегда стоит учитывать burst нагрузку, что бы не прилечь снова =)
Коллеги, всем привет!)
Многие из вас на своей шкуре вчера в 17-00 ощутили падение буквально всего
В нашем случае это выразилось в том, что как будто бы большая часть наших клиентов “испарилась”
Конечно же мы пошутили всякие разные шутки про DNS, BGP, уборщицу в серверной и все такое и стали следить за ситуацией и думать, а что же все таки произошло и что делать
По итогу через примерно через 30 минут “все отлегло”
На графике который я приложил видно как раз этот инцидент
Обычной историей в такой ситуации является burst нагрузка, проще говоря клиенты сидели/ждали, все починилось и они резко начали пользоваться приложением
По итогу мы получили +10к RPS к привычным RPS в это время года/суток/etc.
Burst нагрузку мы пережили без проблем, автомасштабирование и вот это вот все
В ситуациях когда по какой либо причине мы перестаем быть доступными для клиентов и потом восстанавливаемся всегда стоит учитывать burst нагрузку, что бы не прилечь снова =)
👍13🔥9
Kubectl neat
Коллеги, всем привет!)
На просторах интернета/чатиков проскочил интересный плагин для kubectl
Иногда бывает нужно получить спецификацию какого-то объекта из kubernetes в yaml формате
Конечно же мы можем выполнить команду:
И получить в консоль здоровенный yaml в котором помимо спецификации объекта будет большое количество мета информации об объекте (creationtimestaml, uid, etc., всякое что нам может и не понадобиться)
Kubectl neat позволяет удалить все эти поля и оставить нам более-менее чистый манифест который гораздо удобнее в случае чего разбирать/использовать
Поставляется kubectl neat как плагин или же как отдельный бинарь
Установить neat можно следующим образом:
Пример использования:
Коллеги, всем привет!)
На просторах интернета/чатиков проскочил интересный плагин для kubectl
Иногда бывает нужно получить спецификацию какого-то объекта из kubernetes в yaml формате
Конечно же мы можем выполнить команду:
kubectl get object-name 4to-to-tam -o yaml
И получить в консоль здоровенный yaml в котором помимо спецификации объекта будет большое количество мета информации об объекте (creationtimestaml, uid, etc., всякое что нам может и не понадобиться)
Kubectl neat позволяет удалить все эти поля и оставить нам более-менее чистый манифест который гораздо удобнее в случае чего разбирать/использовать
Поставляется kubectl neat как плагин или же как отдельный бинарь
Установить neat можно следующим образом:
kubectl krew install neat
Пример использования:
kubectl get object-name 4to-to-tam -o yaml | kubectl neat
### OR
kubectl neat get -- object-name 4to-to-tam -o yaml
👍8🔥3