Страница пересобрана: 06:41 15.09.2017
[d | an-b-bro-fr-hr-l-m-maid-med-mi-mu-ne-o-ph-r-s-sci-sp-tran-tv-x | bg-vg | au-tr | a-aa-c-fi-jp-ls-rm-tan-to-vn | gf | azu-dn-hau-ma-me-mo-p-sos-t-w | misc-vnd | stat ]
[Burichan] [Futaba] [Gurochan] - [Архив - Каталог] [Главная]

[Назад]
Ответ
Файл: 1474448485822.jpg -(273 KB, 1067x800, __kirisame_marisa_touhou_drawn_by_pisosh(...).jpg)
273 No.184243  

Как в установщике CentOS при разметке диска настроить порядок следования разделов и их названия (sda1, sda2, sda3...)? При создании разделов они размещаются на диске и получают имена так, как вздумается установщику. Как это настроить вручную? Устанавливаю в графическом режиме.

>> No.184244  

ЯННП. Как создаёшь, так и размещаются, от начала диска sda1.

>> No.184245  
> 2016
> разделы

Лол.

>> No.184246  

>>184245
Наркоман?

>> No.184247  

Скриншоты хоть показал, если совсем не разбираешься. Учитывая, что центось полигон для альфатестирования красношапки, где давно системд и уничтожение старого unix-наследия, есть подозрение, что оно подсовывает тебе GPT by default. А поттерингово поделие учится определять назначение разделов не по таблице fstab, а по именам самих разделов. Так что или скринкаст процесса, или у меня libastral.so староватой версии для помощи тебе.

>> No.184248  

>>184247

>центось полигон для альфатестирования красношапки

Ты с федорой перепутал. Центось это клон промышленной красношапки.

>где давно системд

В RHEL 7, кстати, тоже systemd.

>> No.184251  

>>184246
В юниксах и их копипасте - прыщах - всё осталось со времен вычислительных центров (и это очень медленно выкорчевывается, например init.d -> systemd), когда на одной здоровенной машине работали десятки, а то и сотни пользователей, а обслуживали её пара бородатых программистов-админов. Куча разделов - одно из последствий, для того сценария идеальных, для современных систем - дегенеративных. Объем памяти например никогда не менялся, отсюда раздел /swap вместо файла.
В экспериментальных ФС размер разделов меняется безболезненно средствами самой ФС, а на актуальных - это сплошной гемор. Нахрена нужен раздел /home или /system фиксированного размера на пользовательской ОС? Чтобы он рано или поздно закончился при наличии кучи свободного места в каком-нибудь другом разделе?

>> No.184252  

>>184243
Если я правильно помню, то при разметке MBR sda1, sda2, sda3, sda4 - это физические разделы по порядку их следования на диске. Логические разделы начинаются с sda5 и далее. У тебя вполне может быть sda1 как расширенный и внутри него sda5, sda6 и тп. И вообще, какая разница, как их именовать?

>> No.184253  

>>184251
Нахрена нужен раздел /home или /system фиксированного размера на пользовательской ОС? Чтобы он рано или поздно закончился при наличии кучи свободного места в каком-нибудь другом разделе?
Чтобы он рано или поздно не закончился, забив к чертям весь общий раздел и оставив систему в нерабочем состоянии. Чтобы можно было загружать несколько систем с одним и тем же корнем. Да тупо вынести / на SSD, а /home - на HDD. Всегда лучше иметь возможность, чем не иметь ее. Ты рассуждаешь как типичный фанат systemd: "мне не нужно - значит не нужно никому".

>> No.184254  

>>184251
И да, тебе никто не запрещает использовать файл подкачки, как ты привык. Просто раздел тупо быстрее - снимается лишний (и совершенно ненужный в данном случае) уровень абстракции в виде ФС. Не трогайте наши прыщи, пожалуйста, в них уже 25 лет как все прекрасно и удобно работает. Пилите свои systemd где-нибудь в отдельном загоне и не лезьте к нам.

>> No.184256  

