Dayanıklılığı Artırmak İçin Gözlemlenebilirlik İnşası

<div class="toc">
    <h3>İçindekiler</h3>
    <ul>
        <li><a href="#sorunlari-teshis-etme">Sorunları Teşhis Etme</a></li>
        <li><a href="#gizli-sorunlari-ortaya-cikarma">Gizli Sorunları Ortaya Çıkarma</a></li>
        <li><a href="#gelecekteki-sorunlari-onleme">Gelecekteki Sorunları Önleme</a></li>
        <li><a href="#adim-adim-kilavuz">Adım Adım: İstemci Tarafı Anomalilerini Tespit Etme</a></li>
        <li><a href="#sss">Sıkça Sorulan Sorular</a></li>
    </ul>
</div>

<p>Sistemlerinize gözlemlenebilirlik (observability) kazandırmak, sadece log toplamak değildir; uygulamalarınızı dayanıklı hale getirmek için gereken içgörüleri kazanmaktır. Yakın tarihli bir re:Invent konuşmasında David Yanacek, sorunları hızla tespit edip çözmede gözlemlenebilirliğin önemini vurguladı.</p>

<h2 id="sorunlari-teshis-etme">Sorunları Teşhis Etme</h2>
<p>Sistemler başarısız olduğunda ilk hedef teşhistir. Sorunları etkili bir şekilde teşhis etmek, dört ana alana bakmayı gerektirir:</p>
<ul>
    <li><strong>Kötü Bağımlılıklar:</strong> Tüm yığınızdaki hataları izlemek için Bileşik Alarmlar (Composite Alarms) kullanın.</li>
    <li><strong>Kötü Bileşenler:</strong> Etkileşimleri görselleştirmek ve hatalı bileşenleri belirlemek için Hizmet Haritalarından (AWS X-Ray gibi) yararlanın.</li>
    <li><strong>Kötü Dağıtımlar:</strong> Hızlı geri alma (rollback) işlemlerini sağlamak için bir sürümden hemen sonraki anomalileri tespit edin.</li>
    <li><strong>Trafik Artışları:</strong> Ani artışın meşru bir trafik mi yoksa DDoS saldırısı mı olduğunu anlamak için ayrıntılı metrikleri analiz edin.</li>
</ul>

<h2 id="gizli-sorunlari-ortaya-cikarma">Gizli Sorunları Ortaya Çıkarma</h2>
<p>Bazı sorunlar sessiz katillerdir. Standart 5xx alarmlarını tetiklemezler ancak kullanıcı deneyimini önemli ölçüde etkilerler.</p>

<h3>RUM ve Sentetik İzleme (Synthetic Monitoring)</h3>
<p><strong>Gerçek Kullanıcı İzleme (RUM)</strong>, deneyimi doğrudan kullanıcının tarayıcısından ölçer. Ancak trafiğiniz düşerse (örneğin bir DNS kesintisi sırasında), RUM sessizleşir.</p>
<p><strong>Sentetik İzleme</strong>, kullanıcı etkileşimlerini sürekli olarak simüle etmek için otomatik komut dosyaları (Canaries) kullanır, böylece gerçek trafik düşük olduğunda bile görünürlüğe sahip olursunuz.</p>

<h3>İstemci Tarafı ve Sunucu Tarafı Hataları</h3>
<p>Bir dağıtımın (deployment) bir giriş alanının karakter sınırını düşürdüğü bir senaryoyu düşünün. Bu, sunucu tarafı (5xx) alarmlarının kaçırabileceği bir istemci tarafı (4xx) hata artışına neden olabilir. Bunu yakalamak için sadece ham hata sayısını değil, <em>hata yaşayan istemcilerin oranını</em> izlemeniz gerekir.</p>

