Anda di halaman 1dari 141

LAPORAN

PRAKTIK KERJA LAPANGAN


DI
PT BOER TECHNOLOGY
Komplek Ruko Pandu Raya No. 14, Ruko Bagian Belakang, Jl. Pandu Raya,
RT.001/RW.005, Tegal Gundil, Kec. Bogor Utara, Kota Bogor, Jawa Barat 16152

SENTRALISASI LOG DAN MONITORING NODE


PADA OPENSTACK MENGGUNAKAN ELASTIC STACK
Diajukan untuk memenuhi salah satu syarat kelulusan dari SMK Negeri 1 Cimahi

Oleh:

NAMA : ROBI SETIA PERMADI


NOMOR INDUK SISWA : 181113923
TINGKAT : IV (EMPAT)
PROGRAM KEAHLIAN : TEKNIK KOMPUTER DAN INFORMATIKA
KOMPETENSI KEAHLIAN : SISTEM INFORMATIKA, JARINGAN DAN
APLIKASI

SEKOLAH MENENGAH KEJURUAN NEGERI 1 CIMAHI


2022
PENGESAHAN DARI PIHAK SEKOLAH

SENTRALISASI LOG DAN MONITORING NODE


PADA OPENSTACK MENGGUNAKAN ELASTIC STACK

Laporan ini telah disetujui oleh:

Ketua Kompetensi Keahlian, Pembimbing,

Diky Ridwan, S. Kom., Trimans Yogiana, S. Pd.,


NIP. 197507032009021001

MENGETAHUI:
Kepala SMK Negeri 1 Cimahi

Agus Priyatmono Nugroho, S.Pd, M.Si.


NIP. 196708311190031003
KATA PENGANTAR
Puji syukur penulis panjatkan ke hadirat Allah SWT. Atas rahmat dan
karunia-Nya, penulis dapat menyelesaikan laporan dengan judul “Sentralisasi Log
dan Monitoring Node Pada OpenStack Menggunakan Elastic Stack”.
Laporan ini disusun dan diajukan untuk memenuhi salah satu syarat kelulusan
di SMK Negeri 1 Cimahi.
Laporan ini dapat diselesaikan semata karena penulis menerima banyak
bantuan dan dukungan. Untuk itu, penulis mengucapkan terima kasih yang tak
terhingga kepada:
1. Orang tua yang senantiasa memberikan dukungan penuh dan mendo’akan
kelancaran untuk pernulis,
2. Bapak Utian Ayuba selaku direktur utama PT Boer Technology yang telah
mengizinkan dan mendukung penulis untuk melaksanakan Praktek Kerja
Lapangan di PT Boer Technology,
3. Bapak Agus Priyatmono Nugroho, S.Pd, M.Si., selaku Kepala Sekolah
SMK Negeri 1 Cimahi,
4. Bapak Diky Ridwan , S. Kom., selaku Kepala Program Keahlian Sistem
Informatika, Jaringan, dan Aplikasi
5. Bapak Abdul Hakim, Bapak Andri Wijaya, dan Bapak Sidarmawan selaku
pembimbing dari pihak industri yang banyak memberi bimbingan, waktu,
dan masukan sehingga penulis dapat menyelesaikan laporan,
6. Bapak Trimans Yogiana, S. Pd., selaku pembimbing dari pihak sekolah
yang banyak memberi bimbingan, waktu, dan masukan sehingga penulis
dapat menyelesaikan laporan,
7. Serta berbagai pihak yang tidak mungkin dapat penulis sebutkan satu per
satu.
Penulis telah membuat laporan ini semaksimal mungkin yang bisa penulis
lakukan. Oleh karena itu, apabila dirasa ada kekutangan dari laporan ini maka
penulis akan menerima saran dan kritik yang bersifat membangun dengan senang
hati.

i
Akhir kata, penulis berharap semoga laporan ini dapat bermanfaat bagi semua
pihak yang memerlukan.
Bogor, Januari 2022

Penulis

ii
DAFTAR ISI

KATA PENGANTAR ............................................................................................. i

DAFTAR ISI .......................................................................................................... iii

DAFTAR GAMBAR .............................................................................................. v

DAFTAR LAMPIRAN .......................................................................................... xi

BAB I PENDAHULUAN ....................................................................................... 1

1.1 Latar Belakang Masalah ........................................................................... 1

1.2 Tujuan ....................................................................................................... 2

1.3 Pembatasan Masalah ................................................................................ 2

1.4 Sistematika Pembahasan .......................................................................... 2

BAB II TINJAUAN PERUSAHAAN .................................................................... 4

2.1 Profil Perusahaan ...................................................................................... 4

2.2 Layanan Perusahaan ................................................................................. 5

2.3 Struktur Organisasi Perusahaan................................................................ 6

BAB III LANDASAN TEORI .............................................................................. 10

3.1 Jaringan Komputer ................................................................................. 10

3.2 Komputasi Awan (Cloud Computing) .................................................... 13

3.3 OpenStack............................................................................................... 15

3.4 Kolla-Ansible ......................................................................................... 17

3.5 Elastic Stack ........................................................................................... 17

BAB IV PEMBAHASAN ..................................................................................... 21

4.1 Analisis ................................................................................................... 21

4.2 Perencanaan ............................................................................................ 23

4.3 Implementasi .......................................................................................... 25

4.4 Pengujian ................................................................................................ 89

iii
BAB V PENUTUP ................................................................................................ 95

5.1 Kesimpulan ............................................................................................. 95

5.2 Saran ....................................................................................................... 95

DAFTAR PUSTAKA ........................................................................................... 96

LAMPIRAN .......................................................................................................... 98

Lampiran 1 . File /etc/filebeat/filebeat.yml Pada Node Controller ............... 98

Lampiran 2 . File /etc/filebeat/filebeat.yml Pada Node Compute ............... 106

Lampiran 3 . File /etc/logstash/conf.d/30-filter.conf Pada Node Elastic .... 108

iv
DAFTAR GAMBAR

Gambar 2.1 Logo PT Boer Technology .................................................................. 4

Gambar 2.2 Struktur Organisasi Board of Commisioners PT Boer Technology ... 6

Gambar 2.3 Struktur Organisasi Board of Directors PT Boer Technology............ 6

Gambar 2.4 Struktur Organisasi Business Support PT Boer Technology .............. 7

Gambar 2.5 Struktur Organisasi Business Operations PT Boer Technology ......... 7

Gambar 2.6 Struktur Organisasi Tech Talent Delivery PT Boer Technology ........ 8

Gambar 2.7 Struktur Organisasi Product Development PT Boer Technology ....... 8

Gambar 2.8 Struktur Organisasi Service Delivery PT Boer Technology................ 9

