ограничений на уровне своей архитектуры
Эээ... я примерно про то же и говорю.
> если есть необходимость отправляй разные типы телеметрии в разные типы хранилищ
Спасибо за совет, но я как раз начал разговор с этой идеи.
> Аптайм сервера это телеметрия, а получишь ты эти данные 1 раз за секунду или 10000 или в каком виде и где они хранятся - это вообще про другое совсем.
Я вообще про разрешение метрик ничего не упоминал. При чем тут оно?
> а есть ли тут люди у которых уровень сбора, хранения, анализа, выполнения действий по событию и оповещения друг от друга изолированы достаточным уровнем абстракций для того что бы в любой момент можно было заменить один из компонентов или подключить новый
Это другой вопрос и я его не задавал.
> очень хороший пример довольно универсального хранилища - VictoriaMetrics
> The best long-term remote storage for Prometheus
В плане поддержки разных интерфейсов — да. В плане применения — нет. Виктория явно разрабатывается как хранилище архива телеметрии и ее применимость в качестве хранилища системы мониторинга сомнительна.
> Ну не похоже это на наброс и даже поспорить не о чем
Так и вопрос был не о том, какая архитектура правильная, а о том, кто в этом чате на нее забивает и жрет кактус, пытясь усадить на оба стула штуки, вроде, заббикса или прометеуса, которые подходят, в лучшем случае, только для решения задач системы мониторинга.
то-есть, все то, что не prometheus, есть хранилищем метрик? если не сложно, сделайте таблицу сравнения и опишите критерии сравнения, можно внести туда: prometheus vm icinga2 thanos Z ... и еще варианты, которые посчитаете необходимые, лучше в google docs и мы сразу раставим точки, а так можно флеймить постоянно
Обсуждают сегодня