инфраструктурный мониторинг что контролирует

Зачем нужен комплексный мониторинг ИТ и бизнесу и КАК его внедрять?

На «Хабре» есть статьи о том, как внедрять мониторинг. В них описано, как надо и не надо организовывать систему мониторинга. Все эти статьи мы прочитали и поняли, что чего-то не хватает. Здесь не будет информации о важности разработки ресурсно-сервисной модели и о том, как уменьшить число ложно-позитивных сообщений о проблеме. Мы поделимся лайфхаками в работе команды, которые помогают реализовывать подобные проекты. Дальше будут такие рекомендации, которых в других статьях нет. Советы собраны на основе нашего опыта.

Комплексный мониторинг позволяет компаниям понять, где они теряют деньги

В компаниях всегда есть бизнес-подразделения. Они смотрят, где компания может больше зарабатывать и меньше тратить. Часто они обращают внимание на внутренние ИТ-системы. Если в ИТ-системах возникают инциденты, компания будет терять деньги. Например, рухнула платёжная система. Или регистрация стала сложнее, потому что её модифицировали. Или процесс оплаты неудобен для пользователей – в нем 10 кликов вместо 2.

Чем сложнее архитектура бизнес-приложения, тем больше людей необходимо для ее обслуживания: мониторить системы, анализировать и диагностировать инциденты, вникать, как эти инциденты влияют на клиентов. Итог – потрачены часы на выяснение причин сбоя, кто виноват и что делать. Пока это делается, клиенты страдают, деньги компании тратятся, а время устранения инцидентов растёт. Компании приходится смотреть на шлейф всех этих проблем, а не в светлое будущее. Дальше разберёмся, почему так происходит.

Есть кое-что, что мешает быстро обнаруживать источник проблем. Это разрозненность средств мониторинга. Все вместе они не дают единой картины для всех ИТ-компонентов, которые влияют на работу бизнес-приложения. Бывает так, что задачи похожи или даже одинаковые, но повторно их решают другие люди другими инструментами. Нередко приходится сверять друг с другом показатели одних и тех же метрик.

Что будет, если вот это все заставить работать вместе? О плюсах комплексного мониторинга – далее.

Преимущества комплексного мониторинга

Внедрение единого комплексного мониторинга для бизнес-процессов и ИТ-систем – логичное решение. Вот, что сможет делать компания, которая внедрила комплексный мониторинг:

Оперативно обнаруживать и решать проблемы в работе приложений до того, как они повлияют на пользователей;

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

Анализировать клиентский опыт на протяжении всего процесса взаимодействия пользователя с системой;

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

Получить единую точку доступа к общей картине состояния ИТ, возможность исследования «вглубь» – до сырых данных, а также анализировать корреляции.

Какие правила при внедрении комплексного мониторинга мы выработали

Совет №1: Выделите отдельную целостную команду разработки системы комплексного мониторинга.

Вот, кто должен быть в команде:

Специалист по Data Science

Бизнес- и системные аналитики должны быть вовлечены в проект на 100% и играть роль Product Owner’а. Они общаются с командой разработки основного продукта компании: от администраторов до руководителей. Бизнес- и системные аналитики пишут требования к системе мониторинга, планируют релизы и проводят UAT. Они обучают конечных пользователей системы мониторинга.

ИТ-роли в команде можно совмещать: разработчик системы мониторинга и инженер данных, администратор и DevOps инженер.

Совет №2: Заведите мониторинг препродуктивной среды. Потом синхронизируйте релизные циклы команды разработки основного продукта и команды разработки системы мониторинга

Бизнес ставит задачу разработчикам оптимизировать процесс взаимодействия пользователей с платформой. Например, процесс регистрации, оформления покупки, оплаты или возврата средств. Это влечет за собой изменение логов и логики построения KPI. Чтобы это сделать, нужно строить синхронные процессы изменения логики бизнес-процессов сайта и их KPI. Это важно, чтобы одним утром после релиза не обнаружить, что мониторинг не работает.

Совет №3: Начинайте с мониторинга простых метрик, релизьте чаще, усложняйте метрики постепенно

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

В проектах разработки и внедрения системы комплексного мониторинга лучше использовать спринты и Agile-подход. Процесс разработки в нашей команде упрощенно выглядит так:

Определяем один показатель или один бизнес-процесс для мониторинга

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

Реализуем KPI на основе выгрузок и демонстрации пользователя мониторинга.

Дорабатываем источники данных и их подключения.

Разрабатываем KPI на основе живых данных.

Дальше релиз и получение обратной связи.

Потом планируем доработки на основе отзывов. Усложняем KPI путём подключения новых источников. Повторяем цикл.

