Alauda Streaming Service for RabbitMQ
  • Русский

    • Проверка статуса RabbitmqCluster

    Используйте это руководство, чтобы определить, является ли RabbitmqCluster здоровым как с точки зрения оператора Kubernetes, так и с точки зрения брокера RabbitMQ.

    Одной только готовности Kubernetes недостаточно. Pod может быть в состоянии Ready, в то время как брокер еще не присоединился к ожидаемому кластеру RabbitMQ или когда активны runtime-alarms.

    Содержание

    1. Проверьте ресурс RabbitmqCluster2. Проверьте Pods и Services3. Проверьте доступность брокера и членство в кластере4. Проверьте listeners, alarms и runtime status5. Проверьте logs, если status неясенСвязанная информация

    1. Проверьте ресурс RabbitmqCluster

    Начните с custom resource:

    kubectl -n <namespace> get rabbitmqcluster <instance-name> \
  -o custom-columns='NAME:.metadata.name,PHASE:.status.phase,GENERATION:.metadata.generation,OBSERVED:.status.observedGeneration,OPERATOR:.status.operatorVersion,DEFAULT_USER:.status.defaultUser.secretReference.name'

    Проверьте conditions:

    kubectl -n <namespace> get rabbitmqcluster <instance-name> \
  -o jsonpath='{range .status.conditions[*]}{.type}={"status":.status,"reason":.reason}{"\n"}{end}'

    Следующие поля status наиболее полезны для регулярных проверок:

    ПолеЗначение
    status.phaseОбщее состояние жизненного цикла, сообщаемое оператором.
    status.conditionsПодробные conditions готовности и reconciliation, такие как AllReplicasReady, ClusterAvailable и ReconcileSuccess.
    status.observedGenerationСамая последняя metadata.generation, успешно замеченная оператором.
    status.defaultUser.secretReferenceСгенерированный Secret, в котором хранится пользователь RabbitMQ по умолчанию.
    status.operatorVersionВерсия оператора, выполнившего reconciliation кластера.
    status.upgradeStatusМетаданные, связанные с upgrade, для bundle кластера.

    2. Проверьте Pods и Services

    Выведите список Pods:

    kubectl -n <namespace> get pods \
  -l app.kubernetes.io/name=<instance-name>

    Проверьте Service:

    kubectl -n <namespace> get svc <instance-name>

    Проверьте endpoints:

    kubectl -n <namespace> get endpoints <instance-name>
kubectl -n <namespace> get endpoints <instance-name>-nodes

    Если Pod отсутствует в endpoints, клиенты или peer discovery могут завершиться сбоем, даже если Pod существует.

    3. Проверьте доступность брокера и членство в кластере

    Убедитесь, что процесс брокера запущен:

    kubectl -n <namespace> exec <instance-name>-server-0 -- \
  rabbitmq-diagnostics ping

    Проверьте членство в кластере:

    kubectl -n <namespace> exec <instance-name>-server-0 -- \
  rabbitmqctl cluster_status

    cluster_status должен показывать все ожидаемые узлы в кластере брокера. Если Pod находится в состоянии Ready, но cluster_status не показывает соответствующий узел брокера, изучите формирование кластера, прежде чем объявлять экземпляр здоровым.

    4. Проверьте listeners, alarms и runtime status

    Проверьте listeners:

    kubectl -n <namespace> exec <instance-name>-server-0 -- \
  rabbitmq-diagnostics listeners

    Проверьте runtime status:

    kubectl -n <namespace> exec <instance-name>-server-0 -- \
  rabbitmq-diagnostics status

    Обратите внимание на:

    • использование memory high watermark
    • alarms о свободном disk space
    • общее количество connections и queues
    • включенные plugins
    • порты listeners, соответствующие вашему способу доступа и ожиданиям по TLS

    5. Проверьте logs, если status неясен

    Если проверки ресурса или брокера противоречат друг другу, изучите logs оператора и брокера:

    kubectl -n <namespace> logs <instance-name>-server-0

    Рекомендации по logs для конкретной платформы см. в Log View.

    Связанная информация