DevOps Brain 🧠

Channel name was changed to «DevOps Brain 🧠»

Channel name was changed to «DevOps Brain»

📎 Dive in performance tools. Часть 1️⃣ [sysdig]

Котлеги, привет. Вдохновленный серией статей от Евгения Козлова про CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async, я решил написать свой цикл статей по инструментам диагностики производительности linux с примерами.

Сегодняшний обзор я начну с тулы, которая по своей сути является серебрянной пулей в вопросах диагностики проблем с производительностью - sysdig. Конечно, чаще всего ее использование бывает избыточным, но может настать тот момент, когда штатных средств может не хватить и на помощь придет sysdig.

Long story short - sysdig использует модуль ядра для перехвата системных вызовов и событий, что открывает нам невероятные возможности в плане диагностики. Вы буквально можете расковырять практически все что происходит у вас в системе. Можно использовать realtime-диагностику или собрать трейс с системы за определенный период, обычно при проблемах достаточно до 30 секунд сбора данных.

# Установка sysdig
curl -s https://download.sysdig.com/stable/install-sysdig | sudo bash

Есть небольшой минус - sysdig требует заголовки ядра (kernel headers), потому что он использует модуль ядра для перехвата системных вызовов и событий. Но глобально это влияет только на скорость установки и требуется немного места.

Допустим у вас есть какая-то лагучая нода и базовые инструменты дигностики/логи вам не особо помогли. Давайте посмотрим на живом примере как ее использовать.

# Запускаем запись всех эвентов на 30 секунд 
sysdig -w capture.scap -M 30

Конечно можно не использовать GUI, а вытащить из трейса событий нужные данные. Но это обычно работает, если вы точно знаете что искать. Например так] (без GUI)

# Вывести срезы которые доступны в этом трейсе (тут вы получите список срезов в различных категориях. Например, bottlenecks - cамые медленные системные вызовы) 
sysdig -r capture.scap  -cl

# выведем top процессов утилирующих cpu
root@server:~# sysdig -r capture.scap -c topprocs_cpu
CPU%                Process             PID
--------------------------------------------------------------------------------
15.00%              redis-server        1095390
12.60%              redis-server        1095391
12.20%              redis-server        1095375
....

# Показать top файлов с которыми велась работа (R+W) 
root@server:~# sysdig -r capture.scap -c topfiles_bytes proc.name=redis-server
Bytes               Filename
--------------------------------------------------------------------------------
72.00M              /data/temp-27.rdb
40.00M              /data/temp-28.rdb
82.72KB             /proc/self/stat
.....

Как я и сказал ранее, все эти данные есть в realtime и можно просто запустить GUI csysdig, но проблема может быть плавающая. В таком случае есть шанс просто пропустить нужные данные. Поэтому, я рекомендую снимать трейс эвентов и работать с ним.

# Открываем консольный GUI и скармливаем ему capture.scap
csysdig -r ./capture.scap

После этого переходим в режим Views (F2) и можем нырять на столько глубоко на сколько у вас хватит фантазии.

Перед нами открываются все тайны нашей системы: что именно передавалось установленным соединением определенного процесса. Сколько данных было передано, порты, ip адреса и тд. Какие ошибки происходили в системе и в каких процессах. Какие процессы какие файлы писали с каким рейтом. Какие открывались каталоги, какие контейнеры работали и какие процессы были запущеные внутри, какие действия делали эти контейнеры. Какие происходили ошибки Page Faults. Где какой был латенси на файлах. Какие порты были открыты и сколько с них было переданно данных. Этот список можно продолжать бесконечно.

А на этом все - спасибо за внимание.

В следующий раз расскажу о более простых инструментах первичной диагностики. А также попробую записать видео-урок с разбором инструмента

Ссылка на habr: https://habr.com/ru/articles/876160/

В продолжении темы про терминалы - недавно наткнулся на https://tabby.sh. Я погонял его пару дней - есть небольшие баги, но в целом как альтернативна терминалу очень даже огонь.