Совет №4: Не планируйте ресурсные затраты на разработку мониторинга на основе объема систем, покрываемых мониторингом, или по количеству метрик и KPI, запланированных в разработку – вы все равно промахнетесь

Этот пункт вытекает из предыдущего. Наша команда начала разрабатывать мониторинг с зафиксированным объемом и количеством KPI. Сначала мы реализовали несколько дашбордов. Потом перешли на спринты и запланировали только набор бизнес процессов, которые будут мониториться. В результате (а может в процессе) перехода выработался процесс разработки KPI. Тот, что описан выше.

Совет №5: Дайте пользователям системы мониторинга больше свободы

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

Продуктовая команда знает о своем продукте всё. При общении с системными аналитиками они могут упустить некоторые детали в работе или архитектуре систем. Если дать им доступ к изучению сырых данных, вы повышаете интерес конечных пользователей к мониторингу. Может так получиться, что продуктовая команда заметит отклонение показателей. Тогда она начнёт исследовать причины отклонений. Для этого команда сформирует новые метрики – так в будущем обнаруживать подобные проблемы будет проще. Команде мониторинга останется только формализовать метрику и запустить в работу.

Совет №6: Предусмотрите возможность отображения показателей на дашбордах в разрезе разных отрезков времени

Рассмотрим пример: мы разрабатываем бизнес KPI «Процент успешно завершенных регистраций пользователей на сайте». Для разработки KPI необходимо выбрать промежуток времени, в рамках которого мы будем наблюдать за показателем, а также на основе исторических данных определить уровни критичности. Уровень критичности, или важность проблем, определяет какой процент успешно завершенных регистраций считается обычным поведением (обычно обозначается зеленым цветом), или, когда процент успешно завершенных регистраций очень мал, сигнализирует о серьезных проблемах и обозначается красным цветом. В зависимости от промежутка времени, за который мы рассчитываем «Процент успешно завершенных регистраций», уровень критичности может быть разным. Процесс регистрации, как правило состоит из двух основных шагов: заполнение формы на сайте и подтверждение почты путем перехода по ссылке из письма. Некоторые пользователи выполняют регистрацию за пару минут, а другим – требуется вспомнить или восстановить забытый пароль от своей почты, что может занять более 5 минут. Если мы будем вычислять Процент успешных регистраций в рамках 5 минут, то мы «потеряем» пользователей, которые завершат регистрацию за 7-8 минут, что может значительно повлиять на Процент успешных регистраций, и система будет сигнализировать о проблеме.

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

Совет №7: Настраивайте self-мониторинг, чтобы сохранить доверие к системе мониторинга

Совет №8: Используйте стандартный функционал продвинутой аналитики «из коробки». Например, «Автоматический ML»

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

Однако, мы всегда прогоняем их через встроенные аналитические инструменты. Полученные показатели и графики оставляем «пожить» в течение какого-то времени и «пережить» инциденты. В половине случаев обнаруживаем новые зависимости от других показателей и интересные аномалии. На основе этого рождаются новые KPI.

Совет №9: Не спешите передавать дашборды и направлять оповещения группе поддержки второй и третьей линии

Есть показатели, разрабатываемые в рамках комплексного мониторинга, а есть – в рамках инфраструктурного. Они сильно различны по своей природе и имеют совершенно разные понятия «нормы» и отклонения от нее.

«Комплексные» KPI строятся на основе корреляции разнородных бизнес и ИТ-показателей. Как правило, этим показателям присваивают веса, которые определяют влияние на «комплексный» KPI. Поэтому сразу определить понятие «нормы» и построить грамотный алертинг бывает очень сложно.

Команда разработки мониторинга должна брать на себя роль поддержки на какое-то время при релизе каждого нового дашборда или KPI. Это позволит получать обратную связь без посредников и дорабатывать «на ходу». Оповещений не должно быть много.

Есть специалист поддержки, который отвечает за решение проблемы или поиск её причин. Действия этого специалиста должны быть максимально понятными и простыми. Написано множество статей про лечение событийной усталости и о том, как грамотно настраивать алертинг.

Совет №10: Ведите историю инцидентов

ИТОГ: Выгоды от внедрения системы мониторинга

Мы собрали их пять. Вот они:

Система комплексного мониторинга является зонтичным решением для существующих систем мониторинга. Она объединяет агрегированные данные из других узкоспециализированных систем.

Комплексное решение закрывает все «слепые зоны», не покрытые существующими в компании системами мониторингами – сбор сырых данных из систем источников в комплексный мониторинг.

Появляется единая точка для анализа данных и расследования причин инцидентов.

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

Все события имеют корреляцию по времени.

