Tutorial Setup OpenTelemetry & SigNoz: Distributed Tracing di VPS

Tantangan Observability pada Arsitektur Microservices

Transisi dari arsitektur monolith ke microservices memecah kompleksitas basis kode, tetapi meningkatkan kompleksitas operasional infrastruktur. Pada sistem monolith, pelacakan alur eksekusi aplikasi dapat dilakukan dengan memeriksa satu berkas log terpusat menggunakan perintah standar Linux seperti tail atau grep. Namun, ketika satu permintaan pengguna memicu belasan panggilan API antar-layanan melalui protokol HTTP atau gRPC, pelacakan berbasis log konvensional menjadi tidak efektif.

Ketika terjadi lonjakan latency (p99 latency spike) atau kegagalan cascading (cascading failure), tim engineering kesulitan mengisolasi layanan mana yang menjadi penyebab utama bottleneck. Log terisolasi pada masing-masing kontainer tidak memiliki konteks keterhubungan antar-permintaan. Tanpa mekanisme korelasi yang jelas, pencarian akar masalah membutuhkan waktu berjam-jam (Mean Time to Resolution / MTTR tinggi).

Solusi standar industri untuk masalah ini adalah Distributed Tracing. Distributed tracing merekam seluruh perjalanan permintaan pengguna dari entry point (API Gateway), melewati batas-batas jaringan jaringan antar-layanan, hingga eksekusi query ke database atau layanan pihak ketiga. Setiap permintaan diberi identitas unik berupa Trace ID, dan setiap operasi individual di dalam layanan direkam sebagai Span.

Mengenal Standar OpenTelemetry dan Engine SigNoz

OpenTelemetry (OTel) adalah proyek open-source di bawah naungan Cloud Native Computing Foundation (CNCF) yang menyediakan kerangka kerja vendor-neutral untuk mengumpulkan, memproses, dan mengekspor data telemetri (traces, metrics, dan logs). OTel menggantikan berbagai pustaka instrumentasi proprietary yang sebelumnya mengunci (vendor lock-in) pengembang pada ekosistem APM tertentu.

Untuk menyimpan dan menganalisis data telemetri yang dihasilkan OTel SDK, diperlukan backend APM. SigNoz hadir sebagai platform Application Performance Monitoring (APM) open-source yang dirancang sebagai alternatif hemat biaya bagi solusi SaaS seperti Datadog, New Relic, atau Dynatrace.

SigNoz menggunakan ClickHouse sebagai database analitis berkinerja tinggi. Berbeda dengan platform berbasis Elasticsearch yang mengonsumsi memori secara masif, ClickHouse mengadopsi penyimpanan berorientasi kolom (columnar storage) dengan rasio kompresi data yang sangat tinggi dan kemampuan kueri SQL super cepat. Hal ini memungkinkan SigNoz dijalankan secara efisien di VPS Linux dengan sumber daya terbatas tanpa mengorbankan kecepatan analisis data trace.

Persiapan dan Deployment SigNoz di VPS Linux

1. Persyaratan Sistem dan Port

Sebelum memulai instalasi, pastikan VPS Linux Anda memenuhi spesifikasi minimal berikut:

• Sistem Operasi: Ubuntu 22.04 LTS (disarankan) atau Debian 11/12.
• CPU: Minimal 2 vCPU.
• RAM: Minimal 4 GB (8 GB disarankan untuk beban produksi sedang).
• Penyimpanan: 30 GB SSD / NVMe.

Pastikan port-port berikut dikonfigurasi pada firewall (UFW atau Security Group VPS):

• 3301: Akses Dashboard Web Frontend SigNoz.
• 4317: Receiver OpenTelemetry OTLP/gRPC.
• 4318: Receiver OpenTelemetry OTLP/HTTP.

2. Instalasi SigNoz via Script Automation

Jalankan perintah berikut pada terminal VPS untuk mengkloning repositori resmi SigNoz dan mengeksekusi script instalasi berbasis Docker Compose:

git clone -b main https://github.com/SigNoz/signoz.git
cd signoz/deploy/
sudo ./install.sh

Script instalasi secara otomatis mengunduh dan menjalankan komponen-kommonen berikut:

• signoz-clickhouse: Datastore utama untuk data trace dan metrik.
• signoz-otel-collector: Agent penerima dan pemroses telemetry dari aplikasi.
• signoz-query-service: Engine kueri untuk mengolah data dari ClickHouse.
• signoz-frontend: UI berbasis React untuk visualisasi trace dan metrik.

