Selasa, 14 April 2026

Browser-Only Bastion: Akses CLI & GUI Tanpa VPN, SSH, RDP

Halo guys, Ridwan here..
Come again with a new notes update!

Sudah lama saya ingin punya cara akses server yang simpel tidak perlu install SSH client, RDP Client, tidak perlu setup VPN, tidak perlu bawa laptop khusus. Cukup buka browser, akses URL, dan langsung bisa kerja.

Untuk kalian yang belum paham, apa itu "Bastion"
Bastion host itu basically server yang jadi "pintu masuk" ke jaringan internal kita, Biasanya akses ke bastion butuh SSH client atau VPN. Nah, di setup ini, kita expose dua hal langsung ke browser:

  • Terminal shell  via ttyd, bisa ngetik command langsung dari browser
  • GUI browser (Firefox) via xpra, Firefox yang berjalan di server di-stream agar bisa akses WebApp Internal

Keduanya dibungkus Caddy sebagai reverse proxy (with auth), dengan Cloudflare di depannya untuk keamanan dan DNS management.

Arsitektur Singkat :

Semua service bind ke 127.0.0.1, jadi tidak langsung expose ke internet.
Cukup open satu port 80/443 melalui Caddy yang menjadi satu-satunya pintu masuk dari luar.

Ok, Penasaran cara install nya ?

1. Install ttyd

  • Download & install binary
$ wget https://github.com/tsl0922/ttyd/releases/latest/download/ttyd.x86_64
$ sudo chmod +x ttyd.x86_64 && mv ttyd.x86_64 /usr/local/bin/ttyd
  • Daftarkan menjadi Systemd (/etc/systemd/system/ttyd.service)
[Unit]
Description=ttyd Web Terminal
After=network.target

[Service]
ExecStart=ttyd -W -p 7681 -t fontSize=20 -t rendererType=canvas login
User=root
Restart=always

[Install]
WantedBy=multi-user.target

2. Install xpra + Firefox

  • Download & install binary
$ sudo apt install xpra firefox-esr
  • Daftarkan menjadi Systemd (/lib/systemd/system/xpra.service)
[Unit]
Description=Xpra Firefox Service
After=network.target

[Service]
User=root
Environment=DISPLAY=:100
ExecStart=/usr/bin/xpra start :100 \
    --bind-tcp=0.0.0.0:10000 \
    --html=on \
    --start-child="firefox --no-remote" \
    --exit-with-children \
    --daemon=no

Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target


3. Install Caddy Reverse_Proxy

  • Download & install binary
$ sudo apt install caddy

  • Edit Caddyfile ( /etc/caddy/Caddyfile )
