Привет
Есть ли админы которые успешно переехали со скома на заббикс?
Если есть -
1) что из мониторинга не смогли перенести/повторить в заббиксе ?
2) что больше всего бесит в заббиксе после скома?
3) удобно ли админить в плане количества действий?
4) как вам скорость работы заббикса?
Спасибо!
Стоит ли идти работать системным администратором. Помимо основной работы часто ли его загружают дополнительной?
Seq — это сервер поиска и анализа структурированных журналов приложений в режиме реального времени. Можно смотреть на него как на своего рода альтернативу для ELK. Хотя лицензия тут тоже не свободная, а использование для юрлиц платное. Но для домашней лаборатории для меня в своё время это оказался превосходный вариант (в принципе я до сих пор считаю так, потому что времени на развертывание Seq тратится несравнимо меньше чем на ELK. Для экспериментов самое то.
В данной статье проведу нехитрую операцию по развертыванию и настройке fluentbit и seq в docker, и настрою отправку собранных логов из fluentbit в seq.
Начнём с создания отдельной сети для наших контейнеров:
docker network create fluent-bit_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.
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
Отправляемся в конфиг 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 отправляются прямиком туда:
P.S. Для тех кто не в курсе, HP покупает Juniper.
Всем доброго!
Требуется помощь зала.
Столкнулся с непонятным поведением сетевой(их) карта.
Строю 10G сеточку, в наличии 4 компа и комутатор D-link 1250-28 с 4мя SFP+ портами, 4 сетевых карты от дядюшки Ляо названные Intel 520-DA1, от этого же старика 2 провода 7м.
С 3мя компами все отлично вставляем карточку, провод в карточку и в комутатор и D-link оповещает зелененьким светодиодом о наличии коннекта на порту. С одним же компом чудеса, карта стоит, проводок на месте D-link не видит на порту подключение. Произвольная замена сетевых карт, проводов, портов, показала что все сетевые карты работают, провода целы, порты в комутаторе живы.
Полез в биос матери MSI MAG B550 TOMAHAWK MAX WIFI (MS-7C91) в настройках PCI-E испробовал все варианты - auto, x8+x8, x8+x4+x4, x4+x4+x4+x4. Поведение одинаковое, на сетевой карте жёлтые act/link, на комутаторе на порту пусто.
Куда бы ещё копнуть?
Давайте представим, что нам нужно развернуть приложение, у которого есть явные требования к скорости сети. Мы например можем просто взять, открыть браузер, забить в гугле "тест скорости сети", открыть любой из приглянувшихся нам тестов скорости и... вспомнить что все эти тесты могут проверить только скорость вашего подключения к внешнему миру.
Ок. А что насчёт тестов скорости в локальной сети? Ну, в принципе у нас вроде как есть iperf. Но может еще что-то менее кондовое?
Что-то еще есть. Это как раз https://github.com/openspeedtest/Speed-Test.
OpenSpeedTest - open source решение, предоставляющее возможность оценки производительности сети, и не требующее установки каких-либо агентов или плагинов на стороне клиента. После установки доступ к инструменту можно получить из любого современного браузера. Удобней всего развернуть docker-контейнер с OpenSpeedTest из готового образа (nginx+alpine).
Запустить OpenSpeedTest можно как с готовым, и автоматически обновляемым LetsEncrypt SSL сертификатом, так и без него. В статье мы рассмотрим оба варианта.
Для запуска приложения нам понадобится только какая-нибудь машина с Linux, где мы сможем запускать контейнеры. В статье все действия будут проводиться на виртуалке с Ubuntu 22.04. Для других ОС отличие будет в основном только в методе установки Docker.
Установка Docker
Понятно, что большинство этот пункт могут воспроизвести с закрытыми глазами, но пусть будет.
Итак. Для начала позаботимся о скачивании и установке GPG ключа:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
После выполнения команды добавим официальный репозиторий Docker:
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
Установим нужные зависимости:
sudo apt-get install apt-transport-https ca-certificates curl gnupg lsb-release -y
Перед установкой Docker на всякий случай обновим систему:
sudo apt-get update
Ну и поставим уже сам Docker CE со всем необходимым:
sudo apt-get install docker-ce docker-ce-cli containerd.io -y
Во избежание запуска Docker с sudo и прочими повышениями привелегий, добавляем пользователя в группу docker:
sudo usermod -aG docker $USER
Для проверки работы нужно перелогиниться в систему, после чего выполнить например:
docker ps
Если всё хорошо, должна показаться примерно такая картина:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS
Всё готово. Теперь можно приступить к более интересной части.
Развёртывание OpenSpeedTest
Сначала рассмотрим вариант запуска без LetsEncrypt. Всё, что вам нужно сделать для этого - запустить следующую команду:
docker run --restart=unless-stopped --name openspeedtest -d -p 3000:3000 -p 3001:3001 openspeedtest/latest
Запуск контейнера может занять некоторое время (вполне может повисеть пару минут). После того как контейнер запустится, откройте браузер и введите http://SERVER:3000, где SERVER - IP адрес сервера на котором размещён контейнер с OpenSpeedTest. После открытия веб-интерфейса приложения вам достаточно нажать кнопку Start, чтобы запустить проверку:
Никто не мешает так же подключаться к нему и по https, для этого в адресной строке браузера нужно будет ввести https://SERVER:3001.
Запуск с LetsEncrypt
Если вы предпочитаете разворачивать контейнеры с поддержкой LetsEncrypt SSL, вам нужно соблюсти несколько условий:
иметь белый IP
доменное имя, которое преобразуется в IP-адрес хост-сервера
почта
Если всё в наличие, то запуск контейнера с поддержкой LetsEncrypt SSL можно произвести следующей командой:
docker run -e ENABLE_LETSENCRYPT=True -e DOMAIN_NAME=yourdomain -e USER_EMAIL=youremail --restart=unless-stopped --name openspeedtest -d -p 80:3000 -p 443:3001 openspeedtest/latest
После удачного запуска контейнера, сервис будет доступен по адресу https://SERVER:443.
Заключение
В целом это все действия, которые потребуется сделать для запуска собственного сервера SpeedTest в своей локальной сети. Штука достаточно удобная и сильно упрощает поиск проблем в перспективе (при их появлении).
