[ English | 日本語 | Deutsch | Indonesia ]

Logging

Dimana Log-nya?

Sebagian besar layanan menggunakan konvensi penulisan file log mereka ke subdirektori dari /var/log directory, sebagaimana tercantum dalam Tabel lokasi log OpenStack.

Tabel lokasi log OpenStack

Node type

Service

Log location

Cloud controller

nova-*

/var/log/nova

Cloud controller

glance-*

/var/log/glance

Cloud controller

cinder-*

/var/log/cinder

Cloud controller

keystone-*

/var/log/keystone

Cloud controller

neutron-*

/var/log/neutron

Cloud controller

horizon

/var/log/apache2/

All nodes

misc (swift, dnsmasq)

/var/log/syslog

Compute nodes

libvirt

/var/log/libvirt/libvirtd.log

Compute nodes

Console (boot up messages) for VM instances:

/var/lib/nova/instances/instance-<instance id>/console.log

Block Storage nodes

cinder-volume

/var/log/cinder/cinder-volume.log

Membaca Log

Layanan OpenStack menggunakan level logging standar, dengan tingkat keparahan (severity) meningkat: TRACE, DEBUG, INFO, AUDIT, WARNING, ERROR, dan CRITICAL. Artinya, pesan hanya muncul di log jika mereka lebih "severe" daripada tingkat log tertentu, dengan DEBUG memungkinkan semua pernyataan log dilalui. Misalnya, TRACE dicatat hanya jika perangkat lunak memiliki jejak tumpukan (stack trace), sementara INFO dicatat untuk setiap pesan termasuk yang hanya untuk informasi.

Untuk menonaktifkan logging tingkat DEBUG, edit file /etc/nova/nova.conf sebagai berikut:

debug=false

Keystone ditangani sedikit berbeda. Untuk memodifikasi level logging, edit file /etc/keystone/logging.conf dan lihat bagian logger_root dan handler_file.

Logging untuk horizon dikonfigurasi dalam /etc/openstack_dashboard/local_settings.py. Karena horizon adalah aplikasi web Django, ia mengikuti Django Logging framework conventions.

Langkah pertama dalam menemukan sumber kesalahan biasanya untuk mencari pesan CRITICAL, atau ERROR dalam log mulai dari bagian bawah file log.

Berikut adalah contoh dari pesan log dengan ERROR (Python traceback) yang sesuai segera berikut:

2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server [req-c0b38ace-2586-48ce-9336-6233efa1f035 6c9808c2c5044e1388a83a74da9364d5 e07f5395c
2eb428cafc41679e7deeab1 - default default] Exception during message handling
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server Traceback (most recent call last):
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 133, in _process_incoming
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     res = self.dispatcher.dispatch(message)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 150, in dispatch
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     return self._do_dispatch(endpoint, method, ctxt, args)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 121, in _do_dispatch
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     result = func(ctxt, **new_args)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/cinder/volume/manager.py", line 4366, in create_volume
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     allow_reschedule=allow_reschedule, volume=volume)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/cinder/volume/manager.py", line 634, in create_volume
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     _run_flow()
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/cinder/volume/manager.py", line 626, in _run_flow
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     flow_engine.run()
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/taskflow/engines/action_engine/engine.py", line 247, in run
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     for _state in self.run_iter(timeout=timeout):
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/taskflow/engines/action_engine/engine.py", line 340, in run_iter
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     failure.Failure.reraise_if_any(er_failures)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/taskflow/types/failure.py", line 336, in reraise_if_any
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     failures[0].reraise()
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/taskflow/types/failure.py", line 343, in reraise

Dalam contoh ini, cinder-volume gagal untuk memulai dan telah menyediakan jejak stack (stack trace), karena volume back end-nya tidak dapat mengatur volume penyimpanan— mungkin karena volume LVM yang diharapkan dari konfigurasi tidak ada .

Berikut ini contoh log kesalahan:

2013-02-25 20:26:33 6619 ERROR nova.openstack.common.rpc.common [-] AMQP server on localhost:5672 is unreachable:
 [Errno 111] ECONNREFUSED. Trying again in 23 seconds.

Dalam kesalahan ini, layanan nova telah gagal terhubung ke server RabbitMQ karena mendapat koneksi menolak kesalahan.

Melacak Permintaan Instance

Ketika sebuah instance gagal untuk berperilaku dengan benar, Anda akan sering harus melacak aktivitas yang terkait dengan instance tersebut di seluruh file log dari berbagai layanan ``nova- * `` dan di seluruh cloud controller dan compute nodes.

Cara tipikal adalah melacak UUID yang terkait dengan instance di seluruh log layanan.

