Bash Days | Linux | DevOps
Авторский блог от действующего девопса Самобытно про разработку, devops, linux, скрипты, сисадминство, техдирство и за айтишную жизу. Автор: Роман Шубин Реклама: @maxgrue MAX: https://max.ru/bashdays Курс: @tormozilla_bot Блог: https://bashdays.ru
Показати більше📈 Аналітичний огляд Telegram-каналу Bash Days | Linux | DevOps
Канал Bash Days | Linux | DevOps (@bashdays) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 23 783 підписників, посідаючи 5 702 місце в категорії Технології та додатки та 28 084 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 23 783 підписників.
За останніми даними від 20 червня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на -224, а за останні 24 години на -6, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 24.67%. Протягом перших 24 годин після публікації контент зазвичай збирає 13.65% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 5 869 переглядів. Протягом першої доби публікація в середньому набирає 3 246 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 24.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як bashdays, linux, bash, docker, скрипт.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Авторский блог от действующего девопса
Самобытно про разработку, devops, linux, скрипты, сисадминство, техдирство и за айтишную жизу.
Автор: Роман Шубин
Реклама: @maxgrue
MAX: https://max.ru/bashdays
Курс: @tormozilla_bot
Блог: https://bashdays.r...”
Завдяки високій частоті оновлень (останні дані отримано 21 червня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
upstream backend {
server unix:/var/run/haproxy/backend.sock;
}
location / {
proxy_pass http://backend;
}
Ставим рядом haproxy, и конфигурируем блоки frontend и backend таким образом:
defaults retries 3 timeout check 5s frontend bashdays-backend bind /var/run/haproxy/backend.sock user nginx mode 600 mode tcp default_backend bashdays-backend option tcplog backend bashdays-backend balance roundrobin option tcplog server bashdays-w1 192.168.0.1:80 check server bashdays-w2 192.168.0.2:80 check server bashdays-w3 192.168.0.3:80 check server bashdays-w4 192.168.0.4:80 checkЧто это за хрень, щас объясню. Смотри. Клиент идет на
--collector.textfile.directory. Из коробки он не прописан в systemd, поэтому нужно самостоятельно прописать руками в файле /etc/systemd/system/node_exporter.service (у тебя может называться по другому).
ExecStart=/usr/local/bin/node_exporter --collector.textfile.directory /tmp/textfile_collectorСуть такая, указываем ему директорию, которая будет регулярно опрашиваться на наличие
.prom файлов. Соответственно эти .prom файлы мы будем генерировать с помощью bash скрипта, который засунем в крон. Файл представляет собой текстовый документ в определенном формате.
А далее все нужные нам метрики попадут автоматом в prometheus, а там глядишь и в grafana красиво всё станет.
Лепота! 🫥
Покажу на примере моего скрипта, который забирает количество оставшихся писем в квоте по API с почтового сервиса smtp и передает напрямую в prometheus.
#!/bin/bash
MAINDIR=/tmp/text_collector
METRICS=smtp.prom
rm $MAINDIR/$METRICS
count=$(curl -s -X GET "https://api.smtp/v1/user" -H "accept: application/json" -H "Authorization: superapipassword» | jq '.quota')
echo "smtp_quota{service=\"smtp_exporter\"} "$count >> $MAINDIR/$METRICS
Кидаем его в крон */1 * * * * и на выходе получаем в папке /tmp/text_collector файл smtp.prom в котором будет нечто подобное:
smtp_quota{service="smtp_exporter"} 26818
И это всё! Готовый экспортер на коленке за несколько минут! Все данные по квоте теперь лежат в параметре smtp_quota. А дальше выводим графики, ставим алерты, балдеем.
С помощью curl и jq можно парсить вообще всё что угодно и запихивать в prometheus, пусть страдает, он для этого и был создан! Ну а больше инфы по ключикам node_exporter можешь получить тут, может чего еще интересного откопаешь и с нами поделишься.
tags: #bash #monitoring
—
🟢 Подпишись: @bashdaysbashdays-b1:443 -> bashdays-w1:3000 -> bashdays-w2:3000 -> bashdays-w3:3000 -> bashdays-w4:3000К примеру от клиентов идут POST запросы к апихе, запросы попадают на сервер b1, затем nginx распределяет запросы по нодам w1-w4 и отдает в ответ json. Примитивная балансировка нагрузки, но достаточно стабильная. В какой-то момент мне необходимо добавить еще одну ноду с новой версией nodejs приложения. Назовем её
bashdays-w5. Эта нода не должна обслуживать клиентов, но должна отдавать данные тестировщикам, чтобы те могли потыкать и протестировать в условиях продакшена. Ну а ты как думал? Тестируем на проде, можем себе позволить ))) 🎉
Городим в nginx на b1 такой велосипед:
map $http_x_backend $backend {
bashdays-w5 192.168.0.5:3000; # w5
default backend;
}
upstream backend {
server 192.168.0.1:3000; # w1
server 192.168.0.2:3000; # w2
server 192.168.0.3:3000; # w3
server 192.168.0.4:3000; # w4
}
location / {
add_header X-Upstream $upstream_addr;
proxy_pass http://$backend;
}
Объясняю что происходит, клиенты идут на b1 и попадают по умолчанию в upstream backend, где прописаны ноды w1-w4.
Тестировщики подставляют заголовок X-Backend: bashdays-w5 в своих запросах и попадают на w5. То есть для обычных пользователей ничего не изменилось, но QA теперь с помощью заголовка X-Backend: bashdays-w5 могут попасть на новую ноду и затыкать ее хоть до усрачки.
В location есть директива add_header X-Upstream, она выведет в ответе nginx на какую ноду ты попал, удобно для дебага.
В раздел map можно добавить еще кучу нод, которые не будут участвовать в обслуживании клиентов, но ты в любой момент сможешь на них попасть с помощью заголовка.
Если у тебя не апиха, а веб приложение, можешь воспользоваться плагином ModHeader, есть для фокса и хрома. В нём можно легко подставить все необходимые заголовки и попасть if [[ "$THREADS" -ge "500" ]]; then logger "MYSQL THREADS OVERLOAD:" $THREADS fiСуть скрипта заключается в том, чтобы мониторить число тредов в mysql, если тредов больше 500, то в системный журнал пишется фраза «MYSQL THREADS OVERLOAD» Далее у меня есть еще один bash скрипт, так же запускается раз в минуту:
TH=$(journalctl -S -180s | grep -c 'MYSQL THREADS OVERLOAD’) if [[ "$TH" -ge "3" ]]; then systemctl reboot mysql fiЭтот скрипт читает системный журнал и проверяет, если за три минуты в журнале проскочила трижды (либо больше) фраза «MYSQL THREADS OVERLOAD», то запускается полезная нагрузка, в данном примере у меня ребутится mysql. Этот способ можно адаптировать под любые задачи и сделать быстрый мониторинг с оповещением в слак/телеграм. Костыльно? ОЧЕНЬ! Я даже не представляю сколько сейчас людей перевернулось в гробу. 🤣 Но когда под рукой нет поднятой связки prometheus + grafana + alertmanager, а заказчик требует сделать быстро и срочно, пойдёт и такое решение. Главное чтобы все были довольны. Кстати я как-то встречал у клиента подобный самописный мониторинг, он нарочно отказался от всех этих модных штук в пользу — чем проще система, тем меньше отказов. Доля правды в этом есть, ну как говорится — каждому свой костыль и велосипед. tags: #bash — 🟢 Подпишись: @bashdays
apt/yum/brew install nethogs но если ты упоротый админ, можешь из исходников собрать и ядро пропатчить 🔨
Я использую nethogs довольно редко, но метко. В последний раз была ситуация, когда ко мне пришел Selectel и попросил разобраться почему мы начали превышать полосу пропускания и наш канал несколько дней забит на 200%.
С помощью nethogs это быстро удалось вычислить, утилита показала с какого айпишника протекает и куда вытекает, далее выяснили что наша система синхронизации rclone сошла с ума и гнала терабайты данных со стораджа и прямиком в облачное хранилище.
Так же у nethogs есть различные ключи для запуска, но я ими никогда не пользуюсь, всё и так понятно без всяких надстроек и тюнинга.
Именно поэтому я тащусь от подобных утилит, где ничего не нужно конфигурировать и по факту получаешь необходимую информацию для дальнейшего дебага.
Что можно выделить по параметрам запуска
1. Выставляем время обновления в секундах (по умолчанию 1 секунда)
nethogs –d 52. Посмотреть сколько процесс передает в мегабайтах, а не его скорость (0 = KB/s, 1 = total KB, 2 = total B, 3 = total MB)
nethogs –v 3но можно этого добиться и без параметров, после запуска nethogs, нужно нажать букву m и отображение поменяется, удобно 3. Так же возможно мониторить отдельные интерфейсы
nethogs eth0 nethogs wlan04. Ну и как вишенка, в nethogs есть режим трассировки, запускается с ключом -t
nethogs -tКстати если перевести nethogs на русский язык, то дословно получается что программа называется: «сетевая свинья» ну или «сетевой боров/кабан». Название безусловно интересное, я не знаю что ты будешь делать с этой информацией, просто живи с ней )) tags: #utils — 🟢 Подпишись: @bashdays
pstree -cНу и конечно же с помощью ключа -p, можно вывести список PID’ов и PGI’ов и потом их жёстко закилить.
pstree -pЕсть еще крутая фишка, это ключ -a, с помощью него можно получить параметры конфигурации запущенных приложений. То есть допустим запущен у меня какой-то prometheus экспортер и мне надо знать с какими параметрами он запущен, выполняем:
pstree -aи получаем:
nginx_exporter -nginx.scrape-uri http://localhost/nginx_statusСказка, а не утилита! Лично для меня проще запустить pstree и не приседать вокруг ps со всеми его ключами и наворотами, грепая и страдая. Глянул на дерево визуально и понял, что php, nginx, mysql запущены, значит проблему надо искать в другом месте. pstree входит в пакет psmisc, установка стандартная
apt install psmisc, для остальных дистрибутивов аналогично yum/pacman/другое, но в osx без проблем поставилась через brew install pstree, короче тут индивидуальный подход.
если вкатит, можешь запустить pstree --help и глянуть на что она еще способна, там и подсветка и танцы под гитару и жаркие африканские женщины 💃
tags: #utils
—
🟢 Подпишись: @bashdays/root/.mytop. Минимальный конфиг .mytop выглядит так:
user=db_user pass=superpassword delay=5 db=db_baseЧерез конфиг
.mytop так же возможно сконфигурировать работу утилиты с удалёнными серверами, достаточно указать ip адрес сервера и порт на котором у вас крутится mysql. Но я обычно ставлю ее на тот же сервер где у нас крутится база.
Устанавливается обычным apt install mytop, а для других дистрибутивов и операционных систем с помощью brew/yum/pacman
mytop достаточно хороший инструмент для отладки, берите на вооружение
tags: #utils
—
🟢 Подпишись: @bashdaysdu и find, есть прекрасная утилита, которая называется ncdu.
ncdu имеет мощный функционал, у неё много ключей для запуска, но в повседневной работе, мы используем ее с дефолтными параметрами:
# cd / # ncduПосле запуска строится удобное дерево в процентном соотношении занятого дискового пространства, удобная навигация, ну а самое главное есть возможность прямо из нее удалять жирные файлы (нажать на файле или каталоге букву d). Утилита мастхев, которая ежедневно экономит нам кучу времени и нервов. Рекомендуем. установка элементарная ubuntu:
apt install ncdu
osx: brew install ncdu
centos: yum install ncdu
tags: #utils
—
🟢 Подпишись: @bashdaystail -f, которая разделяет «линией» активность в логах.
До этого я (да и многие из вас) обычно несколько раз нажимал Enter. Теперь достаточно соорудить нечто такое и радоваться:
tail -f /var/log/nginx/error.log | spacerКонечно это не замена агрегаторам ELK и LOKI, но обязательно пригодится разработчикам и девопсам как быстрое решение. Думаю с docker logs так же будет работать. 🐱 Spacer на гитхабе tags: #utils — 🟢 Подпишись: @bashdays
Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