Ещё раз все наши рекомендации кратко:

Комплексный мониторинг внедряет отдельная команда, а не участники продуктовой команды;

Не упускайте мониторинг препродуктивной среды;

Начинайте с мониторинга простых метрик, релизьте чаще, усложняйте метрики постепенно;

Для внедрения комплексного мониторинга больше подходит Agile методология и отсутствие жестко зафиксированного скоупа;

При планировании закладывайте ресурсы продуктовой команды на доработку и изменение источников данных;

Пользователи системы мониторинга должны иметь возможность «покрутить» данные и метрики;

Дашборды должны иметь фильтры для настройки отображения метрик в разрезе 5 минут и 1 часа;

Разрабатывайте мониторинг для системы мониторинга. Особое внимание стоит уделить точкам взаимодействия системы мониторинга с источниками данных;

Аналитический функционал системы мониторинга, поставляемый «из-коробки», может быть полезен;

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

Ведите историю инцидентов.

Статью подготовил консультант компании Accenture Анастасия Астафьева

Источник

Мониторинг инженерной инфраструктуры в дата-центре. Часть 1. Основные моменты

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

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

В комментариях можно попробовать повлиять на редакторскую политику и предложить для рассмотрения интересные именно для вас аспекты мониторинга.

С организационными моментами вроде разобрались, приступим к азбуке мониторинга в редакции DataLine :). Итак, сегодня речь пойдет о концептуальных вещах, которые нужно учитывать на этапе проектирования, внедрения и настройки системы мониторинга. Сабж рассмотрим на примере нашего мониторинга, построенного на базе Nagios и Cacti.

Что такое мониторинг

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

Мониторинг можно трактовать по-разному: как систему и как процесс. В нашем случае это две стороны одной медали – одно без другого существовать не может.

Мониторинг как система помогает непрерывно собирать, хранить и анализировать параметры оборудования и систем. Он снабжает данными, на основе которых инженер делает выводы о текущем состоянии и о возможном будущем поведении наблюдаемого объекта.

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

Когда нужно озадачиться системой мониторинга

Тогда же, когда и начинаете проектировать инженерную инфраструктуру. Если заниматься мониторингом уже после запуска дата-центра, то какое-то время служба эксплуатации будет работать вслепую. Дежурные инженеры не смогут отслеживать ошибки в работе оборудования, пропустят предаварийные ситуации. Единственный доступный способ мониторинга в такой ситуации – это физический обход всех инженерных систем и ИТ-оборудования.

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

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

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

За чем нужно следить

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

Под автономными датчиками мы в первую очередь подразумеваем датчики протечек, температурные датчики, датчики объема и движения.

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

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

Документация по мониторингу

По мере того, как определяемся с объектами и параметрами мониторинга, составляем документацию по системе. В ней фиксируем:

Независимость и резервирование системы мониторинга

Под мониторинг лучше использовать отдельное серверное и сетевое оборудование с выделенным сетевым сегментом.

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

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

Единый центр мониторинга

Всю информацию с датчиков, оборудования и систем нужно сводить в единый интерфейс и выборочно отображать на экранах в центре мониторинга.
За всем этим хозяйством должен следить круглосуточно хотя бы один дежурный инженер. Здесь же все уведомления регистрируются в виде инцидентов на ответственных лиц или отделы.
Это своего рода ЦУП и первый рубеж обороны в случае аварии в дата-центре.

Центр мониторинга на площадке OST.

Визуализация

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

Сводная схема дата-центра OST-2.

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

Разное время опроса для разных систем

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

Устанавливайте разное время опроса для разных систем. Так вы не пропустите важных событий и не перегрузите систему слишком частыми запросами.

Правильно выбранные пороговые значения для уведомлений

Прописывайте критические значения, по достижении которых будут срабатывать оповещения. Лучше предусмотреть как минимум два уровня оповещения – предупреждения и критические ошибки. В Nаgios, например, такому разделению соответствуют warning и critical:

При необходимости корректируйте пороговые значения для разных типов уведомлений.

Примеры warning и alarm

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

Четкий регламент действий при аварийных ситуациях

Не пропустить аварию важно, но еще важнее правильно на нее среагировать и запустить процесс реакции на инцидент.

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

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

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

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

Оповещение по email и смс

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

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

Сбор статистики

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

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

Источник

Всё под контролем. Зачем нужны системы мониторинга инженерной инфраструктуры центров обработки данных

Я ведущий инженер компании «ЛАНИТ-Интеграция». Работаю здесь больше 20 лет. Последние семь лет занимаюсь инженерным обеспечением ЦОДов: устанавливаю и запускаю оборудование в работу.

