Metric Collection #

Metrik adalah pondasi dari semua sistem pemantauan berbasis data. Node Exporter atau exporter standar bawaan vendor sangat membantu untuk melacak kesehatan infrastruktur dasar. Namun, ketika kita dihadapkan pada skenario khusus — seperti mengumpulkan suhu sensor server fisik, memantau sisa kuota API pihak ketiga, atau mengurai file log aplikasi secara real-time — kita memerlukan agen pengumpul metrik yang lebih fleksibel dan database deret waktu (time-series database atau TSDB) yang mampu menangani pengiriman data berkecepatan tinggi. Artikel ini membahas penerapan tumpukan teknologi Telegraf dan InfluxDB sebagai solusi pengumpulan metrik khusus, bagaimana merancang model komunikasi push versus pull, serta bagaimana menulis kolektor kustom menggunakan skrip bash dan parser log berbasis pola Grok yang seluruh proses deployment-nya diotomatisasi dengan Ansible.

Arsitektur Pengumpulan Metrik: Push vs Pull #

Dalam dunia observability, terdapat perdebatan klasik mengenai metode terbaik untuk memindahkan metrik dari server target ke database terpusat: apakah server penampung yang menarik data dari target (Pull), atau agen di target yang mengirimkan data ke penampung (Push). Kedua model ini memiliki implikasi yang mendalam terhadap desain jaringan, keamanan, dan keandalan sistem kita.

Berikut adalah diagram perbandingan alur komunikasi antara model Pull (Prometheus) dan model Push (Telegraf/InfluxDB):

flowchart TD
    subgraph PullModel["Model Tarik (Pull - Prometheus)"]
        direction LR
        PROM["Prometheus Server"] -->|"HTTP GET /metrics"| T1["Target Agent (Exporter)"]
    end
    subgraph PushModel["Model Dorong (Push - Telegraf/InfluxDB)"]
        direction LR
        T2["Target Agent (Telegraf)"] -->|"HTTP POST (Line Protocol)"| INF["InfluxDB TSDB"]
    end

Model Pull (Tarik) #

Model Pull diwakili oleh sistem seperti Prometheus. Di sini, setiap target menjalankan layanan web kecil (exporter) yang mengekspos metrik di port tertentu. Prometheus secara periodik mengirimkan permintaan HTTP GET ke endpoint /metrics di setiap target.

• Kelebihan:
  • Deteksi Kematian Target: Jika Prometheus gagal menghubungi target, sistem langsung tahu bahwa target tersebut down.
  • Kontrol Beban: Server monitoring mengontrol sepenuhnya seberapa sering metrik diambil, mencegah server kebanjiran data.
  • Sederhana di Sisi Target: Agen target tidak perlu tahu alamat server monitoring atau memiliki token autentikasi write.
• Kekurangan:
  • Masalah Firewall: Server monitoring harus bisa menjangkau port target secara langsung. Ini sulit diterapkan jika target berada di balik jaringan privat atau NAT.
  • Ephemeral Service: Kurang cocok untuk fungsi serverless (seperti AWS Lambda) yang menyala hanya selama beberapa milidetik lalu mati.

Model Push (Dorong) #

Model Push diwakili oleh Telegraf yang mengirimkan data ke InfluxDB. Agen Telegraf dipasang di server target, mengumpulkan data secara lokal, lalu secara aktif mengirimkan payload HTTP POST berisi data metrik ke endpoint InfluxDB.

• Kelebihan:
  • Interoperabilitas Jaringan: Agen target hanya butuh akses keluar (outbound) ke internet/TSDB. Kita tidak perlu membuka port masuk (inbound) pada server target.
  • Mendukung Serverless dan Batch Job: Sangat ideal untuk skenario jangka pendek di mana instans menyala secara dinamis dan langsung mengirimkan status kerjanya sebelum dimatikan.
  • Skalabilitas Pengumpulan: Pengumpulan data terjadi secara independen di sisi klien, meringankan beban polling di sisi server TSDB.
• Kekurangan:
  • Kehilangan Status Agen: Jika agen berhenti mengirim data, TSDB tidak secara otomatis tahu apakah agen tersebut mati atau hanya tidak memiliki metrik baru untuk dikirim.
  • Manajemen Kredensial: Setiap agen harus dibekali token tulis (write token) yang aman agar bisa menulis ke InfluxDB.

Di dalam infrastruktur kita, kita dapat mengombinasikan keduanya. Kita menggunakan Telegraf untuk mengumpulkan metrik dari server-server edge yang berada di balik NAT privat, lalu mengonfigurasi Telegraf tersebut untuk mendorong data ke kluster InfluxDB terpusat.

Deployment Stack Data TSDB: InfluxDB dan Telegraf #

