Я совсем не программист, но нужна была похожая реализация для мониторинга большого количества устройств со сбором дополнительной статистики. Сделал используя библиотеку pro-bing и основная проблема в том, что запуская сотни горутин на слабом железе, мы получаем RTT и stddev отличающийся от обычного одиночного пинга на десятки миллисекунд, что иногда критично и выглядит не сильно красиво. Я так понимаю, что это происходит из-за реализации подсчета RTT через time.Since и времени на переключение контекста между разными горутинами. Тестировали ли вы этот момент? Как можно оптимизировать это и получать RTT близкий к одиночному пингу не закидывая все железом с большим количеством CPU?
Loki интексирует метаданные и лейбы, используя тот же promtail для отправки логов, можно их парсить и необходимую информацию выносить в лейбы, увеличивая скорость поиска по ним, но тут надо помнить о кардинальности. Loki не сильно любит high cardinality.
Второй момент, это querier инстансы, которые могут скейлится горизонтально и вычитывать чанки с логами параллельно, ускоряя поиск.
Касательно проверки сертификатов, можно посмотреть в сторону zabbix_agent2 с ключом web.certificate.get + стандартный шаблон (https://www.zabbix.com/integrations/ssl) Еще интересно почему была выбрана реализация создания хостов/метрик/триггеров через API, а не через Discovery и host/items/trigger prototypes? Скрипт можно запускать через external check вместо cron, для мониторинга выполнения и конфигурации расписания из одной точки. А так, интересная реализация, хотя кажется немного усложненной
Я совсем не программист, но нужна была похожая реализация для мониторинга большого количества устройств со сбором дополнительной статистики. Сделал используя библиотеку pro-bing и основная проблема в том, что запуская сотни горутин на слабом железе, мы получаем RTT и stddev отличающийся от обычного одиночного пинга на десятки миллисекунд, что иногда критично и выглядит не сильно красиво. Я так понимаю, что это происходит из-за реализации подсчета RTT через time.Since и времени на переключение контекста между разными горутинами. Тестировали ли вы этот момент?
Как можно оптимизировать это и получать RTT близкий к одиночному пингу не закидывая все железом с большим количеством CPU?
Loki интексирует метаданные и лейбы, используя тот же promtail для отправки логов, можно их парсить и необходимую информацию выносить в лейбы, увеличивая скорость поиска по ним, но тут надо помнить о кардинальности. Loki не сильно любит high cardinality.
Второй момент, это querier инстансы, которые могут скейлится горизонтально и вычитывать чанки с логами параллельно, ускоряя поиск.
Вот здесь хорошо описаны эти моменты:
https://grafana.com/blog/2023/12/20/the-concise-guide-to-grafana-loki-everything-you-need-to-know-about-labels/?utm_source=grafana_news&utm_medium=rss
https://grafana.com/blog/2023/12/28/the-concise-guide-to-loki-how-to-get-the-most-out-of-your-query-performance/?utm_source=grafana_news&utm_medium=rss
Касательно проверки сертификатов, можно посмотреть в сторону zabbix_agent2 с ключом web.certificate.get + стандартный шаблон (https://www.zabbix.com/integrations/ssl)
Еще интересно почему была выбрана реализация создания хостов/метрик/триггеров через API, а не через Discovery и host/items/trigger prototypes?
Скрипт можно запускать через external check вместо cron, для мониторинга выполнения и конфигурации расписания из одной точки.
А так, интересная реализация, хотя кажется немного усложненной