Один коміт, а не десяток тематичних, свідомо: теми переплетені в
спільних файлах (store.go, docker-compose.yml, deploy/README.md), і
розділити їх можна було б лише індексуванням шматків. Коміти, які не
збираються, гірші за один великий — тим паче що це рівно той стан, який
перевірявся разом.
ЩО ПРАЦЮЄ НА СТЕНДІ Й ПЕРЕВІРЕНО ТАМ
0058 подієві алерти: syslog, ncm, compliance спрацьовують у мить
події; правило з нереалізованим джерелом більше не зберігається
мовчки
0059 snmp.walk і прототипи шаблонів — таблиці з динамічним індексом
описуються шаблоном, а не Go
0060 відкат конфігу: план як різниця, маскування паролів із підписом
плану, обов'язковий контрольний збір, verifying при обриві
0061 кнопки Telegram: довге опитування, авторизація не з callback_data
0062 аудит і архів хостів; тест на AST, що падає на ключі без назви
0063 RLS: три ролі, окремий пул для фонових тактів
0064 строки зберігання даних і сторінка сховища
0065 приймач SNMP-трапів; перевірено справжніми пакетами по дроту,
переклад v1→v2 за RFC 3584 дає правильний OID
0066 ескалації сповіщень
0067 алерт про вичерпання диска
0068 поля заливки конфігу переїхали в каталог профілів
Плюс: 137 тестів вебу з нуля (їх не було взагалі), одинадцять справжніх
вад, знайдених ними й виправлених, і виправлення двох інтеграційних
тестів grpcapi, які мовчки пропускались півтора року.
ЩО ЩЕ НЕ ЗАПУСКАЛОСЬ
netpulse установник: одна команда замість 18 змінних і
593 рядків інструкції
RLS з першого запуску нова інсталяція під політиками одразу;
RLS-EXISTING-INSTALL.md лишається тільки для
старих інсталяцій
.forgejo + CI раннер не зареєстрований
Ці три перевірені компіляцією й міркуванням, але не виконанням.
ГОЛОВНИЙ ВИСНОВОК ДВОХ СЕСІЙ
Зелена перевірка доводить рівно те, що вона перевіряє. Тест ізоляції RLS
був правильний і зелений — і пропустив зламаний вхід, бо перевіряв «чи
не видно чужого», коли зламалось «чи видно своє». Інтеграційні тести
grpcapi були зелені, бо не виконувались. Схема, довідник і протокол
описували те, чого в коді не існувало, і виглядало це як готове.
Тому в кожному завданні цих сесій стояла вимога назвати НЕПОКРИТЕ, а
чотири задачі закінчились не можливістю, а відмовою: правило з
нереалізованим джерелом не зберігається, профіль без команд заливки
каже про це замість мовчазної кнопки, міграція RLS валить сама себе на
таблиці без політики, тест словника аудиту падає на ключі без назви.
Подробиці — HISTORY.md, розділи за 26 і 27 серпня.
172 lines
8.9 KiB
Go
172 lines
8.9 KiB
Go
package store
|
||
|
||
import (
|
||
"context"
|
||
"fmt"
|
||
"time"
|
||
|
||
"github.com/jackc/pgx/v5"
|
||
)
|
||
|
||
// Добір хостів для сторінки «Метрики».
|
||
//
|
||
// Навіщо окремий добір. Сторінка досі вивантажувала весь інвентар і
|
||
// клала його в один `<select>`. На шести хостах це працює; на тисячі це
|
||
// список на тисячу рядків без пошуку — тобто спосіб не знайти хост.
|
||
//
|
||
// Фільтр — той самий DeviceFilter, що в «Командах», масових діях і
|
||
// «Конфігах». Четверта сторінка з власними поняттями означала б, що
|
||
// людина, яка навчилась відбирати хости в трьох місцях, вчить їх заново
|
||
// в четвертому. Умова теж та сама — deviceFilterSQL.
|
||
//
|
||
// Власне поняття рівно одне (Data), і воно, як і стан архіву в
|
||
// ConfigFilter, не має сенсу ніде більше: питання «у кого взагалі є що
|
||
// малювати» ставлять на цій сторінці й тільки на ній.
|
||
|
||
// MetricsFilter — спільний фільтр хостів плюс одне питання про дані.
|
||
type MetricsFilter struct {
|
||
DeviceFilter
|
||
|
||
// Data — чи є в хоста ряди метрик. Перелік, а не одне значення, і
|
||
// тлумачиться як АБО — так само, як виробник чи тип у спільній
|
||
// частині.
|
||
//
|
||
// Два значення ділять хости без залишку й без жодного порога.
|
||
// Порога тут навмисно немає: «мовчить понад добу» на рівні ХОСТА
|
||
// збрехало б рівно на найважливішому випадку зі стенда — у
|
||
// JUN.QFX-Миронівка 196 рядів портів стоять із учора, а icmp
|
||
// приходить щохвилини. Хост живий, майже всі його ряди — ні, і
|
||
// звести це до одного прапорця не можна. Тому питання «живий чи
|
||
// мертвий» ставиться до РЯДУ й живе там, де на нього є чим
|
||
// відповісти, — у переліку рядів хоста (device_detail.go).
|
||
Data []string `json:"data,omitempty"`
|
||
}
|
||
|
||
// Значення MetricsFilter.Data.
|
||
const (
|
||
// MetricsDataAny — є хоч один ряд: хост можна відкрити й побачити графік.
|
||
MetricsDataAny = "any"
|
||
// MetricsDataNone — жодного ряду: хост відкривати марно.
|
||
//
|
||
// Потрібне не заради симетрії. Порожня сторінка метрик — типова
|
||
// скарга («чому тут нічого»), і відповідь на неї — це перелік саме
|
||
// таких хостів: їх або щойно завели, або з них нічого не збирають.
|
||
MetricsDataNone = "none"
|
||
)
|
||
|
||
// MetricDeviceRow — хост у переліку сторінки «Метрики».
|
||
//
|
||
// Числа їдуть разом із хостом, а не добираються запитом на кожен
|
||
// клікнутий рядок: питання «у кого тут взагалі є дані» ставлять до
|
||
// всього переліку одразу.
|
||
type MetricDeviceRow struct {
|
||
DeviceID string `json:"device_id"`
|
||
Name string `json:"name"`
|
||
Address string `json:"address,omitempty"`
|
||
Kind string `json:"kind"`
|
||
Vendor string `json:"vendor,omitempty"`
|
||
Model string `json:"model,omitempty"`
|
||
SiteName string `json:"site_name,omitempty"`
|
||
Status string `json:"status"`
|
||
Enabled bool `json:"enabled"`
|
||
|
||
// Series — скільки рядів у хоста.
|
||
Series int `json:"series"`
|
||
// Keys — скільки з них РІЗНИХ метрик.
|
||
//
|
||
// Друге число пояснює перше: «200 рядів» лякає, «200 рядів · 6
|
||
// метрик» одразу каже, що це шість вимірів, повторених по портах, —
|
||
// тобто рівно те, як їх показує перелік рядів.
|
||
Keys int `json:"keys"`
|
||
// LastAt — коли в цей хост востаннє прийшло хоч якесь значення.
|
||
//
|
||
// Факт, а не висновок: жодного порога «свіжий/застарілий» тут не
|
||
// рахується. Поріг залежить від інтервалу перевірки, а інтервал
|
||
// стосується ряду, а не хоста.
|
||
LastAt *time.Time `json:"last_at,omitempty"`
|
||
}
|
||
|
||
// ListMetricDevices — хости для сторінки метрик за спільним фільтром.
|
||
//
|
||
// Відбір робить запит, а не браузер: на парку в кілька тисяч хостів
|
||
// фільтрація в пам'яті означає вивантажити весь інвентар і зробити це
|
||
// знову на кожну натиснуту літеру.
|
||
//
|
||
// Межі — Readable, а не Writable: тут дивляться графіки, а не міняють
|
||
// залізо.
|
||
func (s *Store) ListMetricDevices(ctx context.Context, tenantID string,
|
||
sc Scope, f MetricsFilter) ([]MetricDeviceRow, error) {
|
||
|
||
sql, args := metricDevicesSQL(tenantID, sc, f)
|
||
|
||
var out []MetricDeviceRow
|
||
err := s.InTenantTx(ctx, tenantID, func(tx pgx.Tx) error {
|
||
rows, err := tx.Query(ctx, sql, args...)
|
||
if err != nil {
|
||
return err
|
||
}
|
||
defer rows.Close()
|
||
for rows.Next() {
|
||
var r MetricDeviceRow
|
||
if err := rows.Scan(&r.DeviceID, &r.Name, &r.Address, &r.Kind,
|
||
&r.Vendor, &r.Model, &r.SiteName, &r.Status, &r.Enabled,
|
||
&r.Series, &r.Keys, &r.LastAt); err != nil {
|
||
return err
|
||
}
|
||
out = append(out, r)
|
||
}
|
||
return rows.Err()
|
||
})
|
||
return out, err
|
||
}
|
||
|
||
// metricDevicesSQL складає запит окремо від виконання — з тієї ж
|
||
// причини, що й configDevicesSQL: умова збирається рядками з
|
||
// плейсхолдерів, що нумеруються від зміщення, і перевірити таку збірку
|
||
// без бази можна лише подивившись на готовий текст.
|
||
func metricDevicesSQL(tenantID string, sc Scope, f MetricsFilter) (string, []any) {
|
||
cond, condArgs := deviceFilterSQL(f.DeviceFilter, 4)
|
||
// Власний параметр стає після спільних; deviceFilterArgs існує саме
|
||
// для того, щоб не рахувати $-и очима після кожної правки фільтра.
|
||
own := 4 + deviceFilterArgs
|
||
|
||
args := append([]any{tenantID, sc.Unrestricted, nonNilIDs(sc.Readable)}, condArgs...)
|
||
args = append(args, nonNilIDs(f.Data))
|
||
|
||
// Підсумок по рядах — один LATERAL на хост, а всередині нього один
|
||
// індексний доторк на ряд (ORDER BY ts DESC LIMIT 1 по
|
||
// samples_series_ts_idx). Заміряно на стенді: 6 хостів, 489 рядів —
|
||
// 2.75 мс, тобто близько 6 мкс на ряд, і росте воно з кількістю
|
||
// РЯДІВ, а не з обсягом історії.
|
||
//
|
||
// Дешевшого способу дізнатись «коли востаннє щось прийшло» немає:
|
||
// у ts.series такого стовпця нема, а max(ts) через з'єднання з
|
||
// ts.samples без LIMIT 1 читає гіпертаблицю цілком.
|
||
return fmt.Sprintf(`
|
||
SELECT d.id::text, d.name, COALESCE(host(d.address),''), d.kind::text,
|
||
COALESCE(d.vendor,''), COALESCE(d.model,''), COALESCE(st.name,''),
|
||
d.status::text, d.enabled,
|
||
COALESCE(ss.n, 0), COALESCE(ss.keys, 0), ss.last_at
|
||
FROM inv.devices d
|
||
LEFT JOIN inv.sites st ON st.id = d.site_id
|
||
LEFT JOIN LATERAL (
|
||
SELECT count(*) AS n,
|
||
count(DISTINCT s.metric_key) AS keys,
|
||
max(l.ts) AS last_at
|
||
FROM ts.series s
|
||
LEFT JOIN LATERAL (
|
||
SELECT m.ts FROM ts.samples m
|
||
WHERE m.series_id = s.id ORDER BY m.ts DESC LIMIT 1
|
||
) l ON true
|
||
WHERE s.tenant_id = d.tenant_id AND s.device_id = d.id
|
||
) ss ON true
|
||
WHERE d.tenant_id = $1 AND d.deleted_at IS NULL
|
||
AND ($2::boolean OR d.id = ANY($3::uuid[]))%[1]s
|
||
-- Наявність даних. Порожній перелік — умови немає; обидва
|
||
-- відмічені значення складаються через АБО, як і решта полів.
|
||
AND (cardinality($%[2]d::text[]) = 0
|
||
OR ('any' = ANY($%[2]d::text[]) AND COALESCE(ss.n,0) > 0)
|
||
OR ('none' = ANY($%[2]d::text[]) AND COALESCE(ss.n,0) = 0))
|
||
ORDER BY d.name
|
||
`, cond, own), args
|
||
}
|