🟢 Работает на Windows, Mac и Linux.
🟢 Встроенный SSH-клиент с менеджером подключений.
🟢 Встроенный терминал для работы с последовательными портами.
🟢 Поддержка PowerShell, PS Core, WSL, Git-Bash, Cygwin, Cmder и CMD.
🟢 Полная поддержка Unicode, включая символы двойной ширины.
🟢 Передача файлов в/из SSH-сессий через SFTP и Zmodem.
🟢 Темы оформления и цветовые схемы.
🟢 Полностью настраиваемые горячие клавиши, включая составные комбинации.
🟢 Запоминает ваши вкладки и разделенные панели.
🟢 Полноценный опыт работы с Shell на Windows, включая автодополнение.
🟢 Встроенный зашифрованный контейнер для хранения SSH-секретов и настроек.

#tools

Всем привет, я тут показывал недавно как сделать такую красоту котлеге и сразу записал небольшой гайд. Хотите такой же zsh на стеройдах? Без проблем!

Будем юзать Oh My Zsh, который позволит нам получить:

✨ Автодополнения команд (например, Docker).
⚡ Алиасы для сокращений (например, gcb – создание ветки).
🎨 Красивую кастомизацию с темами.

# 1. Устанавливаем oh my zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

# 2. Устанавливаем шрифты
git clone https://github.com/powerline/fonts.git --depth=1
cd fonts
./install.sh
cd ..
rm -rf fonts

# 3. Устанавливаем rvm-prompt, чтобы тема не плевала ошибку
curl -sSL https://get.rvm.io | bash

# 4. Устанавливаем тему
git clone https://github.com/consolemaverick/zsh2000.git
ln -s $(pwd)/zsh2000/zsh2000.zsh-theme ~/.oh-my-zsh/themes/zsh2000.zsh-theme

Теперь пропишем нужные плагины. Полный список всех плагинов есть по ссылке https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins c детальным описанием. В любом удобном редакторе открываем ~/.zshrc и прописываем параметры.

ZSH_THEME="zsh2000"

plugins=(
  git
  macos
  docker
  docker-compose
)

В настройках терминала выставляем шрифт на Meslo LG M DZ for Powerline, Regular, 11px. Перезапускаем терминал и радуемся.

Всем привет. Надеюсь, все выжили после праздников и готовы делать мир лучше (или хуже - тут уж от каждого по способностям каждому по потребностям). 🎅

Я вам вакансию принес на Junior Devops Engineer, не проходите мимо кому актуально
https://www.aviasales.ru/about/vacancies/3870114

Всем доброго утра. Я к вам с отличной новостью.

Теперь github copilot for vscode бесплатный. Никаких подписок, триалов, карточек не требуется.

Более того, вы можете сами решать какую модель использовать.

Как активировать и другие подробности по ссылке: https://code.visualstudio.com/blogs/2024/12/18/free-github-copilot

Всем привет! А давайте разыграем новенькую обложку на паспорт с лого github 🍾

Оставляй коммент "хотеть это" (или любой другой) и в понедельник выберем победителя великим рандомом. 😁

Мониторинг и алертинг - это база. Без них не может нормально ехать ни один продукт и ни один бизнес. Если говорить про IT, то чтобы иметь полную картину у вас должны быть:

🟢 Infrastructure-related alerts - например, высокая утилизация CPU на ноде
🟢 Application-related alerts - например, прилка начала сыпать 500-ми ошибками
🟢 Business-related alerts - например, снижение конверсии

✍️ Давайте разберем простой кейс, вам прилетел алерт на CPU от ноды с postre в проде. Дежурный инженер открывает борду в grafana ( или zabbix ), смотрит какие то общие показатели. Потом подключается к базе, смотрит какие запросы сейчас обрабатываются, читает логи и тд. И принимает дальнейшие решения по тому в кого эскалировать проблему или решает вопрос сам. И вот этот порядок действий практически всегда один и тот же.

