Ana içeriğe atla

Üretim İzleme ve Uyarı: Tam Kurulum Kılavuzu

Prometheus, Grafana ve Sentry ile üretim izleme ve uyarıları ayarlayın. Ölçümleri, günlükleri, izlemeleri, uyarı politikalarını ve olay müdahale iş akışlarını kapsar.

E
ECOSIRE Research and Development Team
|16 Mart 20267 dk okuma1.4k Kelime|

Ortalama üretim olayının maliyeti, kesinti süresi başına 5.600 ABD dolarıdır. Olgun izleme sistemine sahip şirketler sorunları 5 dakikadan kısa bir sürede tespit ederken, izleme özelliği olmayan şirketlerin tespit edilmesi ortalama 197 dakika sürer; bu, küçük bir kesinti ile müşteri kaybına yol açan bir felaket…

Performance & Scalability serimizin bir parçası

Tam kılavuzu okuyun

Ortalama üretim olayının maliyeti, kesinti süresi başına 5.600 ABD dolarıdır. Olgun izleme sistemine sahip şirketler sorunları 5 dakikadan kısa bir sürede tespit ederken, izleme özelliği olmayan şirketlerin tespit edilmesi ortalama 197 dakika sürer; bu, küçük bir kesinti ile müşteri kaybına yol açan bir felaket arasındaki farktır.

Bu kılavuz, uçtan uca üretim izleme kurulumunu kapsar: neyin ölçüleceği, nasıl toplanacağı, nerede görselleştirileceği ve ne zaman uyarı verileceği.

Önemli Çıkarımlar

  • Gözlemlenebilirliğin üç temel direği (metrikler, günlükler, izler) farklı amaçlara hizmet eder ve üçü de gereklidir
  • Gürültüyü %80 oranında azaltmaya (CPU kullanımı) neden olmayan belirtilere ilişkin uyarı (hata oranı, gecikme)
  • Her uyarıya eklenen Runbook'lar, çağrıda kim olursa olsun olaylara tutarlı yanıt verilmesini sağlar
  • 5 temel uyarıyla başlayın ve yalnızca temel çizgiyi anladığınızda genişletin

Gözlemlenebilirliğin Üç Temeli

Metrikler

Zaman içinde örneklenen sayısal ölçümler. Metrikler "şu anda ne oluyor?" sorusunu yanıtlıyor.

Uygulama metrikleri:

  • Talep oranı (saniyedeki istekler)
  • Hata oranı (saniyede 5xx yanıt)
  • Gecikme dağılımı (P50, P95, P99)
  • Aktif oturumlar / eşzamanlı kullanıcılar

Altyapı metrikleri:

  • Hizmet başına CPU kullanımı
  • Bellek kullanımı ve çöp toplama
  • Disk G/Ç ve kullanılabilir alan
  • Ağ verimi

İş metrikleri:

  • Dakika başına siparişler
  • Sepeti terk etme oranı
  • Saat başına gelir
  • Uç noktaya göre API çağrıları

Günlükler

Ayrı olayların zaman damgalı, yapılandırılmış kayıtları. Günlükler "neden oldu?" sorusunu yanıtlıyor.

{
  "timestamp": "2026-03-16T14:32:01.234Z",
  "level": "error",
  "service": "api",
  "requestId": "req_abc123",
  "userId": "usr_456",
  "message": "Payment processing failed",
  "error": "Stripe API timeout after 30000ms",
  "endpoint": "POST /billing/checkout",
  "duration": 30142
}

En iyi uygulamaları günlüğe kaydedin:

  • Düz metin yerine yapılandırılmış JSON günlük kaydını kullanın
  • Hizmetler genelinde korelasyon kimliklerini (requestId) ekleyin
  • Uygun seviyelerde oturum açın (arızalar için HATA, bozulma için UYARI, önemli olaylar için BİLGİ)
  • Asla hassas verileri (şifreler, jetonlar, tam kredi kartı numaraları) kaydetmeyin

İzler

Dağıtılmış sistemler aracılığıyla uçtan uca istek yolları. İzler "darboğaz nerede?" sorusunu yanıtlıyor.

Bir e-Ticaret ödemesine yönelik tek bir kullanıcı isteği şunlara dokunabilir:

  1. Nginx'ten (2 ms) Next.js ön ucuna (50 ms) NestJS API'ye (120 ms) PostgreSQL'e (45 ms) Stripe API'ye (800 ms) ve e-posta hizmetine (200 ms)