Gambar 3.1 Topologi Bus (Sumber: http://ptik.unhas.ac.id/) ............................... 10

Gambar 3.2 Topologu Star (Sumber: http://ptik.unhas.ac.id/).............................. 11

Gambar 3.3 Topologi Ring (Sumber : https://snabaynetworking.com) ................ 12

Gambar 3.4 Topologi Mesh (Sumber : https://diskominfo.kuburayakab.go.id) ... 12

Gambar 3.5 Cloud Service Models (Sumber : www.stackscale.com).................. 13

Gambar 3.6 Logo OpenStack (Sumber : www.openstack.org) ............................. 15

Gambar 3.7 Logo Elastic Stack (Sumber : www.elastic.co) ................................. 17

Gambar 3.8 Proses Pada Elastic Stack (Sumber : www.elastic.co) ...................... 18

Gambar 3.9 Logo Elasticsearch (Sumber : www.elastic.co) ................................ 18

Gambar 3.10 Logo Logstash (Sumber : www.elastic.co) ..................................... 18

Gambar 3.11 Logo Kibana (Sumber : www.elastic.co) ........................................ 19

Gambar 3.12 Logo Beats (Sumber : www.elastic.co) ........................................... 19

Gambar 4.1 Topologi ............................................................................................ 24

Gambar 4.2 Arsitektur Sistem Monitoring dan Log Tersentralisasi ..................... 25

Gambar 4.3 Penambahan User Baru Pada Node controller .................................. 26

Gambar 4.4 Isi File /etc/hosts Pada Semua Node ................................................. 27

v
Gambar 4.5 Pembuatan Pasangan Kunci SSH ...................................................... 28

Gambar 4.6 Pendistribusian Kunci Publik ke Semua Node .................................. 29

Gambar 4.7 Proses Perbaharuan Repositori Pada Node controller ....................... 30

Gambar 4.8 Proses Instalasi Dependensi Pada Node controller ........................... 31

Gambar 4.9 Proses Pembuatan dan Pengaktifan Virtual Environment Python .... 31

Gambar 4.10 Proses Instalasi pip .......................................................................... 32

Gambar 4.11 Instalasi Ansible versi 2.9.13 .......................................................... 32

Gambar 4.12 Instalasi kolla-ansible Versi 10.2.0 ................................................. 33

Gambar 4.13 Instalasi openstackclient .................................................................. 33

Gambar 4.14 Pembuatan dan Penggantian Pemilik Direktori /etc/kolla............... 34

Gambar 4.15 Menyalin Isi Dari Direktori ~/kolla-venv/share/kolla-


ansible/etc_examples/kolla/ ke /etc/kolla .............................................................. 34

Gambar 4.16 Menyalin File multinode ................................................................. 35

Gambar 4.17 File Konfigurasi multinode ............................................................. 35

Gambar 4.18 Pembuatan Kata Sandi Untuk OpenStack ....................................... 36

Gambar 4.19 Isi Dari File Konfigurasi /etc/kolla/globals.yml ............................. 37

Gambar 4.20 Perintah Untuk Menambahkan PV pada Node controller ............... 37

Gambar 4.21 Perintah Untuk Menambahkan VG pada Node controller .............. 38

Gambar 4.22 Proses Bootsrap Servers Pada Proses Deploy OpenStack .............. 38

Gambar 4.23 Proses Prechecks Pada Proses Deploy OpenStack.......................... 39

Gambar 4.24 Proses Deploy OpenStack ............................................................... 39

Gambar 4.25 Proses Post-deploy Pada OpenStack ............................................... 40

Gambar 4.25 Pembaharuan Repositori ................................................................. 40

Gambar 4.26 Penginstalan Dependensi................................................................. 41

Gambar 4.27 Pengunduhan dan Pemasangan GPG Key ....................................... 41

Gambar 4.28 Penambahan Repositori Elastic ....................................................... 41

vi
Gambar 4.29 Proses Instalasi Elasticsearch .......................................................... 42

Gambar 4.30 Proses Menjalankan Layanan Elasticsearch .................................... 42

Gambar 4.31 Isi Dari File Konfigurasi /etc/elasticsearch/elasticsearch.yml ........ 43

Gambar 4.32 Proses Setup Kata Sandi Untuk Built-in User Pada Elasticsearch .. 44

Gambar 4.33 Restart Layanan Elasticsearch ........................................................ 44

Gambar 4.34 Response Saat Mengirim Request Tanpa Kredensial ...................... 45

Gambar 4.35 Response Saat mengirim Request Dengan Kredensial .................... 45

Gambar 4.36 Proses Instalasi Kibana.................................................................... 46

Gambar 4.37 Proses Menjalankan Layanan Kibana ............................................. 46

Gambar 4.38 Isi Dari File /etc/kibana/kibana.yml ................................................ 47

Gambar 4.39 Proses Pengaturan kibana-keystore Agar Menggunakan Kata Sandi


............................................................................................................................... 47

Gambar 4.40 Perintah Restart Layanan Kibana.................................................... 47

Gambar 4.41 Uji Coba Mengakses Kibana ........................................................... 48

Gambar 4.42 Penambahan Repositori Elastic Versi 8.x ....................................... 48

Gambar 4.43 Proses Instalasi Logstash Versi 8.0.0-beta1-1................................. 49

Gambar 4.44 Perintah Untuk Menjalankan Layanan Logstash ............................ 49

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.47 Instalasi Metricbeat Pada Node controller ...................................... 51

Gambar 4.48 Isi Dari File cert.yml ....................................................................... 52

Gambar 4.49 Proses Pembuatan CA Certificate dan Server Certificate ............... 53

Gambar 4.50 Proses Ekstraksi File elastic-cert.zip............................................... 54

Gambar 4.51 Proses Konversi Kunci Privat ......................................................... 54

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.56 Isi Dari File /etc/filebeat/filebeat.yml ............................................. 57

Gambar 4.57 Script Monitoring Nova Compute Stats .......................................... 57

Gambar 4.58 Salah Satu Contoh Pendefinisian Log yang Akan Dipilih .............. 58

Gambar 4.59 Contoh Multiline Log ...................................................................... 59

Gambar 4.60 Isi Dari File /etc/metricbeat/metricbeat.yml Pada OpenStack


Cluster Nodes ........................................................................................................ 59

Gambar 4.61 Isi Dari File Konfigurasi /etc/logstash/conf.d/10-input.conf .......... 61

Gambar 4.62 Isi Dari File /etc/logstash/conf.d/90-output.conf ............................ 62

Gambar 4.63 Letak Tombol Stack Management................................................... 63

Gambar 4.64 Letak Tombol Roles ........................................................................ 63

Gambar 4.65 Tombol Create role ......................................................................... 63

Gambar 4.66 Form Pembuatan Role ..................................................................... 64

Gambar 4.67 Letak Tombol Users ........................................................................ 64

Gambar 4.68 Tombol Create User........................................................................ 65

Gambar 4.69 Form Pembuatan User .................................................................... 65

Gambar 4.70 Letak Tombol Index Patterns .......................................................... 66

Gambar 4.71 Letak Tombol Dashboard ............................................................... 67

Gambar 4.72 Tombol Create Dashboard ............................................................. 67

Gambar 4.73 Tombol Create Visualization .......................................................... 67

Gambar 4.74 Pemilihan Tipe Visualisasi .............................................................. 68

Gambar 4.75 Index Pattern yang Digunakan........................................................ 68

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.84 Konfigurasi Time Series Untuk Visualisasi Nomor 8 ..................... 77

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.88 Konfigurasi Index Pattern Untuk Visualisasi Nomor 8 .................. 79

Gambar 4.89 Tombol Untuk Menambahkan Visualisasi Jenis Time Series ......... 79

Gambar 4.90 Konfigurasi Time Series Untuk Visualisasi Nomor 9 ..................... 80

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.94 Tombol Create Visualization .......................................................... 81

Gambar 4.95 Memilih Visualization Type ............................................................ 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.100 Field yang Ditampilkan Untuk Visualisasi Nomor 11 ................. 84

Gambar 4.101 Filter yang Diisi ............................................................................ 85

Gambar 4.102 Tombol Save.................................................................................. 85

Gambar 4.103 Tombol Add From Library............................................................ 85

Gambar 4.104 Penambahan Visualisasi Nomor 11 Dari Library ......................... 85

Gambar 4.105 Field yang Ditampilkan Untuk Visualisasi Nomor 12 .................. 86

Gambar 4.106 Filter yang Digunakan Untuk Visualisasi Nomor 12.................... 86

Gambar 4.107 Proses Menambahkan Visualisasi dari Library............................. 87

Gambar 4.108 Tombol Create Visualization ........................................................ 87

Gambar 4.109 Proses Pemilihan Jenis Visualisasi Untuk Visualisasi Nomor 13 . 87

Gambar 4.110 Index Pattern yang Digunakan Untuk Visualisasi Nomor 10 ....... 88

Gambar 4.111 Konfigurasi Vertical Axis Pada Visualisasi Nomor 13 ................. 88

Gambar 4.112 Jumlah Error Pada Setiap Layanan OpenStack ............................ 90

Gambar 4.113 Pesan Error Pada Layanan Nova Compute ................................... 90

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 4.120 Riwayat Status Pada Nova Instance .............................................. 93

Gambar 4.121 Riwayat Proses Autentikasi Pada Layanan Horizon ..................... 94

Gambar 4.122 Jumlah Proses Autentikasi Pada Layanan Horizon ....................... 94

Gambar 5.1 Contoh Arsitektur Multi-node Cluster Pada Elastic Stack ................ 95

x
DAFTAR LAMPIRAN

Lampiran 1 . File /etc/filebeat/filebeat.yml Pada Node Controller ................... 98

Lampiran 2 . File /etc/filebeat/filebeat.yml Pada Node Compute................... 106

Lampiran 3 . File /etc/logstash/conf.d/30-filter.conf Pada Node Elastic ........ 108

xi
BAB I
PENDAHULUAN

1.1 Latar Belakang Masalah


PT Boer Technology adalah sebuah perusahaan yang berkomitmen kepada
pelanggan dari berbagai industri di Indonesia untuk terus memberikan layanan dan
solusi terbaik dengan menggunakan Open Source Software. Didukung oleh sumber
daya manusia yang andal, perusahaan ini berfokus meneydiakan layanan untuk
Cloud computing, DevOps, Security, dan Tech Professional Delivery.
Semakin banyaknya penggunaan private cloud sebagai solusi model
komputasi awan oleh para perusahaan membuat OpenStack yang merupakan salah
satu platform private cloud semakin banyak diminati. Oleh karena itu, PT Boer
Technology meminta penulis untuk meriset pembuatan sebuah sistem sentralisasi
log dan monitoring node pada OpenStack Cluster.
OpenStack sendiri merupakan salah satu platform open source terkemuka
untuk public maupun private cloud yang terdiri dari serangkaian proyek yang
digabungkan dan berkembang pesat sehingga mendukung serangkaian teknologi
dan opsi konfigurasi yang luas. (Almási, Castaños, Franke, & Silva, 2016)
Dalam implementasi private cloud menggunakan OpenStack, acapkali
menggunakan banyak node. Hal tersebut seringkali menyebabkan kurangnya
efisiensi waktu pada saat proses troubleshooting maupun monitoring resources
(CPU, dan Memory) oleh engineer. Karena logs yang dihasilkan OpenStack sangat
banyak dan tersebar di semua cluster node, membuat engineer harus masuk ke
setiap node untuk melihat file log mentah yang sangat banyak untuk mencari
masalah jika ada kesalahan ataupun untuk proses monitoring resources. Oleh
karena itu, diperlukan sentralisasi log dan monitoring terpusat sehingga engineer
hanya perlu masuk ke dashboard untuk mencari kesalahan pada file log maupun
monitoring node.
Salah satu solusinya adalah menggunakan Elastic Stack. Elastic Stack
menyediakan tool lengkap untuk mengumpulkan, memusatkan, menganalisis, dan
memvisualisasikan file logs yang sangat banyak maupun metrics. Pada Elastic
Stack terdapat kumpulan tool diantaranya ada Beats sebagai pengumpul logs

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.

1.3 Pembatasan Masalah


Agar laporan ini sesuai dengan tujuan penulis serta tepat sasaran sesuai
dengan permasalahan, maka penulis membatasi permasalahan. Permasalahan yang
akan dibahas adalah bagaimana penggunaan Elastic Stack untuk sentralisasi log
pada OpenStack, sehingga batasan dari permasalahan tersebut adalah sebagai
berikut :
1. Dalam implementasinya, penulis hanya mengambil log dari OpenStack
Services yang umum digunakan (Nova, Cinder, Glance, Neutron, Heat,
Horizon, dan Keystone),
2. Dalam implementasinya, penulis hanya mengambil metrics yang ada pada
OpenStack cluster nodes (controller node, compute node).

1.4 Sistematika Pembahasan


Sistematika pembahasan dari laporan ini bertujuan agar pembaca mudah
mendapatkan gambaran dari isi laporan yang disusun.
BAB I : Pendahuluan
3

Pada bab I terdapat bahasan mengenai uraian laporan yang disusun


yaitu latar belakang masalah, tujuan pembahasan, rumusan
masalah, dan sistematika pembahasan.
BAB II : Tinjauan Perusahan
Pada bab II, berisi tentang sejarah singkat perusahaan tempat
dimana penulis melaksanakan PKL, yaitu PT Boer Technology.
BAB III : Landasan Teori
Pada bab III penulis akan menuliskan teori-teori yang nantinya
akan menjadi acuan pada bab pembahasan.
BAB IV : Pembahasan
Pada bab ini berisikan materi yang penulis akan bahas dan jelaskan
dalam sidang. Pada bab ini penulis menjelaskan bagaimana
mengimplementasikan Sentralisasi Log dan Monitoring Node pada
OpenStack menggunakan Elastic Stack.
BAB IV : Penutup
Pada bab ini penulis menuliskan kesimpulan yang didapatkan
mengenai laporan yang telah disusun dan saran yang bersifat
membangun yang berhubungan dengan masalah yang dibahas.
BAB II
TINJAUAN PERUSAHAAN

2.1 Profil Perusahaan

Gambar 2.1 Logo PT Boer Technology

PT Boer Technology (Btech) merupakan perusahaan yang bergerak di bidang


cloud, DevOps, dan security. Btech berkomitmen untuk memberikan solusi optimal
dengan layanan profesional yang diberikan oleh tim btech yang berpengalaman
dalam spesialisasi Cloud, DevOps, dan Keamanan.
Btech dikembangkan dari visi pemanfaatan Teknologi Informasi dan
Komunikasi (TIK) yang efisien dan ramah lingkungan bagi perusahaan yang
memiliki misi utama menggunakan Linux dan FOSS (Free Open-Source
Software) sebagai alatnya. Didirikan sejak pertengahan tahun 2009, Btech
selalu berkomitmen untuk memberikan layanan terbaik bagi pelanggan. Btech
memiliki produktivitas dan inovasi yang tinggi karena didukung oleh sumber
daya manusia yang cakap dan terampil serta infrastruktur kerja yang andal.
Lokasi kantor yang kondusif dan suasana kerja yang bersahabat juga
mendukung Btech untuk dapat memberikan solusi dari masalah pelanggan.
Kekuatan dari PT Boer Technology adalah hubungan dan interaksi
yang baik dengan komunitas IT yang memiliki visi sama, karena PT Boer
Technology percaya bahwa dengan bersama-sama dapat melakukan hal yang
lebih baik. Layanan yang disediakan oleh PT Boer Technology termasuk pelatihan
sistem cloud yang komprehensif dan solusi sistem cloud terintegrasi
untuk diterapkan di lingkungan bisnis.

4
5

2.2 Layanan Perusahaan


PT Boer Technology menyediakan beberapa layanan di antaranya
adalah layanan:
2.2.1 Konsultasi
Ahli yang bersertifikat dari Btech memberikan layanan
profesional luar biasa dalam bentuk diskusi untuk menghasilkan
rencana yang terdokumentasi untuk memberikan solusi terbaik untuk
kebutuhan pelanggan.
2.2.2 Penerapan
Btech menyediakan layanan pengembangan untuk infrastruktur
atau platform independen yang disesuaikan dengan kebutuhan klien.
Implementasinya dapat dipasangkan dengan kegiatan pelatihan dan
layanan perawatan opsional.
2.2.3 Dukungan Pemeliharaan
Dukungan pemeliharaan menyediakan pemeliharaan untuk
pencegahan dan perbaikan berbasis tiket dengan Perjanjian Tingkat
Layanan yang fleksibel. Layanan ini dapat digabungkan dengan
kegiatan implementasi jika diperlukan oleh calon klien.
2.2.4 Layanan Terkelola
Dukungan pemeliharaan menyediakan pemeliharaan untuk
pencegahan dan perbaikan berbasis tiket dengan Perjanjian Tingkat
Layanan yang fleksibel. Layanan ini dapat digabungkan dengan
kegiatan implementasi jika diperlukan oleh calon klien.
6

2.3 Struktur Organisasi Perusahaan

Gambar 2.2 Struktur Organisasi Board of Commisioners


PT Boer Technology

Gambar 2.3 Struktur Organisasi Board of Directors PT Boer Technology


7

Gambar 2.4 Struktur Organisasi Business Support PT Boer Technology

Gambar 2.5 Struktur Organisasi Business Operations PT Boer Technology


8

Gambar 2.6 Struktur Organisasi Tech Talent Delivery PT Boer Technology

Gambar 2.7 Struktur Organisasi Product Development PT Boer Technology


9

Gambar 2.8 Struktur Organisasi Service Delivery PT Boer Technology


BAB III
LANDASAN TEORI

3.1 Jaringan Komputer


Jaringan komputer adalah sekumpulan komputer, yang terhubung sedemikian
rupa sehingga mereka dapat bertukar data antara komputer pada jaringan. Disebut
Jaringan komputer jika dua atau lebih komputer terhubung untuk berbagi informasi
maupun sumber daya. (Kumar M. D. & B. Deepa, 2015)
Komputer harus memiliki minimal 1 network interface agar dapat terhubung.
Setiap komputer ini dapat dihubungkan menggunakan kabel maupun nirkabel.
Apabila ingin membuat jaringan komputer yang lebih luas jangkauannya maka
diperlukan perangkat jaringan tambahan seperti Switch, Router, dan lain-lain.
Jaringan komputer dapat diklasifikasikan berdasarkan cangkupan areanya,
yaitu:
3.1.1 Topologi
Topologi Jaringan adalah tata letak interkoneksi dari node pada jaringan
komputer. Terdapat beberapa jenis Topologi Jaringan, diantaranya.
a. Topologi Bus
Pada Topologi Bus, Semua perangkat yang ada pada jaringan topologi
ini terhubung melalui kabel tunggal yang dikenal dengan nama kabel
backbone. Setiap node terhubung ke kabel backbone melalui kabel
sambungan maupun secara langsung. Kabel ini yang nantinya akan
mengirimkan jaringan ke perangkat lainnya.

Gambar 3.1 Topologi Bus (Sumber: http://ptik.unhas.ac.id/)

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.

Gambar 3.2 Topologu Star (Sumber: http://ptik.unhas.ac.id/)

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

Gambar 3.3 Topologi Ring (Sumber : https://snabaynetworking.com)

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.

Gambar 3.4 Topologi Mesh (Sumber : https://diskominfo.kuburayakab.go.id)


13

3.2 Komputasi Awan (Cloud Computing)


Menurut National Institute of Standards and Technology (NIST) Komputasi
awan adalah sebuah model komputasi yang memungkinkan untuk diakses di mana
saja serta memberikan kemudahan, kenyamanan, dan sesuai dengan permintaan
konsumen (on-demand) untuk mengakses ke kumpulan sumber daya komputasi
(networks, servers, storages, applications, dan services) yang dapat dikonfigurasi
sehingga dapat dengan cepat disediakan dan dirilis tanpa adanya banyak interaksi
dengan penyedia layanan. (Peter & Timothy, 2011)
3.2.1 Service Models

Gambar 3.5 Cloud Service Models


(Sumber : www.stackscale.com)

a. Software as a Service (SaaS)


SaaS menyediakan layanan berupa aplikasi berbasis cloud kepada
konsumen melalui Internet. Konsumen layanan SaaS tidak memiliki kontrol
atas infrastruktur cloud yang digunakannya. Jadi kemampuan yang diberikan
kepada konsumen hanyalah kemampuan untuk menggunkan aplikasinya.
(Peter & Timothy, 2011)
14

Beberapa contoh dari Software as a Service adalah Gmail, Trello,


Office 365, dan masih banyak lagi.
b. Platform as a Service (PaaS)
Pada Platform as a Service, kemampuan yang diberikan kepada
konsumen adalah untuk men-deploy sebuah aplikasi ke infrastruktur cloud.
Aplikasi yang di-deploy dibuat menggunakan bahasa pemrograman, library,
layanan, dan alat yang didukung oleh penyedia PaaS. Pada layanan ini,
konsumen tidak mengelola atau mengontrol infrastruktur cloud yang dipakai
seperti jaringan, server, sistem operasi, atau penyimpanan, tetapi memiliki
kontrol atas aplikasi yang di-deploy dan dapat mengkonfigurasi untuk
environment aplikasinya. (Peter & Timothy, 2011)
Beberapa contoh dari Platform as a Service adalah Heroku, Openshift,
dan lain-lain.
c. Infrastructure as a Service (IaaS)
Pada Infrastructure as a Service, kemampuan yang diberikan kepada
konsumen adalah penyediaan dan pengelolaan sumber daya komputasi
melalui Internet seperti server, penyimpanan, jaringan, dan virtualisasi.
Layanan ini menyediakan solusi untuk konsumen yang membutuhkan
infrastruktur IT tanpa perlu pengelolaan secara fisik. Konsumen tidak
mengelola atau mengontrol infrastruktur cloud yang mendasarinya tetapi
hanya memiliki kontrol atas sistem operasi, penyimpanan, aplikasi yang
digunakan, dan mungkin kontrol terbatas dari komponen jaringan tertentu
firewall. (Peter & Timothy, 2011)
3.2.2 Deployment Models
a. Private Cloud
Pada model ini, infrastruktur cloud disediakan untuk penggunaan
eksklusif oleh suatu organisasi yang memiliki konsumen. Organisasi ini bisa
berupa perusahaan ataupun yang lainnya. Model ini bisa dimiliki, dikelola,
dan dioperasikan oleh organisasi, pihak ketiga, ataupun keduanya. (Peter &
Timothy, 2011)
b. Community Cloud
15

Pada model ini, infrastruktur cloud disediakan untuk penggunaan


eksklusif oleh suatu komunitas konsumen dari sebuah organisasi yang
memiliki kepentingan dan tujuan yang sama. Model penyebaran ini bisa
dimiliki, dikelola, dan dioperasikan oleh komunitas, pihak ketiga, ataupun
keduanya. Bisa dibilang pada model ini, beberapa organisasi secara bersama-
sama membangun dan berbagi infrastruktur cloud. (Peter & Timothy, 2011)
c. Public Cloud
Kemudian ada public cloud, model ini disediakan secara terbuka untuk
masyarakat umum. model ini dikelola oleh penyedia layanan public cloud
yang memiliki kepemilikan penuh atas public cloud dengan kebijakan, dan
keuntungannya sendiri. Beberapa contoh layanan public cloud populer adalah
AWS dari Amazon, Google Cloud dari Google, dan lain-lain. (Dillon, Wu, &
Chang, 2010)
d. Hybrid Cloud
Hybrid cloud merupakan gabungan dari dua atau lebih model
penyebaran yang implementasikan oleh sebuah perusahaan atau organisasi.
Dalam penerapannya, sebuah organisasi menggunakan model hybrid cloud
untuk mengoptimalkan sumber daya mereka. (Dillon, Wu, & Chang, 2010)

3.3 OpenStack

Gambar 3.6 Logo OpenStack (Sumber : www.openstack.org)

OpenStack merupakan salah satu platform open source terkemuka untuk


infrastructure as a Service public maupun private cloud yang terdiri dari
serangkaian proyek yang digabungkan dan berkembang pesat sehingga mendukung
serangkaian teknologi dan opsi konfigurasi yang luas. (Almási, Castaños, Franke,
& Silva, 2016)
Dalam implementasinya, OpenStack menggabungkan beberapa komponen
diantaranya penulis jelaskan dibawah.
3.3.1 Nova (Compute)
16

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)

3.5 Elastic Stack

Gambar 3.7 Logo Elastic Stack (Sumber : www.elastic.co)

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

Gambar 3.8 Proses Pada Elastic Stack (Sumber : www.elastic.co)

3.5.1 Elasticsearch

Gambar 3.9 Logo Elasticsearch (Sumber : www.elastic.co)

Elasticsearch merupakan sebuah tool open source yang berfungsi sebagai


mesin pencarian dan analisis yang dibangun menggunakan bahasa pemrograman
Java. Semua entri data yang masuk ke Elasticsearch disimpan dalam dokumen
JSON dan semua field dapat diindeks menggunakan query. (Talaş, Pop, & Neagu,
2017)
3.5.2 Logstash

Gambar 3.10 Logo Logstash (Sumber : www.elastic.co)


19

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

Gambar 3.11 Logo Kibana (Sumber : www.elastic.co)

Kibana adalah sebuah dashboard yang berfungsi untuk memvisualisasikan


data dan menavigasi Elastic Stack. Kibana dapat juga digunakan sebagai alat untuk
mencari, dan mengamati. Dengan Kibana dapat menemukan data hingga
menganalisis log sampai menemukan kerentanan keamanan. (Elastic, 2022)
3.5.4 Beats

Gambar 3.12 Logo Beats (Sumber : www.elastic.co)

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

jaringan, menguraikan kode protokol, dan mengambil data yang


diperlukan kemudian mengirimkannya ke pengolah data misalnya
Logstash. (Kotenko, Kuleshov, & Ushakov, 2017)
d. Metricbeat digunakan untuk mengumpulkan metrik sistem operasi,
misalnya, penggunaan CPU dan memori, jumlah paket yang
ditransmisikan dalam jaringan, status sistem, dan layanan yang sedang
berjalan. Kemudian setelah dikumpulkan, dikirimkan ke pengolah data
seperti Logstash. (Kotenko, Kuleshov, & Ushakov, 2017)
BAB IV
PEMBAHASAN

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

4.1.3 Analisis kebutuhan perangkat lunak (software)


Dalam karya tulis ini, penulis membuat project akhir yang menggabungkan
beberapa perangkat lunak, diantaranya:
a. OpenStack, sebagai platform untuk membangun private cloud,
b. Kolla-ansible, sebagai tool yang mengotomatisasi proses deployment
OpenStack dengan menggunakan teknologi kontainerisasi.
c. Ansible, sebuah tool yang berfungsi untuk mengelola sekumpulan
server secara otomatis. Nantinya, tool ini akan digunakan oleh Kolla-
ansible untuk mengotomatisasi proses deployment OpenStack.
d. Docker, digunakan sebagai tool yang berfungsi untuk tempat dari
kontainer yang diinstal OpenStack.
e. Metricbeat, digunakan sebagai tool yang mengirimkan metric dan
statistik dari sebuah node ke Logstash.
f. Filebeat, digunakan sebagai tool yang mengirimkan file log ataupun file
lainnya dari sebuah node ke Logstash.
g. Logstash, adalah sebuah tool yang digunakan untuk mengumpulkan
dan mem-parsing log data, serta membuat indeks log yang disimpan
pada Elasticsearch.
h. Elasticsearch, digunakan sebagai tool untuk search dan analytics
engine.
i. Kibana, adalah sebuah web interface yang dapat memvisualisasikan
data dari Elasticsearch dalam beragam bentuk grafik.
4.1.4 Analisis kebutuhan perangkat keras (hardware)
Dalam karya tulis ini, penulis membuat project akhir yang menggunakan
beberapa perangkat keras, diantaranya:
a. Empat virtual machine dengan setiap virtual machine memiliki
spesifikasi sebagai berikut:
1) Tiga virtual machines yang berfungsi sebagai Openstack Cluster
dengan spesifikasi:
- Sistem operasi : Ubuntu 18.04 LTS
- RAM : 8 GB
- CPU : 4 cores
23

- 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 (/)

b. Laptop yang digunakan oleh penulis untuk mengakses virtual machines


dengan spesifikasi:
1) Prosesor : Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz (8
CPUs)
2) RAM : 4096 MB DDR4

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

Gambar 4.1 Topologi

4.2.2 Arsitektur sistem monitoring dan log tersentralisasi


Pada gambar 4.2 terdapat arsitektur dari sistem yang akan dibangun oleh
penulis, yaitu Sistem Sentralisasi Log dan Monitoring Node Pada OpenStack
Menggunakan Elastic Stack. Pada arsitektur tersebut, dapat diartikan bahwa
Filebeat berfungsi untuk mengirimkan semua log yang dipilih, kemudian
dikirimkan ke Logstash. Sedangkan untuk Metricbeat berfungsi untuk
mengirimkan metric dan statistik penggunaan sumber daya dari sebuah node ke
Logstash.
Oleh Logstash, data-data yang telah diterima diuraikan sehingga menjadi
data-data yang informatif dan mudah dicerna. Kemudian data-data yang telah
diuraikan oleh Logstash dikirim ke Elasticsearch untuk fungsi search dan analytics.
Dalam memudahkan mencari dan menganalisis data-data, maka Kibana berfungsi
untuk membuat sebuah web user interface. Sehingga penulis dapat
memvisualisasikan lagi data-data yang ada pada Elasticsearch.
25

Gambar 4.2 Arsitektur Sistem Monitoring dan Log Tersentralisasi

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

a. Pengubahan hostname pada semua node


Tahapan pertama dalam persiapan environment adalah pengubahan
hostname pada semua node sehingga sesuai dengan topologi. Untuk
mengubah hostname penulis mengubah file /etc/hostname pada setiap node
dengan hostname yang sesuai dengan topologi.
b. Pembuatan user sudo
Tahapan kedua dalam persiapan environment yang dilakukan penulis
adalah membuat user sudo pada semua node. Penulis membuat user bernama
“setiapermadir” yang dimasukan ke dalam sudoers. Perintah untuk
menambah user adalah sudo adduser setiapermadir lalu isikan profil dari user
yang akan dibuat.
Kemudian tambahkan user baru tersebut ke dalam sudoers dengan
perintah sudo usermod -aG sudo setiapermadir dan sudo echo
“setiapermadir ALL=(ALL) NOPASSWD:ALL” | sudo tee
/etc/sudoers.d/setiapermadir. Karena tahapan ini memiliki langkah yang sama
pada semua node, maka penulis hanya mancantumkan tangkapan layar pada
node controller sesuai dengan gambar 4.3.

Gambar 4.3 Penambahan User Baru Pada Node controller

Setelah menambahkan user baru, maka penulis menggunakan user baru


tersebut untuk menjalankan langkah-langkah selanjutnya.
c. Memetakan host pada /etc/hosts
27

Pada tahapan ini, penulis mengkonfigurasi file /etc/hosts pada semua


node agar semua node bisa saling berkomunikasi menggunakan hostname.
Penulis menambahkan konfigurasi yang sama persis di file /etc/hosts pada
semua node, sehingga file /etc/hosts pada setiap node berisi seperti pada
gambar 4.4.

Gambar 4.4 Isi File /etc/hosts Pada Semua Node

Setelah tahapan ini selesai, maka semua node bisa berkomunikasi


menggunakan hostname.
d. Membuat pasangan kunci SSH pada node controller
Penulis membuat pasangan kunci SSH pada node controller agar node
controller dapat remote ke node lainnya tanpa kata sandi dan agar Ansible
bisa berjalan. Untuk membuat pasangan kunci SSH, penulis menggunaka
perintah ssh-keygen -t rsa kemudian kosongkan saja isian yang diberikan
sesuai dengan gambar 4.5.
28

Gambar 4.5 Pembuatan Pasangan Kunci SSH

e. Mendistribusikan kunci publik SSH dari node controller ke semua


node
Pada tahapan pembuatan pasangan kunci SSH akan menghasilkan dua
kunci, yaitu kunci publik dan kunci privat. Kunci privat disimpan pada node
controller kemudian kunci publik disimpan pada node yang nantinya akan
diremote.
Oleh karena itu, pada tahapan ini penulis mendistribusikan kunci publik
ke semua node menggunakan perintah ssh-copy-id -i ~/.ssh/id_rsa.pub
setiapermadir@[hostname] yang sesuai dengan gambar 4.6.
29

Gambar 4.6 Pendistribusian Kunci Publik ke Semua Node

Setelah tahapan pendistribusian kunci publik SSH selesai, maka bagian


tahapan persiapan environment selesai sehingga penulis melanjutkan ke
bagian tahapan berikutnya, yaitu bagian deploy OpenStack cluster.
4.3.2 Deploy OpenStack Cluster
Sebelum instalasi dan konfigurasi Elastic Stack untuk sentralisasi log dan
monitoring node pada OpenStack. Maka penulis deploy terlebih dahulu OpenStack
30

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.

Gambar 4.7 Proses Perbaharuan Repositori Pada Node controller

b. Menginstal dependensi yang dibutuhkan pada node controller


Pada proses deploy, kita memerlukan beberapa dependensi yang
dibutuhkan, diantaranya:
1) Python3-dev,
2) Libffi-dev,
3) Gcc,
4) Libssl-dev,
5) Python3-selinux,
6) Python3-setuptools, dan
7) Python3-venv.
Untuk menginstal dependensi yang dibutuhkan, penulis mengunakan
perintah sudo apt-get install python3-dev libffi-dev gcc libssl-dev python3-
selinux python3-setuptools python3-venc -y yang sesuai dengan gambar 4.8.
31

