Webmin для ленивого админа.

Всем привет.

Webmin это web панель для администрирования unix сервера. Она кроссплатформенная, ставится на различные unix дистрибутивы. С помощью webmin можно выполнять практически все популярные административные действия на сервере, такие как:

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

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

Если вы привыкли настраивать Linux исключительно в консоли то вам Webmin будет как игрушка. Но тем не менее раз он существует, то есть и админы, которые активно им пользуются. Судить по этому насколько они продвинутые в Linux-е админы не берусь ибо главное это результат и время потраченное на его достижение. Остальное это все личные предпочтения в жизни. 

Обновление Zabbix 4.4 до 5.0.

Всем привет. 

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

В 5-й версии очень много изменений, как в настройках, так и в интерфейсе. Обновлять без подготовки не рекомендую. Если у вас несколько серверов, начните с самого простого и незанятого.

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

Последний нюанс - минимальные системные требования к версии PHP для Zabbix 5 - 7.2 Так что прежде чем обновлять сам сервер мониторинга, убедитесь, что у вас стоит подходящая версия php. Обращаю ваше внимание на это ибо у меня один сервер уперся именно в версию PHP и хотя сам zabbix продолжал работать доступ к фронтенду был утерян. 

Приступаем к обновлению сервера мониторинг Zabbix версии 4.4 до 5.0. Итак имеем Centos 8 и zabbix 4.4.7.

Подключаем репозиторий версии zabbix 5.0:

# rpm -Uvh https://repo.zabbix.com/zabbix/5.0/rhel/8/x86_64/zabbix-release-5.0-1.el8.noarch.rpm

Старый репозиторий от версии 4.4 будет автоматически удален.

Очищаем и пересоздаем кэш yum:

# yum clean all

# yum makecache

Устанавливаем само обновление zabbix на сервер Centos следующей командой:

# yum upgrade zabbix-server-mysql zabbix-web-mysql zabbix-web zabbix-agent

Меняем max_connections для MySQL.

Всем привет.

При экспериментах с буфером в Zabbix получил неожиданно ошибку "...too many connections". При этом фронтенд Zabbix-а был доступен, но сам сервис благополучно отдыхал от своей работы. Оказалось что текущие настройки pooler-a Zabbix требуют себе больше количество разрешенных коннектов при доступе к базе данных MySQL. Как известно, за это отвечает параметр MySQL max_connections, который по умолчанию равен 200.

Вроде все просто - идем в файл /etc/mysql.cnf и меняем лимит подключения:

[mysqld]

max_connections = 1000

Перезапускаем сервис MySQL

systemctl restart mysql

и проверяем SQL-запросом show variables like "max_connections"; текущее значение max_connections и... понимаем что ничего не изменилось.

А дело в том что в связи с переходом Ubuntu с Upstart на Systemd с версии 15.04 и выше, не соблюдаются ограничения выставленные в /etc/security/limits.conf для системных служб. Эти ограничения теперь применяются только к пользовательским сеансам. Пределы для службы MySQL определены в файле конфигурации Systemd, который мы должны скопировать из своего местоположения по умолчанию в /etc/systemd, а затем отредактировать копию:

sudo cp /lib/systemd/system/mysql.service /etc/systemd/system/

sudo nano /etc/systemd/system/mysql.service

Добавляем следующие строки в конец файла:

LimitNOFILE=infinity

LimitMEMLOCK=infinity

И перегружаем конфигурацию Systemd с помощью:

sudo systemctl daemon-reload

Перезапускаем еще раз MySQL

systemctl restart mysql

и вот только теперь он будет подчиняться нашей директиве max_connections.

Также советуют указать большие значения параметров для max_user_connections  и max_connect_error.

Успехов.

How is doing patches and installation by Ansible.

Hi all.

How is doing patches and installation by Ansible? Next story by Janathan Lozada De La Matta.

