plustrace monitoring solutions для чего
Обзор систем мониторинга серверов. Заменяем munin на…
Очень долго хотел написать статью, но не хватало времени. Нигде (в том числе на Хабре) не нашёл такой простой альтернативы munin, как описанная в этой статье.
Я backend developer и очень часто на моих проектах не бывает выделенных админов (особенно в самом начале жизни продукта), поэтому я уже давно занимаюсь базовым администрированием серверов (начальная установка-настройка, бекапы, репликация, мониторинг и т.д.). Мне это очень нравится и я всё время узнаю что-то новое в этом направлении.
В большинстве случаев для проекта хватает одного сервера и мне как старшему разработчику (и просто ответственному человеку) всегда нужно было контролировать его ресурсы, чтобы понимать когда мы упрёмся в его ограничения. Для этих целей было достаточно munin.
Munin
Он легко устанавливается и имеет небольшие требования. Он написан на perl и использует кольцевую базу данных (RRDtool).
Выполняем команды:
apt-get install munin munin-node
service munin-node start
Теперь munin-node будет собирать метрики системы и писать их в бд, а munin раз в 5 минут будет генерировать из этой бд html-отчёты и класть их в папку /var/cache/munin/www
Для удобного просмотра этих отчётов можно создать простой конфиг для nginx
Собственно и всё. Уже можно смотреть любые графики использования процессора, памяти, жёсткого диска, сети и многого другого за день/неделю/месяц/год. Чаще всего меня интересовала нагрузка чтения/записи на жёсткий диск, потому что узким местом всегда была база данных.
Для мониторинга ресурсов сервера его всегда хватало, а для мониторинга доступности сервера использовался бесплатный сервис наподобие uptimerobot.com.
Я использую такую комбинацию для мониторинга своих домашних проектов на виртуальном сервере.
Если проект вырастает из одного сервера, тогда на втором сервере достаточно установить munin-node, а на первом — добавить в конфиге одну строчку для сбора метрик со второго сервера. Графики по обоим серверам будут раздельные, что не удобно для просмотра общей картины — на каком сервере заканчивается свободное место на диске, а на каком оперативная память. Эту ситуации можно исправить добавив в конфиг уже десяток строчек для агрегации одного графика с метриками с обоих серверов. Соответственно целесообразно это делать только для самых основных метрик. Если в конфиге сделать ошибку, то придётся долго читать в логах, что именно к ней привело и не найдя информации попытаться исправить ситуацию «методом тыка».
Стоит ли говорить, что для большего количества серверов это превращается в самый настоящий ад. Может это из-за того, что munin был разработан в 2003 году и изначально не был рассчитан на это.
Альтернативы munin для мониторинга нескольких серверов
Splunk — общее описание платформы, базовые особенности установки и архитектуры
В рамках корпоративного блога компании TS Solution мы начинаем серию обучающих статей про такой продукт для анализа машинных данных как Splunk. Большинство статей будут представлять собой «how to tutorial», описание интересных кейсов и решение популярных проблем.
В данной статье мы кратко расскажем о самой системе и её назначении, а также рассмотрим варианты по её установке. 
Пару слов про Splunk
Splunk это платформа для сбора, хранения, обработки и анализа машинных данных, то есть логов. На сегодняшний день является крайне популярной в США и в Европе и постепенно выходит на другие рынки, включая Россию. Одной из главных особенностей платформы является то, что она может работать с данными практически из любых источников, и поэтому список возможных применений системы очень широк.
Splunk, в большинстве случаев, (автоматически или с помощью аддонов) разбирает входные данные на поля и значения и в последствии обрабатывает их. Обработка происходит посредством SPL запросов (специальный язык от Splunk), с помощью которого можно строить различные выборки и таблицы, сортировать, фильтровать, агрегировать, строить отчеты, создавать вычисляемые поля, обращаться как к внутренним, так и внешним справочникам, создавать дашборды, с широким спектром визуализации и делать алерты (например по результату выполнения запроса отправлять тикеты в Service Desk). Все это можно упаковать в свое персональное приложение.
Основные отличия или сильные стороны Splunk
Почему это важно? Потому что Splunk может обеспечить сбор данных в реальном времени из тысяч разнородных источников — и это может быть как физический или виртуальный хост, так и облако. Также Splunk поддерживает поиск не только в реальном времени, но и по всему временному промежутку, данные за который были собраны. То есть мы можем осуществлять поиск, мониторинг, оповещения, отчетность и анализ за любое время (исторический данные и данные в реальном времени в одном решении). И наконец, Splunk обеспечивает быстрый результат и высокую интерактивность поисковых запросов на чрезвычайно больших объемах данных.
Где скачать?
Бесплатная версия Splunk c ограничением на индексацию в 500 Мб в день доступна на официальном сайте компании, единственное что вам нужно сделать это пройти регистрацию.
Системные требования
Splunk поддерживает как 32-bit, так и 64-bit разрядную архитектуру. Ниже представлены таблицы с доступными платформами для Splunk отдельно для Unix и Microsoft. В последнем столбце таблицы находится информация о Splunk Universal Forwarder. Это отдельный дистрибутив и отдельная роль в платформе Splunk, которая выступает в качестве агента и отвечает исключительно за сбор логов и пересылку их на сервер.
Unix
А – версия доступна для скачивания, но не имеет официальной поддержки
D – версия в данный момент поддерживается, но в будущих релизах компания может снять ее с официальной поддержки
Windows
D – версия в данный момент поддерживается, но в будущих релизах компания может снять ее с официальной поддержки
… — версия поддерживается, но Splunk не рекомендует использовать данную архитектуру
Установка
После того как вы скачали установочный файл просто запускайте установку и по умолчанию система встанет в базовой конфигурации. Подробная пошаговая инструкция по установке на Windows здесь, на Unix системы здесь.
После установки Splunk должен быть доступен через веб интерфейс порт 8000: localhost:8000 и после смены пароля и входа вы увидите следующий интерфейс.
На этом мы закончим вводный обзор. В следующей статье мы расскажем как загрузить данные в Splunk, как пользоваться языком SPL, как строить графики и дашборды.
Также, мы недавно делали вебекс общего характера про Splunk — его запись вы можете посмотреть по ссылке на Youtube. В этом вебинаре был показан базовый функционал и рассказаны некоторые кейсы применения продукта.
Мониторинг серверов: что это и для необходимо
Для чего нужен мониторинг серверов
Обратите внимание, что наряду с анализом работоспособности серверного оборудования целесообразно осуществлять постоянный мониторинг корпоративной сети. Это стало особенно необходимым после того, как сеть расширилась не только на локальных пользователей, но и на удаленных юзеров, мобильные устройства, беспроводные сети, облачные технологии, IoT, VPN и многое другие. Сети мониторятся также при помощи специального программного обеспечения. У этого процесса такие же задачи, как и у мониторинга серверов: своевременно обнаружить ошибку, избежать сбоя и исключить взлом.
Какие данные отслеживаются при мониторинге серверов
На основании этих данных можно контролировать свободное и заполненное место СХД, статус оборудования (активно или нет), объем трафика, загруженность ЦП, температуру устройств, работоспособность отдельных элементов СХД (например, активной системы охлаждения на корпоративных моделях). Вся информация анализируется и отображается в режиме реального времени. Утилиты с удобным интерфейсом имеют режим оповещений, поэтому любая ошибка сразу же будет замечена системным администратором.
Утилиты и специализированные сервисы для мониторинга серверов
Мониторинг серверного оборудования осуществляется при помощи специальных утилит или сервисов. Чаще всего для круглосуточного контроля используются утилиты Linux или сервисы мониторинга. Они могут быть платными или бесплатными. В корпоративной среде, конечно же, зачастую используют платные утилиты и сервисы, которые более функциональны и стабильны. Выбор сервисов очень большой и зачастую системные администраторы выбирают те инструменты, с которыми они работали ранее или в функционале которых они полностью уверены.
Примеры сервисов и утилит для мониторинга серверов:
Большая часть корпоративных сервисов мониторинга совместимы с серверами Dell PowerEdge, HP ProLiant, IBM eServer xSeries, Dell PowerEdge Blade, HP BladeSystem, VMware vSphere и другими. Но иногда рационально выбрать их по более узкой специализации. Например, Navicat Monitor больше подходит для мониторинга баз данных (включая облачные СХД). А Site24х7 более функционален и удобен для контроля работы веб-ресурсов.
Те или иные решения в области мониторинга серверов позволяют в режиме реального времени следить за состоянием СХД или облачных баз данных. С подобными системами легко обеспечить бесперебойную работу сайтов, приложений, онлайн-сервисов и систем хранения данных.
Чудеса трассировки: Решение проблем с приложениями при помощи утилиты strace
Содержание статьи
Представь ситуацию: ты поставил новую классную прогу, а она не запускается или безбожно тормозит. Или сетевой сервис падает при непонятных обстоятельствах. Досадно! Ситуация усугубляется тем, что ни в консольном выводе, ни в логах ничего интересного нет. Но и в этом случае можно предпринять ряд действий, которые, если и не помогут устранить проблему в запуске, то хотя бы позволят составить правильный баг-репорт.
Знакомство
Первый помощник в таком случае — это strace. Для тех, кто вдруг не читал статью в #10 за 2009 год («Танцы с бубном и напильником»), напомню, что работа strace заключается в перехвате и записи системных вызовов, выполненных процессом, а также полученных им сигналов. Strace может помочь в следующих ситуациях:
По умолчанию весь вывод strace отправляет в stderr, что далеко не всегда удобно. Попросить strace писать вывод в файл можно с помощью опции ‘-o’:
Как правило, с помощью вызова access проверяются только права на файл или существование самого файла, без каких-либо последующих манипуляций над файлом. Манипуляции над файлом всегда начинаются с системного вызова open, открывающего файл в одном из режимов (O_RDONLY, O_WRONLY или O_RDWR).
Вызов возвращает небольшое целое число — файловый дескриптор, который впоследствии будет использоваться другими вызовами (до того момента, пока не будет закрыт с помощью вызова close).
После открытия файла вызовом open происходит его чтение вызовом read или запись вызовом write. Оба вызова принимают файловый дескриптор, а возвращают количество прочитанных/записанных байт.
Вызов fstat предназначен для получения информации о файле (номер inode, uid, gid и т.д.)
Самый главный вызов в листинге выше — uname, который позволяет получить информацию о текущем ядре. Если трассировка uname занимает всего сотню строк, то трассировка серьезного приложения легко может занимать несколько тысяч строк. Читать такой лог — не самое большое удовольствие. Поэтому иногда лучше записывать в лог только определенные вызовы. Например, чтобы отследить все вызовы open и access (а на них следует обращать внимание в первую очередь при проблемах с запуском приложения):
Вместо перечисления всех нужных вызовов можно использовать классы, состоящие только из специализированных вызовов: file, process, network, signal или ipc. Также можно писать в лог все вызовы, кроме одного.
Например, чтобы исключить вызов mmap:
К сожалению, исключить из вывода сразу несколько вызовов не получится. Некоторые приложения в процессе работы любят наплодить большое количество дочерних процессов. По умолчанию strace игнорирует дочерние процессы, но это поведение можно изменить с помощью опции ‘-f’.
Если вывод strace пишется в лог, то удобно использовать опцию ‘-ff’, которая заставляет strace писать трассировку каждого процесса в отдельный лог вида filename.PID.
Еще одна весьма полезная возможность strace: с помощью опции ‘-p’ и указания PID можно проводить трассировку работающего процесса. Можно даже соединиться сразу с несколькими процессами, указав опцию ‘-p’ несколько раз. Вот такая конструкция запустит трассировку всех процессов apache:
Чтобы показать всю мощь strace, опишу несколько случаев из моей практики, в которых без помощи этой удивительной утилиты на поиск и устранение проблемы я потратил бы кучу времени.
Проблемы с правами
Давным-давно, когда апач еще был версии 1.3, а PHP — 4, переехал я на новый сервак. И практически сразу вылезла одна проблема — из PHP с помощью обычной функции mail не отправлялись письма. Заглянул в логи индейца — пусто, в логах сендмыла и системных логах — тоже ничего интересного. С точно такими же конфигами apache, PHP и sendmail на другом сервере все работало, значит, причина не в них. Пора расчехлять strace. Остановил апач и запустил трассировку:
После того, как скрипт отправки почты (с нехитрым названием mail.php) был несколько раз запущен из браузера, а apache остановлен, можно приступать к анализу лога.
Здесь в каждой строчке первое поле — PID, второе — вызов с параметрами, третье — значение, которое вернул вызов. В большинстве случаев, если возвращаемое значение не отрицательное — вызов отработал без ошибки. То есть, grep по mail.php не дал ничего интересного, кроме PID-процесса (5345), который его обрабатывал. Что ж, запустим grep по PID:
Опять ничего интересного по поводу ошибки. Но на последней строчке с помощью системного вызова clone создается дочерний процесс с PID 5347. Ух ты, квест! 🙂 Grep по 5347:
Бинго! Для отправки почты используется /usr/sbin/sendmail, а вызов ругается на отсутствие прав. Причем права на sendmail выставлены корректно, а вот на /bin/sh — нет. Каким-то образом оказалось, что права на /bin/sh были 770 (при владельце и группе root), то есть пользователь www-data (от которого работал apache) не имел прав на выполнение. Корректировка прав исправила это недоразумение.
Проблемы с сетью
Иногда strace позволяет решать сетевые проблемы гораздо быстрее, чем tcpdump. В частности, с помощью strace очень удобно отслеживать, к каким сервисам и в каком порядке обращается приложение для определения имен.
Однажды я сменил IP для одного домена, но, несмотря на то, что dig выдавал мне правильный новый IP, firefox все еще ломился на старый. Трассируем:
Вызов connect из листинга показывает, что Firefox сначала обращается к сервису NSCD (кэширующий демон) для разрешения имен, а только потом, если NSCD ничего не выдаст — к DNS. На ноутбуке NSCD только мешается, поэтому я его смело удалил, после чего огнелис нашел правильный айпишник.
Проблемы с псевдоустройствами
Бывает, что какое-то приложение просто виснет, не выдавая никаких ошибок и завершаясь только по kill. Или работает, но тормозит на, казалось бы, простейшей операции. Приведу пример: есть старенький Debian Etch, на нем squid из репозитория с простой NCSA аутентификацией и SAMS для удобного управления. После создания пользователя через SAMS при релоаде squid долго тормозит на операциях добавления пользователей.
На последнем вызове система задумывается больше, чем на минуту. Значит, проблема в /dev/random. SAMS применяет его для создания хешей паролей пользователей. Самое простое решение — использовать /dev/urandom, который гораздо быстрее, чем /dev/random.
Сажаем nginx в песочницу
Безопасности много не бывает, поэтому никакая дополнительная ступень защиты лишней не будет. Достаточно популярный и простой в реализации механизм минимизации урона от взлома — запуск приложения в chroot. Процесс переноса приложения в песочницу не сложен, если воспользоваться strace и еще одной полезной утилитой — ldd (показывает список совместно используемых библиотек ELFфайла). Покажу на примере, как запускать в chroot популярный на просторах рунета веб-сервер nginx.
Предположим, что nginx (последней на момент написания статьи версии 0.8.40) уже собран с параметрами по умолчанию и лежит в /usr/local. Список библиотек, которые нужны ему для работы:
# ldd /usr/local/nginx/sbin/nginx
linux-gate.so.1 => (0xb7789000)
libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1
(0xb7751000)
libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb7728000)
libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb75d4000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7cde000)
libz.so.1 => /usr/lib/libz.so.1 (0xb75bf000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7464000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7460000)
/lib/ld-linux.so.2 (0xb778a000)
Переносим эти библиотеки в заранее созданное chroot-окружение (например, /chroot/nginx). Дальше, чтобы удостовериться в том, что у нас есть все необходимые библиотеки, нужно с помощью ldd посмотреть также зависимости скопированных библиотек. Кроме библиотек nginx’у нужны еще некоторые конфиги и логи. Получим список необходимых файлов:
Скопируем недостающие файлы, удаляя при этом из конфигов ненужную информацию (например, лишних пользователей из /etc/ passwd).
Создадим в chroot-окружении /dev/null, необходимый для нормального функционирования nginx’а:
# mknod /chroot/nginx/dev/null c 1 3
Вот и все. Теперь запускать nginx в chroot можно следующим образом:
# chroot /chroot/nginx/ /usr/local/nginx/sbin/nginx
Заключение
Для применения strace есть некоторые ограничения. Во-первых, понятно, что не следует использовать этот инструмент в рабочем окружении (трассировка apache на высоконагруженном productionсервере будет большой ошибкой) — производительность приложения в режиме трассировки сильно снижается. Второе ограничение — это возможные проблемы с трассировкой 32-битных приложений на 64-битной системе. И, наконец, третье — некоторые проги падают при выполнении трассировки вследствие наличия либо багов, либо защиты от трассировок (в основном это касается, конечно, проприетарного софта).
Несмотря на широкие возможности, strace — не «серебряная пуля», он не сможет помочь найти причину абсолютно всех проблем. Однако это очень хороший инструмент, который обязательно нужно попробовать, прежде чем браться за gdb.
Немного истории
Статистика библиотечных вызовов OpenOffice Strace (сокращение от system trace) — это свободное ПО, распространяемое под BSD-подобной лицензией. Утилита была написана в 1991 году Полом Краненбургом для SunOS как аналог утилиты trace. На Linux ее портировал Бранко Ланкестер, который также реализовал поддержку в ядре. В 1992 году вышла версия 2.5 для SunOS, но версия для Linux все еще базировалась на версии 1.5. В 1993 году Рик Слэдки объединил strace 2.5 для SunOS и второй релиз strace для Linux, добавив при этом много возможностей от truss из SVR4. В результате появилась strace, которая работала и на Linux, и на SunOS. В 1994 Рик портировал strace на SVR4 и Solaris, а в 1995 — на Irix. Сегодня strace поддерживается большим количеством людей, в списке разработчиков даже успел отметиться сам Линус. Последняя на момент написания статьи версия — 4.5.20 от 14 апреля 2010 года. strace сейчас достаточно активно развивается, в основном добавляется поддержка и фиксятся баги при работе на всяких экзотичных архитектурах.
Инструменты, подобные strace
DTrace — продукт Sun Microsystems, работает на Solaris, FreeBSD и Mac OS X (10.5 и старше). Есть тестовая версия порта для Linux. ktrace — работает на FreeBSD, OpenBSD, NetBSD и Mac OS X (до версии 10.5).
Inotify-tools
Кроме Incron есть еще полезная штука, использующая inotify — inotify-tools, включающая в себя inotifywait и inotifywatch, которые очень удобно использовать в скриптах. Inotifywait просто ждет указанных событий над указанными файлами и завершается с тем или иным кодом возврата. Немного модифицированный скрипт из man’а, хорошо иллюстрирующий предназначение inotifywait:
Inotifywatch просто собирает статистику по обращению к определенному файлу/каталогу в течение определенного времени или до прерывания и отображает ее в виде таблицы. Есть возможность сбора статистики только по определенным событиям, задания исключения файлов по маске и чтения списка объектов для мониторинга из файла.
Inotify: мониторинг событий
С помощью strace можно отследить, к каким файлам обращалось конкретное приложение. Но иногда возникает обратная задача — отследить обращения к определенному файлу и выполнить какието действия при этих обращениях. Тогда на помощь придет механизм inotify. Inotify — подсистема ядра, позволяющая отслеживать файловые операции. Технология проверена временем — она была включена еще в ядро 2.6.13 (июнь 2005). Inotify активно используется, например, десктопными поисковиками (вроде Beagle), а также такой полезной штукой, как incron.
Incron — аналог обычного cron с той лишь разницей, что выполнение команды происходит не по времени, а по наступлению указанного в задании события. После установки (incron есть в репозиториях большинства дистрибутивов) создается пустой файл /etc/incron.allow, в котором надо перечислить пользователей, которым разрешено использовать incron.
Создаются задания с помощью команды:
(с разделением через пробел)
Самые интересные события
В описании команды можно использовать внутренние переменные. Самые полезные:
51 инструмент для APM и мониторинга серверов
После создания веб- или мобильного приложения начинается не менее интересный этап: нужно арендовать или приобрести серверы, развернуть на них бэкенд и наблюдать, как твой продукт пользуется бешеной популярностью у пользователей. А чтобы всё шло гладко, необходимо мониторить работу серверов и приложений, контролируя их производительность и устраняя намёки на проблемы. А чтобы не терять время на поиски подходящих инструментов для мониторинга и управления, предлагаем вам — сисадминам и разработчикам — воспользоваться этой подборкой.
1. Anturis — Облачный мониторинг для серверов и веб-сайтов, мониторинг ИТ-инфраструктуры
Это облачная (SaaS) платформа, предназначенная для внешнего мониторинга веб-сервисов компании и внутреннего мониторинга ИТ-инфраструктуры (серверов и приложений). В команду этого проекта входят опытные специалисты и инженеры, работавшие на крупные компании и известные стартапы, в том числе Parallels, Лаборатория Касперского, Amdocs, Atempo, K7 Cloud и jNetX.
2. AppDynamics — Сервис для APM и мониторинга серверов
AppDynamics относится к новому поколению решений для мониторинга, упрощающих управление сложными, критически важными приложениями. Среди клиентов сервиса DIRECTV, AMICA Insurance, Hotels.com, StubHub, Staples, Insight Technologies и Корнельский университет.
3. AppNeta — Решения для APM
AppNeta осуществляет комплексный контроль приложений и производительности сети, предоставляет обширные средства мониторинга конечных пользователей. В рамках проекта доступны простые в использовании, эффективные сервисы, позволяющие установить связи между приложениями и сетями, а также между компаниями, управляющими ими.
4. BigPanda — Автоматизация управления инцидентами
BigPanda — это SaaS-платформа, упрощающая процесс разрешения конфликтов в сложных веб-средах. Проект может помочь вам разобраться с потоком данных и алертов, визуализировать зависимости в производственных процессах. И если что-то пойдёт не так, вы сможете быстро выявить причину и устранить её.
5. Boundary — Мониторинг серверов и приложений для разработчиков
Boundary — это сервис мониторинга инфраструктуры приложений. Не требует внесения каких-либо изменений в сами приложения. Не зависит от используемых языков программирования, располагается на каждой виртуальной машине. Boundary собирает большой объём данных о производительности, консолидирует информацию из других источников и формирует комплексные карты приложений, обновляемые в реальном времени.
6. Datadog — Облачный мониторинг в виде сервиса
Datadog — это мониторинговый сервис, агрегирующий метрики и события с серверов, из баз данных, приложений, инструментов и сервисов, на основании которых формируется комплексное представление инфраструктуры. Эти возможности предоставляются на базе аналитической SaaS-платформы, позволяющей координировать действия команд разработчиков и админов, чтобы избегать простоев, быстро решать проблемы с производительностью и вовремя завершать циклы разработки и развёртывания.
7. Dynatrace — APM-сервис
DynaTrace — один из инноваторов и лидеров в сфере APM. Компания предлагает мощную APM-систему, в которой реализован превентивный подход к управлению производительностью приложений. Это позволяет в разы уменьшить продолжительность устранения проблем, а также высвободить кучу ресурсов, ранее затрачиваемых на решение задач по производительности.
8. Gear5 — Система оповещение и мониторинга производительности сайтов
Измеряет время загрузки и скорость работы вашего сайта с точки зрения реальных пользователей. Данные собираются напрямую из браузеров пользователей, что позволит вам получить точное представление о работе сайта.
9. Idera — Мониторинг ИТ-инфраструктуры
Это проект по мониторингу серверов и веб-сайтов для облачных инфраструктур. Idera предоставляет простой, унифицированный, умный и быстрый инструментарий для облачных серверов AWS (EC2), веб-сайтов, веб-приложений и сервисов. Проект помогает оптимизировать производительность и процесс устранение сбоев. Информация в панели управления Idera обновляется каждые несколько секунд (не минут), и с её помощью вы сможете выявить такие скрытые проблемы, как кража процессорных ресурсов (CPU Steal), и своевременно принять меры.
10. Instrumental — Мониторинг приложений в реальном времени
Очень мощный мониторинговый сервис, позволяет снимать порядка 500 000 метрик/сек, и даже не вспотеет.
11. LogicMonitor — хостинговый мониторинг сетей, серверов, приложений, хранилищ и облачных сервисов
LogicMonitor — это SaaS-сервис для мониторинга физической, виртуальной и облачной ИТ-инфраструктуры. Здесь вы сможете отслеживать производительность, просматривать историю и отчёты, настраивать оповещения по почте и SMS, чтобы предупредить сотрудников о потенциальных проблемах, которые нужно решить, пока они не начали влиять на ваши бизнес-процессы. LogicMonitor предоставляет в виде одной веб-консоли заранее сконфигурированный, готовый к работе мониторинговый сервис для большинства вендоров свичей, роутеров, файрволов, балансировщиков, серверов, приложений, баз данных, VoIP-систем и хранилищ.
12. Munin — Программный мониторинг системы, сети и приложений
Munin — инструмент для мониторинга сетевых ресурсов, помогающий анализировать динамику их потребления и решать проблемы типа «что сейчас убило нашу производительность?». Munin очень прост в настройке и использовании, по умолчанию он предоставляет кучу графиков, почти не требуя телодвижений.
13. Nagios — Система мониторинга ИТ-инфраструктуры и рассылки оповещений
Nagios — мощная мониторинговая система, позволяющая определять и решать проблемы, связанные с ИТ-инфраструктурой, прежде чем они окажут влияние на важные бизнес-процессы. Это масштабируемый и гибкий инструмент, благодаря которому можно спать спокойно — нежданные сбои не нарушат ход работы.
14. New Relic — Система мониторинга и APM
15. Ruxit — Система мониторинга производительности веб-приложений
Ruxit изучает вашу среду и проводит анализ различных аномалий. И когда что-то пойдёт не так, вы получите не только предупреждение, но и возможное решение проблемы.
16. Scoutapp — Хостинговый мониторинг серверов
Удобные графики и система оповещения, развёртывается за пять минут. Более 60 плагинов, простое конфигурирование через веб-интерфейс, без необходимости запоминать какие-то команды.
17. Sematext — Система мониторинга производительности, рассылки оповещений и обнаружения аномалий
Компания Sematext предлагает ряд модульных масштабируемых облачных сервисов — SPM Performance Monitoring, Logsene Log Management & Analytics, Site Search Analytics и ряд других. Некоторые из них доступны в локальных версиях (on premise).
18. Solarwinds — Система мониторинга серверов и APM
Сотни тысяч системных администраторов по всему миру пользуются продуктами SolarWinds для управления средами, включающими от десяти до десятков тысяч сетевых устройств. Это семейство продуктов включает в себя инструменты для управления отказоустойчивостью и производительностью, для конфигурирования и инжиниринга. Компания основана в 1999 году, штаб-квартира в Остине, Техас, а группы разработчиков раскиданы по разным странам.
19. Stackify — Application Monitoring & performance for DevOps insight.
Stackify — это облачная платформа для мониторинга и выявления неисправностей в веб-приложениях. Предназначена для разработчиков ПО, сисадминов и служб поддержки. С помощью Stackify можно легко выявлять и решать возникающие в приложениях проблемы. Платформа предлагает инструменты для мониторинга, регистрации ошибок, логов и безопасного удалённого доступа к данным, агрегируемых на сервисе.
20. WhatsUpGold — ПО для мониторинга сетей и серверов
Позволяет получить точное представление о производительности вашей ИТ-среды. Использует различные методики мониторинга для измерения производительности, определения доступности и статуса вашей сети, серверов и приложений.
21. Manageengine Opmanager — ПО для сетевого управления и мониторинга
Компания ManageEngine создаёт приложения уровня Enterprise для управления ИТ-ресурсами. Это большие сетевые фреймворки для крупных, в том числе международных компаний. На текущий момент ManageEngine обслуживает более 45 000 клиентов, в том числе около 60% компаний из списка Fortune 500.
22. Count.ly — Мобильная аналитическая платформа
Countly — приложение для мобильной аналитики, работающее в реальном времени. Собирает данные с мобильных телефонов и визуализирует информацию, позволяя проанализировать использование приложений и поведение пользователей.
23. CA Technologies
Компания CA Tchnologies занимается дизайном, разработкой, маркетингом, лицензированием и поддержкой программных продуктов для управления в сфере ИТ, работающих на всевозможных платформах. В портфеле компании есть решения для мейнфреймов и распределённых сред, для управления инфраструктурой, проектами, безопасностью, сервисом, производительностью, а также для автоматизации ЦОДов и виртуализации.
24. Riverbed — Управление производительностью
Компания Riverbed разработала несколько продуктов класса Enterprise, позволяющих решать фундаментальные проблемы, связанные с производительностью в сфере WAN.
25. Icinga — Open Source мониторинг
Icinga 2 — система сетевого мониторинга, параллельная ветвь развития Icinga 1. По умолчанию не имеет пользовательского интерфейса, его нужно поставить отдельно. Совместима с Nagios, в качестве его форка унаследовала его недостатки.
26. Zabbix — Распределённое open source-решение класса Enterprise для мониторинга
Zabbix создал Алексей Владышев. Система предназначена для мониторинга и отслеживания статусов разнообразных сервисов, серверов и сетевого оборудования.
27. Monit — Простое решение для превентивного мониторинга
Monit — это маленькая open source-утилита для управления и мониторинга Unix-систем. Monit обеспечивает автоматическое сопровождение и восстановление, умеет выявлять причины сбоев.
28. Cacti
Полноценное решение для построения графиков различных метрик, создано на базе RRDTool.
29. Sealion
Этот сервис позволяет быстро диагностировать проблемы на Linux-серверах.
30. OpenNMS
Свободная платформа класса Enterprise для сетевого мониторинга и управления.
31. Site24x7
Внешний мониторинговый сервис для веб-сайтов, созданный компанией ZOHO Corp. Website & Server Monitoring Service.
32. Serverdensity
Мониторинговая система для серверов на FreeBSD, Windows, OS X и Linux, с кастомными плагинами.
33. Keymetrics
PM2 менеджер процессов для NodeJS и мониторинг серверов.
За наводку спасибо botaniQQQ
34. Nixstats
Nixstats — бесплатный сервис для мониторинга и отображения статистики сервера. Пока бесплатен, достаточно зарегистрироваться на сайте.
За наводку спасибо zapimir
35. Sensu
Сервис мониторинга и телеметрии с открытым ядром.
За наводку спасибо levkin
36. Netdata
Real-time мониторинг и телеметрия. Ссылка на гитхаб для установки демо-версии.
За наводку спасибо OLQLOSH
37. Zenoss
Гибкий комплексный сервис для мониторинга событий, производительности и доступности.
За наводку спасибо SemperFi
38. Glowroot
Открытая APM-система, написанная на Java.
За наводку спасибо johndow
39. Observium
Мониторинговая система с очень высокой степень автоматизации. Поддерживает очень широкий спектр оборудования, платформ и операционных систем.
За наводку спасибо varnav
40. Hawkular
Набор REST-сервисов для мониторинга, развитие которого спонсируется Red Hat.
За наводку спасибо MBurov
41. Prometheus
Ещё одно открытое решение для мониторинга и рассылки оповещений.
За наводку спасибо MBurov
42. Raintank
Компания raintank предлагает open source решение для мониторинга класса Enterprise — Grafana.
За наводку спасибо ealebed
43. MoSKito
Этот инструмент во многом схож с NewRelic и AppDynamics, но реализует концепцию более узконаправленного применения.
За наводку спасибо dvayanu
44. Cloudstats
Российская комплексная облачная система мониторинга и резервного копирования.
За наводку спасибо zombi_man
45. SpiceWorks
Полностью бесплатная (даже поддержка) система мониторинга с богатыми возможностями.
За наводку спасибо phoenix87
46. Visual Studio Application Insights
Детище Microsoft, предназначенное для мониторинга и выявления неполадок в веб-приложениях и службах.
За наводку спасибо Ky7m
47. System Center Operations Manager
Ещё один продукт от создателей Windows, предназначенный для мониторинга и управления в корпоративном сегменте.
За наводку спасибо brainfair
48. Anodot
Система реального времени для обнаружения аномалий и аналитики.
За наводку спасибо sergeylanz
49. Инструменты для мониторинга и диагностики HP
За наводку спасибо Balintrue
50. IBM Smart Cloud Monitoring
Система для мониторинга частных облачных инфраструктур.
За наводку спасибо Balintrue
51. Monitor.us
Платформа для создания собственного набора мониторинговых онлайн-сервисов.
Если у вас есть на примете подходящие сервисы, пишите в комментариях, с удовольствием дополним подборку.