როგორ მიდიხართ logging-ის და monitoring-ის უზრუნველყოფაში production Node-ში?

Question

Accepted Answer

**Logging** ფიქსირებს თქვენი აპლიკაციის შესაქმელებას; **monitoring** აკვირდება მის ჯანმრთელობას და ზეპირფორმას. ერთად ისინი იძლევენ **observability**-ს — ის წარმოების სისტემის გაგებისა და გამართვის უნარი. `console.log` არასაკმარისია ამისთვის; საჭიროა structured logs, metrics და alerting.

## Structured logging (არა 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");
```

იყენებთ structured logger-ს (pino/winston), რომელიც გამოაქვს **JSON** თანმიმდევრული ველებით. JSON logs ძებნა და ფილტრირება შესაძლებელია log aggregation ხელმისაწვდომელი ინსტრუმენტებში, არე როგორც თავისუფალი ფორმის `console.log` სტრიქონები. დაამატეთ context (user id, request id) ყოველ log-ზე.

## Log levels და რა უნდა ჩანიშნოთ

```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 ტრეკავს მოთხოვნას სერვისებში

```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** საშუალებას აძლევთ აღადგინოთ ერთი მოთხოვნის სრული ისტორია, მაშინაც კი თუ ის რამდენიმე სერვისში გადის — აუცილებელია განაწილებული სისტემების გამართვისთვის.

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

მნიშვნელოვანი მეტრიკა არის **"golden signals"**: latency, traffic, errors და saturation. ამათ კეთილდღეობის მონიტორინგი თავიდან აიცილებს პრობლემებს, სანამ მომხმარებლები მათ აცნობიან.

## რატომ არის ეს მნიშვნელოვანი

წარმოებაში ვერ დააკავშირებთ debugger-ს — **observability logging-ის და monitoring-ის საშუალებით არის თქვენი გზა რომ გაითავისოთ, გამართოთ და მართოთ** ფუნქციონირებელი სისტემა.

Structured JSON logs correlation ID-ებთან კეთის incidents diagnosable-ს (განსაკუთრებით microservices-ებში); centralized aggregation ხდის logs გამოყენებადს დიდ მასშტაბებზე; და monitoring metrics-ით, health checks-ით, distributed tracing-ით და alerting-ით საშუალებას აძლევთ პროაქტიულად აღმოაჩინოთ და პასუხი გამოიტანოთ პრობლემებზე მომხმარებელთა უჩივლის ნაცვლად.

ამის აგება თავიდან (არა დაკერძოთ outage-ის შემდეგ) განსაზღვრავს საიმედო production Node სერვისების ამოქმედების პრაქტიკას.