😀😃😄😁😆

🔧 Утилиты: #utils
💳 Таблицы: #sheets
⚙ Скрипты: #bash
🎙 Мониторинг: #monitoring
🤔 Отладка: #debug
🎃 Линукс: #linux
✉️ Nginx: #nginx
📦 GIT: #git
📊 Mysql: #mysql
📱 Сервисы: #services
🔄 Девопс: #devops
🛡 Безопасность: #security
👻 Игры: #games
🌐 Сети: #networks
💬 Будни: #рабочиебудни

Подвернулась интересная утилита Spacer работающая в каскаде с tail -f, которая разделяет «линией» активность в логах.

До этого я (да и многие из вас) обычно несколько раз нажимал Enter. Теперь достаточно соорудить нечто такое и радоваться:

tail -f /var/log/nginx/error.log | spacer

Конечно это не замена агрегаторам ELK и LOKI, но обязательно пригодится разработчикам и девопсам как быстрое решение. Думаю с docker logs так же будет работать.

🐱 Spacer на гитхабе

tags: #utils
—
🟢 Подпишись: @bashdays

Табличка консольных инструментов для наблюдения и дебага на linux машинах. Хотя справедливо можно сказать, что и для других операционных систем данные утилиты актуальны.

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

tags: #sheets
—
🟢 Подпишись: @bashdays

Утилита ncdu: эффективный инструмент для борьбы с переполнением дискового пространства

Перво-наперво что мы делаем при инцидентах с серверами, это проверяем свободное место на диске. Зачастую проблема именно в этом, к примеру диск переполнился жирным лог файлом или наплодилось куча мусора в /tmp папке, а может быть система резервного копирования вышла из-под контроля.

Для того чтобы не заморачиваться с командами du и find, есть прекрасная утилита, которая называется ncdu.

ncdu имеет мощный функционал, у неё много ключей для запуска, но в повседневной работе, мы используем ее с дефолтными параметрами:

# cd /
# ncdu

После запуска строится удобное дерево в процентном соотношении занятого дискового пространства, удобная навигация, ну а самое главное есть возможность прямо из нее удалять жирные файлы (нажать на файле или каталоге букву d).

Утилита мастхев, которая ежедневно экономит нам кучу времени и нервов. Рекомендуем.

установка элементарная

ubuntu: apt install ncdu
osx: brew install ncdu
centos: yum install ncdu

tags: #utils
—
🟢 Подпишись: @bashdays

mytop — это отличная обертка для мониторинга mysql, я применяю её довольно часто, чтобы в реальном времени отследить какие запросы нагружают базу и откуда растут ноги.

Конечно можно законектится в сам mysql и выполнить SHOW FULL PROCESSLIST, но mytop делает это автоматически, регулярно запрашивая PROCESSLIST и STATUS.

По умолчанию информация о длинных запросах для удобства обрезается. Чтобы посмотреть полный запрос к базе, необходимо нажать букву f и ввести ID потока (треда).

Утилиту нужно сконфигурировать через конфиг файл /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
—
🟢 Подпишись: @bashdays

pstree — незаменимый инструмент в работе, утилита визуально выводит компактное дерево всех запущенных процессов. Можно сказать что это аналог команды ps, но на стероидах и самое главное для людей.

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

pstree стакает идентичные ветви, помещая их в квадратные скобки и добавляет к ним целое число, это число является количеством ветвей процесса.

Редко, но иногда требуется отключить объединение ветвей, для этого можно использовать ключ -c

pstree -c

Ну и конечно же с помощью ключа -p, можно вывести список PID’ов и PGI’ов и потом их жёстко закилить.

pstree -p

Есть еще крутая фишка, это ключ -a, с помощью него можно получить параметры конфигурации запущенных приложений. То есть допустим запущен у меня какой-то prometheus экспортер и мне надо знать с какими параметрами он запущен, выполняем:

pstree -a

и получаем:

nginx_exporter -nginx.scrape-uri https://localhost/nginx_status