gui.bastionmu.com {
    reverse_proxy localhost:10000
    
    basicauth /* {
        [Username] [Passwd-Hash]  ## Perhatikan ini - gunakan command "caddy hash-password"
    }
}

cli.bastionmu.com {
    reverse_proxy localhost:7681
    
    basicauth /* {
        [Username] [Passwd-Hash]   ## Perhatikan ini - gunakan command "caddy hash-password"
    }
}

Sesimple itu. Ganti bastion.example.com dengan domain kalian sendiri, dan Caddy akan otomatis urus certificate-nya !


4. Config Cloudflare (Opsional)

Opsi ini opsional, Tetapi jika bastion kalian memiliki IP Public ini menjadi hal wajib untuk dilakukan domain di-point ke server via Cloudflare dengan proxy mode aktif (ikon awan oranye). Btw, Real IP Addr nya jangan dikepoin ya guys ! 


 Beberapa benefit langsung yang kita dapat:

  • Real IP Addr server tersembunyi dari publik



















  • Basic DDoS / BruteForce Protection 

Web ini sudah di kasih "HTTP Authorization Header" untuk akses nya oleh Caddy, dengan Cloudflare kita bisa limit failed auth nya !
  • Bisa tambahkan Cloudflare Access untuk autentikasi Zero Trust tanpa modifikasi server.
  • Atau tambahkan Black/Whitelist IP, WAF Restrictions, IP/Bot Blocking, atau Security Features lainnya.

Hasilnya.. Setelah semua terpasang, ini yang bisa saya lakukan hanya dari browser:

  • ✅ Buka terminal server, cocok dari HP sekalipun
  • ✅ Akses Firefox yang berjalan di server, bisa browsing ke Aplikasi internal network
  • ✅ Semua tanpa install VPN client, tanpa SSH, RPD client, tanpa port forwarding tambahan yang ribet itu.
  • ✅ Bisa dibuka dari device apapun, laptop, tablet, HP, Head Unit Mobil Android.


Satu-satunya requirement di sisi client hanyalah Web Browser modern. Dan Spec/Flavor dari VM Bastion ini cukup low cost hanya "1 vCPU, 1 GiB Memory".

Sekian catatan kali ini,
Thank you sudah membaca tulisan ini.. Semoga bermanfaat!

Best Regards, 
Rdw

 

Share:

Jumat, 10 April 2026

Red Hat OpenStack Services on OpenShift (RHOSO) Deployment Workflow

 Halo guys, Ridwan here..
Come again with a new notes update!

Kali ini saya mau berbagi catatan dari Red Hat OpenStack Services on OpenShift (RHOSO) Deployment

Buat kalian yang berkecimpung di dunia infrastruktur atau cloud, pasti sudah familiar dengan OpenStack. Nah, RHOSO ini adalah evolusi dari deployment OpenStack konvensional, di sini control plane OpenStack berjalan sebagai pods di atas OpenShift Container Platform (OCP), sementara compute node-nya tetap menggunakan RHEL biasa.

Menarik, kan? Yuk langsung kita gas!

Deployment RHOSO terdiri dari 6 fase utama yang saling bergantung satu sama lain.

Fase Deskripsi
Phase 1 Install & konfigurasi OpenShift Cluster
Phase 2 Install prerequisite operators
Phase 3 Deploy control plane
Phase 4 Prepare data plane nodes
Phase 5 Deploy data plane
Phase 6 Konfigurasi untuk user workloads

Error atau miskonfigurasi di fase awal bisa berdampak ke fase berikutnya, jadi pastikan setiap fase sudah diverifikasi sebelum lanjut!


Phase 1 : Install OpenShift Cluster

Phase pertama adalah menyiapkan OpenShift Container Platform sebagai fondasi. OCP bisa berjalan di atas physical server maupun VM, dan bertugas menyediakan container orchestration platform untuk semua OpenStack services yang akan kita deploy nantinya. Setelah OCP terpasang, lakukan verifikasi berikut sebelum lanjut ke fase berikutnya:

  • ✅ Semua cluster operator berstatus Available dan tidak Degraded
  • ✅ Semua nodes berstatus Ready
  • Default storage class sudah tersedia
  • ✅ Autentikasi via oc login berhasil
  • DNS resolution untuk cluster hostname berfungsi normal


Phase 2 : Install Prerequisite Operators

Di fase ini, kita menyiapkan OCP dengan operator-operator yang dibutuhkan RHOSO. Yang pertama perlu dicek adalah Multus CNI plug-in biasanya sudah terinstall by default di OCP. Multus adalah meta-CNI plugin yang memungkinkan pods attach ke multiple network interface sekaligus, dan ini sangat krusial untuk isolated network architecture di OpenStack.

Cara verifikasi Multus:

  • Check pod Multus berjalan di namespace openshift-multus
  • Pastikan CRD Network Attachment Definition tersedia di cluster
  • Konfirmasi konfigurasi Multus CNI ada di /etc/cni/net.d/ pada worker nodes

Setelah Multus terverifikasi, install 4 operator berikut:

  1. NMState Operator Mengelola konfigurasi network di OpenShift nodes bridges, VLANs, dan physical network interface.
  2. MetalLB Operator Menyediakan load balancing untuk OpenStack services di secondary network. Bertugas mengalokasikan virtual IP untuk API endpoints OpenStack.
  3. Cert-manager Operator Manajemen TLS certificate untuk OpenStack services otomatis buat dan renew certificate.
  4. OpenStack Operator Ini yang paling utama! Setelah terinstall, operator ini akan menginstall operator-operator tambahan per service: keystone-operator, glance-operator, nova-operator, neutron-operator, cinder-operator, dan lainnya. Mereka bertugas me-watch OpenStackControlPlane custom resources dan manage lifecycle semua OpenStack services.


Phase 3 : Deploy Control Plane

Phase ini mencakup konfigurasi networking & storage resources, pembuatan service credentials, dan deployment OpenStack control plane services di atas OCP cluster.

Intinya di sinilah semua OpenStack service (Keystone, Glance, Nova, Neutron, Cinder, dst.) mulai di-deploy sebagai pods di dalam OpenShift.


Phase 4 : Prepare Data Plane Nodes

Sebelum compute nodes bisa bergabung ke cluster, RHEL servers perlu disiapkan terlebih dahulu. Ada dua jenis provisioning: pre-provisioned dan unprovisioned — catatan ini fokus ke pre-provisioned.

Tiga hal yang wajib disiapkan di RHEL servers:

  • Network Connectivity Pastikan server punya network interface yang dibutuhkan untuk isolated networks. Management interface harus sudah aktif. Untuk secondary networks, tenang saja — nanti akan dikonfigurasi otomatis oleh EDPM.
  • SSH Access SSH key-based authentication harus bisa digunakan untuk akses ke server. EDPM membutuhkan ini untuk menjalankan Ansible Playbooks secara remote.
  • Package Repositories Register server dengan rhc atau subscription-manager, atau ke Red Hat Satellite. Untuk disconnected environment, konfigurasikan local mirror atau Satellite terlebih dahulu.


Phase 5 : Deploy Data Plane

Phase ini menggunakan EDPM (External Data Plane Management) — automation engine berbasis Ansible untuk deploy compute nodes.

  • Langkah 1: Buat OpenStackDataPlaneNodeSet CR

CR ini mendefinisikan:

  • Daftar compute nodes (hostname + Ansible connection info)
  • Network config per node, termasuk IP address di setiap isolated network
  • List data plane services yang akan di-deploy: configure-network, install-os, ovn, nova, dll.
  • Langkah 2: Buat OpenStackDataPlaneDeployment CR

CR ini me-reference node set di atas dan men-trigger deployment. Ansible akan otomatis jalan di compute nodes untuk install packages, konfigurasi services, dan integrasi ke control plane.

Cara monitor progress deployment:

  • Watch status resource OpenStackDataPlaneDeployment
  • Lihat Ansible job logs di namespace openstack
  • Pantau progress per data plane service

Setelah selesai, verifikasi:

  • ✅ Compute nodes terdaftar di Nova sebagai hypervisors
  • ✅ OpenStack services running di compute nodes (cek via systemd)
  • ✅ Network agents running dan status alive
  • ✅ Komunikasi compute nodes ↔ control plane di semua isolated networks OK


Phase 6 : Konfigurasi untuk User Workloads

Phase terakhir ini mempersiapkan cluster agar siap dipakai oleh end users.

Projects & Users Buat initial projects untuk resource isolation dan quota management, lalu assign role ke users yang membutuhkan akses.

Networking Resources

  • Provider networks (mapping ke external VLAN untuk floating IP)
  • Tenant networks untuk komunikasi internal antar instance
  • Router untuk koneksi tenant ↔ provider network
  • Subnets dengan IP range dan gateway yang sesuai

Images & Flavors Upload OS images ke Glance, buat flavors (define vCPU/RAM/disk), dan konfigurasi security groups.

Verifikasi Fungsionalitas Buat test instance, verifikasi konektivitas antar instance, assign floating IP, test akses eksternal, dan jangan lupa test attach persistent volume dari Cinder.

Identity Management Integrasikan OpenShift + OpenStack dengan enterprise IdP (LDAP / OIDC / Keycloak), konfigurasi RBAC policies, dan aktifkan MFA untuk akses administratif.

Backup & Disaster Recovery

  • Backup reguler etcd OpenShift dan database control plane OpenStack
  • Dokumentasikan dan test disaster recovery procedures secara berkala
  • Tetapkan RTO (Recovery Time Objective) dan RPO (Recovery Point Objective)
  • Backup semua custom resources dan manifests

Security Hardening

  • Terapkan CIS benchmarks atau STIG
  • Enkripsi data at-rest dan in-transit
  • Konfigurasi audit logging untuk security events di OpenShift maupun OpenStack
  • Implementasikan network policies untuk restrict pod-to-pod communication


Referensi


Sekian catatan kali ini, Thank you sudah membaca tulisan ini.. Semoga bermanfaat!

Best Regards, Rdw



Share:

Rabu, 25 Maret 2026

Grafana Alloy: Satu Agent untuk Metrics, Logs, & Traces

 Halo guys, Ridwan here..
Come again with a new notes update!

Untuk kalian yang sudah terbiasa menggunakan monitoring tools Grafana, kalian pasti sudah familiar dengan agent berikut :

  • Node_Exporter (untuk mengambil metrics resource seperti CPU, RAM, Disk).
  • Promtail (untuk mengambil log data).

Tapi, pernahkah kalian merasa repot karena harus mengelola banyak agent sekaligus di satu server? Nah, di catatan kali ini saya mau mengenalkan "evolusi" dari agent-agent tersebut, yaitu Grafana Alloy.

Kenapa Harus Pindah ke Grafana Alloy?
Grafana Alloy bukan sekadar pengganti, melainkan sebuah kemajuan besar. Beberapa alasan utamanya:

  • Agent Consolidation: Gak perlu lagi pusing kelola banyak agent. Cukup satu tool untuk metrics, logs, dan traces.
  • Programmable Pipeline: Konfigurasinya menggunakan bahasa HCL (HashiCorp Configuration Language). Jadi lebih fleksibel dan readable, mirip seperti nulis Terraform!
  • OpenTelemetry (OTel) Native: Support penuh terhadap standar industri saat ini.

Multi-Architecture: Berbeda dengan Node_exporter lama, Alloy punya dukungan yang lebih luas untuk berbagai OS dan arsitektur hardware.

Simplenya, dengan Grafana Alloy, semua fungsi monitoring digabungkan jadi satu pintu. Penasaran gimana cara pakainya? 


Yuk, langsung kita gas!


1. Install Grafana Alloy (Fedora/RHEL)

Alloy bisa diinstal di mana saja: Docker, K8s, Linux, macOS, sampai Windows. Di tutorial ini, saya menggunakan Fedora dengan metode instalasi binary/RPM.

Langkah pertama, daftarkan dulu repo Grafana:

$ sudo tee /etc/yum.repos.d/grafana.repo <<EOF
[grafana]
name=grafana
baseurl=https://rpm.grafana.com
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://rpm.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
EOF

Langkah kedua, install Grafana Alloy nya:

$ sudo dnf install alloy -y

*Note: Untuk kalian yang menggunakan distro lain atau ingin menggunakan Docker, silakan cek dokumentasi resminya di https://grafana.com/docs/alloy/latest/set-up/install/


2. Konfigurasi Alloy (Metrics & SSH Logs)

Alloy menggunakan file konfigurasi ".alloy", Biar gak pusing nulis config dari nol, kita bisa pakai Alloy Configuration Generator berikut: https://grafana.github.io/alloy-configurator/

**Penting: Pastikan kalian menyesuaikan alamat IP Address dan endpoint tujuan (seperti URL Prometheus/Loki) agar data terkirim dengan benar.

Setelah dapet hasilnya dari generator tersebut, masukkan ke file /etc/alloy/config.alloy.

Jika sudah ready, langsung apply & aktifkan service-nya:

$ sudo systemctl restart alloy
$ sudo systemctl enable alloy --now


3. Konfigurasi di Sisi Prometheus

Ini bagian yang menarik. Di metode lama, Prometheus biasanya "menarik" (pull) data dari agent. Tapi dengan Alloy menggunakan metode Remote Write.


Pastikan service Prometheus kalian sudah berjalan dengan fitur remote write receiver yang aktif. Dengan begini, Prometheus tidak lagi repot scrape satu-satu ke target, melainkan menerima "setoran" data langsung dari Grafana Alloy.


Secara data, metrics yang dihasilkan Alloy tetap kompatibel dan serupa dengan yang dihasilkan Node_exporter, jadi kalian gak perlu merombak Dashboard Grafana kalian dari nol!


Sekian tutorial singkat kali ini, Thank you sudah membaca tulisan ini..
Semoga bermanfaat!

Best Regards,
Rdw

Share:

Kamis, 05 Maret 2026

Deploy ARM64 (aarch64) dengan Qemu & Virt-Manager

 Halo Guys, Ridwan heres! 
Come again with a new notes update!

Belakangan ini, arsitektur ARM64 atau aarch64 makin naik daun, mulai dari perangkat Raspberry Pi, Apple Silicon, sampai instance Public Cloud seperti AWS Graviton, Google, Azure, Oracle Ampere, semuanya mulai menyediakan ARM karena efisiensi dayanya yang luar biasa, tetapi tetap punya performa jempolan.

Kenapa sih mulai banyak yang memakai arsitektur ARM?

  • Hemat Daya: Cocok buat server rumahan yang nyala 24/7 tanpa bikin tagihan listrik bengkak.
  • Performa per watt: Di banyak skenario, prosesor ARM modern jauh lebih efisien dibandingkan dengan x86 tradisional.
  • Ekosistem Sudah mulai Matang: Sekarang hampir semua aplikasi open-source sudah mendukung arsitektur

Karena di masa depan akan banyak pengguna ARM, bagaimana cara kita melakukan troubleshooting atau mereplikasi issue, kalau pelanggan menggunakan instances dengan arsitektur ARM ?
Apakah kita perlu menyiapkan Perangkat Devices ARM atau berlangganan Cloud Services juga? Jawabannya tentu tidak.

Laptop harian kita yang biasanya menggunakan arsitektur x86_64 sudah bisa mengemulasikan/virtualisasikan ARM devices. Jadi, kita tidak perlu beli hardware baru atau langganan cloud services hanya untuk testing atau troubleshooting.

Penasaran gimana caranya? 
Yuk, simak catatan kali ini!


1. Install Cross-Architecture QEMU

Langkah pertama, kita butuh tools utama, yaitu QEMU. Kamu bisa langsung install dengan perintah ini:

# Debian / Ubuntu
$ sudo apt update
$ sudo apt install qemu-system-arm qemu-efi qemu-efi-aarch64 qemu-utils virt-manager

# RHEL / Fedora
$ sudo dnf group install --with-optional virtualization
$ sudo dnf install qemu-system-aarch64 qemu-utils virt-manager

Note: Paket qemu-system-arm ini adalah paket yang memungkinkan laptop kita menjalankan instruksi CPU ARM64 di atas prosesor Intel/AMD kalian.


2. Download ARM64 Cloud Image

Di sini kita tidak perlu menginstal secara manual menggunakan ISO file yang makan waktu lama. 
Cukup pakai Cloud Image saja yang sudah jadi (format .img atau .qcow2).


3. Create Virtual Machine ARM64

Oke, setelah file cloud images sudah di-download, Kita bisa langsung create VM-nya, tidak ada perbedaan yang jauh dalam membuat VM untuk ARM atau x64. Perhatikan perbedaannya !

Disini saya menggunakan Debian 13 dengan path /home/ridwan/Documents/Qcow2/debian-13-nocloud-arm64.qcow2

  • Menggunakan Qemu ( CLI ):
$ qemu-system-aarch64 \
  -machine virt \
  -cpu cortex-a57 \
  -smp 2 \
  -m 2G \
  -bios /usr/share/AAVMF/AAVMF_CODE.fd \
  -drive if=none,file=/home/ridwan/Documents/Qcow2/debian-13-nocloud-arm64.qcow2,id=hd0 \
  -device virtio-blk-device,drive=hd0 \
  -netdev user,id=net0 \
  -device virtio-net-device,netdev=net0 \
  -nographic

Note: untuk Spec CPU & RAM kalian dapat sesuaikan dengan kebutuhan, untuk path bios location pastikan sudah sesuai !




  • Menggunakan Virt-Manager (GUI)

Pada "Architecture options" pastikan kalian memilih :

  • Architecture = aarch64
  • Machine Type = Virt 

Kemudian pilih cloud images / qcow2 disk dari OS ARM kalian,

untuk Spec CPU ,RAM , Disk kalian dapat sesuaikan dengan kebutuhan

Next / Forward sampai step terakhir, dan tampil seperti berikut :

Note: Jangan kwatir ini normal, Pada banyak image Linux ARM64 (terutama versi server atau cloud image), output booting diarahkan ke Serial Console (ttyAMA0) secara default, bukan ke display grafis. ARM tidak memiliki standar VGA secara otomatis.


Solusinya:
Pilih menu "View" > Console > Pilih Serial 1


**Bonus: Create Ubuntu ARM64 Instances on Public Cloud

  • AWS Graviton (EC2)
# Launch a Graviton instance with Ubuntu 24.04
aws ec2 run-instances \
    --image-id $(aws ec2 describe-images \
        --filters "Name=name,Values=ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-arm64-server-*" \
                  "Name=state,Values=available" \
        --query 'sort_by(Images, &CreationDate)[-1].ImageId' \
        --output text \
        --region us-east-1) \
    --instance-type t4g.micro \
    --key-name your-key-pair \
    --region us-east-1
  • Google Cloud
# Via Google Cloud Shell
gcloud compute instances create [INSTANCE_NAME] \
    --project=[PROJECT_ID] \
    --zone=us-central1-a \
    --machine-type=t2a-standard-1 \
    --image-family=ubuntu-2204-lts-arm64 \
    --image-project=ubuntu-os-cloud \
    --boot-disk-size=20GB \
    --boot-disk-type=pd-balanced
  • Oracle Cloud 
# Via OCI CLI
oci compute instance launch \
    --compartment-id <compartment-id> \
    --availability-domain <ad-name> \
    --shape VM.Standard.A1.Flex \
    --shape-config '{"ocpus": 4, "memoryInGBs": 24}' \
    --image-id <ubuntu-24.04-arm64-image-id> \
    --subnet-id <subnet-id>
  • Hetzner Ampere
# Create an Arm64 server on Hetzner
hcloud server create \
    --name arm64-server \
    --type cax11 \    # Ampere Altra-based server type
    --image ubuntu-24.04 \
    --ssh-key your-key


Sekian tutorial singkat kali ini, Thank you sudah membaca tulisan ini.. 

Semoga bermanfaat !
Rdw
Share:

Sabtu, 31 Januari 2026

Mapping Process ID to Instance-ID Openstack

Halo Guys, Ridwan heres!  Come again with a new  notes update!

Kali ini saya mau berbagi sedikit tips Troubleshooting di OpenStack. Sebagai SysAdmin pasti pernah mengalami momen di mana Monitoring System Trigger Alert pada salah satu Compute Node (Hypervisor) yang mengalami High Load Resource Usage.


Alert di atas berisi informasi terkait kondisi Resource CPU usage melebihi nilai ambang batas normal, dan tidak ada informasi lebih details seperti penyebabnya apa, aplikasi apa yang menggunakan resource tersebut, dan lainnya.  Untuk mencari tahu details tersebut, kita butuh belajar kembali "Back to Basic" pada course di  Red Hat 124 dengan judul materi "Monitoring and Managing Linux Processes" 


1. Analisis Anomali Resource usage di Server Compute

Pada output command "top" akan ada banyak proses qemu-kvm karena server ini merupakan hypervisor tempat running nya VM.

top - 13:31:48 up 66 days, 23:50,  1 user,  load average: 126.82, 126.23, 128.78
Tasks: 3357 total,   4 running, 3353 sleeping,   0 stopped,   0 zombie
%Cpu(s): 52.4 us,  8.6 sy,  0.0 ni, 35.2 id,  0.0 wa,  1.9 hi,  1.8 si,  0.0 st
MiB Mem : 3094507.+total, 614593.1 free, 2479829.+used,  12083.9 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used. 614678.2 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 691730 qemu      20   0  518.2g 510.5g  22936 R  2646  16.9 565461:25 qemu-kvm
  75529 qemu      20   0   35.0g  31.8g  22584 S  1165   1.1 725669:37 qemu-kvm
 213227 qemu      20   0  132.2g 124.6g  22696 S 775.4   4.1 529504:26 qemu-kvm

Perhatikan baris pertama pada kolom PID dan %CPU. Di situ terlihat jelas ada proses dari qemu-kvm dengan PID 691730 yang menggunakan CPU secara tidak wajar (sampai 2646% karena multicore). Ini dia penyebab yang bikin load average server jadi tinggi.


2. Mencari Openstack ID-Instance dari Process ID (PID)

[tripleo-admin@Openstack-Compute-2 ~]$ ps aux | grep 691730

tripleo+  578303  0.0  0.0   6408  2316 pts/27   S+   13:31   0:00 grep --color=auto 691730
qemu      691730 1201 16.8 543362420 535312312 ? Sl    2025 565465:21 /usr/libexec/qemu-kvm -name guest=instance-00003161,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-324-instance-00003161/master-key.aes"} -machine pc-q35-rhel9.0.0,usb=off,dump-guest-core=off,memory-backend=pc.ram -accel kvm -cpu Cascadelake-Server-noTSX -m 524288 -object {"qom-type":"memory-backend-ram","id":"pc.ram","size":549755813888} -overcommit mem-lock=off -smp 64,sockets=64,dies=1,cores=1,threads=1 -uuid 457990e4-8d26-4f18-9940-72f652b99572 -smbios type=1,manufacturer=Red Hat,product=OpenStack Compute,version=23.2.3-17.1.20231018130828.el9ost,serial=457990e4-8d26-4f18-9940-72f652b99572,uuid=457990e4-8d26-4f18-9940-72f652b99572,family=Virtual Machine -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=59,server=on,wait=off -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device {"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"} -device {"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"} -device {"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"} -device {"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"} -device {"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"} -device {"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"} -device {"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"} -device {"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"} -device {"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"} -device {"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"} -device {"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"} -device {"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"} -device {"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"} -device {"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"} -device {"driver":"pcie-root-port","port":30,"chassis":15,"id":"pci.15","bus":"pcie.0","addr":"0x3.0x6"} -device {"driver":"pcie-root-port","port":31,"chassis":16,"id":"pci.16","bus":"pcie.0","addr":"0x3.0x7"} -device {"driver":"pcie-root-port","port":32,"chassis":17,"id":"pci.17","bus":"pcie.0","addr":"0x4"} -device {"driver":"pcie-pci-bridge","id":"pci.18","bus":"pci.1","addr":"0x0"} -device {"driver":"piix3-usb-uhci","id":"usb","bus":"pci.18","addr":"0x1"} -blockdev {"driver":"host_device","filename":"/dev/dm-8","aio":"native","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-1-storage"} -device {"driver":"virtio-blk-pci","bus":"pci.4","addr":"0x0","drive":"libvirt-1-format","id":"virtio-disk0","bootindex":1,"write-cache":"on","serial":"eb6afa3f-0f95-407e-a71f-94f013d98902"} -netdev {"type":"tap","fd":"62","vhost":true,"vhostfd":"64","id":"hostnet0"} -device {"driver":"virtio-net-pci","rx_queue_size":512,"host_mtu":8942,"netdev":"hostnet0","id":"net0","mac":"fa:16:3e:65:81:25","bus":"pci.2","addr":"0x0"} -netdev {"type":"tap","fd":"65","vhost":true,"vhostfd":"66","id":"hostnet1"} -device {"driver":"virtio-net-pci","rx_queue_size":512,"host_mtu":9000,"netdev":"hostnet1","id":"net1","mac":"fa:16:3e:63:c6:c3","bus":"pci.3","addr":"0x0"} -add-fd set=0,fd=61,opaque=serial0-log -chardev pty,id=charserial0,logfile=/dev/fdset/0,logappend=on -device {"driver":"isa-serial","chardev":"charserial0","id":"serial0","index":0} -device {"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"} -device {"driver":"usb-kbd","id":"input1","bus":"usb.0","port":"2"} -audiodev {"id":"audio1","driver":"none"} -vnc 172.22.74.116:8,audiodev=audio1 -device {"driver":"virtio-vga","id":"video0","max_outputs":1,"bus":"pcie.0","addr":"0x1"} -device {"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.5","addr":"0x0"} -object {"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"} -device {"driver":"virtio-rng-pci","rng":"objrng0","id":"rng0","bus":"pci.6","addr":"0x0"} -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on

Kalau kita baca argument dari command (qemu) nya panjang sekali, padahal kita hanya butuh informasi ID-Instances saja.

Kalian dapat menggunakan command berikut, untuk menemukan instances dengan CPU/Memory usage tertinggi ( --sort=-%cpu atau --sort=-%mem)

[tripleo-admin@Openstack-Compute-2 ~]$ ps aux --sort=-%cpu | awk 'NR==1 {print $1, $2, $3, $4, "UUID"} / -uuid / {for(i=1;i<=NF;i++) if($i=="-uuid") {print $1, $2, $3, $4, $(i+1)}}' | column -t
USER   PID      %CPU  %MEM  UUID
qemu   691730   2646  16.9  457990e4-8d26-4f18-9940-72f652b99572
qemu   75529    1165  1.1   e6175dac-d40f-4375-855c-b48632a28d68
qemu   213227   775.4 4.1   148f0a0b-b13d-4718-aff2-1bc2b11ec505
admin  1642873  0.0   0.0   /

Output dari command ini lebih rapih, mudah dipahami.

 

3. Check ID-Instances via Openstack Client 

Setelah mendapatkan ID dari instance, langkah selanjutnya adalah mengecek dari Openstack-Cli-Client atau Dashboard Horizon untuk mengatahui details info dari VM tersebut.

[stack@DIRECTOR ~]$ source overcloudrc
(overcloud) [stack@DIRECTOR ~]$ openstack server show 457990e4-8d26-4f18-9940-72f652b99572 --fit-width

+-------------------------------------+----------------------------------------------------------------------+
| Field                               | Value                                                                |
+-------------------------------------+----------------------------------------------------------------------+
| OS-DCF:diskConfig                   | MANUAL                                                               |
| OS-EXT-AZ:availability_zone         | nova                                                                 |
| OS-EXT-SRV-ATTR:host                | compute-2                                    |
| OS-EXT-SRV-ATTR:hypervisor_hostname | compute-2                                  |
| OS-EXT-SRV-ATTR:instance_name       | instance-00003161                                                    |
| OS-EXT-STS:power_state              | Running                                                              |
| OS-EXT-STS:task_state               | None                                                                 |
| OS-EXT-STS:vm_state                 | active                                                               |
| OS-SRV-USG:launched_at              | 2025-12-03T14:13:20.000000                                           |
| addresses                           | 2024399561-IT-Corp-DRC=10.24.216.154; VPC LAN CRM NG=192.168.100.253 |
| flavor                              | a1.xxxlarge.rc (df018f79-910f-4487-965b-2068585cb1ca)                |
| id                                  | 457990e4-8d26-4f18-9940-72f652b99572                                 |
| name                                | LAB-RDW001                                                      |
| project_id                          | 4af09b6255794f4bbc9b285fb5d7eb3d                                     |
| status                              | ACTIVE                                                               |
| user_id                             | 2ce9c0fc6163463b85c323ea07151e75                                     |
+-------------------------------------+----------------------------------------------------------------------+
Bingo!  pada kolom name,  kita akhirnya tahu bahwa VM yang menyebabkan load tinggi tersebut bernama LAB-RDW001.

Sekian tutorial singkat kali ini, Thank you sudah membaca tulisan ini.. 

Semoga bermanfaat !
Share:

Selasa, 27 Januari 2026

Monitoring Endpoint HTTP API dengan Blackbox Exporter

 Halo Guys, Ridwan here! Come again with a new notes update!

Kali ini saya mau berbagi sedikit catatan mengenai monitoring di dunia DevOps. 
Sebagai SysAdmin atau DevOps Engineer, kita pasti sudah familiar dengan Prometheus untuk scraping metrics dari server menggunakan Node Exporter, Kali ini kita akan bahas tool yang serupa dengan itu.

Pernah kah, teman-teman mengalami laporan website/aplikasi error, tetapi setelah kita check singkat pada semua service (HTTP, DB, Network, lainnya) statusnya, running. Ternyata yang error pada beberapa function di API Endpoint.

Nah, bagaimana cara kita tahu kalau website atau API kita benar-benar bisa diakses oleh user dari ? 
Server & servicenya mungkin running, tapi kalau aplikasinya / API timeout atau return 500, atau sedang high load jadi slow respond, atau juga ssl status nya ssl expired. Hal ini berdampak pada user menjadi tidak bisa akses kan?

Untuk menjawab kebutuhan tersebut, untuk selalu memantau website / API service dalam keadaan normal atau tidak nya, Kita perlu monitoring ini, Kita butuh tools "Blackbox Exporter."


Singkatnya, Blackbox Exporter ini memungkinkan kita untuk melakukan probing endpoint melalui berbagai protokol seperti HTTP, HTTPS, DNS, TCP, dan ICMP. Jadi kita bisa mengecek availability dan response time.

Yuk, langsung saja kita bahas cara setup-nya!


1. Persiapan & Instalasi Blackbox Exporter

Aplikasi ini bisa di-install dengan cara "Binary Install" atau dalam bentuk container menggunakan docker.

  • Download Binary
    https://github.com/prometheus/blackbox_exporter/releases

Create Systemd File (/etc/systemd/system/blackbox.service)



Docker command

docker run -d \
  --name=blackbox_exporter \
  -p 9115:9115 \
  -v $(pwd)/blackbox.yml:/etc/blackbox_exporter/config.yml \
  prom/blackbox-exporter --config.file=/etc/blackbox_exporter/config.yml

Setelah running, exporter ini akan berjalan di port 9115.


Yaps, tampilan hanya seperti, karena kita belum memberikan target endpoint untuk dimonitor.
Penasaran cara input target endpoint nya bagaimana ?


2. Konfigurasi Module (blackbox.yml)

Secara default, file blackbox.yml ini sudah cukup tidak perlu dilakukan edit-edit lagi.
hanya saya menambahkan parameter untuk menggunakan CA dari self-signed SSL.


3. Integrasi ke Prometheus

Jadi untuk target endpoint yang ingin di monitor oleh blackbox-exporte, di-input melalui prometheus. Berikut untuk config file "Prometheus.yml".


Setelah config prometheus ter'apply, dan status service Blackbox-exporter & Prometheus nya running.. Status tampilan dari port 9115 milik blacbkbox pages akan tampil seperti berikut :



4. Integrasi ke Grafana Dashboard

Setelah Blackbox-Exporter nya sudah berhasil memonitor beberapa target endpoint HTTP API tadi, selanjutnya kita akan membuat Grafana Dashboard untuk mem-visualisasikan data dari Blacbox-Exporter agar mudah dibaca oleh kita.


Caranya cukup Import saja dashboard tersebut.


Ok,  Sekian catatan kali ini, semoga kalian sudah berhasil melakukan monitoring HTTP / API respond dari aplikasi-aplikasi kalian. 

Next, apakah kita jadikan alert ?

Thank you sudah membaca tulisan ini.. Semoga bermanfaat !
Rdw

Share: