[ English | Indonesia | Deutsch | 日本語 ]
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.
Node type |
Service |
Log location |
|---|---|---|
Cloud controller |
|
|
Cloud controller |
|
|
Cloud controller |
|
|
Cloud controller |
|
|
Cloud controller |
|
|
Cloud controller |
horizon |
|
All nodes |
misc (swift, dnsmasq) |
|
Compute nodes |
libvirt |
|
Compute nodes |
Console (boot up messages) for VM instances: |
|
Block Storage nodes |
cinder-volume |
|
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.
