Logs and troubleshooting (Release ONE): Difference between revisions

From OSM Public Wiki
Jump to: navigation, search
Line 63: Line 63:


In case it is not running try to see the last logs at /var/log/openmano/openmano.log
In case it is not running try to see the last logs at /var/log/openmano/openmano.log
'''TROUBLESHOOTING''': Possible known errors are:
'''Wrong database version'''
SYMPTOM: openmano service fails. At openmano logs appear:
<pre>2016-11-02T17:19:51 CRITICAL  openmano openmanod.py:268 DATABASE wrong version '0.15'.                                Try to upgrade/downgrade to version '0.16' with './database_utils/migrate_mano_db.sh'</pre>
CAUSE: Openmano has been upgraded with a new version that requieres a new database version.
SOLUTION: To upgrade de database version run ./database_utils/migrate_mano_db.sh and provide credentias if needed (by default database user is 'mano', and database password is 'manopw')
'''invalid openstack credentials'''
SYMPTOM: At deployment it appear the error message: Not possible to get_networks_list from VIM: AuthorizationFailure: Authorization Failed: The resource could not be found. (HTTPS: 404)
CAUSE: Openstack is not properly added to openmano with the right credentials
SOLUTION:  See the steps at [[OSM_Release_ONE#Openstack_site]]. If the problem persist ensure openstack is properly configured. Ensure you have access to the openstack endpoints (many times port 5000 is redirected using iptables, but other endpoints use other ports that must also be redirected). Can be checked using openstack client with:
sudo apt install python-openstackclient
openstack --os-project-id <auth-project-id> --os-url <auth-url>  --os-username <auth-username>  --os-password <auth-password> --debug network list #server list
#providing the same URL, credentials as you provide to openmano. The (--debug) will show more info so that you will see the IP/ports it try to access


====VCA status====
====VCA status====

Revision as of 17:39, 2 November 2016

Under elaboration

Logs

SO logs

UI logs

The server-side UI logs can be obtained on the SO-ub container at:

/usr/rift/usr/share/rw.ui/skyquake/err.log
/usr/rift/usr/share/rw.ui/skyquake/out.log

Client side UI logs can be obtained in the Developer Console in a browser.

RO logs

RO logs can be obtained on the RO container at:

/var/log/openmano/openmano.log

Log file and log level (debug by default) can be set at file:

/etc/default/openmanod.cfg

VCA logs

Troubleshooting

Checking status

SO status

UI status

  • The status of the UI process can be checked by running the following command in the SO-ub container as root:
forever list
  • You should see a status similar to following with an uptime:
info:    Forever processes running
data:        uid  command         script                                                                                                                 forever pid   id logfile                    uptime
data:    [0] uivz /usr/bin/nodejs skyquake.js --enable-https --keyfile-path=/usr/rift/etc/ssl/current.key --certfile-path=/usr/rift/etc/ssl/current.cert 21071   21082    /root/.forever/forever.log 0:18:12:3.231
  • In case the UI server process has issues, you won't see an uptime but will instead see a status "STOPPED" in that position.
  • In case the UI server process never started, you'll see a status saying "No forever processes running".

RO status

  • The status of the RO process can be checked by running the following command in the RO container as root:
 service openmano status
● openmano.service - openmano server
   Loaded: loaded (/etc/systemd/system/openmano.service; disabled; vendor preset: enabled)
   Active: active (running) since Wed 2016-11-02 16:50:21 UTC; 2s ago
 Main PID: 550 (python)
    Tasks: 1
   Memory: 51.2M
      CPU: 717ms
   CGroup: /system.slice/openmano.service
           └─550 python /opt/openmano/openmanod.py -c /opt/openmano/openmanod.cfg --log-file=/opt/openmano/logs/openmano.log

Nov 02 16:50:21 RO-integration systemd[1]: Started openmano server.

In case it is not running try to see the last logs at /var/log/openmano/openmano.log

TROUBLESHOOTING: Possible known errors are:

Wrong database version

SYMPTOM: openmano service fails. At openmano logs appear:

2016-11-02T17:19:51 CRITICAL  openmano openmanod.py:268 DATABASE wrong version '0.15'.                                 Try to upgrade/downgrade to version '0.16' with './database_utils/migrate_mano_db.sh'

CAUSE: Openmano has been upgraded with a new version that requieres a new database version.

SOLUTION: To upgrade de database version run ./database_utils/migrate_mano_db.sh and provide credentias if needed (by default database user is 'mano', and database password is 'manopw')

invalid openstack credentials

SYMPTOM: At deployment it appear the error message: Not possible to get_networks_list from VIM: AuthorizationFailure: Authorization Failed: The resource could not be found. (HTTPS: 404)

CAUSE: Openstack is not properly added to openmano with the right credentials

SOLUTION: See the steps at OSM_Release_ONE#Openstack_site. If the problem persist ensure openstack is properly configured. Ensure you have access to the openstack endpoints (many times port 5000 is redirected using iptables, but other endpoints use other ports that must also be redirected). Can be checked using openstack client with:

sudo apt install python-openstackclient
openstack --os-project-id <auth-project-id> --os-url <auth-url>   --os-username <auth-username>  --os-password <auth-password> --debug network list #server list
#providing the same URL, credentials as you provide to openmano. The (--debug) will show more info so that you will see the IP/ports it try to access

VCA status

Restarting services

Restarting SO

Restarting UI

  • The UI is restarted when the SO module (launchpad) is restarted.
  • However, in case just the UI needs to be restarted, you can run the following command in the SO-ub container as root:
forever restartall

Restarting RO

RO can be restarted on the RO container at:

service openmano restart

Restarting VCA