Perhatikan contoh berikut:

$ openstack server list
+--------------------------------+--------+--------+--------------------------+------------+
| ID                             | Name   | Status | Networks                 | Image Name |
+--------------------------------+--------+--------+--------------------------+------------+
| fafed8-4a46-413b-b113-f1959ffe | cirros | ACTIVE | novanetwork=192.168.100.3| cirros     |
+--------------------------------------+--------+--------+--------------------+------------+

Di sini, ID yang terkait dengan instance adalah faf7ded8-4a46-413b-b113-f19590746ffe. Jika Anda mencari string ini pada pengontrol cloud di file /var/log/nova-*.log, muncul di nova-api.log dan `` nova-scheduler.log`` . Jika Anda mencari ini di compute nodes di /var/log/nova-*.log, muncul di nova-compute.log. Jika tidak ada pesan ERROR atau CRITICAL yang muncul, entri log terbaru yang melaporkan ini dapat memberikan petunjuk tentang apa yang salah.

Menambahkan Pernyataan Logging Kustom

Jika tidak ada informasi yang cukup di log yang ada, Anda mungkin perlu menambahkan pernyataan logging kustom Anda sendiri ke layanan ``nova- * ``.

File sumber terletak di /usr/lib/python2.7/dist-packages/nova.

Untuk menambahkan pernyataan logging, baris berikut harus di dekat bagian atas file. Untuk sebagian besar file, ini seharusnya sudah ada:

from nova.openstack.common import log as logging
LOG = logging.getLogger(__name__)

Untuk menambahkan pernyataan logging DEBUG, Anda harus melakukan:

LOG.debug("This is a custom debugging statement")

Anda mungkin memperhatikan bahwa semua pesan logging yang ada didahului dengan garis bawah dan dikelilingi oleh tanda kurung, misalnya:

LOG.debug(_("Logging statement appears here"))

Pemformatan ini digunakan untuk mendukung terjemahan pesan logging ke bahasa yang berbeda menggunakan gettext <https://docs.python.org/2/library/gettext.html> _ perpustakaan internasionalisasi. Anda tidak perlu melakukan ini untuk pesan log kustom Anda sendiri. Namun, jika Anda ingin berkontribusi kode kembali ke proyek OpenStack yang mencakup pernyataan logging, Anda harus mengelilingi pesan log Anda dengan garis bawah dan tanda kurung.

RabbitMQ Web Management Interface atau rabbitmqctl

Selain dari kegagalan koneksi, file log RabbitMQ umumnya tidak berguna untuk debugging masalah terkait OpenStack. Sebagai gantinya, kami sarankan Anda menggunakan antarmuka manajemen web RabbitMQ. Aktifkan di pengontrol cloud Anda:

# /usr/lib/rabbitmq/bin/rabbitmq-plugins enable rabbitmq_management
# service rabbitmq-server restart

Antarmuka manajemen web RabbitMQ dapat diakses di cloud controller Anda di http://localhost:55672.

Catatan

Ubuntu 12.04 menginstal RabbitMQ versi 2.7.1, yang menggunakan port 55672. Sebaliknya, RabbitMQ versi 3.0 dan di atasnya menggunakan port 15672. Anda dapat memeriksa versi RabbitMQ mana yang telah Anda jalankan di mesin Ubuntu lokal Anda dengan melakukan:

$ dpkg -s rabbitmq-server | grep "Version:"
Version: 2.7.1-0ubuntu4

Alternatif untuk mengaktifkan antarmuka manajemen web RabbitMQ adalah dengan menggunakan perintah rabbitmqctl. Sebagai contoh, rabbitmqctl list_queues| grep cinder menampilkan pesan apa pun yang tersisa di antrian. Jika ada pesan, itu kemungkinan pertanda bahwa layanan cinder tidak terhubung dengan benar ke rabbitmq dan mungkin harus dimulai ulang.

Item yang dipantau untuk RabbitMQ mencakup jumlah item di setiap antrian dan statistik waktu pemrosesan untuk server.

Mengelola Log Secara terpusat

Karena cloud Anda kemungkinan besar terdiri dari banyak server, Anda harus memeriksa log pada masing-masing server untuk menyatukan acara dengan benar. Solusi yang lebih baik adalah dengan mengirim log dari semua server ke lokasi pusat sehingga semuanya dapat diakses dari area yang sama.

Pilihan mesin logging pusat akan tergantung pada sistem operasi yang digunakan serta persyaratan organisasi untuk alat logging.

Pilihan syslog

Ada sejumlah besar mesin syslog yang tersedia, masing-masing memiliki kemampuan dan persyaratan konfigurasi yang berbeda.