🔛 Как было бы круто дообогатить алерт уже подготовленной информацией. Например, получить вместе с алертом список выполняющихся сейчас запросов в базе и их потребление по ресурсам. (Например, через SELECT pid AS process_id, query AS active_query FROM pg_stat_activity WHERE state = 'active'; )

🧠Вот ребята из keephq тоже так подумали и запилили просто офигенскую прилу, добавив нереальное количество интеграций (провайдеров), которые можно интегрировать в различные флоу обработки алертов

Просто взгляните на список провайдеров: AKS, AppDynamics, Auth0, Axiom, Azure, BigQuery, Centreon, Chat, Checkmk, Cilium, Clickhouse, Cloud, Cloudwatch, Coralogix, Datadog, Discord, Elastic, GCP, GKE, GitHub, GitLab, Google, Grafana, Graylog, Incident, Jira, Kafka, Kubernetes, Linear, LinearB, Mailchimp, Manager, Mattermost, Microsoft, MongoDB, Monitor, Monitoring, MySQL, Netdata, New, Now, On-Prem, OnCall, OpenAI, OpenObserve, Openshift, OpsGenie, PagerDuty, PagerTree, Pipelines, Planner, PostgreSQL, Pushover, QuickChart, Redmine, Relic, Resend, Rollbar, SIGNL4, SMTP, SSH, SendGrid, Service, SignalFx, Slack, Snowflake, Splunk, Squadcast, Statuscake, SumoLogic, Teams, Telegram, Trello, Twilio, UptimeKuma, Webhook, Zenduty

https://github.com/keephq/keep

Я пока сам не тестровал, но выглядит это просто 🔥 В ближайшее время буду поднимать и тестировать, а результатами поделюсь с вами 👍

Нашел консольный аналог postman - как вам? По-моему выглядит круто, там даже command palette есть 🤯Правда ставится через uv. 🙁

https://github.com/darrenburns/posting

#tools

Давайте познакомимся с таким инструментом как grafana k6. С помощью него вы можете производительность ваших приложений и тестирование хаоса (Это метод, используемый для проверки устойчивости программных систем путем внесения непредвиденных сбоев или сбоев. Целью хаотического тестирования является выявление слабых мест и повышение устойчивости приложения)

Основной фичей инструмента является то, что вы можете писать довольно сложные сценарии тестирования используя javascript. k6 легко запускается из командной строки и хорошо интегрируется в CI/CD пайплайны, а также эмулирует работу виртуальных пользователей.

Ниже пример моего кейса. Надо было протестировать как себя ведет балансировщик. Поскольку балансер еще работает не в боевом режиме, надо отправить на IP адрес балансера заголовок с нужным хостом и игнорированием https. В примере мы в течении 30s плавно повышаем нагрузку до 1000 виртуальных пользователей, держим 30 секунд и далее в течении 20 секунд уменьшаем нагрузку до 0.

import http from "k6/http";
import { check, sleep } from "k6";

// Test configuration
export const options = {
  thresholds: {
    // Assert that 99% of requests finish within 3000ms.
    http_req_duration: ["p(99) < 3000"],
  },
  stages: [
    { duration: "10s", target: 1000 },
    { duration: "30s", target: 1000 },
    { duration: "20s", target: 0 },
  ],
  // ignore ssl valudation
  insecureSkipTLSVerify: true,
};

// Simulated user behavior
export default function () {
  const url = "https://my.loadbalancer.ip.address"; // Set load balancer host

  // set header hosts
  const headers = {
    Host: "example.com", 
  };

  let res = http.get(url, { headers });

  check(res, { "status was 200": (r) => r.status == 200 });

  sleep(1);
}

В результате вы получите супер подробный отчет по производительности.

На самом деле это довольно базовый сценарий, но сила k6 в возможности наращивать и усложнять логику, ограниченную только вашей фантазией. Примеры использования вы найдете в официальной документации https://grafana.com/docs/k6/next/get-started/running-k6/

