Problem mit der Sensu TCP-Verbindung

Ich habe einen neuen sensu / uchiwa-Stack, der auf einer virtuellen Maschine ausgeführt wird. Es handelt sich um eine "eigenständige" Installation - Redis, Rabbitmq, Sensu-Server, Sensu-API, Sensu-Client und Uchiwa sind alle auf demselben Computer installiert. Ich habe eine einzige Prüfung, die die client.json abonniert.

Kurz gesagt, etwas scheint nicht zu stimmen. Ich habe mich beim Uchiwa-Dashboard angemeldet und es wird eine Warnmeldung angezeigt, dass "Datacenter sensu-81 zurückgegeben hat: 500 INTERNAL SERVER ERROR".

Die sensu-client, sensu-apiund sensu-serverProtokolle werden mit diesen Nachrichten gefüllt und nur diese Meldungen:

==> /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"}

Es deutet darauf hin, dass beim Herstellen einer Verbindung zur Transportschicht ein Fehler aufgetreten ist. Daher habe ich überprüft, ob meine transport.json wie erwartet konfiguriert wurde, und dies war (die sensu-Standardeinstellung):

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

Also überprüfte ich sensus rabbitmq.json, um zu überprüfen, ob es wie erwartet konfiguriert war, was es auch wieder war. (Hinweis: Ich habe eine Zeile in meiner Hosts-Datei, die den Monitor in 127.0.0.1 übersetzt. Ich bin mir des Problems bewusst, dass die Verwendung von "localhost" Probleme mit IPv6 verursacht, und habe daher überprüft, ob die Hosts-Datei "monitor" 127.0 zuordnet. 0,1). Um weiter zu bestätigen, dass diese Anmeldeinformationen funktionieren, habe ich die webbasierte Verwaltung von rabbitmq aktiviert und mich erfolgreich mit diesen Anmeldeinformationen angemeldet.

{
  "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"
  }
}

Ich habe auch überprüft, ob die Konfiguration von rabbitmq selbst wie erwartet war (ssl aktiviert und so):

[
    {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}]}
      ]}
].

Ich bin ratlos, wo ich weiter debuggen soll.

Ich habe auch die Konfigurationsdateien api.json und uchiwa.json überprüft, um sicherzustellen, dass sie über übereinstimmende Anmeldeinformationen verfügen.

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
  }
}

Der Versuch, direkt aus der Box heraus mit der sensu-API zu sprechen, führt ebenfalls zu einem Fehler von 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

Am Ende enthielten die Rabbitmq-Protokolle die Antwort. Ich sah, dass etwas nicht stimmte, aber die Nachrichten waren so kryptisch, dass ich nicht sagen konnte, was tatsächlich kaputt ging. Es stellte sich heraus, dass es sich um ein SSL-Problem handelte, das durch eine alte Version von Erlang verursacht wurde. Dies wurde von apt standardmäßig unter Ubuntu 14.04 (erlang Version R16B03) installiert.

Dieses Amqp-Problem hat mich auf die Lösung hingewiesen:

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

Ich musste auf Erlang> = 17.5 upgraden, dann funktionierte es wie erwartet.