İzleme olmadan "ödeme işlemi 1,2 saniye sürer" ifadesini görürsünüz. İzleme sırasında "Stripe API, ödeme gecikmesinin %67'sinden sorumludur." ifadesini görürsünüz.


Yığın Kurulumunu İzleme

Prometheus + Grafana (Kendi Kendine Barındırılan)

# docker-compose.monitoring.yml
services:
  prometheus:
    image: prom/prometheus:v2.50.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    ports:
      - "9090:9090"
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'
      - '--web.enable-lifecycle'

  grafana:
    image: grafana/grafana:10.3.0
    volumes:
      - grafana-data:/var/lib/grafana
    ports:
      - "3030:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASSWORD}
      - GF_USERS_ALLOW_SIGN_UP=false

  loki:
    image: grafana/loki:2.9.0
    volumes:
      - loki-data:/loki
    ports:
      - "3100:3100"

  alertmanager:
    image: prom/alertmanager:v0.27.0
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports:
      - "9093:9093"

volumes:
  prometheus-data:
  grafana-data:
  loki-data:

Prometheus Yapılandırması

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "alerts/*.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

scrape_configs:
  - job_name: "api"
    metrics_path: /metrics
    static_configs:
      - targets: ["api:3001"]

  - job_name: "node-exporter"
    static_configs:
      - targets: ["node-exporter:9100"]

  - job_name: "postgres"
    static_configs:
      - targets: ["postgres-exporter:9187"]

  - job_name: "redis"
    static_configs:
      - targets: ["redis-exporter:9121"]

NestJS Uygulama Metrikleri

Prometheus Metriklerini Açığa Çıkarma

// metrics.module.ts
import { Module } from '@nestjs/common';
import { PrometheusModule } from '@willsoto/nestjs-prometheus';
import {
  makeCounterProvider,
  makeHistogramProvider,
  makeGaugeProvider,
} from '@willsoto/nestjs-prometheus';

@Module({
  imports: [
    PrometheusModule.register({
      path: '/metrics',
      defaultMetrics: { enabled: true },
    }),
  ],
  providers: [
    makeCounterProvider({
      name: 'http_requests_total',
      help: 'Total HTTP requests',
      labelNames: ['method', 'path', 'status'],
    }),
    makeHistogramProvider({
      name: 'http_request_duration_seconds',
      help: 'HTTP request duration in seconds',
      labelNames: ['method', 'path'],
      buckets: [0.01, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10],
    }),
    makeGaugeProvider({
      name: 'active_connections',
      help: 'Number of active connections',
    }),
  ],
  exports: [PrometheusModule],
})
export class MetricsModule {}

Uyarı Yapılandırması

Beş Temel Uyarı

Her üretim sisteminin ilk günden itibaren bu uyarılara ihtiyacı vardır:

# alerts/essential.yml
groups:
  - name: essential
    rules:
      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Service {{ $labels.job }} is down"
          runbook: "https://wiki.example.com/runbooks/service-down"

      - alert: HighErrorRate
        expr: |
          rate(http_requests_total{status=~"5.."}[5m])
          / rate(http_requests_total[5m]) > 0.01
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Error rate above 1% for 5 minutes"
          runbook: "https://wiki.example.com/runbooks/high-error-rate"

      - alert: HighLatency
        expr: |
          histogram_quantile(0.95,
            rate(http_request_duration_seconds_bucket[5m])
          ) > 2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "P95 latency above 2 seconds"

      - alert: DiskSpaceLow
        expr: |
          node_filesystem_avail_bytes{mountpoint="/"}
          / node_filesystem_size_bytes{mountpoint="/"} < 0.2
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Disk space below 20% on {{ $labels.instance }}"

      - alert: SSLCertExpiringSoon
        expr: |
          probe_ssl_earliest_cert_expiry - time() < 14 * 24 * 3600
        labels:
          severity: warning
        annotations:
          summary: "SSL certificate expires within 14 days"

Uyarı Yönlendirme

# alertmanager.yml
global:
  slack_api_url: "${SLACK_WEBHOOK_URL}"

route:
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'
      repeat_interval: 15m
    - match:
        severity: warning
      receiver: 'slack'

