- Перевод
Тех, кто использует или собирается использовать Zabbix в промышленных масштабах, всегда волновал вопрос: сколько реально данных сможет Заббикс «переварить» перед тем как окончательно поперхнется и подавится? Часть моей недавней работы как раз касалось этого вопроса. Дело в том, что у меня есть огромная сеть, насчитывающая более 32000 узлов, и которая потенциально может полностью мониториться Заббиксом в будущем. На форуме давно идут обсуждения о том, как оптимизировать Zabbix для работы в больших масштабах, но, к сожалению, мне так и не удалось найти законченное решение.
В этой статье я хочу показать, как я настраивал свою систему, способную обрабатывать реально много данных. Чтобы вы понимали, о чем речь, вот просто картинка со статистикой системы:
Для начала хочется обговорить, что реально означает пункт «Required server performance, new values per second (далее NVPS) (Требуемое быстродействие в секунду)». Так вот, он не соответствует тому, сколько реально данных попадает в систему в секунду, а является простым математических подсчетом всех активных элементов данных с учетом интервалов опроса. И тогда получается, что Zabbix-trapper в расчете не участвует. В нашей сети trapper использовался достаточно активно, так что давайте посмотрим, сколько реально NVPS в рассматриваемом окружении:
Как показано на графике, в среднем Zabbix обрабатывает около 9260 запросов в секунду. Кроме того, в сети бывали и короткие всплески до 15000 NVPS , с которыми сервер без проблем справился. Честно говоря, это здорово!
Архитектура
Первое, в чем стоит разобраться это архитектура системы мониторинга. Должен ли Zabbix быть отказоустойчивым? Будут ли иметь значение один-два часа простоя? Какие последствия ждут, если упадет база данных? Какие потребуются диски для базы, и какой настраивать RAID? Какая нужна пропускная способность между Zabbix-сервером и Zabbix-proxy? Какая максимальная задержка? Как собирать данные? Опрашивать сеть (пассивный мониторинг) или слушать сеть (активный мониторинг)?Давайте рассмотрим каждый вопрос детально. Если быть честным, то вопрос сети я не рассматривал при разворачивании системы, что привело к проблемам, которые в дальнейшем было трудно продиагностировать. Итак, вот общая схема архитектуры системы мониторинга:
Железо
Точно подобрать правильное железо процесс не из легких. Главное что я здесь сделал, это использовал SAN для хранения данных, так как база Заббикса требует много I/O дисковой системы. Проще говоря, чем быстрее диски у сервера БД, тем больше данных сможет обработать Заббикс.Конечно, ЦПУ и память тоже очень важны для MySQL. Большое количество ОЗУ позволяет Заббиксу хранить часто читаемые данные в памяти, что естественно способствует быстродействию системы. Изначально я планировал для сервера БД 64ГБ памяти, однако все замечательно работает и на 32ГБ до сих пор.
Сервера, на которых стоит сам zabbix_server, тоже должен иметь достаточно быстрые ЦПУ, так как необходимо, чтобы он спокойно обрабатывал сотни тысяч триггеров. Памяти же хватило бы и 12ГБ - так как на самом Заббикс сервере не так много процессов (практически весь мониторинг идет через прокси).
В отличии от СУБД и zabbix_server, Zabbix-прокси не требуют серьезного железа, поэтому я использовал «виртуалки». В основном собираются активные элементы данных, так что прокси служат как точки сбора данных, сами же практически ничего не опрашивают.
Вот сводная таблица, что я использовал в своей системе:
| Zabbix server | Zabbix БД | Zabbix proxies | SAN |
|---|---|---|---|
| HP ProLiant BL460c Gen8 12x Intel Xeon E5-2630 16GB memory 128GB disk CentOS 6.2 x64 Zabbix 2.0.6 |
HP ProLiant BL460c Gen8 12x Intel Xeon E5-2630 32GB memory 2TB SAN-backed storage (4Gbps FC) CentOS 6.2 x64 MySQL 5.6.12 |
VMware Virtual Machine 4x vCPU 8GB memory 50GB disk CentOS 6.2 x64 Zabbix 2.0.6 MySQL 5.5.18 |
Hitachi Unified Storage VM 2x 2TB LUN Tiered storage (with 2TB SSD) |
Отказоустойчивость Zabbix server
Вернемся к архитектурным вопросам, что я озвучивал выше. В больших сетях по понятным причинам не работающий мониторинг является настоящей катастрофой. Однако, архитектура Заббикса не позволяет запускать больше одного экземпляра процесса zabbix server.Поэтому я решил воспользоваться Linux HA с Pacemaker и CMAN. Для базовой настройки прошу глянуть мануал RedHat 6.4 . К сожалению, инструкция была изменена с момента, как я ее использовал, однако конечный результат должен получиться таким же. После базовой настройки дополнительно я настроил:
- Так как общий IP-адрес всегда используется активным Zabbix-сервером, то отсюда следует три преимущества:
- Всегда легко найти какой сервер активен
- Все соединения от Zabbix сервера всегда с одного и того же IP (После установки параметра SourceIP= в zabbix_server.conf)
- Всем Zabbix-прокси и Zabbix-агентам в качестве сервера просто указывается общий IP
- Так как общий IP-адрес всегда используется активным Zabbix-сервером, то отсюда следует три преимущества:
- Процесс zabbix_server
- в случае фейловера zabbix_server будет остановлен на старом сервере и запущен на новом
- Symlink для заданий cron
- Симлинк указывает на директорию, в которой лежат задания, которые должны выполняться только на активном Zabbix-сервере. Crontab должен иметь доступ ко всем задания через этот симлинк
- В случае фейловера симлинк удаляется на старом сервере и создается на новом
- crond
- В случае фейловера crond останавливается на старом сервере и запускается на новом активном сервере
Отказоустойчивость СУБД
Очевидно, что никакой пользы от отказоустойчивости серверов с Zabbix-серверами, если база данных может упасть в любой момент. Для MySQL есть огромное количество путей создать кластер, я расскажу о способе, что я использовал.Я также использовал Linux HA с Pacemaker и CMAN и для базы данных. Как оказалось, в нем есть пару отличный возможностей для управления репликацией MySQL. Я использую (использовал, смотри раздел «открытые проблемы») репликацию для синхронизации данных между активным(master) и резервным(slave) MySQL. Для начала, точно также как и для серверов Zabbix-сервера, мы делаем базовую настройку кластера. Затем в дополнении я настроил:
- Общий IP-адрес (shared IP address)
- В случае фейловера, IP-адрес переходит на сервер, который становится активным
- Так как общий IP-адрес всегда используется активным Zabbix-сервером, то отсюда следует два преимущества:
- Всегда легко найти, какой сервер активен
- В случае фейловера, на самом Zabbix-сервере не требуется никаких действий, чтобы указать адрес нового активного сервера MySQL
- Общий дополнительный (slave) IP-адрес
- Этот IP-адрес может использоваться, когда к происходит запрос на чтение к базе. Таким образом, запрос может обработать slave-сервер MySQL, если он доступен
- дополнительный адрес может быть у любого из серверов, это зависит от следующего:
- если slave-сервер доступен, и часы не отстают на более чем 60 секунд, то адрес будет у него
- В обратном случае адрес будет у master-сервера MySQL
- mysqld
- В случае фейловера новый сервер MySQL станет активным. Если после этого старый сервер вернется в строй, то он останется slave для уже новоиспечённого master.
Zabbix-прокси
Если по какой-то причине вы не слышали о Zabbix-прокси, то, пожалуйста, срочно посмотрите в документации . Прокси позволяют Заббиксу распределить нагрузку мониторинга на несколько машин. После этого уже каждый Заббикс прокси отсылает все собранные данные на Заббикс сервер.Работая с Заббикс прокси важно помнить:
- Заббикс прокси способны обрабатывать очень серьезные объемы данных, если их настроить как следует. Так, например, во время тестов, прокси (назовем ее Proxy А) обрабатывала 1500-1750 NVPS без каких либо проблем. И это виртуалка с двумя виртуальными ЦПУ, 4ГБ ОЗУ и БД SQLite3. При этом прокси находилась на одной площадки с самим сервером, так что задержки на сети можно было просто не учитывать. Также почти все, что собиралась, было активными элементами данных Заббикс агента
- Ранее я уже упоминал, как важна задержка на сети при мониторинге. Так вот, это действительно так, когда речь идет о крупных системах. Фактически, количество данных, которое может отослать прокси, не отставая, напрямую зависит от сети.
На графике ниже хорошо видно как накапливаются проблемы, когда задержка сети не учитывается. Прокси, который не успевает:
Пожалуй, достаточно очевидно, что очередь из данных для передачи не должна увеличиваться. График относится к другому Заббикс-прокси (Proxy B), которая ничем по железу не отличается от Proxy A, но может передавать без проблем только 500NVPS а не 1500NVPS, как Proxy A. Отличие как раз в том, что B находится в Сингапуре а сам сервер в Северной Америке, и задержка между площадками порядка 230мс. Данная задержка имеет серьезный эффект, учитывая способ пересылки данных. В нашем случае, Proxy B может отправить только по 1000 собранных элементов Заббикс серверу каждые 2-3 секунды. По моим наблюдениям, вот что происходит:
- Прокси устанавливает соединение до сервера
- Прокси максимум отправляет за раз 1000 собранных значений элементов данных
- Прокси закрывает соединение
- Первичное подключение очень медленное. В моем случае оно происходит за 0,25 секунды. Уф!
- Так как соединение закрывается после отправки 1000 элементов данных, то TCP-соединение никогда не длится достаточно долго, чтобы успеть использовать всю доступную пропускную способность канала.
Производительность базы данных
Высокая производительность базы данных является ключевой для системы мониторинга, так как абсолютно вся собранная информация попадает туда. При этом, с учетом большого количества операций записи в базу, производительность дисков - это первое бутылочное горлышко с которым сталкиваешься. Мне повезло и у меня в распоряжении оказались SSD-диски, однако все равно это не является гарантией быстрой работы базы. Вот пример:- Изначально в системе я использовал MySQL 5.5.18. Сначала никаких видимых проблем с производительностью не наблюдалось, однако, после 700-750 NVPS MySQL стал загружать процессор на 100% и система буквально «замерла». Дальнейшие мои попытки исправить ситуацию, подкручивая параметры в конфигурационном файле, активируя large pages или partitioning ни к чему не привели. Более хорошее решение предложила моя жена: сначала обновиться MySQL до 5.6 и потом разбираться. На мое удивление, простой апдейт решил все проблемы с производительностью, который я никак победить в 5.5.18. На всякий случай, вот копия my.cnf .
Обратите внимание, что больше всего запросов «Com_update». Причина кроется в том, что каждое полученное значение влечет Update в таблицу «items». Также в базе данных в основном операции на запись, так что MySQL query cache никак не поможет. По сути, он может быть даже вредным для производительности, учитывая, что постоянно придется маркировать запросы как неверные.
Другой проблемой для производительности может стать Zabbix Housekeeper. В больших сетях его настоятельно рекомендую отключать. Для этого в конфиг-файле выставите DisableHousekeeping=1. Понятно, что без Housekeeping старые данные(элементы данных, события, действия) не будут удаляться из базы. Тогда удаление можно организовать через partitioning.
Однако, одно из ограничений MySQL 5.6.12 в том, что partitioning не может быть использован в таблицах с foreign keys и как раз они присутствуют почти повсеместно в базе Заббикс. Но кроме таблиц history, которые нам и нужны. Partitioning дает нам два преимущества:
- Все исторические данные таблицы разбитые по днем/неделям/месяцам/и т.д. могут находиться в отдельных файлах, что позволяет в дальнейшем удалять данные без каких либо последствий для базы. Также очень просто понимать сколько данных собирается за определенный период времени.
- После очистки таблиц InnoDB не возвращает место диску, оставляя его себе для новых данных. В итоге с InnoDB невозможно очистить место на диске. В случае с partitioning это не проблема, место может быть освобождено, простым удалением старых партиций.
Собирать или слушать
В Заббиксе существует два метода сбора данных: активный и пассивный: В случае пассивного мониторинга Заббикс сервер сам опрашивает Заббикс агентов, а в случае активного - ждет когда Zabbix-агенты сами подключаться к серверу. Под активный мониторинг также попадает Zabbix trapper , так как инициация отсылки остается на стороне узла сети.Разница в производительности может быть серьезной при выборе одного или другого способа как основного. Пассивный мониторинг требует запущенных процессов на Заббикс сервере, которые будут регулярно посылать запрос к Заббикс агенту и ждать ответа, в некоторых случаях ожидание может затянуться даже до нескольких секунд. Теперь умножьте это время хотя бы на тысячу серверов, и становится ясно, что «поллинг» может занять время.
В случае активного мониторинга процессов опроса нет, сервер находится в состоянии ожидания, когда агенты сами начнут подключаться к Zabbix-серверу, чтобы получить список элементов данных, которые требуется мониторить.
Далее, агент начнет сам собирать элементы данных с учетом полученного с сервера интервала и отправлять их, при этом соединение будет открыто только тогда, когда агенту есть что отправить. Таким образом, отпадает необходимость в проверке до получения данных, которая присутствует при пассивном мониторинге. Вывод: активный мониторинг увеличивает скорость сбора данных, что и требуется в нашей большой сети.
Мониторинг самого Заббикса
Без мониторинга самого Zabbix эффективная работа большой системы просто не представляется возможной - критически важно понимать в каком месте произойдет «затык», когда система откажется принимать новые данные. Существующие элементы данных для мониторинга Заббикса могут быть найдены . В версиях 2.х Заббикса они были любезно собраны в шаблон для мониторинга Zabbix server, предоставляемый «из коробки». Пользуйтесь!Одной полезной метрикой является свободное место в History Write Cache (HistoryCacheSize в в конфиг-файле сервера). Данный параметр должен всегда быть близок к 100%. Если же кэш переполняется - это означает, что Zabbix не успевает добавлять в базу поступающие данные.
К сожалению, подобный параметр не поддерживается Zabbix-прокси. Кроме того, в Zabbix, отсутствует элемент данных, указывающий, сколько данных ожидает отправки на Zabbix-сервер. Впрочем, этот элемент данных легко сделать самому через SQL-запрос к базе прокси:
SELECT ((SELECT MAX(proxy_history.id) FROM proxy_history)-nextid) FROM ids WHERE field_name="history_lastid"
Запрос вернет необходимо число. Если у вас стоит SQLite3 в качестве БД для Zabbix-прокси, то просто добавьте следующую команду как UserParameter в конфиг-файле Zabbix-агента, установленного на машине, где крутится Zabbix-прокси.
UserParameter=zabbix.proxy.items.sync.remaining,/usr/bin/sqlite3 /path/to/the/sqlite/database "SELECT ((SELECT MAX(proxy_history.id) FROM proxy_history)-nextid) FROM ids WHERE field_name="history_lastid"" 2>&1
{Hostname:zabbix.proxy.items.sync.remaining.min(10m)}>100000
Итого статистика
Напоследок предлагаю графики загрузки системы. Сразу говорю, что не знаю, что произошло 16 июля - мне пришлось пересоздать все базы прокси (SQLite на тот момент), чтобы решить проблему. С тех пор я перевел все прокси на MySQL и проблема не повторялась. Остальные «неровности» графиков совпадают со временем проведения нагрузочного тестирования. В целом, из графиков видно, что у используемого железа большой запас прочности.
А вот графики с сервера базы данных. Приросты трафика каждый день соответствуют времени снятия дампа(mysqldump). Также провал 16 июля на графике запросов(qps) относится к той же проблеме, что я описывал выше.
Управление
Итого в системе используется 2 сервера под Zabbix-сервера, 2 сервера под MySQL, 16 виртуальных серверов под Zabbix-прокси и тысячи наблюдаемых серверов с Zabbix-агентами. При таком количестве хостов о внесении изменений руками не могло быть и речи. И решением стал Git-репозиторий, к которому имеют доступ все сервера, и где я расположил все конфигурационные файлы, скрипты, и все остальное, что нужно распространять. Далее, я написал скрипт, который вызывается через UserParameter в агенте. После запуска скрипта сервер подключается к Git-репозиторию, скачивает все необходимые файлы и обновления и затем перезагружает Zabbix-агента/прокси/сервера, если конфиг-файлы имели изменения. Обновление стало не сложнее, чем запустить zabbix_get!Открытые проблемы
Несмотря на все усилия, которые я приложил, осталась одна существенная проблема, которую мне только предстоит решить. Речь о том, что когда система достигает 8000-9000NVPS, то резервная база MySQL больше не успевает за основной, таким образом никакой отказоустойчивости на самом деле и нет.У меня есть идеи, как данную проблему можно решить, но еще не было времени это имплементировать:
- Использовать Linux-HA с DRBD для partitioning БД.
- LUN-репликация на SAN с репликацией на другой LUN
- Percona XtraDB cluster. В версии 5.6 еще недоступен, так что с этим придется подождать(как я писал, были проблемы с производительностью в MySQL 5.5)
Для хранения данных используется MySQL , PostgreSQL , SQLite или Oracle . Веб-интерфейс написан на PHP . ZABBIX поддерживает несколько видов мониторинга:
- Simple checks - может проверять доступность и реакцию стандартных сервисов, таких как SMTP или HTTP, без установки какого-либо программного обеспечения на наблюдаемом хосте.
- ZABBIX agent - может быть установлен на UNIX-подобных или Windows -хостах для получения данных о нагрузке процессора , использования сети, дисковом пространстве и т. д.
- External check - выполнение внешних программ. ZABBIX также поддерживает мониторинг через SNMP .
История
Zabbix начался в 1998 году как проект внутреннего программного обеспечения. Спустя 3 года, в 2001 году, он был выпущен публично под лицензией GPL . Прошло более трёх лет до выхода первой стабильной версии - 1.0, которая была выпущена в 2004.
| График релизов | |
|---|---|
| Дата | Релиз |
| Zabbix 1.0 | |
| 1998 | ПО Zabbix началось как внутренний проект в банке Алексеем Владышевым |
| 7 Апреля 2001 | Zabbix 1.0alpha1 был выпущен с лицензией GPL |
| 23 Марта 2004 | Выпущен Zabbix 1.0 |
| Zabbix 1.1 | |
| 6 Февраля 2006 | Выпущен Zabbix 1.1 |
| Zabbix 1.4 | |
| 29 Мая 2007 | Выпущен Zabbix 1.4 |
| Zabbix 1.6 | |
| 11 Сентября 2008 | Выпущен Zabbix 1.6 |
| Zabbix 1.8 | |
| 7 Декабря 2009 | Выпущен Zabbix 1.8 |
| Zabbix 2.0 | |
| 21 Мая 2012 | Выпущен Zabbix 2.0 |
| Zabbix 2.2.1 | |
| 21 Декабря 2013 | Выпущен Zabbix 2.2.1 |
| Zabbix 2.4.0 | |
| 11 Сентября 2014 | Выпущен Zabbix 2.4.0 |
| Zabbix 3.0 | |
| 16 Февраля 2016 | Выпущен Zabbix 3.0 |
Архитектура
- Zabbix-сервер - это ядро программного обеспечения Zabbix. Сервер может удаленно проверять сетевые сервисы, является хранилищем, в котором хранятся все конфигурационные, статистические и оперативные данные, и он является тем субъектом в программном обеспечении Zabbix, который оповестит администраторов в случае возникновения проблем с любым контролируемым оборудованием.
- Zabbix-прокси - собирает данные о производительности и доступности от имени Zabbix-сервера. Все собранные данные заносятся в буфер на локальном уровне и передаются Zabbix-серверу, к которому принадлежит прокси-сервер. Zabbix-прокси является идеальным решением для централизованного удаленного мониторинга мест, филиалов, сетей, не имеющих локальных администраторов. Он может быть также использован для распределения нагрузки одного Zabbix-сервера. В этом случае, прокси только собирает данные, тем самым на сервер ложится меньшая нагрузка на ЦПУ и на ввод-вывод диска.
- Zabbix-агент - контроль локальных ресурсов и приложений (таких как жесткие диски, память, статистика процессора и т. д.) на сетевых системах, эти системы должны работать с запущенным Zabbix-агентом. Zabbix-агенты являются чрезвычайно эффективными из-за использования родных системных вызовов для сбора информации о статистике.
- Веб-интерфейс - интерфейс является частью Zabbix-сервера, и, как правило (но не обязательно), запущен на том же физическом сервере, что и Zabbix-сервер. Работает на PHP , требует веб сервер (например, Apache).
Обзор возможностей
- Распределённый мониторинг вплоть до 1000 узлов. Конфигурация младших узлов полностью контролируется старшими узлами, находящимися на более высоком уровне иерархии.
- Сценарии на основе мониторинга
- Автоматическое обнаружение
- Централизованный мониторинг лог-файлов
- Веб-интерфейс для администрирования и настройки
- Отчетность и тенденции
- SLA мониторинг
- Поддержка высокопроизводительных агентов (zabbix-agent) практически для всех платформ
- Комплексная реакция на события
- Поддержка SNMP v1, 2, 3
- Поддержка SNMP ловушек
- Поддержка IPMI
- Поддержка мониторинга JMX приложений из коробки
- Поддержка выполнения запросов в различные базы данных без необходимости использования скриптовой обвязки
- Расширение за счет выполнения внешних скриптов
- Гибкая система шаблонов и групп
- Возможность создавать карты сетей
Автоматическое обнаружение
- Автоматическое обнаружение по диапазону IP-адресов, доступным сервисам и SNMP проверка
- Автоматический мониторинг обнаруженных устройств
- Автоматическое удаление отсутствующих хостов
- Распределение по группам и шаблонам в зависимости от возвращаемого результата
Низкоуровневое обнаружение
Низкоуровневое обнаружение может быть использовано для обнаружения и для начала мониторинга файловых систем, сетевых интерфейсов. Начиная с Zabbix 2.0, поддерживаются три встроенных механизма низкоуровневого обнаружения:
- обнаружение файловых систем
- обнаружение сетевых интерфейсов
- обнаружение нескольких SNMP OID’ов
Системные требования для установки ZABBIX-сервера
Поддерживаемые платформы
| Платформа | ZABBIX-сервер | ZABBIX-агент |
|---|---|---|
| AIX | Поддерживается | Поддерживается |
| FreeBSD | Поддерживается | Поддерживается |
| HP-UX | Поддерживается | Поддерживается |
| Linux | Поддерживается | Поддерживается |
| Mac OS X | Поддерживается | Поддерживается |
| Novell Netware | - | Поддерживается |
| OpenBSD | Поддерживается | Поддерживается |
| SCO Open Server | Поддерживается | Поддерживается |
| Solaris | Поддерживается | Поддерживается |
| Tru64/OSF | Поддерживается | Поддерживается |
| Windows NT 4.0, Windows 2000, Windows 2003, Windows XP, Windows Vista | - | Поддерживается |
См. также
Напишите отзыв о статье "Zabbix"
Примечания
Ссылки
- во FreeBSD
- во FreeBSD
- = =
Отрывок, характеризующий Zabbix
– Вы? – сказал он. – Как счастливо!Наташа быстрым, но осторожным движением подвинулась к нему на коленях и, взяв осторожно его руку, нагнулась над ней лицом и стала целовать ее, чуть дотрогиваясь губами.
– Простите! – сказала она шепотом, подняв голову и взглядывая на него. – Простите меня!
– Я вас люблю, – сказал князь Андрей.
– Простите…
– Что простить? – спросил князь Андрей.
– Простите меня за то, что я сделала, – чуть слышным, прерывным шепотом проговорила Наташа и чаще стала, чуть дотрогиваясь губами, целовать руку.
– Я люблю тебя больше, лучше, чем прежде, – сказал князь Андрей, поднимая рукой ее лицо так, чтобы он мог глядеть в ее глаза.
Глаза эти, налитые счастливыми слезами, робко, сострадательно и радостно любовно смотрели на него. Худое и бледное лицо Наташи с распухшими губами было более чем некрасиво, оно было страшно. Но князь Андрей не видел этого лица, он видел сияющие глаза, которые были прекрасны. Сзади их послышался говор.
Петр камердинер, теперь совсем очнувшийся от сна, разбудил доктора. Тимохин, не спавший все время от боли в ноге, давно уже видел все, что делалось, и, старательно закрывая простыней свое неодетое тело, ежился на лавке.
– Это что такое? – сказал доктор, приподнявшись с своего ложа. – Извольте идти, сударыня.
В это же время в дверь стучалась девушка, посланная графиней, хватившейся дочери.
Как сомнамбулка, которую разбудили в середине ее сна, Наташа вышла из комнаты и, вернувшись в свою избу, рыдая упала на свою постель.
С этого дня, во время всего дальнейшего путешествия Ростовых, на всех отдыхах и ночлегах, Наташа не отходила от раненого Болконского, и доктор должен был признаться, что он не ожидал от девицы ни такой твердости, ни такого искусства ходить за раненым.
Как ни страшна казалась для графини мысль, что князь Андрей мог (весьма вероятно, по словам доктора) умереть во время дороги на руках ее дочери, она не могла противиться Наташе. Хотя вследствие теперь установившегося сближения между раненым князем Андреем и Наташей приходило в голову, что в случае выздоровления прежние отношения жениха и невесты будут возобновлены, никто, еще менее Наташа и князь Андрей, не говорил об этом: нерешенный, висящий вопрос жизни или смерти не только над Болконским, но над Россией заслонял все другие предположения.
Пьер проснулся 3 го сентября поздно. Голова его болела, платье, в котором он спал не раздеваясь, тяготило его тело, и на душе было смутное сознание чего то постыдного, совершенного накануне; это постыдное был вчерашний разговор с капитаном Рамбалем.
Часы показывали одиннадцать, но на дворе казалось особенно пасмурно. Пьер встал, протер глаза и, увидав пистолет с вырезным ложем, который Герасим положил опять на письменный стол, Пьер вспомнил то, где он находился и что ему предстояло именно в нынешний день.
«Уж не опоздал ли я? – подумал Пьер. – Нет, вероятно, он сделает свой въезд в Москву не ранее двенадцати». Пьер не позволял себе размышлять о том, что ему предстояло, но торопился поскорее действовать.
Оправив на себе платье, Пьер взял в руки пистолет и сбирался уже идти. Но тут ему в первый раз пришла мысль о том, каким образом, не в руке же, по улице нести ему это оружие. Даже и под широким кафтаном трудно было спрятать большой пистолет. Ни за поясом, ни под мышкой нельзя было поместить его незаметным. Кроме того, пистолет был разряжен, а Пьер не успел зарядить его. «Все равно, кинжал», – сказал себе Пьер, хотя он не раз, обсуживая исполнение своего намерения, решал сам с собою, что главная ошибка студента в 1809 году состояла в том, что он хотел убить Наполеона кинжалом. Но, как будто главная цель Пьера состояла не в том, чтобы исполнить задуманное дело, а в том, чтобы показать самому себе, что не отрекается от своего намерения и делает все для исполнения его, Пьер поспешно взял купленный им у Сухаревой башни вместе с пистолетом тупой зазубренный кинжал в зеленых ножнах и спрятал его под жилет.
Подпоясав кафтан и надвинув шапку, Пьер, стараясь не шуметь и не встретить капитана, прошел по коридору и вышел на улицу.
Тот пожар, на который так равнодушно смотрел он накануне вечером, за ночь значительно увеличился. Москва горела уже с разных сторон. Горели в одно и то же время Каретный ряд, Замоскворечье, Гостиный двор, Поварская, барки на Москве реке и дровяной рынок у Дорогомиловского моста.
Путь Пьера лежал через переулки на Поварскую и оттуда на Арбат, к Николе Явленному, у которого он в воображении своем давно определил место, на котором должно быть совершено его дело. У большей части домов были заперты ворота и ставни. Улицы и переулки были пустынны. В воздухе пахло гарью и дымом. Изредка встречались русские с беспокойно робкими лицами и французы с негородским, лагерным видом, шедшие по серединам улиц. И те и другие с удивлением смотрели на Пьера. Кроме большого роста и толщины, кроме странного мрачно сосредоточенного и страдальческого выражения лица и всей фигуры, русские присматривались к Пьеру, потому что не понимали, к какому сословию мог принадлежать этот человек. Французы же с удивлением провожали его глазами, в особенности потому, что Пьер, противно всем другим русским, испуганно или любопытна смотревшим на французов, не обращал на них никакого внимания. У ворот одного дома три француза, толковавшие что то не понимавшим их русским людям, остановили Пьера, спрашивая, не знает ли он по французски?
Пьер отрицательно покачал головой и пошел дальше. В другом переулке на него крикнул часовой, стоявший у зеленого ящика, и Пьер только на повторенный грозный крик и звук ружья, взятого часовым на руку, понял, что он должен был обойти другой стороной улицы. Он ничего не слышал и не видел вокруг себя. Он, как что то страшное и чуждое ему, с поспешностью и ужасом нес в себе свое намерение, боясь – наученный опытом прошлой ночи – как нибудь растерять его. Но Пьеру не суждено было донести в целости свое настроение до того места, куда он направлялся. Кроме того, ежели бы даже он и не был ничем задержан на пути, намерение его не могло быть исполнено уже потому, что Наполеон тому назад более четырех часов проехал из Дорогомиловского предместья через Арбат в Кремль и теперь в самом мрачном расположении духа сидел в царском кабинете кремлевского дворца и отдавал подробные, обстоятельные приказания о мерах, которые немедленно должны были бытт, приняты для тушения пожара, предупреждения мародерства и успокоения жителей. Но Пьер не знал этого; он, весь поглощенный предстоящим, мучился, как мучаются люди, упрямо предпринявшие дело невозможное – не по трудностям, но по несвойственности дела с своей природой; он мучился страхом того, что он ослабеет в решительную минуту и, вследствие того, потеряет уважение к себе.
Он хотя ничего не видел и не слышал вокруг себя, но инстинктом соображал дорогу и не ошибался переулками, выводившими его на Поварскую.
По мере того как Пьер приближался к Поварской, дым становился сильнее и сильнее, становилось даже тепло от огня пожара. Изредка взвивались огненные языка из за крыш домов. Больше народу встречалось на улицах, и народ этот был тревожнее. Но Пьер, хотя и чувствовал, что что то такое необыкновенное творилось вокруг него, не отдавал себе отчета о том, что он подходил к пожару. Проходя по тропинке, шедшей по большому незастроенному месту, примыкавшему одной стороной к Поварской, другой к садам дома князя Грузинского, Пьер вдруг услыхал подле самого себя отчаянный плач женщины. Он остановился, как бы пробудившись от сна, и поднял голову.
Системное администрирование неэффективно без автоматизированных средств мониторинга, позволяющих своевременно реагировать на нештатные ситуации и отслеживать динамику работы сервисов. При малом количестве серверов часто применяются скрипты, написанные под конкретные нужды, но с ростом инфраструктуры такой подход начинает вызывать множество проблем. И тут на помощь приходят уже готовые инструменты, один из которых - Zabbix .
Zabbix - это многофункциональная система мониторинга с веб-интерфейсом, которая подстраивается под нужные системы, собирая с них статистику, и действующая заданным образом в предусмотренных случаях.
Основной дашборд
Система состоит из четырёх основных компонентов:
- Сервер мониторинга, который собирает и обрабатывает данные от всех агентов.
- Прокси сервер, выполняющий те же функции, но с последующей отправкой на центральный сервер.
- Веб-интерфейс для мониторинга.
- Агент, собирающий данные на физическом сервере.
Для работы необходима одна из нескольких возможных вариантов баз данных, которая должна быть предварительно настроена (это происходит автоматически, с помощью готовых скриптов):
- MySQL;
- Oracle;
- PostgreSQL;
- SQLite;
- IBM DB2.
Краткая история
29 выпуск SDCast в августе 2015 немного пролил свет на то, как всё происходило. Zabbix был создан в 1998 для нужд банка Алексеем Владышевым. В те времена он был написан на языке Perl. Позднее проект был сильно переработан, в частности - переписан на C и PHP, изменилась его архитектура. В 2001 году Zabbix открыл исходные коды под свободной лицензией GPL, а стабильная версия 1.0 была выпущена спустя три года, в 2004. В 2005 была создана компания Zabbix SIA, занимающаяся оказанием платных технических услуг, связанных с ПО.
Возможности Zabbix
В систему мониторинга уже встроен ряд стандартных метрик:
- нагрузка на процессор, в том числе отдельными процессами;
- объём свободной оперативной памяти;
- активность жёсткого диска;
- объём свободной физической памяти;
- сетевая активность;
- пинг.
А также прочие проверки общего назначения и для самых распространённых сервисов, таких как веб-сервер, СУБД, SSH, Telnet, VMware, NTP, POP, SMTP, FTP и других.
Чтобы задать реакцию при отклонении каких-либо метрик от нормы, используются специальные условия - триггеры . Например, если пинг отсутствует пять минут, выводится уведомление администратору и выполняется команда перезапуска сервиса.
Для выхода из нештатной ситуации применяются отдельные условия, поэтому незначительное улучшение метрики не является достаточным для устранения неполадки. Например, если свободного места на жёстком диске осталось меньше 10%, сработает аварийный триггер и чтобы он выключился, значение должно превышать 30%.
Если готового функционала недостаточно, то можно использовать свой - настроить реакцию на определённый вывод команд (чтение выходного потока от утилит), либо написать дополнение, используя API.
Проверки
Установка агента не является обязательной, всего на выбор администратора есть 17 способов осуществления сбора информации с сервера.
- Zabbix agent - сервер сам опрашивает агента, подключаясь к нему с нужным интервалом.
- Zabbix agent (active) - агент подключается к серверу и отправляет информацию.
- Simple check - различные простые проверки (например, пинг).
- SNMP agent (версии 1-3, trap) - сбор данных по SNMP протоколу.
- Zabbix Internal - сбор информации с самого сервера Zabbix для проверки его состояния.
- Zabbix trapper - сбор данных с трапперов, которые являются мостом между некими сервисами и Zabbix (принимают данные по сети из сторонних приложений, чтобы транспортировать их на сервер мониторинга).
- Zabbix aggregate - проверка, при которой происходит сбор совокупной информации из базы данных.
- External check - внешняя проверка, при которой запускается исполняемый файл и считывается стандартный вывод.
- Zabbix database monitor - сбор данных из базы через ODBC.
- IPMI agent - сбор данных через интерфейс IPMI.
- SSH agent - Zabbix подключается по SSH и выполняет заданные команды, считывая стандартный вывод.
- TELNET agent - делает то же самое, что и SSH agent, но по протоколу TELNET.
- JMX agent - сбор информации через технологию JMX (наблюдение за Java машиной).
- Calculate - вычисления на основе различных данных (других проверок, их исторических значений).
Читайте также:
Что нового в System Center 1801
Для стандартных проверок Zabbix уже имеет шаблоны определения состояния, что упрощает их создание. Помимо перечисленного, есть проверка доступности веб-сервера, когда система мониторинга имитирует запросы браузера.
Агент Zabbix способен собирать различную информацию, отражающую текущее состояние физического сервера. Например:
- CPU idle time - время простоя (когда процессор не выполняет никаких операций).
- CPU interrupt timer - время, затрачиваемое на обработку прерываний от оборудования.
- CPU iowait time - время ожидания запрошенных ресурсов.
- CPU nice time - время, потраченное на обслуживание процессов с изменёнными приоритетами.
- Interrupts per second - количество прерываний от оборудования в секунду.
- Processor load - загруженность ядра процессора.
- Host boot time - время, за которое происходит включение физического сервера.
- Host local time - значение локального времени на сервере.
- System uptime - время непрерывной работы сервера.
- Available memory - объём свободного дискового пространства.
- Free swap space - объём свободного места подкачки.
- Free swap space in % - то же самое, только в процентах.
- Total memory - общий объём дискового пространства.
- Total swap space - общий объём системы подкачки.
И многие другие метрики.
Триггеры
Триггеры представляют собой логические выражения, цель которых - обрабатывать накопленные данные. Их можно составлять как вручную, так и с помощью конструктора. Есть функция тестирования триггеров на произвольных значениях. Для составления триггеров используются операторы Zabbix, подставляющие необходимые данные, в том числе из конкретной проверки или за заданный интервал времени.
Устанавливается реакция на сработавшие условия, её важность, критерии выхода (снятия предупреждения).
Прогнозирование
У триггеров есть довольно полезная возможность - функции предугадывания будущих значений и того, когда они возникнут по времени. Для составления прогноза используются исторические данные, проанализировав которые, триггер может выявить возможные проблемы в будущем, выдав соответствующее уведомление. Таким образом, можно заранее предупреждать возникающие проблемы, например, пики нагрузки на оборудование или заканчивающееся место на жёстком диске. Данная функциональность была добавлена в обновлении 3.0, выпущенным в феврале 2016.
Низкоуровневое обнаружение
Читайте также:
Обзор функции MP Updates and Recommendations в Microsoft SCOM 2016
Оно предназначается для автоматического создания элементов и триггеров, чтобы отслеживать состояние различных систем наблюдаемого сервера.
Zabbix умеет обнаруживать:
- файловые системы;
- сетевые интерфейсы;
- процессоры и их ядра;
- распространённые OID, используемые SNMP;
- наличие ODBC;
- службы Windows.
Если этого мало, то имеется возможность задать свои типы обнаружения, используя формат JSON .
Прокси Zabbix
Прокси Zabbix используют в тех случаях, когда инфраструктура достаточно велика, чтобы на одиночный сервер ложилась слишком большая нагрузка. Прокси выступает в роли промежуточного звена, собирающего данные с агентов, как это делает основной сервер. Затем данные из буфера отправляются на центральный сервер.
Но это не единственная причина, по которой может понадобится использование прокси. Он так же нужен, если некоторые агенты находятся в значительно отдалённых местах, что сказывается на величине пинга и их доступности, либо по каким-то причинам ограничены локальной сетью.
Интерфейс
Взаимодействие пользователей с самой системой мониторинга происходит через веб-панель, на которой сгруппированы все элементы управления. На главном экране отображается основная информация: состояние узлов сети и индикаторы состояния триггеров.
Узлы сети - это серверы, с которых снимается информация. У каждого узла есть элементы - отслеживаемые параметры, на изменение которых, собственно, и реагирует система. Каждому параметру можно задать свой интервал обновления и скорость изменения (например, чтобы сообщение о проблеме выводилось только после N проваленных проверок). Для каждого узла не обязательно выставлять свои параметры. Если они одинаковые, то оптимальным решением является использование шаблонов , которые наследуют все серверы.
Управление шаблонами в Zabbix
Узлы объединяются в группы, общая информация о которых видна в панели. По каждой группе и по серверу в отдельности можно посмотреть лог последних событий и различные графики, построенные на основе данных из параметров.
Управление группами хостов в Zabbix
Графики в Zabbix
Диаграммы в Zabbix
Управление системой так же осуществляется через веб интерфейс: именно там создаются и настраиваются группы, серверы, сбор параметров, триггеры и прочее. Возможно создание множества аккаунтов с разными уровнями доступа.
1-го октября 2018 года вышла новая версия бесплатной системы мониторинга, которую я постоянно использую. Я подробно расскажу об установке и начальной настройке Zabbix 4.0 на примере систем CentOS, Debian, Ubuntu со скриншотами и пояснениями. В этой версии много интересных и полезных нововведений, так что посмотреть на неё однозначно стоит.
На сегодняшний день, по моему мнению, из бесплатных систем мониторинга именно Zabbix самая популярная и функциональная. Упоминания о ней я постоянно встречаю в технических статьях специалистов различного масштаба и организаций. К примеру, СберТех использует Zabbix как единую платформу мониторинга. ИТ отдел сети магазинов Магнит так же использует zabbix как основную систему мониторинга. Пару лет назад я смотрел выступление представителя ИТ отдела Магнита, где он подробно описывал структуру системы. На тот момент это была самая крупная инсталляция заббикса с тысячами прокси серверов для сбора данных из магазинов по всей стране. Упоминания о мониторинге заббикс я встречал у специалистов компаний 1С, Крок, Яндекс.Деньги и других. Перечислил только то, что запомнилось.
Нужно понимать, что Zabbix — система мониторинга общего назначения. У нее нет специализации в микросервисы, сеть, железо и т.д. В связи с этим, всегда может найтись инструмент, который сможет выполнять ту или иную задачу удобнее и эффективнее, чем zabbix. Но это не умоляет остальных достоинств системы. Я их вижу в первую очередь в том, что в ней можно настроить мониторинг всего, что угодно. Главное научиться подавать значения в систему. А для этого есть масса инструментов — как самих агентов, так и скриптов, которые можно подключать к сбору данных.
Система мониторинга Zabbix позволяет так или иначе завести на нее все обслуживаемые сервисы. Где-то это может быть не очень просто, но в любом случае, один универсальный инструмент удобнее, чем несколько. Мне всегда удавалось настроить желаемый мониторинг с помощью заббикса. Если не было готовых шаблонов или подходящих агентов для сбора, писал скрипты и передавал ими данные агенту. С моими (и не только) решениями по мониторингу можете познакомиться в отдельном разделе .
Чем меня еще подкупает zabbix — хорошая документация и большое комьюнити. Много выступлений от различных специалистов с описанием внедрений. Все это облегчает работу с системой. Проще принять решение как поступить в той или иной ситуации. Сами разработчики постоянно проводят встречи, приглашают выступающих, потом выкладывают видео. В общем, система со всех сторон оставляет благоприятное впечатление.
Я буду устанавливать и настраивать работу сервера zabbix на nginx, что несколько отличается от дефолтной установки, которая включает в себя веб сервер apache. В связи с этим, нам необходимо будет подготовиться.
Подготовка сервера CentOS к установке
Первым делом вам необходимо и сервер CentOS 7. Перед установкой сервера Zabbix нам также нужно подготовить Web сервер. У меня есть отдельная статья по . Там все подробно описано. Сейчас же я кратко и без лишних комментариев выполню минимум необходимых действий для работы заббикса. Так же я не буду останавливаться на . Эта отдельная тема и мне не хочется ее касаться в этой статье. Либо настройте сами по моим инструкциям, либо просто отключите firewall:
# systemctl stop firewalld # systemctl disable firewalld
Подключаем репозиторий nginx и устанавливаем его:
# rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm # yum install nginx
Запускаем nginx и добавляем в автозагрузку.
Проверяем, работает ли он. Для этого открываем в браузере ссылку http://192.168.13.117/, где 192.168.13.117 — ip адрес настраиваемого сервера.
Если у вас не работает nginx, разберитесь с ним, прежде чем двигаться дальше. В первую очередь проверьте настройки фаервола.
# yum install epel-release # rpm -Uhv http://rpms.remirepo.net/enterprise/remi-release-7.rpm
Активируем репу remi-php71, для этого выполняем команды:
# yum install yum-utils # yum-config-manager --enable remi-php71
Устанавливаем php 7.1 и модули к нему.
# yum install php71 php-fpm php-cli php-mysql php-gd php-ldap php-odbc php-pdo php-pecl-memcache php-pear php-xml php-xmlrpc php-mbstring php-snmp php-soap php-bcmath
Запускаем php-fpm и добавляем в автозагрузку.
# systemctl start php-fpm # systemctl enable php-fpm
Проверяем, запустился ли он.
# netstat -tulpn | grep php-fpm tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 13261/php-fpm: mast
Все в порядке, запустился на порту 9000. Запустим его через unix сокет. Для этого открываем конфиг /etc/php-fpm.d/www.conf и комментируем строку:
# mcedit /etc/php-fpm.d/www.conf ;listen = 127.0.0.1:9000
Вместо нее добавляем несколько других:
Listen = /var/run/php-fpm/php-fpm.sock listen.mode = 0660 listen.owner = nginx listen.group = nginx
Заодно измените пользователя, от которого будет работать php-fpm. Вместо apache укажите nginx, отредактировав соответствующие параметры.
User = nginx group = nginx
Перезапускаем php-fpm.
# systemctl restart php-fpm
Проверяем, стартовал ли указанный сокет.
# ll /var/run/php-fpm/php-fpm.sock srw-rw----. 1 nginx nginx 0 Oct 4 15:08 /var/run/php-fpm/php-fpm.sock
На текущий момент с настройкой php-fpm закончили. Продолжаем подготовку сервера к установке zabbix.
Устанавливаем свежую версию MariaDB. Подключаем репозиторий. Для этого создаем файл /etc/yum.repos.d/mariadb.repo следующего содержания.
# mcedit /etc/yum.repos.d/mariadb.repo # MariaDB 10.3 CentOS repository list - created 2018-10-04 12:10 UTC # http://downloads.mariadb.org/mariadb/repositories/ name = MariaDB baseurl = http://yum.mariadb.org/10.3/centos7-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1
Устанавливаем последнюю версию mariadb на centos.
# yum install MariaDB-server MariaDB-client
Запускаем mariadb и добавляем в автозагрузку.
# systemctl start mariadb # systemctl enable mariadb
Внесем некоторые изменения в стандартный конфиг mariadb, чтобы потом не заниматься . Для этого открываем конфиг mysql /etc/my.cnf.d/server.cnf и приводим его к следующему виду.
# mcedit /etc/my.cnf.d/server.cnf port = 3306 socket = /var/lib/mysql/mysql.sock default-character-set=utf8 character_set_server=utf8 collation-server=utf8_bin init_connect="SET NAMES utf8 collate utf8_bin" port = 3306 socket = /var/lib/mysql/mysql.sock innodb_file_per_table=1 innodb_buffer_pool_size = 768M # внимание на параметр! установить примерно в 2 раза меньше объема оперативной памяти сервера innodb_buffer_pool_instances=1 # увеличивать на 1 каждый GB innodb_buffer_pool_size innodb_flush_log_at_trx_commit = 0 innodb_log_file_size = 512M innodb_log_files_in_group = 3
Я добавил минимум настроек, отличных от дефолта. В статье про оптимизацию mysql их приведено гораздо больше, но со временем я понял, что зря это сделал. Реально у меня нет большого опыта в тонкой настройке mysql. Никаких тестов и проверок я не делал, а данные брал на основе других статей в интернете. Не факт, что там не было ошибок. В итоге сейчас тут только заданы некоторые важные параметры по innodb, в частности указание хранить каждую таблицу в отдельном файле, задан размер и количество бинарных логов и еще пару настроек, которые явно будут к месту (innodb_buffer_pool_size, innodb_buffer_pool_instances и innodb_flush_log_at_trx_commit). При желании, вы можете сами заняться тюнингом mysql. В общем случае, достаточно будет текущих настроек.
# systemctl restart mariadb # systemctl status mariadb.service
Сервер баз данных mysql для нашего zabbix сервера готов. На этом предварительные настройки сервера закончены. Приступаем к установке.
Установка сервера Zabbix 4.0 в CentOS
Для того, чтобы установить Zabbix Server 4.0 нужно подключить репозиторий актуальной версии.
# rpm -Uvh https://repo.zabbix.com/zabbix/4.0/rhel/7/x86_64/zabbix-release-4.0-1.el7.noarch.rpm Retrieving https://repo.zabbix.com/zabbix/4.0/rhel/7/x86_64/zabbix-release-4.0-1.el7.noarch.rpm warning: /var/tmp/rpm-tmp.fCWryx: Header V4 RSA/SHA512 Signature, key ID a14fe591: NOKEY Preparing... ################################# Updating / installing... 1:zabbix-release-4.0-1.el7 #################################
Устанавливаем сам сервер заббикса.
# yum install zabbix-server-mysql zabbix-web-mysql
В зависимостях пакетов будет httpd, который нам не нужен, так как у нас будет nginx и php7.1, но я не разбирался, как поставить без него. После установки пакетов, создадим базу данных, пользователя zabbix и заполним базу.
# mysql -uroot -p Enter password: > create database zabbix character set utf8 collate utf8_bin; > grant all privileges on zabbix.* to zabbix@localhost identified by "zabpassword"; exit # zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbix
Этих минимальных настроек достаточно, для работы сервера. Я рекомендую увеличивать параметр Timeout , так как он отвечает за время ожидания ответа от агента, snmp устройства или внешней проверки. Иногда стандартного значения в 4 секунды бывает недостаточно. В частности, когда используется какой-то скрипт, который долго выполняется для получения метрики. Поставьте секунд 10.
Проверяем лог файл на наличие ошибок.
# cat /var/log/zabbix/zabbix_server.log
Настройка SELinux с zabbix
Если у вас включен SELinux, получите ошибку.
Cannot start preprocessing service: Cannot bind socket to "/var/run/zabbix/zabbix_server_preprocessing.sock": Permission denied.
Это нормально, сейчас настроим SELinux для нормальной работы Zabbix. Для этого устанавливаем пакет policycoreutils-python, скачиваем готовый модуль для SELinux и применяем его.
# yum install policycoreutils-python # cd ~ # curl https://support.zabbix.com/secure/attachment/53320/zabbix_server_add.te > zabbix_server_add.te # checkmodule -M -m -o zabbix_server_add.mod zabbix_server_add.te # semodule_package -m zabbix_server_add.mod -o zabbix_server_add.pp # semodule -i zabbix_server_add.pp
Теперь нам надо перезапустить zabbix-server.
# systemctl restart zabbix-server
Если у вас это не получится сделать через systemctl, значит служба зависла. Завершаем ее принудительно и запускаем снова.
# kill -9 `pidof zabbix_server` # systemctl start zabbix-server
Снова проверяйте log файл. Теперь ошибок быть не должно. Как я уже сказал, если у вас отключен SELinux, то делать описанные выше манипуляции с модулем не надо.
С серверной частью закончили. Нам нужно сделать конфиг nginx для работы web интерфейса zabbix. Если у вас nginx работает на том же сервере, где сам zabbix, и других виртуальных хостов нет и не будет, то правьте сразу дефолтный — /etc/nginx/conf.d/default.conf
# mcedit /etc/nginx/conf.d/default.conf server { listen 80; server_name localhost; root /usr/share/zabbix; location / { index index.php index.html index.htm; } location ~ \.php$ { fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_param PHP_VALUE " max_execution_time = 300 memory_limit = 128M post_max_size = 16M upload_max_filesize = 2M max_input_time = 300 date.timezone = Europe/Moscow always_populate_raw_post_data = -1 "; fastcgi_buffers 8 256k; fastcgi_buffer_size 128k; fastcgi_intercept_errors on; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; } }
Маленький, но важный нюанс. Нам надо изменить права доступа на некоторые папки. Назначить владельца nginx.
# chown -R nginx:nginx /var/lib/php/session # chown -R nginx:nginx /etc/zabbix/web
Этот шаг нужно будет проделывать после каждого обновления php или zabbix. Связано с тем, что по-умолчанию zabbix идет в комплекте с apache и рассчитан на работу с ним. Поэтому после установки или обновления, он делает его владельцем директории /etc/zabbix/web .
Даем разрешения SELinux для работы заббикса с web сервером и базой данных.
# setsebool -P httpd_can_connect_zabbix on # setsebool -P httpd_can_network_connect_db on
Я не знаю, насколько последняя настройка актуальна, если подключение к БД локальное. У разработчиков в инструкции сказано, что в случае с postgresql даже если подключаетесь через 127.0.0.1, разрешение выдавать нужно. Насчет mysql нет комментариев.
С серверной частью закончили. Для продолжения установки zabbix сервера переходим к .
Установка сервера Zabbix 4.0 в Ubuntu, Debian
С установкой Zabbix на сервер с Ubuntu или Debian попроще, так как в стандартных репозиториях посвежее версии софта, можно использовать их. Подключаем репозитории zabbix 4.0.
# wget https://repo.zabbix.com/zabbix/4.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_4.0-2+bionic_all.deb # dpkg -i zabbix-release_4.0-2+bionic_all.deb
# wget https://repo.zabbix.com/zabbix/4.0/debian/pool/main/z/zabbix-release/zabbix-release_4.0-2+stretch_all.deb # dpkg -i zabbix-release_4.0-2+stretch_all.deb
Если у вас другие версии систем, то простой найдите ссылки пакетов под свою версию в официальном репозитории - https://repo.zabbix.com/zabbix/4.0/ Дальнейшая установка не будет отличаться от текущей.
Обновляем информацию о репозиториях, а заодно и последние обновления поставим:
# apt update && apt upgrade
Устанавливаем zabbix сервер:
# apt install zabbix-server-mysql zabbix-frontend-php
Он по-умолчанию ставится с apache, который сразу же запускается. Остановим его и отключим:
# systemctl stop apache2 # systemctl disable apache2
Ставим отдельно nginx и php-fpm:
# apt install nginx php-fpm
Запускаем скрипт начальной конфигурации mysql и задаем пароль для root. Все остальное можно оставить по-умолчанию.
# /usr/bin/mysql_secure_installation
Отредактируем некоторые параметры Mariadb в конфиге /etc/mysql/mariadb.conf.d/50-server.cnf . Добавляем туда в секцию :
# mcedit /etc/mysql/mariadb.conf.d/50-server.cnf innodb_file_per_table=1 innodb_buffer_pool_size = 768M # внимание на параметр! установить примерно в 2 раза меньше объема оперативной памяти сервера innodb_buffer_pool_instances=1 # увеличивать на 1 каждый GB innodb_buffer_pool_size innodb_flush_log_at_trx_commit = 0 innodb_log_file_size = 512M innodb_log_files_in_group = 3
Перезапустите mariadb и убедитесь, что она запустилась.
# systemctl restart mariadb # netstat -tulnp | grep mysqld tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 16753/mysqld
Cоздадим базу данных, пользователя zabbix, и заполним базу.
# mysql -uroot -p Enter password: > create database zabbix character set utf8 collate utf8_bin; > grant all privileges on zabbix.* to zabbix@localhost identified by "zabpassword"; exit # zcat /usr/share/doc/zabbix-server-mysql/create.sql.gz | mysql -uzabbix -p zabbix
Теперь редактируем файл конфигурации сервера заббикс. Прописываем данные для подключения к БД, отключаем ipv6 и увеличиваем стандартный timeout.
# mcedit /etc/zabbix/zabbix_server.conf
Изменяем указанные строки, остальные не трогаем:
DBHost=localhost DBName=zabbix DBUser=zabbix DBPassword=zabpassword ListenIP=0.0.0.0 Timeout=10
Этих минимальных настроек достаточно, для работы сервера. Я рекомендую увеличивать параметр Timeout, так как он отвечает за время ожидания ответа от агента, snmp устройства или внешней проверки. Иногда стандартного значения в 4 секунды бывает недостаточно. В частности, когда используется какой-то скрипт, который долго выполняется, для получения метрики. Поставьте секунд 10.
Запускаем zabbix и добавляем в автозагрузку.
# systemctl start zabbix-server # systemctl enable zabbix-server
Проверяем запустился ли.
# netstat -tulnp | grep zabbix_server tcp 0 0 0.0.0.0:10051 0.0.0.0:* LISTEN 16847/zabbix_server
Все в порядке. Запускаем nginx, который у нас будет выступать в качестве web сервера.
# systemctl start nginx # systemctl enable nginx
Убедимся, что в качестве web сервера работает nginx.
# netstat -tulnp | grep 80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 17075/nginx: master tcp6 0 0:::80:::* LISTEN 17075/nginx: master
Нам нужно сделать конфиг nginx для работы web интерфейса zabbix. Если у вас nginx работает на том же сервере, где сам zabbix, и других виртуальных хостов нет и не будет, то правьте сразу дефолтный - /etc/nginx/sites-available/default . Приводим его к следующему виду:
# mcedit /etc/nginx/sites-available/default server { listen 80; server_name localhost; root /usr/share/zabbix; location / { index index.php index.html index.htm; } location ~ \.php$ { fastcgi_pass unix:/run/php/php7.2-fpm.sock ; # проверьте этот путь, для разных версий php он будет разный fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_param PHP_VALUE " max_execution_time = 300 memory_limit = 128M post_max_size = 16M upload_max_filesize = 2M max_input_time = 300 date.timezone = Europe/Moscow always_populate_raw_post_data = -1 "; fastcgi_buffers 8 256k; fastcgi_buffer_size 128k; fastcgi_intercept_errors on; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; } }
Проверим конфиг на ошибки и если все в порядке, перезапустим nginx.
# nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful # nginx -s reload
С серверной частью закончили. Для продолжения установки zabbix сервера переходим к настройке Zabbix Frontend.
Настройка Zabbix Frontend
Идем в браузер и открываем адрес http://192.168.13.117. Вы должны увидеть установщик Zabbix 4.0.
Нажимаем Next step и начинаем настройку web интерфейса. На следующей странице будет проверка требований. У вас должны быть выполнены все требования. В зависимости от системы и версии php, информация будет в каждом случае разниться.
На следующем этапе указываем параметры доступа к базе данных, потом Zabbix server details. Там можно ничего не указывать, а оставить дефолтные параметры. Потом будет страница с проверкой введенных данных. Если все в порядке, то заканчивайте установку. В конце увидите сообщение: Congratulations! You have successfully installed Zabbix frontend.
После нажатия на Finish увидите окно авторизации Zabbix сервера.
Стандартная учетная запись для входа в web интерфейс zabbix следующая:
- Пользователь Admin
- Пароль zabbix
После логина увидите стандартный dashboard.
На этом установка бесплатного сервера мониторинга zabbix окончена. Можно приступать к настройке.
Настройка Zabbix Server
Создание учетной записи и смена пароля
Первое, что нужно сделать — сменить стандартные учетные данные для входа. Можно просто поменять пароль пользователя admin, но лучше создать новую учетную запись с правами суперпользователя, а админа удалить. Для этого идем в раздел Administration -> Users и нажимаем Create User .
Заполняем все необходимые поля. Можно выбрать русский язык. Обычно я стараюсь работать в английском, но в случае с заббиксом можно сделать исключение. Он очень качественно локализован и проблем не возникает. Не забудьте зайти во вкладку Permissions и выбрать User type — Zabbix Super Admin.
Теперь можно зайти под новым пользователем, а Admin удалить. Но система не даст его удалить, так как он является владельцем некоторых объектов:
- карты сети — Local Network
- комплексного экрана Zabbix server
- панелей Global view и Zabbix server health
Они создаются автоматически при установке заббикса. Вам нужно сменить у них владельца на нового пользователя. После этого стандартного админа можно будет удалить.
Настройка email оповещений
Дальше нужно настроить очень важную часть системы мониторинга — уведомления на email. Без нее система мониторинга не выглядит целостной и полноценной. Zabbix сервер поддерживает отправку почты через сторонние smtp серверы. Настроим один из них. Для этого идем в раздел Администрирование -> Способы оповещений и нажимаем на Email .
Покажу на примере настроек ящика в Яндексе.
Это мы настроили адрес отправки. Теперь нужно пользователю добавить адрес для получения оповещений. Для этого идем в Администрирование -> Пользователи , выбираем своего пользователя. Идем во вкладку Оповещения и жмем Добавить . Добавляйте свой ящик и нажимайте Обновить .
Зайдите еще раз в учетную запись и убедитесь, что ящик добавили.
Все, отправку уведомлений мы настроили, осталось подождать срабатывания триггера, чтобы проверить. Сделаем это позже, когда подключим хост к мониторингу.
Я вношу следующие изменения. Меняю шаблон темы письма при проблеме и восстановлении. В стандартном шаблоне в теме письма нет информации об имени хоста. В некоторых шаблонах триггера указано имя хоста, но есть и такие, где нет этой информации. В итоге в оповещении сразу не видно, о каком хосте идет речь. В моем же шаблоне сразу в теме будет указано имя хоста далее статус, а потом все остальное. Вот пример старого и нового оповещения:
Мне мой вид кажется более наглядным. Шаблон меняет на следующий:
{HOST.NAME} - {TRIGGER.STATUS}: {TRIGGER.NAME}
Он одинаковый и для проблемы, и для восстановления.
Изменение стандартных шаблонов мониторинга
На своих серверах мониторинга я изменяю некоторые параметры стандартных шаблонов, чтобы было меньше бесполезных и неинформативных срабатываний. Вот список того, что я делаю.
- В шаблоне Template App Zabbix Agent отключаю триггер Version of zabbix_agent(d) was changed on {HOST.NAME} . Если его оставить, то после каждого обновления zabbix агента вы будете получать уведомление. Лично мне эта информация не нужна.
- В шаблоне Template OS Linux меняю в триггере Disk I/O is overloaded on {HOST.NAME} значение со стандартных 20% до 50%. Я считаю, что начинать беспокоиться и смотреть на машину надо при этом значении. Но вы можете подобрать под свои нужды.
- В этом же шаблоне в правиле обнаружения Mounted filesystem discovery добавляю еще один прототип триггера, скопировав Free disk space is less than 20% on volume {#FSNAME} . Новый шаблон полностью идентичен скопированному, только вместо 20% указываю 5% и ставлю важность с «Предупреждение» на «Высокая». Я добавляю еще одно оповещение, если свободного места на дисках остается меньше 5%. Стандартные 20% очень высокий порог, особенно если большой диск. Оперативное решение проблемы не требуется. Из-за этого часто откладываешь чистку диска на потом и забываешь о ней. Теперь будет еще один страховочный триггер, после которого точно надо идти и прямо сейчас разбираться с местом. В триггере на 20% свободного места ставлю разрешение на закрытие триггера вручную.
- В этом же шаблоне в триггере Lack of free swap space on {HOST.NAME} меняю порог срабатывания с 50% до 20%, либо вообще отключаю его. Сейчас много серверов работают без swap. Хотя лично я всегда его создаю и подключаю.
- В шаблоне Template OS Windows отключаю Правило обнаружения Windows service discovery . В дефолтном варианте оно генерирует очень много ненужных итемов и оповещений. Если нужен мониторинг какой-то службы windows, я делаю для этого отдельный шаблон.
Общие настройки
В общих настройках zabbix server, которые располагаются в разделе Администрирование -> Общие я меняю следующие параметры:
- В разделе Рабочее время выставляю актуальные рабочие часы.
- В разделе Опции отображения триггеров меняю значения Отображать триггеры в состоянии ОК в течении и Мигание триггеров при изменении состояния на 1 минуту. Это просто мои предпочтения. Мне не нравится, когда триггеры долго мигают, либо висят уже закрытые.
- В разделе Прочее меняю Обновление неподдерживаемых элементов данных на 1 минуту. Это актуально во время отладки новых шаблонов.
Установка Zabbix Agent на Linux
Если вы хотите установить zabbix-agent на сам сервер мониторинга, то ничего делать не надо, кроме самой установки. Для других систем необходимо подключить репозитории заббикса, которые мы использовали во время установки сервера. Можете посмотреть их в соответствующих разделах для своей системы.
Установка zabbix agent в Centos:
# yum install zabbix-agent
Тоже самое в Ubuntu/Debian:
# apt install zabbix-agent
Для работы с сервером, который установлен локально на этой же машине, больше никаких настроек не надо делать. Если же вы будете устанавливать zabbix agent на другую машину, то в файле конфигурации агента /etc/zabbix/zabbix_agentd.conf нужно будет задать следующие параметры:
# mcedit /etc/zabbix/zabbix_agentd.conf Server=192.168.13.117 ServerActive=192.168.13.117 Hostname=srv10 # имя вашего узла мониторинга, которое будет указано на сервере zabbix, Zabbix server если это сам сервер заббикса
Запускаем агент и добавляем в автозагрузку:
# systemctl start zabbix-agent # systemctl enable zabbix-agent
Проверяем лог файл.
# cat /var/log/zabbix/zabbix_agentd.log 14154:20181004:201307.800 Starting Zabbix Agent . Zabbix 4.0.0 (revision 85308). 14154:20181004:201307.800 **** Enabled features **** 14154:20181004:201307.800 IPv6 support: YES 14154:20181004:201307.800 TLS support: YES 14154:20181004:201307.800 ************************** 14154:20181004:201307.800 using configuration file: /etc/zabbix/zabbix_agentd.conf 14154:20181004:201307.800 agent #0 started 14157:20181004:201307.801 agent #3 started 14159:20181004:201307.802 agent #5 started 14155:20181004:201307.804 agent #1 started 14158:20181004:201307.806 agent #4 started 14156:20181004:201307.810 agent #2 started
Все в порядке. Идем в веб интерфейс и проверяем поступление данных. Для этого идем в раздел Мониторинг -> Последние данные . Указываем в разделе Узлы сети Zabbix Server и ждем поступления первых данных. Они должны пойти через 2-3 минуты после запуска агента.
Теперь попробуем остановить агент и проверить, придет ли уведомление на почту. Идем в консоль и выключаем агента:
# systemctl stop zabbix-agent
Ждем минимум 5 минут. Именно такой интервал указан по-умолчанию для срабатывания триггера на недоступность агента. После этого проверяем главную панель, виджет Проблемы .
Небольшая статья-инструкция, посвященная тому, как сделать первоначальную настройку мониторинга Zabbix. Итак: Заходим. Пользователь и пароль по умолчанию Admin zabbix. Настраиваем Email уведомления, в меню “Administration -> Media types -> Email” Указываем настройки подключения к Вашему почтовому серверу и адрес отправки, в меню “Administration -> Users -> Admin -> Media” добавляем адреса получателей, галочками отмечаем типы…
Установка Zabbix на Centos 7 - инструкция самостоятельной установки
Приступаем к установке Centos 7 Скачиваем последний образ Centos. Готовим для него железо или виртуальную среду в соответствии с требованиями. Окно “INSTALLATION SUMMARY” Не забываем выставить свой часовой пояс в “DATE & TIME”, добавить раскладку в “KEYBOARD”, зайти в “INSTALLATION DESTINATION” и выбрать диск, выбрать тип установки в “SOFTWARE SELECTION”. Многие ресурсы рекомендуют выставить “MINIMAL…
Безвозвратное удаление данных
Просто отформатировать носитель и затем выбросить его неэффективно - информация может быть восстановлена с помощью специального ПО. Безвозвратное удаление данных выполняется несколькими методами, о которых мы расскажем в данной статье
Защита информации в 1С
Услуги обеспечения защиты и информационной безопасности баз данных и модулей 1С:Предприятие 7.7 и 8, настройка защиты сервера 1С. Защита информации в 1С от сбоев, взлома, копирования на программном и аппаратном уровнях для обеспечения отказоустойчивости бизнеса
Настройка разграничения прав доступа на сервере
Услуги по настройке файлового сервера с разграничением прав доступа. Разграничение прав доступа пользователей обеспечит более высокий уровень защиты вашей конфиденциальной информации и закроет некоторые потенциальные уязвимости в корпоративной сети.
Прямой обмен по технологии directbank 1С
Прямой обмен с банками по технологии DirectBank для тех, кто хочет работать с банковскими документами ещё быстрее, комфортнее и безопаснее. Все происходит в привычном интерфейсе 1С, все действия в одном-единственном окне – не придется тратить время и силы на обучение, можно сразу же приступать к работе.
Внедрение 1С: ERP (Управление предприятием)
Установка и настройка 1С:УТ редакций 11.2, 10.3, доработка конфигурации под задачи пользователей, создание собственных форм отчетов и другие работы по внедрению данной системы в рамках проектов по автоматизации 1С
Обновление 1С нетиповых конфигураций
Услуги обновления 1С для организаций. Апдейт различных платформ, версий, типовых и нетиповых конфигураций. Обновление 1С – именно та услуга, которая позволяет избегать ошибок и неисправности эксплуатации программного комплекса “1 С”.