Bagaimana Anda mendekati logging dan monitoring di production Node?

Question

Accepted Answer

**Logging** mencatat apa yang dilakukan aplikasi Anda; **monitoring** melacak kesehatan dan kinerjanya. Bersama-sama memberikan Anda **observability** — kemampuan memahami dan men-debug sistem production yang 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 agregasi log, tidak seperti string `console.log` bentuk bebas. Sertakan konteks (user id, request id) pada setiap log.

## Log levels dan apa yang harus dicatat

```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 permintaan di seluruh layanan

```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 satu permintaan, bahkan di seluruh layanan multipel — sangat penting untuk men-debug sistem terdistribusi.

## Sentralisasikan 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
```

Metrik kunci yang perlu diawasi adalah **"golden signals"**: latency, traffic, errors, dan saturation. Alerting pada ini menangkap masalah sebelum pengguna melaporkannya.

## Mengapa ini penting

Di production Anda tidak dapat melampirkan debugger — **observability melalui logging dan monitoring adalah cara Anda memahami, men-debug, dan mengoperasikan** sistem yang sedang berjalan.

Structured JSON logs dengan correlation IDs membuat insiden dapat didiagnosis (terutama di seluruh microservices); agregasi terpusat membuat logs dapat digunakan dalam skala; dan monitoring dengan metrics, health checks, distributed tracing, dan alerting memungkinkan Anda mendeteksi dan merespons masalah secara proaktif daripada setelah pengguna mengeluh.

Membangun ini (bukan memasangnya setelah outage) adalah praktik yang menentukan dalam menjalankan layanan Node production yang dapat diandalkan.