So we’ve learned how to update a system, restart the VM, reconnect, and install a RPM. 

  - name: update the system

    yum:

      name: "*"

      state: latest

In the first line, we give the task a meaningful name so we know what Ansible is doing. In the next line, the yum module updates the CentOS virtual machine (VM), then name: "*" tells yum to update everything, and, finally, state: latest updates to the latest RPM. After updating the system, we need to restart and reconnect:

  - name: restart system to reboot to newest kernel

    shell: "sleep 5 && reboot"

    async: 1

    poll: 0

  - name: wait for 10 seconds

    pause:

      seconds: 10

  - name: wait for the system to reboot

    wait_for_connection:

      connect_timeout: 20

      sleep: 5

      delay: 5

      timeout: 60

  - name: install epel-release

    yum:

      name: epel-release

      state: latest

Читаем журналы Linux #4 - rsyslog.

Всем привет.

Центром механизма журналирования является демон Rsyslog:  (R)ocket-fast (Sys)tem for (log) processing. Данный сервис отвечает за прослушивание зарегистрированных сообщений различных частей системы Linux и маршрутизацию сообщения к соответствующему журналу в каталоге /var/log. Он также может передавать зарегистрированные сообщения другому серверу Linux. Весьма подробно настройка rsyslog показана здесь.

Особенности Rsyslog:

-многопоточный

-TCP, SSL, TLS, RELP, etc.

-сохранение логов в базы данных (MySQL, PostgreSQL, Oracle, etc.)

-фильтрация по любой части лога

-полностью настраиваемый формат вывода.

Конфигурационный файл rsyslog.

Демон rsyslog получает конфигурации из файла «rsyslog.conf», который находится в каталоге /etc.

В основном, файл rsyslog.conf говорит демону, где хранить сообщения. Данная информация имеет вид серии строк, состоящих из двух частей. Под двумя частями строк подразумеваются селектор и действие (selector и action). Они разделяются пробельным символом. Селектор указывает на  источник и важность сообщения, а действие говорит, что нужно сделать с данным сообщением. Сам селектор также разделен на 2 части символом точки (.). Часть перед символом точки называется объектом (источник сообщения), а часть за символом называется приоритетом (степень важности сообщения). Комбинация объекта-приоритета и действия говорит rsyslog, что делать, если сообщение соответствует указанным параметрам.

Вот отрывок из файла rsyslog.conf на CentOS:

# rsyslog v5 configuration file

...

# Include all config files in /etc/rsyslog.d/

