ЮЛЯ: ПТИЧИЙ ЯЗЫК
Звонит босс:
- Юля, нужно срочно найти сисадмина. Пропадаем! Обнови вакансию и назначай минимум по три собеседования в день.
Оффер приличный, приток желающих внушительный. Причем, я заметила: все кандидаты вроде бы разные, но – похожи друг на друга. Что-то общее во взгляде, в манере разговора, жестах. Мне стало казаться, что даже в толпе незнакомцев я отличу сисадмина от других.
Но я столкнулась с проблемой: вроде говорю с кандидатом на русском языке – но не вполне его понимаю. Если первая часть интервью выглядела стандартно – где работали, почему меняете место, чего хотите от новой должности, то в технической части я откровенно "плыла". Даже погуглив специфические вопросы и заучив ответы на них – я все равно понятия не имела, о чем говорит кандидат.
Каждый, естественно, уточнял будущие обязанности:
- Сервак какой? Отказоустойчивая система есть? MAC-адрес, IP-адрес, DNS? Типы виртуализации?
Я краснею, бледнею и объясняю, что на все узкоспециальные вопросы ответит непосредственно директор компании.
Переадресовываю боссу и слышу в ответ:
- Ты думаешь, я знаю? Я в это вообще не врубаюсь. Предыдущий сисадмин 2 года отработал, до сих пор не знаю, чем он занимался. Но! Все работало и ничего не зависало, от этого нужно так же.
По итогу приняли того, чей знак зодиака и расклад по Human Design (я не шучу) понравился боссу.
Новый сисадмин был похож на Тора, только без мышц. С цветными татухами. Молчаливый и на своей волне, но если спросить – рассказывал долго и вдохновенно.
- Юля, женщина – как Windows: умом понимаешь, что она не способна сделать пpавильно, но все pавно не можешь без нее жить.
Я вот думаю - может, он так заигрывал, а я просто не поняла?
СКУЧНО? "ГРАФИНЯ и САНТЕХНИК"!: https://t.me/graf_sant
Утилиты Linux значительно облегчающие жизнь сисадмина
Linux для инженера это как правило bash через SSH. У каждого свой набор предпочтений, предлагаю поделиться своими фаворитами, думаю будет много полезной информации.
Самый простой к пониманию метод подачи материала:
Название
Практическая ситуация в которой утилита используется
Для затравки:
Утилита screen
Часто приходится делать продолжительные операции через SSH, например сжимать большие архивы, копировать значительный объем данных и если по ходу работы пропадет линк, операция прервется, неприятно. Или когда необходимо запустить несколько задач параллельно, переключаясь между ними по необходимости, например запущен снифер, копирование и проверка диска. Даже если вы отключитесь от консоли или разорвется соединение, всё запущенное в скрине продолжит работать и вы спокойно подключитесь и продолжите работать. Присутствует почти во всех репозиториях, но её придется устанавливать.
Консольная утилита screen это по сути оконный менеджер, разделяющий один физический терминал между несколькими процессами. Подходит для прямого либо удалённого администрирования. Подробнее читайте в Гугле
Комрады, большая просьба, постарайтесь воздержаться от негатива и понтов, а тех кто этим грешен, не стесняйтесь минусить.
В Питере шаверма и мосты, в Казани эчпочмаки и казан. А что в других городах?
Мы постарались сделать каждый город, с которого начинается еженедельный заед в нашей новой игре, по-настоящему уникальным. Оценить можно на странице совместной игры Torero и Пикабу.
Реклама АО «Кордиант», ИНН 7601001509
Перенаправление логов из Fluentbit в Seq
Seq — это сервер поиска и анализа структурированных журналов приложений в режиме реального времени. Можно смотреть на него как на своего рода альтернативу для ELK. Хотя лицензия тут тоже не свободная, а использование для юрлиц платное. Но для домашней лаборатории для меня в своё время это оказался превосходный вариант (в принципе я до сих пор считаю так, потому что времени на развертывание Seq тратится несравнимо меньше чем на ELK. Для экспериментов самое то.
В данной статье проведу нехитрую операцию по развертыванию и настройке fluentbit и seq в docker, и настрою отправку собранных логов из fluentbit в seq.
Начнём с создания отдельной сети для наших контейнеров:
docker network create fluent-bit_seq
Установка Seq
Теперь захэшируем пароль, который будет использоваться.
PH=$(echo 'seqPass%%' | docker run --rm -i datalust/seq config hash)
Убедимся, что переменная действительно содержит пароль:
echo $PH
Запускаем контейнер:
docker run --name seq -d --network fluent-bit_seq \ -p8080:80 --restart unless-stopped \ -e ACCEPT_EULA=Y -e SEQ_FIRSTRUN_ADMINPASSWORDHASH="$PH" \ datalust/seq
Теперь, можем обратиться в браузере к localhost:8080 и залогиниться в Seq с помощью username=admin password=seqPass%%
Установка Fluentbit
Для начала экспортируем переменную, которая будет содержать каталог из которого будет взята конфигурация Fluentbit.
export sharedFolder=/var/fluent-bit_seq
Запустим временный контейнер, откуда скопируем дефолтный конфиг:
docker run -d --rm --name temp cr.fluentbit.io/fluent/fluent-bit
Скопируем сам конфиг с последующей остановкой ставшего ненужным контейнера:
docker cp temp:/fluent-bit/etc/ $sharedFolder docker stop temp
Теперь еще раз запустим контейнер fluentbit, но уже смонтировав в него каталог с конфигом:
docker run -dti --name fluent-bit --network fluent-bit_seq \ -v $sharedFolder:/fluent-bit/etc \ cr.fluentbit.io/fluent/fluent-bit
По дефолту fluentbit отправляет вывод на stdout. Так что с помощью docker log всегда можно посмотреть что с ним происходит. Наша задача как раз исправить дефолтное поведение.
docker logs fluent-bit
Настройка отправки логов в Seq
Отправляемся в конфиг fluentbit и ищем следующую секцию:
# fluent-bit.conf
[OUTPUT]
name stdout
match *
Заменяем её на указанную ниже, с последующим сохранением:
# fluent-bit.conf
[OUTPUT]
Name http
Match *
Host seq
Port 5341
URI /api/events/raw?clef
Format json_lines
Json_date_key @t
Json_date_format iso8601
Log_response_payload False
Теперь перезапустим контейнер с fluentbit для принятия изменений:
docker restart fluent-bit
Возвращаемся в браузер, открываем Seq, логинимся и теперь можем видеть, что логи из fluentbit отправляются прямиком туда:
Куда могло исчезнуть дисковое пространство? (5/5)
Подытожим этот короткий цикл последним случаем.
Файловая система только для чтения
Последний из рассматриваемых кейсов может произойти из-за проблем с самим жёстким диском:
Мы не можем создать новый файл, хотя явно видно, что дисковое пространство у нас ещё есть. Посмотрим в каком режиме смонтирована файловая система:
Вывод mount даёт нам подсказку, что наша rootfs смонтирована только для чтения (ro).
Теперь имеет смысл приступить к чтению системных логов, чтобы лучше понять что именно произошло:
В логах видно, что ядро перевело файловую систему в режим read-only из-за - sysrq: Emergency Remount R/O.
Объяснений произошедшему может быть достаточно много. Тут сложно вывести какую-то общую рекомендацию для решения. Что нужно будет сделать наверняка: просмотреть сообщения dmesg, более детально логи системного журнала, сделать SMART тест жесткого диска.
Заключение
Когда ядро сталкивается с проблемами в работе файловых систем, оно ведёт себя в соответствии с аргументом error= команды mount. Этот аргумент может принимать следующие параметры:
errors=continue - игнорирует ошибки, однако помечает файловую систему как некорректную, после этого монтирование продолжается.
errors=remount-ro - перемонтирует файловую систему в режим "только для чтения".
errors=panic - аварийно завершает процесс монтирования и блокирует работу системы.
Нужное поведение при монтировании можно настроить в /etc/fstab.
Нельзя забывать, что подобная ошибка сообщает о вероятной проблеме с железом, поэтому в случае возникновения такой ошибки в первую очередь необходимо будет проверить корректность состояния физического устройства.
Будни сисадминов: ситуация №6
Один из офисов нехило затопило и он превратился в импровизированный филиал Венеции.
Такая ситуация была для меня в диковинку, поэтому было интересно оценить масштаб приключения.
То оборудование, что стояло на столах было в порядке и надменно взирало на то, что стояло на полу и подверглось проверке на работоспособность в условиях апокалипсиса.
Всё было буднично, до момента, пока я работал над этим один. Сотрудница подошла ко мне и попросила поднять бесперебойник с пола, что бы она под него поставила коробку.
Беглый осмотр показал, что мне предлагают сыграть в русскую рулетку с электричеством.
-С него течёт вода ручьем. Меня может убить током.
Девушка невинно посмотрела мне в глаза и, улыбнувшись как сама смерть, сказала:
-Ну, поэтому я вас и попросила.
Куда могло исчезнуть дисковое пространство? (4/5)
Inodes
Продолжая тему исследования того, куда могло исчезнуть место на диске, рассмотрим новую задачу.
Сервер перестал отвечать. Смотрим по логам, что произошло:
Ок, делаем стандартные проверки для подобного сценария:
Ну, у нас определённо есть свободное пространство, но что-то всё равно пошло не так. Давайте попробуем посмотреть ещё кое-что:
-x tmpfs -x squashfs из первой части, тут также может быть вполне уместно применить
Сервер использовал все доступные inode.
Попробуем найти директорию, с наибольшим количеством использованых inode:
Чтож. Довольно предсказуемо. Теперь провернём небольшой трюк:
Мы смонтировали tmpfs в /tmp. Оно конечно само по себе может вызвать проблемы, но мы тут и так уже посреди инцидента, так что двигаемся дальше:
Почистим эту директорию:
Ладно. Пойдём другим путём:
Решение на perl не единственное, но одно из самых быстрых. С другими возможными вариантами решения можно, например, ознакомиться здесь.
Заключение
количество индексных дескрипторов в файловой системе определяется во время создания. Несмотря на то, что их число достаточно велико, тем не менее они могут быть исчерпаны.
такой тип инцидентов крайне редкий. В основном подобное может случиться в системах, где создаётся множество мелких файлов. Например почтовый сервер, в котором письма хранятся в файлах, накрыла волна спама.