С каждым годом появляется всё больше требований к надежности и удобству использования дата-центров. Однако этого нельзя добиться, если сосредоточиться только на резервных копиях систем и качестве отдельных элементов. На рынке понимают эту простую мысль, поэтому компании всё чаще внедряют единую систему мониторинга. Если коротко, она следит за инженерной инфраструктурой ЦОД и помогает избежать аварийных ситуаций.

В статье я расскажу о готовых программно-аппаратных решениях мониторинга, которые мы с коллегами используем в проектах.

Источник

Для начала расскажу о том, из чего состоит основа центра обработки данных. Её разделяют на три составляющих.

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

Мониторинг помогает инженерам, обслуживающим ЦОД, комфортнее работать. Без него специалисты должны либо жить и трудиться всё время рядом со шкафами, либо выходить из кабинета и бежать к ним каждый раз, когда возникла какая-то проблема или есть подозрения, что она может случиться.

Мониторинг в реальном времени показывает, как работает инфраструктура ЦОД. За показателями, как правило, следит дежурная смена. При возникновении отклонения или нештатной ситуации сотрудники дежурной смены могут вовремя предотвратить критическую ситуацию или же свести её последствия к минимуму. Также система мониторинга собирает данные о параметрах, статусе оборудования, следит за сроками сервисного обслуживания, наработанными часами и т.д.

Что именно контролирует система мониторинга и какие задачи решает?

Защита от людей

К сожалению, статистика говорит, что множество аварийных ситуаций с техникой возникает по вине человека. Именно поэтому мониторинг в том числе следит не только за параметрами, но и за теми, кто имеет доступ к ЦОД и кто/что в нем делает.

Существует множество различных систем, так или иначе позволяющих контролировать параметры и работу различных типов оборудования — мониторинг IT-систем, мониторинг СКС/ЛВС, мониторинг инженерных систем и т.д.

По типу реализации системы делятся на программные, аппаратные и гибридные решения.

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

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

Централизованные системы дают возможность объединить всё контролируемое оборудование, в том числе и несколько распределенных систем, в единую систему, позволяющую наблюдать за работой всего оборудования в «одном окне».

Из чего состоит

Уже много лет мы с коллегами работаем с системой мониторинга NetBotz и системой управления инфраструктурой ЦОД StruxureWare Data center Expert от APC by Schneider Electric. У нашей команды есть партнёрская сертификация направления DCIM.

У большинства производителей инженерного оборудования существуют комплексные решения. С их помощью можно создать инженерную инфраструктуру ЦОД «под ключ» и собрать систему мониторинга «из кубиков».

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

Например для подключения устройств других брендов, подключаемых по протоколу MODBUS к системе Data center Expert от APC, не входящих в список поддерживаемого, приходиться обращаться в службу поддержки. При этом нужно предоставить технические данные на подключаемое оборудование, заполнить несколько форм и подождать около месяца. Своими силами это сделать практически невозможно.

Установка и настройка

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

НИС ГЛОНАСС

Два центра обработки данных находились в Москве и в Санкт-Петербурге. Их связали единой системой мониторинга инженерной инфраструктуры. В этом проекте впервые пришлось разделять права пользователей для доступа к группам устройств. Как это? Специалисты из Москвы контролировали все устройства в обоих ЦОД, а специалисты в Санкт-Петербурге контролировали только свою часть оборудования.

Проект для металлургического комбината

Нашей команде впервые пришлось «прикручивать» к системе мониторинга StruxureWare Data center Expert оборудование сторонних производителей, дизель-генераторную установку, щит автоматики и щит управления системой кондиционирования. Не обошлось без помощи западных специалистов службы поддержки производителя системы мониторинга. Они за месяц написали драйверы для нужных нам устройств.

Научно-исследовательское подразделение госкорпорации

Здесь помимо стандартного решения мы впервые реализовали мониторинг щита вводного распределительного устройства с автоматическими рубильниками, управляемого программируемым реле ZelioLogic, щита распределения питания с контролем состояния автоматических выключателей на контроллере Acti-9 SmartLink и счетчиков электроэнергии PowerLogic от компании Schneider Electric.

Технопарк

Мы впервые в стране реализовывали системы мониторинга и системы управления инфраструктурой ЦОД с применением 190 беспроводных датчиков температуры и влажности, расположенными в 6 машинных залах и 4 аппаратных.

Относительно скоро стартует ещё один крупный проект. Для нас это будет новый опыт. Предстоит внедрять системы мониторинга RAMOS и систему управления инфраструктурой ЦОД Aegis DCIM (чешский производитель CONTEG). Возможно, снова появится повод, о чём вам рассказать.

Источник