Сначала Линупс Торвальдс выпилил код российских разработчиков из ядра. Теперь вот тут отклонили PR за русскость https://github.com/reactor/reactor-core/pull/3897#issuecomment-2460103961.

А сегодня я орнул. Короче, есть такая прикольная штука для доставки миграций в базы bytebase зовется. Штука реально крутая, работать можно практически с любой субд, есть gitops, разные флоу, роли права доступа и тд. Ну красота в-общем. Но есть один косячек который глаз мозолит - поскольку у нас оно запущено в кубе, то конечно хочется что бы контейнер bytebase отдавал в логи в json. Пошел я искать как можно это реализовать и нашел кусочек недокументированного кода, где задать вывод лога в json можно сделать через параметр saas. Причем параметр влияет еще на кучу всего в приложении и юзается для их клаудовой версии. Ну думаю "непорядок" - надо запилить пулик и вынести все в отдельный параметр.

Закидываю пулик https://github.com/bytebase/bytebase/pull/14375 и получают фейл чекам verification/cla-signed и коммент

We require contributors to sign our Contributor License Agreement, and we don't have yours on file. In order for us to review and merge your code, please sign CLA and add your name to contributors list.

Там ссылка на гугл форму что я согласен контибутить. А также надо заполнить из какой я страны, мой адрес и почта. И надо добавить себя отдельный реп с контибюторами.

OpenSource явно свернул куда то не туда, скоро скрин паспорта походу надо приложить будет. 💩 А так инструмент, конечно, классный - рекомендую кто не юзал. Всем хорошей пятницы.

Отпуск “потрачено”. Press F

👨‍💻 Нашел хипстерский htop под macos https://github.com/Abdenasser/neohtop. Пользоваться, конечно не буду, старый добрый htop все равно лучше - все таки в консоли привычнее. Но дизайн прикольный. А вам как?

#tools #macos

Channel name was changed to «DevOps Brain ✈️»

В эту прекрасную пятницу ( а прекрасная она потому что на следующей неделе я ухожу в отпуск ), делюсь порцией крутых статей и видосов

1️⃣ https://habr.com/ru/articles/852536/ - Maxpain рассказывает как искал нашел баг в параметре ядра linux и раскопал причину медленной работы дисков в Talos Linux. Много графики, полезных тулов и в целом читается на одном дыхании.

2️⃣ https://github.com/rcoh/angle-grinder - Angle grinder предназначен для случаев, когда у вас нет данных в graphite/honeycomb/kibana/sumologic/splunk/и т.д., но вы все равно хотите иметь возможность выполнять сложную аналитику. Позволяет вам в реальном времени анализировать, агрегировать, суммировать, усреднять, находить минимум и максимум, процентиль и сортировать ваши данные.

3️⃣ https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/ - Andrew Locks рассказал про фичу --update-refs для ребейзов в Git 2.38. Автор показывает различные сценарии использования --update-refs. Если вы хотите чего то нового в git - то вот оно!

4️⃣ Ну и из лайтового могу порекомендовать просмотреть видос на 20 минут про Redis. Автор (канал suchkov tech) отлично показал на примере как работает редиска на живом приложении и как в принципе кеш позволяет ускорить работу приложения минимум в несколько раз https://www.youtube.com/watch?v=QpBaA6B1U90

Ну а на этом все - всем спасибо и хорошей пятницы! 🤗️️️️️️

Накатал некий аналог service discovery для VMs и Nodes в кластере proxmox ( если вы не юзаете SDN). Принцип работы максимально простой. Фигачите обслуживание зоны (например proxmox.example.com) в proxmox-service-discovery (желательно в 2 экземплярах конечно - ну вы поняли почему). Дальше тула забирает по API все нужные данные для отдачи IP адреса и отдается по 53 (UDP, DNS)

Мапа из A записей в памяти собирается из нод, имен VM и тегов ( если нужно )

Сама тула тут https://github.com/nrukavkov/proxmox-service-discovery