да,на этом месте с телеграфом тк коллега не захотел в экспортеры

ок как вы собираете конфиги телеграфа чтобы сразу все мониторить?

ansible

не в ручную я надеюсь(я счас частично автоматизировала часть вещей)

вы вносите в какой-то hostvars переменные которыми определяете что именно мониторить хотите?

да

telegraf_plugins_extra:
  memcached:
    config:
      - servers = ["localhost:11211"]
  phpfpm:
    config:
      - urls = ["fcgi://localhost:7000/fpm-status"]
  elasticsearch:
    config:
      - servers = ["http://localhost:9200"]
      - cluster_health = true
      - cluster_health_level = "indices"
      - cluster_stats = true
      - indices_include = ["_all"]
      - tagexclude = ["node_id»]

ну и тд

group_vars только

telegraf_plugins_extra:
  memcached:
    config:
      - servers = ["localhost:11211"]
  phpfpm:
    config:
      - urls = ["fcgi://localhost:7000/fpm-status"]
  elasticsearch:
    config:
      - servers = ["http://localhost:9200"]
      - cluster_health = true
      - cluster_health_level = "indices"
      - cluster_stats = true
      - indices_include = ["_all"]
      - tagexclude = ["node_id»]

ну ок

TL:DR

Для управления триггерами и нотификациями как кодом, мы использованием подходы завязанные на CI/CD. А именно:
У нас есть декларативное описание триггеров и нотификаций который называется alert.yaml. Мы храним эти alert.yaml в гите, и раскатываем описанные в них триггеры и нотификации через Teamcity, используя самописную-обертку "alert-autoconf" над moira-client(opensource) .  
Для сервисов - в момент генерации нового сервиса мы создаем alert.yaml, с базовым набором триггеров, и подкладываем его в репу этого нового сервиса. Так же в момент генерации сервиса создается сборка этого сервиса и выкатка его в Teamcity, где одним из шагов является выкатка содержимого alert.yaml в Мойру. Все подписки создаваемые таким образом принадлежат системному пользователю, и если кто-то решит уволиться, то его алерты не уволятся вместе с ним.
Для инфраструктурных команд - где у ребят нет каких-то выделенных сервисов: Для таких команд мы подготовили отдельный репозиторий  Alerting, и в нем организовали структуру хранения alert.yaml:
$team/[$service,$system,$any]/alert.yaml, и на все эти alert.yaml создаем отдельные сборки в Teamcity, которые следят за изменениями в директориях этих файлов. При получении PR с изменением какого-то файла, стартует авто-тестирование  этого alert.yaml. после чего изменения можно будет вмержить. После мержа, запускается выкатка содержимого alert.yaml в прод.

"alert-autoconf" - мы возможно в скором времени заопенсорсим.

если есть вопросы можете писать.

По-моему подобное можно было бы попробовать реализовать и для алерт-менеджера. Кто его использует расскажите это так или нет

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

ClickHouse/ClickHouse tagged: v20.5.2.7-stable
Link: https://github.com/ClickHouse/ClickHouse/releases/tag/v20.5.2.7-stable
Release notes:

v20.5.2.7-stable

Тут ребята стримят разбор нашей имплементации statsd : https://youtu.be/VioGYjJqGP0

Странные ребята какие-то

чем странные? умеют в го лучше вас?  😂

Я в го вообще не умею 😁

Странные тем, что они к эфирам не готовятся. Кажется, они только что узнали, что такое протокол statsd

эм