МОНИТОРИНГ, ЖУРНАЛИРОВАНИЕ, АУДИТ И ДИАГНОСТИКА Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Руководство по наблюдаемости и диагностике Последнее обновление: 09.09.2026 ЧТО МЫ НАСТРОИМ Инструкция описывает контроль Health и freshness, метрики, события и алерты, просмотр журналов, Audit действий администратора, корреляцию Change/Job и сбор безопасного диагностического пакета. КЛЮЧЕВЫЕ ПОНЯТИЯ Health | Нормализованное состояние управляемого объекта Freshness | Насколько свежи фактические данные Actual State Metrics | Числовые показатели ресурсов и работы компонентов Logs | Технические журналы выполнения Audit | История значимых действий и изменений Alert | Уведомление о состоянии, требующем внимания Correlation ID | Идентификатор, связывающий запрос/операцию с логами Change/Job ID | Идентификаторы управляемого изменения и его исполнения Важно: Audit не заменяется обычными логами, а успешный liveness не означает, что доменный Health объекта нормален. ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ Требование | Значение Время | NTP синхронизирован Права | Monitoring/Logs/Audit по минимально необходимому scope Storage | Достаточная емкость под retention Alerts | Определены получатели/каналы [ТРЕБУЕТ УТОЧНЕНИЯ] External export | Если используется — утвержденный endpoint и TLS АРХИТЕКТУРА Node/Service → Metrics/Health/Logs → Control Center → Alert/History Change/Job ────────────────────────────────┐ User action → Audit ───────────────────────┼→ correlation/evidence Request ID ────────────────────────────────┘ ПЕРЕД НАЧАЛОМ 1. Проверьте NTP на всех узлах. 2. Определите retention для metrics/logs/audit. 3. Не включайте чрезмерное debug-логирование постоянно без оценки объема и чувствительности данных. 4. Убедитесь, что секреты, пароли, API credentials и приватные ключи не попадают в diagnostics/support bundle. Шаг 1. Проверка общего Health Откройте обзор состояния [Уточнить название элемента интерфейса]. Проверьте: - Overall Health; - состояние узлов; - критические роли/сервисы; - freshness Actual State; - активные Alerts; - незавершенные Changes/Jobs. Ожидаемый результат: Healthy объекты имеют свежий Actual State; Unknown/Stale отображаются отдельно от Healthy. Шаг 2. Разбор Degraded/Unknown 1. Откройте объект. 2. Прочитайте reason/evidence. 3. Проверьте время последнего успешного наблюдения. 4. Найдите связанные Change/Job ID. 5. Не запускайте автоматическую remediation до понимания причины, если Actual State stale/unknown. Шаг 3. Метрики ресурсов Проверьте CPU, RAM, storage capacity, disk performance, network и иные доступные показатели. Используйте историю, а не одиночное значение. Короткий пик нагрузки не равен постоянному bottleneck. [ТРЕБУЕТ УТОЧНЕНИЯ: точные metrics, sampling interval и retention]. Для долгосрочного анализа используйте Capacity Planner (документ 13). Шаг 4. Алерты Для каждого Alert определите: - severity; - объект; - начало/продолжительность; - текущее состояние; - связанный evidence; - owner/acknowledgement, если поддерживается. Порядок реакции: 1. Critical — оценить доступность/данные/HA. 2. Проверить, является ли проблема текущей или уже восстановленной. 3. Связать с недавним Change/Job. 4. Выполнить минимальное безопасное corrective action. 5. Подтвердить восстановление Health. 6. Закрыть/acknowledge Alert только после проверки результата. Шаг 5. Просмотр технических логов Откройте Logs [Уточнить название элемента интерфейса]. Фильтруйте по: - времени; - node/service; - severity; - correlation ID; - Change ID; - Job ID. Не копируйте весь журнал в публичный канал. Сначала ограничьте диапазон и проверьте наличие чувствительных данных. [ТРЕБУЕТ УТОЧНЕНИЯ: локальные диагностические команды/пути журналов]. Шаг 6. Audit Audit используется для ответа на вопросы: кто, когда, над каким объектом и какое значимое действие выполнил. Проверьте Audit после: - входа/выхода и session revoke; - изменения RBAC; - изменения сети/firewall; - update/restore; - установки/удаления Market-модуля; - maintenance/drain/decommission; - data-changing operation. Ожидаемый результат: Событие содержит достаточный контекст для расследования и не раскрывает секретные значения. ПРЕДУПРЕЖДЕНИЕ: Не удаляйте или не редактируйте Audit вручную для «очистки» ошибки администратора. Шаг 7. Корреляция Change → Job → Logs → Actual При проблемном изменении: 1. откройте Change; 2. зафиксируйте Change ID; 3. найдите Jobs; 4. откройте evidence/logs по Job ID; 5. сопоставьте timestamps/correlation ID; 6. проверьте Actual State после попытки; 7. определите, применена ли часть операции. Ожидаемый результат: Диагностика показывает не только ошибку, но и фактический эффект операции. Шаг 8. Внешний экспорт наблюдаемости Архитектура допускает совместимые механизмы экспорта metrics/traces/logging, однако точные endpoints и способы настройки зависят от релиза. [ТРЕБУЕТ УТОЧНЕНИЯ: Prometheus-compatible metrics endpoint, OpenTelemetry/OTLP options, TLS/authentication]. Не публикуйте telemetry endpoint в Internet без аутентификации/сетевого ограничения, если он содержит инфраструктурные сведения. Шаг 9. Diagnostic/Support bundle Перед созданием support bundle: 1. выберите минимальный временной диапазон; 2. включите только относящиеся к инциденту компоненты, если доступен выбор; 3. выполните preview/redaction; 4. убедитесь, что bundle не содержит паролей, токенов, private keys или необязательных пользовательских данных; 5. создайте bundle; 6. храните и передавайте его через защищенный канал. [ТРЕБУЕТ УТОЧНЕНИЯ: точный состав bundle, redaction rules и UI]. Шаг 10. Retention и емкость Настройте retention так, чтобы: - расследование инцидентов было возможно; - primary transactional storage не переполнялся неограниченной telemetry; - Audit сохранялся согласно требованиям организации; - удаление старых diagnostics было предсказуемым. [ТРЕБУЕТ УТОЧНЕНИЯ: поддерживаемая retention policy по типам данных]. ПРОВЕРКА - [ ] NTP synchronized; - [ ] Health отображается для всех критических узлов/ролей; - [ ] freshness видима; - [ ] Alerts имеют severity и evidence; - [ ] Change/Job коррелируются с логами; - [ ] Audit фиксирует административные изменения; - [ ] секреты не видны в логах/Audit/support bundle; - [ ] retention настроен; - [ ] storage telemetry не близок к исчерпанию; - [ ] external export защищен, если используется; - [ ] diagnostic bundle проходит preview/redaction. ТИПОВЫЕ ОШИБКИ Симптом | Возможная причина | Проверка | Решение Health Unknown | узел недоступен или stale discovery | freshness/connectivity | восстановить наблюдаемость до remediation Много ложных Alerts | threshold/короткие spikes | history | скорректировать подтвержденную alert policy Нельзя связать ошибку с изменением | нет фильтра по ID/не тот диапазон | Change/Job/correlation | искать по идентификаторам и времени Заканчивается диск | retention/debug logs | storage metrics | уменьшить поддерживаемый retention/debug и расширить storage Support bundle содержит лишнее | недостаточная redaction | preview | не передавать; пересоздать с корректной фильтрацией РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - мониторьте не только up/down, но и freshness, latency, capacity и replication; - используйте correlation IDs для расследований; - регулярно проверяйте Critical Alerts и Audit; - ограничивайте debug logging по времени; - отделяйте долговременную telemetry от primary transactional state; - храните diagnostic bundles ограниченное время; - проверяйте redaction на тестовом инциденте заранее. ИТОГ Наблюдаемость Control Center объединяет Health, freshness, metrics, Alerts, Logs и Audit. Диагностика должна связывать пользовательский Change с Job, evidence и фактическим Actual State, при этом секреты и чувствительные данные не должны попадать в журналы или support bundle. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - точные UI names; - Health state catalog; - freshness thresholds; - metrics list/sampling/retention; - alert channels/rules; - log locations/CLI; - Audit retention/export; - Prometheus/OpenTelemetry endpoints; - support bundle content/redaction; - telemetry storage limits.