Обнаружена проблема с агентами Opscenter. Opscenter сообщает, что агенты не подключены, и в журнале agent.log на каждом узле все они сообщают следующее:
com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: /127.0.0.1:9042 (com.datastax.driver.core. TransportException: [/127.0.0.1:9042] Cannot connect))
Я не уверен, когда это началось, но это недавно и раньше все работало нормально.
Мы используем datastax-agent версии 5.1.0 и версии Cassandra: 2.1.3.
Любые советы о том, где искать, будут оценены.
РЕДАКТИРОВАТЬ: Я оставляю исходный ответ, цитируемый ниже, но, пожалуйста, сделайте не попробуй следовать ему. Предлагаемое здесь решение является официальным и проверено работающим!
Как упоминалось в документация:
Примечание. Начиная с версии 5.1 OpsCenter, параметр hosts в address.yaml теперь определяет, к каким узлам подключается агент. Для получения дополнительной информации об изменениях конфигурации и путях миграции см. Руководство по обновлению.
Итак, просто измените свой address.yaml чтобы отразить эти изменения и перезапустить агент. Например, в нашем случае мы сделали следующее изменение из этого:
stomp_interface: 10.0.10.10
local_interface: 10.0.10.20
к этому:
stomp_interface: 10.0.10.10
hosts: ["10.0.10.20"]
Новый hosts property - это массив строк, поэтому вы можете адаптировать его к своим потребностям, если вам нужно более одного интерфейса. Но для стандартной настройки этого должно хватить.
Исходный ответ находится ниже, не обращайте на него внимания.
У нас такая же проблема с тех пор, как мы обновились до Opscenter 5.1.0. Единственный обходной путь, который мы нашли до сих пор, - это изменить настройку rpc в cassandra.yaml:
rpc_address: 0.0.0.0
Я знаю, что это НЕ политически корректный способ, но он выполняет свою работу, не нарушая всего, и вы заставляете свой OpsCenter работать, пока не придет более официальный способ.
PS: Я действительно не понимаю, почему кто-то отвергает этот вопрос, это серьезная проблема, и она ломает производственные системы.