Пятничный деплой
4.74K subscribers
1.51K photos
35 videos
167 files
7.94K links
Подборка ссылок, статей и постов из мира DevOps\SRE\разработки. Если вы хотите прислать фидбек, интересную статью или просто поболтать пишите @count0ru https://xn--r1a.website/s/count0_digest
Download Telegram
Тут Флант Prometheus форкнули переписали с кучей оптимизаций. Пост на Хабре большой с кучей подробностей + провели сравнение с VictoriaMetrics. Сам я ещё, естественно, не успел попробовать, но выглядит многообещающе

Если подобным образом проанализировать все лейблы на реальных данных, получится, что:

- 32,7 % из них имеют всего одно возможное значение, например true или 0;
- 60 % — от 2 до 255 значений, то есть укладываются в 1 байт;
- 7,3 % — от 256 до 5275 значений;
- 0 % — больше 65 535 значений.

Это значит, что все возможные значения укладываются в два байта.

Мы решили хранить все ID (#0, #1, #2 и т. д.) не в четырёхбайтных значениях, а как два бита, указывающие количество байт, в которые укладывается число, плюс значение.

Это дало нам очередной выигрыш по памяти — теперь весь labelset для 1 миллиона метрик стал занимать 30 МБ. Это в 30 раз лучше стартовых 762 МБ.
. . .
Оптимальное хранение строк дало приличный выигрыш и в индексе. Если раньше в нём были строки и хэш-таблицы, которые не особенно оптимально хранятся в памяти, то в нашей реализации есть ID, которые выдаются по порядку. Это позволяет хранить в кэше четырехбайтные числа uint32 и заменить хэш-таблицы на sparse-векторы и Bitset.

В итоге основным потребителем памяти у нас стали точки. Prometheus хранит их достаточно компактно: он использует Gorilla Encoding и битовые операции. Это не значит, что оптимизировать нечего, но для этого надо внимательно посмотреть на данные.
. . .
Оказалось, что уникальных последовательностей временных меток всего 10 % от миллиона. Эта оптимизация позволила выиграть 55,5 % по памяти просто за счёт дедупликации.
. . .
После всех преобразований мы получили выигрыш по хранению точек почти в три раза: изначальные 787,72 МБ превратились в 283,9 МБ. При этом чем больше данных и серий, тем лучше срабатывает наша оптимизация. Если на одном миллионе метрик мы выиграли по хранению точек в 2,7 раза, то на трёх миллионах это будет уже три с небольшим раза.
. . .
В процессе работы Prometheus пишет WAL. Мы оптимизировали журнал предзаписи примерно в 19 раз. Изначальные 6,2 ГБ без сжатия в Prometheus v2 для 1 миллиона метрик превратились в 153 МБ в Deckhouse Prom++.

Deckhouse Prom++: мы добавили плюсы к Prometheus и сократили потребление памяти в 7,8 раза
https://habr.com/ru/companies/flant/articles/878282/
+
Deckhouse Prom++
https://github.com/deckhouse/prompp/

Чат: @prom_plus_plus
👍171👎1
Радует когда подписчики делятся своими наработками, спасибо!
👍5
🛠 tenv — универсальный менеджер версий для OpenTofu, Terraform, Terragrunt и Atmos
В проектах с разными версиями Terraform, OpenTofu, Terragrunt или Atmos важно быстро и надёжно переключаться между ними. tenv автоматизирует этот процесс и делает его максимально удобным.

Возможности:
• Гибкое управление версиями — легко переключайтесь между версиями OpenTofu, Terraform, Terragrunt и Atmos
• Автоматическое определение версии — анализирует все релевантные конфигурационные файлы и точно подбирает нужную версию
• Проверка подписи — поддержка PGP (через gopenpgp) и cosign
• Быстрее и стабильнее, чем tfenv и аналоги — написан на Go, без Shell-магии
• Кроссплатформенный — работает на Linux, macOS, Windows и других ОС
• Простая установка — доступен через Homebrew, APT, Chocolatey и другие пакетные менеджеры
• Использование как Go-модуля — предоставляет стабильный API через tenvlib для интеграции в собственные решения

tenv совместим с синтаксисом tfenv / tofuenv, но предлагает более надёжную архитектуру и современный подход к управлению версиями в DevOps- и SRE-процессах.
👍8🔥6👎21
Forwarded from Мониторим ИТ
Редтимим мониторинг: рекон Grafana

Статья о том, что можно достать из Grafana, которая одной ногой торчит в интернете. Проверьте, хорошо ли она у вас защищена.
Forwarded from about:performance
CPU Isolation: исследование в шести частях о применение техник CPU Isolation для задержкочувствительных нагрузок.

Недостаточно просто выгнать все процессы, кроме целевого, с ядра с помощью cpuset и привязать его к CPU через taskset. Надо не забыть и о фоновых задачах ядра, т.н. housekeeping work.

Housekeeping work – это совокупность фоновых операций, которые ядро Linux выполняет для поддержания своей внутренней инфраструктуры. Эти задачи включают обработку таймеров, обновление системного времени, управление очередями отложенной работы (workqueues), обработку прерываний, очистку ресурсов и прочее. Несмотря на то, что они обычно незаметны для пользователя, именно эти операции обеспечивают стабильность и корректное функционирование всей системы.


Оборотной стороной housekeeping work является то, что она привносит непредсказуемые задержки (jitter), прерывая выполнение пользовательских задач.

Борьба с этими задержками и есть центральная тема цикла.
Самое инересное с P99

Хотел сделать обзор основных докладов с недавнего Monster Scale Summit, но как будто там не было ничего настолько яркого, как на P99. А вот как раз в марте организаторы выложили довольно много материала на YouTube. И поскольку обзора P99 я не делал, я решил поделиться с вами тремя на мой взгляд важными выступлениями: Майкла Стоунбрейкера, Энди Павло и Керри Осборна.

За 3 недели у всех видео невысокое количество просмотров, количество лайков, что в целом конечно говорит и о качестве аудитории, и о маркетинге организаторов - но не обращайте на это внимания, доклады - золото, особенно первый.

🤩 The Next Chapter in the Sordid Love/Hate Relationship Btwn DBs & OSes // Andy Pavlo (Carnegie Mellon University)
https://www.youtube.com/watch?v=vD-0dw4gUhw

Это доклад стоило назвать “как eBPF может помочь базам данных”, но вообще там космос. Фокус делается отдельно на stateless (прокси-пулеры-баунсеры) и stateful (собственно субд) приложения. В лаборатории Павло сделали два прототипа, в докладе рассказывается что сделано и какие результаты. По прокси это продукт под названием Tigger, форк баунсера с оптимизациями, в сравнении и с оригинальным баунсером, и с Yandex Odyssey (про который кстати Павло отозвался позитивно) - работает быстрее. Коллеги из Яндекса, если вы друг пропустили - посмотрите. По СУБД - они сделали проект BPF-DB и позиционируют его как потенцильный сторадж-бекенд для более сложных СУБД. Там внутри прям кернел-матан, они сделали прототип и ресерч, очень похожий на то, что мы в devhands сделали в 2024м году: сравнили performance KV решений со своим, Redis, KeyDB, Dragonfly, BPF-DB. Посмотрите, если интересно, там сюрприз, там супер-круто выглядит Dragonfly. Valkey и Memcached там нет.

🤩 You’re Doing It All Wrong // Michael Stonebraker (MIT)
https://www.youtube.com/watch?v=Rzwift2iJlM

Этот доклад - промоушен проекта Стоунбрейкера DBOS, эдакий “Temporal на хранимках, только хранимки на js или питоне”. Доклад интересен в любом случае – тем, что это Стоунбрейкер. Тем, как он смотрит на проблему workflow, конситенстности, саг. Что предлагает для решения и что считает важным. Некоторые утверждения спорны, но в целом не снижает ценности. Из него я кстати узнал про Firecracker, потому что в нашем облаке старт vm за секунды стоит супер-остро (и мы эту задачу пока не решили).

🤩 How to Improve Your Ability to Solve Complex Performance Problems // Kerry Osborne (Google)
Part 2: https://www.youtube.com/watch?v=vvDnaISGCPI
Part 1: https://www.youtube.com/watch?v=F57m48x4OZ0 (это 2023, “предыстория”)

Доклад про то, как работают люди в области тюнинга производительности. Совсем не технологический доклад, но на супер-важную тему: что за функция мозга “умение решать сложные проблемы”, как её прокачивать. Интуиция и Анализ, две системы мышления, что и когда лучше работает. Какие упражнения могут помочь задействовать “дополнительные способности” мозга. Докладчик работает в группе производительности СУБД, он конечно бьет просто в точку: in performance tuning world there’s a lot of pressure. Так что ещё одна из тем это адреналин/кортизол, какие техники могут уменьшить влияние гормонов на способность думать в стрессовой ситуации. Здорово было бы конечно им коллаборацию с нейрофизиологом. Но в целом Music beats Valium, я согласен. Вообще, Music is the best, как говорил Заппа.

Enjoy! Новости тоже выпустим, но позже, хотелось бы поглубже разобраться, что за косяк посадили в nginx ingress, что дошло аж до 0-day IngressNightmare.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Forwarded from about:performance
CPU Isolation: исследование в шести частях о применение техник CPU Isolation для задержкочувствительных нагрузок.

Недостаточно просто выгнать все процессы, кроме целевого, с ядра с помощью cpuset и привязать его к CPU через taskset. Надо не забыть и о фоновых задачах ядра, т.н. housekeeping work.

Housekeeping work – это совокупность фоновых операций, которые ядро Linux выполняет для поддержания своей внутренней инфраструктуры. Эти задачи включают обработку таймеров, обновление системного времени, управление очередями отложенной работы (workqueues), обработку прерываний, очистку ресурсов и прочее. Несмотря на то, что они обычно незаметны для пользователя, именно эти операции обеспечивают стабильность и корректное функционирование всей системы.


Оборотной стороной housekeeping work является то, что она привносит непредсказуемые задержки (jitter), прерывая выполнение пользовательских задач.

Борьба с этими задержками и есть центральная тема цикла.
🔥1
Forwarded from DevOps Kitchen Talks (Alexander Dovnar)
Приветик всем! В этот тяжелый понедельник после солнечного затмения и вспышек на солнце мы опубликовали выпуск #74.

В новом выпуске Виктор побеседовал с ключевыми лицами конференции "DevOpsConf", которая через неделю отмечает 10 лет.
В выпуске мы поговорили с cовладелецем\генеральным директором компании «Флант» Александром Титовым и Head of SRE Дмитрием Зайцевым о истории конференции, современных трендах в докладах и мире IT в целом. И конечно затронули такие трендовые темы как eBPF 🙂

Просмотр, лайк, репост 🙂

https://youtu.be/lP6oKlAacN0
👍7
Forwarded from Go Library
Patterns and Techniques for Writing High-Performance Applications with Go

https://goperf.dev
👍1
Forwarded from Ever Secure (Aleksey Fedulaev)
Друзья, после первого выпуска получили много ваших отзывов, подготовили для вас новый материал 🎬

01.04 в 19:00 Созвон сообщества в Zoom.
Тема: Карьера в ИТ
Поговорим про:
Как успешно проходить интервью и испытательный срок?
Самые частые ошибоки при инкрейзе зарплаты?
Внутренняя ротация - хорошо или плохо?
Что такое стеклянный потолок?
Куда лучше качаться в менеджера или эксперта?
Кто такие карьерные консультанты?
Как понять, что пора увольняться?

В гостях:
Яна Шаповалова (Руководитель отдела подбора персонала и бизнес-партнерства BI.ZONE) и Саша Кондратьев (Руководитель отдела DevOps BI.ZONE, автор канала "Админим с Буквой" @bykvaadm)

Предыдущий выпуск: https://xn--r1a.website/ever_secure/644

Ссылка: Zoom
Событие добавлено в календарь мероприятий ссыль, добавляй к себе, что бы не пропустить 😉

👀@ever_secure
Please open Telegram to view this post
VIEW IN TELEGRAM
1👎1🔥1
Forwarded from Ever Secure (Aleksey Fedulaev)
Стартуем через 5 минут, залетайте на стрим 😉
👎2
Forwarded from HABR FEED + OPENNET
Отказоустойчивость в MinIO #habr
https://habr.com/ru/companies/habr_rutube/articles/895286/
Tags: minio, отказоустойчивость, s3, репликация, хранение данных
Author: stratnevpy (RUTUBE)
2👎2
Сегодня в 18:00 MSK ждём всех на открытую встречу Devhands: выбор брокера и системы очередей в 2025м.

Kafka, Rabbit, NATS или что-то ещё?

Своро выясним! Уже через час начнется очередная открытая встреча Devhands.

У меня в гостях будет Владимир Перепелица, эксперт по большим проектам, очередям и Tarantool, Solution Architect в Exness, создатель S3 в VK Cloud, регулярный спикер и член ПК конференций Highload.

Будем обсуждать:
- выбор брокера и системы очередей 2025м году, что поменялось?
- NATS, его особенности, перспективы, кого он “подвинет” в первую очередь, Kafka или RabbitMQ?
- что нового в свежей Apache Kafka 4?
- насколько популярны архитектуры, где, например, Kafka основной storage (IoT, сбор метрик и тд)

Бесплатно, без регистрации и sms:
https://www.youtube.com/@AlexeyRybak/streams. Запись будет - там же в стримах.

Приходите, будет интересно.
👍1👎1
Forwarded from Мониторим ИТ
Эй, где моя ошибка? Как OpenTelemetry фиксирует ошибки

В зависимости от языка программирования, на котором вы привыкли работать, у вас могут быть определённые представления о том, что такое ошибка, что такое исключение и как его следует обрабатывать. Например, в Go нет исключений — отчасти для того, чтобы отбить у программистов желание причислять слишком много обычных ошибок к «исключительным». С другой стороны, в Java, Python и т. п. поддержка для работы с исключениями встроена.

Когда разные языки расходятся во мнении, что такое ошибки или исключения и как их обрабатывать, возникает вопрос: что использовать, если нужны стандартизированная телеметрия и отчёты об ошибках для микросервисов, написанных на этих языках? OpenTelemetry отвечает на него. Читать дальше на Хабре.
Forwarded from /usr/bin
Шардированный кластер ClickHouse

Про ClickHouse как MPP-систему (Massively Parallel Processing) не так много информации можно найти в открытом доступе, но многое можно рассказать. Автор этой статье делится своим опытом и считает, что его рассказ поможет кому-нибудь сформировать целостную картину о том, как в ClickHouse спроектированы распределённые вычисления. Читать на Хабре.
Подробный разбор инцидента от 30 марта в Яндекс Облаке

Что случилось?

В период с 30.03.2025 12:25 по 31.03.2025 00:00 (МСК) сервисы Yandex Cloud, расположенные в зоне ru-central1-b, были недоступны. Инцидент был вызван двойным отказом по питанию из-за сбоя на городской высоковольтной подстанции, питающей ряд областных и промышленных объектов, включая дата-центр Яндекса.
. . .
Предотвращение

Корневая причина инцидента – потеря напряжения на двух независимых источниках питания одновременно. Команда Yandex Cloud анализирует возможные варианты предотвращения этого риска (включая вариант добавления третьего независимого источника питания). Об итоговом решении мы сообщим дополнительно.

Резюме по инциденту
https://status.yandex.cloud/ru/incidents/1129
👎14👍4