Gambar 4.8 Proses Instalasi Dependensi Pada Node controller

c. Membuat virtual environment python pada node controller


Penulis menggunakan virtual environment agar tidak menggangu
environment default. Untuk membuat virtual environment Python penulis
menggunakan perintah python3 -m venv kolla-venv kemudian untuk
mengaktifkan virtual enviroment penulis menggunakan perintah source
kolla-venv/bin/activate. Jika pada awal baris terminal terdapat tulisan (kolla-
venv) maka virtual environment berhasil dibuat dan diaktifkan seperti pada
gambar 4.9.

Gambar 4.9 Proses Pembuatan dan Pengaktifan Virtual Environment Python

d. Menginstal pip pada node controller


Kemudian selanjutnya penulis menginstal pip yaitu package manager
untuk Python dengan menggunakan perintah pip install -U pip sesuai dengan
gambar 4.10.
32

Gambar 4.10 Proses Instalasi pip

e. Menginstal Ansible, kolla-ansible, dan openstackclient


menggunakan pip pada node controller
Pada tahapan ini, penulis menginstal Ansible agar kolla-ansible dapat
berjalan, kemudian menginstal kolla-ansible untuk deploy OpenStack dan
openstackclient untuk mengelola OpenStack cluster.
Untuk menginstal Ansible versi 2.9.13, penulis menggunakan perintah
pip install ansible==2.9.13 seperti pada gambar 4.11.

