Bagaimana anda mendekati logging dan monitoring dalam production Node?

Question

Accepted Answer

**Logging** mencatat apa yang dilakukan aplikasi anda; **monitoring** melacak kesehatan dan kinerja sistem. Bersama-sama, mereka memberikan anda **observability** — kemampuan untuk memahami dan men-debug sistem production yang sedang berjalan. `console.log` tidak cukup untuk ini; anda memerlukan structured logs, metrics, dan alerting.

## Structured logging (bukan console.log)

```js
import pino from "pino";
const logger = pino();

// ✅ structured JSON logs — machine-parseable, searchable, with context
logger.info({ userId: 123, action: "login", ip: req.ip }, "user logged in");
logger.error({ err, requestId }, "failed to process order");
```

Gunakan structured logger (pino/winston) yang mengeluarkan **JSON** dengan field yang konsisten. JSON logs dapat dicari dan disaring dalam alat aggregasi log, tidak seperti string `console.log` bentuk bebas. Sertakan context (user id, request id) di setiap log.

## Log levels dan apa yang harus di-log

```text
Levels: error > warn > info > debug (configure threshold per environment)
Log:    requests, errors with stack traces, key business events, slow operations
DON'T log: passwords, tokens, PII, full payloads with secrets (security/privacy)
```

## Correlation IDs melacak request di seluruh services

```js
// attach a unique id per request, include it in EVERY log for that request
app.use((req, res, next) => {
  req.id = crypto.randomUUID();
  res.setHeader("X-Request-Id", req.id);
  next();
});
// now you can filter all logs for one request — vital in microservices
```

**Correlation/request ID** memungkinkan anda merekonstruksi cerita lengkap dari satu request, bahkan di seluruh multiple services — sangat penting untuk men-debug distributed systems.

## Sentralisasi logs

```text
Ship logs to a central platform (ELK/Elasticsearch, Datadog, Grafana Loki, CloudWatch)
→ search/aggregate across all instances; don't grep files on individual servers.
```

## Monitoring: metrics, alerts, tracing

```text
Metrics:  request rate, error rate, latency (p50/p95/p99), CPU/memory, event-loop lag
          (often via Prometheus + Grafana, or an APM like Datadog/New Relic)
Health:   /health & /ready endpoints for load balancers and orchestrators
Alerting: notify (PagerDuty/Slack) when error rate spikes or latency degrades
Tracing:  distributed tracing (OpenTelemetry) to follow requests across services
Errors:   error tracking (Sentry) for aggregated exceptions with stack traces & context
```

Metrics kunci yang harus dimonitor adalah **"golden signals"**: latency, traffic, errors, dan saturation. Alerting pada ini menangkap masalah sebelum pengguna melaporkannya.

## Mengapa hal ini penting

Dalam production anda tidak dapat menghubungkan debugger — **observability melalui logging dan monitoring adalah bagaimana anda memahami, men-debug, dan mengoperasikan** sistem yang sedang berjalan.

Structured JSON logs dengan correlation IDs membuat incidents dapat didiagnosis (khususnya di seluruh microservices); centralized aggregation membuat logs dapat digunakan dalam skala besar; dan monitoring dengan metrics, health checks, distributed tracing, dan alerting memungkinkan anda mendeteksi dan merespons masalah secara proaktif daripada setelah pengguna mengeluh.

Membangun ini dari awal (bukan memasang setelah outage) adalah praktik yang menentukan menjalankan layanan Node production yang dapat diandalkan.