Problema de conexão TCP Sensu

Eu tenho uma nova pilha sensu / uchiwa executando em uma máquina virtual. É uma instalação "independente" - redis, rabbitmq, sensu-server, sensu-api, sensu-client e uchiwa são todos instalados na mesma máquina. Eu tenho uma única verificação que o client.json assina.

Em suma, algo parece estar errado. Entrei no painel do uchiwa e há uma mensagem de aviso de que "O datacenter sensu-81 retornou: 500 ERRO INTERNO DO SERVIDOR".

Os sensu-client, sensu-apie sensu-serveros registros são preenchidos com essas mensagens e apenas estas mensagens:

==> /var/log/sensu/sensu-api.log <==
{"timestamp":"2017-05-11T21:00:34.758243+0000","level":"warn","message":"transport connection error","reason":"tcp connection lost"}
{"timestamp":"2017-05-11T21:00:34.758784+0000","level":"warn","message":"transport connection error","reason":"possible authentication failure. wrong credentials?","user":"sensu"}

==> /var/log/sensu/sensu-client.log <==
{"timestamp":"2017-05-11T21:00:35.973060+0000","level":"warn","message":"transport connection error","reason":"tcp connection lost"}
{"timestamp":"2017-05-11T21:00:35.974858+0000","level":"warn","message":"transport connection error","reason":"possible authentication failure. wrong credentials?","user":"sensu"}

==> /var/log/sensu/sensu-server.log <==
{"timestamp":"2017-05-11T21:00:37.489540+0000","level":"warn","message":"transport connection error","reason":"tcp connection lost"}
{"timestamp":"2017-05-11T21:00:37.489704+0000","level":"warn","message":"transport connection error","reason":"possible authentication failure. wrong credentials?","user":"sensu"}

Ele sugere que há um erro ao conectar-se à camada de transporte, então verifiquei se meu transport.json estava configurado conforme o esperado e era (o padrão do sensor):

{
  "transport": {
    "name": "rabbitmq",
    "reconnect_on_error": true
  }
}

Por isso, verifiquei o rabbitmq.json do sensu para verificar se estava configurado conforme o esperado, e novamente foi. (Nota: eu tenho uma linha no arquivo hosts que traduz o monitor para 127.0.0.1. Estou ciente do problema de usar "localhost" causando problemas no IPv6, por isso verifiquei que o arquivo hosts mapeia "monitor" para 127.0. 0,1). Para confirmar ainda mais que essas credenciais estão funcionando, ativei o gerenciamento baseado na Web rabbitmq e entrei com êxito usando essas credenciais.

{
  "rabbitmq": {
        "ssl": {
      "cert_chain_file": "/etc/sensu/ssl/cert.pem",
      "private_key_file": "/etc/sensu/ssl/key.pem"
    },
        "host": "monitor",
    "port": 5671,
    "vhost": "/sensu",
    "user": "sensu",
    "password": "sensu"
  }
}

Eu também verifiquei se a configuração do rabbitmq estava como o esperado (ssl ativado e tal):

[
    {rabbit, [
        {ssl_listeners, [5671]},
    {ssl_options, [{cacertfile,"/etc/rabbitmq/ssl/cacert.pem"},
                   {certfile,"/etc/rabbitmq/ssl/cert.pem"},
                   {keyfile,"/etc/rabbitmq/ssl/key.pem"},
                   {verify,verify_peer},
                   {fail_if_no_peer_cert,true}]}
      ]}
].

Estou sem saber onde continuar a depuração.

Também verifiquei os arquivos de configuração api.json e uchiwa.json, apenas para garantir que eles possuíssem credenciais correspondentes e o que fazem:

api.json:

{
  "api": {
    "host": "monitor",
    "port": 4567,
    "user": "admin",
    "password": "secret"
  }
}

uchiwa.json:

{
 "sensu": [
   {
       "name": "",
       "host": "monitor",
       "ssl": false,
       "port": 4567,
       "user": "admin",
       "pass": "secret",
       "path": "",
       "timeout": 5000
   }
 ],
 "uchiwa": {
   "users": [
    {
        "password": "admin",
        "username": "admin"
    }
],
   "port": 3000,
   "refresh": 5
  }
}

Tentar falar com o sensu api diretamente de dentro da caixa também gera um erro 500:

vagrant@vagrant-ubuntu-trusty-64:/etc/default$ curl -I http://localhost:4567/stashes -u admin
Enter host password for user 'admin':
HTTP/1.1 500 Internal Server Error
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Origin: *
Connection: close
Content-length: 0

Termina que os logs rabbitmq mantiveram a resposta. Vi que algo estava errado, mas as mensagens eram tão enigmáticas que não sabia dizer o que realmente estava quebrando. Acontece que foi um problema de SSL causado por uma versão antiga do Erlang, que é o que o apt estava instalando por padrão no ubuntu 14.04 (versão erlang R16B03).

Esse problema do amqp foi o que me indicou a solução:

https://github.com/squaremo/amqp.node/issues/224

Eu precisava atualizar para Erlang> = 17.5, e funcionou como esperado.