{"id":33205,"date":"2025-10-31T03:01:40","date_gmt":"2025-10-31T00:01:40","guid":{"rendered":"https:\/\/fatihsoysal.com\/blog\/dagitik-sistemlerin-karmasikligini-anlamak-sorunlari-teshis-etmek-ve-sistem-performansi\/"},"modified":"2025-10-31T03:01:40","modified_gmt":"2025-10-31T00:01:40","slug":"dagitik-sistemlerin-karmasikligini-anlamak-sorunlari-teshis-etmek-ve-sistem-performansi","status":"publish","type":"post","link":"https:\/\/fatihsoysal.com\/blog\/dagitik-sistemlerin-karmasikligini-anlamak-sorunlari-teshis-etmek-ve-sistem-performansi\/","title":{"rendered":"Da\u011f\u0131t\u0131k sistemlerin karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 anlamak, sorunlar\u0131 te\u015fhis etmek ve sistem performans\u0131…"},"content":{"rendered":"

Da\u011f\u0131t\u0131k sistemlerin karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 anlamak, sorunlar\u0131 te\u015fhis etmek ve sistem performans\u0131n\u0131 optimize etmek her zamankinden daha zorlu hale geldi. G\u00f6zlemlenebilirlik, bu dinamik ortamlarda sisteminizin i\u00e7 i\u015fleyi\u015fini derinlemesine anlaman\u0131z\u0131 sa\u011flayan kritik bir yetenektir.<\/p>\n

G\u00fcn\u00fcm\u00fcz\u00fcn modern yaz\u0131l\u0131m mimarileri genellikle mikroservislere ve sunucusuz fonksiyonlara dayan\u0131r; bu da tek bir monolitik uygulamadan \u00e7ok say\u0131da ba\u011f\u0131ms\u0131z servisin birbiriyle etkile\u015fimde oldu\u011fu anlam\u0131na gelir. Bu par\u00e7al\u0131 yap\u0131, esneklik ve \u00f6l\u00e7eklenebilirlik sunarken, ayn\u0131 zamanda yeni zorluklar\u0131 da beraberinde getirir. Bir kullan\u0131c\u0131 iste\u011fi, arka planda onlarca farkl\u0131 servisten ge\u00e7ebilir ve bu yolculuk s\u0131ras\u0131nda herhangi bir noktada bir sorun ya\u015fanabilir. \u0130\u015fte tam da bu noktada geleneksel izleme y\u00f6ntemleri yetersiz kal\u0131r ve g\u00f6zlemlenebilirlik<\/strong> (observability) devreye girer.<\/p>\n

Geleneksel izleme (monitoring) genellikle sistemin bilinen, \u00f6nceden tan\u0131mlanm\u0131\u015f durumlar\u0131n\u0131 kontrol etmeye odaklan\u0131r. CPU kullan\u0131m\u0131 y\u00fcksek mi? Bellek t\u00fcketimi belirli bir e\u015fi\u011fi a\u015ft\u0131 m\u0131? Bu sorular, sistemin genel sa\u011fl\u0131\u011f\u0131 hakk\u0131nda \u00f6nemli bilgiler sunar ancak da\u011f\u0131t\u0131k bir sistemde “neden” sorusuna cevap vermekte zorlan\u0131r. \u00d6rne\u011fin, bir API \u00e7a\u011fr\u0131s\u0131 neden yava\u015flad\u0131? Hangi servis zincirinde sorun ya\u015fan\u0131yor? Kullan\u0131c\u0131 X’in i\u015flemi neden ba\u015far\u0131s\u0131z oldu? Bu t\u00fcr bilinmeyen bilinmeyenleri ke\u015ffetmek ve anlamak i\u00e7in daha derinlelemesine bir bak\u0131\u015f a\u00e7\u0131s\u0131na ihtiya\u00e7 duyar\u0131z. Bu derinlemesine bak\u0131\u015f a\u00e7\u0131s\u0131n\u0131 sa\u011flayan \u015fey g\u00f6zlemlenebilirliktir.<\/p>\n

G\u00f6zlemlenebilirlik, sistemin d\u0131\u015far\u0131dan \u00f6l\u00e7\u00fclebilen \u00e7\u0131kt\u0131lar\u0131 arac\u0131l\u0131\u011f\u0131yla i\u00e7 durumunu \u00e7\u0131karabilme yetene\u011fidir. Bu, sadece “bir \u015feyler yanl\u0131\u015f” demek yerine, “neden yanl\u0131\u015f oldu\u011funu” ve “nerede yanl\u0131\u015f gitti\u011fini” anlamam\u0131z\u0131 sa\u011flar. \u00d6zellikle bulut tabanl\u0131 ve dinamik ortamlarda, konteynerler ve orkestrasyon ara\u00e7lar\u0131 (Kubernetes gibi) sayesinde sistemler s\u00fcrekli olarak de\u011fi\u015febilir ve yeni sorunlar ortaya \u00e7\u0131kabilir. Bu durumlar i\u00e7in dinamik ve esnek bir hata ay\u0131klama ve te\u015fhis mekanizmas\u0131 \u015fartt\u0131r. G\u00f6zlemlenebilirlik sayesinde ekipler, bilinmeyen durumlar\u0131 bile anlayabilir ve bu sayede daha h\u0131zl\u0131 problem \u00e7\u00f6z\u00fcm\u00fc, daha az kesinti s\u00fcresi ve daha iyi bir kullan\u0131c\u0131 deneyimi sunabilirler. Sonu\u00e7 olarak, da\u011f\u0131t\u0131k sistemlerin karma\u015f\u0131kl\u0131\u011f\u0131 artt\u0131k\u00e7a, g\u00f6zlemlenebilirlik sadece bir iyi uygulama olmaktan \u00e7\u0131k\u0131p, sistemlerin g\u00fcvenilirli\u011fini ve s\u00fcrd\u00fcr\u00fclebilirli\u011fini sa\u011flamak i\u00e7in olmazsa olmaz bir gereklilik haline gelmi\u015ftir.<\/p>\n

G\u00f6zlemlenebilirlik Nedir ve Geleneksel \u0130zlemeden Fark\u0131 Ne?<\/h2>\n

G\u00f6zlemlenebilirlik, bir sistemin d\u0131\u015far\u0131dan toplanabilen veriler (metrikler, loglar ve izler) arac\u0131l\u0131\u011f\u0131yla i\u00e7 durumunu ne kadar iyi anlayabildi\u011fimizin bir \u00f6l\u00e7\u00fcs\u00fcd\u00fcr. Geleneksel izleme (monitoring) ise genellikle belirli e\u015fiklere ula\u015f\u0131ld\u0131\u011f\u0131nda uyar\u0131 vermeye veya \u00f6nceden tan\u0131mlanm\u0131\u015f g\u00f6stergeleri takip etmeye odaklan\u0131r. \u0130kisi de sistem sa\u011fl\u0131\u011f\u0131 i\u00e7in \u00f6nemli olsa da, temel yakla\u015f\u0131mlar\u0131 ve sunduklar\u0131 derinlik a\u00e7\u0131s\u0131ndan farkl\u0131la\u015f\u0131rlar. G\u00f6zlemlenebilirlik, sistemlerimizin neden belirli bir \u015fekilde davrand\u0131\u011f\u0131n\u0131 anlamam\u0131z\u0131 sa\u011flayan, daha proaktif ve kapsaml\u0131 bir yakla\u015f\u0131md\u0131r.<\/p>\n

G\u00f6zlemlenebilirli\u011fin \u00fc\u00e7 ana s\u00fctunu vard\u0131r:<\/p>\n

    \n
  1. Metrikler (Metrics):<\/strong> Belirli bir zaman aral\u0131\u011f\u0131nda toplanan say\u0131sal de\u011ferlerdir. CPU kullan\u0131m\u0131, bellek t\u00fcketimi, disk G\/\u00c7, a\u011f trafi\u011fi, talep say\u0131s\u0131, hata oranlar\u0131, yan\u0131t s\u00fcreleri gibi veriler metrik olarak kabul edilir. Metrikler, sistemin genel sa\u011fl\u0131\u011f\u0131 hakk\u0131nda h\u0131zl\u0131 ve \u00f6zet bilgiler sunar. Zaman serisi veritabanlar\u0131nda depolan\u0131r ve genellikle Grafana gibi ara\u00e7larla g\u00f6rselle\u015ftirilir.<\/li>\n
  2. Loglar (Logs):<\/strong> Bir sistemdeki olaylar\u0131n zaman damgal\u0131, yap\u0131land\u0131r\u0131lm\u0131\u015f veya yap\u0131land\u0131r\u0131lmam\u0131\u015f kay\u0131tlar\u0131d\u0131r. Bir kullan\u0131c\u0131n\u0131n oturum a\u00e7mas\u0131, bir servisin \u00e7a\u011fr\u0131lmas\u0131, bir veritaban\u0131 sorgusunun y\u00fcr\u00fct\u00fclmesi veya bir hatan\u0131n olu\u015fmas\u0131 gibi her t\u00fcrl\u00fc olay loglara kaydedilebilir. Loglar, bir olay\u0131n ayr\u0131nt\u0131l\u0131 hikayesini anlat\u0131r ve sorun giderme (troubleshooting) s\u0131ras\u0131nda kritik \u00f6nem ta\u015f\u0131r. Merkezi bir log toplama sistemi (ELK Stack, Grafana Loki) kullanmak, da\u011f\u0131t\u0131k sistemlerdeki loglar\u0131 anlamland\u0131rmak i\u00e7in olmazsa olmazd\u0131r.<\/li>\n
  3. \u0130zler (Traces\/Tracing):<\/strong> Da\u011f\u0131t\u0131k bir sistemde tek bir i\u015flemin veya iste\u011fin t\u00fcm yolculu\u011funu g\u00f6steren bir dizi olayd\u0131r. Bir kullan\u0131c\u0131n\u0131n web sitesine yapt\u0131\u011f\u0131 bir istek, arka planda birden fazla mikroservisten ge\u00e7ebilir. \u0130zleme, bu iste\u011fin her bir servisten ne kadar s\u00fcre harcad\u0131\u011f\u0131n\u0131, hangi hatalarla kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131 ve hangi servisi \u00e7a\u011f\u0131rd\u0131\u011f\u0131n\u0131 g\u00f6rselle\u015ftirmemizi sa\u011flar. Bu, \u00f6zellikle performans sorunlar\u0131n\u0131 veya darbo\u011fazlar\u0131 belirlemede paha bi\u00e7ilmezdir. OpenTelemetry veya Jaeger gibi ara\u00e7lar izleme i\u00e7in s\u0131k\u00e7a kullan\u0131l\u0131r.<\/li>\n<\/ol>\n

    Peki, geleneksel izlemeden fark\u0131 ne? \u0130\u015fte temel kar\u015f\u0131la\u015ft\u0131rma:<\/p>\n\n\n\n\n\n\n\n\n\n\n
    \u00d6zellik<\/th>\nGeleneksel \u0130zleme (Monitoring)<\/th>\nG\u00f6zlemlenebilirlik (Observability)<\/th>\n<\/tr>\n<\/thead>\n
    Yakla\u015f\u0131m<\/strong><\/td>\nNeyi bilebilece\u011fimize odaklan\u0131r (\u00f6nceden tan\u0131ml\u0131 metrikler).<\/td>\nNeyi bilmedi\u011fimize odaklan\u0131r (bilinmeyen bilinmeyenleri ke\u015ffetme).<\/td>\n<\/tr>\n
    Hedef<\/strong><\/td>\nSistemin beklendi\u011fi gibi \u00e7al\u0131\u015f\u0131p \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 kontrol etmek.<\/td>\nSistemin neden belirli bir \u015fekilde davrand\u0131\u011f\u0131n\u0131 anlamak.<\/td>\n<\/tr>\n
    Veri Kaynaklar\u0131<\/strong><\/td>\nTemelde metrikler (CPU, bellek, a\u011f).<\/td>\nMetrikler, loglar ve izler (\u00fc\u00e7 s\u00fctun).<\/td>\n<\/tr>\n
    Problem \u00c7\u00f6z\u00fcm\u00fc<\/strong><\/td>\nSemptomlar\u0131 g\u00f6sterir, \u00f6nceden bilinen sorunlar\u0131 tespit eder.<\/td>\nSorunlar\u0131n k\u00f6k nedenlerini derinlemesine analiz eder, bilinmeyen sorunlar\u0131 a\u00e7\u0131\u011fa \u00e7\u0131kar\u0131r.<\/td>\n<\/tr>\n
    Esneklik<\/strong><\/td>\nDaha az esnek, yeni sorular i\u00e7in yeni ara\u00e7lar\/konfig\u00fcrasyonlar gerekir.<\/td>\nDaha esnek, yeni sorular\u0131 mevcut verilerle yan\u0131tlamaya olanak tan\u0131r.<\/td>\n<\/tr>\n
    Kullan\u0131m Alan\u0131<\/strong><\/td>\nSistem sa\u011fl\u0131\u011f\u0131 uyar\u0131lar\u0131, kapasite planlamas\u0131.<\/td>\nK\u00f6k neden analizi, performans optimizasyonu, hata ay\u0131klama, g\u00fcvenlik denetimi.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    \u00d6zetle, izleme sisteminizin “ne” oldu\u011funu s\u00f6ylerken, g\u00f6zlemlenebilirlik sisteminizin “neden” oldu\u011funu s\u00f6yler. Da\u011f\u0131t\u0131k ve karma\u015f\u0131k sistemlerde, bu “neden” sorusunu yan\u0131tlayabilmek, kritik bir rekabet avantaj\u0131 ve operasyonel verimlilik arac\u0131d\u0131r.<\/p>\n

    Metrikler: Sistem Sa\u011fl\u0131\u011f\u0131n\u0131n Nabz\u0131n\u0131 Tutmak Nas\u0131l M\u00fcmk\u00fcn?<\/h3>\n

    Metrikler, bir sistemin performans\u0131n\u0131 ve davran\u0131\u015f\u0131n\u0131 anlaman\u0131n en temel yollar\u0131ndan biridir. Belirli bir zaman diliminde toplanan say\u0131sal de\u011ferler olup, sistem sa\u011fl\u0131\u011f\u0131 hakk\u0131nda h\u0131zl\u0131 bir bak\u0131\u015f a\u00e7\u0131s\u0131 sunarlar. Metrikler olmadan, sisteminizin CPU’sunun ne kadar yo\u011fun \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131, bellek kullan\u0131m\u0131n\u0131n s\u0131n\u0131rlar\u0131 zorlay\u0131p zorlamad\u0131\u011f\u0131n\u0131 veya bir servisin ne kadar istek ald\u0131\u011f\u0131n\u0131 bilemezsiniz. Bu t\u00fcr veriler, sisteminizin “nabz\u0131n\u0131” tutmak gibidir ve proaktif bir \u015fekilde sorunlar\u0131 \u00f6nceden tespit etmenize yard\u0131mc\u0131 olur.<\/p>\n

    Metrikler genellikle \u00fc\u00e7 kategoriye ayr\u0131l\u0131r:<\/p>\n

      \n
    1. Sistem Metrikleri:<\/strong> CPU kullan\u0131m\u0131, bellek t\u00fcketimi, disk G\/\u00c7, a\u011f trafi\u011fi gibi altyap\u0131 bile\u015fenlerinin durumuyla ilgili verilerdir. \u0130\u015fletim sistemi veya konteyner \u00e7al\u0131\u015fma zaman\u0131 taraf\u0131ndan otomatik olarak toplanabilirler.<\/li>\n
    2. Uygulama Metrikleri:<\/strong> Uygulaman\u0131z\u0131n i\u00e7inden gelen verilerdir. \u00d6rne\u011fin, bir API \u00e7a\u011fr\u0131s\u0131n\u0131n yan\u0131t s\u00fcresi, bir veritaban\u0131 sorgusunun s\u00fcresi, kullan\u0131c\u0131 oturum say\u0131s\u0131, hata oranlar\u0131, belirli bir fonksiyonun \u00e7a\u011fr\u0131lma s\u0131kl\u0131\u011f\u0131 gibi. Bu metrikleri toplamak i\u00e7in uygulaman\u0131z\u0131n koduna enstr\u00fcmantasyon eklemeniz gerekebilir.<\/li>\n
    3. \u0130\u015f Metrikleri:<\/strong> Do\u011frudan i\u015f de\u011feriyle ilgili metriklerdir. \u00d6rne\u011fin, e-ticaret uygulamas\u0131ndaki sipari\u015f say\u0131s\u0131, kay\u0131t olan yeni kullan\u0131c\u0131 say\u0131s\u0131, belirli bir \u00fcr\u00fcn\u00fcn g\u00f6r\u00fcnt\u00fclenme say\u0131s\u0131. Bu metrikler, teknik performans\u0131n i\u015f \u00fczerindeki etkisini anlamak i\u00e7in \u00f6nemlidir.<\/li>\n<\/ol>\n

      Metrik toplama i\u00e7in pop\u00fcler ara\u00e7lardan biri Prometheus<\/a>‘tur. Prometheus, zaman serisi veritaban\u0131, \u00e7ekme tabanl\u0131 veri toplama mekanizmas\u0131 ve esnek bir sorgu dili (PromQL) sunar. Uygulamalar\u0131n\u0131za veya servislerinize bir istemci k\u00fct\u00fcphanesi entegre ederek metrikleri a\u00e7\u0131\u011fa \u00e7\u0131karabilirsiniz (expose). Prometheus sunucusu, yap\u0131land\u0131rd\u0131\u011f\u0131n\u0131z hedeflerden bu metrikleri d\u00fczenli aral\u0131klarla \u00e7eker.<\/p>\n

      \u00d6rne\u011fin, bir Node.js uygulamas\u0131nda Prometheus metriklerini nas\u0131l a\u00e7\u0131\u011fa \u00e7\u0131karabilece\u011finize dair basit bir \u00f6rnek:<\/p>\n

      const client = require('prom-client');\nconst express = require('express');\nconst app = express();\n\n\/\/ Register default metrics\nclient.collectDefaultMetrics();\n\n\/\/ Custom metric: a counter for HTTP requests\nconst httpRequestCounter = new client.Counter({\n  name: 'http_requests_total',\n  help: 'Total number of HTTP requests',\n  labelNames: ['method', 'status_code']\n});\n\n\/\/ Middleware to count requests\napp.use((req, res, next) => {\n  res.on('finish', () => {\n    httpRequestCounter.inc({ method: req.method, status_code: res.statusCode });\n  });\n  next();\n});\n\n\/\/ Expose metrics at \/metrics endpoint\napp.get('\/metrics', async (req, res) => {\n  res.set('Content-Type', client.register.contentType);\n  res.end(await client.register.metrics());\n});\n\napp.get('\/', (req, res) => {\n  res.send('Merhaba, Metrikler \u00c7al\u0131\u015f\u0131yor!');\n});\n\nconst PORT = process.env.PORT || 3000;\napp.listen(PORT, () => {\n  console.log(Uygulama ${PORT} portunda \u00e7al\u0131\u015f\u0131yor.<\/code>);\n});\n<\/pre>\n
      <\/code><\/p>\n
      Bu kod blo\u011fu, uygulaman\u0131za gelen HTTP isteklerini sayan ve bu metri\u011fi \/metrics<\/code> adresinde Prometheus'un okuyabilece\u011fi bir formatta sunan bir \u00f6rnek g\u00f6sterir. Prometheus sunucunuz bu u\u00e7 noktay\u0131 periyodik olarak sorgulayarak verileri toplar. Toplanan metrikler daha sonra Grafana<\/a> gibi g\u00f6rselle\u015ftirme ara\u00e7lar\u0131yla panolar olu\u015fturmak ve e\u011filimleri izlemek i\u00e7in kullan\u0131labilir.<\/p>\n
      \n  Uzman \u0130pucu: Metriklerinizi etiketlemeye (labeling) \u00f6zen g\u00f6sterin. Servis ad\u0131, endpoint, HTTP metodu, durum kodu gibi etiketler, metriklerinizi daha anlaml\u0131 hale getirir ve karma\u015f\u0131k sorgular yapman\u0131z\u0131 sa\u011flar. Bu sayede sorunlar\u0131 daha detayl\u0131 inceleyebilir ve farkl\u0131 boyutlarda analiz edebilirsiniz.\n<\/div>\n
      Loglar: Sistem Hikayesini Detayl\u0131ca Okumak \u0130\u00e7in Ne Yapmal\u0131y\u0131z?<\/h3>\n
      Loglar, bir sistemde meydana gelen her bir olay\u0131n yaz\u0131l\u0131 kayd\u0131d\u0131r. Uygulaman\u0131z\u0131n ne yapt\u0131\u011f\u0131n\u0131, hangi kararlar\u0131 ald\u0131\u011f\u0131n\u0131 ve hangi sorunlarla kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131 anlatan detayl\u0131 hikayelerdir. Da\u011f\u0131t\u0131k sistemlerde, tek bir kullan\u0131c\u0131n\u0131n iste\u011fi bile birden fazla servisten ge\u00e7ti\u011fi i\u00e7in, bu servislerin her birinin kendi loglar\u0131n\u0131 \u00fcretmesi ka\u00e7\u0131n\u0131lmazd\u0131r. Bu loglar\u0131n merkezi bir yerde toplanmas\u0131 ve analiz edilebilir hale getirilmesi, hata ay\u0131klama ve sorun giderme s\u00fcre\u00e7lerinde kritik \u00f6neme sahiptir.<\/p>\n
      Loglar genellikle farkl\u0131 seviyelerde (DEBUG, INFO, WARN, ERROR, FATAL) olu\u015fturulur. Bu seviyeler, logun \u00f6nem derecesini belirtir ve ne kadar detayl\u0131 bilgi istedi\u011finize g\u00f6re filtreleme yapman\u0131z\u0131 sa\u011flar. \u0130yi bir loglama stratejisi, sadece hata durumlar\u0131n\u0131 de\u011fil, ayn\u0131 zamanda sistemin kritik s\u00fcre\u00e7lerini, \u00f6nemli olaylar\u0131 ve kullan\u0131c\u0131 etkile\u015fimlerini de kaydetmeyi i\u00e7ermelidir.<\/p>\n
      Ancak, da\u011f\u0131t\u0131k sistemlerde log toplama ve y\u00f6netimi zorlu olabilir:<\/p>\n