Дико нравится концепция BTRFS, где можно сделать subvolume и вообще не морозится по поводу размера разделов, сохраняя при этом преимущество отдельных разделов для системы и /home. Удурчает только быстродействие.

>> No.184257  

>>184252
Да нет, я не об этом. Создаю корень, он называется /dev/sda1, потом своп - он называется /dev/sda2, потом /tmp - и тут /tmp начинает называться /dev/sda1, корень начинает называться /dev/sda2, своп - /dev/sda3. В том-то и дело, что я создаю разделы в том порядке, который мне нужен, но эта анаконда с дискдруидом пидорасят нужный мне порядок и как сделать нормально я не знаю.
А у меня в планах было сделать отдельные разделы для корня, свопа, /tmp, /var (это сервер БД) и /home.
Собственно, это единственный момент, который просто "убил" меня в центоси - остальное (если не считать SELinux, в который я пока не научился и просто отключил его) идёт гладко.

>> No.184258  

>>184253

>на SSD

А за SSD... Ну, в общем, денег он стоит.

>> No.184259  

>>184253

> / на SSD, а /home - на HDD

Вот этого никогда не понимал. На HDD надо выносить медиапомойку, но уж никак не /home со всеми его конфигами и профилями.

>> No.184260  

>>184259
Но Чии считают, что SSD для файловой каши, что творится в /home, медленнее HDD в четыре раза.

>> No.184261  

>>184243
Пользуйся симлинками из /dev/disk/by-* - их специально для этого и придумали.

>> No.184262  

>>184259
В случае чего ты с HDD свои данные восстановишь. Вон, в особом случае даже с блинов рванувшей в верхних слоях атмосферы «Колумбии» вытянули данные. А SSD как раз подходят под медиа/файлопомойку, куда данные пишутся один раз и надолго.

>> No.184263  

>>184262
А ты богат.

>> No.184265  

>>184262

>В случае чего ты с HDD свои данные восстановишь.

Ты Троля, а не Кроля.

Юзеры делятся на тех, кто ещё не делает бекапы, и ТЕПЕРЬ делает.

>> No.184266  

>>184261

>симлинками

Но mount -o bind и соответствующие записи в /etc/fstab лучше же!

>> No.184267  

Ну охренеть. Я тут сервер поднимаю, а вы какие-то костыли советует.

>> No.184268  

>>184267
Тогда RTFM!

>> No.184269  

>>184243
Не знаю как именно работает установщик центоса, но наверняка у тебя есть какой-нибудь live дистр, так разметь диск заранее в fdisk или gdisk
Но зачем?

>> No.184270  

>>184257
Давно не ставил CentOS вручную, всё кикстартами, твой пост подбил меня посмотреть.
Мне не удалось это воспроизвести, ни на семёрке, ни на шестёрке.

>> No.184271  

