Доброе утро!

Внедряем мониторинг и столкнулись с проблемой: не все устройства есть в DNS. Поэтому сложно понять какое устройство изображено на графике с легендой "10.123.15.8".  В связи с этим надумали все девайсы внести в DNS. И возникли вопросы.

1. Заводить ли отдельный DNS сервер или зону для этих целей?
2. Как защитить эти технические записи от перебора злоумышленниками?
3. Как автоматически регистрировать отдельные сервисы в домене? Понятно, что Linux может регистрировать с помощью Consul, а как быть с роутерами/коммутаторами?
4. Правильный ли подход мы выбрали?


Расскажите как у вас устроено именование устройств/ВМ/сервисов в сети?

1) да, зона, приватная
2) отвечать только определенным сетям
3) не знаю, не по dhcp же.
4) кто знает, но лучше иметь прямые и обратные зоны для железок, чем нет

1. да, зона, публичная
2. зачем? security through obscurity?
3. менеджмент днс встроен а процесс назначения имени и переналивки конкретной железяки, будь то свитч, роутер, сервер или ipmi
4. смотрите как вам удобнее же. днс не шибко хорошая вещь, если у вас часто изменяющиеся данные и нужна очень высокая достоверность и низкая задержка распространения изменений.

Может, я совсем не в ту сторону смотрю и DNS нужно заменить другими буквами?

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

Alert! One day Muase is a known spammer and is CAS banned. Ban is strongly recommended.

метрики из StatsD попадают в Графит, откуда их потом и запрашивает Графана, так что да, можно

Мы только-что запостили статью на хабре, о том как развивали свою систему мониторинга последние 2 года:
https://habr.com/ru/company/avito/blog/467995/

👍

интересует как раз, если пушить метрики не через statsd а напрямую в графит

да, я именно про это и говорю, так можно делать.

а чем же тогда агрегация происходит?
https://prnt.sc/pqijeb
есть такая кверя и оно понятно что через statsd агрегирование происходит
а если напрямую слать метрики в графит, например так:

echo "domain_status.$domains:1|ms" | nc -w 1 -u graphite_host 2003
echo "domain_status.$domains:0|ms" | nc -w 1 -u graphite_host 2003

то на основании чего выборку делать?Оо

echo "domain_status.$domains:1|ms" | nc -w 1 -u graphite_host 2003
echo "domain_status.$domains:0|ms" | nc -w 1 -u graphite_host 2003

В Графит нужно отправлять уже съагрегированные метрики. Если Вам нужна агрегация то отправляйте события в statsd, если агрегация не нужна, то отправляйте данные сразу в Графит. Так как речь идет об отправке метрик из ci/cd есть подозрение что она может быть не нужна.

и у Графита формат метрик другой:

echo "domain_status.$domains 1 $(date +%s)" | nc -w 1 graphite_host 2003

ну вероятно не нужно, я точно такой же формат метрик слал в statsd

echo "domain_status.$domains:1|ms"

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

> В результате мы имеем таблицу с 100% данных, реплицированных на все шесть серверов, которые обрабатывают всю читающую нагрузку от запросов с окном менее двух суток (а таких у нас 95%).

это дистрибьютед?

нет, дистрибьютед - это как раз шард, а это обычная ReplicatedGraphiteMergeTree()