Представление данных мониторинга. Помогите советом?

[AnrDaemon]

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

Идея:
На каждый сайт (их несколько, в разных углах этой планеты) ставится идентичная система.
Система состоит из
1. монитора, собирающего локально доступную информацию и отправляющего запросы на контролируемые сайты;
2. респондера, отвечающего на запросы и записывающего статистику.
Каждый запрос содержит локальное время монитора и "краткий пересказ предыдущих серий" - т.е. если у самого монитора, по его данным, не было интернета "с … по …", в запросе это будет отражено.
Время на всех хостах синхронизировано довольно точно, так что информация накапливаться будет интересная. Кроме собственно доступности сайта - время прохождения запроса, это как минимум.

Собственно проблема:
Не приходит в голову, в каком формате представить информацию, чтобы это было наглядно и практично. График - понятно, а в каком виде? Тупо наложением трёх линий? Вроде не очень наглядно получается, не так очевидно, сколько точек мониторится.
Идеи будут?

P.S.
Пока всё "на текстовых файликах" бегает в тестовом режиме.
Планирую прикрутить RRDtool для хранения информации.
Если будут более интересные идеи - тоже выслушаю.

 

[michelle]

Смотреть в сторону Zabbix, Cacti - полноценный мониторинг, Munin - рисовалка всего и вся, Grafana - красивые графики (есть плагин для отрисовки данных из zabbix'a)

 

[AnrDaemon]

И нарисует мне заббикс три красивых отдельных картинки… Спасибо, мне этого не надо.
Мне надо одну, чтобы её можно было распечатать на салфетке и подтирать ею сопли сеорастов.

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

 

[michelle]

И нарисует мне заббикс три красивых отдельных картинки

А это как твоей душеньке угодно - можно хоть 100500 на одном графике.
А есть еще такая штука, как экраны (screen) - 100500 графиков в одном месте.

Munin - рисовалка основанана на rrdtool
Смотри еще grafana - сейчас так и делаю - zabbix + grafana.

Я в курсе про системы локального мониторинга, они есть и работают, но не дают нужной информации.

Значит нужно что-то в "консерватории подправить" - то есть сделать так, чтобы заббикс (или любая другая мониторилка) собирал и отрисовывал то что нужно (у меня например, сильно кастомизированы шаблоны и собирают и рисуют то что нужно мне), а не изобретать костыли и велосипеды.

 

[AnrDaemon]

Знаешь, сколько было выдано патентов на костыли за последние лет десять?…
Костыли и велосипеды начинают изобретать не от нефиг делать, а потому, что существующие решения очевидно не устраивают.
Например, одна из точек мониторинга - мой рабочий комп. Предлагаешь мне на нём заббикс или munun разворачивать? PHP скрипт я могу в крон воткнуть и не вспоминать о нём. Одним больше - одним меньше…

 

[Крот]

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

 

[AnrDaemon]

О доверии ко мне речь вообще не идёт. Стоит вопрос доверия к сеорастам во-первых и к яндексу во-вторых.
И давайте не будем считать деньги в чужих карманах, хорошо?

 

[MiksIr]

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

В 99% случаев - из-за того, что "не асилил" и из-за того, что "фатальный недостаток".
Для предоставления отчета о доступности сайта достаточно дергать постоянно http анализируя код ответа и таймауты. Можно saas, таких решений куча. Можно zabbix, расставив агенты на разные машины для полноты картины.

 

[AnrDaemon]

Да, спасибо, я в курсе. >.<
Я попросил идей о представлении данных, а получил советы по их сбору.
Может, для вас мой вопрос и кажется детским, но у меня проблемы с визуализацией. Проще говоря, я хреново рисую.
Ладно. буду сам мучаться.

 

[MiksIr]

График время/доступность. В качестве доступности можно время ответа, можно просто 1/0. Если агентов несколько, вывести графики на одном.
Что еще может быть проще. Когда поступает претензия от метрики - есть график, на котором все видно.

 

[AnrDaemon]

Доступность в количестве доступности?… Ну, может быть. Да, наверное ты прав. На общем графике можно просто количество точек мониторинга суммировать.
Попробуем.

 

[MiksIr]

Зачем суммировать, просто несколько "линий" графика с легендой - какая линия какой агент. "упали" в ноль (ну или прыгнули к значению максимального ожидания ответа) все сразу - значит канал ближе к ДЦ или сам сервис. Упало что-то одно - сразу понятно, какое направление проблемное.
Ну и просто пинги тоже считать, можно отдельным графиком, что бы различить сразу - канал или сервис. Пинги есть, а сервис в таймауте - ну беда с сервисом скорее всего. Ну и обычно туда же пинги гейта агента, что бы видеть локальные проблемы у агента.

 

[AnrDaemon]

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

 

[fixxxer]

http://riemann.io/

 

[weregod]

вот тут такое делал (демоны делают http / json-rpc запросы на разные сервера) такие графики:
1. UPTIME сервисов (на графике отображаются все сервисы, можно отключить любой из них прямо на странице, http://www.highcharts.com/ могучая либа)
2. по каждому сервису два графика:
2.1. сгруппированный по часам: uptime, average connect time, average total time, max connect time, max total time;
2.2. детали за последние 24 часа: connect time, total time

 

[MiksIr]

http://riemann.io/

Чем интереснее того же zabbix?

 

[fixxxer]

Чем интереснее того же zabbix?

К заббиксу испытываю личную неприязнь, причем уже много лет заочную, так что не в курсе современного состояния дел. Сравнить могу с семейством nagios (shinken прежде всего) - думаю, будет близко.

Во-первых, отличается моделью, никакого поллинга нет. Мониторингом как таковым, по сути, занимаются локально запущенные на серверах демоны, которые шлют поток событий в виде protobuf-структур. С одной стороны, это кажется менее надежным, с другой - в семействе nagios все равно часто без nrpe не обойтись. Зато такая модель позволяет обрабатывать огромный поток событий, хоть каждую миллисекунду. Если сеть выдержит. В общем, больше похоже, наверное, на пинбу.

Во-вторых, это, по сути, вообще не система мониторинга как таковая. Это этакий фреймворк для обработки потока событий, с инфраструктурой, удобной для решения прежде всего задач мониторинга. То, что в riemann называется конфигурацией, на самом деле не конфигурация, а программы на Clojure. Это, конечно, выглядит непривычно (особенно если никогда не настраивал emacs ), но дает гибкость, позволяющую на лету делать интересные вещи, вплоть до realtime аналитики.

Вкратце суть описана тут: http://riemann.io/concepts.html

 

[MiksIr]

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

 

[fixxxer]

В общем, еще пол года бегать, что бы фотку отдать В смысле, конфигурацию написать.

Да не, типовая конфигурация пишется просто. По мне, даже проще, чем в nagios family. Непривычно - да. Но для классического мониторинга и стандартных метрик оно особо не нужно. А вот если нужны нестандартные realtime метрики - самое то. Впрочем, к нему быстро привыкаешь и не хочется использовать что-то другое, даже когда и не особо нужно.

 

[grigori]

> "по данным яндекса ваш сайт ни… не пашет."
это по данным метрики?
Если да - я тебя огорчу: всем плевать как работает сайт. Если Яндекс считает, что сайт лежит - он будет падать в выдаче.

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

"В народе" сайт оценивается по позиции в выдаче яндекса, а не гугла. Они как IE6: зарабатывают на нас, работают плохо, но пока что мы не можем на них забить. Доказывать нечего, надо решать и ждать, через несколько лет они уйдут, но пока надо решать.
В yandex webmaster есть sms-уведомление о недоступности сайта, включай и отлови момент, когда яндекс считает, что твой сайт упал, сделай traceroute на яндекс и узнай где разрыв.

Вплоть до того, что придется переезжать или поставить прокси, к которому у яндекса будет доступность 24*7*365
С Линодой нормально.