вместо того чтобы сказать "в пизду этот ваш карбон, я пойду и напишу свою TSDB для нашей команды" Рома и ко нахуярили го-карбон, а потом протолкали его в остальные команды.

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

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

но графит остался графитом. и ваш графит даже мы использовать начали в определенный момент.

это именно как раз пример того что в одной команде создали альтернативное решение. и оно эволюционно победило остальные

(а потом еще раз создали и теперь всех побеждает графит на КХ) ?

(а потом еще раз создали и теперь всех побеждает графит на КХ) ?

и это все еще графит. и когда кому-то нужно напихать куда-то точки - оно уже есть и им уже можно пользоваться.

но кроме одного графита я знаю штуки четыре инсталляции OpenTSDB, например. слабо поддерживаемые, никому не нужные, на полудохлом железе, постоянно ломающиеся (времени-то даже на их администрирование нет).

(возможно их уже нет, я давно не там, увы)

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

ещё и на другом языке

который до этого в компании вообще никто не использовал

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

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

Вот как важно чтобы был архитектор Матрицы :) всем ку в чатике.

Да уж как то писсиместично

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

Есть и другая крайность, когда на большую контору есть Мониторинг, там, Хранилище Картинок, Система Деплоя, и другие неподъёмные глыбы, в которые впилить что-то внезапно понадобившееся какой-то команде ооочень долго и сложно.

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

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

А не приведёт ли это к тому, что через некоторое время хранилищ будет штук пять разных?

А не приведёт ли это к тому, что через некоторое время хранилищ будет штук пять разных?

точно!

выше, если что, был сарказм.

А, ну да)

Ну то есть решение в том, чтобы внутри компании строить своё подобие амазона?

Ну то есть решение в том, чтобы внутри компании строить своё подобие амазона?

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

Да, ограничения иногда весьма позитивны

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

Принцип Конвея и все. Ты не можешь сделать никакой проект, который не повторяет структуру компани

Принцип Конвея и все. Ты не можешь сделать никакой проект, который не повторяет структуру компани

that's true

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

@researcher_kot будет жить. Поприветствуем!

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

можно. таблицу по up

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

У себя так и сделал. Сгенерил табличку по таргетам

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

Можно

спасибо всем, пошёл курить дальше гугл

а можете подсказать какой гуйд, как правильно в графане запрос писать в query, а то туплю как его писать

Запросы в графане это запросы прома

спасибо, тогда пойду доку прома почитаю ещё раз, а то видимо невнимательно читал

а можете подсказать какой гуйд, как правильно в графане запрос писать в query, а то туплю как его писать

probe_success{job="your job"} в табличку выведет всё что есть

column styles останется только подкрутить

спасибо

где probe_success - имя метрики, соответственно

@Timofmax будет жить. Поприветствуем!

всем привет, а где меня приветствия ?

всем привет, а где меня приветствия ?

приветик)))))))) какими судьбами?)))))))))

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

им *промом

ты всегда можешь попробовать

это точно, очень интересен он, уже читаю параллельно. интересует бест практис

просто кругом про пром и как круто он сервисы мониторит

я аж в растерянности

ну я на прошлой работе делал снятие метрик по SNMP и пинговалку

ну я на прошлой работе делал снятие метрик по SNMP и пинговалку

аяаяаяаяй

для SNMP прометей не очень

но там проблема скорее в SNMP, чем в прометее

для SNMP прометей не очень

а что будет не очень? ?

ну и карту не так чтобы удобно строить

а что будет не очень? ?

ответившего забанят

шутка местная штоле

а что будет не очень? ?

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

название забыл опять

noc project вроде

шутка местная штоле

чо шутка-то, ты правила в описании канала читал, прежде чем заджойниться?

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

мониторить и снимать метрики - это несколько разных задач. мониторить можно и заббиксом.

мониторить и снимать метрики - это несколько разных задач. мониторить можно и заббиксом.

смотреть на загрузку тунеля это мониторинг или снятие метрики?

да

что да)

смотреть на загрузку тунеля это мониторинг или снятие метрики?

смотреть загрузку туннеля - это сбор метрик состояние туннеля - мониторинг

состояние тоже можно считать метрикой

а доступность по пингу - мониторинг строго)

доступность есть - 1, доступности нет - 0

состояние тоже можно считать метрикой

да, вполне, или результатом проверок нескольких метрик за предыдущие 5 минут

Тимон ставь cacti и оставь zabbix))))))))))))) все будет чикипуки

если железок не много, то cacti даже будет успевать

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

Совсем грустно. Лучше возьми Nocproject

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

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

зависит от количества объектов в мониторинге.

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

попробовать можно, но делать так не нужно

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

noc, opennms

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

меня привлекает что у прома есть хуки для алертменеджера по уведомленнию в Teams

но ты конечно всегда можешь сделать эти инструменты

мы с cacti съехали на librenms. Зависимость есть

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

он же умеет в snmp?

кто?

пром

прометей поддерживает только один формат метрик - свой собственный