[ English | Indonesia | Deutsch | 日本語 ]

Menentukan Komponen Yang Rusak

Koleksi OpenStack untuk berbagai komponen saling berinteraksi satu sama lain dengan kuat. Misalnya, mengunggah gambar memerlukan interaksi dari nova-api, glance-api, glance-registry, keystone, dan berpotensi swift-proxy. Akibatnya, terkadang sulit untuk menentukan dengan tepat di mana letak masalah. Membantu dalam hal ini adalah tujuan dari bagian ini.

Tailing Logs

Tempat pertama yang harus dilihat adalah file log yang terkait dengan perintah yang Anda coba jalankan. Sebagai contoh, jika openstack server list gagal, coba tailing file log nova dan jalankan perintah lagi:

Terminal 1:

# tail -f /var/log/nova/nova-api.log

Terminal 2:

# openstack server list

Cari kesalahan atau jejak dalam file log. Untuk informasi lebih lanjut, lihat :doc: ops-logging-monitoring.

Jika kesalahan menunjukkan bahwa masalahnya ada pada komponen lain, alihkan untuk menyesuaikan file log komponen itu. Misalnya, jika nova tidak dapat mengakses glance, lihat pada log glance-api:

Terminal 1:

# tail -f /var/log/glance/api.log

Terminal 2:

# openstack server list

Cuci, bilas, dan ulangi sampai Anda menemukan inti penyebab masalahnya.

Menjalankan Daemon di CLI

Sayangnya, terkadang kesalahan tidak terlihat dari file log. Dalam hal ini, alihkan taktik dan gunakan perintah yang berbeda; mungkin menjalankan layanan langsung pada command line. Misalnya, jika layanan glance-api menolak untuk memulai dan tetap berjalan, coba luncurkan daemon dari command line:

# sudo -u glance -H glance-api

Ini mungkin mencetak kesalahan dan penyebab masalah.

Catatan

Flag -H diperlukan ketika menjalankan daemon dengan sudo karena beberapa daemon akan menulis file relatif ke direktori home pengguna, dan penulisan ini mungkin gagal jika -H ditinggalkan.

Tip

Example of Complexity

Suatu pagi, sebuah compute node gagal menjalankan instance. File log agak kabur, mengklaim bahwa instance tertentu tidak dapat dimulai. Ini akhirnya menjadi red herring karena instance hanyalah instance pertama dalam urutan abjad, jadi itu adalah instance pertama yang akan disentuh nova-compute.

Pemecahan masalah lebih lanjut menunjukkan bahwa libvirt tidak berjalan sama sekali. Ini lebih masuk akal. Jika libvirt tidak berjalan, maka tidak ada instance yang dapat divirtualisasikan melalui KVM. Setelah mencoba memulai libvirt, ia akan segera mati secara diam-diam. Log libvirt tidak menjelaskan alasannya.

Selanjutnya, daemon libvirtd dijalankan pada command line. Akhirnya muncul pesan kesalahan yang bermanfaat: tidak dapat terhubung ke d-bus. Kedengarannya konyol, libvirt, dan karenanya nova-compute, bergantung pada d-bus dan entah bagaimana d-bus jatuh. Cukup memulai d-bus, atur seluruh rantai kembali ke jalurnya, dan segera semuanya kembali dan berjalan.