Контроль агентов за запланированной работой: создать конверт для ожидаемой работы

Мониторинг агента по запланированной работе должен начаться с одного вопроса: , начал ли этот конкретный запланированный случай, закончил ли он и принес ли обещанный результат в пределах разрешенного окна? Зеленый выход из процесса, недавний сердечный ритм и полный след не могут ответить на этот вопрос в одиночку. Практическим дефолтом является ожидаемое запускное конверт . Для каждого случая записывайте планируемое расписание времени, допустимую задержку запуска, максимальное время выполнения и срок проверки доставки. Держи эти часовые марки отдельно. Работа может законно ждать, начать поздно, работать до сих пор, опоздать, повторить или закончить без результата. Разваливание этих состояний в "бегущий" и "неудачный" создает шумные предупреждения и скрывает ложный успех. Этот справочник создает этот конверт как нейтральный контракт. Включенная девятью случаями фиксация является синтетической, а не производственной доказательством, но она выполняется и раскрывает решения, которые должна принимать система мониторинга. Закрепить запись на запланированное событие Не следует выводить ожидаемое время из первой строки. Получить планируемый срок событий и сохранить его как scheduled at . Kubernetes 1.32 и позже добавляет batch.kubernetes.io/cronjob scheduled timestamp к созданным работам. Google Cloud Scheduler отправляет X CloudScheduler ScheduleTime , который остается постоянным во время повторных попыток. Эти значения переживают поздний старт и делают повторные попытки относящимися к тому же событию. Используйте стабильный ключ: Тогда оставьте эти поля: outcome ref должен идентифицировать доказательства, а не содержать конфиденциальную информацию. Это может быть хэш, версия объекта, идентификатор тестирования или ключ строки базы данных. Создаваемый файл, просто существующий, может быть недостаточным; проверка должна соответствовать реальному обещанию, например, существует todayс краткое содержание, имеет пять цитируемых элементов и хранится в ожидаемом месте назначения. Контракт планер имеет значение, потому что исполнение не обязательно происходит один раз. Kubernetes документирует, что CronJob иногда может создавать две работы или никакой работы и советует бессильные рабочие нагрузки. Cloud Scheduler описывает как минимум один раз доставку и также требует бессильных целей. Следовательно, мониторинг должен рассматривать дублированные старты как состояние первого класса, а не как невозможную аномалию. Вычислить три срока, не один отсрочка Определить оболочку с тремя независимыми границами: Значения должны исходить из наблюдаемого распределения времени работы и требований бизнеса, а не универсального предустановления. Задача, запланированная в 09:00 может быть совершенно здоровой, когда она начинается в 09:40. Та же 40 секундная задержка может нарушить обещание отправки в течение нескольких минут. Например, Amazon EventBridge Scheduler документирует точность в 60 секунд; если рассматривать второй 01 как late, это неправильно расшифрует контракт с программистом. Три ограничения отвечают на разные вопросы: Государство Доказательства Ответ оператора waiting for start Никакой пробежки нет, но start deadline не прошел Подождите . missed start После start deadline не существует никакой пробежки Проверка расписания и доступности running Один пробег активен до finish deadline Оставь это в покое. overrun Активная работа прошла finish deadline Перед прерыванием проверьте прогресс outcome pending Процесс завершен; окно проверки остается открытым Подождите проверку . outcome missing Срок проверки прошел без доказательств Исследовать ложный успех duplicate start Более одного пробега требует одного и того же ключа Содержат побочные эффекты; проверьте причину повторного испытания healthy Обещанный результат был подтвержден. Закройте событие suspended Явная пауза обслуживания или одобрения покрывает разрыв Устранение неудач; сохранение доказательств аудита Этот порядок предотвращает две распространенные ошибки. Во первых, отсутствие не является неудачей до истечения действующего срока. Во вторых, завершение процесса это не завершение задачи. Побега, выходящая в 09:06, может оставаться outcome pending до завершения проверки загрузки, тестирования или назначения. Он становится outcome missing только после того, как истекает отдельное окно благодати. Нападение также не означает разрешения на убийство агента. Проверьте, продолжается ли полезный прогресс, ожидается ли он на внешней системе и может ли прерываться. В конверте указывается, где внимание оправдано; оно не принимает решение о возмещении. Воспроизвести классификатор с девятью неудобными случаями Артефакт выполнения оценивает новые линейные фиксации с помощью детерминистического классификатора. Попробуйте: Устройство использует двухминутный стартовый график, десятьминутный максимальный срок работы и двухминутный исходный график. Результат заключается в следующем: Основной классификатор намеренно небольшой: Этот эксперимент демонстрирует ценность ясных границ, но не доказывает, что выбранные пороги подходят для реальной нагрузки. Он также предполагает, что один график событий карты чисто на один слот. Вспышки, основанные на событиях, ручная воспроизведение исторической работы и выполнение задач с несколькими необходимыми результатами требуют расширенной модели идентичности. Двойные, перекрывающиеся, часовые пояса и паузы Повторные попытки и перекрытия взаимосвязаны, но не идентичны. Повторная попытка может повторить тот же промежуток времени после неисправности транспортировки. На следующий слот может начаться перекрытие, пока предыдущий еще активен. Сохранить как slot key , так и run id , а затем применить заявленное поведенческое совпадение программиста. Kubernetes раскрывает политику конверсии Allow , Forbid и Replace . В соответствии с Forbid , пропущенное событие, когда предыдущая работа активна, считается пропущенным. В соответствии с Replace , новое происшествие вытесняет старую работу. Ваше наблюдение должно сохранить эту причину, иначе преднамеренная замена выглядит как крушение. Для выполнения задач с побочным воздействием дедупликуйте на клавиатуре слота в пункте назначения, а также на мониторе. Второе успешное выполнение может по прежнему отправлять второй счет, перезаписать новый отчет или опубликовать одно и то же сообщение дважды. Монитор может раскрыть риск, но недействительность входит в договор на рабочую нагрузку и место назначения. Временные зоны нуждаются в одновременно явном правиле. Сохранить часовые марки событий в UTC, сохраняя идентификатор часовой зоны IANA и оригинальное выражение. Переходы, которые позволяют сэкономить время на дневном свете, являются специфическими для планировщика. EventBridge Scheduler документирует, что несуществующее местное время во время весеннего перерыва выпускается, а повторяемое местное время во время осени один раз. Не синтезируйте пропущенное событие, которое планировщик никогда не обещал. Наконец, паузы должны быть моделированы, а не скрыты путем отключения оповещений. Запишите, кто остановил расписание, почему, время начала и окончания, и ожидается ли задержание. Kubernetes отмечает, что приостановленные события CronJob считаются пропущенными и могут запускаться сразу после отмены при отсутствии установленного срока начала. Монитор, который забывает паузу, может затопить оператора именно тогда, когда заканчивается обслуживание. Превратить конверт в тихое правило работы Начнем с одного критически важного агента, а не с каждой следы: 1. Прочитайте местную временную марку происшествий, часовую зону, политику повторной попытки и политику совпадения. 2. Прежде чем начать работу, назначайте ключ и сохраняйте его во время повторных попыток. 3. Выберите start grace , max runtime и outcome grace из фактических требований и наблюдаемой продолжительности. 4. Определите один детерминистический проверяющий результат. 5. Повторяйте недавнюю историю через девять штатов, прежде чем включить уведомления. 6. Опубликовать страницу только тогда, когда соответствующее обещание пользователя находится вне ее рамки; держать waiting for start , running и outcome pending видимыми, но тихими. Пересмотреть пороги после изменения графика, модели, инструмента или места назначения. Большая модель может увеличить время выполнения без изменения точности. Более медленная внешняя API может удлинять проверку результатов. Дрейф порога это задолженность по конфигурации, а не доказательство того, что агент стал ненадежным. Этот договор также устанавливает полезные границы данных. Вам нужны часовые марки, стабильные идентификаторы, состояние и ссылка на доказательства проверки. Вам не нужны автоматические просьбы, ответы, грузы инструментов или полные следы. Собирайте их только тогда, когда диагноз требует их и ваша политика конфиденциальности позволяет. Sidewisp предназначен для преобразования таких сигналов, как пропущенные графики, стойки, неисправности инструментов и пропущенные результаты, в приоритетное представление о состоянии здоровья с ясными доказательствами и ограничениями одобрения. Двигатель мониторинга производства и адаптеры для работы обычно не поставляются сегодня. Sidewisp сейчас находится на этапе закрытого предварительного доступа. Если этот ожидаемый контракт совпадает с ошибкой, которую вы совершаете, регистрация в частном просмотре это следующий сдержанный шагне утверждение о том, что Sidewisp уже следит за вашими живыми агентами. Первичные источники Документация Kubernetes CronJob запланированные временные знаки, сроки начала, политика конкуренции, приостановка, приблизительное создание и безвыборность. Обзор Google Cloud Scheduler по крайней мере один раз доставка, повторное поведение, беспомощность, и стабильный заголовок запланированного времени. Типы расписания Amazon EventBridge Scheduler точность призыва, часовые пояса и поведение, которое сохраняет дневный свет.