В этом материале
Возврат сетевого соединения и готовность модели обслуживать запросы — разные события, поэтому их фиксируют отдельно.
Журнал сетевого перерыва GPU-узла должен показывать последовательность проверяемых событий: когда пропала связь, когда проблему обнаружили, когда восстановилось подключение и когда сервис прошёл тест. Одной продолжительности «сервер был недоступен» мало для выяснения причины и улучшения эксплуатации.
Для владельца оборудования это способ обсуждать фактическую доступность без предположений о потерянной выручке. Если запросов в период перерыва не было или их история неизвестна, журнал не должен придумывать их объём.
Определите точку наблюдения
Проверка с самого сервера, из сети площадки и из внешнего региона может давать разные результаты. В записи укажите источник проверки, проверяемый адрес и тип сигнала: соединение, HTTP-ответ или завершённый запрос модели.
Prometheus различает задания и экземпляры наблюдения. Доступность цели сбора метрик относится к этой цели, а не автоматически ко всему пользовательскому пути. Ошибка одного наблюдателя требует сопоставления с другими данными, прежде чем её называют отказом сервера.
Записывайте несколько времён
| Событие | Пример времени UTC | Подтверждение |
|---|---|---|
| Последний успешный внешний тест | 10:00 | Запись проверяющего сервиса |
| Первое обнаружение недоступности | 10:03 | Срабатывание проверки |
| Ответ площадки | 10:15 | Номер обращения |
| Восстановление соединения | 10:30 | Успешное подключение |
| Завершение тестового запроса | 10:38 | Ответ модели и идентификатор теста |
По такой таблице видно, что связь вернулась раньше приложения. Но точное начало перерыва находится между последним успехом и первым обнаружением, если нет более подробного источника.
Сохраняйте часовой пояс
Время без зоны неудобно сопоставлять с логами площадки и действиями оператора. Используйте UTC для общей линии событий, сохраняя локальную зону там, где она нужна для рабочих часов и обращений.
Документация Python zoneinfo описывает работу с именованными часовыми зонами. Практический вывод для журнала прост: фиксируйте исходную зону и правило преобразования, не прибавляйте вручную один постоянный сдвиг ко всем историческим событиям.
Отделите причину от предположения
Сначала записывают наблюдение: внешний запрос не завершился, локальный процесс продолжал работать, площадка сообщила о переключении линии. Подтверждённую причину добавляют после сопоставления данных. Пометка «предполагается» сохраняет смысл, если расследование ещё идёт.
Не пересчитывайте всю продолжительность перерыва в потерянные токены по максимальной скорости карты. Реальный спрос, очередь и возможность повторного запроса могут быть другими. Для технического решения полезнее указать, какой контроль позволил бы быстрее обнаружить или устранить проблему.
Если площадка уточняет причину позднее, добавьте отдельную запись с датой, сохранив первоначальное наблюдение и источник нового объяснения.
Закройте событие действием
В финальной записи нужны ответственный, проверка восстановления и одно конкретное улучшение: дополнительный внешний тест, корректировка контакта площадки или резервный способ доступа. Изменение заносят в рабочую документацию, чтобы оно не осталось обещанием в переписке.
Журнал дополняет план сети и доступности и отчёт о мощности оборудования.