AWS ELB убивает сервис RabbitMQ в AWS ECS раз в несколько минут из-за неудачной проверки работоспособности - PullRequest
0 голосов
/ 24 июня 2019

Я запускаю образ RabbitMQ Docker (rabbitmq: 3-management) в AWS ECS. Работает нормально, без проблем.

Затем я добавил немного больше сложности и создал сервис с тем же RabbitMQ, но теперь подключенным к AWS Network Load Balancer (моя конечная цель - создать кластер RabbitMQ, поэтому мне нужно несколько экземпляров за балансировщиком нагрузки). Целевая группа настроена с портом 5672 и использует тот же порт для проверки работоспособности. Интервал между проверками работоспособности составляет 30 секунд (это максимально доступно). Порог равен 5. В конфигурации обслуживания в ECS Льготный период проверки работоспособности составляет 120 сек. Должно быть достаточно, чтобы начать обслуживание. Что происходит, когда я запускаю сервис через несколько минут, он убивается и перезапускается:

service Rabbit-master (instance i-xxx) (port 5672) is unhealthy in target-group Rabbit-cluster-target-group due to (reason Health checks failed)

«Несколько минут» означает 2, 5 или 9 ... Это меняется. Это не происходит на старте, но через некоторое время. Также я вижу, что RabbitMQ отлично работает (в логах и в панели управления). Так что именно ELB вызывает его перезапуск. Не то чтобы сначала RabbitMQ умер, а затем ELB перезапустил его, нет.

Итак, мой вопрос в том, что я делаю неправильно и как мне добиться стабильной работы RabbitMQ в ECS в паре с ELB? Является ли идея использовать порт 5672 для проверки здоровья неверно? Но какой порт тогда использовать? 15672

Извините, если я предоставил недостаточно информации. Я описал те, которые мне показались актуальными. Если вам нужно что-то еще, я буду рад разработать. Спасибо!

Ответы [ 3 ]

1 голос
/ 25 июня 2019

Видимо проблема была в настройке группы безопасности сервиса RabbitMQ с IP NLB.Эта идея пришла мне не сразу, потому что перезапуски

  1. произошли не сразу после запуска службы, а через несколько минут
  2. NLB не имеют групп безопасности и их идентификаторы нечто очевидно найти.

Более подробная информация здесь:

https://forums.aws.amazon.com/thread.jspa?threadID=263245

и здесь:

https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#target-security-groups

0 голосов
/ 24 июня 2019

Это очень важно для указания пути или порта проверки работоспособности при подключении службы к ALB.

ALB не проверяет тело ответа, но проверяет код состояния, поэтому единственный вызов, который вернет вам 200 код состояния: curl -I http://127.0.0.1:15672 rest потребует аутентификации или 404 или 403, какой LB пометит цель как нездоровую.

enter image description here

Как 15672 вернет 200.

enter image description here

Кроме того, проверьте проверку работоспособности целевой целевой группы задачи ECS, указывает ли она правильный порт экземпляра. enter image description here

2-й вариант: Кроме того, вы можете написать пользовательские проверки работоспособности для LB, которые будут контролировать оба порта вашего контейнера, так как ALB проверяет работоспособность только одного порта за раз, простой пример может быть основан на nodejs, так что это означает, что вы должны запустить простое приложение узла, которое проверит оба порта и ответит на проверки состояния ALB.

В этом случае ваша проверка здоровья будет /ping, а порт будет 3007

Ниже приведен код, который мы используем для такой задачи ECS, где нам нужно проверить несколько портов.

   var express = require('express');
const isAllReachable = require('is-all-reachable');
var request = require('request');
var app = express();

app.get('/ping', (req, res) => {

    isAllReachable([
        // first check if all reachable
        'http://localhost:15672'
        // 'http://localhost:otherport'
    ], (err, reachable, host) => {
        //if reachable then do API request if its responding
        if (reachable) {

            console.log("Health check passed");
            console.log("checking rabbitMQ");
            request.get('http://localhost:15672/api/vhosts', {
                'auth': {
                    'user': 'guest',
                    'pass': 'guest',
                    'sendImmediately': false
                }
            }, function(error, response, body) {
                console.log({
                    "status_code": response.statusCode,
                    "body": body
                })
                if (error) {
                    console.log(error)
                    console.log("failed to get vhosts");
                    res.status(500).send('health check failed');
                } else {
                    res.status(200).send('rabbit mq is running');
                }

            })
        } else {
            console.log("health check failed. ", "This server is not reachable", err);
            res.status(500).send('health check failed. one of the port is not reachable.');
            console.log(reachable)
        }
    });
});

    app.listen(3007, () => console.log('LB custom Health check server listening on port 3007!'));

Для мониторинга Кролика, в глубине вы можете изучить Мониторинг кролика.

0 голосов
/ 24 июня 2019

Работает ли ваш Healthcheck URL?это случилось со мной с ALB.Мой случай был

  • Например: TargetGroup был сопоставлен с /api/profiles => контейнер: 4000, но у моего контейнера не было никакого маршрута к серверу api/profiles.Потому что ALB не переписал путь как для бывшего Nginx.Он искал маршрут api/profiles в контейнере, и мой маршрут был просто /profiles.Поэтому я изменил путь в nginx, после чего он заработал.

Как диагностировать

...