Zabbix, мониторинг портов последней мили и оптимизация работы с БД с использованием partitioning

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

Скрин как раз из заббикса.

Вам интересно чтобы на линке отображался тарфик?
Вставьте в название линка или узла сети
DL/UL: {ИМЯ_УЗЛА:ifHCOutOctets.XGigabitEthernet0-1-1.last(0)} / {ИМЯ_УЗЛА:ifHCInOctets.XGigabitEthernet0-1-1.last(0)}
т… е. узел сети- его элемент — тип последнего значения в данном случае последнее занчение можно среднее можно минимум можно максимум, более подробно есть в документации.

Делаете подложку, загружаете ее. Грузите сервера и добавляете необходимые метки для отображения. Никакой магии.

Это холиварная тема, но отвечу — просто опишу плюсы: железки не добавляю руками, все делается автоматом. Шаблоны подцепляются автоматом. Железки по группам распределяются автоматом. Все делается на основе правил которые меняются на лету без перезагрузки. Для изменения любого параметра на всех железках сразу достаточно поменять шаблон. Если нужно поменять этот параметр только на железке меняем на железке шаблон при этом не трогается. Глубина хранения истории, трендов, интервал опроса и прочее меняется на лету без остановок и потерь накопленной информации. Вся информация хранится в БД. Есть удобный API. Высокая производительность на больших количествах итемов. Легкая масштабируемость системы.
Уверен, что то же есть и Nagios, но формат вывода и доступ к сохраненной информации мне более удобен в этой системе. ЗЫ Nagios у нас тоже есть и успешно мониторит состояние сети но не порты конечных абонентов, да я и честно не представляю как удобно реализовать в нем мониторинг хотябы десятка тысяч абонентских портов.

download.yandex.ru/company/experience/rit2008/highload_lapan.pdf
Вот почему. Думаю яндексу вы вполне поверите ага? :)

Ну и да я забыл сказать, профили там есть. Так что никаких проблем. В целом zabbix актуален при большом количестве оборудования с snmp.

Первая оптимизация — использовать отдельный сервер под БД и вот тогда можно настроить и заточить его на максимальную производительность. ;)

Ну RAID10 будет быстрее, но будет меньше места. Опять же при наличии контроллера с RAM это уже не стреляет.

Вот, если есть замечания с удовольствием прислушаюсь.
[client]
default-character-set=utf8
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = -10
[mysqld]
character_set_server=utf8
collation-server=utf8_bin
init_connect="SET NAMES utf8 collate utf8_bin"
user = mysql
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
skip-external-locking
default-storage-engine = innodb
tmp_table_size = 1024M
query_cache_limit = 1M
query_cache_size = 256M
max_heap_table_size = 256M
max_connections = 400
join_buffer_size = 2048K
read_buffer_size = 256k
read_rnd_buffer_size = 256k
thread_cache_size = 4
bind-address = 127.0.0.1
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
myisam-recover = BACKUP
max_connections = 400
table_cache = 512
log_error = /var/log/mysql/error.log
log_slow_queries = /var/log/mysql/mysql-slow.log
log-queries-not-using-indexes
expire_logs_days = 10
max_binlog_size = 100M
innodb_file_per_table
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
default-character-set=utf8
[isamchk]
key_buffer = 16M

innodb_flush_log_at_trx_commit = 2
innodb_file_per_table
innodb_flush_method = O_DIRECT
innodb_log_file_size = 512M
innodb_log_buffer_size = 4M
innodb_buffer_pool_size = 6G
innodb_thread_concurrency =8
/code>

Работает и вполне успешно.
uname -a
Linux monitor 2.6.32-31-server #61-Ubuntu SMP Fri Apr 8 19:44:42 UTC 2011 x86_64 GNU/Linux

Смотреть надо при сборке, может либ каких не хватает.

Проблема есть еще с версии 1.8.4.
>> socket() system call that does not support SOCK_CLOEXEC flag on earlier kernels

По роду деятельности приходится собирать статики агенты. Вот до сих пор агенты 1.8.3 из за этого юзаю.

Официальный мануал достаточно подробный. Переведен на несколько языков.
Discovery вместе с триггерами очень гибкая вещь. Я использую в правиле обнаружения SNMPv2 агент ".1.3.6.1.2.1.1.1.0" который возвращает тип железки который очень часто уникален для одной серии железа.
Дальше пишем действие на обнаружение с использованием «И»
например такое если
Полученное значение содержит "MA5600 V100R011"
Состояние обнаружения = "Up"
Тип сервиса = "SNMPv2 агент"
IP адрес узла сети = "10.хх.ххх.2-30"

ипы/диапазон подставьте свои
то делать следующее
Присоединить шаблон "Template_Huawei_MA5605_system"
Добавить в группу "Huawei MA5605"
Добавить в группу "Группа какого либо района"
Добавить узел сети

для другого типа железки полученное значение будет другое можно написать другое действия исходя из этого.
Используя подобные правила и действия, можно не беспокоится об изменениях в количестве УД, они будут сами добавляться при настройке на них snmp в данном случае. Также можно их и удалять.
У меня например 73 триггера на обнаружение, и я еще не все настроил, что хотел.