Стандартизация и Conventions¶

Представьте библиотеку, где у каждой книги разный формат обложки, шрифт названия, цвет корешка. Можно ли найти нужную книгу? Можно. Но долго. А если все книги одного формата, на корешках автор и название — найти нужное можно даже с закрытыми глазами (ладно, с полузакрытыми, в 3 часа ночи).

Стандартизация дашбордов — это такой же подход к организации.

Правило именования дашбордов¶

[Команда]-[Система]-[Цель]-[Окружение]

Примеры:

sre - kubernetes - resource usage - production
dev - myapp - SLO - staging
dba - postgresql - overview - prod

По такому названию вы сразу видите, где искать информацию. И поиск по "production SLO" мгновенно находит то, что нужно.

Правила именования панелей¶

Имена панелей — это не технический нарратив, а понятный человеку ответ на вопрос. Примеры:

HTTP RPS — нет.
Request Rate per second — лучше.

Правило единообразия интервалов¶

Дашборды одной команды всех окружений должны выглядеть одинаково по layout'у. Пользователь, перешедший из Production в Staging, не должен переучиваться. Для этого:

Use dashboard links с параметрами (переключаешь окружение через переменную)
Или используйте Grafonnet (Jsonnet) для генерации.

Как в библиотеке: читатель знает, что "Романы А" всегда на левой полке, а "Учебники Б" — справа. Узнать новую книгу не нужно.

Layout conventions¶

Панели — minimum width, делённый на 24 (стандартная сетка Grafana).
Высота панели: 12 стандартных пикселей высоты для нормальной читаемости.
НЕ должно быть панелей с шириной 24 (на всю строчку) — слишком растянуто.

Document your dashboards¶

Дашборд должен иметь Description в настройках (General → Description) с пояснением: - Что содержит. - Кому предназначен. - Ссылку на runbook/связанный дашборд.

Далее: Тегирование дашбордов