Modern yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda, uygulamalar\u0131n her zaman beklendi\u011fi gibi \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamak giderek daha karma\u015f\u0131k hale geliyor. Da\u011f\u0131t\u0131k sistemlerin yayg\u0131nla\u015fmas\u0131, mikroservis mimarilerinin kullan\u0131m\u0131 ve s\u00fcrekli entegrasyon\/s\u00fcrekli da\u011f\u0131t\u0131m (CI\/CD) s\u00fcre\u00e7lerinin h\u0131zlanmas\u0131, hatalar\u0131n tespiti ve y\u00f6netilmesini zorla\u015ft\u0131r\u0131yor. Peki, bu karma\u015f\u0131kl\u0131k i\u00e7inde sistemlerimizin ne kadar “sa\u011fl\u0131kl\u0131” oldu\u011funu nas\u0131l \u00f6l\u00e7eriz? \u0130\u015fte burada “Hata B\u00fct\u00e7esi” (Error Budget) kavram\u0131 devreye giriyor. Bu makalede, a\u00e7\u0131k kaynakl\u0131 izleme (observability) \u00e7\u00f6z\u00fcm\u00fc SigNoz ve standart tabanl\u0131 telemetri platformu OpenTelemetry’yi kullanarak nas\u0131l otonom bir hata b\u00fct\u00e7esi ge\u00e7idi (gateway) olu\u015fturabilece\u011finizi ad\u0131m ad\u0131m inceleyece\u011fiz. Bu sayede, sistemlerinizdeki hatalar\u0131 proaktif olarak y\u00f6netebilir, kullan\u0131c\u0131 deneyimini iyile\u015ftirebilir ve geli\u015ftirme ekiplerinin g\u00fcvenle yenilik yapmas\u0131n\u0131 sa\u011flayabilirsiniz.<\/p>\n
Bu makale, da\u011f\u0131t\u0131k sistemlerde hata y\u00f6netimi ve izleme konular\u0131na ilgi duyan geli\u015ftiriciler, DevOps m\u00fchendisleri ve sistem mimarlar\u0131 i\u00e7in rehber niteli\u011findedir. Konuya tamamen yabanc\u0131 olanlar i\u00e7in temel kavramlar\u0131 a\u00e7\u0131klayacak, ard\u0131ndan pratik uygulamalar ve ileri d\u00fczey ipu\u00e7lar\u0131yla konuyu derinle\u015ftirecektir. Amac\u0131m\u0131z, karma\u015f\u0131k gibi g\u00f6r\u00fcnen bu s\u00fcreci anla\u015f\u0131l\u0131r hale getirmek ve okuyucular\u0131n kendi projelerinde uygulayabilecekleri somut ad\u0131mlar sunmakt\u0131r.<\/p>\n
G\u00fcn\u00fcm\u00fcz\u00fcn h\u0131zla de\u011fi\u015fen teknoloji ekosisteminde, yaz\u0131l\u0131m ekipleri s\u00fcrekli olarak yeni \u00f6zellikler geli\u015ftirmek ve mevcut sistemleri iyile\u015ftirmek i\u00e7in bask\u0131 alt\u0131ndad\u0131r. Ancak bu ilerleme h\u0131z\u0131, ka\u00e7\u0131n\u0131lmaz olarak hatalar\u0131n ortaya \u00e7\u0131kmas\u0131na neden olabilir. Geleneksel yakla\u015f\u0131mda, hatalar genellikle bir sorun olarak g\u00f6r\u00fcl\u00fcr ve hemen d\u00fczeltilmesi hedeflenir. Ancak bu yakla\u015f\u0131m, geli\u015ftirme h\u0131z\u0131n\u0131 yava\u015flatabilir ve ekipleri riskten ka\u00e7\u0131nmaya itebilir. Hata b\u00fct\u00e7esi kavram\u0131, bu dengeyi sa\u011flamak i\u00e7in ortaya \u00e7\u0131km\u0131\u015ft\u0131r. Temel fikir \u015fudur: Bir sistemin belirli bir zaman diliminde kabul edilebilir bir hata oran\u0131 vard\u0131r. Bu b\u00fct\u00e7e a\u015f\u0131ld\u0131\u011f\u0131nda, yeni \u00f6zellik geli\u015ftirme yerine mevcut hatalar\u0131 d\u00fczeltmeye odaklan\u0131l\u0131r.<\/p>\n
Hata b\u00fct\u00e7esi, sadece bir hata oran\u0131 belirlemekle kalmaz, ayn\u0131 zamanda sistemin g\u00fcvenilirli\u011fi ile yenilik\u00e7ili\u011fi aras\u0131ndaki dengeyi kurmaya yard\u0131mc\u0131 olur. \u00d6rne\u011fin, bir e-ticaret sitesinde, \u00f6deme i\u015flemleri gibi kritik bir i\u015flev i\u00e7in hata b\u00fct\u00e7esi \u00e7ok d\u00fc\u015f\u00fck tutulurken, kullan\u0131c\u0131 profili g\u00fcncelleme gibi daha az kritik bir i\u015flev i\u00e7in daha y\u00fcksek bir hata b\u00fct\u00e7esi tan\u0131mlanabilir. Bu, ekiplerin hangi alanlara daha fazla dikkat etmesi gerekti\u011fini belirlemelerine ve kaynaklar\u0131n\u0131 en etkili \u015fekilde kullanmalar\u0131na olanak tan\u0131r. SigNoz ve OpenTelemetry gibi ara\u00e7larla entegre edildi\u011finde, bu b\u00fct\u00e7eyi otomatik olarak izleyebilir ve gerekti\u011finde aksiyon al\u0131nmas\u0131n\u0131 sa\u011flayabiliriz. Bu da “otonom” bir hata b\u00fct\u00e7esi ge\u00e7idi olu\u015fturmam\u0131z\u0131 m\u00fcmk\u00fcn k\u0131lar.<\/p>\n
Hata b\u00fct\u00e7esi, bir hizmetin belirli bir zaman dilimi boyunca (\u00f6rne\u011fin, bir ay) kabul edebilece\u011fi maksimum hata y\u00fczdesini ifade eder. Bu, genellikle “hizmet seviyesi g\u00f6stergesi” (Service Level Indicator – SLI) olarak tan\u0131mlanan bir metrik \u00fczerinden hesaplan\u0131r. \u00d6rne\u011fin, bir SLI, bir iste\u011fin ba\u015far\u0131yla tamamlanma oran\u0131 olabilir. E\u011fer bir hizmetin hedefi %99.9 ba\u015far\u0131 oran\u0131 ise, bu %0.1’lik k\u0131sm\u0131n hata b\u00fct\u00e7esi oldu\u011funu s\u00f6yleyebiliriz. Bu b\u00fct\u00e7e, sistemin \u00e7al\u0131\u015f\u0131rken kar\u015f\u0131la\u015ft\u0131\u011f\u0131 hatalar i\u00e7in harcan\u0131r.<\/p>\n
Hata b\u00fct\u00e7esinin \u00f6nemi birka\u00e7 temel noktada yatmaktad\u0131r:<\/p>\n
Bu kavramlar\u0131 somutla\u015ft\u0131rmak gerekirse, bir online bankac\u0131l\u0131k uygulamas\u0131n\u0131 d\u00fc\u015f\u00fcnelim. Bu uygulaman\u0131n para transferi gibi kritik bir i\u015flemi i\u00e7in hata b\u00fct\u00e7esi %0.01 gibi \u00e7ok d\u00fc\u015f\u00fck bir de\u011ferde olabilir. E\u011fer bir ay i\u00e7inde bu b\u00fct\u00e7e a\u015f\u0131l\u0131rsa, yeni bir mobil uygulama \u00f6zelli\u011fi eklemek yerine t\u00fcm geli\u015ftirme kaynaklar\u0131 para transferi mod\u00fcl\u00fcndeki hatalar\u0131 gidermeye y\u00f6nlendirilir. Bu, hem kullan\u0131c\u0131lar\u0131n finansal i\u015flemlerinin g\u00fcvenli\u011fini sa\u011flar hem de geli\u015ftirme ekiplerinin ne zaman “risk alabilece\u011fini” ve ne zaman “g\u00fcvenli\u011fi \u00f6nceliklendirmesi” gerekti\u011fini net bir \u015fekilde ortaya koyar.<\/p>\n
Otonom bir hata b\u00fct\u00e7esi ge\u00e7idi olu\u015fturmak i\u00e7in g\u00fc\u00e7l\u00fc bir izleme (observability) altyap\u0131s\u0131na ihtiyac\u0131m\u0131z var. \u0130\u015fte bu noktada SigNoz ve OpenTelemetry devreye giriyor. Bu ikili, modern da\u011f\u0131t\u0131k sistemlerin karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 anlamak ve y\u00f6netmek i\u00e7in kapsaml\u0131 bir \u00e7\u00f6z\u00fcm sunar. OpenTelemetry, telemetri verilerini (izler, metrikler ve g\u00fcnl\u00fckler) toplamak, i\u015flemek ve g\u00f6ndermek i\u00e7in a\u00e7\u0131k bir standart ve ara\u00e7 setidir. SigNoz ise, bu verileri almak, depolamak, g\u00f6rselle\u015ftirmek ve analiz etmek i\u00e7in a\u00e7\u0131k kaynakl\u0131 bir izleme platformudur.<\/p>\n
OpenTelemetry’nin sundu\u011fu en b\u00fcy\u00fck avantaj, sat\u0131c\u0131 ba\u011f\u0131ms\u0131zl\u0131\u011f\u0131d\u0131r. Farkl\u0131 dillerde ve framework’lerde yaz\u0131lm\u0131\u015f uygulamalar\u0131n\u0131zdaki telemetri verilerini tek bir standart formatta toplaman\u0131z\u0131 sa\u011flar. Bu, vendor lock-in (tedarik\u00e7i kilidi) riskini ortadan kald\u0131r\u0131r ve gelecekte farkl\u0131 izleme ara\u00e7lar\u0131na ge\u00e7i\u015f yapmay\u0131 kolayla\u015ft\u0131r\u0131r. Uygulamalar\u0131n\u0131za OpenTelemetry SDK’lar\u0131n\u0131 entegre ederek, kritik metrikleri ve izleri otomatik olarak toplayabilirsiniz. Bu metrikler, hata b\u00fct\u00e7enizi hesaplamak i\u00e7in temel olu\u015fturacakt\u0131r.<\/p>\n
SigNoz ise, OpenTelemetry taraf\u0131ndan toplanan bu ham verileri anlaml\u0131 bilgilere d\u00f6n\u00fc\u015ft\u00fcren platformdur. Kullan\u0131c\u0131 dostu aray\u00fcz\u00fc sayesinde, hizmetlerinizin performans\u0131n\u0131, hatalar\u0131n\u0131 ve genel sa\u011fl\u0131\u011f\u0131n\u0131 kolayca izleyebilirsiniz. Metrikleri g\u00f6rselle\u015ftirebilir, uyar\u0131lar (alerts) ayarlayabilir ve da\u011f\u0131t\u0131k izleme (distributed tracing) ile isteklerin bir hizmetten di\u011ferine nas\u0131l akt\u0131\u011f\u0131n\u0131 takip edebilirsiniz. SigNoz’un en g\u00fc\u00e7l\u00fc yanlar\u0131ndan biri, OpenTelemetry ile sorunsuz entegrasyonu ve tek bir platformda izleme, metrikler ve g\u00fcnl\u00fckleri bir araya getirmesidir. Bu, hata b\u00fct\u00e7esi takibi gibi karma\u015f\u0131k senaryolar\u0131 y\u00f6netmeyi \u00e7ok daha kolay hale getirir.<\/p>\n
OpenTelemetry (OTel), bulut-yerel uygulamalar i\u00e7in telemetri verilerini (metrikler, izler ve g\u00fcnl\u00fckler) \u00fcretmek, toplamak ve g\u00f6ndermek i\u00e7in bir dizi API, SDK, ara\u00e7 ve uzant\u0131 sunan bir projedir. CNCF (Cloud Native Computing Foundation) taraf\u0131ndan desteklenen OpenTelemetry, telemetri verilerini standartla\u015ft\u0131rmay\u0131 ama\u00e7lar. Bu standartla\u015fma, farkl\u0131 ara\u00e7lar ve platformlar aras\u0131nda veri al\u0131\u015fveri\u015fini kolayla\u015ft\u0131r\u0131r ve ekiplerin izleme altyap\u0131lar\u0131n\u0131 esnek bir \u015fekilde tasarlamalar\u0131na olanak tan\u0131r.<\/p>\n
OpenTelemetry’nin temel bile\u015fenleri \u015funlard\u0131r:<\/p>\n
\u00d6rne\u011fin, bir Java uygulamas\u0131nda OpenTelemetry kullanarak \u015fu \u015fekilde metrikler toplayabilirsiniz:<\/p>\n
\nimport io.opentelemetry.api.OpenTelemetry;\nimport io.opentelemetry.api.common.Attributes;\nimport io.opentelemetry.api.metrics.DoubleCounter;\nimport io.opentelemetry.api.metrics.Meter;\nimport io.opentelemetry.api.metrics.MeterProvider;\n\npublic class MyService {\n\n private static final String INSTRUMENTATION_SCOPE_NAME = \"my-service\";\n private static DoubleCounter requestCounter;\n\n public static void initialize(OpenTelemetry openTelemetry) {\n Meter meter = openTelemetry.getMeterProvider().get(INSTRUMENTATION_SCOPE_NAME);\n requestCounter = meter.counterBuilder(\"http.server.requests\")\n .setDescription(\"Number of HTTP server requests.\")\n .setUnit(\"1\")\n .build();\n }\n\n public void handleRequest(String method, String status) {\n Attributes attributes = Attributes.builder()\n .put(\"http.method\", method)\n .put(\"http.status_code\", status)\n .build();\n requestCounter.add(1.0, attributes);\n }\n\n \/\/ ... di\u011fer servis mant\u0131\u011f\u0131 ...\n}\n <\/code><\/pre>\nBu kod par\u00e7as\u0131, bir HTTP iste\u011fi geldi\u011finde sayac\u0131 art\u0131rarak gelen istek say\u0131s\u0131n\u0131 metrik olarak toplar. http.method<\/code> ve http.status_code<\/code> gibi etiketler, bu metrikleri daha detayl\u0131 analiz etmemizi sa\u011flar. Bu metrikler daha sonra OpenTelemetry Collector arac\u0131l\u0131\u011f\u0131yla SigNoz gibi bir arka uca g\u00f6nderilebilir.<\/p>\nSigNoz: A\u00e7\u0131k Kaynakl\u0131 \u0130zleme Platformu<\/h3>\n
SigNoz, OpenTelemetry’yi destekleyen ve izleme, metrikler ve g\u00fcnl\u00fckleri tek bir platformda birle\u015ftiren a\u00e7\u0131k kaynakl\u0131 bir izleme (observability) \u00e7\u00f6z\u00fcm\u00fcd\u00fcr. Temel olarak, da\u011f\u0131t\u0131k sistemlerinizdeki telemetri verilerini toplar, depolar, analiz eder ve g\u00f6rselle\u015ftirir. SigNoz, Prometheus ve Jaeger gibi pop\u00fcler a\u00e7\u0131k kaynakl\u0131 ara\u00e7lar\u0131n yeteneklerini tek bir platformda sunarak karma\u015f\u0131kl\u0131\u011f\u0131 azalt\u0131r.<\/p>\n
SigNoz’un sundu\u011fu temel \u00f6zellikler \u015funlard\u0131r:<\/p>\n
\n- Da\u011f\u0131t\u0131k \u0130zleme (Distributed Tracing):<\/b> OpenTelemetry ile entegre olarak, bir iste\u011fin farkl\u0131 servisler aras\u0131ndaki yolculu\u011funu ad\u0131m ad\u0131m izlemenizi sa\u011flar. Bu, performans darbo\u011fazlar\u0131n\u0131 ve hatalar\u0131n kayna\u011f\u0131n\u0131 bulmak i\u00e7in kritiktir.<\/li>\n
- Metrikler (Metrics):<\/b> Uygulamalar\u0131n\u0131zdan gelen metrikleri toplar, depolar ve g\u00f6rselle\u015ftirir. Bu metrikler, hata b\u00fct\u00e7esi hesaplamalar\u0131 ve sistem sa\u011fl\u0131\u011f\u0131 takibi i\u00e7in kullan\u0131l\u0131r.<\/li>\n
- G\u00fcnl\u00fckler (Logs):<\/b> Uygulama g\u00fcnl\u00fcklerini merkezi bir yerde toplar ve aranabilir hale getirir.<\/li>\n
- Uyar\u0131lar (Alerting):<\/b> Belirlenen e\u015fiklere ula\u015f\u0131ld\u0131\u011f\u0131nda veya belirli durumlar olu\u015ftu\u011funda otomatik uyar\u0131lar g\u00f6nderir.<\/li>\n
- Kullan\u0131c\u0131 Dostu Aray\u00fcz:<\/b> T\u00fcm bu verileri anla\u015f\u0131l\u0131r grafikler ve tablolarla sunan sezgisel bir web aray\u00fcz\u00fc sa\u011flar.<\/li>\n<\/ul>\n
SigNoz’u kurmak genellikle Docker Compose kullanarak birka\u00e7 ad\u0131mda ger\u00e7ekle\u015ftirilebilir. Kurulum sonras\u0131, OpenTelemetry SDK’lar\u0131 ile yap\u0131land\u0131r\u0131lm\u0131\u015f uygulamalar\u0131n\u0131zdan gelen verileri SigNoz aray\u00fcz\u00fcnde g\u00f6rmeye ba\u015flayabilirsiniz. \u00d6rne\u011fin, bir hizmetin istek ba\u015f\u0131na ortalama yan\u0131t s\u00fcresi gibi metrikleri SigNoz’da g\u00f6rselle\u015ftirebilirsiniz.<\/p>\n
Otonom Hata B\u00fct\u00e7esi Ge\u00e7idi Olu\u015fturma Ad\u0131mlar\u0131<\/h2>\n
Art\u0131k temel kavramlar\u0131 ve ara\u00e7lar\u0131 anlad\u0131\u011f\u0131m\u0131za g\u00f6re, SigNoz ve OpenTelemetry ile otonom bir hata b\u00fct\u00e7esi ge\u00e7idi olu\u015fturma s\u00fcrecine ge\u00e7ebiliriz. Bu s\u00fcre\u00e7, birka\u00e7 ana ad\u0131mdan olu\u015fur: do\u011fru metrikleri tan\u0131mlama, bu metrikleri toplama, SigNoz’da hata b\u00fct\u00e7esini hesaplama ve gerekti\u011finde aksiyon alma mekanizmalar\u0131n\u0131 kurma.<\/p>\n
Bu ad\u0131mlar, sisteminizin mevcut durumuna ve gereksinimlerine g\u00f6re uyarlanabilir. Ancak genel \u00e7er\u00e7eve, g\u00fcvenilirli\u011fi \u00f6l\u00e7mek i\u00e7in \u00f6l\u00e7\u00fclebilir bir hedef belirlemek, bu hedefe ula\u015fmak i\u00e7in gerekli veriyi toplamak ve bu veriye dayanarak otomatik kararlar almakt\u0131r. Otonom bir sistemde, bu kararlar manuel m\u00fcdahale gerektirmeden al\u0131n\u0131r ve uygulan\u0131r.<\/p>\n
Ad\u0131m 1: Hata B\u00fct\u00e7esi \u0130\u00e7in Kritik Hizmet Seviyesi G\u00f6stergelerini (SLI) Tan\u0131mlama<\/h3>\n
Hata b\u00fct\u00e7esinin temelini olu\u015fturan \u015fey, hizmetlerinizin ne kadar “iyi” \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 \u00f6l\u00e7en metriklerdir. Bu metriklere Hizmet Seviyesi G\u00f6stergeleri (Service Level Indicators – SLI) denir. Bir hata b\u00fct\u00e7esi ge\u00e7idi olu\u015ftururken, hangi SLI’lar\u0131n en kritik oldu\u011funu belirlemek ilk ad\u0131md\u0131r. Bu SLI’lar, kullan\u0131c\u0131 deneyimini do\u011frudan etkileyen, i\u015f ak\u0131\u015f\u0131n\u0131n s\u00fcreklili\u011fi i\u00e7in hayati \u00f6nem ta\u015f\u0131yan metrikler olmal\u0131d\u0131r.<\/p>\n
Yayg\u0131n olarak kullan\u0131lan SLI t\u00fcrleri \u015funlard\u0131r:<\/p>\n
\n- Ba\u015far\u0131 Oran\u0131 (Success Rate):<\/b> Belirli bir zaman diliminde ba\u015far\u0131yla tamamlanan isteklerin toplam isteklere oran\u0131. \u00d6rne\u011fin, bir API iste\u011finin 2xx veya 3xx durum koduyla d\u00f6nmesi ba\u015far\u0131 olarak kabul edilebilir.<\/li>\n
- Gecikme S\u00fcresi (Latency):<\/b> Bir iste\u011fin i\u015flenmesi i\u00e7in ge\u00e7en ortalama veya belirli bir y\u00fczdelik dilimdeki (\u00f6rne\u011fin, 95. persentil) s\u00fcre. Y\u00fcksek gecikme s\u00fcresi, kullan\u0131c\u0131 deneyimini olumsuz etkiler.<\/li>\n
- Hata Oran\u0131 (Error Rate):<\/b> Belirli bir zaman diliminde ba\u015far\u0131s\u0131z olan isteklerin toplam isteklere oran\u0131. Bu, do\u011frudan hata b\u00fct\u00e7esi hesaplamas\u0131nda kullan\u0131labilir.<\/li>\n
- Kullan\u0131labilirlik (Availability):<\/b> Hizmetin belirli bir zaman diliminde eri\u015filebilir olma y\u00fczdesi.<\/li>\n<\/ul>\n
\u00d6rne\u011fin, bir mikroservis mimarisinde \u00e7al\u0131\u015fan bir e-ticaret platformu i\u00e7in \u015fu SLI’lar\u0131 tan\u0131mlayabiliriz:<\/p>\n
\n- Kullan\u0131c\u0131 Kay\u0131t API’si Ba\u015far\u0131 Oran\u0131:<\/b> Kay\u0131t i\u015fleminin ba\u015far\u0131yla tamamlanma y\u00fczdesi.<\/li>\n
- \u00dcr\u00fcn Arama API’si Gecikme S\u00fcresi:<\/b> \u00dcr\u00fcn arama sorgular\u0131n\u0131n ortalama yan\u0131t s\u00fcresi.<\/li>\n
- Sepete Ekleme API’si Hata Oran\u0131:<\/b> Sepete ekleme i\u015fleminin ba\u015far\u0131s\u0131z olma y\u00fczdesi.<\/li>\n
- \u00d6deme \u0130\u015flemi Ba\u015far\u0131 Oran\u0131:<\/b> \u00d6deme i\u015fleminin ba\u015far\u0131l\u0131 olma y\u00fczdesi.<\/li>\n<\/ul>\n
Bu SLI’lar\u0131 tan\u0131mlarken, “iyi” ve “k\u00f6t\u00fc” aras\u0131ndaki s\u0131n\u0131r\u0131 net bir \u015fekilde belirlemek \u00f6nemlidir. \u00d6rne\u011fin, “ba\u015far\u0131l\u0131” bir istek nedir? 500ms alt\u0131nda yan\u0131t veren istekler mi, yoksa 100ms alt\u0131nda yan\u0131t verenler mi? Bu tan\u0131mlamalar, hata b\u00fct\u00e7esi hesaplamalar\u0131n\u0131n do\u011frulu\u011funu do\u011frudan etkiler.<\/p>\n
Ad\u0131m 2: OpenTelemetry ile SLI Metriklerini Toplama ve G\u00f6nderme<\/h3>\n
Tan\u0131mlad\u0131\u011f\u0131m\u0131z SLI’lar\u0131 toplamak i\u00e7in OpenTelemetry SDK’lar\u0131n\u0131 uygulamalar\u0131m\u0131za entegre etmemiz gerekiyor. Bu, her bir hizmetin kendi kritik metriklerini izlemesini ve bu metrikleri bir telemetri arka ucuna (bu durumda SigNoz) g\u00f6ndermesini sa\u011flar.<\/p>\n
\u00d6rnek olarak, bir Node.js uygulamas\u0131nda HTTP isteklerinin ba\u015far\u0131 oran\u0131n\u0131 ve gecikme s\u00fcresini izlemek i\u00e7in OpenTelemetry’yi nas\u0131l kullanabilece\u011fimizi g\u00f6relim:<\/p>\n
\nconst { trace } = require('@opentelemetry\/api');\nconst { HttpInstrumentation } = require('@opentelemetry\/instrumentation-http');\nconst { NodeSDK } = require('@opentelemetry\/sdk-node');\nconst { OTLPTraceExporter } = require('@opentelemetry\/exporter-otlp-proto');\nconst { PrometheusExporter } = require('@opentelemetry\/exporter-prometheus');\nconst { MeterProvider } = require('@opentelemetry\/sdk-metrics');\n\nconst sdk = new NodeSDK({\n traceExporter: new OTLPTraceExporter({\n url: 'http:\/\/localhost:4318\/v1\/traces', \/\/ SigNoz'un OTLP gRPC endpoint'i\n }),\n instrumentations: [\n new HttpInstrumentation(),\n ],\n});\n\nsdk.start();\n\n\/\/ Metrikler i\u00e7in MeterProvider ve Prometheus Exporter (SigNoz Prometheus'u destekler)\nconst meterProvider = new MeterProvider();\nconst prometheusExporter = new PrometheusExporter({\n \/\/ SigNoz, Prometheus metriklerini belirli bir endpoint'ten \u00e7eker\n \/\/ Bu yap\u0131land\u0131rma, SigNoz'un metrikleri toplamas\u0131 i\u00e7in gereklidir.\n});\n\nconst meter = meterProvider.getMeter('my-node-app');\nconst requestCounter = meter.createCounter('http.server.requests', {\n description: 'Number of HTTP server requests',\n unit: '1',\n});\nconst requestLatency = meter.createHistogram('http.server.request.latency', {\n description: 'Latency of HTTP server requests',\n unit: 'ms',\n});\n\n\/\/ Express.js uygulamas\u0131nda middleware olarak kullanma \u00f6rne\u011fi\nconst express = require('express');\nconst app = express();\n\napp.use((req, res, next) => {\n const start = process.hrtime();\n res.on('finish', () => {\n const duration = process.hrtime(start);\n const latencyMs = (duration[0] * 1000) + (duration[1] \/ 1e6);\n requestLatency.record(latencyMs);\n\n const statusCode = res.statusCode;\n const httpMethod = req.method;\n const success = statusCode >= 200 && statusCode < 400;\n\n requestCounter.add(1, {\n http_method: httpMethod,\n http_status_code: statusCode,\n success: success ? 'true' : 'false',\n });\n });\n next();\n});\n\napp.get('\/', (req, res) => {\n setTimeout(() => {\n res.send('Merhaba!');\n }, Math.random() * 100);\n});\n\napp.listen(3000, () => {\n console.log('Sunucu 3000 portunda \u00e7al\u0131\u015f\u0131yor');\n});\n\n\/\/ Metrikleri toplamak i\u00e7in Prometheus exporter'\u0131 ba\u015flat\nprometheusExporter.start();\n <\/code><\/pre>\nBu \u00f6rnekte, http.server.requests<\/code> ve http.server.request.latency<\/code> metriklerini topluyoruz. success<\/code> etiketi, iste\u011fin ba\u015far\u0131l\u0131 olup olmad\u0131\u011f\u0131n\u0131 belirtiyor. Bu metrikler, SigNoz’a g\u00f6nderilerek hata b\u00fct\u00e7esi hesaplamalar\u0131nda kullan\u0131lacakt\u0131r. SigNoz’un OpenTelemetry Collector’\u0131 veya do\u011frudan OTLP gRPC\/HTTP endpoint’leri arac\u0131l\u0131\u011f\u0131yla metrikleri alabilece\u011fini unutmay\u0131n.<\/p>\nAd\u0131m 3: SigNoz’da Hata B\u00fct\u00e7esi Hesaplama ve G\u00f6rselle\u015ftirme<\/h3>\n
OpenTelemetry ile toplanan metrikler SigNoz’a ula\u015ft\u0131ktan sonra, hata b\u00fct\u00e7esi hesaplamalar\u0131n\u0131 yapabiliriz. SigNoz, Prometheus sorgu dilini (PromQL) destekledi\u011fi i\u00e7in, bu hesaplamalar\u0131 kolayca ger\u00e7ekle\u015ftirebiliriz.<\/p>\n
\u00d6rne\u011fin, bir hizmetin son 5 dakikadaki ba\u015far\u0131 oran\u0131n\u0131 hesaplamak i\u00e7in a\u015fa\u011f\u0131daki PromQL sorgusunu kullanabiliriz:<\/p>\n
(sum by (service_name) (rate(http_server_requests_total{success=\"true\"}[5m])) \/ sum by (service_name) (rate(http_server_requests_total{}[5m]))) * 100<\/code><\/p>\nBu sorgu, son 5 dakikadaki ba\u015far\u0131l\u0131 isteklerin oran\u0131n\u0131 hesaplar. SigNoz’un grafik aray\u00fcz\u00fcnde bu sorguyu kullanarak bir dashboard olu\u015fturabiliriz. Hata b\u00fct\u00e7esini g\u00f6rselle\u015ftirmek i\u00e7in, bu ba\u015far\u0131 oran\u0131n\u0131 hedefledi\u011fimiz SLI de\u011feriyle kar\u015f\u0131la\u015ft\u0131rabiliriz. \u00d6rne\u011fin, e\u011fer hedefimiz %99.9 ba\u015far\u0131 oran\u0131 ise, bu metrik %99.9’un alt\u0131na d\u00fc\u015ft\u00fc\u011f\u00fcnde bir uyar\u0131 tetiklenebilir.<\/p>\n
Hata b\u00fct\u00e7esi t\u00fcketimini izlemek i\u00e7in de \u00f6zel metrikler tan\u0131mlayabiliriz. \u00d6rne\u011fin, her ba\u015far\u0131s\u0131z istek i\u00e7in bir “hata b\u00fct\u00e7esi t\u00fcketimi” sayac\u0131 art\u0131r\u0131labilir. Bu sayac\u0131n belirli bir zaman dilimindeki toplam de\u011feri, t\u00fcketilen hata b\u00fct\u00e7esini g\u00f6sterir.<\/p>\n
SigNoz’da bir “Hata B\u00fct\u00e7esi Paneli” olu\u015fturarak \u015fu bilgileri g\u00f6rselle\u015ftirebiliriz:<\/p>\n
\n- Her kritik hizmet i\u00e7in mevcut ba\u015far\u0131 oran\u0131.<\/li>\n
- Hedeflenen ba\u015far\u0131 oran\u0131 (SLO – Service Level Objective).<\/li>\n
- T\u00fcketilen hata b\u00fct\u00e7esi y\u00fczdesi.<\/li>\n
- Kalan hata b\u00fct\u00e7esi.<\/li>\n
- Son d\u00f6nemdeki hata art\u0131\u015flar\u0131 veya d\u00fc\u015f\u00fc\u015fleri.<\/li>\n<\/ul>\n
Bu g\u00f6rselle\u015ftirmeler, ekiplerin sistemin sa\u011fl\u0131\u011f\u0131 hakk\u0131nda h\u0131zl\u0131 bir genel bak\u0131\u015f edinmelerini ve potansiyel sorunlar\u0131 erkenden fark etmelerini sa\u011flar.<\/p>\n
Ad\u0131m 4: Otomatik Uyar\u0131lar ve Aksiyon Mekanizmalar\u0131 Kurma<\/h3>\n
Otonom hata b\u00fct\u00e7esi ge\u00e7idinin en \u00f6nemli \u00f6zelli\u011fi, belirlenen e\u015fikler a\u015f\u0131ld\u0131\u011f\u0131nda otomatik olarak aksiyon alabilmesidir. SigNoz, uyar\u0131 (alerting) mekanizmalar\u0131 ile bu i\u015flevi yerine getirebilir.<\/p>\n
SigNoz’da, hata b\u00fct\u00e7esi belirli bir seviyenin alt\u0131na d\u00fc\u015ft\u00fc\u011f\u00fcnde veya ba\u015far\u0131 oran\u0131 hedefin alt\u0131na indi\u011finde tetiklenecek uyar\u0131lar tan\u0131mlayabiliriz. Bu uyar\u0131lar, Slack, PagerDuty, e-posta gibi \u00e7e\u015fitli bildirim kanallar\u0131na g\u00f6nderilebilir.<\/p>\n
Daha geli\u015fmi\u015f bir senaryoda, bu uyar\u0131lar sadece bilgilendirme ama\u00e7l\u0131 olmay\u0131p, otomatik aksiyonlar\u0131 da tetikleyebilir. \u00d6rne\u011fin:<\/p>\n
\n- Geli\u015ftirme K\u0131s\u0131tlamas\u0131:<\/b> E\u011fer hata b\u00fct\u00e7esi t\u00fckenmek \u00fczereyse, CI\/CD pipeline’\u0131ndaki yeni \u00f6zellik da\u011f\u0131t\u0131mlar\u0131n\u0131 otomatik olarak durdurabiliriz. Bu, “hata b\u00fct\u00e7esi t\u00fckenmeden yeni \u00f6zellik yok” politikas\u0131d\u0131r.<\/li>\n
- Otomatik Geri Alma (Rollback):<\/b> E\u011fer bir da\u011f\u0131t\u0131m sonras\u0131 hata oran\u0131 aniden y\u00fckselirse, otomatik olarak \u00f6nceki kararl\u0131 s\u00fcr\u00fcme geri d\u00f6n\u00fclebilir.<\/li>\n
- Otomatik \u00d6l\u00e7eklendirme (Scaling):<\/b> Yo\u011fun trafik nedeniyle hata oran\u0131 art\u0131yorsa, hizmetin otomatik olarak \u00f6l\u00e7eklenmesi tetiklenebilir.<\/li>\n
- Daha Fazla Kaynak Tahsisi:<\/b> Hata b\u00fct\u00e7esi s\u00fcrekli olarak a\u015f\u0131l\u0131yorsa, bu durum ilgili ekibe bildirilir ve ekibin sorunu \u00e7\u00f6zmek i\u00e7in ek kaynaklar veya zaman ay\u0131rmas\u0131 istenir.<\/li>\n<\/ul>\n
Bu t\u00fcr otomatik aksiyonlar, yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerini daha dayan\u0131kl\u0131 ve g\u00fcvenilir hale getirir. \u00d6rne\u011fin, Kubernetes \u00fczerinde \u00e7al\u0131\u015fan bir uygulamada, hata b\u00fct\u00e7esi a\u015f\u0131ld\u0131\u011f\u0131nda bir Kubernetes Job tetikleyerek otomatik bir geri alma i\u015flemi ba\u015flat\u0131labilir. Bu, manuel m\u00fcdahale gerektirmeden sistemin sa\u011fl\u0131\u011f\u0131n\u0131 korur.<\/p>\n
Ger\u00e7ek D\u00fcnya Senaryosu: E-Ticaret Sitesinde Hata B\u00fct\u00e7esi Y\u00f6netimi<\/h2>\n
Bir e-ticaret sitesi d\u00fc\u015f\u00fcnelim. Bu sitede binlerce \u00fcr\u00fcn var ve her g\u00fcn milyonlarca kullan\u0131c\u0131 al\u0131\u015fveri\u015f yap\u0131yor. Sitenin temel i\u015flevleri aras\u0131nda \u00fcr\u00fcn arama, sepete ekleme, \u00f6deme yapma ve sipari\u015f takibi yer al\u0131yor. Bu i\u015flevlerin her birinin y\u00fcksek oranda eri\u015filebilir ve h\u0131zl\u0131 olmas\u0131 gerekiyor.<\/p>\n
Problem:<\/b> Geli\u015ftirme ekibi s\u00fcrekli olarak yeni \u00f6zellikler ekliyor, ancak bu durum bazen beklenmedik hatalara yol a\u00e7\u0131yor. Kullan\u0131c\u0131lar, \u00f6deme s\u0131ras\u0131nda ya\u015fanan hatalar nedeniyle al\u0131\u015fveri\u015flerini tamamlayam\u0131yor ve bu da gelir kayb\u0131na neden oluyor. Hangi \u00f6zellik geli\u015ftirmenin g\u00fcvenilirli\u011fi daha \u00e7ok etkiledi\u011fini anlamak zorla\u015f\u0131yor.<\/p>\n
\u00c7\u00f6z\u00fcm:<\/b> SigNoz ve OpenTelemetry kullanarak bir hata b\u00fct\u00e7esi ge\u00e7idi olu\u015fturuluyor.<\/p>\n
Ad\u0131mlar:<\/b><\/p>\n\n- SLI Tan\u0131mlama:<\/b> Kritik i\u015flevler i\u00e7in SLI’lar belirlenir:\n
\n- \u00d6deme \u0130\u015flemi Ba\u015far\u0131 Oran\u0131 (Hedef: %99.99)<\/li>\n
- \u00dcr\u00fcn Arama Gecikme S\u00fcresi (Hedef: 95. persentil < 500ms)<\/li>\n
- Sepete Ekleme Ba\u015far\u0131 Oran\u0131 (Hedef: %99.9)<\/li>\n<\/ul>\n<\/li>\n
- OpenTelemetry Entegrasyonu:<\/b> Her bir mikroservise OpenTelemetry SDK’lar\u0131 eklenir. \u00d6deme servisi, \u00f6deme i\u015fleminin sonucunu (ba\u015far\u0131l\u0131\/ba\u015far\u0131s\u0131z) ve s\u00fcresini metrik olarak toplar. \u00dcr\u00fcn arama servisi, arama sorgular\u0131n\u0131n s\u00fcresini metrik olarak toplar.<\/li>\n
- SigNoz Kurulumu:<\/b> SigNoz kurulur ve OpenTelemetry Collector arac\u0131l\u0131\u011f\u0131yla metrikler SigNoz’a g\u00f6nderilir.<\/li>\n
- Hata B\u00fct\u00e7esi Paneli:<\/b> SigNoz’da, her SLI i\u00e7in mevcut durumunu g\u00f6steren bir dashboard olu\u015fturulur. Hata b\u00fct\u00e7esi y\u00fczdesi hesaplan\u0131r ve g\u00f6rselle\u015ftirilir. \u00d6rne\u011fin, \u00f6deme i\u015flemi ba\u015far\u0131 oran\u0131 %99.99’un alt\u0131na d\u00fc\u015ft\u00fc\u011f\u00fcnde, hata b\u00fct\u00e7esi t\u00fcketildi\u011fi anlam\u0131na gelir.<\/li>\n
- Otomatik Uyar\u0131lar ve Aksiyonlar:<\/b>\n
\n- \u00d6deme \u0130\u015flemi Ba\u015far\u0131 Oran\u0131 %99.95’in alt\u0131na d\u00fc\u015ft\u00fc\u011f\u00fcnde, geli\u015ftirme ekibine Slack \u00fczerinden uyar\u0131 g\u00f6nderilir.<\/li>\n
- E\u011fer ba\u015far\u0131 oran\u0131 %99.9’un alt\u0131na d\u00fc\u015ferse, CI\/CD pipeline’\u0131 otomatik olarak durdurulur ve yeni \u00f6zellik da\u011f\u0131t\u0131mlar\u0131 ask\u0131ya al\u0131n\u0131r.<\/li>\n
- Geli\u015ftirme ekibi, bu durumdan haberdar olduktan sonra \u00f6nceli\u011fi hata gidermeye verir.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n
Sonu\u00e7:<\/b> Bu yakla\u015f\u0131m sayesinde, e-ticaret sitesi, kritik i\u015flevlerdeki hatalar\u0131 proaktif olarak y\u00f6netebilir. Geli\u015ftirme ekipleri, hata b\u00fct\u00e7esi dahilinde kald\u0131klar\u0131 s\u00fcrece yenilik yapmaya devam edebilirken, b\u00fct\u00e7e a\u015f\u0131ld\u0131\u011f\u0131nda sistemin kararl\u0131l\u0131\u011f\u0131na odaklan\u0131l\u0131r. Bu, hem kullan\u0131c\u0131 memnuniyetini art\u0131r\u0131r hem de gelir kayb\u0131n\u0131 \u00f6nler.<\/p>\n\u0130leri D\u00fczey Konular ve En \u0130yi Uygulamalar<\/h2>\n
Otonom hata b\u00fct\u00e7esi ge\u00e7idi olu\u015fturmak sadece ara\u00e7lar\u0131 kurmakla bitmez. S\u00fcrekli iyile\u015ftirme ve do\u011fru stratejilerle bu sistemi daha etkili hale getirmek m\u00fcmk\u00fcnd\u00fcr. \u0130\u015fte ileri d\u00fczeyde dikkat edilmesi gereken baz\u0131 noktalar:<\/p>\n
Hizmet Seviyesi Anla\u015fmalar\u0131 (SLA) ve Hedefleri (SLO) Belirleme<\/h3>\n
Hata b\u00fct\u00e7eleri, Hizmet Seviyesi Anla\u015fmalar\u0131 (Service Level Agreements – SLA) ve Hizmet Seviyesi Hedefleri (Service Level Objectives – SLO) ile s\u0131k\u0131 s\u0131k\u0131ya ili\u015fkilidir. SLA, genellikle m\u00fc\u015fteri ile yap\u0131lan s\u00f6zle\u015fmelerde yer alan, hizmetin ne kadar g\u00fcvenilir olmas\u0131 gerekti\u011fini belirten resmi bir taahh\u00fctt\u00fcr. SLO ise, bu SLA’y\u0131 kar\u015f\u0131lamak i\u00e7in i\u00e7sel olarak belirlenen daha spesifik hedeflerdir. Hata b\u00fct\u00e7esi, SLO’lar\u0131 kar\u015f\u0131lamak i\u00e7in harcanan “izin verilen hata” miktar\u0131d\u0131r.<\/p>\n
SLO’lar\u0131 belirlerken ger\u00e7ek\u00e7i olmak \u00f6nemlidir. \u00c7ok iddial\u0131 SLO’lar, s\u00fcrekli hata b\u00fct\u00e7esi t\u00fckenmesine ve geli\u015ftirme h\u0131z\u0131n\u0131n yava\u015flamas\u0131na neden olabilir. Tam tersine, \u00e7ok gev\u015fek SLO’lar ise kullan\u0131c\u0131 deneyimini olumsuz etkileyebilir. Bu dengeyi bulmak i\u00e7in ge\u00e7mi\u015f verilere bakmak, kullan\u0131c\u0131 geri bildirimlerini de\u011ferlendirmek ve i\u015f hedeflerini g\u00f6z \u00f6n\u00fcnde bulundurmak gerekir.<\/p>\n
\u00d6rne\u011fin, bir finansal hizmet i\u00e7in %99.999 kullan\u0131labilirlik SLO’su belirlemek, y\u0131lda yakla\u015f\u0131k 5 dakika kesinti anlam\u0131na gelir. Bu, y\u00fcksek d\u00fczeyde g\u00fcvenilirlik gerektiren durumlar i\u00e7in uygundur. Ancak, bir i\u00e7 ara\u00e7 i\u00e7in %99.5 kullan\u0131labilirlik SLO’su yeterli olabilir.<\/p>\n
Daha Ak\u0131ll\u0131 Uyar\u0131 Mekanizmalar\u0131 ve Otomasyon<\/h3>\n
Sadece hata b\u00fct\u00e7esi t\u00fckenmek \u00fczereyken uyar\u0131 almak yeterli olmayabilir. Daha ak\u0131ll\u0131 uyar\u0131 sistemleri, potansiyel sorunlar\u0131 \u00f6nceden tahmin etmeye yard\u0131mc\u0131 olabilir. \u00d6rne\u011fin, hata b\u00fct\u00e7esi t\u00fcketim h\u0131z\u0131n\u0131n artmas\u0131 durumunda (hata b\u00fct\u00e7esi h\u0131zla t\u00fckeniyorsa), erken uyar\u0131lar g\u00f6nderilebilir. Bu, ekiplere sorunu b\u00fcy\u00fcmeden m\u00fcdahale etme \u015fans\u0131 verir.<\/p>\n
Otomasyon taraf\u0131nda ise, sadece da\u011f\u0131t\u0131m durdurma gibi basit aksiyonlar yerine, daha karma\u015f\u0131k senaryolar\u0131 otomatikle\u015ftirmek m\u00fcmk\u00fcnd\u00fcr. \u00d6rne\u011fin, bir hata b\u00fct\u00e7esi ihlali durumunda, ilgili servis i\u00e7in otomatik olarak daha fazla test \u00e7al\u0131\u015ft\u0131r\u0131labilir veya daha detayl\u0131 log toplama seviyeleri etkinle\u015ftirilebilir. Bu t\u00fcr otomasyonlar, sorunlar\u0131n k\u00f6k nedenini daha h\u0131zl\u0131 bulmaya yard\u0131mc\u0131 olur.<\/p>\n
Hata B\u00fct\u00e7esi K\u00fclt\u00fcr\u00fcn\u00fcn Olu\u015fturulmas\u0131<\/h3>\n
Teknik altyap\u0131 ne kadar g\u00fc\u00e7l\u00fc olursa olsun, bir hata b\u00fct\u00e7esi k\u00fclt\u00fcr\u00fcn\u00fcn olu\u015fturulmas\u0131, bu sistemin ba\u015far\u0131s\u0131 i\u00e7in kritik \u00f6neme sahiptir. Geli\u015ftirme ve operasyon ekiplerinin, hata b\u00fct\u00e7esinin sadece bir metrik olmad\u0131\u011f\u0131n\u0131, ayn\u0131 zamanda g\u00fcvenilirlik ve yenilik\u00e7ilik aras\u0131ndaki dengeyi sa\u011flayan stratejik bir ara\u00e7 oldu\u011funu anlamalar\u0131 gerekir.<\/p>\n
Bu k\u00fclt\u00fcr\u00fc olu\u015fturmak i\u00e7in:<\/p>\n
\n- E\u011fitim:<\/b> Ekiplere hata b\u00fct\u00e7esi kavram\u0131, \u00f6nemi ve nas\u0131l kullan\u0131laca\u011f\u0131 konusunda d\u00fczenli e\u011fitimler verilmelidir.<\/li>\n
- \u015eeffafl\u0131k:<\/b> Hata b\u00fct\u00e7esi durumu ve t\u00fcketimi t\u00fcm ekiplerle a\u00e7\u0131k\u00e7a payla\u015f\u0131lmal\u0131d\u0131r.<\/li>\n
- Sorumluluk:<\/b> Ekiplerin hata b\u00fct\u00e7esi hedeflerine ula\u015fmaktan sorumlu oldu\u011fu hissi yarat\u0131lmal\u0131d\u0131r.<\/li>\n
- \u00d6d\u00fcllendirme:<\/b> G\u00fcvenilirlik hedeflerine ula\u015fan ekipler takdir edilmelidir.<\/li>\n<\/ul>\n
Bu k\u00fclt\u00fcrel de\u011fi\u015fim, teknik \u00e7\u00f6z\u00fcmlerin etkinli\u011fini art\u0131r\u0131r ve t\u00fcm organizasyonun daha g\u00fcvenilir sistemler olu\u015fturmas\u0131na katk\u0131da bulunur.<\/p>\n
Sonu\u00e7<\/h2>\n
SigNoz ve OpenTelemetry gibi g\u00fc\u00e7l\u00fc a\u00e7\u0131k kaynakl\u0131 ara\u00e7larla otonom bir hata b\u00fct\u00e7esi ge\u00e7idi olu\u015fturmak, modern da\u011f\u0131t\u0131k sistemlerde g\u00fcvenilirli\u011fi ve yenilik\u00e7ili\u011fi dengelemek i\u00e7in etkili bir yoldur. Bu makalede, hata b\u00fct\u00e7esi kavram\u0131n\u0131n temelini, neden \u00f6nemli oldu\u011funu, OpenTelemetry ve SigNoz’un bu s\u00fcre\u00e7teki rol\u00fcn\u00fc ve ad\u0131m ad\u0131m nas\u0131l bir hata b\u00fct\u00e7esi ge\u00e7idi olu\u015fturulaca\u011f\u0131n\u0131 inceledik. Kritik SLI’lar\u0131n tan\u0131mlanmas\u0131, telemetri verilerinin toplanmas\u0131, SigNoz’da hesaplama ve g\u00f6rselle\u015ftirme, otomatik uyar\u0131lar ve aksiyon mekanizmalar\u0131n\u0131n kurulmas\u0131 gibi temel ad\u0131mlar\u0131 ele ald\u0131k.<\/p>\n
Unutmamak gerekir ki, hata b\u00fct\u00e7esi sadece teknik bir uygulama de\u011fil, ayn\u0131 zamanda bir k\u00fclt\u00fcrel de\u011fi\u015fim gerektiren bir yakla\u015f\u0131md\u0131r. Ekiplerin g\u00fcvenilirlik ve h\u0131z aras\u0131ndaki dengeyi anlamas\u0131, s\u00fcrekli iyile\u015ftirme i\u00e7in proaktif bir tutum benimsemesi, bu sistemin uzun vadeli ba\u015far\u0131s\u0131 i\u00e7in hayati \u00f6nem ta\u015f\u0131r. SigNoz ve OpenTelemetry, bu yolculukta size rehberlik edecek g\u00fc\u00e7l\u00fc ara\u00e7lard\u0131r. Bu ara\u00e7lar\u0131 kullanarak, sistemlerinizin sa\u011fl\u0131\u011f\u0131n\u0131 daha iyi anlayabilir, hatalar\u0131 proaktif olarak y\u00f6netebilir ve kullan\u0131c\u0131lar\u0131n\u0131za kesintisiz bir deneyim sunabilirsiniz.<\/p>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n\n- Hata b\u00fct\u00e7esi neden \u00f6nemlidir?<\/b> Hata b\u00fct\u00e7esi, sistem g\u00fcvenilirli\u011fi ile yenilik\u00e7ilik aras\u0131nda denge kurar. G\u00fcvenilirli\u011fi sa\u011flarken geli\u015ftirme h\u0131z\u0131n\u0131 yava\u015flatmadan ilerlemeyi m\u00fcmk\u00fcn k\u0131lar.<\/li>\n
- SigNoz ve OpenTelemetry’yi kullanmak zor mu?<\/b> Her iki ara\u00e7 da \u00f6\u011frenme e\u011frisine sahip olsa da, a\u00e7\u0131k kaynak topluluklar\u0131 ve zengin dok\u00fcmantasyonlar\u0131 sayesinde kurulum ve temel yap\u0131land\u0131rma olduk\u00e7a kolayd\u0131r. \u00d6zellikle Docker ile kurulumlar h\u0131zl\u0131ca yap\u0131labilir.<\/li>\n
- Hata b\u00fct\u00e7esi her hizmet i\u00e7in ayn\u0131 olmal\u0131 m\u0131?<\/b> Hay\u0131r, hata b\u00fct\u00e7eleri hizmetin kritiklik seviyesine g\u00f6re farkl\u0131l\u0131k g\u00f6stermelidir. \u00d6deme i\u015flemleri gibi kritik hizmetler i\u00e7in daha d\u00fc\u015f\u00fck hata b\u00fct\u00e7eleri, daha az kritik hizmetler i\u00e7in ise daha y\u00fcksek b\u00fct\u00e7eler tan\u0131mlanabilir.<\/li>\n
- Otonom aksiyonlar ne kadar g\u00fcvenilir?<\/b> Otomasyonun g\u00fcvenilirli\u011fi, do\u011fru yap\u0131land\u0131r\u0131lmas\u0131na ve test edilmesine ba\u011fl\u0131d\u0131r. Ba\u015flang\u0131\u00e7ta basit aksiyonlarla ba\u015flay\u0131p, zamanla daha karma\u015f\u0131k ve g\u00fcvenilir otomasyon senaryolar\u0131na ge\u00e7mek iyi bir stratejidir.<\/li>\n
- Hata b\u00fct\u00e7esi takibi gelirle nas\u0131l ili\u015fkilendirilir?<\/b> Hata b\u00fct\u00e7esi a\u015f\u0131ld\u0131\u011f\u0131nda olu\u015fan kesintiler veya performans d\u00fc\u015f\u00fc\u015fleri do\u011frudan gelir kayb\u0131na neden olabilir. Hata b\u00fct\u00e7esini y\u00f6netmek, bu t\u00fcr gelir kay\u0131plar\u0131n\u0131 \u00f6nlemeye yard\u0131mc\u0131 olur.<\/li>\n<\/ul>\n