Сказка, а не утилита! Лично для меня проще запустить pstree и не приседать вокруг ps со всеми его ключами и наворотами, грепая и страдая. Глянул на дерево визуально и понял, что php, nginx, mysql запущены, значит проблему надо искать в другом месте.

pstree входит в пакет psmisc, установка стандартная apt install psmisc, для остальных дистрибутивов аналогично yum/pacman/другое, но в osx без проблем поставилась через brew install pstree, короче тут индивидуальный подход.

если вкатит, можешь запустить pstree --help и глянуть на что она еще способна, там и подсветка и танцы под гитару и жаркие африканские женщины 💃

tags: #utils
—
🟢 Подпишись: @bashdays

nethogs - одна из большинства программ для мониторинга сети в linux системах. Но среди других она выделяется тем, что можно в режиме реального времени отследить процесс и источник которые генерируют много трафика и забивают канал.

Установка стандартная: apt/yum/brew install nethogs но если ты упоротый админ, можешь из исходников собрать и ядро пропатчить 🔨

Я использую nethogs довольно редко, но метко. В последний раз была ситуация, когда ко мне пришел Selectel и попросил разобраться почему мы начали превышать полосу пропускания и наш канал несколько дней забит на 200%.

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

Так же у nethogs есть различные ключи для запуска, но я ими никогда не пользуюсь, всё и так понятно без всяких надстроек и тюнинга.

Именно поэтому я тащусь от подобных утилит, где ничего не нужно конфигурировать и по факту получаешь необходимую информацию для дальнейшего дебага.

Что можно выделить по параметрам запуска

1. Выставляем время обновления в секундах (по умолчанию 1 секунда)

nethogs –d 5

2. Посмотреть сколько процесс передает в мегабайтах, а не его скорость (0 = KB/s, 1 = total KB, 2 = total B, 3 = total MB)

nethogs –v 3

но можно этого добиться и без параметров, после запуска nethogs, нужно нажать букву m и отображение поменяется, удобно

3. Так же возможно мониторить отдельные интерфейсы

nethogs eth0
nethogs wlan0

4. Ну и как вишенка, в nethogs есть режим трассировки, запускается с ключом -t

nethogs -t

Кстати если перевести nethogs на русский язык, то дословно получается что программа называется: «сетевая свинья» ну или «сетевой боров/кабан». Название безусловно интересное, я не знаю что ты будешь делать с этой информацией, просто живи с ней ))

tags: #utils
—
🟢 Подпишись: @bashdays

Мало кто знает об этой фишке в journalctl, ща расскажу…

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

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

Будем расширять границы контента. Ща покажу магию, знать это мастхэв. Мотай на ус, если не индус знал, пригодится.

У нас в компании достаточно банальная инфраструктура, в которую входит балансировщик и несколько нод на которых крутится nodejs приложение с 3000м портом, короче говоря апиха.

bashdays-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 https://$backend;
}

Объясняю что происходит, клиенты идут на b1 и попадают по умолчанию в upstream backend, где прописаны ноды w1-w4.

Тестировщики подставляют заголовок X-Backend: bashdays-w5 в своих запросах и попадают на w5. То есть для обычных пользователей ничего не изменилось, но QA теперь с помощью заголовка X-Backend: bashdays-w5 могут попасть на новую ноду и затыкать ее хоть до усрачки.

В location есть директива add_header X-Upstream, она выведет в ответе nginx на какую ноду ты попал, удобно для дебага.

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

Если у тебя не апиха, а веб приложение, можешь воспользоваться плагином ModHeader, есть для фокса и хрома. В нём можно легко подставить все необходимые заголовки и попасть в жопу пальцем туда куда тебе нужно, или не нужно.

Конфигурация nginx это как стихи писать, есть какие-то базовые слова и правила, но в большинстве случаев 90% функционала вообще не используется. Потому что, документацию никто не читает и люди делают так, как научились или подсмотрели на stackoverflow. Вот такие пироги.