Gambar 4.11 Instalasi Ansible versi 2.9.13

Kemudian untuk menginstal kolla-ansible versi 10.2.0, penulis


menggunakan perintah pip install kolla-ansible==10.2.0 seperti pada gambar
4.12.
33

Gambar 4.12 Instalasi kolla-ansible Versi 10.2.0

Terakhir untuk menginstal openstackclient, penulis menggunakan


perintah pip install openstackclient seperti pada gambar 4.13.

Gambar 4.13 Instalasi openstackclient

f. Membuat direktori /etc/kolla pada node controller dan mengganti


pemilik direktorinya
Untuk membuat direktori, penulis menggunakan perintah sudo mkdir -
p /etc/kolla dan perintah sudo chown $USER:USER /etc/kolla untuk
mengganti pemilik direktorinya seperti pada gambar 4.14. Nantinya direktori
ini akan berisi file konfigurasi dari kolla-ansible.
34

Gambar 4.14 Pembuatan dan Penggantian Pemilik Direktori /etc/kolla

g. Menyalin file globals.yml dan passwords.yml dari direktori ~/kolla-


venv/share/kolla-ansible/etc_examples/kolla/ ke direktori /etc/kolla
pada node controller
Pada tahapan ini, penulis menggunakan perintah cp -r kolla-
venv/share/kolla-ansible/etc_examples/kolla/* /etc/kolla/ seperti pada
gambar 4.15.

Gambar 4.15 Menyalin Isi Dari Direktori ~/kolla-venv/share/kolla-


ansible/etc_examples/kolla/ ke /etc/kolla

File globals.yml adalah file konfigurasi kolla-ansible yang berfungsi


untuk mengkonfigurasi layanan OpenStack mana saja yang akan diinstal
ataupun mengkonfigurasi OpenStack cluster lainnya.
Sedangkan, file passwords.yml berisikan kata sandi yang nantinya akan
digunakan oleh OpenStack cluster. Tapi pada tahapan ini, file passwords.yml
masih kosong.
h. Menyalin file multinode dari ~/kolla-venv/share/kolla-
ansible/ansible/inventory ke direktori ~/ pada node controller
Pada tahapan ini, penulis menyalin file menggunakan perintah “cp
kolla-venv/share/kolla-ansible/ansible/inventory/multinode .” seperti pada
gambar 4.16. File multinode sendiri merupakan file konfigurasi inventory
dari Ansible. File konfigurasi ini nantinya akan menentukan node yang
berperan sebagai control node, network node, compute node, monitoring
node, dan storage node.
35

Gambar 4.16 Menyalin File multinode

i. Konfigurasi file multinode pada node controller


Pada konfigurasi ini, penulis hanya mengganti pada bagian [control],
[network], [compute], [monitoring], dan [storage] menjadi seperti pada
gambar 4.17.

Gambar 4.17 File Konfigurasi multinode

Bagian [control] berfungsi untuk menentukan node mana saja yang


akan menjadi control node. Bagian [network] berfungsi untuk menentukan
node mana saja yang akan menjadi network node. Bagian [compute]
berfungsi untuk menentukan node mana saja yang akan menjadi compute
node. Bagian [monitoring] berfungsi untuk menentukan node mana saja yang
akan menjadi monitoring node. Bagian [storage] berfungsi untuk
menentukan node mana saja yang akan menjadi storage node.
j. Membuat kata sandi untuk OpenStack menggunakan kolla-
genpwd secara random
36

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.

Gambar 4.18 Pembuatan Kata Sandi Untuk OpenStack

k. Konfigurasi file /etc/kolla/globals.yml


Pada tahapan ini penulis mengkonfigurasi file /etc/kolla/globals.yml di
node controller pada beberapa baris , diantaranya:
1) Baris kolla_base_distro: "ubuntu", menentukan sistem operasi apa
yang dipakai pada OpenStack cluster node(controller, compute1,
compute2),
2) Baris kolla_install_type: "source", menentukan tipe penginstalan
kontainernya,
3) Baris openstack_release: "ussuri", menentukan versi dari
OpenStack yang akan diinstal,
4) Baris kolla_internal_vip_address: "10.203.203.100", menentukan
virtual ip dari OpenStack untuk mengakses API OpenStack
maupun layanan OpenStack,
5) Baris network_interface: "ens3", menentukan interface mana yang
akan digunakan sebagai jaringan management,
6) Baris neutron_external_interface: "ens4", menentukan interface
mana yang terhubung ke external/provided network,
37

7) Baris enable_cinder: "yes", berfungsi untuk mengaktifkan layanan


cinder,
8) Baris enable_cinder_backend_lvm: "yes", berfungsi untuk
mengkonfigurasi cinder agar menggunakan LVM sebagai backend.
Sehingga, isi dari file /etc/kolla/globals.yml seperti pada gambar 4.19.

Gambar 4.19 Isi Dari File Konfigurasi /etc/kolla/globals.yml

l. Membuat volume group untuk Cinder


Pada tahap ini, penulis mengkonfigurasi volume group yang nantinya
akan digunakan oleh layanan Cinder. Proses konfigurasi ini dilakukan pada
semua node karena setiap node sudah diberikan 2 hard disk yang nantinnya
salah satunya akan digunakan oleh layanan cinder sebagai block storage
service.
Tahapan ini dilakukan pada semua node OpenStack Cluster. Karena
perintah yang digunakan sama, maka penulis hanya mencantumkan
tangkapan layar pada node controller saja. Pertama, penulis membuat
physical volume(PV) pada semua OpenStack cluster nodes dengan perintah
sudo pvcreate /dev/vdb seperti pada gambar 4.20 yang dijalankan pada setiap
OpenStack cluster nodes.

Gambar 4.20 Perintah Untuk Menambahkan PV pada Node controller

Selanjutnya untuk membuat volume group(VG) pada semua OpenStack


cluster nodes, penulis menjalankan perintah sudo vgcreate cinder-volumes
/dev/vdb seperti pada gambar 4.21 yang dijalankan pada setiap OpenStack
cluster nodes.
38

Gambar 4.21 Perintah Untuk Menambahkan VG pada Node controller

m. Deploy OpenStack mengunakan kolla-ansible


Pada tahap ini, penulis melakukan tahapan terakhir untuk proses deploy
OpenStack cluster menggunakan kolla-ansible. Pada tahapan ini, hanya
dilakukan pada node controller. Langkah pertama penulis melakukan terlebih
dahulu proses boostrap servers menggunakan perintah kolla-ansible -I
./multinode bootstrap-servers sesuai pada gambar 4.22.

Gambar 4.22 Proses Bootsrap Servers Pada Proses Deploy OpenStack

Proses bootstrap servers ini berfungsi untuk mengotomatisasi


konfigurasi lain seperti mematikan firewall, instalasi dan konfigurasi Docker,
instalasi dependensi, konfigurasi SELinux, konfigurasi Apparmor dan
konfigurasi NTP.
Setelah proses bootsrap servers selesai, penulis melakukan proses
prechecks menggunakan perintah kolla-ansible -I ./multinode prechecks
sesuai dengan gambar 4.23. Proses prechecks ini berfungsi untuk mengecek
bahwa semua persyaratan telah dipenuhi sebelum proses deploy.
39

Gambar 4.23 Proses Prechecks Pada Proses Deploy OpenStack

Selanjutnya proses deploy menggunakan perintah kolla-ansible -I


./multinode deploy seperti pada gambar 4.24.

Gambar 4.24 Proses Deploy OpenStack

Kemudian terakhir menjalankan proses post deploy untuk membuat file


admin-openrc.sh yang digunakan untuk proses autentikasi untuk mengelola
OpenStack menggunakan perintah kolla-ansible -I ./multinode post-deploy
seperti pada gambar 4.25.
40

Gambar 4.25 Proses Post-deploy Pada OpenStack

4.3.3 Instalasi dan konfigurasi Elasticsearch pada node elastic


a. Memperbaharui repositori
Tahapan pertama sebelum menginstal Elasticsearch adalah
memperbaharui repositori pada node elastic dengan menggunakan perintah
sudo apt update -y yang sesuai dengan gambar 4.25.

Gambar 4.25 Pembaharuan Repositori

b. Menginstal dependensi yang dibutuhkan


Untuk menginstal Elasticsearch, kita memerlukan beberapa dependensi
yang dibutuhkan, diantaranya:
1) Openjdk-11-jre, yaitu bahasa pemrograman Java karena
Elasticseach berbasiskan bahasa pemrograman Java,
2) Apt-transport-https,
3) Curl,
4) Wget.
Untuk menginstal dependensi yang dibutuhkan, penulis mengunakan
perintah sudo apt install openjdk-11-jre apt-transport-https curl wget yang
sesuai dengan gambar 4.26.
41

Gambar 4.26 Penginstalan Dependensi

c. Mengunduh dan memasangkan GPG key repositori Elastic dan


menambahkan repositori Elastic
Agar repositori Elastic bisa dipakai, maka penulis harus mengunduh
dan memasangkan GPG key terlebih dahulu sebelum menambahkan
repositorinya.
Perintah untuk mengunduh dan memasangkan GPG key dari Elastic
adalah “wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo
apt-key add –“ yang sesuai dengan gambar 4.27.

Gambar 4.27 Pengunduhan dan Pemasangan GPG Key

Sedangkan untuk menambahkan repositori Elastic menggunakan


perintah:
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" |
sudo tee /etc/apt/sources.list.d/elastic-7.x.list yang sesuai dengan gambar
4.28.

Gambar 4.28 Penambahan Repositori Elastic

d. Instalasi Elasticsearch
42

Pada tahapan sebelumnya penulis menambahkan repositori baru. Akan


tetapi penulis belum memperbaharui cache repositori. Oleh karena itu untuk
menginstal Elasticsearch harus didahului dengan memperbaharui cache
repositori. Oleh karena itu, maka perintah yang digunakan pada tahapan ini
adalah sudo apt update && sudo apt -y install elasticsearch yang sesuai pada
gambar 4.29.

Gambar 4.29 Proses Instalasi Elasticsearch

e. Menjalankan layanan Elasticsearch


Untuk menjalankan layanan Elasticsearch dan agar otomatis berjalan
setiap kali restart node, penulis menggunakan perintah sudo systemctl start
elasticsearch.service dan sudo systemctl enable elasticsearch.service sesuai
pada gambar 4.30.

Gambar 4.30 Proses Menjalankan Layanan Elasticsearch

f. Konfigurasi Elasticsearch
43

Untuk mengkonfigurasi Elasticsearch, file yang dikonfigurasi adalah


/etc/elasticsearch/elasticsearch.yml. Penulis hanya mengkonfigurasi pada
beberapa baris, diantaranya adalah:
1) Baris network.host dengan mengubah nilainya menjadi 0.0.0.0
sehingga Elasticsearch bisa diakses lewat alamat IP mana saja,
2) Baris http.port dengan mengubah nilainya menjadi 9200 untuk
mengatur di port mana Elasticsearch akan dijalankan,
3) Baris discovery.seed_hosts dengan mengubah nilainya menjadi
["127.0.0.1", "[::1]"] untuk mengkonfigurasi bahwa hanya
localhost yang diinstal Elasticsearch,
4) Baris discovery.type dengan mengubah nilainya menjadi single-
node untuk mengkonfigurasi bahwa Elasticsearch diinstal secara
single-node,
5) Baris xpack.security.enabled dengan mengubah nilainya menjadi
true yang artinya fitur security pada Elasticsearch dinyalakan.
Sehingga, isi dari file /etc/elasticsearch/elasticsearch.yml sesuai pada
gambar 4.31.

Gambar 4.31 Isi Dari File Konfigurasi /etc/elasticsearch/elasticsearch.yml

g. Mengatur kata sandi untuk built-in user pada Elasticsearch


Agar Elasticsearch aman, maka penulis mengatur kata sandi untuk
built-in user sehingga perlu proses autentikasi untuk mengakses
Elasticsearch.
Untuk mengatur kata sandi built-in user penulis menggunakan perintah
sudo /usr/share/elasticsearch/bin/elasticsearch-setup-passwords interactive
kemudian isikan kata sandi pada setiap built-in user seperti pada gambar 4.32.
44

Gambar 4.32 Proses Setup Kata Sandi Untuk Built-in User Pada Elasticsearch

h. Restart layanan Elasticsearch


Agar hasil konfigurasi terpasang pada Elasticsearch, maka penulis
restart layanan Elasticsearch menggunakan perintah sudo systemctl restart
elasticsearch sesuai pada gambar 4.33.

Gambar 4.33 Restart Layanan Elasticsearch

i. Verifikasi Elasticsearch sudah menggunakan kata sandi


Untuk membuktikan bahwa Elasticsearch sudah menggunakan kata
sandi, maka penulis mencoba mengirim request ke API Server tanpa
kredensial dan dengan kredensial.
Untuk mengirim request ke API Server tanpa kredensial, penulis
menggunakan perintah curl -X GET elastic:9200/?pretty sesuai pada gambar
4.34 dimana response status menghasilkan 401 atau Unauthorized yang
artinya tidak diizinkan karena tidak mencantumkan kredensial.
45

Gambar 4.34 Response Saat Mengirim Request Tanpa Kredensial

Untuk mengirim request ke API Server dengan autentikasi, penulis


menggunakan perintah curl --user 'elastic:[redacted]' -X GET
elastic:9200/?pretty sesuai pada gambar 4.35 yang menunjukan bahwa
Elastisearch berhasil diakses.

Gambar 4.35 Response Saat mengirim Request Dengan Kredensial


46

4.3.4 Instalasi dan konfigurasi Kibana pada node elastic


a. Instalasi Kibana
Karena pada tahap instalasi Elasticsearch sudah menambahkan
repositori Elastic, maka tahapan ini penulis langsung menginstal Kibana
menggunakan perintah sudo apt-get install -y kibana yang sesuai dengan
gambar 4.36.

Gambar 4.36 Proses Instalasi Kibana

b. Menjalankan layanan Kibana


Untuk menjalankan layanan Kibana dan agar otomatis berjalan setiap
kali restart node, penulis menggunakan perintah sudo systemctl start kibana
dan sudo systemctl enable kibana sesuai pada gambar 4.37.

Gambar 4.37 Proses Menjalankan Layanan Kibana

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

2) Baris elasticsearch.username: “kibana-system” untuk


mengkonfigurasi agar Kibana menggunakan user kibana-system
untuk mengakses Elasticsearch.
Sehingga isi dari file konfigurasi /etc/kibana/kibana.yml sesuai dengan
gambar 4.38.

Gambar 4.38 Isi Dari File /etc/kibana/kibana.yml

d. Atur kibana-keystore agar menggunakan kata sandi


Pada tahapan ini, penulis mengatur kibana agar memakai kata sandi
yang telah diatur pada saat konfigurasi Elasticsearch. Pada tahapan ini,
penulis menggunakan 2 perintah, yaitu:
1) Perintah sudo /usr/share/kibana/bin/kibana-keystore create untuk
membuat keystore,
2) Perintah sudo /usr/share/kibana/bin/kibana-keystore add
elasticsearch.password kemudian isikan kata sandinya untuk
menyimpan konfigurasi kata sandi.
Kedua perintah ini sesuai dengan gambar 4.39.

Gambar 4.39 Proses Pengaturan kibana-keystore Agar Menggunakan Kata Sandi

e. Restart Kibana
Setelah mengatur kata sandi, penulis melakukan restart layanan Kibana
menggunakan perintah sudo systemctl restart kibana yang sesuai dengan
gambar 4.40.

Gambar 4.40 Perintah Restart Layanan Kibana


48

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.41 Uji Coba Mengakses Kibana

4.3.5 Instalasi Logstash pada node elastic


Pada instalasi Logstash, disini penulis menggunakan Logstash versi 8.0.0-
beta1-1 agar mendukung timestamp yang presisi hingga nanosecond.
a. Penambahan repositori Elastic versi 8.x
Untuk menambah repositori Elastic versi 8.x, penulis menggunakan
perintah echo "deb https://artifacts.elastic.co/packages/8.x-prerelease/apt
stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list yang sesuai
dengan gambar 4.42.

Gambar 4.42 Penambahan Repositori Elastic Versi 8.x

b. Instalasi Logstash versi 8.0.0-beta1-1


49

Untuk mengisntal Logstash versi 8.0.0-beta1-1, penulis


mengunakan perintah sudo apt install logstash=18.0.0~beta1-1 yang sesuai
dengan gambar 4.43.

Gambar 4.43 Proses Instalasi Logstash Versi 8.0.0-beta1-1

c. Menjalankan layanan Logstash


Untuk menjalankan layanan Logstash dan agar otomatis berjalan setiap
kali restart node, penulis menggunakan perintah sudo systemctl start logstash
dan sudo systemctl enable logstash sesuai pada gambar 4.44.

Gambar 4.44 Perintah Untuk Menjalankan Layanan Logstash

4.3.6 Instalasi Beats (Filebeat dan Metricbeat) pada OpenStack cluster


nodes(node controller, node compute1, node compute2)
Pada bagian tahapan ini, penulis menjalankannya pada node controller,
compute1, dan compute2
a. Mengunduh dan memasangkan GPG key repositori Elastic
kemudian menambahkan repositori Elastic
Agar repositori Elastic bisa dipakai, maka penulis harus mengunduh
dan memasangkan GPG key terlebih dahulu sebelum menambahkan
repositorinya.
50

Perintah untuk mengunduh dan memasangkan GPG key dari Elastic


adalah “wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo
apt-key add –“.
Sedangkan untuk menambahkan repositori Elastic menggunakan
perintah:
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee
/etc/apt/sources.list.d/elastic-7.x.list.
Karena perintah yang dijalankan pada ketiga OpenStack cluster nodes
sama, maka penulis hanya mencantumkan tangkapan layar pada node
controller. Pada gambar 4.45 merupakan tangkapan layar saat penulis
menjalankan perintah untuk tahapan ini.

Gambar 4.45 Penambahan Repositori Elastic Versi 8.x Pada Node controller

b. Pembaharuan repositori dan instalasi Filebeat


Pada tahapan sebelumnya penulis menambahkan repositori baru. Akan
tetapi penulis belum memperbaharui cache repositori. Oleh karena itu untuk
menginstal Filebeat harus didahului dengan memperbaharui cache repositori.
Oleh karena itu, maka perintah yang digunakan pada tahapan ini adalah sudo
apt update && sudo apt -y install filebeat yang dijalankan pada node
controller sesuai pada gambar 4.46. Penulis hanya mencantumkan tangkapan
layar pada node controller karena perintahnya sama.
51

Gambar 4.46 Proses Instalasi Filebeat Pada OpenStack Cluster Nodes

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.

Gambar 4.47 Instalasi Metricbeat Pada Node controller

4.3.7 Mengamankan komunikasi antara Beats dan Logstash


52

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.48 Isi Dari File cert.yml

Setelah membuat file cert.yml, jalankan perintah untuk membuat CA


certificate dan server certificate yaitu sudo
/usr/share/elasticsearch/bin/elasticsearch-certutil cert –keep-ca-key –pem –
in $HOME/cert.yml –out $HOME/elastic-cert.zip –days 365 yang sesuai
dengan gambar 4.49.
53

Gambar 4.49 Proses Pembuatan CA Certificate dan Server Certificate

b. Ekstrak file zip hasil dari tahapan sebelumnya


Setelah melakukan tahapan sebelumnya akan menghasilkan file zip
baru yaitu elastic-cert.zip. Pada tahapan ini, penulis mengekstraksi file zip
tersebut sehingga CA certificate dan server certificate bisa dipakai. Pada
tahapan ini penulis mengekstraksi file zip menggunakan perintah sudo unzip
elastic-cert.zip yang sesuai dengan gambar 4.50.
54

Gambar 4.50 Proses Ekstraksi File elastic-cert.zip

c. Konversi kunci privat ke format standar Elastic Beats PKCS#8


Setelah diekstraksi, penulis melakukan konversi kunci privat ke format
standar Elastic Beats PKCS#8 menggunakan perintah sudo openssl pkcs8 -in
~/elastic/elastic.key -topk8 -nocrypt -out ~/elastic/elastic.pkcs8.key yang
sesuai dengan gambar 4.51.

Gambar 4.51 Proses Konversi Kunci Privat

d. Konfigurasi Logstash pada node elastic agar input dari Beats


menggunakan koneksi SSL/TLS
Setelah kunci privat dikonversi, maka penulis langsung
mengkonfigurasi Logstash pada node elastic agar menggunakan SSL/TLS
dengan mengkonfigurasi file /etc/logstash/conf.d/10-input.conf.
Sebelum mengkonfigurasi file /etc/logstash/conf.d/10-input.conf,
penulis menyalin terlebih dahulu kunci privat hasil konversi dan server
certificate ke direktori /etc/logstash/ menggunakan perintah sudo cp
~/elastic/{elastic.pkcs8.key,elastic.crt} /etc/logstash/ yang sesuai dengan
gambar 4.52.

Gambar 4.52 Proses Menyalin Kunci Privat Hasil Konversi dan Server Certificate
55

Setelah menyalin kunci privat hasil konversi dan server certificate,


maka penulis langsung mengkonfigurasi file /etc/logstash/conf.d/10-
input.conf dengan menambahkan konfigurasi untuk input yang sumbernya
dari Beats hingga file /etc/logstash/conf.d/10-input.conf isinya menjadi
seperti pada gambar 4.53.

Gambar 4.53 Isi Dari File /etc/logstash/conf.d/10-input.conf

Pada gambar 4..53, penulis menambah input dari Beats dengan


konfigurasi:
1) Baris “port => 5044” yang artinya membuka input pada port
5044,
2) Baris “ssl => true” yang artinya mengaktifkan koneksi SSL,
3) Baris “ssl_key => ‘/etc/logstash/elastic.pkcs8.key’” untuk
mendefinisikan letak dari kunci privat,
4) Baris “ssl_certificate => ‘/etc/logstash/elastic.crt’” yang
berfungsi untuk mendefinisikan letak dari server certificate.
e. Menyalin file ca.crt dari node elastic ke node controller, compute1,
dan compute2
Sebelum mengkonfigurasi Beats, salin terlebih dahulu CA certificate
untuk client dari node elastic ke OpenStack cluster nodes menggunakan tool
scp. Perintah yang digunakan untuk menyalin dari node elastic ke OpenStack
cluster nodes adalah “scp setiapermadir@elastic:$HOME/ca/ca.crt . “ yang
dijalankan pada semua OpenStack cluster nodes seperti pada gambar 4.54.
56

Untuk tangkapan layarnya, penulis hanya mencantumkan pada node


controller karena tangkapan layarnya sama persis.

Gambar 4.54 Proses Menyalin CA certificate Untuk Client Dari Node elastic ke
OpenStack Cluster Nodes Menggunakan Tool SCP

Setelah file CA certificate sudah ada pada semua OpenStack cluster


node, salin lagi file tersebut ke direktori /etc/filebeat dan direktori
/etc/metricbeat pada masing-masing OpenStack cluster node menggunakan
perintah sudo cp -r ca.crt /etc/{filebeat/metricbeat}/ yang dijalankan pada
node controller, compute1, dan compute2 yang sesuai dengan gambar 4.55.
Pada gambar 4.55, penulis hanya menampilkan tangkapan layar untuk node
controller karena tangkapan layarnya sama persis.

Gambar 4.55 Proses Menyalin File ca.crt ke /etc/filebeat dan /etc/metricbeat Pada
Node controller

f. Konfigurasi output Beats pada OpenStack cluster nodes(node


controller, compute1, dan compute2) agar menggunakan CA
certificate yang telah disalin
Setelah menyalin file ca.crt ke direktori /etc/filebeat dan direktori
/etc/metricbeat pada setiap OpenStack cluster nodes, selanjutnya penulis
mengkonfigurasi output Beats agar menggunakan CA certificate yang telah
disalin tersebut.
Penulis mengkonfigurasi file /etc/filebeat/filebeat.yml dan
/etc/metricbeat/metricbeat.yml pada setiap OpenStack cluster nodes,
sehingga isi dari file tersebut seperti pada gambar 4.56. Untuk Filebeat
maupun Metricbeat memiliki isi konfigurasi ouput yang sama.
57

Gambar 4.56 Isi Dari File /etc/filebeat/filebeat.yml

4.3.8 Pembuatan script dari bahasa pemrograman Python untuk monitoring


stats layanan Nova pada OpenStack
Pada tahapan ini, penulis membuat script dari bahasa pemrograman Python
untuk monitoring stats pada layanan Nova di OpenStack. Untuk mendapatkan stats
dari layanan Nova pada OpenStack penulis membuat script yang mengirim request
ke API server Nova yang menghasilkan response berupa stats dari layanan Nova.
Isi dari script ini ada pada gambar 4.57.

Gambar 4.57 Script Monitoring Nova Compute Stats

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

/etc/filebeat/filebeat.yml pada setiap OpenStack cluster nodes. Isi dari file


konfigurasi /etc/filebeat/filebeat.yml pada node controller ada pada lampiran 1.
Sedangkan untuk isi dari file konfigurasi /etc/filebeat/filebeat.yml pada node
compute1 dan compute2 ada pada lampiran 2.
Pada lampiran 1 dan lampiran 2, penulis mendefinisikan log apa saja yang
akan diambil. Untuk contoh, penulis mengambil salah satu pendefinsian log yang
akan diambil yang ada pada gambar 4.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

Gambar 4.59 Contoh Multiline Log

4.3.10 Konfigurasi Metricbeat


Pada tahapan ini, penulis mengkonfigurasi file /etc/metricbeat/metricbeat.yml
pada semua OpenStack cluster nodes sehingga isi dari file tersebut sesuai dengan
gambar 4.60.

Gambar 4.60 Isi Dari File /etc/metricbeat/metricbeat.yml Pada


OpenStack Cluster Nodes
60

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

Gambar 4.61 Isi Dari File Konfigurasi /etc/logstash/conf.d/10-input.conf

c. Konfigurasi filter Logstash


Selanjutnya, penulis mengkonfigurasi file /etc/logstash/conf.d/30-
filter.conf pada node elastic. Karena file konfigurasi tersebut sampai 488
baris, maka penulis mencantumkannya pada lampiran yaitu lampiran 3.
Pada tahapan ini, penulis membuat filter untuk semua input yaitu dari
Beats(Filebeat dan Metricbeat) dan script Python. Untuk mengkonfigurasi
filter, penulis menggunakan beberapa plugin agar memudahkan, diantaranya:
1) Grok berfungsi untuk menguraikan entri data ke dalam field
tertentu,
2) Mutate berfungsi untuk mengubah data dalam sebuah field,
3) Ruby berfungsi untuk mengolah sebuah data menggunkan bahasa
pemrograman Ruby,
4) Date berfungsi untuk mengubah sebuah field yang berisi
keterangan waktu sehingga menjadi tipe data date pada Kibana,
5) Json berfungsi untuk menguraikan sebuah data JSON, dan
6) Translate berfungsi untuk mengubah sebuah string tertentu
menjadi string lainnya.
d. Konfigurasi output Logstash
Selanjutnya, penulis mengkonfigurasi file /etc/logstash/conf.d/90-
output.conf pada node elastic agar output dari Logstash terkirim ke
Elasticsearch. Penulis mengkonfigurasi file ini, sehingga isi dari file ini sesuai
dengan gambar 4.62.
62

Gambar 4.62 Isi Dari File /etc/logstash/conf.d/90-output.conf

Pada file tersebut, penulis mengkonfigurasi pada beberapa baris,


diantaranya adalah:
1) Baris hosts => ["10.203.203.40:9200"] untuk menentukan node
yang terinstal Elasticsearch,
2) Baris user untuk menentukan user pada Elasticsearch yang dipakai,
3) Baris password untuk menentukan kata sandi,
4) Baris manage_template untuk menentukan template dari index,
5) Baris index untuk menentukan nama index yang digunakan.
4.3.12 Konfigurasi dashboard pada Kibana
Pada tahapan ini penulis mengkonfigurasi Kibana pada node elastic dengan
membuat visualisasi data berupa diagram dan sebagainya. Pada tahapan ini, penulis
membagi lagi menjadi 4 bagian, yaitu bagian pembuatan role untuk user
logstash_internal, pembuatan user logstash_internal, penambahan index
pattern, dan pembuatan dashboard. Nantimya user ini akan dipakai oleh Logstash
untuk input data.
a. Pembuatan role untuk user logstash_internal
Untuk membuat role pada Kibana, harus login terlebih dahulu. Pada
proyek ini,penulis menggunakan kredensial dengan username elastic dan kata
sandi sesuai dengan yang telah diatur pada poin g saat instalasi dan
konfigurasi Elasticsearch untuk login ke dalam Kibana. Setelah login ke
dalam Kibana, tekan tombol Menu kemudian pada bagian Management tekan
Stack Management sesuai pada gambar 4.63.
63

Gambar 4.63 Letak Tombol Stack Management

Setelah masuk ke Stack Management, tekan tombol Roles pada bagian


Security sesuai pada gambar 4.64. Setelah menekan tombol Roles maka tekan
tombol Create role seperti pada gambar 4.65.

Gambar 4.64 Letak Tombol Roles

Gambar 4.65 Tombol Create role


64

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.

Gambar 4.66 Form Pembuatan Role

b. Pembuatan user logstash_internal


Setelah membuat role, selanjutnya penulis membuat user bernama
logstash_internal. Untuk membuat user, hampir sama seperti membuat role
yaitu masuk ke Stack Management seperti pada gambar 4.63. Setelah masuk
ke Stack Management tekan tombol Users pada bagian Security seperti pada
gambar 4.67.

Gambar 4.67 Letak Tombol Users


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.

Gambar 4.68 Tombol Create User

Gambar 4.69 Form Pembuatan User


66

c. Penambahan Index patterns


Untuk menambahkan index patterns, langkah pertama yang dilakukan
adalah masuk ke Stack Management seperti pada gambar 4.63. Setelah
masuk ke Stack Management tekan tombol Index Patterns pada bagian
Kibana seperti pada gambar 4.70.

Gambar 4.70 Letak Tombol Index Patterns

d. Pembuatan dashboard pada Kibana


Tahap terakhir pada proyek ini, penulis membuat dashboard pada
Kibana. Pada tahapan ini, penulis membuat beberapa visualisasi data pada
dashboard Kibana, diantaranya adalah:
1) Jumlah Nova instances yang telah dibuat,
2) Jumlah vCPUs yang dipakai oleh Nova instances,
3) Jumlah vCPUs yang belum dipakai oleh Nova instances,
4) Jumlah penyimpanan yang dipakai oleh Nova instances,
5) Jumlah penyimpanan yang belum dipakai oleh Nova instances,
6) Jumlah RAM yang dipakai oleh Nova instances,
7) Jumlah RAM yang belum dipakai oleh Nova instances,
8) Penggunaan CPU pada OpenStack cluster nodes,
9) Penggunaan RAM pada OpenStack cluster nodes,
10) Percobaan login pada layanan Horizon dashboard,
11) Detail percobaan login pada layanan Horizon dashboard,
12) Log dari status instances pada layanan Nova, dan
13) Jumlah error pada setiap layanan di OpenStack.
67

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.

Gambar 4.71 Letak Tombol Dashboard

Setelah ditekan, kemudian tekan tombol Create dashboard pada


gambar 4.72 untuk membuat dashboard baru. Setelah itu, langsung saja
penulis membuat visualisasi data nomor 1, yaitu Jumlah Nova instances
yang telah dibuat.

Gambar 4.72 Tombol Create Dashboard

Untuk membuat visualisasi nomor 1, pertama penulis menekan tombol


Create visualization seperti pada gambar 4.73.

Gambar 4.73 Tombol Create Visualization

Kemudian pada tipe visualisasinya, penulis memilih Metrics seperti


pada gambar 4.74.
68

Gambar 4.74 Pemilihan Tipe Visualisasi

Kemudian untuk index pattern, penulis memilih logstash-hypervisor-


stats-* seperti pada gambar 4.75.

Gambar 4.75 Index Pattern yang Digunakan

Kemudian pada konfigurasi Metric, penulis mengisi seperti pada


gambar 4.76. Setelah itu, tekan tombol Close kemudian tekan tombol Save.
69

Gambar 4.76 Konfigurasi Metric yang Digunakan Pada Visualisasi Nomor 1

Selanjutnya, penulis membuat visualisasi nomor 2, sama seperti pada


visualisasi nomor 1 hanya saja penulis mengubah konfigurasi Metric seperti
pada gambar 4.77.
70

Gambar 4.77 Konfigurasi Metric yang Digunakan Pada Visualisasi Nomor 2

Selanjutnya, penulis membuat visualisasi nomor 3, sama seperti pada


visualisasi nomor 1 hanya saja penulis mengubah konfigurasi Metric seperti
pada gambar 4.78.
71

Gambar 4.78 Konfigurasi Metric yang Digunakan Pada Visualisasi Nomor 3

Pada visualisasi nomor 3 ini, penulis mengisi konfigurasi Metrics


dengan jenis Formula. Pada jenis Formula, penulis mengisikan rumus
dimana rumusnya yaitu mengurangi jumlah vCPUs yang belum dipakai
dengan yang sudah dipakai.
Selanjutnya, penulis membuat visualisasi nomor 4 dengan memakai
Metrics jenis Formula, sama seperti pada visualisasi nomor 3 hanya saja
penulis mengubah konfigurasi Metric seperti pada gambar 4.79. Isi dari
rumusnya adalah mengkonversi nilai dari jumlah penyimpanan yang terpakai
dari gigabytes menjadi bytes agar sesuai dengan Value format.
72

Gambar 4.79 Konfigurasi Metric yang Digunakan Pada Visualisasi Nomor 4

Selanjutnya, penulis membuat visualisasi nomor 5 dengan memakai


Metrics jenis Formula, sama seperti pada visualisasi nomor 4 hanya saja
penulis mengubah konfigurasi Metric seperti pada gambar 4.80. Isi dari
rumusnya adalah mengkonversi nilai dari jumlah penyimpanan yang belum
terpakai dari gigabytes menjadi bytes agar sesuai dengan Value format.
73

Gambar 4.80 Konfigurasi Metric yang Digunakan Pada Visualisasi Nomor 5

Selanjutnya, penulis membuat visualisasi nomor 6 dengan memakai


Metrics jenis Formula, sama seperti pada visualisasi nomor 4 hanya saja
penulis mengubah konfigurasi Metric seperti pada gambar 4.81. Isi dari
rumusnya adalah mengkonversi nilai dari jumlah RAM yang terpakai dari
megabytes menjadi bytes agar sesuai dengan Value format.
74

Gambar 4.81 Konfigurasi Metric yang Digunakan Pada Visualisasi Nomor 6

Selanjutnya, penulis membuat visualisasi nomor 7 dengan memakai


Metrics jenis Formula, sama seperti pada visualisasi nomor 4 hanya saja
penulis mengubah konfigurasi Metric seperti pada gambar 4.82. Isi dari
rumusnya adalah mengurangi nilai dari jumlah RAM dengan jumlah yang
sudah terpakai kemudian mengkonversi dari megabytes menjadi bytes agar
sesuai dengan Value format.
75

Gambar 4.82 Konfigurasi Metric yang Digunakan Pada Visualisasi Nomor 7

Selanjutnya, penulis membuat visualisasi nomor 8. Pada visualisasi


nomor 8 menggunakan visualisasi jenis Time Series. Untuk menambahkan
visualisasi jenis Time Series tekan pada dropdown All types kemudian tekan
tombol TVSB seperti pada gambar 4.83.
76

Gambar 4.83 Tombol Untuk Menambahkan Visualisasi Jenis Time Series

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.84 Konfigurasi Time Series Untuk Visualisasi Nomor 8

Kemudian, penulis mengkonfigurasi pada ketiga form data seperti pada


gambar 4.85 untuk node controller.

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

Kemudian penulis mengkonfigurasi Index pattern yang digunakan


pada tab Panel options dan mengisi Index pattern dengan logstash-
metricbeat-* seperti pada gambar 4.88.
79

Gambar 4.88 Konfigurasi Index Pattern Untuk Visualisasi Nomor 8

Selanjutnya, penulis membuat visualisasi nomor 9. Sama seperti


visualisasi nomor 8, pada visualisasi nomor 9 penulis menggunakan
visualisasi jenis Time Series. Untuk menambahkan visualisasi jenis Time
Series tekan pada dropdown All types kemudian tekan tombol TVSB seperti
pada gambar 4.89.

Gambar 4.89 Tombol Untuk Menambahkan Visualisasi Jenis Time Series

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.90 Konfigurasi Time Series Untuk Visualisasi Nomor 9

Kemudian, penulis mengkonfigurasi pada ketiga form data seperti pada


gambar 4.91 untuk node controller.

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

Selanjutnya, penulis membuat visualisasi nomor 10. Pada visualisasi


nomor 10 penulis menggunakan visualisasi jenis Bar vertical stacked. Untuk
menambahkan visualisasi jenis Bar vertical stacked tekan pada tombol
Create visualization seperti pada gambar 4.94.

Gambar 4.94 Tombol Create Visualization

Setelah itu, pada Visualization type pilih Bar vertical stacked seperti
pada gambar 4.95.

Gambar 4.95 Memilih Visualization Type


82

Kemudian, pada Index pattern yang digunakan penulis memilih


logstash-openstack.horizon-* seperti pada gambar 4.96.

Gambar 4.96 Index Pattern yang Digunakan Untuk Visualisasi Nomor 10

Kemudian untuk Horizontal axis penulis menggunkan @timestamp


dan untuk Vertical axis, penulis menambahkan 2 data, yaitu:
1) Data login yang sukses pada layanan Horizon yang konfigurasinya
ada pada gambar 4.97, dan
2) Data login yang gagal pada layanan Horizon yang konfigurasinya
ada pada gambar 4.98.

Gambar 4.97 Konfigurasi Vertical Axis Nomor 1 Pada Visualisasi Nomor 10


83

Gambar 4.98 Konfigurasi Vertical Axis Nomor 2 Pada Visualisasi Nomor 10

Pada konfigurasi Vertical axis , penulis mengisi beberapa form. Untuk


form Select a function berfungsi untuk menentukan fungsi yang digunakan.
Pada konfigurasi ini, penulis mengisi keduanya dengan Count yang artinya
menghitung jumlah log yang sesuain dengan filter.
Untuk form Select a field berfungsi untuk menentukan filed mana yang
akan dihitung. Disini penulis mengisi dengan Records yang artinya
menghitung jumlah semua log. Kemudian untuk form Filter by berfungsi
untuk menentukan kondisi log yang akan dihitung. Pada Vertical axis nomor
1 kondisinya adalah jika auth.type:”login” dan result:”success”. Sedangkan
pada Vertical axis nomor 2 kondisinya adalah jika auth_type:”login” dan
result:”success”.
Kemudian ada form Display name untuk menentukan nama. Kemudian
ada form Value format untuk menentukan jenis format nilainya. Disini
penulis mengisi Value format dengan jenis number dan decimal 0. Kemudian
ada form Series color untuk menentukan warna dari visualisasinya.
84

Selanjutnya, penulis membuat visualisasi nomor 11. Pada visualisasi


nomor 11 penulis menggunakan visualisasi berupa hasil dari search pada
Discover. Untuk membuat visualisasi ini, tekan tombol menu kemudian tekan
tombol Discover pada bagian Analytics. Kemudian penulis membuat search
pada Discover dengan Index pattern ada pada logstash-openstack.horizon-*
seperti pada gambar 4.99.

Gambar 4.99 Index Pattern yang Dipakai Untuk Visualisasi Nomor 11

Kemudian pada gambar 4.100, penulis mengisi form Selected fields


dengan beberapa pilihan, yaitu result untuk menampilkan hasil dari login
berupa sukses atau gagal, domain untuk menampilkan pada domain mana
proses autentikasi tersebut, user berfungsi untuk menampilkan nama user
yang melakukan proses autentikasi tersebut, dan clientip untuk menampilkan
alamat IP yang dipakai oleh user untuk melakukan proses autentikasi
tersebut.

Gambar 4.100 Field yang Ditampilkan Untuk Visualisasi Nomor 11


85

Kemudian pada form search pada gambar 4.101 penulis mengisi


dengan auth_type : "login" agar hanya menampilkan percobaan login.

Gambar 4.101 Filter yang Diisi

Setelah itu, penulis langsung menyimpan search ini dengan menekan


tombol save seperti pada gambar 4.102 kemudian mengisikan nama dengan
Horizon login.

Gambar 4.102 Tombol Save

Setelah membuat hasil search disimpan, kemudian penulis kembali ke


Dashboard dan menekan tombol Add from library seperti pada gambar 4.103
untuk menambahkannya ke dashboard, kemudian pilih hasil search
sebelumnya yaitu Horizon login seperti pada gambar 4.104 maka visualisasi
nomor 11 sudah ditambahkan ke dashboard.

Gambar 4.103 Tombol Add From Library

Gambar 4.104 Penambahan Visualisasi Nomor 11 Dari Library

Selanjutnya, penulis membuat visualisasi nomor 12. Pada visualisasi


nomor 12 penulis menggunakan visualisasi yang jenisnya sama dengan
visualisasi nomor 11. Untuk membuat visualisasi ini, tekan tombol menu
kemudian tekan tombol Discover pada bagian Analytics. Kemudian penulis
membuat search pada Discover dengan Index pattern ada pada logstash-
86

openstack.nova.compute-* hampir seperti pada gambar 4.99 hanya saja index


pattern yang dipilihnya berbeda.
Kemudian pada gambar 4.105, penulis mengisi form Selected fields
dengan instance_id untuk menampilkan id dari instance, host.name untuk
menampilkan pada node mana instance tersebut dijalankan, dan status untuk
menampilkan keterangan status dari instance.

Gambar 4.105 Field yang Ditampilkan Untuk Visualisasi Nomor 12

Kemudian penulis menambahkan filter seperti pada gambar 4.106 agar


hanya menampilkan log yang kolom status terdapat nilai. Setelah itu, penulis
lansung menyimpan search ini dengan menekan tombol save kemudian
mengisikan nama dengan Nova compute logs.

Gambar 4.106 Filter yang Digunakan Untuk Visualisasi Nomor 12

Setelah hasil search tersimpan, kemudian penulis kembali ke


Dashboard dan menekan tombol Add from library untuk menambahkan hasil
search ke dashboard, kemudian pilih hasil search sebelumnya yaitu Nova
compute logs seperti pada gambar 4.107 maka visualisasi nomor 12 sudah
ada di dashboard.
87

Gambar 4.107 Proses Menambahkan Visualisasi dari Library

Terakhir, penulis membuat visualisasi nomor 13. Pada visualisasi


nomor 13 penulis menggunakan visualisasi yang jenisnya sama dengan
visualisasi nomor 10 yaitu Bar vertical stacked. Untuk menambahkan
visualisasi jenis Bar vertical stacked tekan pada tombol Create visualization
seperti pada gambar 4.108.

Gambar 4.108 Tombol Create Visualization

Setelah itu, pada Visualization type pilih Bar vertical stacked seperti
pada gambar 4.109.

Gambar 4.109 Proses Pemilihan Jenis Visualisasi Untuk Visualisasi Nomor 13

Kemudian, pada Index pattern yang digunakan penulis memilih


logstash-openstack.* seperti pada gambar 4.110.
88

Gambar 4.110 Index Pattern yang Digunakan Untuk Visualisasi Nomor 10

Kemudian untuk Horizontal axis penulis menggunkan @timestamp.


Sedangkan untuk Vertical axis, penulis menambahkan dengan nilai jumlah
log yang memiliki field log_level yang bernilai ERROR.

Gambar 4.111 Konfigurasi Vertical Axis Pada Visualisasi Nomor 13

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

Gambar 4.112 Jumlah Error Pada Setiap Layanan OpenStack

4.4.2 Pencarian error pada OpenStack dengan Elastic Stack


Pada pengujian selanjutnya, penulis menguji bahwa fungsi discover pada
Kibana dapat mencari error yang ada pada layanan OpenStack. Pada gambar 4.113
diketahui bahwa pada layanan Nova compute mengalami error pada pukul
18:29:47.886 WIB. Pada gambar 4.113 tersebut diketahui bahwa error tersebut
dapat diartikan bahwa layanan Nova compute pada compute2 tidak merespon atau
sedang dalam keadaan mati.

Gambar 4.113 Pesan Error Pada Layanan Nova Compute

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

Gambar 4.114 Monitoring Penggunaan CPU Pada OpenStack Cluster Nodes

4.4.4 Monitoring penggunaan RAM pada OpenStack Cluster Nodes


Pada pengujian selanjutnya, penulis menguji bahwa penulis dapat memantau
penggunaan RAM pada OpenStack cluster nodes(node controller, compute1, dan
compute2). Pada gambar 4.115, dapat diketahui bahwa pada pukul 22.01 WIB
penggunaan RAM pada node controller sebesar 58.997%, kemudian pada node
compute1 sebesar 16.227%, sedangkan pada node compute2 sebesar 16.212%.

Gambar 4.115 Monitoring Penggunaan RAM Pada OpenStack Cluster Nodes


92

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

4.4.7 Monitoring jumlah RAM yang digunakan untuk Nova instance


Pada pengujian selanjutnya, penulis menguji bahwa penulis dapat mengetahui
jumlah RAM yang terpakai maupun belum terpakai oleh layanan Nova. Pada
gambar 4.118, dapat diketahui bahwa jumlah RAM yang terpakai oleh layanan Nova
sebanyak 1.5 GB dan belum terpakai sebanyak 14.08 GB.
93

Gambar 4.118 Jumlah RAM yang Sudah Terpakai dan Belum Terpakai

4.4.8 Monitoring jumlah penyimpanan yang digunakan untuk Nova instance


Pada pengujian selanjutnya, penulis menguji bahwa penulis dapat mengetahui
jumlah penyimpanan yang terpakai maupun belum terpakai oleh layanan Nova.
Pada gambar 4.119, dapat diketahui bahwa jumlah penyimpanan yang terpakai oleh
layanan Nova sebanyak 2 GB dan belum terpakai sebanyak 18 GB.

Gambar 4.119 Jumlah Penyimpanan yang Sudah Terpakai dan Belum Terpakai

4.4.9 Melihat riwayat status pada Nova instance


Pada pengujian selanjutnya, penulis menguji bahwa penulis dapat melihat
riwayat status pada Nova instance. Status disini berarti kapan sebuah instance
dibuat, dijalankan, dihapus, maupun di-reboot. Pada gambar 4.120, dapat diketahui
bahwa instance dengan id d271766d-8fd8-4fe3-b6a4-543518b963f9 dibuat dan
dihapus secara berturut-turut pada pukul 22:21:50.609 WIB dan 22:32:09.359 WIB.

Gambar 4.120 Riwayat Status Pada Nova Instance


94

4.4.10 Melihat riwayat proses autentikasi pada layanan Horizon di


OpenStack
Pada pengujian terakhir, penulis menguji bahwa penulis dapat melihat
riwayat proses autentikasi pada layanan Horizon. Pada gambar 4.121, dapat
diketahui bahwa user admin pada pukul 22:17:59.897 WIB telah login.

Gambar 4.121 Riwayat Proses Autentikasi Pada Layanan Horizon

Selain itu, pada gambar 4.122, penulis juga dapat melihat jumlah percobaan
login yang sukses maupun gagal.

Gambar 4.122 Jumlah Proses Autentikasi Pada Layanan Horizon


BAB V
PENUTUP

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.

Gambar 5.1 Contoh Arsitektur Multi-node Cluster Pada Elastic Stack

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

OpenStack. (2018). OpenStack Docs: Kolla’s Deployment Philosophy. Diambil


kembali dari Openstack.org: https://docs.openstack.org/kolla-
ansible/stein/admin/deployment-philosophy.html#overview
OpenStack. (2019). OpenStack Docs: Placement. Diambil kembali dari
Openstack.org: https://docs.openstack.org/placement/ussuri/
OpenStack. (2020). OpenStack Docs: OpenStack Compute (nova). Diambil
kembali dari Openstack.org: https://docs.openstack.org/nova/ussuri/
OpenStack. (2022). Open Source Cloud Computing Platform Software -
OpenStack. Diambil kembali dari OpenStack:
https://www.openstack.org/software/releases/stein/components/kolla-
ansible
Peter, M., & Timothy, G. (2011). The NIST Definition of Cloud Computing. NIST
Special Publication 800-145, 2-3.
Safira, A. P. (2021, 10 29). Topologi Jaringan Komputer: Pengertian & Jenisnya -
GFN Blog. Diambil kembali dari GFN Blog:
https://www.goldenfast.net/blog/topologi-jaringan-komputer/
Talaş, A., Pop, F., & Neagu, G. (2017). Elastic stack in action for smart cities:
Making sense of big data. 2017 13th IEEE International Conference on
Intelligent Computer Communication and Processing (ICCP), 471-472.
LAMPIRAN

Lampiran 1 . File /etc/filebeat/filebeat.yml Pada Node Controller


filebeat.config.modules.path: ${path.config}/modules.d/*.yml
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/kolla/cinder/cinder-api.log
fields:
log_type: openstack.cinder.api
- type: log
enabled: true
paths:
- /var/log/kolla/cinder/cinder-backup.log
fields:
log_type: openstack.cinder.backup
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/cinder/cinder-manage.log
fields:
log_type: openstack.cinder.manage
- type: log
enabled: true
paths:
- /var/log/kolla/cinder/cinder-scheduler.log
fields:
log_type: openstack.cinder.scheduler

98
99

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/cinder/cinder-volume.log
fields:
log_type: openstack.cinder.volume
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/cinder/cinder-wsgi.log
fields:
log_type: openstack.cinder.wsgi
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/glance/glance-api.log
fields:
log_type: openstack.glance.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._]+ \['
100

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

Lampiran 2 . File /etc/filebeat/filebeat.yml Pada Node Compute


filebeat.config.modules.path: ${path.config}/modules.d/*.yml
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/kolla/cinder/cinder-backup.log
fields:
log_type: openstack.cinder.backup
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/cinder/cinder-volume.log
fields:
log_type: openstack.cinder.volume
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
107

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

Lampiran 3 . File /etc/logstash/conf.d/30-filter.conf Pada Node Elastic


filter {
if [fields][log_type] == "openstack.cinder.api" {
grok {
match => { "message" => "%{YEAR:tahun}-%{MONTHNUM:bulan}-
%{MONTHDAY:tanggal}[T
]%{HOUR:jam}:?%{MINUTE:menit}(?::?%{SECOND:detik})?%{ISO8601_TI
MEZONE:timezone}?"}
}
mutate {
add_field => { "[system][timestamp]" => "%{tahun}-%{bulan}-
%{tanggal}T%{jam}:%{menit}:%{detik}+07:00" }
remove_field => [ "tahun", "bulan", "tanggal", "jam", "menit", "detik" ]
}
ruby {
path => "/etc/logstash/rubyfilter/precision-timestamp-parse.logstash-filter-
ruby.rb"
script_params => {
source => "[system][timestamp]"
format => ["ISO8601"]
}
}
mutate {
add_tag => [ "cinder" ]
}
}
if [fields][log_type] == "openstack.cinder.wsgi" {
grok {
match => { "message" => "%{TIMESTAMP_ISO8601:timestamp}
%{NUMBER} %{LOGLEVEL:log_level} %{NOTSPACE:api}
?(%{GREEDYDATA:event})?"}
}
109

if "multiline" not in [log][flags]{


grok {
match => { "event" => "\[%{DATA:req_id} %{DATA:user_id}
%{DATA:project_id} %{DATA} %{DATA} %{DATA}\]
%{DATA:http_method} %{URI:uri}" }
add_tag => [ "request" ]
}
}
if "request" not in [tags] {
grok {
match => { "message" => "\[%{DATA:req_id} %{DATA:user_id}
%{DATA:project_id} %{DATA} %{DATA} %{DATA}\]
%{GREEDYDATA:response}" }
add_tag => [ "response" ]
}
}
date {
match => [ "timestamp", "ISO8601" ]
}
mutate {
add_tag => [ "cinder" ]
}
}
if [fields][log_type] == "openstack.cinder.backup" {
grok {
match => { "message" => "%{TIMESTAMP_ISO8601:timestamp}
%{NUMBER} %{LOGLEVEL:log_level} %{NOTSPACE:api}
?(%{GREEDYDATA:event})?"}
}
date {
match => [ "timestamp", "ISO8601" ]
}
110

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

add_field => { "accesstime" => "%{tahun}-%{bulan}-%{tanggal}


%{jam}:%{menit}:%{detik}+07:00" }
remove_field => [ "tahun", "bulan", "tanggal", "jam", "menit", "detik" ]
}
date {
match => [ "accesstime" , "yyyy-MMM-dd HH:mm:ss.SSSZ"]
}

}
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

%{DATA:response_code} %{DATA:body_sent_bytes} %{DATA}


\"%{DATA:referrer}\" \"%{DATA:user_agent}\""}
}
date {
match => [ "access_time", "dd/MMM/yyyy:HH:mm:ss Z" ]
}
mutate {
add_tag => [ "cinder" ]
}

}
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

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.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

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.openvswitch.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}"}
119

}
}
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

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.nova.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 {
121

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.nova.conductor" {
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" }
122

remove_field => [ "tahun", "bulan", "tanggal", "jam", "menit", "detik" ]


}
date {
match => [ "accesstime" , "yyyy-MM-dd HH:mm:ss.SSSZ"]
}
}
if [fields][log_type] == "openstack.nova.manage" {
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.nova.novncproxy" {
grok {
123

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.nova.scheduler" {
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 {
124

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.ovs.vswitchd" {
dissect {
mapping => { "message" =>
"%{timestamp}|%{line}|%{proccess}|%{log_level}|%{event}"}
}
date {
match => [ "timestamp" , "ISO8601"]
}
}
if [fields][log_type] == "openstack.ovsdb.server" {
dissect {
mapping => { "message" =>
"%{timestamp}|%{line}|%{proccess}|%{log_level}|%{event}"}
}
date {
match => [ "timestamp" , "ISO8601"]
}
}
125

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"
}
}
}

Anda mungkin juga menyukai