Графана одна на все среды, но конкретное окружение можно выбрать при помощи переменной на дашборде
Пока такого процесса нет. Но автоматизация позволила существенно сократить человеческий фактор и вероятность ошибки. Пока покопим опыт так, потом подумаем требуется ли нам тестировать дашборды
Удаление сервиса сейчас не является у нас полностью автоматизированным процессом. Некоторые ресурсы освобождаются автоматизировано, некоторые нет. Есть чеклист со списком ресурсов, которые требуется освободить — среди них дашборды. Думаю со временем автоматизация и сюда придет
Да, у нас все микросервисы на одной платформе. Многие технические метрики пишутся именно платформой, и это во много позволило достичь стандартизации.
Но вариант с единым дашбордом с переключателем для всех микросервисов нам не подошёл, потому что набор панелей у нас отличается в зависимости от технического устройства микросервиса и типов API, которые он предоставляет. Например, у сервиса с публичным REST API и у сервиса, который внутри контура взаимодействует только через kafka, дашборды будут отличаться. Нам хочется видеть на дашборде только те панели, которые релевантны конкретному сервису.
Ещё на дашборд иногда добавляется ряд с "бизнесовыми" метриками (например, количество успешно заказанных карт). Мы стремимся к тому, чтобы у микросервиса была строго определённая роль с точки зрения бизнес логики. И если существует метрика, по которой видно, насколько хорошо он с этой ролью справляется, то мы добавляем для неё панель и алерты. Чтобы не перемешалось с техническими метриками, выносим "бизнесовые" в отдельный ряд.
В сумме это позволяет иметь дашборды которые могут ёмко передать всю ключевую информацию о состоянии сервиса. Но не даёт возможности сделать один единый дашборд с переключателем.
Привет!
Графана одна на все среды, но конкретное окружение можно выбрать при помощи переменной на дашборде
Пока такого процесса нет. Но автоматизация позволила существенно сократить человеческий фактор и вероятность ошибки. Пока покопим опыт так, потом подумаем требуется ли нам тестировать дашборды
Удаление сервиса сейчас не является у нас полностью автоматизированным процессом. Некоторые ресурсы освобождаются автоматизировано, некоторые нет. Есть чеклист со списком ресурсов, которые требуется освободить — среди них дашборды. Думаю со временем автоматизация и сюда придет
Привет! Спасибо за вопрос!
Да, у нас все микросервисы на одной платформе. Многие технические метрики пишутся именно платформой, и это во много позволило достичь стандартизации.
Но вариант с единым дашбордом с переключателем для всех микросервисов нам не подошёл, потому что набор панелей у нас отличается в зависимости от технического устройства микросервиса и типов API, которые он предоставляет. Например, у сервиса с публичным REST API и у сервиса, который внутри контура взаимодействует только через kafka, дашборды будут отличаться. Нам хочется видеть на дашборде только те панели, которые релевантны конкретному сервису.
Ещё на дашборд иногда добавляется ряд с "бизнесовыми" метриками (например, количество успешно заказанных карт). Мы стремимся к тому, чтобы у микросервиса была строго определённая роль с точки зрения бизнес логики. И если существует метрика, по которой видно, насколько хорошо он с этой ролью справляется, то мы добавляем для неё панель и алерты. Чтобы не перемешалось с техническими метриками, выносим "бизнесовые" в отдельный ряд.
В сумме это позволяет иметь дашборды которые могут ёмко передать всю ключевую информацию о состоянии сервиса. Но не даёт возможности сделать один единый дашборд с переключателем.
Без паники :-)