receivers:
  - name: 'default'
    slack_configs:
      - channel: '#alerts'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ .CommonAnnotations.summary }}'

  - name: 'pagerduty'
    pagerduty_configs:
      - routing_key: "${PAGERDUTY_KEY}"
        severity: '{{ .GroupLabels.severity }}'

  - name: 'slack'
    slack_configs:
      - channel: '#alerts-warnings'
        title: '{{ .GroupLabels.alertname }}'

Uyarı Kalitesi Kuralları

AlıştırmaNeden
Sebeplere değil semptomlara ilişkin uyarı"Hata oranı yüksek" eyleme geçirilebilir; "CPU %80'de" olmayabilir
Her uyarının bir runbook'u vardırNöbetçi mühendislerin sabah 3'te düşünmesine gerek yok
Uyarılar eyleme dönüştürülebilir olmalıdırEğer kimse harekete geçemezse bu bir uyarı değil gürültüdür
Eşikleri 2 hafta sonra ayarlayınBaşlangıç ​​eşikleri tahminlerden ibarettir; taban çizgilerine göre ayarlama
Uyarı yorgunluğunu aylık olarak inceleyinUyarılar herhangi bir işlem yapılmadan her gün tetikleniyorsa eşikleri yükseltin veya kaldırın

Grafana Kontrol Panelleri

Kontrol Paneli Hiyerarşisi

  1. Genel bakış kontrol paneli: Tüm hizmetler genelinde üst düzey sağlık durumu. Bu, bir olay sırasında herkesin baktığı ilk ekrandır.
  2. Hizmet kontrol panelleri: Her hizmete (API, web, çalışanlar) ilişkin ayrıntılı ölçümler.
  3. Altyapı kontrol panelleri: Düğüm düzeyindeki ölçümler (CPU, bellek, disk, ağ).
  4. İşletme kontrol panelleri: Gelir, siparişler, kullanıcı etkinliği.

Hizmet Kontrol Panelleri için KIRMIZI Yöntem

Her hizmet için şunu görüntüleyin:

  • Rate: Saniye başına istek sayısı
  • Ehatalar: Yüzde olarak hata oranı
  • **Süre: Gecikme dağılımı (P50, P95, P99)

Bu, bilişsel aşırı yük olmadan hizmet durumuna ilişkin anında görünürlük sağlar.


Sentry ile Hata Takibi

// sentry.config.ts
import * as Sentry from '@sentry/nestjs';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1,
  profilesSampleRate: 0.1,
  integrations: [
    Sentry.postgresIntegration(),
  ],
  beforeSend(event) {
    // Strip sensitive data
    if (event.request?.headers) {
      delete event.request.headers['authorization'];
      delete event.request.headers['cookie'];
    }
    return event;
  },
});

Sentry şunları sağlar:

  • Otomatik hata gruplama ve veri tekilleştirme
  • Kaynak haritalarla izleri yığınlayın
  • Sürüm izleme (bu dağıtım hatayı ortaya çıkardı)
  • Performans takibi (işlem izleri)

Sıkça Sorulan Sorular

Bir izleme yığınının maliyeti ne kadardır?

Kendi kendine barındırılan (Prometheus + Grafana + Loki): Barındırma kaynakları için ayda yaklaşık 50-100$. Yönetilen alternatifler: Datadog, altyapı için ana bilgisayar başına 15 ABD dolarından, günlükler için GB başına 0,10 ABD dolarından başlar. Ekip planı için Nöbetçi bulutu ayda 26 ABD dolarıdır. Küçük bir işletme için makul bir başlangıç ​​bütçesi ayda toplam 100-200 ABD dolarıdır.

İzleme ile gözlemlenebilirlik arasındaki fark nedir?

İzleme, bir şeylerin ters gittiğini size bildirir. Gözlemlenebilirlik size bunun nedenini söyler. İzleme, önceden tanımlanmış kontrol panelleri ve bilinen arıza modlarına yönelik uyarılarla ilgilidir. Gözlemlenebilirlik, ölçümler, günlükler ve izlemeler kullanarak sisteminizin davranışı hakkında rastgele sorular sorma yeteneği ile ilgilidir. Her ikisine de ihtiyacınız var, ancak izleme temeldir.

Uyarı yorgunluğunu nasıl önleyebiliriz?