tags: #nginx
—
🟢 Подпишись: @bashdays

Сегодня я снова научу тебя плохому хорошему. Про prometheus я думаю все знают. Но не все знают, что на bash можно за несколько минут написать собственный экспортер метрик. Дада, ты не ослышался — не обязательно быть golang сеньором, чтобы делать крутые и полезные штуки. Погнали чо!

У prometheus есть основной экспортер node_exporter, который собирает 100500 метрик с хоста. Ставится отдельно и элементарно. Гугол тебе подскажет. У меня он установлен везде где хоть что-то напоминает linux. Короче бест-практик.

Эт я к чему. У node_exporter есть прекрасный ключик --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
—
🟢 Подпишись: @bashdays

Сегодня мы будем делать с вами свой nginx plus (тот который платный), а именно реализуем плюшку «Active health checks».

Это когда у тебя к примеру 10 апстримов и если один из них дохнет, то какой-нибудь богатый клиент получит 502 ошибку, обозлится и ничего не купит. А должен автоматически попасть на другой, более живой апстрим и потратить денежку.

Само собой будем применять инновационные технологии и немного возьмем из фреймворка «гавно и палки». Ну а как ты хотел? Бест практик! На халяву и уксус сладкий, как говорится. Короче все элементарно. Погнали.

Ставим ванильный nginx и делаем так:

upstream backend {
    server unix:/var/run/haproxy/backend.sock;
}