Verifikasi status kontainer yang sedang berjalan:

docker ps --format "table {{.Names}}	{{.Status}}	{{.Ports}}"

Buka peramban web dan akses http://<IP-VPS-ANDA>:3301. Buat akun administrator pertama untuk mengamankan akses ke dashboard.

Integrasi SDK OpenTelemetry pada Microservices

Agar layanan dapat mengirimkan data trace ke SigNoz, aplikasi harus di-instrumentasi menggunakan OpenTelemetry SDK. Berikut adalah cara memasang instrumentasi pada dua ekosistem populer: Node.js dan Go.

1. Integrasi pada Aplikasi Node.js

Pasang pustaka dependensi OTel yang dibutuhkan melalui NPM:

npm install --save @opentelemetry/sdk-node \
  @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-trace-otlp-grpc \
  @grpc/grpc-js

Buat berkas inisialisasi tracing bernama tracing.js pada direktori utama proyek:

const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-grpc');
const { Resource } = require('@opentelemetry/resources');
const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');

const sdk = new NodeSDK({
  resource: new Resource({
    [SemanticResourceAttributes.SERVICE_NAME]: 'cart-service-node',
    [SemanticResourceAttributes.SERVICE_VERSION]: '1.0.0',
    [SemanticResourceAttributes.DEPLOYMENT_ENVIRONMENT]: 'production',
  }),
  traceExporter: new OTLPTraceExporter({
    url: 'grpc://<IP-VPS-ANDA>:4317',
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Jalankan aplikasi Node.js dengan menyuntikkan (require) berkas tracing sebelum kode utama dieksekusi:

node --require ./tracing.js index.js

Dengan getNodeAutoInstrumentations(), OTel secara otomatis menyuntikkan penangkap trace ke modul-modul populer seperti Express, Fastify, HTTP, Redis, MySQL, dan Postgres tanpa perlu mengubah kode bisnis aplikasi.

2. Integrasi pada Aplikasi Go

Unduh modul OpenTelemetry untuk bahasa Go:

go get go.opentelemetry.io/otel \
  go.opentelemetry.io/otel/sdk \
  go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc \
  google.golang.org/grpc

Implementasikan fungsi inisialisasi Tracer Provider pada file main.go:

package main

import (
	"context"
	"log"
	"time"

	"go.opentelemetry.io/otel"
	"go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
	"go.opentelemetry.io/otel/sdk/resource"
	sdktrace "go.opentelemetry.io/otel/sdk/trace"
	semconv "go.opentelemetry.io/otel/semconv/v1.4.0"
	"google.golang.org/grpc"
)

func initTracer(ctx context.Context) func(context.Context) error {
	exporter, err := otlptracegrpc.New(ctx,
		otlptracegrpc.WithInsecure(),
		otlptracegrpc.WithEndpoint("<IP-VPS-ANDA>:4317"),
		otlptracegrpc.WithDialOption(grpc.WithBlock()),
	)
	if err != nil {
		log.Fatalf("Gagal membuat exporter OTLP: %v", err)
	}

	res, err := resource.New(ctx,
		resource.WithAttributes(
			semconv.SchemaURL,
			semconv.ServiceNameKey.String("payment-service-go"),
			semconv.ServiceVersionKey.String("1.1.0"),
		),
	)
	if err != nil {
		log.Fatalf("Gagal membuat resource: %v", err)
	}

	tp := sdktrace.NewTracerProvider(
		sdktrace.WithBatcher(exporter),
		sdktrace.WithResource(res),
	)
	otel.SetTracerProvider(tp)
	return tp.Shutdown
}

func main() {
	ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
	defer cancel()

	shutdown := initTracer(ctx)
	defer func() {
		if err := shutdown(context.Background()); err != nil {
			log.Printf("Gagal mematikan tracer provider: %v", err)
		}
	}()

	// Kode aplikasi Go Anda dijalankan di sini
}

Propagasi Konteks Trace Antar-Layanan (Context Propagation)

Agar rantai panggilan antar-microservice terhubung menjadi satu kesatuan Trace, header HTTP/gRPC harus diteruskan dari layanan pengirim ke layanan penerima. OpenTelemetry menggunakan standar spesifikasi W3C Trace Context.

Header HTTP utama yang dikirimkan secara otomatis oleh pustaka HTTP OTel adalah traceparent, yang memiliki format sebagai berikut:

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

• 00: Versi spesifikasi W3C.
• 4bf92f3577b34da6a3ce929d0e0e4736: Trace ID unik (berlaku universal sepanjang rantai request).
• 00f067aa0ba902b7: Parent Span ID.
• 01: Trace flags (penanda apakah request di-sample atau tidak).

Pastikan API Gateway dan Reverse Proxy (seperti Nginx, Traefik, atau Kong) tidak menghapus header traceparent dan tracestate saat meneruskan trafik ke layanan internal.

Optimasi OTel Collector: Memory Limiter dan Sampling Rate

Menjalankan observability pada VPS dengan spesifikasi terbatas berisiko menyebabkan crash akibat kehabisan memori (Out of Memory / OOM) atau penurunan performa I/O disk jika beban trafik melonjak tajam. Oleh karena itu, optimasi pada otel-collector-config.yaml mutlak diperlukan.

Edit berkas konfigurasi OTel Collector yang berlokasi di direktori instalasi SigNoz (signoz/deploy/docker/clickhouse-setup/otel-collector-config.yaml):

processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 75
    spike_limit_percentage: 20
  probabilistic_sampler:
    sampling_percentage: 15.0
  batch:
    send_batch_size: 10000
    timeout: 2s
    send_batch_max_size: 11000

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, probabilistic_sampler, batch]
      exporters: [clickhousetraces]

Penjelasan Komponen Optimasi:

• memory_limiter: Memantau penggunaan RAM oleh Collector secara real-time. Jika konsumsi memori mencapai 75% dari batas sistem, collector akan menolak data baru secara bertahap dan memicu garbage collection untuk mencegah OOM-kill oleh kernel Linux.
• probabilistic_sampler: Mengonfigurasi tingkat pengambil sampel (sampling rate). Dalam konfigurasi di atas, hanya 15% dari total trace normal yang disimpan ke ClickHouse. Strategi ini secara drastis mengurangi beban penulisan SSD dan konsumsi memori tanpa kehilangan gambaran umum agregat p95/p99 latency.
• batch: Menggabungkan beberapa span ke dalam satu paket data sebelum dikirimkan ke ClickHouse. Pola penulisan massal (bulk write) ini sangat disukai oleh ClickHouse dibandingkan penulisan data kecil secara berulang-ulang.

Terapkan konfigurasi baru dengan merestart kontainer collector:

docker restart signoz-otel-collector

Checklist Observability Production-Ready

Sebelum mempublikasikan arsitektur ini ke lingkungan produksi, jalankan pemeriksaan daftar komprehensif berikut:

• [ ] Spesifikasi VPS telah disesuaikan (minimal 2 vCPU dan 4GB RAM).
• [ ] Port 3301 dilindungi oleh Reverse Proxy (Nginx) menggunakan enkripsi HTTPS/TLS (Let's Encrypt).
• [ ] Kredensial akun admin SigNoz diperbarui dengan kata sandi acak yang kuat.
• [ ] Port OTLP 4317 dan 4318 ditutup dari akses publik luar dan hanya diizinkan dari subnet jaringan internal/VPN VPS.
• [ ] Atribut service.name dan deployment.environment didefinisikan dengan konsisten di setiap layanan.
• [ ] Header traceparent dipastikan lolos melewati API Gateway tanpa di-strip.
• [ ] Processor memory_limiter dan probabilistic_sampler diaktifkan pada pipeline Collector.
• [ ] Kebijakan retensi data (Data Retention Policy) di Dashboard SigNoz dikonfigurasi (misal: simpan data trace maksimal 7 hari untuk menghemat disk).

Kesimpulan

Mengimplementasikan OpenTelemetry dan SigNoz di VPS Linux memberikan infrastruktur observability kelas enterprise dengan biaya terjangkau. Pendekatan open-source berbasis ClickHouse memungkinkan pengembang memiliki kontrol penuh atas data telemetri tanpa risiko penggelembungan biaya SaaS APM.

Dengan integrasi SDK yang tepat pada microservices Node.js dan Go, serta konfigurasi OTel Collector yang dioptimalkan untuk memori VPS, analisis latency hingga level query database dan panggilan fungsi eksternal dapat dilakukan secara presisi dan real-time.