Üç kural: (1) her uyarı insan eylemini gerektirmelidir, (2) eşikleri teorik ideallere değil gerçek temellere göre ayarlayın, (3) uyarıları aylık olarak gözden geçirin ve ayarlayın. Bir uyarı, herhangi bir eylem gerektirmeden haftada bir kereden fazla tetiklenirse, ya altta yatan sorunu düzeltin ya da eşiği yükseltin. Uyarı yorgunluğundan muzdarip olan takımlar, kritik olanlar da dahil olmak üzere tüm uyarıları görmezden gelir.

ERP sistemimizi farklı şekilde mi izlememiz gerekiyor?

ERP sistemlerinin benzersiz izleme gereksinimleri vardır. Standart web ölçümlerinin ötesinde, şunları izleyin: veritabanı bağlantı havuzu kullanımını, arka plan iş kuyruğu derinliğini, entegrasyon senkronizasyon durumunu (Shopify, ödeme ağ geçitleri), planlanmış rapor yürütme süresini ve modüle göre kullanıcı oturumu sayılarını. ECOSIRE, destek paketlerimizin bir parçası olarak yönetilen Odoo izlemeyi sağlar.


Sırada Ne Var?

İzleme, üretim altyapınızın gözü ve kulağıdır. Dağıtım güvenliği için bunu CI/CD otomasyonu ve dayanıklılık için olağanüstü durum kurtarma planlaması ile eşleştirin. Kapsamlı bir DevOps yol haritası için Küçük işletmelere yönelik DevOps kılavuzumuza bakın.

Kurulumu ve yönetilen altyapı hizmetlerini izlemek için ECOSIRE ile iletişime geçin.


ECOSIRE tarafından yayınlandı - işletmelerin üretimde neyin önemli olduğunu görmesine yardımcı oluyor.

E

Yazan

ECOSIRE Team

Technical Writing

The ECOSIRE technical writing team covers Odoo ERP, Shopify eCommerce, AI agents, Power BI analytics, GoHighLevel automation, and enterprise software best practices. Our guides help businesses make informed technology decisions.

ECOSIRE

ECOSIRE ile İşinizi Büyütün

ERP, e-Ticaret, yapay zeka, analitik ve otomasyon genelinde kurumsal çözümler.

Performance & Scalability serisinden daha fazlası

Shopify Hız Optimizasyonu: Temel Web Verilerini Gerçekten Yönlendiren Teknik Bir Kontrol Listesi (2026)

2026 için sahada test edilmiş Shopify hız kontrol listesi - gerçek mağazalarda LCP, INP ve CLS'yi gerçekte neyin iyileştirdiği, neyin zaman kaybettirdiği ve uygulamaların ve temaların nasıl denetleneceği.

Teknik SEO Denetim Kontrol Listesi 2026: Her Müşteri Sitesinde Çalıştırdığımız 47 Kontrol

2026'da her müşteri sitesinde yürüttüğümüz 47 maddelik teknik SEO denetim kontrol listesi: taranabilirlik, dizine ekleme, kanonik bilgiler, hreflang, Önemli Web Verileri ve günlükler.

Odoo 19 HR: Beceri Matrisi, Kariyer Planları, Performans Döngüleri

Odoo 19 İK yükseltmesi: yerel beceriler matrisi, kariyer yolu planlaması, performans inceleme döngüleri, 9 kutulu tablo, yedekleme planlaması, HRIS entegrasyonu.

Odoo 19 Performans Karşılaştırmaları: PostgreSQL 17 Ayar Numaraları

Gerçek dünya Odoo 19 performans kıyaslamaları: web istemci hızı, ORM verimi, PG17 ayarlama ayarları, bağlantı havuzu oluşturma, çalışan sayıları, ölçeklendirme eşikleri.

OpenClaw Maliyet Optimizasyonu ve Büyük Ölçekte Token Verimliliği

OpenClaw belirteci maliyet optimizasyonu: hızlı önbelleğe alma, model yönlendirme, yanıt önbelleğe alma, toplu API'ler ve üretim aracıları için kiracı başına maliyet korkulukları.

10 Milyon Satırdan Fazla Tablolar için Power BI Artımlı Yenileme

10 milyondan fazla satır tablosu için Power BI Artımlı Yenileme oyun kitabı: bölüm tasarımı, RangeStart/RangeEnd, yenileme ilkeleri, sorgu katlama ve DirectQuery hibritleri.