<h2 id="gelecekteki-sorunlari-onleme">Gelecekteki Sorunları Önleme</h2>
<p>Dayanıklılık hazırlıkla ilgilidir.</p>
<ul>
    <li><strong>Esneklik (Elasticity):</strong> Otomatik Ölçeklendirmeyi (Auto Scaling) yönlendirmek için CPU, Bellek ve İş Parçacığı Havuzları (Thread Pools) genelinde kullanımı ölçün.</li>
    <li><strong>Oyun Günleri (Game Days):</strong> Gözlemlenebilirlik araçlarınızın beklendiği gibi çalıştığını doğrulamak için üretim ortamında (kontrollü bir şekilde) düzenli olarak arıza simülasyonları yapın.</li>
</ul>

<h2 id="adim-adim-kilavuz">Adım Adım: İstemci Tarafı Anomalilerini Tespit Etme</h2>
<p>Bir dağıtımın istemci tarafı hatalarında bir artışa neden olup olmadığını tespit etmek için CloudWatch Contributor Insights kullanabilirsiniz. İşte etkilenen müşterilerin oranını izlemek için bir kuralı nasıl tanımlayabileceğiniz.</p>

<p><strong>Senaryo:</strong> Belirli bir istemci kimliğinin (client ID) orantısız sayıda 4xx hatası üretip üretmediğini bilmek istiyorsunuz.</p>

<pre><code>{
"Schema": {
    "Name": "CloudWatchLogRule",
    "Version": 1
},
"LogGroupNames": ["/aws/lambda/my-app-logs"],
"LogFormat": "JSON",
"Contribution": {
    "Keys": ["$.clientId"],
    "ValueOf": "$.requestId",
    "Filters": [
        {
            "Match": "$.status",
            "In": [400, 401, 403, 404]
        }
    ]
},
"AggregateOn": "Count"

}</code></pre>

<p>Bu Contributor Insights JSON kuralı, istekleri <code>clientId</code> bazında gruplayarak 4xx durum kodlarına sahip olanları sayar. Bu, tek bir kullanıcının hatalı istekler göndermesi ile herkesi etkileyen sistemsel bir sorunu ayırt etmenize yardımcı olur.</p>

<h2 id="sss">Sıkça Sorulan Sorular</h2>
<h3>İzleme (Monitoring) ve Gözlemlenebilirlik (Observability) arasındaki fark nedir?</h3>
<p>İzleme size sistemin sağlıklı olup olmadığını söyler. Gözlemlenebilirlik, sistemin <em>neden</em> sağlıklı olmadığını anlamak için keyfi sorular sormanıza olanak tanır.</p>

<h3>RUM varken neden Sentetik İzlemeye ihtiyacım var?</h3>
<p>Sentetik İzleme, gerçek kullanıcı trafiği olmadığında bile performans ve kullanılabilirlik için bir temel sağlar, böylece düşük trafikli dönemlerde sorunları yakalayabilirsiniz.</p>

<h3>"Bilinmeyen bilinmeyenleri" (unknown unknowns) nasıl tespit edebilirim?</h3>
<p>Yüksek kardinaliteli veriler toplayarak ve CloudWatch Contributor Insights gibi araçları kullanarak, açıkça alarm kurmadığınız anomalileri bulmak için verileri dilimleyip inceleyebilirsiniz.</p>

<p>AWS üzerinde dayanıklı sistemler inşa etmek hakkında daha fazla bilgi için <a href="/tech/aws-consultancy">AWS Danışmanlık hizmetlerimizi</a> inceleyebilir veya <a href="/tech/kubernetes-consultancy">Kubernetes çözümlerimize</a> göz atabilirsiniz. Kapsamlı bulut çözümlerimiz hakkında daha fazla bilgi almak için <a href="/">ana sayfamızı</a> ziyaret edin.</p>

<p>Kaynak / Source: <a href="https://awsfundamentals.com/blog/building-observability-to-increase-resiliency" target="_blank" rel="noopener noreferrer">https://awsfundamentals.com/blog/building-observability-to-increase-resiliency</a></p>