DN
Хотя рестарт какого нибудь нджинска как пример
Зачем его ловить?
Size: a a a
2020 January 01
DN
Блекбокс мониторинг должен быть
DN
Ловить рестарта приложений Прометеем это такое
DN
Можно и за секунду не поймать
MD
Ловить рестарта приложений Прометеем это такое
Наверно лучше мониторить journalctl на лог рестарта приложения. И потом алертит исходя из лога.
MD
Уж если так то надо мониторит ещё и релоад конфига. В это состоянии сама приложение не рестартится
AN
а можно чуть больше деталей насчет рестарта и интервала в 200мс, необходимо сделать какую либо автоматизаци на этот счет? или просто отловить? если отловить uptime счетчик и ловить counter reset
AN
если автоматизаци - то скорее всего надо писать свое ПО для этого, ну или фиксить рестарты
A
а можно чуть больше деталей насчет рестарта и интервала в 200мс, необходимо сделать какую либо автоматизаци на этот счет? или просто отловить? если отловить uptime счетчик и ловить counter reset
Зачем счётчик, если можно время запуска отдавать метрикой
AN
или так
ДУ
время запуска наверное самый правильный путь
GM
Хотя рестарт какого нибудь нджинска как пример
а зачем его так рестартить?
W
И звук не пропадает?
a
пс, там записи с PromCon 2019 выложили
спс, схоронил, потом посмотрю
дш
Всем привет, задам, наверное, сейчас очень глупый вопрос)
Есть небольшой микросервис (5 типов приложений), все приложения на ноде.
Необходимо:
1 организовать нормальную систему логирования, с группировкой по типу человеческой веб мордой оповещениями и прочими возможными плюшками
сейчас под логирование выведен отдельный сервис, который тупо ловит по http и пересылает все исключения в мессенджер...
2 иметь понятия о нагрузке на систему в общем. По сути весь функционал системы сводится к обработке событий и взаимодействию с внешними API. хотелось бы иметь возможность знать хотя бы кол. событий по времени и время обработки события....
3 Ловить исключения с клиента (web), требования аналогичны 1 пункту
Все сервисы уже для старта используют pm2 для загрузки и кластеризации. Pm2 имеет собственно веб морду, но она не удовлетворяет всем потребностям и имеет как по мне не оправданную цену -_-
2 пункт можно решить через связку небольшой самописный костыль к pm2 + influxdb + grafana (на это уже есть готовое решение в закромах и по ресурсам оно весьма дешево требуется лишь influxdb)
1 и 3 пункт смотрю в сторону Sentry (минимум настроек, но ограничение 5к событий на бесплатной версии) или же стек ELK (ограничений как я понял нет, но много софта настраивать + отдельный сервак...)
Я сейчас вижу 2 варианта:
1 pm2 + influxdb + grafana для метрик и Sentry для исключений
2 ELK, и к Logstash прикручиваем исключения + метрики необходимые
Посоветуйте, как все это собрать во едино c минимумом затрат(время/финансы), возможно кто-то подскажет другой стек для данной задачи)
и да, сори за портяну текста...
пологаю с всеми вводными проще будет дать совет)
Есть небольшой микросервис (5 типов приложений), все приложения на ноде.
Необходимо:
1 организовать нормальную систему логирования, с группировкой по типу человеческой веб мордой оповещениями и прочими возможными плюшками
сейчас под логирование выведен отдельный сервис, который тупо ловит по http и пересылает все исключения в мессенджер...
2 иметь понятия о нагрузке на систему в общем. По сути весь функционал системы сводится к обработке событий и взаимодействию с внешними API. хотелось бы иметь возможность знать хотя бы кол. событий по времени и время обработки события....
3 Ловить исключения с клиента (web), требования аналогичны 1 пункту
Все сервисы уже для старта используют pm2 для загрузки и кластеризации. Pm2 имеет собственно веб морду, но она не удовлетворяет всем потребностям и имеет как по мне не оправданную цену -_-
2 пункт можно решить через связку небольшой самописный костыль к pm2 + influxdb + grafana (на это уже есть готовое решение в закромах и по ресурсам оно весьма дешево требуется лишь influxdb)
1 и 3 пункт смотрю в сторону Sentry (минимум настроек, но ограничение 5к событий на бесплатной версии) или же стек ELK (ограничений как я понял нет, но много софта настраивать + отдельный сервак...)
Я сейчас вижу 2 варианта:
1 pm2 + influxdb + grafana для метрик и Sentry для исключений
2 ELK, и к Logstash прикручиваем исключения + метрики необходимые
Посоветуйте, как все это собрать во едино c минимумом затрат(время/финансы), возможно кто-то подскажет другой стек для данной задачи)
и да, сори за портяну текста...
пологаю с всеми вводными проще будет дать совет)
A
Всем привет, задам, наверное, сейчас очень глупый вопрос)
Есть небольшой микросервис (5 типов приложений), все приложения на ноде.
Необходимо:
1 организовать нормальную систему логирования, с группировкой по типу человеческой веб мордой оповещениями и прочими возможными плюшками
сейчас под логирование выведен отдельный сервис, который тупо ловит по http и пересылает все исключения в мессенджер...
2 иметь понятия о нагрузке на систему в общем. По сути весь функционал системы сводится к обработке событий и взаимодействию с внешними API. хотелось бы иметь возможность знать хотя бы кол. событий по времени и время обработки события....
3 Ловить исключения с клиента (web), требования аналогичны 1 пункту
Все сервисы уже для старта используют pm2 для загрузки и кластеризации. Pm2 имеет собственно веб морду, но она не удовлетворяет всем потребностям и имеет как по мне не оправданную цену -_-
2 пункт можно решить через связку небольшой самописный костыль к pm2 + influxdb + grafana (на это уже есть готовое решение в закромах и по ресурсам оно весьма дешево требуется лишь influxdb)
1 и 3 пункт смотрю в сторону Sentry (минимум настроек, но ограничение 5к событий на бесплатной версии) или же стек ELK (ограничений как я понял нет, но много софта настраивать + отдельный сервак...)
Я сейчас вижу 2 варианта:
1 pm2 + influxdb + grafana для метрик и Sentry для исключений
2 ELK, и к Logstash прикручиваем исключения + метрики необходимые
Посоветуйте, как все это собрать во едино c минимумом затрат(время/финансы), возможно кто-то подскажет другой стек для данной задачи)
и да, сори за портяну текста...
пологаю с всеми вводными проще будет дать совет)
Есть небольшой микросервис (5 типов приложений), все приложения на ноде.
Необходимо:
1 организовать нормальную систему логирования, с группировкой по типу человеческой веб мордой оповещениями и прочими возможными плюшками
сейчас под логирование выведен отдельный сервис, который тупо ловит по http и пересылает все исключения в мессенджер...
2 иметь понятия о нагрузке на систему в общем. По сути весь функционал системы сводится к обработке событий и взаимодействию с внешними API. хотелось бы иметь возможность знать хотя бы кол. событий по времени и время обработки события....
3 Ловить исключения с клиента (web), требования аналогичны 1 пункту
Все сервисы уже для старта используют pm2 для загрузки и кластеризации. Pm2 имеет собственно веб морду, но она не удовлетворяет всем потребностям и имеет как по мне не оправданную цену -_-
2 пункт можно решить через связку небольшой самописный костыль к pm2 + influxdb + grafana (на это уже есть готовое решение в закромах и по ресурсам оно весьма дешево требуется лишь influxdb)
1 и 3 пункт смотрю в сторону Sentry (минимум настроек, но ограничение 5к событий на бесплатной версии) или же стек ELK (ограничений как я понял нет, но много софта настраивать + отдельный сервак...)
Я сейчас вижу 2 варианта:
1 pm2 + influxdb + grafana для метрик и Sentry для исключений
2 ELK, и к Logstash прикручиваем исключения + метрики необходимые
Посоветуйте, как все это собрать во едино c минимумом затрат(время/финансы), возможно кто-то подскажет другой стек для данной задачи)
и да, сори за портяну текста...
пологаю с всеми вводными проще будет дать совет)
Выглядит так, словно тебе нужны error tracking и мониторинг с метриками. И, возможно, еще и логи.
Во-первых, зачем группировать логи? Задача логирования — это формирование потока сообщений, из которого можно понять, как происходила работа программы в более-менее штатном режиме. Здесь нужна только возможность делать запросы с фильтрами по определенным полям, и совершенно нечего агрегировать, т.к. в конечном итоге за логами приходят, когда нужно понять поведение системы в конкретном случае, а не за статистической информацией. То, что ты хочешь, больше похоже на error tracking с отловом нештатного поведения кода и дедупликацией одинаковых стектрейсов, но это совсем другая система, с логированием не связанная.
Для error tracking смотри в сторону sentry (других готовых self-hosted альтернатив нет).
Во-вторых, информация о нагрузке и, в принципе, о любых численных характеристиках — это предметная область системы работы с метриками, с которой логи, обычно, тоже почти никак не связаны (да, можно формировать метрики по логам, но лучше не надо). Мониторинг, обычно, тоже делается по метриками, т.к. формируются они на основе превышения каких-либо пороговых значений. Для этого есть несколько разных инструментов, в этом чате обычно обсуждают prometheus и alert-manager, но что лучше на твоих масштабах хз.
В-третьих, см. "во-первых" про sentry. И, да, не надо ловить эксепшены через логи.
Во-первых, зачем группировать логи? Задача логирования — это формирование потока сообщений, из которого можно понять, как происходила работа программы в более-менее штатном режиме. Здесь нужна только возможность делать запросы с фильтрами по определенным полям, и совершенно нечего агрегировать, т.к. в конечном итоге за логами приходят, когда нужно понять поведение системы в конкретном случае, а не за статистической информацией. То, что ты хочешь, больше похоже на error tracking с отловом нештатного поведения кода и дедупликацией одинаковых стектрейсов, но это совсем другая система, с логированием не связанная.
Для error tracking смотри в сторону sentry (других готовых self-hosted альтернатив нет).
Во-вторых, информация о нагрузке и, в принципе, о любых численных характеристиках — это предметная область системы работы с метриками, с которой логи, обычно, тоже почти никак не связаны (да, можно формировать метрики по логам, но лучше не надо). Мониторинг, обычно, тоже делается по метриками, т.к. формируются они на основе превышения каких-либо пороговых значений. Для этого есть несколько разных инструментов, в этом чате обычно обсуждают prometheus и alert-manager, но что лучше на твоих масштабах хз.
В-третьих, см. "во-первых" про sentry. И, да, не надо ловить эксепшены через логи.
дш
Alexander
Выглядит так, словно тебе нужны error tracking и мониторинг с метриками. И, возможно, еще и логи.
Во-первых, зачем группировать логи? Задача логирования — это формирование потока сообщений, из которого можно понять, как происходила работа программы в более-менее штатном режиме. Здесь нужна только возможность делать запросы с фильтрами по определенным полям, и совершенно нечего агрегировать, т.к. в конечном итоге за логами приходят, когда нужно понять поведение системы в конкретном случае, а не за статистической информацией. То, что ты хочешь, больше похоже на error tracking с отловом нештатного поведения кода и дедупликацией одинаковых стектрейсов, но это совсем другая система, с логированием не связанная.
Для error tracking смотри в сторону sentry (других готовых self-hosted альтернатив нет).
Во-вторых, информация о нагрузке и, в принципе, о любых численных характеристиках — это предметная область системы работы с метриками, с которой логи, обычно, тоже почти никак не связаны (да, можно формировать метрики по логам, но лучше не надо). Мониторинг, обычно, тоже делается по метриками, т.к. формируются они на основе превышения каких-либо пороговых значений. Для этого есть несколько разных инструментов, в этом чате обычно обсуждают prometheus и alert-manager, но что лучше на твоих масштабах хз.
В-третьих, см. "во-первых" про sentry. И, да, не надо ловить эксепшены через логи.
Во-первых, зачем группировать логи? Задача логирования — это формирование потока сообщений, из которого можно понять, как происходила работа программы в более-менее штатном режиме. Здесь нужна только возможность делать запросы с фильтрами по определенным полям, и совершенно нечего агрегировать, т.к. в конечном итоге за логами приходят, когда нужно понять поведение системы в конкретном случае, а не за статистической информацией. То, что ты хочешь, больше похоже на error tracking с отловом нештатного поведения кода и дедупликацией одинаковых стектрейсов, но это совсем другая система, с логированием не связанная.
Для error tracking смотри в сторону sentry (других готовых self-hosted альтернатив нет).
Во-вторых, информация о нагрузке и, в принципе, о любых численных характеристиках — это предметная область системы работы с метриками, с которой логи, обычно, тоже почти никак не связаны (да, можно формировать метрики по логам, но лучше не надо). Мониторинг, обычно, тоже делается по метриками, т.к. формируются они на основе превышения каких-либо пороговых значений. Для этого есть несколько разных инструментов, в этом чате обычно обсуждают prometheus и alert-manager, но что лучше на твоих масштабах хз.
В-третьих, см. "во-первых" про sentry. И, да, не надо ловить эксепшены через логи.
пардон логи группировать не требуется, группировка применима только к error tracking
A
пардон логи группировать не требуется, группировка применима только к error tracking
сентря это делает. Ложных срабатываний у нее пока этом месте я не замечал.
дш
Alexander
сентря это делает. Ложных срабатываний у нее пока этом месте я не замечал.
угу, тоесть волшебной палочки нет
логи, исключения и метрики это разные сферы с разными инструментами, верно понял?
логи, исключения и метрики это разные сферы с разными инструментами, верно понял?