IncludeConfig /etc/rsyslog.d/*.conf

#### RULES ####

# Log all kernel messages to the console.

# Logging much else clutters up the screen.

#kern.*  /dev/console

# Log anything (except mail) of level info or higher.

# Don't log private authentication messages!

*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.

authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.

mail.*                                                  -/var/log/maillog

# Log cron stuff

cron.*                                                  /var/log/cron

# Everybody gets emergency messages

*.emerg                                                 *

# Save news errors of level crit and higher in a special file.

uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log

local7.*                                                /var/log/boot.log

...

Zabbix performance tuning #3.

Всем привет.

Оптимизация Zabbix-а опять на повестке дня. Я вам, наверное, с этим уже надоел. Но сегодня мы, наконец-то, добрались до реального случая. Я кратко покажу что мы меняли на своем сервере, за исключением параметров для базы данных. В разделе БД мнения разделились поэтому ниже опишу только то, что нам предлагали, но что так мы не успели оценить практически. Поехали.

Для беглого мониторинга средствами Zabbix был собран вот такой вот полигон.

Как же мы оценивали "здоровье" нашего Zabbix-сервера?

Этап 1.
По штатным графикам:
Zabbix data gathering process busy %
Zabbix internal process busy %

а также по
Zabbix internal queues
Zabbix server performance

оцениваем максимальные значения загруженности Zabbix-a.

Чтобы уменьшить эти величины меняем дефолтные в
#sudo nano /etc/zabbix/zabbix_server.conf
на

StartPollers=50
StartPreproceessors = 60
StartPollersUnreachable=30
StartPingers=100
StartIPMIPollers=10
StartTrappers=20
StartDBSyncers=8

Не забываем передернуть службу zabbix-server:
#sudo service zabbix-server restart
Опять оцениваем результат по тем же графикам.

Zabbix performance tuning #2.

Всем привет.

Сегодня я хочу продолжить тему оптимизации производительности Zabbix. На это раз пройдемся по разделам книги «Zabbix Performance Tuning» от Luciano Alves, издательство Packt Publishing, 2015. Это материал подготовил Евгений Каменев три года тому. С тех пор ничего более подробного на эту тему я не встречал. Так что продолжим.

Zabbix - это платформа, которая состоит из трех компонентов:

1.Сервер Zabbix.

2.База данных Zabbix.

3.Фронтенд Zabbix.

Но в тему оптимизации следует включить еще два дополнительных пункта:

4.Оптимизация операционной системы Linux.

5. Мониторинг состояния Zabbix.

Далее рассмотрим каждый пункт последовательно.

1.Оптимизация Zabbix-сервера.

Использование активных Zabbix-agent проверок вместо пассивных Zabbix-agent проверок (уменьшает нагрузку на Zabbix-сервер и количество TCP-соединений).

При этом на Zabbix-агенте, возможно,есть смысл увеличить дефолтные значения параметров.

Ниже приведены дефолтные значения

BufferSend=5

BufferSize=100

На Zabbix-сервере необходимо увеличить количество процессов Zabbix-trapper, которые принимают входящие соединения активных агентов, Zabbix-sender и активных прокси.

Использование наименее дорогого с точки зрения чтения/записи базы данных типа элемента данных - (numeric(unsigned),numeric (float), character, text, log).

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

Использовать наименее дорогого с точки зрения нагрузки процессора триггера - (функции last(), nodata(), min(), max(), avg())

Например, функции min/max/avg сильнее нагружают процессор в отличии от функций last и nodata.

Время хранения данных в таблицах history,trends,events.

Уменьшаем время хранения истории с дефолтных 90 дней на 7 дней (при создании элемента данных)

Время хранения в таблице trends оставляем дефолтное 365 дней (при создании триггера)(если нет необходимости в просмотре информации за год,то сокращаем время хранения тенденций)

Время хранения событий, генерируемых триггерами, можно уменьшить с дефолтных 365 дней, чтобы не увеличивать размер таблицы events при частых колебаниях/срабатывании триггеров.

Оптимизация Zabbix.

Всем привет.

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

По ходу рекомендую к прочтению книгу James Turnbull "The Art of Monitoring", 2016. Она хоть и не про Zabbix, но толково освещает общие моменты мониторинга  в сети на примере Reimann, Graphite и ELK.

Ну а сегодня начнем с главного конфига Zabbix.

#sudo nano /etc/zabbix/zabbix_server.conf

Есть смысл править такие параметры, как объем рабочего кэша, количество параллельных процессов в опросах и таймауты:

StartPollers=50

StartPreproceessors = 60

StartPollersUnreachable=30

StartPingers=100

CacheSize=64M

HistoryCacheSize=32M

HistoryIndexCacheSize=16M

TrendCacheSize=16M

ValueCacheSize=32M

Timeout=15

Обратите внимание что если некий узел мониторинга недоступен, процессы опроса его параметров будут заняты промежуток времени, равный таймауту на опрос (например Timeout=15). Если вдруг окажутся недоступными, например, более сотни таких узлов, с каждого из которых Zabbix собирает более десятка параметров, то весь процесс опроса(ожидания ответа) займет ресурсы Zabbix и это может привести к его отказу в нормальной работе.

Не мене важным может оказаться база данных Zabbix. Переходим к конфигу БД Zabbix на примере MySQL.

#sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf