😀😃😄😁😆

🔧 Утилиты: #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