Api слишком медленное

[alp]

Столкнулись с необходимостью проверять наличае десятков тысяч хостов в базе заббикса, но через http-API это происходит слишком долго! На 16 тысяч хостов, около 15 минут!

Есть ли возможность обращаться к АПИ например через локальный интерпретатор php или вообще через другой протокол. Или может быть есть способ не генерить по отдельному обращению на каждый запрос, а делать это по аналогии с БД, когда множество запросов помещается между директивами BEGIN COMMIT и уходят сразу огромной пачкой.

[zalex_ua]

Или может быть есть способ не генерить по отдельному обращению на каждый запрос, а делать это по аналогии с БД, когда множество запросов помещается между директивами begin commit и уходят сразу огромной пачкой.

Можете попробовать работать напрямую с БД, если вам только читать нужно то это вполне подходящий вариант.

[alp]

Первоначальные цифры оказались не совсем верные.
На самом деле, чтобы просто проверить наличае 16 тысяч хостов и в случае отсутствия добавить нужные, необходим целый час!!! Это абсолютно неприемлимо Я не помнимаю нафига нужен API, если всёравно придётся работать напрямую с БД... Неужели никак нельзя обращаться к API в обход http? Если такой возможности нет, то придётся писать фичреквест.

[gdgsoft]

А Вы попробуйте без АПИ создать напрямую в БД:
1) элемент;
2) повесьте на него 100 триггеров;
3) по комбинации элементов создайте графики.

А потом умножте это все на 100 хотя бы

Если Вам нужно только сканировать сеть и добавить новые хосты, то почему бы не использовать дискавери?

Без http-PHP похоже не обойтись По крайней мере без http так точно. Одна из основных проблем, которая меня мучает в данном вопросе это то, что каждое обращение с помощью API приводит к логированию данного обращения в БД. В результате, таблица, вроде sessions, заполняется очень активно и сейчас у меня занимает больше 2.5Гиг. Я достаточно активно стараюсь использовать АПИ в своих скриптах, потому что это позволяет мне реализовать тот алгоритм мониторинга, который меня устраивает

По поводу заполнения таблицы, я открывал ZBXNEXT, но не знаю, будет ли по нему что то сделано или нет.

Попробуйте поставить на сервер шаблон, который мониторит состояние пулеров/буферов сервера, может какой то из них забит на 100% и стоит увеличить его размер. ИМХО, могу ошибаться.

[zalex_ua]

Одна из основных проблем, которая меня мучает в данном вопросе это то, что каждое обращение с помощью API приводит к логированию данного обращения в БД. В результате, таблица, вроде sessions, заполняется очень активно и сейчас у меня занимает больше 2.5Гиг. Я достаточно активно стараюсь использовать АПИ в своих скриптах, потому что это позволяет мне реализовать тот алгоритм мониторинга, который меня устраивает

Будьте точны. Вот тикеты:

https://support.zabbix.com/browse/ZBX-4937

https://support.zabbix.com/browse/ZBX-4842

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

По поводу заполнения таблицы, я открывал ZBXNEXT, но не знаю, будет ли по нему что то сделано или нет.

Какой? Я не помню связанных тикетов ZBXNEXT.

[gdgsoft]

"Логируются не обращения а к API а каждый вход..."
- Ну это я и имел ввиду


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

- Раскажите плиз по подробней. Я не очень в этих вопросах
Могу ли я могу "ЭТО" получить из АПИ и как? И как повторно использовать? Подтолкните пожалуйста.

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

Вот то что я описывал:

https://support.zabbix.com/browse/ZBXNEXT-1158

[zalex_ua]

- Раскажите плиз по подробней. Я не очень в этих вопросах
Могу ли я могу "ЭТО" получить из АПИ и как? И как повторно использовать? Подтолкните пожалуйста.

Гм, вот описано http://www.zabbix.com/documentation/1.8/api/user/login
Вот тот токен ("result":"a9a1f569d10d6339f23c4d122a7f5c46") и используйте потом для аутентификации в следующих вызовах апи. Для этого у пользователя, использующегося для АПИ, выключите в свойствах опцию "Auto-logout (min 90 seconds)" и полученный токен не будет устаревать. Сохраняйте его на диске и используйте для последующих вызовов.
Возможно скрипты следует улучшить чтобы предусмотреть проверку и повторный логин если токен по какойто причине все же устарел или уже недействителен.
Кажется недавно zabon был улучшен начал кешировать этот токен, или это стало доступным как опция.

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

А кто будет историю чистить? Если хаускипер отключают то это всегда рассматривается вместе спартишинингом БД.
Никто просто так не рекомендует отключать хаускипер, особенно Zabbix Team.

Вот то что я описывал:
https://support.zabbix.com/browse/ZBXNEXT-1158

Понятно, боюсь что этот тикет будет закрыт с Won't fix учитывая что там написано и что обсуждено здесь.

[gdgsoft]

Спасибо за информацию! Попробую переработать скрипты.

Конечно, ТТ можно закрывать.

[dotneft]

Я бы вам порекомендовал в несколько потоков обрабатывать данные, например.
Получили список хостов в кэш, создали несколько потоков и проверили хосты, если потребуется добавили/удалили новые хосты прям в многопоточном режиме.

Такая реализация используется в продуктиве, так что работоспособность идеи подтверждается, так скажем

[alp]

Да, "если Магомет не идёт к горе", то будем распараллеливать процесс...

[OKyHb]

Сорри за отклонение от темы... Но я правильно понимаю, что таблицу "sessions" можно спокойно чистить вручную? (что-то типа "DELETE FROM sessions WHERE ...")

