O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Zabbix в сервисной компании  ОНЛАНТА - Zabbix Meetup Moscow

19.463 visualizações

Publicada em

Презентация для Zabbix Moscow Meetup, June 27th 2015
http://www.meetup.com/Zabbix-Moscow-Meetup/events/223289028/

Publicada em: Software
  • Seja o primeiro a comentar

Zabbix в сервисной компании  ОНЛАНТА - Zabbix Meetup Moscow

  1. 1. ZABBIX В СЕРВИСНОЙ КОМПАНИИ Нестеров Вадим
  2. 2. …Так кто ж ты, MonOps? — Я - часть той силы, что вечно хочет зла и вечно совершает благо.
  3. 3. • Все само себя 
 не замониторит • Кнопка «сделай мне зашибись» не случится • Monitoring Operations (MonOps) - это РАЗРАБОТКА решения мониторинга 
 под конкретный проект • Мониторинг - это дорого! • Постоянный процесс разработки СПАСИБО, КЭП!
  4. 4. • услуги IT-аутсорсинга • эксплуатация государственных информационных систем федерального значения • облачные услуги OnCloud.ru • в компании нет разработчиков, только системные администраторы КОМПАНИЯ ОНЛАНТА
  5. 5. ZABBIX В ОНЛАНТА • гос проект с посещаемостью 350 000 в сутки • OnCloud - облачный хостинг, 600 ВМ enterprise level
  6. 6. ZABBIX В ОНЛАНТА • гос проект
  7. 7. Мониторинг — непрерывный процесс наблюдения и регистрации параметров объекта, в сравнении с заданными критериями. сбор метрик соответствие
 граничным
 условиям информирование (alerting) 1 2 3 МОНИТОРИНГ
  8. 8. визуализация данных: графики, комплексные экраны
 
 ЭТО АНАЛИТИКА НЕ МОНИТОРИНГ
  9. 9. ИДЕАЛЬНЫЙ МОНИТОРИНГ • 1 метрика - 1 адекватный триггер • если для метрики нет триггера - значит она не 
 нужна в системе мониторинга
  10. 10. SysOps DevOps NOC Бизнес
 SLA ДС DBA Аналитика MonOps ЗАКАЗЧИКИ МОНИТОРИНГА
  11. 11. • Эксперты определяют граничные условия, интервал, и необходимость в оповещении • Zabbix — это всегда +сотрудник ДС, никаких СМС, приятно услышать человека который знает, что точно случилось в 4 утра :) • Делайте удобно для ДС: четкая инструкция в описание триггера, что делать.
 Если можно починить пусть чинят (если это обходное решение), если нет то пусть звонят эксперту • Ссылку на базу знаний • Меньше графиков, больше толковых триггеров. 
 Визуальный мониторинг - быстрый путь к НШС, считайте, что у вас нет мониторинга • Используйте LLD везде - это унификация и если вы играете в квест с разработчиками
  12. 12. • 1 сервер • 2 х 12 -cores Intel Xeon CPU X5675 @ 3.07GHz • 16 GB RAM •   СХД • 1000 - 1200  NVPS • MariaDB 10 +TokuDB + nginx + php-fpm • tokudb_row_format = tokudb_lzma (жмет хорошо, но долго читает) • NO housekeeper + partitioning • ВМ Zabbix Proxy + ODBC Oracle АРХИТЕКТУРА REV.1
  13. 13. • oVirt (KVM) кластер из 3 нод (ручной HA - БД не переедет автоматом) • 1 сервер: 2 x 24 core Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz, 386 GB RAM • 2 сервера: 2 х 12 core Intel Xeon CPU X5675 @ 3.07GHz, 16 GB RAM • VMs: ZDB (64GB), ZABBIX(8 GB), ZMONITOR(8GB) • СХД • 2200  NVPS • history* - 31 день, trends* - 2 года • размер базы: 170 Гб • MariaDB 10 +TokuDB + nginx + php-fpm • tokudb_row_format = tokudb_zlib • ВМ Zabbix Proxy + ODBC Oracle АРХИТЕКТУРА REV.2
  14. 14. • MariaDB 10 +TokuDB 7.5 • write optimized • no locks • row compression: zlib, lzma (6x < InnoDB) • no slave lag • hot backup > 7.5.5 (MariaDB 10.0.20) • clustering indexes ZABBIX BACKEND
  15. 15. my.cnf: datadir=/data/mysql
 tokudb_data_dir=/data/tokudb #удобно
 tmpdir=/ramtmp #для select distinct 
 
 plugin-load = ha_tokudb
 #tokudb_cache_size = # default: 50% RAM
 #tokudb_directio = OFF query_cache_type = 1 # + 5min event: FLUSH QUERY CACHE
 query_cache_size = 32M # + 30min event: RESET QUERY CACHE
 query_cache_limit=32M # #обязательно(!) иначе будут очень долгие select’ы
 optimizer_switch=index_condition_pushdown=off ZABBIX BACKEND
  16. 16. net.ipv4.ip_local_port_range = 10000 65535
 net.ipv4.tcp_fin_timeout = 5
 net.ipv4.tcp_tw_reuse=1
 
 net.netfilter.nf_conntrack_max=1048576
 
 kernel.msgmni = 1024
 kernel.sem = 250 256000 32 1024 sysctl.conf CacheSize= 512M HistoryCacheSize=512M TrendCacheSize=512M HistoryTextCacheSize=512M ValueCacheSize=512M zabbix_server.conf ZABBIX SERVER
  17. 17. php-fpm:
 pm = static
 pm.max_children = 450 nginx + php-fpm + opcache // permission check if ($userType != USER_TYPE_SUPER_ADMIN && !$options['nopermissions']) { $permission = $options['editable'] ? PERM_READ_WRITE : PERM_READ; $userGroups = getUserGroupsByUserId($userid); // check permissions by graph items /* PATCH: TOO LONG GRAPHS QUERIES $sqlParts['where'][] = 'NOT EXISTS ('. 'SELECT NULL'. ' FROM graphs_items gi,items i,hosts_groups hgg'. ' LEFT JOIN rights r'. ' ON r.id=hgg.groupid'. ' AND '.dbConditionInt('r.groupid', $userGroups). ' WHERE g.graphid=gi.graphid'. ' AND gi.itemid=i.itemid'. ' AND i.hostid=hgg.hostid'. ' GROUP BY i.hostid'. ' HAVING MAX(permission)<'.zbx_dbstr($permission). ' OR MIN(permission) IS NULL'. ' OR MIN(permission)='.PERM_DENY. ')'; /include/classes/api/services/CGraph.php php: 
 memory_limit = 512M
 opcache.enable =1 ZABBIX FRONTEND
  18. 18. • Все в CSV • схема с процедурами партиционирования: 
 
 $MYSQLDUMP --no-data --events --routines • все таблицы кроме исторических:
 
 $MYSQLDUMP --opt --compact --no-create-info 
 --tab=${DB_TABLE_DIR} $db $tb • history и trends по партициям:
 
 SELECT * FROM $tb PARTITION (${PART}) INTO OUTFILE '$FILE'
 DB BACKUP
  19. 19. 1. backup только конфигурации, без истории и трендов 2. создаем базу zabbix_lite из бэкапа на шаге1 3. перенастриваем zabbix_server на zabbix_lite 4. поднимаем zabbix_server новой версии наVM, настраиваем на обновляемую базу 5. проходим по логам процедуру обновления БД, в основном это ALTERTABLE … ENGINE=«TokuDB» 
 
 +смотрим, что он там делает
 src/libs/zbxdbupgrade/dbupgrade.c 6. обновляем основной zabbix_server 7. стартуем на обнолвенной базе ПРОЦЕСС ОБНОВЛЕНИЯ ZABBIX SERVER
  20. 20. 1. пользовательские сценарии по сайту + личный кабинет через wget_gost 2. AIX, Linux,Windows 3. много WebSphere + Zorka.io (heap, GC) 4. Oracle: tablespaces, jobs, replication, бизнес метрики приложения (все на  LLD) 5. работу сервисов: nginx, apache, mongodb, tomcat, … 6. cpu, ram, swap, iostat 7. сертификаты 8. не любим crontab и UserParameter — любим system.run[] ЧТО МОНИТОРИМ
  21. 21. CASE: ОТЧЕТ О ДОСТУПНОСТИ ВИРТУАЛИЗАЦИИ … LUN 1 LUN 2 LUN 3 LUN 1 LUN 2 LUN 3 Задача: сформировать отчет для каждой ВМ заказчика по интегральной метрике доступности гипервизора, СХД и сети. boarder router
  22. 22. FAST: pyVmomi — Python SDK for theVMware vSphere API
 SLOW: VMware Perl SDK НОВОЕ LLD ДЛЯ ОБНАРУЖЕНИЯVM
  23. 23. ПРОВЕРКА ДОСТУПНОСТИ СЕТИ /usr/lib/zabbix/externalscripts/vm.zm.boarder /tmp/vminfo.file
  24. 24. ПРОВЕРКА ДОСТУПНОСТИ СХД /usr/lib/zabbix/externalscripts/vm.zm.datastore /tmp/vminfo.file
  25. 25. ПРОВЕРКА ДОСТУПНОСТИ ГИПЕРВИЗОРА /usr/lib/zabbix/externalscripts/vm.zm.hyper
  26. 26. ТРИГГЕРЫ ДОСТУПНОСТИ
  27. 27. ОТЧЕТ
  28. 28. ОТЧЕТ
  29. 29. CASE: ODBC LLD Задача: создать шаблон автоматического обнаружения метрик приложений 
 на WebSphere application server • имеем в наличии 120 серверов приложений • сервера пишут статистику в Oracle • получаем значения метрик через db.odbc.select[] • функционал опроса БД вынесен на Zabbix Proxy
  30. 30. extrenalscripts/odbc.***.publish.discovery
  31. 31. extrenalscripts/odbc.***.publish.discovery
  32. 32. СЛАБЫЕ МЕСТА ODBC • Нет отдельного процесса под проверки — иногда коннект к базе может быть долгий, отнимается целый poller • Одна проверка — одно новое соединение
 NO connection pooling — не кэшируют соединения, Ваши DBA будут счастливы • Нельзя сделать такое:
 SELECT 
 PERCENTILE_CONT(0.1) WITHIN GROUP (ORDER BY one_query_time_ms ) as p_10,
 PERCENTILE_CONT(0.2) WITHIN GROUP (ORDER BY one_query_time_ms ) as p_20,
 PERCENTILE_CONT(0.3) WITHIN GROUP (ORDER BY one_query_time_ms ) as p_30,
 PERCENTILE_CONT(0.4) WITHIN GROUP (ORDER BY one_query_time_ms ) as p_40, 
 PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY one_query_time_ms ) as p_50, 
 PERCENTILE_CONT(0.6) WITHIN GROUP (ORDER BY one_query_time_ms ) as p_60, 
 PERCENTILE_CONT(0.7) WITHIN GROUP (ORDER BY one_query_time_ms ) as p_70, 
 PERCENTILE_CONT(0.8) WITHIN GROUP (ORDER BY one_query_time_ms ) as p_80, 
 PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY one_query_time_ms ) as p_90
  33. 33. ССЫЛКИ • Лучший доклад про мониторинг на RootConf 2015
 Monitoring-driven эксплуатация.  Николай Сивко hh.ru
 http://goo.gl/HDI86X • Мониторинг базы данных Oracle через ODBC в Zabbix
 http://habrahabr.ru/post/226365/ • pyVmomi is the Python SDK for theVMware vSphere API
 https://github.com/vmware/pyvmomi
  34. 34. ВОПРОСЫ?

×