როგორ აწყობთ logging-ს და monitoring-ს containers-ისთვის?

Question

IT Interview Practice · Accepted Answer

Containerized applications-ებს სჭირდებათ **centralized logging** და **monitoring**, რადგან containers-ები ephemeral-ი და მრავალრიცხოვანი — logs-ები და metrics-ები უნდა შეგროვდეს გარედან, რომ ისინი გადაჭიმონ container-ის წაშლის შემდეგაც და მოგვცენ visibility მთელ სისტემაზე. ეს არის essential observability production containers-ისთვის.

## Logging: log stdout/stderr-ში, aggregate centrally

```text
BEST PRACTICE: containers should log to STDOUT/STDERR (not to files inside the container):
  → Docker captures these (`docker logs`); a logging DRIVER forwards them elsewhere
  → WHY: containers are EPHEMERAL — logs in a removed container are LOST. Centralize them.
```

```text
Logging drivers / pipelines forward logs to a central system:
  → json-file (default), syslog, fluentd, awslogs, gelf, etc. (--log-driver)
  → Aggregation stacks: ELK/Elastic (Elasticsearch+Logstash+Kibana), Loki+Grafana,
    cloud logging (CloudWatch, Stackdriver), Datadog, etc.
→ Centralized logs: searchable, persistent, span ALL containers/hosts → real visibility
```

## Monitoring: metrics, health, alerts

```text
✓ METRICS — collect CPU, memory, network, app metrics per container
  → Prometheus (scrapes metrics) + Grafana (dashboards) — the common stack
  → cAdvisor / node-exporter for container/host metrics
✓ HEALTH — health checks + orchestrator status (which containers are healthy)
✓ ALERTING — alert on failures, resource limits, errors (Alertmanager, etc.)
✓ DISTRIBUTED TRACING — trace requests across microservices (Jaeger, OpenTelemetry)
```

## Why container observability is different

```text
Containers are EPHEMERAL (created/destroyed dynamically) and NUMEROUS (many across hosts):
  → can't rely on logging into a box or local log files (containers come and go)
  → need EXTERNAL, centralized, dynamic collection that handles churn
  → orchestrators add labels/metadata to correlate logs/metrics to services
→ Observability must be designed for dynamic, distributed, ephemeral workloads.
```

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

Logging-ისა და monitoring-ის გაცნობა containers-ისთვის მნიშვნელოვანი senior-level ცოდნა, რადგან **observability აუცილებელია production systems-ის ოპერირებისთვის**, და containers-ების ephemeral, numerous, distributed ბუნება განსხვავებული ხდის მას ტრადიციული მიდგომებისგან.

მთავარი **logging** პრაქტიკა — containers-ებმა უნდა **log stdout/stderr-ში** (არა files-ში container-ის შიგნით), რომ platform-მა დააკავშიროს და გამოუგზავნოს ისინი **centralized aggregation-ში** — გადამწყვეტია, რადგან **containers-ები ephemeral-ი**: logs-ები, რომლებიც container-ის შიგნით არის შენახული, **დაკარგულია როდესაც ის წაშლილი იქნება**, ამიტომ centralize-ება (logging drivers-ის მეშვეობით ELK-ში, Loki/Grafana-ში, cloud logging-ში, და ა.შ.) აუცილებელია logs-ების შესანახად და visibility-ს მისაღებად ყველა containers-ისა და hosts-ის შორის. **Monitoring** თანაბრად აუცილებელია: **metrics**-ის შეგროვება (CPU, memory, application metrics, ჩვეულებრივ Prometheus + Grafana-ის მეშვეობით), **health**-ის ট্র্যাკირება (health checks-ი და orchestrator status), **alerting** პრობლემებზე, და **distributed tracing** (requests-ის ყოლოდლობა microservices-ებში Jaeger/OpenTelemetry-ის მეშვეობით) უზრუნველყოფენ visibility-ს, რომელიც საჭიროა system behavior-ის გასაგებად, issues-ის დიაგნოსტიკისთვის და პრობლემებზე პასუხის გასაცემად.

გაცნობა **რატომ არის container observability განსხვავებული** — containers-ები ephemeral-ი (ხელოვნურად ქმნილი/წაშლილი, ამიტომ არ დაიყრდოთ local files-ზე ან boxes-ში login-ზე) და მრავალრიცხოვანი hosts-ის შორის (რაც მოითხოვს external, dynamic collection-ს, რომელიც справляется churn-თან, orchestrator metadata-თან correlating logs/metrics-ები services-თან) — არის conceptual insight, რომელიც ფორმირებს observability-ს design-ს containerized systems-ისთვის.

მას შემდეგ, რაც production systems-ის ოპერირება მოითხოვს observability-ს (არ შეგიძლია manage-ი რას ვერ ხედავ), და ვინაიდან containers-ების ephemeral, distributed ბუნება მოითხოვს centralized, externally-collected logging-ს და monitoring-ს, რომელიც designed დინამიკური workloads-ისთვის, container logging-ის და monitoring-ის გაცნობა მნიშვნელოვანი senior-level ცოდნა containerized applications-ის ოპერირებისთვის — essential observability, რომელიც ხდის containerized systems-ებს operable-ს, debuggable-ს და maintainable-ს production-ში, და ასახავს operational maturity-ს, რომელიც მოსალოდნელია senior roles-ისთვის, რომლებიც manage-ან container deployments-ებს.

Logging: log stdout/stderr-ში, aggregate centrally

Monitoring: metrics, health, alerts

Why container observability is different

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

დაკავშირებული კითხვები