Housekeeper отключен. Делали партицирование mysql по примеру из wiki, но тогда про эту таблицу не вспоминалось. И сейчас статистика по таблицам выглядит так:

01:06:48 root#zinc[4]/var/lib/mysql/zabbix>ls -lhS | egrep -v "trend|history" | head
total 91G
-rw-rw---- 1 mysql mysql 804M Jul  2 01:10 sessions.ibd
-rw-rw---- 1 mysql mysql 644M Jul  1 10:06 events#P#p2013_06.ibd
-rw-rw---- 1 mysql mysql 272M Jul  2 01:10 items.ibd
-rw-rw---- 1 mysql mysql  84M Jul  2 01:10 graphs.ibd
-rw-rw---- 1 mysql mysql  84M Jul  2 01:10 item_discovery.ibd
-rw-rw---- 1 mysql mysql  80M Jul  2 01:10 graphs_items.ibd
-rw-rw---- 1 mysql mysql  76M Jun 30 23:58 alerts#P#p2013_06.ibd
-rw-rw---- 1 mysql mysql  76M Jul  2 00:58 items_applications.ibd
-rw-rw---- 1 mysql mysql  56M Jul  2 01:10 graph_discovery.ibd

mysql> show table status like 'sessions';
+----------+--------+---------+------------+---------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+
| Name     | Engine | Version | Row_format | Rows    | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         |
+----------+--------+---------+------------+---------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+
| sessions | InnoDB |      10 | Compact    | 3916129 |            119 |   469762048 |               0 |    354418688 |         0 |           NULL | 2013-05-28 11:56:34

Пока не 2.5GB, но на фоне остальных таблиц уже возникает желание почистить.

[zalex_ua]

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

[gdgsoft]

Сорри за отклонение от темы... Но я правильно понимаю, что таблицу "sessions" можно спокойно чистить вручную? (что-то типа "DELETE FROM sessions WHERE ...")

Housekeeper отключен. Делали партицирование mysql по примеру из wiki, но тогда про эту таблицу не вспоминалось. И сейчас статистика по таблицам выглядит так:

01:06:48 root#zinc[4]/var/lib/mysql/zabbix>ls -lhS | egrep -v "trend|history" | head
total 91G
-rw-rw---- 1 mysql mysql 804M Jul  2 01:10 sessions.ibd
-rw-rw---- 1 mysql mysql 644M Jul  1 10:06 events#P#p2013_06.ibd
-rw-rw---- 1 mysql mysql 272M Jul  2 01:10 items.ibd
-rw-rw---- 1 mysql mysql  84M Jul  2 01:10 graphs.ibd
-rw-rw---- 1 mysql mysql  84M Jul  2 01:10 item_discovery.ibd
-rw-rw---- 1 mysql mysql  80M Jul  2 01:10 graphs_items.ibd
-rw-rw---- 1 mysql mysql  76M Jun 30 23:58 alerts#P#p2013_06.ibd
-rw-rw---- 1 mysql mysql  76M Jul  2 00:58 items_applications.ibd
-rw-rw---- 1 mysql mysql  56M Jul  2 01:10 graph_discovery.ibd

mysql> show table status like 'sessions';
+----------+--------+---------+------------+---------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+
| Name     | Engine | Version | Row_format | Rows    | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         |
+----------+--------+---------+------------+---------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+
| sessions | InnoDB |      10 | Compact    | 3916129 |            119 |   469762048 |               0 |    354418688 |         0 |           NULL | 2013-05-28 11:56:34

Пока не 2.5GB, но на фоне остальных таблиц уже возникает желание почистить.

Добрый день.
В свое время, еще на версии 1.8, погрыз все ногти по самые локти касательно хранения сессий.

Возможно я ошибаюсь, но...
Мне кажется, что Вам нужно пересмотреть код своих скриптов (если таковые имеются), которые работают с API. Отсюда и бешенное увеличение этой таблици.

Вот что у меня:
mysql> show table status like 'sessions' \G
*************************** 1. row ***************************
Name: sessions
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 964
Avg_row_length: 118
Data_length: 114688
Max_data_length: 0
Index_length: 81920
Data_free: 0
Auto_increment: NULL
Create_time: 2013-01-04 15:20:02
Update_time: NULL
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:


Я достаточно активно использую API, но при этом у меня файл sessions.ibd занимает 278528.
А общий объем файлов БД Zabbix 121Gb. Партицирование включено.

Уверен, у вас при выполнении любого запроса через API создается новая сессия для пользователя который работает с API.

Вот здесь:

https://www.zabbix.com/documentation/2.0/manual/appendix/api/apiinfo/version

как и в любом другом примере по API есть упоминание о:
"auth": "16a46baf181ef9602e1687f3110abf8a"

Это то что Вам нужно использовать в ваших скриптах. Иначе со временем у Вас API будет всегда начинать тормозить и нужно будет постоянно чистить таблицу.

[OKyHb]

Действительно, стоит пересмотреть скрипты (сейчас биллинг синхронизирует данные по коммутаторам и портам с zabbix'ом. И показывает абонентам графики с их порта).

Пока просто удалили часть старых сессий - "delete from sessions where lastaccess < UNIX_TIMESTAMP()-86400;". Осталось ~7k записей. Это в ~13:00. И загрузка cpu заметно снизилась.





(В 23:00 - наши тех. работы, к sessions отношения не имеют)

[Jimson]

Может глупость скажу, но обессудьте. Когда просматривал код PHP классов обратил внимание что проверка прав производится именно в get(), при этом явным образом проверяется "тип" аккаунта super или обычный юзверь. Если для работы через API сделать супер-админа, по идее должно быть ускорее работы на порядок, ну если я правильно понял код.