Как отличить реальный пробел S2D Performance History от нулевого значения, другого объекта, timeframe или агрегации и собрать доказательства без удаления истории.
Нет данных и ноль — разные результаты
Пустой участок графика нельзя сразу называть потерянными метриками. Нулевое значение — сохранённая точка с числом, а отсутствие точки может относиться к временному диапазону, объекту или доступной детализации. Microsoft описывает встроенную историю производительности Storage Spaces Direct и несколько временных интервалов с агрегацией. Поэтому сначала выпишите точные начало и конец пробела в UTC, имя ряда и тип объекта. Скриншот без шкалы времени и подписи метрики не подходит для сравнения. Интерфейс обновляйте только после того, как исходное состояние зафиксировано.
Одинаковый timeframe для четырёх объектов
Запросите один и тот же показатель и временное окно через Get-ClusterPerformanceHistory для кластера, затем для соответствующего узла, тома и диска, где это применимо. Не подменяйте показатель похожим названием и не сравнивайте минутную детализацию с суточной. Запишите, возвращается ли пустой набор, ряд с нулями или точки за соседние интервалы. Если пробел есть только у одного объекта, граница уже локализована. Если одинаковый интервал отсутствует везде, сопоставьте его с доступностью health service и временем обслуживания, но не объявляйте причинность без журналов.
Свяжите график с журналом обслуживания
Создайте краткую временную линию: начало обслуживания, остановка и запуск узлов или служб, возвращение кворума, момент доступности томов и первое новое значение метрики. Источником времён должны быть штатные журналы и команды, а не память оператора. Не включайте имена серверов, серийные номера дисков и внутренние пути в публичный отчёт. Совпадение окна обслуживания и пробела полезно как корреляция, но ещё не доказывает, что обслуживание удалило историю. Проверьте также соседний ряд, который должен собираться тем же сервисом.
Не удаляйте историю ради проверки
Остановитесь до команд, очищающих или заново создающих историю, если не сделана резервная фиксация и не понятен эффект. Для эскалации сохраните версию Azure Local или Windows Server, объект и metric name, точный timeframe, результаты четырёх запросов, окно обслуживания и статус health service после него. Экспортируйте только нужные строки и удалите названия инфраструктуры. Полезный диагноз звучит так: «у одного ряда отсутствуют точки в одинаковом UTC-окне, соседние объекты показывают такие-то результаты». Это позволяет поддержке проверять сбор и агрегацию, не восстанавливая контекст после разрушительной очистки.
Материал подготовлен редакцией VOne с применением ИИ для структурирования; технические утверждения вручную сверены с Microsoft Learn, а форумный вопрос использован только как обезличенный сигнал.
Источники и проверка
- Microsoft Learn — Get performance history for Azure Local проверено 2026-07-31
- Microsoft Learn — Performance history for Storage Spaces Direct проверено 2026-07-31
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.