Statsd - это, по сути, аккумулятор. Бросаете в него метрики, он из них, согласно настройкам, делает счётчик (суммирует все значения), датчик (отдает самое свежее), и т.п.
У этого механизма есть не упомянутая в документации особенность, которая может знатно попить крови - page_capacity должен быть строго меньше max_bytes (понятно, что больше делать неразумно, но даже равенство этих параметров не допускается).
Несоблюдение чревато внезапной остановкой обработки событий при внешнем отсутствии явных проблем.
Не упомянуты низкопрофильные, оптические, свитчи, ни слова о других производителях, кроме черри, затронуты только попсовые "цвета" переключателей.
Статья ради рекламы.
Для заинтересовавшихся - рекомендую ознакомиться с https://geekboards.ru/page/mechanical_switches_v2. Здесь разобрано много типов и производителей свитчей, от этого уже можно отталкиваться при дальнейшем выборе.
Вы не дочитали до конца)
Текущая статья — только о мониторинге. Логи, трейсы, детали реализации будут дальше.
Потом, возможно, попробуем в рамках другой статьи собрать всё в минимальный Observability.
К тому же, Instanta платная, а мы тут пробуем собрать решение на OpenSource.
Но тут очень тонкая грань проходит:
Есть метрики работоспособности бизнес-процессов — это «иженерный мониторинг». Тут задача состоит в обеспечении функционирования бизнеса.
А есть бизнес-метрики — данные о продажах, притоку/оттоку клиентов, графики выручки и прочее. Это зона BI-систем, и там специфическая кухня, о которой думают в первую очередь «продажники».
Вторую категорию я не рассматриваю — нет релевантного опыта.
Вы, конечно, правы в том, что несколько сотен метрик могут доставлять неудобство, но если такая ситуация возникла, значит у вас что-то не так с их организацией.
В вашем примере, как мне кажется, метрики портов можно группировать по номерам портов и вынести на отдельный дашборд.
К тому же, как уже заметили, заранее не предугадать, пригодится ли та или иная метрика, и когда, а потому, уж лучше пусть они будут. Тут как у самураев — если меч понадобится один раз, ты будешь носить его всю жизнь.
А с позицией по алертингу полностью согласен — только строгая организация, только тонкая настройка.
У инженеров не возникает трудностей в написании скриптов? Не бывает ситуаций, когда плохо написанный скрипт аффектит производительность?
Я одно время искал что-то подобное, но пришел к тому, что людям обычно лень писать скрипты, нужен гуй, особенно на этапе передачи проекта из развертывания в поддержку и сопровождение
> Работает предиктивная диагностика по иному принципу – математическая модель обучается не на отказах, а на правильной работе оборудования в различных режимах. Именно этой стратегии предсказания придерживаются, например, хозяева кошек: они не пытаются диагностировать, чем именно заболело животное, а просто подмечают, что оно ведёт себя не как обычно. То есть что модель нормального кота не работает. И это позволяет понять, что есть какая-то проблема.
Очень простая, но совершенно неочевидная идея, спасибо!
Применимо к любому мониторингу, пожалуй
Надо обдумать в своем контексте
Относительно закрытия в другом потоке — кейс из реальности: поднимается хттп-сервер, к которому цепляются хендлеры с состоянием.
Состояние читается из конфигурации, количество хендлеров зависит только от того, что в конфиге наворотит юзер.
Далее, запускается дежурная горутина, которая по сигналу перебирает срез указателей на структуры (через Closer) и закрывает их, чтобы выполнить gracefull shutdown.
Как в этом случае красиво передать пачку деструкторов?
Можно сделать срез с функциями, конечно, но если дежурная горутина берется из другой либы и ожидает Closer, придется делать обёртку
Интересный подход, спасибо за статью
Попробую немножко покритиковать — имхо, описанный подход слабо жизнеспособен
Дело в чем — если жизненный цикл объекта ограничивается одной областью, то шанс забыть вызвать .Close() стремится к нулю (наплодили объектов, поработали, закрыли).
Если же объект у нас долгоживущий и, как бывает почти всегда, закрывается в какой-нибудь дежурной горутине, тогда, при наличии отвязанной от структуры функции освобождения ресурсов, начинается свистопляска с передачей деструктора (а то и целой пачки).
Привязанная к структуре функция, как ни крути, выходит более простым и не менее надёжным решением.
Плюс, как отметили выше, имплементация Closer идиоматична, значит, такой объект можно использовать и закрывать где угодно, просто обратившись по интерфейсу
Впрочем, это только имхо, буду рад подискутировать!..
Жаль, что не упомянули ILM в части ротации логов, а ведь он хорошо помогает решить проблему баланса между производительностью/потреблением ресурсов эластика и длительностью хранения данных.
По прошествии, например, двух недель пусть индекс переходит в холодную фазу и спокойно лежит на диске, не занимая память — удобно, когда логи необходимо хранить длительное время.
Сравнение эффективности сжатия, которое вы приводите, не имеет веса без демонстрации шаблона индекса, в который эластик складывает данные. Если у вас каждый ключ индексируется в два поля (text и keyword), тогда не удивительно, что данные занимают больше места.
От эластика можно легко добиться того же (или очень близкого) результата, если выносить смысловую часть записи в ключ с типом text, а остальное индексировать только как keyword.
А Локи предлагает что-то сопоставимое с функционалом Logstash? Если да, было бы интересно опробовать.
Увы, порой встречается такое, что можно провалиться в regex hell, и спасает только фильтр на ruby…
Побуду адвокатом InfluxData, не согласен с некоторыми вашими претензиями:
"Периодически выкатывают фичи непонятно зачем сделанные, например сделали ifql (Flux)" — флюкс есть естественная попытка реализовать язык более функциональный, чем изначально слабый и топорный IQL, к которому накопился просто вагон претензий. Получилось хорошо
"или CQ" — CQ вполне себе хороший инструмент для контроля за устареванием метрик. Подходящее решение для случаев, когда нет необходимости детально исследовать данные полугодичной данности, но оценить весь период целиком нужно (рассчитать аптайм СЛА, к примеру)
"или хронограф" — вендор старается поставлять самодостаточный стек, вот и всё. Да и хронограф позиционируется не столько как визуализатор, сколько как веб-гуй для админки стека целиком, так делает много кто. Не будете же вы выдвигать претензию в сторону ELK за то, что у них есть кибана?
"в телеграфе ломали поддержку Прометея" — как и в любом софте, появился баг, баг пофиксили. Нет идеального ПО
"невозможность оверрайдить RP в кафке" — вот тут могу ошибаться, так как не приходилось гонять метрики через кафку, но в вашей цепочке разве не конечный телеграф определяет RP и базу для записи?
"частые Breaking Changes" — чисто субъективно, больше пяти лет с последнего — это нормально, до полноценного релиза InfluxDB 2.0 ещё как до луны, а первую версию никто не бросает в подвал для легаси
А вот с претензиями к производительности и стабильности соглашусь, это прям беда. По запросу "influxdb out of memory" гуглится issue, которому уже скоро годик должен исполниться, вроде, а воз и ныне там.
В общем, не будьте столь категоричны, TICK имеет право на жизнь.
Прекрасная статья, спасибо!
Отмечу следующее — в который уже раз встречаю утверждение "Графана не умеет вычисления между измерениями", но ведь дело тут не в графане!
Объясню по порядку (защищу графану :))
Во-первых, возможность вести вычисления между сериями данных это заслуга использования движка запросов Flux, а не Kapacitor. Дефолтный язык запросов InfluxDB в межсерийные вычисления не умеет, с чем вы и столкнулись при работе с графаной (для работы с Flux есть плагин, но он ещё сырой).
Из этого следует второе — визуализатор/алерт менеджер ограничен только возможностями при запросов, который предоставляет источник данных. Пример — если использовать в качестве источника Elasticsearch (коим я для целей хранения данных мониторинга пользуюсь уже давно, а вам советую попробовать), внезапно, возможность вычислений между сериями появляется, т.к. её предоставляет ES search api — https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-pipeline-bucket-script-aggregation.html
Из минусов относительно InfluxDB — по-умолчанию в Elasticsearch не включен Index lifecycle management (нечто близкое к retention policy), эту вещь нужно настраивать ручками, но это не сложно.
Поработайте с эластиком в связке с графаной, очень мощный получается инструмент.
Statsd - это, по сути, аккумулятор. Бросаете в него метрики, он из них, согласно настройкам, делает счётчик (суммирует все значения), датчик (отдает самое свежее), и т.п.
По поводу persisted queue на Logstash
У этого механизма есть не упомянутая в документации особенность, которая может знатно попить крови - page_capacity должен быть строго меньше max_bytes (понятно, что больше делать неразумно, но даже равенство этих параметров не допускается).
Несоблюдение чревато внезапной остановкой обработки событий при внешнем отсутствии явных проблем.
Мало, мало информации.
Не упомянуты низкопрофильные, оптические, свитчи, ни слова о других производителях, кроме черри, затронуты только попсовые "цвета" переключателей.
Статья ради рекламы.
Для заинтересовавшихся - рекомендую ознакомиться с https://geekboards.ru/page/mechanical_switches_v2. Здесь разобрано много типов и производителей свитчей, от этого уже можно отталкиваться при дальнейшем выборе.
Текущая статья — только о мониторинге. Логи, трейсы, детали реализации будут дальше.
Потом, возможно, попробуем в рамках другой статьи собрать всё в минимальный Observability.
К тому же, Instanta платная, а мы тут пробуем собрать решение на OpenSource.
Но тут очень тонкая грань проходит:
Есть метрики работоспособности бизнес-процессов — это «иженерный мониторинг». Тут задача состоит в обеспечении функционирования бизнеса.
А есть бизнес-метрики — данные о продажах, притоку/оттоку клиентов, графики выручки и прочее. Это зона BI-систем, и там специфическая кухня, о которой думают в первую очередь «продажники».
Вторую категорию я не рассматриваю — нет релевантного опыта.
Но вы правы, тема не раскрыта, постараюсь затронуть её в дальнейшем
В вашем примере, как мне кажется, метрики портов можно группировать по номерам портов и вынести на отдельный дашборд.
К тому же, как уже заметили, заранее не предугадать, пригодится ли та или иная метрика, и когда, а потому, уж лучше пусть они будут. Тут как у самураев — если меч понадобится один раз, ты будешь носить его всю жизнь.
А с позицией по алертингу полностью согласен — только строгая организация, только тонкая настройка.
У инженеров не возникает трудностей в написании скриптов? Не бывает ситуаций, когда плохо написанный скрипт аффектит производительность?
Я одно время искал что-то подобное, но пришел к тому, что людям обычно лень писать скрипты, нужен гуй, особенно на этапе передачи проекта из развертывания в поддержку и сопровождение
Очень простая, но совершенно неочевидная идея, спасибо!
Применимо к любому мониторингу, пожалуй
Надо обдумать в своем контексте
Благодарю за пример, идея стала яснее
Относительно закрытия в другом потоке — кейс из реальности: поднимается хттп-сервер, к которому цепляются хендлеры с состоянием.
Состояние читается из конфигурации, количество хендлеров зависит только от того, что в конфиге наворотит юзер.
Далее, запускается дежурная горутина, которая по сигналу перебирает срез указателей на структуры (через Closer) и закрывает их, чтобы выполнить gracefull shutdown.
Как в этом случае красиво передать пачку деструкторов?
Можно сделать срез с функциями, конечно, но если дежурная горутина берется из другой либы и ожидает Closer, придется делать обёртку
Попробую немножко покритиковать — имхо, описанный подход слабо жизнеспособен
Дело в чем — если жизненный цикл объекта ограничивается одной областью, то шанс забыть вызвать .Close() стремится к нулю (наплодили объектов, поработали, закрыли).
Если же объект у нас долгоживущий и, как бывает почти всегда, закрывается в какой-нибудь дежурной горутине, тогда, при наличии отвязанной от структуры функции освобождения ресурсов, начинается свистопляска с передачей деструктора (а то и целой пачки).
Привязанная к структуре функция, как ни крути, выходит более простым и не менее надёжным решением.
Плюс, как отметили выше, имплементация Closer идиоматична, значит, такой объект можно использовать и закрывать где угодно, просто обратившись по интерфейсу
Впрочем, это только имхо, буду рад подискутировать!..
Жаль, что не упомянули ILM в части ротации логов, а ведь он хорошо помогает решить проблему баланса между производительностью/потреблением ресурсов эластика и длительностью хранения данных.
По прошествии, например, двух недель пусть индекс переходит в холодную фазу и спокойно лежит на диске, не занимая память — удобно, когда логи необходимо хранить длительное время.
От эластика можно легко добиться того же (или очень близкого) результата, если выносить смысловую часть записи в ключ с типом text, а остальное индексировать только как keyword.
А Локи предлагает что-то сопоставимое с функционалом Logstash? Если да, было бы интересно опробовать.
Увы, порой встречается такое, что можно провалиться в regex hell, и спасает только фильтр на ruby…
Побуду адвокатом InfluxData, не согласен с некоторыми вашими претензиями:
А вот с претензиями к производительности и стабильности соглашусь, это прям беда. По запросу "influxdb out of memory" гуглится issue, которому уже скоро годик должен исполниться, вроде, а воз и ныне там.
В общем, не будьте столь категоричны, TICK имеет право на жизнь.
Прекрасная статья, спасибо!
Отмечу следующее — в который уже раз встречаю утверждение "Графана не умеет вычисления между измерениями", но ведь дело тут не в графане!
Объясню по порядку (защищу графану :))
Во-первых, возможность вести вычисления между сериями данных это заслуга использования движка запросов Flux, а не Kapacitor. Дефолтный язык запросов InfluxDB в межсерийные вычисления не умеет, с чем вы и столкнулись при работе с графаной (для работы с Flux есть плагин, но он ещё сырой).
Из этого следует второе — визуализатор/алерт менеджер ограничен только возможностями при запросов, который предоставляет источник данных. Пример — если использовать в качестве источника Elasticsearch (коим я для целей хранения данных мониторинга пользуюсь уже давно, а вам советую попробовать), внезапно, возможность вычислений между сериями появляется, т.к. её предоставляет ES search api — https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-pipeline-bucket-script-aggregation.html
Из минусов относительно InfluxDB — по-умолчанию в Elasticsearch не включен Index lifecycle management (нечто близкое к retention policy), эту вещь нужно настраивать ручками, но это не сложно.
Поработайте с эластиком в связке с графаной, очень мощный получается инструмент.