Oleh:
MENGETAHUI:
Kepala SMK Negeri 1 Cimahi
i
Akhir kata, penulis berharap semoga laporan ini dapat bermanfaat bagi semua
pihak yang memerlukan.
Bogor, Januari 2022
Penulis
ii
DAFTAR ISI
3.3 OpenStack............................................................................................... 15
iii
BAB V PENUTUP ................................................................................................ 95
LAMPIRAN .......................................................................................................... 98
iv
DAFTAR GAMBAR
Gambar 2.6 Struktur Organisasi Tech Talent Delivery PT Boer Technology ........ 8
v
Gambar 4.5 Pembuatan Pasangan Kunci SSH ...................................................... 28
Gambar 4.9 Proses Pembuatan dan Pengaktifan Virtual Environment Python .... 31
Gambar 4.22 Proses Bootsrap Servers Pada Proses Deploy OpenStack .............. 38
vi
Gambar 4.29 Proses Instalasi Elasticsearch .......................................................... 42
Gambar 4.32 Proses Setup Kata Sandi Untuk Built-in User Pada Elasticsearch .. 44
Gambar 4.45 Penambahan Repositori Elastic Versi 8.x Pada Node controller .... 50
Gambar 4.46 Proses Instalasi Filebeat Pada OpenStack Cluster Nodes ............... 51
Gambar 4.52 Proses Menyalin Kunci Privat Hasil Konversi dan Server Certificate
............................................................................................................................... 54
vii
Gambar 4.53 Isi Dari File /etc/logstash/conf.d/10-input.conf .............................. 55
Gambar 4.54 Proses Menyalin CA certificate Untuk Client Dari Node elastic ke
OpenStack Cluster Nodes Menggunakan Tool SCP ............................................. 56
Gambar 4.55 Proses Menyalin File ca.crt ke /etc/filebeat dan /etc/metricbeat Pada
Node controller ...................................................................................................... 56
Gambar 4.58 Salah Satu Contoh Pendefinisian Log yang Akan Dipilih .............. 58
Gambar 4.76 Konfigurasi Metric yang Digunakan Pada Visualisasi Nomor 1 .... 69
viii
Gambar 4.77 Konfigurasi Metric yang Digunakan Pada Visualisasi Nomor 2 .... 70
Gambar 4.78 Konfigurasi Metric yang Digunakan Pada Visualisasi Nomor 3 .... 71
Gambar 4.79 Konfigurasi Metric yang Digunakan Pada Visualisasi Nomor 4 .... 72
Gambar 4.80 Konfigurasi Metric yang Digunakan Pada Visualisasi Nomor 5 .... 73
Gambar 4.81 Konfigurasi Metric yang Digunakan Pada Visualisasi Nomor 6 .... 74
Gambar 4.82 Konfigurasi Metric yang Digunakan Pada Visualisasi Nomor 7 .... 75
Gambar 4.83 Tombol Untuk Menambahkan Visualisasi Jenis Time Series ......... 76
Gambar 4.85 Konfigurasi Form Data Time Series Untuk Visualisasi Nomor 8
Pada Node Controller ............................................................................................ 77
Gambar 4.86 Konfigurasi Form Data Time Series Untuk Visualisasi Nomor 8
Pada Node Compute1 ............................................................................................ 78
Gambar 4.87 Konfigurasi Form Data Time Series Untuk Visualisasi Nomor 8
Pada Node Compute2 ............................................................................................ 78
Gambar 4.89 Tombol Untuk Menambahkan Visualisasi Jenis Time Series ......... 79
Gambar 4.91 Konfigurasi Form Data Time Series Untuk Visualisasi Nomor 9
Pada Node Controller ............................................................................................ 80
Gambar 4.92 Konfigurasi Form Data Time Series Untuk Visualisasi Nomor 9
Pada Node Compute1 ............................................................................................ 81
Gambar 4.93 Konfigurasi Form Data Time Series Untuk Visualisasi Nomor 9
Pada Node Compute2 ............................................................................................ 81
Gambar 4.96 Index Pattern yang Digunakan Untuk Visualisasi Nomor 10 ......... 82
Gambar 4.97 Konfigurasi Vertical Axis Nomor 1 Pada Visualisasi Nomor 10 ... 82
ix
Gambar 4.98 Konfigurasi Vertical Axis Nomor 2 Pada Visualisasi Nomor 10 ... 83
Gambar 4.99 Index Pattern yang Dipakai Untuk Visualisasi Nomor 11 .............. 84
Gambar 4.110 Index Pattern yang Digunakan Untuk Visualisasi Nomor 10 ....... 88
Gambar 4.114 Monitoring Penggunaan CPU Pada OpenStack Cluster Nodes .... 91
Gambar 4.115 Monitoring Penggunaan RAM Pada OpenStack Cluster Nodes ... 91
Gambar 4.116 Jumlah Instance yang Sedang Berjalan Pada Layanan Nova ....... 92
Gambar 4.117 Jumlah Core yang Sudah Terpakai dan Belum Terpakai .............. 92
Gambar 4.118 Jumlah RAM yang Sudah Terpakai dan Belum Terpakai ............. 93
Gambar 4.119 Jumlah Penyimpanan yang Sudah Terpakai dan Belum Terpakai 93
Gambar 5.1 Contoh Arsitektur Multi-node Cluster Pada Elastic Stack ................ 95
x
DAFTAR LAMPIRAN
xi
BAB I
PENDAHULUAN
1
2
maupun metrics dari tiap node, kemudian dikirim ke Logstash untuk diurai dan
diubah menjadi informasi yang lebih berguna, lalu disimpan di Elasticsearch yang
memiliki fitur search engine, kemudian terakhir divisualisasikan oleh Kibana agar
kumpulan logs maupun metrics dari tiap node menjadi lebih informatif.
Dengan demikian dengan menggunakan Elastic Stack, engineer hanya perlu
masuk ke dashboard Kibana untuk mencari kesalahan maupun monitoring node
pada OpenStack.
Berdasarkan hal tersebut, maka penulis mengambil laporan dengan judul:
“Sentralisasi Log dan Monitoring Node pada OpenStack menggunakan Elastic
Stack”.
1.2 Tujuan
Berdasarkan latar belakang masalah tersebut, penulis memiliki tujuan berupa
mengimplementasikan sentralisasi log dan monitoring pada OpenStack Cluster
sehingga hanya perlu masuk ke dashboard Kibana untuk mencari error maupun
monitoring pada OpenStack.
4
5
10
11
b. Topologi Star
Jenis Topologi Star adalah susunan jaringan di mana setiap node
terhubung ke hub pusat, kabel switch atau komputer pusat. Topologi ini
merupakan salah satu topologi terpopuler. Komputer pusat dikenal juga
sebagai server, dan perangkat periferal yang terhubung ke server dikenal
sebagai client.
c. Topologi Ring
Jenis topologi ring sama seperti topologi bus, tetapi dengan ujung-
ujung yang terhubung. Data mengalir dalam satu loop tunggal yang dikenal
sebagai loop tak berujung.
Node yang menerima pesan dari perangkat sebelumnya akan
mengirimkan semua data ke node berikutnya. Data mengalir dalam satu arah
dan mengalir searah jarum jam. Topologi ring tidak memiliki ujung akhir,
jadi setiap node terhubung ke node lain dan tidak memiliki titik akhir.
12
d. Topologi Mesh
Topologi Mesh adalah suatu jaringan komputer dimana bentuk koneksi
antar perangkat komputer saling terhubung secara langsung antara satu
dengan yang lainnya dalam suatu jaringan.
Dalam topologi mesh , masing-masing perangkat komputer dalam satu
jaringan dapat saling berkomunikasi langsung karena saling terhubung satu
sama lain, atau disebut dengan dedicated links. Topologi Mesh umumnya
dibuat untuk jaringan yang skalanya tidak terlalu besar dan membutuhkan
komunikasi antar perangkat dengan cepat.
3.3 OpenStack
Nova adalah kompnoen pada OpenStack yang digunakan untuk deploy dan
mengelola virtual machine atau biasa disebut instance untuk menangani tugas
komputasi. (Kumar, Gupta, Charu, Jain, & Jangir, 2014)
Agar Nova dapat berjalan, secara minimal membutuhkan beberapa komponen
lainnya yaitu Keystone, Glance, Neutron, dan Placement. (OpenStack, 2020)
3.3.2 Cinder (Block Storage)
Cinder adalah komponen yang berfungsi untuk menyediakan block storage.
Lebih jelasnya, Cinder mengelola untuk pembuatan, pemasangan dan pelepasan
sebuah block storage ke sebuah instance. (Kumar, Gupta, Charu, Jain, & Jangir,
2014)
3.3.3 Neutron (Networking)
Neutron merupakan komponen yang menyediakan kemampuan networking
untuk OpenStack dan merupakan sebuah layanan untuk mengelola jaringan dan
alamat IP pada instancee dengan mudah, cepat dan efisien. (Kumar, Gupta, Charu,
Jain, & Jangir, 2014)
3.3.4 Horizon (Dashboard)
Horizon merupakan salah satu komponen pada openstack yang berfungsi
sebagai dashboard yang menyediakan antarmuka grafis bagi administrator ataupun
pengguna untuk mengakses, menyediakan, dan mengotomatiskan sumber daya
pada OpenStack. (Kumar, Gupta, Charu, Jain, & Jangir, 2014)
3.3.5 Keystone (Identity Service)
Keystone merupakan komponen yang menyediakan layanan identitas untuk
OpenStack. Komponen ini menyediakan berbagai jenis cara akses, serta bertindak
sebagai sistem otentikasi umum untuk semua komponen pada OpenStack. (Kumar,
Gupta, Charu, Jain, & Jangir, 2014)
3.3.6 Glance (Image Service)
Glance merupakan komponen yang menyediakan layanan pengelolaan image
untuk OpenStack seperti pencarian, penghapusan atau pembuatan image.
Komponen ini juga menyediakan image untuk digunakan sebagai template saat
membuat instance baru. (Kumar, Gupta, Charu, Jain, & Jangir, 2014)
3.3.7 Placement
17
Placement adalah REST API Stack dan model data yang digunakan untuk
melacak inventaris dan penggunaan penyedia sumber daya. Misalnya, penyedia
sumber daya dapat berupa node komputasi, kumpulan penyimpanan bersama, atau
kumpulan alokasi IP.
Layanan Placement melacak inventaris dan penggunaan setiap sumber daya.
Misalnya, instance yang dibuat pada node compute mungkin merupakan konsumen
sumber daya seperti RAM dan CPU dari penyedia sumber daya node komputasi,
disk dari penyedia sumber daya kumpulan penyimpanan dan alamat IP dari
penyedia sumber daya kumpulan IP eksternal. (OpenStack, 2019)
3.4 Kolla-Ansible
Kolla adalah sebuah project dari komunitas OpenStack yang menyediakan
container siap produksi dan alat penerapan untuk mengoperasikan cloud OpenStack
yang dapat diskalakan, cepat, dan andal. (OpenStack, 2015)
Sedangkan Kolla-Ansible adalah sebuah tool yang bertujuan untuk
menggantikan proses deployment OpenStack yang tidak fleksibel, sulit, dan
penggunaan sumber daya yang intensif dengan proses deployment yang fleksibel,
tidak sulit, dan murah. (OpenStack, 2018)
Kolla-Ansible melakukan proses deploy OpenStack dalam container
menggunakan container Kolla, yang diotomatisasikan oleh Ansible. Proyek ini
bertujuan untuk kesederhanaan dan keandalan, sambil menyediakan model
konfigurasi yang fleksibel dan intuitif. (OpenStack, 2022)
Elastic Stack merupakan pembaharuan istilah dari ELK Stack, pada ELK
Stack hanya tools yang digunakan adalah Elasticsearch, Logstash, dan Kibana;
sedangkan pada Elastic Stack ditambahkan tool baru yaitu Beats. (Kong, Xian, Liu,
& Wang, 2020)
18
3.5.1 Elasticsearch
Logstash adalah sebuah tool open source yang berfungsi sebagai mesin
pengumpulan data dengan kemampuan pipelining secara real-time. Logstash dapat
secara dinamis menyatukan data dari sumber yang berbeda dan mengolah data
kemudian dikirim ke tujuan pilihan. (Elastic, 2022)
3.5.3 Kibana
Beats adalah sekumpulan tools yang berfungsi untuk mengumpulkan data dan
mengirimkannya ke pengolah data (misalnya Logstash). Ada banyak pilihan
kolektor. (Kotenko, Kuleshov, & Ushakov, 2017)
a. Filebeat, mengumpulkan dan mengirimkan file log sistem maupun file
yang berisi informasi teks secara dinamis ke pengolah data misalnya
Logstash. (Kotenko, Kuleshov, & Ushakov, 2017)
b. Winlogbeat, digunakan untuk mengumpulkan dan mengirimkan log
sistem Windows ke pengolah data misalnya Logstash. (Kotenko,
Kuleshov, & Ushakov, 2017)
c. Packetbeat adalah penganalisis paket jaringan, yang mengirimkan
informasi tentang aktivitas jaringan. Packetbeat menangkap lalu lintas
20
4.1 Analisis
Pada sub-bab ini, penulis akan menganalisis tentang sistem yang akan dibuat
oleh penulis.
4.1.1 Deskripsi umum sistem
Sistem Sentralisasi Log dan Monitoring Node Pada OpenStack Menggunakan
Elastic Stack adalah sebuah sistem yang menyediakan manajemen log dan
monitoring tersentralisasi pada sebuah OpenStack cluster. Penulis memilih sistem
ini agar saat pencarian error saat proses troubleshooting dan monitoring
resources(pemakaian CPU dan Memory) oleh engineer dapat dilakukan lewat
dashboard, sehingga mengurangi durasi saat proses troubleshooting maupun
monitoring pada OpenStack Cluster. Penulis membangun sistem ini karena
mengetahui bahwa logs yang dihasilkan OpenStack sangat banyak dan tersebar di
semua node, sehingga seringkali membuat engineer harus login ke setiap node
untuk melihat file log mentah yang sangat banyak untuk mencari masalah.
4.1.2 Analisis kebutuhan pengguna
Pengguna memiliki servers on-premise yang ingin dijadikan private cloud
pada perusahaannya. Karena private cloud membutuhkan banyak node untuk
bekerja dan menghasilkan banyak log yang kompleks sehingga sering kali
kesusahan dalam proses troubleshooting, maka pengguna tersebut memerlukan
solusi untuk dapat memantau penggunaan sumber daya pada banyak nodes tersebut
dan mengelola banyak log yang kompleks tersebut.
Oleh karena itu, Sistem Sentralisasi Log dan Monitoring Node Pada
OpenStack Menggunakan Elastic Stack dapat menjadi solusi yang tepat. Pada
Elastic Stack tersebut sudah terdapat fungsi monitoring maupun fungsi sentralisasi
log dan sudah terdapat dashboard. Sehingga pengguna hanya perlu mengakses
dashboard untuk memantau penggunaan sumber daya dan mengelola log yang
kompleks tersebut.
21
22
- Disk :
o /dev/vda 20 GB untuk root (/)
o /dev/vdb 15 GB untuk layanan Cinder
2) Satu virtual machine yang berfungsi sebagai tempat instalasi
Elasticsearch, Logstash, dan Kibana dengan spesifikasi:
- Sistem operasi : Ubuntu 18.04 LTS
- RAM : 8 GB
- CPU : 4 cores
- Disk : /dev/vda 25 GB untuk root (/)
4.2 Perencanaan
Pada sub-bab ini, penulis akan menjelaskan perencanaan tentang sistem yang
akan dibuat oleh penulis.
4.2.1 Topologi
Topologi yang digunakan untuk sistem ini ada pada gambar 4.1. Pada gambar
4.1 tersebut terdapat 4 node, dimana 3 node sebagai OpenStack cluster dan 1 node
sebagai Elastic Stack node. Topologi tersebut memiliki dua jaringan, jaringan
pertama yaitu Management Network yang merupakan jaringan untuk mengelola
cluster. Jaringan kedua yaitu External Network yang digunakan sebagai jaringan
khusus yang dialokasikan untuk Floating IP dari instance pada OpenStack.
24
4.3 Implementasi
Pada bagian implementasi, penulis mengelompokan lagi menjadi beberapa
bagian tahapan. Maka penulis langsung saja menguraikan apa saja bagian
tahapannya serta isi dari tiap bagian tahapannya.
4.3.1 Persiapan environment
Sebelum memulai implementasi sentralisasi log dan monitoring node, penulis
melakukan persiapan environment terlebih dahulu. Pada bagian ini, penulis
menguraikain persiapan environment yang akan digunakan oleh proyek ini.
Perlu diketahui bahwa IP address telah dikonfigurasi pada saat pembuatan
VM oleh perusahaan. Sehingga pada bagian persiapan environment ini tidak perlu
mengubah IP address.
26
cluster. Oleh karena itu pada bagian tahapan ini, penulis menguraikan bagaimana
cara deploy OpenStack cluster.
a. Memperbaharui repositori pada node controller
Tahapan pertama sebelum deploy adalah memperbaharui repositori
pada node controller dengan menggunakan perintah sudo apt update -y yang
sesuai dengan gambar 4.7.
Pada tahapan ini, penulis membuat kata sandi secara acak yang nantinya
akan disimpan pada file /etc/kolla/passwords.yml yang akan digunakan oleh
OpenStack cluster. Perintah untuk melakukan tahapan ini adalah kolla-
genpwd seperti pada gambar 4.18.
d. Instalasi Elasticsearch
42
f. Konfigurasi Elasticsearch
43
Gambar 4.32 Proses Setup Kata Sandi Untuk Built-in User Pada Elasticsearch
c. Konfigurasi Kibana
Pada tahap ini, penulis mengkonfigurasi file /etc/kibana/kibana.yml
dengan hanya mengisikan 2 baris konfigurasi, yaitu:
1) Baris server.host: “0.0.0.0” agar Kibana bisa diakses dari alamat
IP manapun
47
e. Restart Kibana
Setelah mengatur kata sandi, penulis melakukan restart layanan Kibana
menggunakan perintah sudo systemctl restart kibana yang sesuai dengan
gambar 4.40.
f. Verifikasi Kibana
Pada tahapan ini, penulis memverifikas bahwa Kibana sudah bisa
diakses dengan mengakses ke alamat IP lewat tunneling menggunakan
browser. Pada gambar 4.41 menunjukan bahwa Kibana sudah bisa diakses.
Gambar 4.45 Penambahan Repositori Elastic Versi 8.x Pada Node controller
c. Instalasi Metricbeat
Untuk menginstal Metricbeat, penulis menggunakan perintah sudo apt
-y install metricbeat yang dijalankan pada node controller, compute1, dan
compute2. Karena tangkapan layarnya sama, maka penulis hanya
mencantumkan pada node controller yang ada pada gambar 4.47.
Karena Beats dan Logstash tidak dalam 1 node yang sama, maka penulis
mengenkripsi komunikasi antara Beats dan Logstash dengan menggunakan
SSL/TLS.
a. Membuat CA certificate dan server certificate pada node elastic
Untuk membuat CA certificate dan server certificate penulis
menggunakan tool dari Elasticsearch yaitu elasticsearch-certutil. Sebelum
membuatnya, buat file cert.yml terlebih dahulu dan isikan sehingga seperti
pada gambar 4.48.
Gambar 4.52 Proses Menyalin Kunci Privat Hasil Konversi dan Server Certificate
55
Gambar 4.54 Proses Menyalin CA certificate Untuk Client Dari Node elastic ke
OpenStack Cluster Nodes Menggunakan Tool SCP
Gambar 4.55 Proses Menyalin File ca.crt ke /etc/filebeat dan /etc/metricbeat Pada
Node controller
Saat dijalankan, script ini menghasilkan stats data yang berbentuk JSON.
Nantinya ouput dari script ini akan menjadi input pada Logstash, kemudian diolah
oleh Logstash. Script ini penulis simpan pada node elastic dan lokasinya ada di
direktori /script-python/.
4.3.9 Konfigurasi Filebeat
Tahapan ini berfungsi agar log yang telah ditentukan diambil dan dikirimkan
oleh Filebeat ke Logstash. Pada tahap ini, penulis akan mengkonfigurasi
58
Gambar 4.58 Salah Satu Contoh Pendefinisian Log yang Akan Dipilih
Pada gambar 4.58, penulis mengambil contoh untuk log yang letaknya di
/var/log/kolla/nova/nova-compute.log dengan penjelasan sebagai berikut:
a. Pada baris path berfungsi untuk mendefinisikan lokasi dari log yang
akan diambil,
b. Pada baris fields berfungsi untuk menambahkan kolom pada tiap baris
log tersebut, pada contoh ini penulis memberikan kolom keterangan
berupa ”log_type: openstack.nova.compute” yang kolom keterangan
ini nantinya akan berguna untuk mengelompokan log dan filtering log
pada Logstash dan Kibana,
c. Pada baris multiline berfungsi untuk mengkonfigurasi bahwa jika ada
salah satu baris pada log sesuai dengan pattern yang diberikan, berarti
baris log tersebut merupakan log yang terdiri dari beberapa baris log.
Untuk memperjelas multiline log maka penulis menyertakan contoh dari
multiline log pada gambar 4.59. Jika penulis tidak mengkonfigurasi multiline maka
multiline log tersebut akan terpisah-terpisah dan menjadi data yang tidak berarti.
59
Pada tahap ini, penulis hanya mengkonfigurasi pada beberapa baris, yaitu
pada baris yang ditandai pada gambar 4.60. Pada baris yang ditandai itu berfungsi
agar data yang dikirim dari Metricbeat ditambahkan kolom “log_type: metricbeat”
agar nantinya bisa difilter oleh Logstash.
4.3.11 Konfigurasi Logstash
Pada tahapan ini penulis mengkonfigurasi Logstash pada node elastic agar
log yang telah diterima oleh Logstash dapat dibaca dan diolah dengan mudah pada
Kibana.
a. Konfigurasi precision timestamp menggunakan Ruby filter plugin
Disini penulis mengkonfigurasi Logstash agar dapat mengolah data log
yang timestamp nya memiliki kepresisian waktu hingga nanosecond. Hal
pertama yang dilakukan penulis adalah mengunduh script Ruby yang
berfungsi untuk mengolah timestamp yang memiliki kepresisian waktu
hingga nanosecond. Perintah untuk mengunduh script ini adalah wget
https://gist.githubusercontent.com/yaauie/9bd825578a4f32d3937fe106adfe3
448/raw/3fc4bcd412578bb3c4f3126f4ace048e948d71d8/precision-
timestamp-parse.logstash-filter-ruby.rb -P /etc/logstash/rubyfilter.
Hasil unduhan tersebut nantinya akan digunakan pada konfigurasi filter
Logstash.
b. Konfigurasi input Logstash
Disini, penulis mengkonfgurasi input dari Logstash. Pada Proyek ini,
penulis memasukan 2 input, yaitu:
1) Input dari Beats yang telah dikonfigurasi pada poin d dari sub sub-
bab 4.3.7 pada saat mengkonfigurasi komunikasi antara Beats dan
Logstash,
2) Input dari script Python.
Dari kedua input itu, maka isi dari file /etc/logstash/conf.d/10-
input.conf sesuai dengan gambar 4.61. Untuk konfigurasi input dari
Beats penulis tandai dengan persegi panjang kuning pada gambar 4.61.
Sedangkan untuk konfigurasi input dari script Python, penulis tandai
dengan persegi panjang merah pada gambar 4.61.
61
Kemudian, isikan pada form sesuai dengan gambar 4.66 dimana pada
Role name penulis mengisi dengan nama dari role yang akan dibuat.
Selanjutnya pada Cluster privileges penulis mengisi dengan
manage_index_templates dan manage. Kemudian pada Index privileges
penulis mengisi dengan Indices * dan Privileges all. Setelah mengisi form,
tekan tombol Create role seperti pada gambar 4.65.
Setelah menekan tombol Users, maka tekan tombol Create user seperti
pada gambar 4.68 untuk membuat user. Kemudian, isikan pada form sesuai
dengan gambar 4.69 dimana pada Username penulis mengisi dengan nama
dari user yang akan dibuat . Selanjutnya pada Password penulis mengisi kata
sandi yang akan digunakan. Kemudian pada Privileges penulis mengisi
dengan role manage-index yang sudah dibuat pada tahapan sebelumnya.
Setelah mengisi form, tekan tombol Create user seperti pada gambar 4.68.
Dari semua visualisasi data tersebut, penulis akan menjelaskan satu per
satu cara pembuatannya. Langkah pertama yang dilakukan penulis adalah
membuat dashboard baru terlebih dahulu. Tekan tombol Menu kemudian
pada bagian Analytics tekan Dashboard sesuai pada gambar 4.71.
Setelah itu pilih tab Time Series seperti pada tanda nomor 1 di gambar
4.84, kemudian tekan tombol tambah yang ada pada tanda nomor 2 di gambar
4.84 sebanyak 2 kali sehingga form data menjadi 3. Kemudian atur warna dan
nama sesuai hostname pada OpenStack cluster nodes seperti pada gambar
4.84.
77
Gambar 4.85 Konfigurasi Form Data Time Series Untuk Visualisasi Nomor 8
Pada Node Controller
78
Kemudian pada gambar 4.86 untuk node compute1 dan gambar 4.87
untuk node compute2.
Gambar 4.86 Konfigurasi Form Data Time Series Untuk Visualisasi Nomor 8
Pada Node Compute1
Gambar 4.87 Konfigurasi Form Data Time Series Untuk Visualisasi Nomor 8
Pada Node Compute2
Setelah itu pilih tab Time Series seperti pada tanda nomor 1 di gambar
4.90, kemudian tekan tombol tambah seperti pada tanda nomor 2 di gambar
4.90 sebanyak 2 kali sehingga form data menjadi 3. Kemudian atur warna dan
nama sesuai hostname pada OpenStack cluster nodes seperti pada gambar
4.90.
80
Gambar 4.91 Konfigurasi Form Data Time Series Untuk Visualisasi Nomor 9
Pada Node Controller
Kemudian pada gambar 4.92 untuk node compute1 dan gambar 4.93
untuk node compute2.
81
Gambar 4.92 Konfigurasi Form Data Time Series Untuk Visualisasi Nomor 9
Pada Node Compute1
Gambar 4.93 Konfigurasi Form Data Time Series Untuk Visualisasi Nomor 9
Pada Node Compute2
Setelah itu, pada Visualization type pilih Bar vertical stacked seperti
pada gambar 4.95.
Setelah itu, pada Visualization type pilih Bar vertical stacked seperti
pada gambar 4.109.
Pada konfigurasi Vertical axis yang ada pada gambar 4.111, penulis
mengisi beberapa form. Untuk form Select a function berfungsi untuk
menentukan fungsi yang digunakan. Pada konfigurasi ini, penulis mengisinya
dengan Count yang artinya menghitung jumlah log yang sesuain dengan
filter.
89
Untuk form Select a field berfungsi untuk field mana yang akan
dihitung. Disini penulis mengisi dengan Records yang artinya semua records
akan dihitung. Kemudian untuk form Filter by berfungsi untuk menentukan
kondisi log yang akan dihitung. Disini penulis mengisi filter dengan kondisi
jika log_level:”ERROR”.
Kemudian ada form Display name untuk menentukan nama. Kemudian
ada form Value format untuk menentukan jenis format nilainya. Disini
penulis mengisi Value format dengan default.
4.4 Pengujian
Pada bagian pengujian, penulis melakukan pengujian dengan beberapa
skenario. Penulis langsung saja menguraikan apa saja pengujian yang dilakukan
serta bagaimana hasil pengujian tersebut.
4.4.1 Menampilkan jumlah error pada setiap layanan OpenStack
Pada pengujian ini, penulis menguji bahwa dashboard pada Kibana telah
menampilkan jumlah error yang ada pada setiap layanan OpenStack. Sebelumnya,
penulis dengan sengaja mematikan layanan Nova compute pada node compute2
untuk menguji bahwa error tersebut dapat terdeteksi oleh Elastic Stack ini. Pada
gambar 4.112 diketahui bahwa pada layanan Nova compute dan Placement api
mengalami error pada sekitar pukul 18:29:30 WIB. Layanan Placement api ini
berfungsi untuk melacak sumber daya pada OpenStack cluster. Pada pengujian ini,
layanan Placement terdapat error dikarenakan sumber daya yang berupa compute
tidak merespon.
90
Solusi untuk error ini, penulis menyalakan kembali layanan Nova compute
pada node compute2.
4.4.3 Monitoring penggunaan CPU pada OpenStack Cluster Nodes
Pada pengujian selanjutnya, penulis menguji bahwa penulis bisa memantau
penggunaan CPU pada OpenStack cluster nodes(node controller, compute1, dan
compute2). Pada gambar 4.114, dapat diketahui bahwa pada pukul 20.35 WIB
penggunaan CPU pada node controller sebesar 9.736%, kemudian pada node
compute1 sebesar 1.901%, sedangkan pada node compute2 sebesar 1.925%.
91
4.4.5 Mengetahui jumlah instance yang telah dibuat pada layanan Nova
Pada pengujian selanjutnya, penulis menguji bahwa penulis dapat mengetahui
jumlah instance yang telah dibuat pada layanan Nova. Pada gambar 4.116, dapat
diketahui bahwa instance yang telah dibuat pada layanan Nova berjumlah 1.
Gambar 4.116 Jumlah Instance yang Sedang Berjalan Pada Layanan Nova
4.4.6 Mengetahui jumlah core yang terpakai dan belum terpakai oleh Nova
instance
Pada pengujian selanjutnya, penulis menguji bahwa penulis dapat mengetahui
jumlah core yang terpakai maupun belum terpakai oleh layanan Nova. Pada gambar
4.117, dapat diketahui bahwa jumlah core yang terpakai oleh layanan Nova
berjumlah 1 dan belum terpakai berjumlah 7.
Gambar 4.117 Jumlah Core yang Sudah Terpakai dan Belum Terpakai
Gambar 4.118 Jumlah RAM yang Sudah Terpakai dan Belum Terpakai
Gambar 4.119 Jumlah Penyimpanan yang Sudah Terpakai dan Belum Terpakai
Selain itu, pada gambar 4.122, penulis juga dapat melihat jumlah percobaan
login yang sukses maupun gagal.
5.1 Kesimpulan
Dari hasil riset implementasi sistem sentralisasi log dan monitoring pada
OpenStack, penulis dapat menyimpulkan bahwa dengan sistem ini engineer dapat
mencari masalah dan memantau sumber daya komputasi pada OpenStack hanya
dengan membuka dashboard pada Kibana sesuai dengan bukti pada pengujian yang
dilakukan penulis menggunakan dashboard pada Kibana.
5.2 Saran
Setelah mengerjakan project ini, penulis ingin menyampaikan saran bagi para
pembaca yaitu jika ingin mengimplementasikan sistem ini untuk lingkungan
produksi, penulis menyarankan agar menginstal Elastic Stack secara multi-node
cluster sehingga beban kerja tidak hanya terpusat pada satu node.
Pada gambar 5.1, merupakan salah satu contoh arsitektur multi-node cluster
pada Elastic Stack. Pada gambar 5.1 setiap node memiliki perannya masing-masing,
Sedangkan pada arsitektur yang dibuat oleh penulis, satu node berperan sebagai
tempat diinstalnya Elasticsearch, Logstash, dan Kibana.
95
DAFTAR PUSTAKA
Almási, G., Castaños, J. G., Franke, H., & Silva, M. A. (2016). Toward building
highly available and scalable OpenStack clouds. IBM Journal of Research
and Development, 5:1.
Dillon, T., Wu, C., & Chang, E. (2010). Cloud Computing: Issues and Challenges.
2010 24th IEEE International Conference on Advanced Information
Networking and Applications, 28.
Elastic. (2022). Kibana—your window into Elastic | Kibana Guide [7.16] | Elastic.
Diambil kembali dari Elastic.co:
https://www.elastic.co/guide/en/kibana/current/introduction.html
Elastic. (2022). Logstash Introduction | Logstash Reference [7.16] | Elastic.
Diambil kembali dari Elastic.co:
https://www.elastic.co/guide/en/logstash/current/introduction.html
Kong, C., Xian, M., Liu, J., & Wang, C. (2020). A small LAN Zero Trust network
model based on Elastic Stack. 5th International Conference on Mechanical,
Control and Computer Engineering (ICMCCE), 1075.
Kotenko, I., Kuleshov, A., & Ushakov, I. (2017). Aggregation of elastic stack
instruments for collecting, storing and processing of security information
and events. 2017 IEEE SmartWorld, Ubiquitous Intelligence & Computing,
Advanced & Trusted Computed, Scalable Computing & Communications,
Cloud & Big Data Computing, Internet of People and Smart City Innovation
(SmartWorld/SCALCOM/UIC/ATC/CBDCom/IOP/SCI).
Kumar, M. D., & B. Deepa. (2015). Computer Networking: A Survey. International
Journal of Trend in Research and Development, Volume 2(5), ISSN 2394-
9333, 126.
Kumar, R., Gupta, N., Charu, S., Jain, K., & Jangir, K. K. (2014). Open Source
Solution for Cloud Computing Platform Using OpenStack. International
Journal of Computer Science and Mobile Computing, Vol.3 Issue.5, 93.
OpenStack. (2015). Kolla - OpenStack. Diambil kembali dari Openstack.org:
https://wiki.openstack.org/wiki/Kolla
96
97
98
99
multiline.negate: true
multiline.match: after
- type: log
enabled: true
paths:
- /var/log/kolla/haproxy/haproxy_latest.*.log
fields:
log_type: openstack.haproxy
- type: log
enabled: true
paths:
- /var/log/kolla/heat/heat-api.log
fields:
log_type: openstack.heat.api
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
multiline.negate: true
multiline.match: after
- type: log
enabled: true
paths:
- /var/log/kolla/heat/heat-engine.log
fields:
log_type: openstack.heat.engine
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
multiline.negate: true
multiline.match: after
- type: log
enabled: true
paths:
- /var/log/kolla/horizon/horizon-access.log
101
fields:
log_type: openstack.horizon.access
- type: log
enabled: true
paths:
- /var/log/kolla/horizon/horizon.log
fields:
log_type: openstack.horizon
- type: log
enabled: true
paths:
- /var/log/kolla/keystone/keystone.log
fields:
log_type: openstack.keystone
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
multiline.negate: true
multiline.match: after
- type: log
enabled: true
paths:
- /var/log/kolla/neutron/dnsmasq.log
fields:
log_type: openstack.neutron.dnsmasq
- type: log
enabled: true
paths:
- /var/log/kolla/neutron/neutron-dhcp-agent.log
fields:
log_type: openstack.neutron.dhcp.agent
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
102
multiline.negate: true
multiline.match: after
- type: log
enabled: true
paths:
- /var/log/kolla/neutron/neutron-metadata-agent.log
fields:
log_type: openstack.neutron.metadata.agent
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
multiline.negate: true
multiline.match: after
- type: log
enabled: true
paths:
- /var/log/kolla/neutron/neutron-openvswitch-agent.log
fields:
log_type: openstack.neutron.openvswitch.agent
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
multiline.negate: true
multiline.match: after
- type: log
enabled: true
paths:
- /var/log/kolla/neutron/neutron-l3-agent.log
fields:
log_type: openstack.neutron.l3.agent
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
multiline.negate: true
multiline.match: after
103
- type: log
enabled: true
paths:
- /var/log/kolla/neutron/neutron-server.log
fields:
log_type: openstack.neutron.server
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
multiline.negate: true
multiline.match: after
- type: log
enabled: true
paths:
- /var/log/kolla/nova/nova-api.log
fields:
log_type: openstack.nova.api
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
multiline.negate: true
multiline.match: after
- type: log
enabled: true
paths:
- /var/log/kolla/nova/nova-conductor.log
fields:
log_type: openstack.nova.conductor
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
multiline.negate: true
multiline.match: after
- type: log
enabled: true
104
paths:
- /var/log/kolla/nova/nova-manage.log
fields:
log_type: openstack.nova.manage
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
multiline.negate: true
multiline.match: after
- type: log
enabled: true
paths:
- /var/log/kolla/nova/nova-novncproxy.log
fields:
log_type: openstack.nova.novncproxy
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
multiline.negate: true
multiline.match: after
- type: log
enabled: true
paths:
- /var/log/kolla/nova/nova-scheduler.log
fields:
log_type: openstack.nova.scheduler
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
multiline.negate: true
multiline.match: after
- type: log
enabled: true
paths:
- /var/log/kolla/openvswitch/ovs-vswitchd.log
105
fields:
log_type: openstack.ovs.vswitchd
- type: log
enabled: true
paths:
- /var/log/kolla/openvswitch/ovsdb-server.log
fields:
log_type: openstack.ovsdb.server
- type: log
enabled: true
paths:
- /var/log/kolla/placement/placement-api.log
fields:
log_type: openstack.placement.api
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
multiline.negate: true
multiline.match: after
output.logstash:
hosts: ["10.203.203.40:5044"]
ssl:
enabled: true
certificate_authorities: ["/etc/filebeat/ca.crt"]
106
multiline.match: after
- type: log
enabled: true
paths:
- /var/log/kolla/openvswitch/ovs-vswitchd.log
fields:
log_type: openstack.ovs.vswitchd
- type: log
enabled: true
paths:
- /var/log/kolla/openvswitch/ovsdb-server.log
fields:
log_type: openstack.ovsdb.server
- type: log
enabled: true
paths:
- /var/log/kolla/libvirt/libvirtd.log
fields:
log_type: openstack.libvirt.libvirtd
- type: log
enabled: true
paths:
- /var/log/kolla/nova/nova-compute.log
fields:
log_type: openstack.nova.compute
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-
9]{3} [0-9]+ (ERROR|WARNING|INFO|DEBUG|TRACE) [0-9A-Za-z._]+ \['
multiline.negate: true
multiline.match: after
output.logstash:
hosts: ["10.203.203.40:5044"]
ssl.certificate_authorities: ["/etc/filebeat/ca.crt"]
108
mutate {
add_tag => [ "cinder" ]
}
}
if [fields][log_type] == "openstack.cinder.scheduler" {
grok {
match => { "message" => "%{TIMESTAMP_ISO8601:timestamp}
%{NUMBER} %{LOGLEVEL:log_level} %{NOTSPACE:api}
?(%{GREEDYDATA:event})?"}
}
date {
match => [ "timestamp", "ISO8601" ]
}
mutate {
add_tag => [ "cinder" ]
}
}
if [fields][log_type] == "openstack.cinder.volume" {
grok {
match => { "message" => "%{TIMESTAMP_ISO8601:timestamp}
%{NUMBER} %{LOGLEVEL:log_level} %{NOTSPACE:api}
?(%{GREEDYDATA:event})?"}
}
date {
match => [ "timestamp", "ISO8601" ]
}
mutate {
add_tag => [ "cinder" ]
}
}
if [fields][log_type] == "openstack.glance.api" {
111
grok {
match => { "message" => "%{TIMESTAMP_ISO8601:timestamp}
%{NUMBER} %{LOGLEVEL:log_level} %{NOTSPACE:api}
?(%{GREEDYDATA:event})?"}
}
date {
match => [ "timestamp", "ISO8601" ]
}
mutate {
add_tag => [ "cinder" ]
}
}
if [fields][log_type] == "openstack.haproxy" {
json {
source => "message"
}
mutate {
replace => { "message" => "%{Payload}" }
remove_field => [ "Payload" ]
}
grok {
match => { "message" => ": %{GREEDYDATA:event}"}
}
grok {
match => { "event" => "%{IP:clientip}:%{NUMBER:clientport}
\[%{MONTHDAY:tanggal}/%{MONTH:bulan}/%{YEAR:tahun}:%{HOUR:ja
m}:?%{MINUTE:menit}(?::?%{SECOND:detik})"}
}
mutate {
112
}
if [fields][log_type] == "openstack.heat.api" {
grok {
match => { "message" => "%{YEAR:tahun}-%{MONTHNUM:bulan}-
%{MONTHDAY:tanggal}[T
]%{HOUR:jam}:?%{MINUTE:menit}(?::?%{SECOND:detik})?%{ISO8601_TI
MEZONE:timezone}? %{NUMBER} %{LOGLEVEL:log_level}
%{NOTSPACE:api} ?(%{GREEDYDATA:event})?"}
}
if "multiline" not in [log][flags]{
grok {
match => { "event" => "\[?(%{DATA:req_id} %{DATA:user_id}
%{DATA:project_id} %{DATA} %{DATA} %{DATA})?\]
%{GREEDYDATA:event_message}"}
}
}
mutate {
add_field => { "accesstime" => "%{tahun}-%{bulan}-%{tanggal}
%{jam}:%{menit}:%{detik}+0700" }
remove_field => [ "tahun", "bulan", "tanggal", "jam", "menit", "detik" ]
}
date {
match => [ "accesstime" , "yyyy-MM-dd HH:mm:ss.SSSZ"]
}
113
}
if [fields][log_type] == "openstack.heat.engine" {
grok {
match => { "message" => "%{YEAR:tahun}-%{MONTHNUM:bulan}-
%{MONTHDAY:tanggal}[T
]%{HOUR:jam}:?%{MINUTE:menit}(?::?%{SECOND:detik})?%{ISO8601_TI
MEZONE:timezone}? %{NUMBER} %{LOGLEVEL:log_level}
%{NOTSPACE:api} ?(%{GREEDYDATA:event})?"}
}
if "multiline" not in [log][flags]{
grok {
match => { "event" => "\[?(%{DATA:req_id} %{DATA:user_id}
%{DATA:project_id} %{DATA} %{DATA} %{DATA})?\]
%{GREEDYDATA:event_message}"}
}
}
mutate {
add_field => { "accesstime" => "%{tahun}-%{bulan}-%{tanggal}
%{jam}:%{menit}:%{detik}+0700" }
remove_field => [ "tahun", "bulan", "tanggal", "jam", "menit", "detik" ]
}
date {
match => [ "accesstime" , "yyyy-MM-dd HH:mm:ss.SSSZ"]
}
}
if [fields][log_type] == "openstack.horizon.access" {
grok {
match => { "message" => "%{IPORHOST:remote_ip} -
%{DATA:user_name} \[%{HTTPDATE:access_time}\]
\"%{WORD:http_method} %{DATA:url} HTTP/%{NUMBER:http_version}\"
114
}
if [fields][log_type] == "openstack.horizon" {
grok {
match => { "message" => "\[%{DAY} %{MONTH:bulan}
%{MONTHDAY:tanggal}
%{HOUR:jam}:?%{MINUTE:menit}(?::?%{SECOND:detik})
%{YEAR:tahun}\] \[%{NOTSPACE:log_level}\] \[%{GREEDYDATA}\]
\[%{WORD} %{IP:ip}:%{NUMBER:port}\] ?(%{GREEDYDATA:event})?"}
}
# 2021-12-07T15:42:41.792348+07:00
translate{
exact => true
regex => true
dictionary => [
"Jan","01",
"Feb","02",
"Mar","03",
"Apr","04",
"May","05",
"Jun","06",
"Jul","07",
"Aug","08",
115
"Sep","09",
"Oct","10",
"Nov","11",
"Dec","12"
]
field => "bulan"
destination => "bulan_tmp"
}
grok {
match => { "event" => "Login %{DATA:result} for user
\"%{USERNAME:user}\" using domain \"%{DATA:domain}\", remote address
%{IP:clientip}." }
add_field => { "auth_type" => "login" }
}
mutate {
add_field => { "accesstime" => "%{tahun}-%{bulan_tmp}-
%{tanggal}T%{jam}:%{menit}:%{detik}+07:00" }
remove_field => [ "tahun", "bulan", "tanggal", "jam", "menit", "detik" ,
"bulan_tmp" ]
}
ruby {
path => "/etc/logstash/rubyfilter/precision-timestamp-parse.logstash-filter-
ruby.rb"
script_params => {
source => "accesstime"
format => ["ISO8601"]
}
}
}
if [fields][log_type] == "openstack.keystone" {
grok {
116
}
if [fields][log_type] == "openstack.neutron.dnsmasq" {
grok {
match => { "message" => "%{SYSLOGTIMESTAMP:timestamp}
%{SYSLOGPROG}: ?(%{GREEDYDATA:event})?"}
}
date {
match => [ "timestamp" , "MMM dd HH:mm:ss"]
remove_field => [ "timestamp" ]
}
117
}
if [fields][log_type] == "openstack.neutron.dhcp.agent" {
grok {
match => { "message" => "%{YEAR:tahun}-%{MONTHNUM:bulan}-
%{MONTHDAY:tanggal}[T
]%{HOUR:jam}:?%{MINUTE:menit}(?::?%{SECOND:detik})?%{ISO8601_TI
MEZONE:timezone}? %{NUMBER} %{LOGLEVEL:log_level}
%{NOTSPACE:api} ?(%{GREEDYDATA:event})?"}
}
if "multiline" not in [log][flags]{
grok {
match => { "event" => "\[?(%{DATA:req_id} %{DATA:user_id}
%{DATA:project_id} %{DATA} %{DATA} %{DATA})?\]
%{GREEDYDATA:event_message}"}
}
}
mutate {
add_field => { "accesstime" => "%{tahun}-%{bulan}-%{tanggal}
%{jam}:%{menit}:%{detik}+0700" }
remove_field => [ "tahun", "bulan", "tanggal", "jam", "menit", "detik" ]
}
date {
match => [ "accesstime" , "yyyy-MM-dd HH:mm:ss.SSSZ"]
}
}
if [fields][log_type] == "openstack.neutron.metadata.agent" {
grok {
match => { "message" => "%{YEAR:tahun}-%{MONTHNUM:bulan}-
%{MONTHDAY:tanggal}[T
]%{HOUR:jam}:?%{MINUTE:menit}(?::?%{SECOND:detik})?%{ISO8601_TI
118
}
}
mutate {
add_field => { "accesstime" => "%{tahun}-%{bulan}-%{tanggal}
%{jam}:%{menit}:%{detik}+0700" }
remove_field => [ "tahun", "bulan", "tanggal", "jam", "menit", "detik" ]
}
date {
match => [ "accesstime" , "yyyy-MM-dd HH:mm:ss.SSSZ"]
}
}
if [fields][log_type] == "openstack.neutron.l3.agent" {
grok {
match => { "message" => "%{YEAR:tahun}-%{MONTHNUM:bulan}-
%{MONTHDAY:tanggal}[T
]%{HOUR:jam}:?%{MINUTE:menit}(?::?%{SECOND:detik})?%{ISO8601_TI
MEZONE:timezone}? %{NUMBER} %{LOGLEVEL:log_level}
%{NOTSPACE:api} ?(%{GREEDYDATA:event})?"}
}
mutate {
add_field => { "accesstime" => "%{tahun}-%{bulan}-%{tanggal}
%{jam}:%{menit}:%{detik}+0700" }
remove_field => [ "tahun", "bulan", "tanggal", "jam", "menit", "detik" ]
}
date {
match => [ "accesstime" , "yyyy-MM-dd HH:mm:ss.SSSZ"]
}
}
if [fields][log_type] == "openstack.neutron.server" {
grok {
120
if [fields][log_type] == "openstack.placement.api" {
grok {
match => { "message" => "%{YEAR:tahun}-%{MONTHNUM:bulan}-
%{MONTHDAY:tanggal}[T
]%{HOUR:jam}:?%{MINUTE:menit}(?::?%{SECOND:detik})?%{ISO8601_TI
MEZONE:timezone}? %{NUMBER} %{LOGLEVEL:log_level}
%{NOTSPACE:api} ?(%{GREEDYDATA:event})?"}
}
if "multiline" not in [log][flags]{
grok {
match => { "event" => "\[?(%{DATA:req_id} %{DATA:user_id}
%{DATA:project_id} %{DATA} %{DATA} %{DATA})?\]
%{GREEDYDATA:event_message}"}
}
}
mutate {
add_field => { "accesstime" => "%{tahun}-%{bulan}-%{tanggal}
%{jam}:%{menit}:%{detik}+0700" }
remove_field => [ "tahun", "bulan", "tanggal", "jam", "menit", "detik" ]
}
date {
match => [ "accesstime" , "yyyy-MM-dd HH:mm:ss.SSSZ"]
}
}
if [fields][log_type] == "openstack.libvirt.libvirtd" {
grok {
match => { "message" => "%{YEAR:tahun}-%{MONTHNUM:bulan}-
%{MONTHDAY:tanggal}[T
]%{HOUR:jam}:?%{MINUTE:menit}(?::?%{SECOND:detik})?%{ISO8601_TI
MEZONE:timezone}?: %{NUMBER}: %{LOGLEVEL:log_level} :
%{GREEDYDATA:event}"}
}
126
mutate {
add_field => { "timestamp" => "%{tahun}-%{bulan}-%{tanggal}
%{jam}:%{menit}:%{detik}%{timezone}" }
remove_field => [ "tahun", "bulan", "tanggal", "jam", "menit", "detik" ,
"timezone"]
}
date {
match => [ "timestamp" , "yyyy-MM-dd HH:mm:ss.SSSZ"]
}
}
if [fields][log_type] == "openstack.nova.compute" {
grok {
match => { "message" => "%{YEAR:tahun}-%{MONTHNUM:bulan}-
%{MONTHDAY:tanggal}[T
]%{HOUR:jam}:?%{MINUTE:menit}(?::?%{SECOND:detik})?%{ISO8601_TI
MEZONE:timezone}? %{NUMBER} %{LOGLEVEL:log_level}
%{NOTSPACE:api} ?(%{GREEDYDATA:event})?"}
}
if "multiline" not in [log][flags]{
grok {
match => { "event" => "\[?(%{DATA:req_id} %{DATA:user_id}
%{DATA:project_id} %{DATA} %{DATA} %{DATA})?\]
%{GREEDYDATA:event_message}"}
}
}
grok {
match => { "event_message" => "\[instance: %{NOTSPACE:instance_id}\]
%{GREEDYDATA:task}"}
}
grok {
match => { "task" => "Instance %{GREEDYDATA:status} successfully."}
}
127
mutate {
add_field => { "accesstime" => "%{tahun}-%{bulan}-%{tanggal}
%{jam}:%{menit}:%{detik}+0700" }
remove_field => [ "tahun", "bulan", "tanggal", "jam", "menit", "detik" ]
}
date {
match => [ "accesstime" , "yyyy-MM-dd HH:mm:ss.SSSZ"]
}
}
if [fields][log_type] == "hypervisor-stats" {
json {
source => "message"
}
}
}