Так сделай так, чтобы тебе было удобно пользоваться.
Если у других 200 отдельных алертов — ты будешь делать 200 отдельных, потому что это бест практис?

Удобно неудобно вопрос такой.
Хотел бы понять как у других например: "мы вываливаем 200 алертов потому что " или наоборот.
просто не хочется велосипеды изобретать

Можно использовать зависимость триггеров или корреляцию (на примере именно заббикса, хз как в других системах это называется), если все махом "упали" — чтобы был один алерт, а если точечные вспышки — получать их

Я не понимаю, почему "сделать так, как удобно себе и коллегам" — это "изобретать велосипед"?
Типа, зачем тогда нужен ты (абстрактный инженер, на личный счёт не принимай)? Чтобы копипастить из интернетов?

А почему нет?
Мне нужно скопипастить сами принципы а не их техническую реализацию.

чистое имхо: копипаст и сбор вариантов решений для анализа и выработки своего - это разные вещи. человек пытается узнать кто и как решал схожую проблему

Принципы должны быть выстроены у тебя в компании

И описание потребностей от того же мониторинга

да. вот так точнее будет

Ну вот сейчас ему двое скажут:
1. Группировал
2. Не группировал
И что он выберет?

это прекрасно работать в таких компаниях, но есть и такие у которых их нет и говорят вот _ты_ и должен их нам изобрести )

мне нужно не просто группировал а почему группировал.

Без изучения best practices и архитектурных принципов как раз и получится копипаст из интернета решений, показавшихся хорошими, и постоянное разгребание собственноручно устроенного же бардака. Никто же не лезет в проектирование сложного ПО, не прочитав пару книг на эту тему, так и тут должно быть. Только книг таких по теме я не видел, так что плюсую вопрос )

У меня жизненный опыт и вебинары, семинары это best practices.

там часто объясняют как именно сделать то или другое. но мало где упоминается почему и зачем вообще это делается.

Возможно. Тогда только опыт. Ну вот к примеру. Как мониторить филиал через туннель. С одной стороны делаем как и везде, а с другой. Вам нужны все те алерты когда туннель сляжет. Уже задумаетесь делать зависимости или проксю.

особенно интересен опыт больших компаний.

1. Многое зависит от возможностей того инструмента, которым ты пользуешься.
2. Много зависит от реализации архитектуры сети/серверов/приложений.
3. Никто не читает книги, взяв готовый конттейнер заббикса/прометеуса, натянув его на свои реалии и закрыв задачу мониторинг.

Либо это будет вилами по воде писано, либо чьё-то однобокое мнение. Либо нужно под каждую архитектуру сети/серверов/приложений описывать бест практис. И опять же – там малейший чих и всё бьётся о скалы реальности.

Мне это напоминает исторю с тем, что некоторые внедряют процессы и флоу чисто ради того, чтобы они были. Реальных задач нет, но уже придумали процесс. А потом пытаются решить задачи в тех рамках, которые сами себе и навязали. И не могут сделать это быстро/эффективно.

нет в ИТ волшебного свода бест-практик
у каждого свой набор ограничений, условий, как технических, так и административных

Ну подождите. Есть же записи митапов. Там прям выступают люди внедрявшие мониторинг. И почти все рассказывают зачем они делали то или это. Это же первый вопрос который им зададут.