Untuk membangun infrastruktur pengumpulan metrik berbasis push, kita akan mendistribusikan InfluxDB v2 sebagai TSDB pusat dan Telegraf sebagai agen pengumpul di server target menggunakan Ansible.

1. Deployment InfluxDB v2 via Ansible #

Kita akan memasang InfluxDB v2 di server monitoring utama. Konfigurasi awal membutuhkan pendefinisian organisasi, bucket default, serta token administratif.

# playbooks/deploy_influxdb.yml
---
- name: Deploy InfluxDB Server
  hosts: monitoring_servers
  become: true
  vars:
    influxdb_version: "2.7.5"
    influxdb_org: "badritech"
    influxdb_bucket: "system_metrics"
  tasks:
    - name: Unduh paket instalasi InfluxDB
      get_url:
        url: "https://dl.influxdata.com/influxdb/releases/influxdb2-{{ influxdb_version }}-amd64.deb"
        dest: "/tmp/influxdb2.deb"
        mode: '0640'

    - name: Pasang paket deb InfluxDB
      apt:
        deb: "/tmp/influxdb2.deb"
        state: present

    - name: Pastikan layanan InfluxDB berjalan dan aktif
      systemd:
        name: influxdb
        state: started
        enabled: true

    - name: Tunggu hingga port InfluxDB siap menerima koneksi
      wait_for:
        port: 8086
        delay: 3
        timeout: 30

    - name: Cek apakah InfluxDB sudah diinisialisasi
      command: influx setup --check
      register: influx_check
      failed_when: false
      changed_when: false

    - name: Jalankan inisialisasi awal InfluxDB
      command: >
        influx setup
        --username "{{ influx_admin_user }}"
        --password "{{ vault_influx_admin_password }}"
        --org "{{ influxdb_org }}"
        --bucket "{{ influxdb_bucket }}"
        --token "{{ vault_influx_admin_token }}"
        --force        
      when: influx_check.rc == 0
      no_log: true

2. Deployment Agen Telegraf di Server Target #

Setelah server InfluxDB siap, kita memasang agen Telegraf di seluruh server target. Telegraf dikonfigurasi untuk mengumpulkan metrik sistem bawaan dan mengirimkannya ke InfluxDB menggunakan token yang telah kita buat.

# roles/telegraf_agent/tasks/main.yml
---
- name: Tambahkan kunci repositori InfluxData
  apt_key:
    url: https://repos.influxdata.com/influxdata-archive_compat.key
    state: present

- name: Tambahkan repositori resmi InfluxData
  apt_repository:
    repo: "deb https://repos.influxdata.com/debian stable main"
    state: present

- name: Pasang paket Telegraf
  apt:
    name: telegraf
    state: present
    update_cache: true

- name: Deploy file konfigurasi Telegraf
  template:
    src: telegraf.conf.j2
    dest: /etc/telegraf/telegraf.conf
    owner: root
    group: telegraf
    mode: '0640'
  notify: Restart Telegraf

- name: Pastikan Telegraf berjalan di latar belakang
  systemd:
    name: telegraf
    state: started
    enabled: true

Berikut adalah template konfigurasi telegraf.conf.j2 yang dikelola oleh Ansible:

