Zabbix
Компания
45,57
рейтинг
12 сентября 2013 в 13:47

Разное → Масштабируя Zabbix перевод

Zabbix logoТех, кто использует или собирается использовать Zabbix в промышленных масштабах, всегда волновал вопрос: сколько реально данных сможет Заббикс «переварить» перед тем как окончательно поперхнется и подавится? Часть моей недавней работы как раз касалось этого вопроса. Дело в том, что у меня есть огромная сеть, насчитывающая более 32000 узлов, и которая потенциально может полностью мониториться Заббиксом в будущем. На форуме давно идут обсуждения о том, как оптимизировать Zabbix для работы в больших масштабах, но, к сожалению, мне так и не удалось найти законченное решение.

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

image

Для начала хочется обговорить, что реально означает пункт «Required server performance, new values per second (далее NVPS) (Требуемое быстродействие в секунду)». Так вот, он не соответствует тому, сколько реально данных попадает в систему в секунду, а является простым математических подсчетом всех активных элементов данных с учетом интервалов опроса. И тогда получается, что Zabbix-trapper в расчете не участвует. В нашей сети trapper использовался достаточно активно, так что давайте посмотрим, сколько реально NVPS в рассматриваемом окружении:

image

Как показано на графике, в среднем Zabbix обрабатывает около 9260 запросов в секунду. Кроме того, в сети бывали и короткие всплески до 15000 NVPS, с которыми сервер без проблем справился. Честно говоря, это здорово!

Архитектура


Первое, в чем стоит разобраться это архитектура системы мониторинга. Должен ли Zabbix быть отказоустойчивым? Будут ли иметь значение один-два часа простоя? Какие последствия ждут, если упадет база данных? Какие потребуются диски для базы, и какой настраивать RAID? Какая нужна пропускная способность между Zabbix-сервером и Zabbix-proxy? Какая максимальная задержка? Как собирать данные? Опрашивать сеть (пассивный мониторинг) или слушать сеть (активный мониторинг)?

Давайте рассмотрим каждый вопрос детально. Если быть честным, то вопрос сети я не рассматривал при разворачивании системы, что привело к проблемам, которые в дальнейшем было трудно продиагностировать. Итак, вот общая схема архитектуры системы мониторинга:

image

Железо


Точно подобрать правильное железо процесс не из легких. Главное что я здесь сделал, это использовал 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. К сожалению, инструкция была изменена с момента, как я ее использовал, однако конечный результат должен получиться таким же. После базовой настройки дополнительно я настроил:

  1. Общий IP-адрес (shared IP address)
    1. В случае фейловера, IP-адрес переходит на сервер, который становится активным
    2. Так как общий IP-адрес всегда используется активным Zabbix-сервером, то отсюда следует три преимущества:
      • Всегда легко найти какой сервер активен
      • Все соединения от Zabbix сервера всегда с одного и того же IP (После установки параметра SourceIP= в zabbix_server.conf)
      • Всем Zabbix-прокси и Zabbix-агентам в качестве сервера просто указывается общий IP

  2. Процесс zabbix_server
    • в случае фейловера zabbix_server будет остановлен на старом сервере и запущен на новом

  3. Symlink для заданий cron
    1. Симлинк указывает на директорию, в которой лежат задания, которые должны выполняться только на активном Zabbix-сервере. Crontab должен иметь доступ ко всем задания через этот симлинк
    2. В случае фейловера симлинк удаляется на старом сервере и создается на новом
  4. crond
    • В случае фейловера crond останавливается на старом сервере и запускается на новом активном сервере

Пример конфигурационного файла, а также LSB init-скрипт для zabbix-сервера можно скачать здесь. Не забудьте отредактировать параметры, заключенные в "< >". Кроме того, init-скрипт написан с учетом того, что все файлы Zabbix'а находятся в одной папке (/usr/local/zabbix). Так что поправьте пути в скрипте, если нужно.

Отказоустойчивость СУБД


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