location / {
  proxy_pass https://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

Что это за хрень, щас объясню. Смотри. Клиент идет на хуй корень / и попадает в nginx апстрим backend, а апстрим сконфигурирован на сокет backend.sock от haproxy.

Далее запрос клиента пролетает по сокету, как фанера над загнивающим парижем и попадает в блок haproxy «backend» где у меня описаны все бэкенд-сервера (w1, w2, w3, w4).

Если по какой-то причине к примеру сервер w2 отдаст концы, haproxy это задетектит (timeout check 5s) и закинет запрос клиента на рабочий инстанс, тем самым клиент получит статус 200. А 200 == заебись хорошо! 🗒

Ну а потом когда w2 очухается, то haproxy снова заберет его в свои сети и будет использовать на всю катушку, как провинившуюся падшую женщину.

Вот так это и работает. Вот так вот и живем. Балансировка нагрузки + roundrobin + active health checks

У haproxy еще есть встроенный визуальный мониторинг, но об этом я расскажу тебе в одной из следующих статей.

tags: #nginx
—
🟢 Подпишись: @bashdays

С пятницей коллеги! Сегодня на повестке у нас еще одна полезная тулза.

PV «pipe viewer», держу пари многие даже и не подозревали что такое существует.

Что же она делает? Давай на пальцах, когда ты запускаешь из консоли дампиться базу или выполняешь копирование какого нибудь большого файла, ничего не остается кроме как красноглазить и ждать конца операции. На экране нет никакой полезной информации.

Ну дак вот, встроив в свой pipe эту утилиту у тебя появится информативный progress bar который в реальном времени будет показывать cкорость обработки данных.

[===>xxxxxxxx] 20%

Пошли тыкать:

pv /var/log/php/php-fpm.log | gzip > php-fpm.gz

33MiB 0:00:03 [ 114MiB/s] [==========> ] 32% ETA 0:00:06

Наглядно видно, что через пайп за 3 секунды прошло 33Мб — это 32% от всего объема, операция займет еще 6 секунд. Заебись! Хорошо! 😏

PV это вовсе не cat, её возможности намного шире, тут уже зависит на сколько ты будешь оригинален в своих скриптах и велосипедах.

Утилита укомплектована внушительной кучей различных ключей для запуска. Но я не привередливый и пользуюсь ей исключительно функционалом из коробки. Если есть время, кури --help или можешь глянуть на доисторической официальной страничке, а при желании и скомпилировать. 

Из клёвых ключей, есть:

-l строчный режим, pv может ограничивать скорость и просто в байтах
-L 100 – необходимое ограничение

Допустим у тебя есть база данных, которая не толерантна к большому объёму INSERT-ов и UPDATE-ов. Но у тебя также есть большой дамп с кучей таких операций.

Как безопасно импортировать дамп в базу и не убить её нахуй? А вот так:

# скорость ограничена 100 тысячами строк в секунду
pv -L 100k -l dump.sql | mysql -u root -p

# скорость ограничена 100 строками в секунду
pv -L 100 -l dump.sql | mysql -u root -p

Ну и на закусочку, баянище:

pv /dev/urandom > /dev/null
23MB 0:00:05 [ 12,9MB/s] [...<=>..........]

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

Увидимся в понедельник! 💛

tags: #utils
—
🟢 Подпишись: @bashdays

Ну что ж, надеюсь ты успел отдохнуть и готов к новым приключениям. Сегодня мы с тобой реализуем собственный конфиг-агент. Естественно применим самые наилучшие практики, естественно на bash. Поехали.

Что такое конфиг-агент? Это такой механизм, который держит конфиги на сервере в актуальном состоянии. К примеру какой-нибудь мудень плохой человек с бодуна накосорезил и грохнул важный nginx файл с апстримами, а вернуть как было не может, нет знаний, нет головы, нет бекапов, нет будущего.

Ты спросишь? А какого хуя? Как так получилось? А вот так, порой у тестировщиков есть root на тестовые машины, чтобы они не дергали девопсов, а могли сами зайти на свой сервер и подебажить проект. Но дебаг может затронуть nginx, php и т.п. конфиги. Лезут же куда не попадя, все хотят быть крутыми девопс инженерами.

В этом случае нас спасет конфиг-агент, который автоматически придет через минуту, заберет эталонные конфиги из git, всё красиво восстановит и передернет на Билли Айлиш.

Ясно дело можно через ansible и puppet все это провернуть, но слишком избыточно, это то же самое, что поднять kubernetes и крутить в нем личный бложек на wordpress, ну такое…

Не унывай, выход есть! Это можно реализовать за несколько минут и потом снова пару недель пинать хуи воздух. Главное на планировании спринта сказать — я оцениваю эту задачу в 14 дней. 😘

Как я раньше и сказал, есть некий git репозиторий где хранятся все эталонные конфиги. Все изменения в конфигах производятся через этот репозиторий.

На примере покажу как мониторить nginx конфиги и сделать простенький агент. Дальше уж сам свой велосипед под свои реалии запилишь.

Практика (упрощаю до минимума, чтобы ты понял смысл)

Закидываем файл /usr/local/sbin/config-agent.sh делаем ему chmod +x (чтобы он был исполняемым) и ставим его в крон */1 * * * *

#!/bin/bash

DIR=/tmp/nginx-configs

if [ ! -d "$DIR" ];
then
git clone [email protected]:dev/nginx-configs.git /tmp/nginx-configs
fi

cd /tmp/nginx-configs && git pull --quiet
RSYNC=$(rsync -aizh /tmp/nginx-configs/ /etc/nginx)

if [ $? -eq 0 ]; then
if [ -n "${RSYNC}" ]; then
systemctl reload nginx
fi
else
exit 0
fi

Давай смотреть что тут происходит:

1. Создаем отдельную папку если ее нет в /tmp
2. Клонируем в нее эталонные конфиги с git репозитория
3. Переходим в папку и забираем последние изменения
4. С помощью rsync, синкаем эталон в папку /etc/nginx
5. Если файлы заменились в /etc/nginx то делаем reload

Всё!

Знак $? используется для поиска возвращаемого значения последней выполненной команды.

Теперь у нас есть полный контроль от кривых рук. Ну а чтобы изменить какой-то конфиг, нужно заморочиться и сделать это через git репу со всеми вытекающими кодревью и т.п.

Как говорится - на bash’ке моей горшок, а в кармане пирожок!

Всем хорошего понедельника коллеги!

tags: #bash
—
🟢 Подпишись: @bashdays