{# roles/telegraf_agent/templates/telegraf.conf.j2 #}
[global_tags]
  environment = "{{ env }}"
  hostname = "{{ inventory_hostname }}"

[agent]
  interval = "10s"
  round_interval = true
  metric_batch_size = 1000
  metric_buffer_limit = 10000
  collection_jitter = "0s"
  flush_interval = "10s"
  flush_jitter = "0s"
  precision = "ns"
  hostname = ""
  omit_hostname = false

[[outputs.influxdb_v2]]
  urls = ["{{ influxdb_internal_url }}"]
  token = "{{ vault_telegraf_write_token }}"
  organization = "{{ influxdb_org }}"
  bucket = "{{ influxdb_bucket }}"

[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false
  report_active = false

[[inputs.disk]]
  ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"]

[[inputs.mem]]

[[inputs.system]]

Custom Bash Metrics Collector #

Ketika kita membutuhkan metrik spesifik yang tidak disediakan oleh plugin bawaan Telegraf, kita dapat membuat skrip shell kustom dan mengeksekusinya menggunakan plugin inputs.exec. Skrip ini harus mengeluarkan data dalam format Influx Line Protocol agar dapat dipahami langsung oleh Telegraf.

Format dasar Influx Line Protocol adalah sebagai berikut:

<measurement>,<tag_key>=<tag_value> <field_key>=<field_value> <timestamp>

Mari kita buat sebuah skrip bash untuk memantau status backup di server target:

#!/usr/bin/env bash
# file: /usr/local/bin/backup_metric.sh
# Skrip untuk melacak ukuran dan status keberhasilan backup terakhir.

BACKUP_DIR="/var/backups/postgres"
LAST_BACKUP_FILE=$(find "$BACKUP_DIR" -type f -name "*.sql.gz" -printf '%T@ %p\n' 2>/dev/null | sort -n | tail -1)

if [ -z "$LAST_BACKUP_FILE" ]; then
    # Jika tidak ada file backup
    echo "backup_status,status=failed size_bytes=0i,age_seconds=-1i"
    exit 0
fi

# Dapatkan timestamp saat ini dan timestamp file
CURRENT_TIME=$(date +%s)
FILE_EPOCH=$(echo "$LAST_BACKUP_FILE" | cut -d' ' -f1 | cut -d'.' -f1)
FILE_PATH=$(echo "$LAST_BACKUP_FILE" | cut -d' ' -f2-)

# Hitung usia file dan ukurannya
FILE_AGE=$((CURRENT_TIME - FILE_EPOCH))
FILE_SIZE=$(stat -c%s "$FILE_PATH" 2>/dev/null || echo 0)

# Tentukan status berdasarkan usia file (dianggap gagal jika lebih dari 26 jam)
STATUS="success"
if [ "$FILE_AGE" -gt 93600 ]; then
    STATUS="failed"
fi

# Keluarkan data dalam format Influx Line Protocol
# Integer diidentifikasi dengan akhiran 'i'
echo "backup_status,status=${STATUS} size_bytes=${FILE_SIZE}i,age_seconds=${FILE_AGE}i"

Berikut adalah alur bagaimana Telegraf berinteraksi dengan skrip bash kustom kita:

flowchart TD
    CRON["Telegraf Internal Timer"] -->|"Memicu eksekusi interval"| EXEC["Plugin inputs.exec"]
    EXEC -->|"Jalankan script"| BASH["/usr/local/bin/backup_metric.sh"]
    BASH -->|"Periksa direktori file"| BACKUP["Direktori Backup Postgres"]
    BACKUP -- "Metadata ukuran & waktu" --> BASH
    BASH -->|"Keluarkan output Line Protocol"| EXEC
    EXEC -->|"Kirim batch data"| OUT["Plugin outputs.influxdb_v2"]

Kita mengotomatisasi penyebaran skrip ini dan pendaftaran plugin di Telegraf melalui Ansible tasks:

- name: Salin skrip pemantau backup kustom
  copy:
    src: backup_metric.sh
    dest: /usr/local/bin/backup_metric.sh
    owner: root
    group: root
    mode: '0755'

- name: Deploy konfigurasi input exec Telegraf
  copy:
    content: |
      [[inputs.exec]]
        commands = ["/usr/local/bin/backup_metric.sh"]
        timeout = "5s"
        data_format = "influx"      
    dest: /etc/telegraf/telegraf.d/exec_backup.conf
    owner: root
    group: root
    mode: '0640'
  notify: Restart Telegraf

Logging Metrics Parser #

File log sering kali mengandung informasi metrik bernilai tinggi yang tidak diekspos oleh API internal aplikasi. Misalnya, dari log akses Nginx, kita bisa mengekstrak metrik jumlah request per kode status HTTP dan durasi respons. Kita dapat menggunakan plugin inputs.tail Telegraf dengan pola Grok untuk mengurai file log secara real-time menjadi data deret waktu terstruktur.

Mari kita konfigurasi Telegraf untuk membaca file log akses Nginx:

# Contoh format log akses Nginx standar:
127.0.0.1 - - [17/Jun/2026:10:25:32 +0700] "GET /api/v1/users HTTP/1.1" 200 452 0.125

Pola Grok untuk format di atas adalah:

%{IPORHOST:client_ip} - %{USER:ident} \[%{HTTPDATE:timestamp}\] "%{WORD:method} %{URIPATHPARAM:request} HTTP/%{NUMBER:http_version}" %{NUMBER:status:int} %{NUMBER:bytes:int} %{NUMBER:response_time:float}

Kita deploy konfigurasi logparser ini menggunakan Ansible ke server web:

- name: Deploy konfigurasi parser log Telegraf untuk Nginx
  copy:
    content: |
      [[inputs.tail]]
        files = ["/var/log/nginx/access.log"]
        from_beginning = false
        pipe = false
        data_format = "grok"
        grok_patterns = ['%{IPORHOST:client_ip} - %{USER:auth} \\[%{HTTPDATE:timestamp}\\] "%{WORD:verb} %{URIPATHPARAM:request} HTTP/%{NUMBER:http_version}" %{NUMBER:resp_code:int} (?:%{NUMBER:resp_bytes:int}|-) %{NUMBER:resp_time:float}']
        name_override = "nginx_access_log"      
    dest: /etc/telegraf/telegraf.d/nginx_logparser.conf
    owner: root
    group: root
    mode: '0640'
  notify: Restart Telegraf

Melalui konfigurasi ini, setiap baris log baru yang masuk ke /var/log/nginx/access.log akan dibaca oleh Telegraf, diparse berdasarkan pola Grok, dan dikirimkan ke InfluxDB sebagai metrik dengan tag seperti verb (HTTP Method) dan field seperti resp_time serta resp_code. Hal ini memungkinkan kita untuk memantau performa HTTP tanpa perlu menyentuh kode aplikasi.

Anti-Pattern dan Solusi Pengumpulan Metrik #

Selama implementasi pengumpulan metrik khusus, terdapat beberapa kesalahan fatal yang harus kita hindari demi menjaga kinerja sistem dan keamanan data.

1. Menyimpan Token Autentikasi Secara Terbuka #

• Anti-Pattern: Menuliskan token tulis InfluxDB langsung di dalam file playbook atau template Git dalam bentuk teks biasa. Siapa pun yang memiliki akses ke repositori Git dapat mencuri token tersebut dan merusak data di InfluxDB.
• Solusi: Enkripsi semua variabel sensitif menggunakan Ansible Vault. Saat runtime, Ansible akan mendekripsi variabel tersebut secara aman di memori sebelum disebarkan ke server target.

2. Menggunakan Script Exec Tanpa Batasan Waktu (Timeout) #

• Anti-Pattern: Menjalankan skrip kustom via inputs.exec yang melakukan koneksi database lambat atau query API eksternal tanpa timeout. Jika jaringan lambat, proses skrip akan menggantung, mengunci thread eksekusi Telegraf, dan menghentikan pengumpulan metrik sistem lainnya.
• Solusi: Selalu set parameter timeout yang ketat (misalnya timeout = "5s") di blok konfigurasi inputs.exec. Selain itu, pastikan skrip internal kita juga mengimplementasikan timeout internal pada setiap koneksi jaringan.

3. Mengabaikan Rotasi File Log pada Parser Tail #

• Anti-Pattern: Mengonfigurasi inputs.tail untuk membaca file log berukuran gigabyte tanpa adanya sistem rotasi log. Hal ini membuat Telegraf memakan memori CPU yang besar saat startup karena harus melacak perubahan posisi file.
• Solusi: Pastikan layanan logrotate dikonfigurasi dengan benar di sistem operasi untuk memecah file log secara berkala (misalnya harian atau berdasarkan ukuran). Telegraf secara native mendukung rotasi log dan akan mendeteksi pergantian file secara otomatis tanpa kehilangan data.

Berikut adalah perbandingan penanganan variabel sensitif (Token) antara metode yang salah dan metode yang benar menggunakan Ansible Vault:

# ANTI-PATTERN: Token ditulis langsung di file konfigurasi (Plain Text)
# group_vars/all.yml
telegraf_influx_token: "my-super-secret-admin-token-write-direct"

# BENAR: Menggunakan variabel terenkripsi Ansible Vault
# group_vars/all.yml (File di-enkripsi dengan ansible-vault encrypt)
# $ ansible-vault view group_vars/all.yml
vault_telegraf_write_token: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          36353934333939393739663836373839626330386230323337653634356461323331393666666465
          6430313136363462313639643532393361303831626233360a333333333333333333333333333333
          3333333333333333333333333333333333333333330a383236356265613337626365313962663962

Dengan mengadopsi standar enkripsi variabel, kita memperkuat postur keamanan seluruh rantai pengumpulan metrik.

Ringkasan #

• Telegraf dan InfluxDB membentuk tumpukan teknologi ideal untuk arsitektur pengumpulan metrik berbasis push, yang sangat cocok untuk server di balik NAT privat.
• Model Push memungkinkan agen mengirimkan data secara mandiri ke TSDB pusat melalui akses outbound port 8086, menyederhanakan konfigurasi firewall target.
• Influx Line Protocol adalah format pengiriman metrik berbasis teks yang ringkas, membagi data menjadi measurement, tag (index), field (non-index), dan timestamp.
• Plugin inputs.exec Telegraf mempermudah integrasi metrik sistem kustom dengan mengeksekusi skrip bash atau python lokal secara berkala.
• Pola Grok di dalam plugin inputs.tail memungkinkan kita mengurai log mentah menjadi metrik kinerja berharga seperti HTTP error rate dan latency respons.
• Enkripsi Ansible Vault wajib digunakan untuk melindungi token otorisasi tulis InfluxDB agar tidak tersimpan sebagai teks biasa di repositori Git.
• Timeout Batas Eksekusi harus didefinisikan secara ketat pada setiap modul input eksternal untuk mencegah kebuntuan thread kerja Telegraf.
• Integrasi Logrotate dengan parser tail mencegah penurunan kinerja sistem akibat pemrosesan file log tunggal yang terlalu besar.

← Sebelumnya: Dashboard   Berikutnya: Tracing →