Состояние сервиса: готовность, числа и события

Сервер отвечает, но успевает ли он работать

Открытый порт не объясняет, растёт ли очередь и завершаются ли задания. Добавьте два простых HTTP-пути. GET /healthz сообщает готовность принимать работу: 200 в рабочем состоянии, 503 после начала остановки. GET /metrics возвращает JSON с числом заданий по состояниям queued, running, done, failed, счётчиком retries и пределами workers, capacity.

Готовность относится к приёму новых заданий. Она не обещает отсутствие ошибок и мгновенный ответ на любую нагрузку. Метрики этого учебного сервиса доступны локально без отдельного сервера мониторинга. Если сервис открывают другим людям, доступ к диагностике и данным становится отдельным требованием безопасности.

Что прочитать

Прочитайте наблюдаемость, SLI и разбор неисправностей в надёжности. В математике нагрузки разберите разницу между числом событий, скоростью за интервал и длительностью. По желанию прочитайте ОС глазами бэкендера, когда ищете причину задержек за пределами кода.

Добавьте наблюдаемые факты

Получайте значения метрик под той же защитой, что и состояния заданий. Если отдельно обходить map без синхронизации, диагностика сама создаст гонку. workers означает настроенный предел обработчиков, capacity — вместимость очереди; они не равны числу занятых обработчиков и текущей длине очереди. retries считает дополнительные попытки, а не все попытки вместе с первыми.

Добавьте события через стандартный логгер: принятие задания, начало попытки, успешный результат, ошибка и начало остановки. Полезные поля — id, попытка и итог. Не печатайте весь пользовательский текст ради удобства: содержимое может оказаться личным. Лог события отвечает «что произошло с этим id», метрика отвечает «что происходит с системой в целом».

Выберите и запишите в README временную область счётчиков: какие значения восстановлены из записей, какие относятся к текущему запуску. Нельзя молча сравнивать счётчики до и после перезапуска как один непрерывный интервал. Время обработки и ожидания очереди — разные длительности: если решите их добавить, объясните точки начала и конца.

Проверьте

go test ./... -run '^TestStage0[1-6]' -count=1
go test -race ./... -run '^TestStage0[1-6]' -count=1
curl -i http://127.0.0.1:8080/healthz
curl http://127.0.0.1:8080/metrics

Задержите Process управляемым каналом, создайте задания и сравните метрики с их состояниями. Освободите работу и проверьте переход в done. Введите временную ошибку и убедитесь, что дополнительные попытки отражаются в retries. После начала остановки проверяйте 503 через обработчик в тесте: реальный сервер может уже закрыть слушающий сокет.

Самостоятельный вопрос: очередь растёт, running держится около workers, ошибок нет. Достаточно ли этого, чтобы обвинить диск? Нет: это наблюдение совместимо с медленной обработкой, большим входным потоком и другими причинами. Нужны измерения конкретных участков и сравнение с входной нагрузкой.

Ошибки: считать каждый опрос метрик новым событием; отдавать 200 готовности после остановки; публиковать накопленное число done как RPS; делать вывод о причине по одному числу.

Когда идти дальше

Покажите снимки до отправки, во время ожидания и после завершения. По одному id восстановите последовательность событий. Автотест проверяет ответы и счётчики; объяснение причины наблюдений проверим в нагрузке и сбоях.