Я также использовал Linux HA с Pacemaker и CMAN и для базы данных. Как оказалось, в нем есть пару отличный возможностей для управления репликацией MySQL. Я использую (использовал, смотри раздел «открытые проблемы») репликацию для синхронизации данных между активным(master) и резервным(slave) MySQL. Для начала, точно также как и для серверов Zabbix-сервера, мы делаем базовую настройку кластера. Затем в дополнении я настроил:

  1. Общий IP-адрес (shared IP address)
    1. В случае фейловера, IP-адрес переходит на сервер, который становится активным
    2. Так как общий IP-адрес всегда используется активным Zabbix-сервером, то отсюда следует два преимущества:
      • Всегда легко найти, какой сервер активен
      • В случае фейловера, на самом Zabbix-сервере не требуется никаких действий, чтобы указать адрес нового активного сервера MySQL

  2. Общий дополнительный (slave) IP-адрес
    1. Этот IP-адрес может использоваться, когда к происходит запрос на чтение к базе. Таким образом, запрос может обработать slave-сервер MySQL, если он доступен
    2. дополнительный адрес может быть у любого из серверов, это зависит от следующего:
      • если slave-сервер доступен, и часы не отстают на более чем 60 секунд, то адрес будет у него
      • В обратном случае адрес будет у master-сервера MySQL
  3. mysqld
    • В случае фейловера новый сервер MySQL станет активным. Если после этого старый сервер вернется в строй, то он останется slave для уже новоиспечённого master.

Пример конфигурационного файла можно взять здесь. Не забудьте отредактировать параметры pacemaker, заключенные в "< >". Также, возможно, потребуется скачать другого MySQL resource agent для использования с pacemaker. Ссылку можно найти в документации по установке MySQL кластера с pacemaker в Percona репозитории github. Также на всякий «пожарный случай» копия лежит тут.

Zabbix-прокси


Если по какой-то причине вы не слышали о Zabbix-прокси, то, пожалуйста, срочно посмотрите в документации. Прокси позволяют Заббиксу распределить нагрузку мониторинга на несколько машин. После этого уже каждый Заббикс прокси отсылает все собранные данные на Заббикс сервер.

Работая с Заббикс прокси важно помнить:

  1. Заббикс прокси способны обрабатывать очень серьезные объемы данных, если их настроить как следует. Так, например, во время тестов, прокси (назовем ее Proxy А) обрабатывала 1500-1750 NVPS без каких либо проблем. И это виртуалка с двумя виртуальными ЦПУ, 4ГБ ОЗУ и БД SQLite3. При этом прокси находилась на одной площадки с самим сервером, так что задержки на сети можно было просто не учитывать. Также почти все, что собиралась, было активными элементами данных Заббикс агента
  2. Ранее я уже упоминал, как важна задержка на сети при мониторинге. Так вот, это действительно так, когда речь идет о крупных системах. Фактически, количество данных, которое может отослать прокси, не отставая, напрямую зависит от сети.

    На графике ниже хорошо видно как накапливаются проблемы, когда задержка сети не учитывается. Прокси, который не успевает:

image