>>184269
Так и сделал - загрузился с арчевского лайвсиди, разбил диск cfdisk`ом, включил диск CentOS, подхватил уже созданные разделы, всё пошло нормально.
Честно говоря, не думал, что у центоси такой отвратительный разбивщик дисков - при том, что в остальном дистрибутив оставляет приятные впечатления.
>>184245
А то, что если раздел слетит, то слетит всё сразу - ничего?
Алсо, разбивка на разделы уменьшает фрагментацию, нет, разве?

>> No.184272  

>>184253

> Чтобы он рано или поздно не закончился, забив к чертям весь общий раздел и оставив систему в нерабочем состоянии.

Ты на своей кудахтере не контролируешь что происходит со свободным местом?
>>184260

> Но Чии считают, что SSD для файловой каши, что творится в /home, медленнее HDD в четыре раза.

Бред какой. В любых условиях современные SSD будут заметно быстрее HDD.
>>184271

> А то, что если раздел слетит, то слетит всё сразу - ничего?

А зачем ему слетать?

> Алсо, разбивка на разделы уменьшает фрагментацию, нет, разве?

На любимых здесь HDD разделы снижают производительность. А SSD в общем-то пофиг на фрагментацию.
В общем я уточню - на серверах конечно разделы могут быть полезны. На десктопах чаще всего бесполезны, если речь не идет о каких-то специальных нуждах. Ну и всякие мелкие служебные разделы с загрузчиком, например.

>> No.184274  

>>184272

>На любимых здесь HDD разделы снижают производительность. А SSD в общем-то пофиг на фрагментацию.

Ещё раз говорю. Первое. SSD стоит немалых денег. Второе. Это сервер.

>> No.184275  

>>184257
Тогда не знаю, чем помочь. Единственное, что могу сказать - своп лучше в начало диска поставить, он шустрее работать будет если он тебе хоть когда-то понадобится
>>184258
Да я сам не любитель ссд, но тут он как раз кстати оказывается.
>>184259
Но /хоум и есть медиапомойка. Все конфиги загружаются олин раз в кэш при старте системы и благополучно там лежат себе.

>> No.184276  

>>184272

> Ты на своей кудахтере не контролируешь что происходит со свободным местом?

Мама поставила на закачку свежий сезон любимого сериала. На диске свободно 20 гигов, сериал весит 25. Предупреждение торрент-клиента было благополучно проигнорировано, как и твои лекции по этому поводу. Реальная ситуация.

> Бред какой. В любых условиях современные SSD будут заметно быстрее HDD.

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

> На любимых здесь HDD разделы снижают производительность. А SSD в общем-то пофиг на фрагментацию.

Хахаха. Каким образом разделы снижают производительность? Поведай, будь добр.

> В общем я уточню - на серверах конечно разделы могут быть полезны. На десктопах чаще всего бесполезны, если речь не идет о каких-то специальных нуждах. Ну и всякие мелкие служебные разделы с загрузчиком, например.

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

>> No.184277  

>>184275

> Все конфиги загружаются олин раз в кэш при старте системы и благополучно там лежат себе.

Скажи это фаерфоксу и азуреусу.

>> No.184278  

>>184276

> Мама поставила на закачку свежий сезон любимого сериала. На диске свободно 20 гигов, сериал весит 25. Предупреждение торрент-клиента было благополучно проигнорировано, как и твои лекции по этому поводу. Реальная ситуация.

ext дала тебе резервирование, неужели ты его выключил?

>> No.184279  

>>184276
Ну вот тебе обратный пример - пользователь хочет установить новую классную программу, а на системном разделе для неё не хватает места. Зато на разделе с пользовательскими данными свободно 100 ГБ. Обычная ситуация на windows-машинах с вендорской установкой, они любят на OS и DATA разделять.

> Твое заявление - бред.

Нет, твое. Я-то реально использую SSD, а не ссылочки на проблемы кидаю (где каждый случай ни о чем толком не говорит, т.к. нет полной картины - включен ли TRIM, насколько заполнен диск и т.д.). У меня никогда производительность IO не падала до уровня HDD.

> Каким образом разделы снижают производительность?

Элементарно, одновременное обращение к файлам на разных разделах. Блок головок, будет метаться туда-сюда, выдавая скорость чтения 0,2 МБ/c. Впрочем это нормальный режим работы HDD при случайном чтении.

> логическая организация всегда лучше, чем помойка.

Для этого вполне подходят директории. Юниксовые имеют стандарт организации, выделять что-то в отдельный раздел или нет - по желанию.

> раздел подкачки

В някоси и виндоус файлы прекрасно справляются с этой задачей. На виртуалке (сервере) можно и раздел, там конфигурация оборудования редко меняется.

>> No.184282  

>>184276

>Загляни в соседний тред, там я даже расписал и привел ссылки

Туда, где ты рассказывал про новые бюджетные ссд на sandforce пятилетней давности?

>> No.184285  

>>184277
За аузерус ничего не скажу, но файрфокс не так много работает с диском, чтоб его сильно нагружать. При желании можно, в принципе, кеш в tmpfs вынести, если это кажется критичным. Я больших проблем даже на ноуте не замечаю.
>>184282
Это моя вина, что в бюджетном секторе нет особого выбора?
>>184279

> Ну вот тебе обратный пример - пользователь хочет установить новую классную программу, а на системном разделе для неё не хватает места. Зато на разделе с пользовательскими данными свободно 100 ГБ.

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

> Обычная ситуация на windows-машинах с вендорской установкой, они любят на OS и DATA разделять.

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

> Нет, твое. Я-то реально использую SSD, а не ссылочки на проблемы кидаю (где каждый случай ни о чем толком не говорит, т.к. нет полной картины - включен ли TRIM, насколько заполнен диск и т.д.).

Я говорил, что не использую SDD? Напротив, у меня он есть. Просто стараюсь расширять имеющиеся знания не только за счет своего опыта, но и опыта других людей.

> У меня никогда производительность IO не падала до уровня HDD.

Я тоже не ловил ничего смертельного до сих пор. Но у меня основная ОС - GNU/Linux с отличной организацией дисковой подсистемы, плюс я выполняю несколько простых правил (не забивать диск намертво, минимизировать запись и тп).

> Элементарно, одновременное обращение к файлам на разных разделах. Блок головок, будет метаться туда-сюда, выдавая скорость чтения 0,2 МБ/c. Впрочем это нормальный режим работы HDD при случайном чтении.

Ты немного не представляешь, как это выглядит на самом деле. Контроллер не будет гонять головку туда-сюда на каждый блок, он сначала заполнит кэш, а потом будет считывать куски другого файла. В синтетических тестах роль кэширования стараются минимизировать, чтобы получить заведомо худший случай, но в реальности такого никогда не случается. Да и 0.2 МБ/с - совсем мало, современные даже бюджетные диски меньше 0.5 не выдают. И, повторюсь, это синтетические тесты с огромной глубиной очереди, недостижимой на практике.

> Для этого вполне подходят директории. Юниксовые имеют стандарт организации, выделять что-то в отдельный раздел или нет - по желанию.

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

> В някоси и виндоус файлы прекрасно справляются с этой задачей. На виртуалке (сервере) можно и раздел, там конфигурация оборудования редко меняется.

На домашнем компьютере конфигурация оборудования тоже меняется довольно редко, честно говоря. Раз в пять лет переразбить диск не так и страшно. Ну а вообще подсистема памяти в NT организована отвратно, это единственное, что мне жутко в нем не нравится (не путать с самой виндой, в ней вообще писец полный), и подкачка на раздел, а не в файл тут бы ничего не изменила. Про мак ничего не скажу, не знаком.

>> No.184298  

>>184285

> Это моя вина, что в бюджетном секторе нет особого выбора?

Пользуюсь бюджетным Kingston UV400 на 240 ГБ с контроллером Marvell (4500 р.), разницы с почти в два раза более дорогим Samsung EVO 850 такого же объема не замечаю. Разница с HDD, оф коурс - небо и земля (HDD на вкус как земля).

> либо эта программа не особо ему и нужна, раз он о ней заранее не подумал и не учел ее объем при разбивке на разделы

Лол.

> чтобы пользователь не загадил системный раздел

Интересно, что быстрее "загадит" пользователь - 80 ГБ или 500 ГБ?

> Ты немного не представляешь, как это выглядит на самом деле.
> недостижимой на практике

Прекрасно представляю, т.к. сталкивался с этим на практике. Контроллер пытается оптимизировать перемещение головок, но чудес не бывает.

>> No.184309  
Файл: 1474636521651.png -(60 KB, 812x368, DiskMark64_2016-09-23_16-06-12.png)
60

>>184285

>Это моя вина, что в бюджетном секторе нет особого выбора?

Ты хотя бы каталог открой перед тем как писать. Один из пяти дисков будет на sandforce, все остальные - на чём угодно кроме него.

>Ты немного не представляешь, как это выглядит на самом деле

Нет, ты. Начнём с того, что память на винте - это буфер, а не кэш. Контроллер не будет пытаться заполнить буфер при каждом чтении - хотя бы потому, что на заполнение даже крошечного 32мб буфера очень быстрому диску потребуется минимум 125мс. Вместо этого в буфер пойдёт запрошенный блок, а так же куски данных, которые винт прочитает вместе с ним.

Далее, знаешь почему никто не делает очереди глубиной в 1000 запросов? Потому что кроме скорости чтения есть ещё один важный параметр - задержка (latency). И если ты сделаешь большую очередь, а планировщик её неудачно оптимизирует, то один жалкий запрос заблокирует тебе весь процесс, и плевать что всё остальное чтение диск выполнил в 10 раз быстрее.

>0.2 МБ/с - совсем мало, современные даже бюджетные диски меньше 0.5 не выдают.

Пикрелейтед. Слева - SSD, справа - два винта 7200RPM в raid0. И с того и с другого в фоне раздаются торренты.

>> No.184317  

>>184309
Циферки синтетики ничего не значат.

>> No.184321  

>>184275

>своп лучше в начало диска поставить, он шустрее работать будет

Что я и рассчитывал сделать. Вместо этого установщик в некоторый момент решает переразместить разделы так, как ему кажется лучше, в результате чего первым оказывается /var, потом корень, потом своп, потом /tmp.

>Да я сам не любитель ссд, но тут он как раз кстати оказывается.

Ещё раз повторяю. Серверные SSD стоят очень и очень много. А подбивать начальство на покупку SSD для сервера базы данных я не собираюсь.

>> No.184328  

>>184321

>Серверные SSD стоят очень и очень много. А подбивать начальство на покупку SSD для сервера базы данных я не собираюсь.

https://market.yandex.ru/product/13527137
https://market.yandex.ru/product/14068358
Много?
Если ты серьёзно предлагаешь в 2016 году сэкономить на ссд для сервера баз данных, то у меня плохие новости по поводу твоей профпригодности.

>> No.184345  

>>184328
Знаешь, это не моё дело - смотреть, какое там сейчас серверное железо. И, тем более, не моё дело - говорить, как надо тем людям, которым я подчиняюсь. Моё дело только исполнять приказ. А как это делать - решаю не я.

>> No.184346  

>>184345
А огребать за проблемы этого сервера тебе. Наслаждайся исполнением приказов.

>> No.184352  
Файл: 1474729789539.png -(221 KB, 700x572, 1326025974560.png)
221

>>184345
Сперва SSD немалых денег стоит, и тормозит. А затем оказывается что ты никто, звать тебя никак, решения принимает начальник, и вообще, дяденька, не бейте.

Не надо так.

>> No.184417  

>>184352

>тормозит

Где я про это говорил? Я сам прекрасно понимаю, что SSD решит многие проблемы, которые мы сейчас имеем с сервером системы мониторинга, у которого узкое место - это перегруженная постоянными запросами чтения/записи в БД дисковая подсистема.
Начальство тоже это понимает. Более того, вопрос перехода на SSD уже рассматривался ранее, но в условиях, когда фирме нечем платить зарплату сотрудникам, а массив SSD стоит как 3 моих месячных зарплаты (пусть я и нахожусь на низшей должности), это довольно проблемно.

>> No.184418  

>>184417
Я думал БД умеют в кеширование на отдельном диске. Или там такой сервер что даже для кеша нужен огого массив?

>> No.184423  

>>184418
Сейчас в кэш умеет всё что угодно. Если не завезли достаточно новый контроллер, можно софтом отделаться. Хочешь - используй форк фейсбучьего flashcache, хочешь - bcache со своими разделами, хочешь - lvmcache. ZFS ещё умеет. Да даже ущербные интеловые контроллеры на десктопе умеют использовать кэш на SSD.

>>184417
Тебе же дали ссылку на ссд 2 поста назад. Под мелкую базу заббикса можно взять на 120 гигов, они вообще смешных денег стоят. А из компании, которой нечем платить зарплату, я бы уходил на твоём месте.

>> No.184497  

Раз уж на то пошло. В /var/log/zabbix/zabbix_server.log:

    3834:20160928:180439.731 [Z3005] query failed: [0] PGRES_FATAL_ERROR:ОШИБКА:  отношение "users" не существует
LINE 1: select userid from users limit 1
^
[select userid from users limit 1]
3834:20160928:180439.731 cannot use database "zabbix": database is not a Zabbix database

Поднимаю его на постгресе, создал БД из create.sql.gz, идущего в потставке заббикса. Таблица users в БД zabbix создалась, однако сервер эту БД не подхватывает.
В чём может быть проблема?
Раньше сам поднимал под MariaDB, проблем не было.

>> No.184668  

Монтируй по UUID, а не по названию диска https://www.opennet.ru/base/sys/fstab_label.txt.html .

>> No.184682  

>>184668
Здесь речь не об этом, а о том, что своп, /tmp и /var лучше располагать ближе к началу диска, где доступ к данным будет быстрее.

>> No.184684  

>>184682
/tmp вообще лучше на tmpfs вынести. И чистить при каждой загрузке не надо, и быстрее гораздо.

>> No.196064  

>>184352

>Лили за рулём

А в маске поди глухая, спрашивает капча Deaff

>> No.196070  

>>196064
Забанить бы тебя, да тред удалить.

>> No.196073  

>>184251

>Нахрена нужен раздел /home или /system фиксированного размера на пользовательской ОС?

Потому что винчестеры пока ещё фиксированных размеров делаются. А для не фиксированного придется заморочиться с рейдами и более современными фс.
>>184275

>Но /хоум и есть медиапомойка.

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

>> No.196078  

>>184497
Ты структру таблицы-то добавил? zcat bla bla bla

>> No.196093  

>>196078
Вопрос был решён уже почти как год назад. Не помню, что у меня там было, но какой-то мелкий и довольно очевидный косяк.
И закончилось тем, что сервер был поднят на FreeBSD 11.3 с ZFS.

>> No.196233  
Файл: 1505216526307.png -(244 KB, 704x400, 11.png)
244

Это линупс тред?
Чии, я отстал от жизни, так что только сейчас осваиваю системы мониторинга. Сейчас подняты CentOS/Zabbix 3.4.
Посоветуйте литературы и источников, где понятно дан концепт системы и её объектов. Поделитесь вашими настроенными серверами: что наблюдаете, какие триггеры, графики?

>> No.196268  

>>196233
Спасибо отписавшимся. Суть понял из документации. Буду закреплять на практике.

>> No.196269  

>>196233
Абсолютно стандартные триггеры и графики из темплейтов, сам еще не разобрался. Задавай ответы, может, вместе будем думать.

>> No.196271  
Файл: 1505325594405.jpg -(103 KB, 800x500, video-games-touhou-computers-geek-keyboa(...).jpg)
103

>>196269
Пока мысли такие:

  • Весь парк пользовательских ПК на виндоус покрывать агентами особо не интересно. Чем оно полезно вообще? Может стоит, если заставить собирать данные SMART.
  • Настроил получение данных с порта моего маршрутизатора по SNMP. Пока только download/upload шнурка в интернет. Интересно было бы получить тут же процент потерь.
  • Есть своя сетка VPN до филиалов. Хочется видеть, что другая сторона on-line и опять же ping до них и потери.
  • Сервера с виртуализацией (ESXi и Xenserver). Пока не разбирался, как с ними контактирует zabbix, но данные с них получать было бы полезно.
  • Банальные серваки с 1C, почтой,файловыми шарами... Ставить агента, брать дефолтные параметры. Было бы интересно иметь данные по терминальным серверам, возможно, контролировать спулер печати и реагировать на нетипичные %cpu.
>> No.196276  

>>196271
Ты когда систему мониторинга поднимал, ты ведь её поднимал не просто так? Вот и добавь туда всё то, ради чего ты её поставил.

По опыту, мониторинг нужен по следующим параметрам:
Все компы: загрузка ЦП, оперативной памяти, свободное место на системных и любых критичных для работы дисках.
Физические машины: температура ЦП, вентилятор ЦП.
Всё, что имеет в себе винты: SMART 5,7,194,196,197,198,199.
Роутеры, свитчи: скорость на портах, ошибки в обе стороны.
Для критичных узлов сети: доступность, пинг, потери.
Естественно, уследить за такими объёмами данных не получится, поэтому нужно будет настроить триггеры и оповещения.

В итоге о любых неполадках и странностях ты станешь узнавать ещё до того, как тебе позвонит пользователь.

>> No.196277  

>>196276

>ты ведь её поднимал не просто так?

Нужна для саморазвития. И без мониторинга жили, не тужили.
Просто я реально засиделся на этом месте, что уже мозги плесневеют, а требованиям рынка не соответствую. Вот и придумываю себе работу, чтоб заполнить пробелы.

>> No.196278  
Файл: 1505329619554.png -(246 KB, 1899x955, firefox_2017-09-13_22-03-10.png)
246

>>196277
Ещё можешь посмотреть в сторону grafana.
Позволяет рисовать вот такие интерактивные дашборды (пикрелейтед), по которым крайне удобно понимать, что происходит с множеством выбранных параметров в данный конкретный момент.

>> No.196286  

>>196271
Если что, NASы умеют в SNMP, можно с ними еще поиграться.

>> No.196292  

>>196271

>Настроил получение данных с порта моего маршрутизатора по SNMP. Пока только download/upload шнурка в интернет. Интересно было бы получить тут же процент потерь.

Из маршрутизаторов использовались, в основном, MikroTik (на сайте заббикса можно найти готовый шаблон), либо одноюнитовые машины или виртуалки с серверными атомами с pfSense (имеет агент и прокси из коробки), либо Zentyal (по сути, убунта, агент ставится как обычно) нв борту. Данные с сетевых интерфейсов, вроде бы, можно получать достаточно разнообразные (уже забыл, если честно - сейчас работаю уже не админом и в совершенно другой организации). Насчёт остального сказать не могу.
Про свитчи ниже правильно сказано. По SNMP можно получить много интересной информации. У нас были Cisco Catalyst и Dlink. Если, конечно, они управляемые.

>Сервера с виртуализацией (ESXi и Xenserver). Пока не разбирался, как с ними контактирует zabbix, но данные с них получать было бы полезно.

С ESXi надо возиться, если не ошибаюсь. Xenserver, насколько помню, открытый и туда можно легко залезть с целю поставить агент.
Сам с этими системами никогда не имел дела, у нас был Proxmox - это дебиан с некоторыми накрутками, скачивается deb с агентом для соответствующей версии дебиана и устанавливается.

>Банальные серваки с 1C, почтой,файловыми шарами... Ставить агента, брать дефолтные параметры. Было бы интересно иметь данные по терминальным серверам, возможно, контролировать спулер печати и реагировать на нетипичные %cpu.

Опять же, ниже правильно сказано про SNMP на СХД. Ещё добавлю, что мы часто использовали FreeNAS. Туда ставил агента. Агент и требующиеся для его работы либы предварительно компилировались из портов и собирались в пакеты на другой машине с той же версией FreeBSD, которая использовалась в FreeNAS. Но, если не ошибаюсь, в SNMP он тоже может.
В качестве почтового сервера много где использовали Zimbra, там в дополнение к мониторингу самого сервера агентом, был ещё JMX. Он же использовался на серверах джаббера.

Что ещё:
Конечно же, UPS. Напряжение в сети, напряжение на выходе, ток, заряд аккумулятора, состояние аккумулятора, температура и т.д..
Принтеры. Остаток тонера, в первую очередь. Что ещё было - не помню.



Удалить сообщение []
Пароль
[d | an-b-bro-fr-hr-l-m-maid-med-mi-mu-ne-o-ph-r-s-sci-sp-tran-tv-x | bg-vg | au-tr | a-aa-c-fi-jp-ls-rm-tan-to-vn | gf | azu-dn-hau-ma-me-mo-p-sos-t-w | misc-vnd | stat ]
[Burichan] [Futaba] [Gurochan] - [Архив - Каталог] [Главная]