Согласен, чаще всего сервис OCSP отвечает корректно.
Но каждый некорректный ответ - это проблема проверки подписи пользователя. Именно поэтому я и интересуюсь чем были вызваны всплески некорректных ответов и как в будующем этого избежать.
В приведенном Вами журнале записей явно меньше, чем зарегистрировано у нас. Присутствует ли у Вас информация о том, по какой причине сервис OCSP вернул ошибку?
Привожу нашу статистику:
12 число, запросы к сервису OCSP
12 число, проблемы
13 число, запросы к сервису OCSP
13 число, проблемы
В данном случае этого исключительно Ваша статистика, как вы писали выше “никаких данных (даже заголовков HTTP ответа)” - может означать, что проблема могла быть также и на сетевом уровне, как у Хостер-провайдера, так и стыке между операторами связи.
А сегодня у Вас были аналогичные проблемы ?
В данном случае этого исключительно Ваша статистика, как вы писали выше “никаких данных (даже заголовков HTTP ответа)” - может означать, что проблема могла быть также и на сетевом уровне, как у Хостер-провайдера, так и стыке между операторами связи.
Думаю что если бы проблема была на сетевом уровне, то устанавливать соединение бы не удавалось. Хотя всякое бывает, да, приведенная мной статистика - это ситуация с точки зрения исключительно нашего сервера.
А сегодня у Вас были аналогичные проблемы ?
Нет, сегодня проблем не наблюдалось.
Меня немного смущают данные из приведенного журнала - первая запись в 13:18, потом уже в 18:50. Но мы точно получили от OCSP сервиса множество квитанций в этот промежуток времени.
И аналогично пробел с 18:59 по 21:18.
Могу разве что предположить что это журнал с одного из узлов OCSP сервиса, перед несколькими узлами может стоять балансировщик. В этом случае наши запросы могли не достигать узлов OCSP сервиса, если балансировщик не мог связаться с узлами. Мою гипотезу можно проверить изучив журналы балансировщика.
Кстати в приведенном журнале странный код статуса HTTP на предпоследней строке: 499. Так и должно быть?
Я специально указал в логе пример на 499 ошибку, это означает что клиент т.е. ваш сервер закрыл соединение до того как получил ответ.
Это наводит на мысль, что у вас возможно установлен слишком короткий time_out на время ответа от нашего сервиса, как вариант 1-2 секунды либо ещё это больше указывает на сетевые проблемы.
Я специально указал в логе пример на 499 ошибку, это означает что клиент т.е. ваш сервер закрыл соединение до того как получил ответ.
Это наводит на мысль, что у вас возможно установлен слишком короткий time_out на время ответа от нашего сервиса, как вариант 1-2 секунды либо ещё это больше указывает на сетевые проблемы.
У нас установлен таймаут в 2 секунды, Вы рекомендуете ждать дольше?
Конечно 2 секунды это мало, Выши ведь сервера не находятся на одной площадке с нашими + подключение идёт через разных операторов связи, Вы можете сами запустить traceroute и проверить через сколько точек происходит подключение.
у нас таймаут 30 секунд. ничего не работает, сам ваш форму через раз выдает ошибку 500
Форум кидает 500 ошибку, из-за межсетевого-экрана от РГП “ГТС”, по этой проблеме уже с ними отрабатываем.
Как понять, что у вас ни чего не работает? Скорее всего, Вы не правильно подключаетесь к сервису OCSP.
да, 2 года я подклчался правильно, а сегодня начал подключаться неправильно.
если в ответ на команду telnet ocsp.pki.gov.kz 80 я получаю ответ “Подключение к ocsp.pki.gov.kz…Не удалось открыть подключение к этому узлу, на порт 80: Сбой подключения”
Это правильное подключение или неправильное?
Давай-те проверим, напишите белый IP с которого пытаетесь подключиться.
Хорошо, мы увеличим таймаут. В том случае, если будут возникать новые проблемы, напишу.
Между прочим, Вас интересуют сторонние метрики доступности сервисов НУЦ? Мы могли бы публиковать данные в каком-нибудь виде, если так же будут поступать другие системы, то Вы сможете получать достаточно объективное представление.
Метрики не так интересны, а вот от стороннего мониторинга доступности были бы не против 
а вот от стороннего мониторинга доступности были бы не против
Мы в скором будущем планируем добавить в наш API новый публично доступный вызов, который будет возвращать текущий статус сторонних сервисов. Таким образом любой желающий сможет запросить у нашего сервиса информацию о том, были ли у него проблемы со сторонними сервисами в последнее время.
Если это не совсем то, о чем Вы думаете, то давайте обсудим.
Да, это весьма интересное решение вполне устроит.
Да, это весьма интересное решение вполне устроит.
Добрый день,
Готово: https://sigex.kz/support/external-services-stats/
Буду признателен за обратную связь.
“В последнее время все обращения к сервису были успешны.” - можете добавить дату и время обращения к сервису или за какой период? Так будет более информативно.