Пожалуй, достаточно очевидно, что очередь из данных для передачи не должна увеличиваться. График относится к другому Заббикс-прокси (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.

На графике показано количество запросов в секунду в базе:
image

Обратите внимание, что больше всего запросов «Com_update». Причина кроется в том, что каждое полученное значение влечет Update в таблицу «items». Также в базе данных в основном операции на запись, так что MySQL query cache никак не поможет. По сути, он может быть даже вредным для производительности, учитывая, что постоянно придется маркировать запросы как неверные.

Другой проблемой для производительности может стать Zabbix Housekeeper. В больших сетях его настоятельно рекомендую отключать. Для этого в конфиг-файле выставите DisableHousekeeping=1. Понятно, что без Housekeeping старые данные(элементы данных, события, действия) не будут удаляться из базы. Тогда удаление можно организовать через partitioning.

Однако, одно из ограничений MySQL 5.6.12 в том, что partitioning не может быть использован в таблицах с foreign keys и как раз они присутствуют почти повсеместно в базе Заббикс. Но кроме таблиц history, которые нам и нужны. Partitioning дает нам два преимущества:

  1. Все исторические данные таблицы разбитые по днем/неделям/месяцам/и т.д. могут находиться в отдельных файлах, что позволяет в дальнейшем удалять данные без каких либо последствий для базы. Также очень просто понимать сколько данных собирается за определенный период времени.
  2. После очистки таблиц InnoDB не возвращает место диску, оставляя его себе для новых данных. В итоге с InnoDB невозможно очистить место на диске. В случае с partitioning это не проблема, место может быть освобождено, простым удалением старых партиций.

О 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 и проблема не повторялась. Остальные «неровности» графиков совпадают со временем проведения нагрузочного тестирования. В целом, из графиков видно, что у используемого железа большой запас прочности.

image
image
image
image
image
image

А вот графики с сервера базы данных. Приросты трафика каждый день соответствуют времени снятия дампа(mysqldump). Также провал 16 июля на графике запросов(qps) относится к той же проблеме, что я описывал выше.

image
image
image
image
image

Управление


Итого в системе используется 2 сервера под Zabbix-сервера, 2 сервера под MySQL, 16 виртуальных серверов под Zabbix-прокси и тысячи наблюдаемых серверов с Zabbix-агентами. При таком количестве хостов о внесении изменений руками не могло быть и речи. И решением стал Git-репозиторий, к которому имеют доступ все сервера, и где я расположил все конфигурационные файлы, скрипты, и все остальное, что нужно распространять. Далее, я написал скрипт, который вызывается через UserParameter в агенте. После запуска скрипта сервер подключается к Git-репозиторию, скачивает все необходимые файлы и обновления и затем перезагружает Zabbix-агента/прокси/сервера, если конфиг-файлы имели изменения. Обновление стало не сложнее, чем запустить zabbix_get!

Создание новых узлов сети вручную через веб-интерфейс тоже не наш метод, при таком количестве серверов. В нашей компании есть CMDB, которая содержит информацию о всех серверах и сервисах, которые они предоставляет. Поэтому другой волшебный скрипт каждый час собирает информацию из CMDB и сравнивает с тем, что есть в Zabbix. На выводах этого сравнения скрипт удаляет/добавляет/включает/выключает хосты, создает хост группы, добавляет хостам шаблоны. Все что остается делать вручную в таком случае это имплементация нового типа триггера или элемента данных. К сожалению, скрипты эти сильно завязаны на наши системы, поэтому я не могу ими поделиться.

Открытые проблемы


Несмотря на все усилия, которые я приложил, осталась одна существенная проблема, которую мне только предстоит решить. Речь о том, что когда система достигает 8000-9000NVPS, то резервная база MySQL больше не успевает за основной, таким образом никакой отказоустойчивости на самом деле и нет.

У меня есть идеи, как данную проблему можно решить, но еще не было времени это имплементировать:

  • Использовать Linux-HA с DRBD для partitioning БД.
  • LUN-репликация на SAN с репликацией на другой LUN
  • Percona XtraDB cluster. В версии 5.6 еще недоступен, так что с этим придется подождать( как я писал, были проблемы с производительностью в MySQL 5.5)

Ссылки


Автор: @alexvl Corey Shaw
Zabbix
рейтинг 45,57
Компания прекратила активность на сайте

Комментарии (39)

  • +1
    Хочу отметить, что мы ожидаем значительный (от 2-3х, осторожная оценка) прирост производительности в следующей версии Zabbix 2.2, которая пока существует только в виде альфы, но готова для предварительного тестирования. Насколько большой — покажет время и реальные цифры от пользователей и клиентов.
    • 0
      У нас на этой версии большие проблемы с postgres и latest data, она не работает ))
      • +1
        Это ведь пока ещё альфа, работаем над ошибками.
      • 0
        На zabbix conference 2013 было большое сравнение производительности mysql и postgresql для работы с zabbix'ом от консультанта по постгресу. Почитайте, мб перейдёте на mysql, и проблема пропадёт
        www.zabbix.com/img/zabconf2013/presentations/Which_Database_is_Better_for_Zabbix.pdf
  • 0
    Zabbix I/O действительно кушает многовато. В AWS на бесплатном микроинстансе кушает помимо бесплатных I/O еще доллара на 2-3 в месяц, при этом мониторит только 3 VDS с стандартными тэмплейтами и раз в 5 минут. Примерно столько-же кушали 5 небольших инет-магазина.
    • 0
      Zabbix I/O складывается из двух основных величин: запись собранной информации и апдейты некоторых таблиц при получении данных. Понятно, что записи исторической информации на диск никак не избежать, но в Zabbix 2.2 мы практически полностью избавились от апдейтов, их не будет. Это позволит сэкономить как минимум половину I/O.
    • +2
      Главное, я думаю, правильно настраивать время хранения raw данных в zabbix, хранить 7-14 дней их в базе, все остально агрегированные значения, про это многие забывают и база из-за индексов разрастается и тормозит на запись. Хорошая производительность заббикса вполне достижима.
  • 0
    Читал эту статью в блоге заббикса, тоже была идея перевести ее. У вас все равно лучше получилось :)
    Тем не менее мои 70 значений в секунду кажутся жалкими на фоне описываемой конфигурации. Еще интересно на сколько большой запас получается. То есть если zabbix_server даже на короткое время остановится, после запуска клиенты начнут засыпать сервер значениями, на сколько, интересно, быстро они будут разобранными?
    • 0
      Статью перевёл wabbit, все плюсы ему. Если сервер остановится на короткое время, то никаких проблем не возникнет. Да, клиенты начнут засыпать сервер значениями, но внутри Заббикса есть буферизация. Новые данные попадут в буфер который будет разгребаться воркерами. Это упрощённая картина.

      В случае длительных остановок картина уже не настолько радужная, могут пройти десятки минут или даже часы пока прокси не отправит все накопленные данные на сервер. А таких данных для высоконагруженного прокси может быть очень много — сотни миллионов записей.
  • +1
    После прочтения таких статей освежается понимание, какое все-таки огромное число слоев абстракции и кода лежит между прикладным уровнем и железом. Казалось бы, 10000 серверов. Не так и много — при том, что производительность процессоров исчисляется миллиардами операций в секунду, памяти — гигабайтами в секунду, дисков — сотнями мегабайт в секунду, сети — гигабитами, а объем оперативной памяти — сотнями гигабайт. Да на экране в разрешении 1024x769 около миллиона точек, а любая 3d-игра сменяет весь этот массив по 60 раз в секунду! Ан нет, нужно 4 машины, чтобы только мониторить эти 10000 серверов. Причем заббикс еще хорошо оптимизирован…
  • 0
    Так вы все таки без Housekeeper работаете?
    • 0
      Отвечу за Corey Shaw. Да, он работает без housekeeper, что фактически является де-факто стандартом по установке Заббикса для мониторинга большой (более 5000 устройств или более 2000 NVPS) инфраструктуры.
      • 0
        Упустил, что автора нельзя спросить:) Алексей, правильно ли я понимаю, что в Z 2.2. вы переработаете схему базы, и будет возможно работать с партицированием?
        • 0
          Нет, партиционирования из коробки пока не будет. Мы надеемся на поддержку модулей для хранения истории в альтернативных хранилищах, например, Cassandra, MongoDB и т.д. Основным преимуществом будет другой уровень производительности, горизонтальное масштабирование и HA.
          • 0
            Переработка архитектуры, интересненько. Тогда ждем с нетерпением новой версии, и новых фич.
  • +2
    Статья называется «Масштабируя Zabbix», но в результате мы получили отказоустойчивое, но не масштабируемое решение. Здесь узкое место — сам zabbix_server и база данных, которые никак не масштабируются.

    В сети есть презентация на highload от яндекса, где они тотально решили эту проблему. Было бы замечательно, если бы они поделились техническими подробностями своего решения.
    • –4
      Мне кажется, что мониторинг не является критически важным сервисом, от которого зависит работа бизнеса. Не думаю что имеет смысл тратить тонну усилий и средств чтобы делать HA.

      К тому же я вижу, что основной упор в статье делается на мускул, как критичную точку. А репликация MySQL в свою очередь — асинхронна, поэтому в данном контексте эту проблему никак не решить.
      • +1
        > мониторинг не является критически важным сервисом, от которого зависит работа бизнеса

        Зависит от бизнеса.
  • 0
    700.000 элементов. Прекрасная работа.
    Неужели такие расширенные шаблоны действительно необходимы. Возможно, чуть сложности можно было поубавить если подкорректировать шаблоны.

    Более хорошее решение предложила моя жена: сначала обновиться MySQL до 5.6 и потом разбираться.
    Вам очень повезло.
  • –1
    После очистки таблиц InnoDB не возвращает место диску, оставляя его себе для новых данных.

    innodb_file_per_table спасет отца русской демократии. А вообще в свое время я решил проблему производительности zabbix весьма радикально. Я сменил MySQL на PostgreSQL и забыл про проблемы с MySQL.
    • +1
      Зато появились новые проблемы.
      — надо как-то партиционировать
      — вакуум
      — жрет ресурсов просто тонну
      — репликация, если масштабировать
      В новой версии, которая альфа, есть специфические для postgres проблемы, которые надо решать, иначе все со скрипом работает. Например тот же раздел latest data.
      Наоборот думаем, обратно на mysql переезжать ))
      • –2
        — надо как-то партиционировать

        Breaking news! Партицирование в PostgreSQL есть.

        — вакуум

        Автоваакуум ваш друг и он уже в поставке начиная с 9 версии.

        — жрет ресурсов просто тонну

        Это вам кто рассказал? Я вообще на ту же самую машину ставил. Я вот сколько времени работаю с СУБД MySQL и СУБД PostgreSQL могу сказать, что PostgreSQL работает лучше.

        — репликация, если масштабировать

        Из коробки. В PostgreSQL 9.3 добавили штатную процедуру remastering.

        В новой версии, которая альфа, есть специфические для postgres проблемы, которые надо решать, иначе все со скрипом работает.

        Это у товарищей из Zabbix есть специфичные проблемы с руками. Знаете когда для того чтобы сменить СУБД для работы надо пересобрать софт потому что используется определяется #define в коде, я начинаю подозревать, что тут что-то не так. Про код я вообще молчу. Я пару раз заглядывал для исправления в код как сервера, так и веб-интерфейса и как-то у меня это вызвало когнитивный дисонанс. Хотя при всем этом zabbix весьма хорош как мониторинг.
        • 0
          Вы не думайте, что я тут холиварю, но мне postgres хочется сменить уже довольно давно.

          Партиционировать что-то как-то и эффективно партиционировать — это разные же вещи. Поэтому я и написал «как-то». Конкретно для zabbix надо еще заморочиться, что там распартиционировать, чтобы не тормозило.

          Автовакуум не работает. Точнее он неэффективен. Все плавно поттупляет и постепенно идет полная деградация.

          Из коробки что? master-slave репликация? Она не очень тут помогает, у нас 99% времени идет запись. Я вообще не очень доволен такой репликацией, когда по сети гоняются несжатые бинарники в просто диких количествах. Валы не долетели: синхронная репликация — клиент пятисотит, асинхронная — жестко жрется память и 30% снижение производительности БД. 9.3 тут вроде получше, да, но он только на днях релизнулся.

          Про define не скажу ничего, у нас два разных пакета. zabbix-psql, zabbix-mysql, нет таких проблем ))

          Ну а ресурсы — тут все у всех по разному.
          • 0
            Партиционировать что-то как-то и эффективно партиционировать — это разные же вещи. Поэтому я и написал «как-то». Конкретно для zabbix надо еще заморочиться, что там распартиционировать, чтобы не тормозило.

            Условия партицирования точно такие же как и в MySQL. Да более заморочно, но работает проверенно.

            Автовакуум не работает. Точнее он неэффективен. Все плавно поттупляет и постепенно идет полная деградация.

            Дурацкий конечно вопрос, но вы его настраивали?

            Из коробки что? master-slave репликация? Она не очень тут помогает, у нас 99% времени идет запись. Я вообще не очень доволен такой репликацией, когда по сети гоняются несжатые бинарники в просто диких количествах.

            Можно подумать в MySQL лучше.

            Про define не скажу ничего, у нас два разных пакета. zabbix-psql, zabbix-mysql, нет таких проблем ))

            Вот по этому и разные.

            Ну а ресурсы — тут все у всех по разному.

            В случае PostgreSQL надо подтюнить. А то большую часть времени когда я сталкиваюсь PostgreSQL говно, а вот MySQL да! Люди банально не тюнили PostgreSQL под свою машину и запускали с параметрами по умолчанию. А потом такие удивляются а чего он так процессор и диск жрет.
            • 0
              Ну конечно мы все настраивали и не по разу. Вот именно, что все более заморочено.

              Репликация в postgres просто отвратная. Я уже молчу, что появилась она не так давно. И не решает почти никаких проблем с определенного профиля нагрузки, только добавляет. Galera cluster -> xtrabackup — работает не в пример отлично и настроить проще.

              Postgresql у нас в проектах жив только потому, что там все просто прекрасно с geo, а мы такое используем очень интенсивно.
              В остальном — mysql проще и лучше, особенно от percona.

              Я про говно, кстати, не говорил. БД как БД. Со своими плюсами и минусами. Не панацея только ни разу. Мускуль такой же ))
              • 0
                Ну конечно мы все настраивали и не по разу. Вот именно, что все более заморочено.

                Весьма интересно так-как я наблюдал строго противоположную ситуацию. Хотя у вас вообще случаем БД не характеризуются следующими факторами
                1. Небольшое количество таблиц
                2. Большое количество данных в таблицах
                3. Простые запросы.

                Galera cluster -> xtrabackup — работает не в пример отлично и настроить проще.

                Галера это другой коленкор. Стандартный же бекап аналогичен тому что в PostgreSQL такой же log shipping

                В остальном — mysql проще и лучше, особенно от percona.

                Ну не знаю. У меня видимо запросы к СУБД другие и при них MySQL ведет себя отвратно. Про то как там сделаны триггеры и процедуры я вообще молчу.
                • 0
                  В постгресе репликация субъективно и правда захлебывается раньше, чем в mysql (пока). Но у постгресовой репликации есть одно неоспоримое достоинство: она никогда, ни при каких обстоятельствах не ломается, что бы ни происходило с машиной. А вот с mysql везде, где мне приходилось сталкиваться с репликацией, она раз или два в год слетала (то после сбоя по питанию, хотя опция синка стояла двоечка, то просто после резкого наплыва конкурентных запросов на запись). Может, не везло просто, не знаю, но когда на каждый сбой репликации удается найти в их багтрекере релевантный баг, это не очень приятно…
                  • 0
                    Да есть такое. И еще что хуже, починить ее без LVM snapshot весьма непросто. В случае же PostgreSQL починить с нуля весьма просто.
                  • 0
                    Ломается еще как. Все от количества данных зависит. Постоянно наблюдаю ситуацию, когда количество апдейтов таково, что сеть не успевает прососать все нагенеренные wal. Async реплики медленно уезжают в рекавери и начинают адски тормозить на простейших селектах.

                    А если в этот момент прилетит еще и битый wal, то реплику надо переподнимать с нуля. В геокластере, например, это — большая проблема. Ну и пока восстанавливаешь один slave, запросто можно потерять и все остальные ))

                    Блин почему они не сжимают бинарь, перед тем, как отправить его в сеть.
                    • 0
                      Ну сжать вы можете при помощи того же ipsec и прочих 100500 методов.
                      • 0
                        Есть несколько путей, да. Но то, что это все жесткие костыли — это факт )) Думаю вообще код хакнуть, там несложно вроде впилить сжатие ))

                        Только не могу найти в интернетиках, чем чревато и кто так уже делал.
                        • 0
                          Ну чревато дополнительной нагрузкой на CPU плюс появится дополнительная задержка.
  • –2
    Круто!

    Кто помнит какие обновления были у Adobe 16 июля, так как тов. Corey Shaw вроде там сисадмин?
    • 0
      Блин, очередной раз не понимаю аудиторию.
      За что заминусовали, на графики кто-нибудь смотрел?
  • +1
    Интересно. 9000 новый значений это много. Я со своими 170 с более чем 1000 железок просто скромен. И у меня всего один сервак на котором крутится не только Zabbix но еще и nocproject. Сервак старый HP 360 c 2 проца по 2 ядра, 10 оперативы, три винта в Raid-5. MySQL 5.5 партиционирование.

    Все оборудование мониторится по SNMP.

    Вот так распределяется время разным процессам.


    Очень конечно хочется отдельный сервер под БД, тогда я бы смог поднять детальность мониторинга сети на новый уровень. Сейчас все упирается в производительность и размер БД
    На графике пила отображает работу удаления старых партиций и создание новых

    Учитывая что размер дискового пространства 128 гиг, очень тесно сейчас.

    Процессорного времени достаточно, IOwait я считаю очень низким.


    Ну и всякие разные данные


    Эта система мониторит большое количество оборудования провайдера. Причем детальность мониторинга такая что можно посмотреть данные от 10G интерфейсов Juniper и вплоть до параметров ADSL каждого конкретного абонента (на более менее серьезных DSLAMах).

    Статья очень понравилась, если будет железо под развитие того что я создал, то она станет ориентиром что возможно получить от системы.

    ЗЫ Раньше был MySQL 5.1, потом долго пытался заставить работать Postgresql 8.3 9.0 9.1 и так и не добился с ним нормальной производительности. Место жралось, авто вакуум жрал проц большой совковой лопатой. Партиционирование, там честно говоря не очень. Хотя я может просто не умею его (Postgresql) готовить? После всех мучений вернулся к MySQL 5.1 земля и небо ))) Дальше было 5.5 и партиции. В общем сейчас система живет как часы. Сама находит новое железо, сама его добавляет и т.д.

    • 0
      Как я уже и писал PostgreSQL надо тюнить. Параметры по умолчанию там не очень так же как и в случае MySQL.
      • 0
        Я его тюнил, с параметрами по умолчанию он сразу ложился. Промучился с ним если правильно помню наверно месяц.
        • 0
          На базе какого руководства тюнили?
          • 0
            Сейчас уже не помню.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное