2015-10-15 2 views
7

В настоящее время я сталкиваюсь с проблемой, когда Eureka никогда не очищает экземпляры служб, которые стали устаревшими, потому что VM неожиданно спустилась. Понятно, что режим самосохранения Eureka начался, потому что произошло значительное снижение (ниже порога) при возобновлении обслуживания/запросах на пульс. Однако спустя 15 часов мертвые инстанции все еще зарегистрированы в Эврика. Это серьезная проблема, так как запросы на обслуживание продолжают направляться в мертвые экземпляры только для возврата ошибок.Режим самосохранения Eureka никогда не восстанавливается

Я надеюсь, что порог будет постоянно корректироваться, и через некоторое время порог Эврика будет на новом уровне нормы, и режим самосохранения будет сброшен. Мы используем Eureka в зеркальной настройке, и наши конфигурации не очень сложны.

Наша установка:

Eureka с помощью пружинного загрузки стартер-родителя 1.2.5.RELEASE

eureka: 
    dashboard: 
    path: services 
    enabled: false 
    instance: 
    hostname: localhost 
    leaseRenewalIntervalInSeconds: 3 
    metadataMap: 
     managementPath: /admin 
     instanceId: discoveryPrimary 
    client: 
    registerWithEureka: false 
    fetchRegistry: false 
    serviceUrl: 
     defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ 
    server: 
    waitTimeInMsWhenSyncEmpty: 0 

Можно ли настроить конфигурацию Eureka, чтобы сбросить режим самосохранения (где он прекращает очищать экземпляры) и позволяет ему очищать реестры служб, если службы мертвы в течение 5 + минут?

ответ

4

Если у вас есть только несколько экземпляров ваших услуг, каждый раз, когда какой-либо из них терпит неудачу, самосохранение будет срабатывать, потому что по умолчанию renewalPercentThreshold - 0.85.

Так что, если только 84% ваших случаев возобновили свою эвенку аренды, «включается» самосохранение.

Это означает, что если у вас есть 3 случая, а один из них терпит неудачу, только 66% процентов из них возобновили свои лицензии, поэтому никто не получит регистрацию. Вы можете настроить renewalPercentThreshold на свойства сервера для развертывания вашего приложения.

eureka: 
    server: 
    renewalPercentThreshold: 0.49 

С этим, если у вас есть 2 экземпляра и 1 сбой, вы все еще хороши.

+0

Настройка параметра «renewalPercentThreshold» будет устранена путем задержки режима самосохранения. Мы можем сделать то же самое, установив 'eureka.server.enableSelfPreservation = false', но это все равно не решит проблему, если будет вызвано самосохранение, и эти экземпляры никогда не возвращаются. – restwzeasy

+0

Нет, это не просто задержит режим самосохранения, если ваша сеть здоровая, или вы не просто приходите и уходите каждую минуту. Он просто настроен на меньшую инфраструктуру. Вы можете настроить его дальше с помощью 'renewalThresholdUpdateIntervalMs', поэтому временное окно будет меньше для самосохранения для запуска.Если вы отключите его, вы просто не используете одну из функций устойчивости Eureka. –

+0

Наша цель - попытаться использовать все функции устойчивости Eureka, в том числе режим самосохранения. Однако, устанавливая пороговое значение ниже, он позволяет избежать включения режима самосохранения, и после его включения он все равно не очистит мертвые объекты через 15 часов. Я не считаю, что порог является проблемой по описанным причинам. Существуют ли какие-то другие конфигурации, которые позволяли бы режим самосохранения перезагружаться и в конечном итоге очищать мертвые случаи? – restwzeasy

1

Даже жесткий старый вопрос, вот мои два цента.

Моя надежда, что порог непрерывно корректируется и после некоторого периода времени, порог Eureka был бы на новом уровне нормы и режим самосохранения будет сброшен.

Неправильное предположение. Самосохранение Eureka никогда не истекает, и пороги не корректируются динамически. Вам нужно будет вернуть обратно виртуальных машин/клиентов (так что в целом> 85% клиентов UP), чтобы уйти от этого состояния.

Я считаю, что имеет смысл отключить его - посмотрите на conclusions here и аналогичные question here.

+0

Не рекомендуется отключать режим самосохранения при производстве. Одно пропущенное сердцебиение и здоровый экземпляр удаляются из реестра. Не хорошая идея. –

+0

Вы не правы @ narendra-choudhary. Одно пропущенное сердцебиение не исключает случай. Если сердцебиение терпит неудачу, клиенты отступают экспоненциально в 2 раза, до максимальной задержки. Затем возвращайтесь к следующему серверу в списке серверов, а серверы реплицируют информацию о реестре. –

 Смежные вопросы

  • Нет связанных вопросов^_^