Etkinliği izleme ve izleme

Tamamlandı

Veritabanlarını korumanın büyük bir kısmı performans ayarlamadır. Şirket içi veritabanlarınızda gözden geçirmek için kullandığınız günlük dosyaları MySQL için Azure Veritabanı/PostgreSQL ile kullanılabilir.

Veritabanlarınız Azure'a geçirildiğinde, veritabanlarının performansının korundığından emin olmak için günlük dosyalarını gözden geçirmeye devam etmeniz gerekir.

Bu ünitede PostgreSQL ve MySQL günlük dosyalarının Azure'da nerede depolandığını ve bunların içerdiği ayrıntı düzeyini göreceksiniz.

Veritabanı etkinliğini izlemek için sunucu günlüklerini kullanma

MySQL için Azure Veritabanı/PostgreSQL ayrıca tanılama bilgilerini sunucu günlüklerine kaydeder. Sunucu günlükleri, MySQL ve PostgreSQL için yerel ileti günlüğü dosyalarıdır (MySQL için Azure Veritabanı/PostgreSQL'de erişilemeyen işlem günlüğü dosyaları değildir). Bu dosyalar, veritabanlarınızla ilgili sorunlarda hata ayıklamak için kullandığınız iletileri, sunucu durumunu ve diğer hata bilgilerini içerir. Sunucu günlükleri yedi güne kadar saklanır (sunucu günlük dosyalarının toplam boyutu 7 GB'ı aşarsa daha az).

MySQL için Azure Veritabanı ve PostgreSQL için Azure Veritabanı sunucu günlüklerine farklı ayrıntılar kaydeder. Aşağıdaki bölümlerde her hizmet için sunucu günlükleri ayrı ayrı açıklanmaktadır.

MySQL için Azure Veritabanı'da sunucu günlükleri

MySQL için Azure Veritabanı'de sunucu günlüğü, yavaş sorgu günlüğünde ve MySQL sunucusundaki denetim günlüğünde normalde kullanılabilir olan bilgileri sağlar.

Yavaş çalışan sorguları tanımlamaya yardımcı olması için yavaş sorgu günlüğündeki bilgileri kullanırsınız. Varsayılan olarak, yavaş sorgu günlüğü devre dışı bırakılır. slow_query_log sunucu parametresini ON olarak ayarlayarak etkinleştirebilirsiniz. Aşağıdaki sunucu parametrelerini kullanarak yavaş sorgunun ne anlama geldiğini belirlemek için yavaş sorgu günlüğünü yapılandırabilirsiniz:

  • log_queries_not_using_indexes. Bu parametre ON veya OFF şeklindedir. Dizin araması yerine tam tablo taraması gerçekleştirme olasılığı olan tüm sorguları kaydetmek için ON olarak ayarlayın.
  • log_throttle_queries_not_using_indexes. Dakikada günlüğe kaydedilebilecek dizinleri kullanmayan en fazla yavaş sorgu sayısını belirtir.
  • log_slow_admin_queries. Günlükte yavaş çalışan yönetim sorgularını dahil etmek için bu parametreyi ON olarak ayarlayın.
  • long_query_time. Sorgunun yavaş çalışıyor olarak kabul edilmesi için eşik (saniye olarak).

Yavaş sorgu günlüğünü ve denetim günlüğünü etkinleştirdikten sonra, günlük dosyaları sunucunun Sunucu günlükleri sayfasında görünmeye başlar. Her gün yeni bir yavaş sorgu günlüğü oluşturulur. İndirmek için bir günlük dosyasına tıklayın:

Image of the Server logs page for Azure Database for MySQL.

Denetim günlüğünü etkinleştirmek için audit_log_enabled sunucu parametresini ON olarak ayarlayın. Denetim günlüğünü aşağıdaki parametrelerle yapılandırabilirsiniz:

  • audit_log_events. Denetlenecek olayları belirtin. Azure portalında bu parametre CONNECTION, DDL, DML, ADMIN ve diğerleri gibi olayların açılan listesini sağlar.
  • audit_log_exclude_users. Bu parametre, etkinlikleri denetim günlüğüne eklenmeyecek kullanıcıların virgülle ayrılmış bir listesidir.

Yavaş sorgu günlüğünü ve denetim günlüğünü yedi günden uzun süre korumanız gerekiyorsa, bunların Azure depolamaya aktarılmasını düzenlersiniz. Sunucunuz için Tanılama ayarları sayfasını kullanın ve + Tanılama ayarı ekle'yi seçin. Tanılama ayarları sayfasında Depolama hesabına arşivle'yi seçin, günlük dosyalarının kaydedildiği bir depolama hesabı seçin (bu depolama hesabı zaten mevcut olmalıdır), MySqlSlowLogs ve MySqlAuditLogs'ı seçin ve 365 güne kadar bir saklama süresi belirtin. Günlük dosyalarını bu süre boyunca herhangi bir noktada Azure depolamadan indirebilirsiniz. Kaydet'i seçin:

Image of the Diagnostic settings page for Azure Database for MySQL.

Yavaş sorgu günlüğü verileri JSON biçiminde insights-logs-mysqlslowlogs adlı bir kapsayıcıdaki bloblara yazılır. Günlük dosyalarının Azure depolamada görünmesi 10 dakika kadar sürebilir. Denetim kayıtları yine JSON biçiminde insights-logs-mysqlslowlogs blob kapsayıcısında depolanır.

PostgreSQL için Azure Veritabanı'da sunucu günlükleri

PostgreSQL için Azure Veritabanı sunucu günlüğü hata günlüğü ve sorgu günlüğü dosyalarını içerir. Hataların ve verimsiz sorguların kaynaklarını bulmanıza yardımcı olması için bu dosyalardaki bilgileri kullanın.

Çeşitli log_ sunucu yapılandırma parametrelerini ON olarak ayarlayarak günlüğe kaydetmeyi etkinleştirirsiniz. Bu parametreler şunlardır:

  • log_checkpoints. Her veri dosyası işlem günlüğündeki en son bilgilerle güncelleştirildiğinde bir denetim noktası oluşur. Bir sunucu hatası varsa, bu nokta işlem günlüğünden ileri doğru ilerleyerek kurtarmanın başlama zamanını işaretler.
  • log_connection ve log_disconnections. Bu ayarlar her başarılı bağlantıyı ve her oturumun sonunu kaydeder.
  • log_duration. Bu ayar, tamamlanan her SQL deyiminin süresinin kaydedilmesine neden olur.
  • log_lock_waits. Bu ayar kilit bekleme olaylarının kaydedilmesine neden olur. Kilit beklemeleri, uygulama kodunda kötü uygulanan işlemlerden kaynaklanabilir.
  • log_statement_stats. Bu ayar, sunucunun performansı hakkındaki toplu bilgileri günlüğe yazar.

PostgreSQL için Azure Veritabanı ayrıca kaydedilen bilgilere ince ayar yapmak için başka parametreler de sağlar:

  • log_error_verbosity. Bu ayar, günlüğe kaydedilen her ileti için kaydedilen ayrıntı düzeyini belirtir.
  • log_retention_days. Bu, sunucunun günlük dosyalarını kaldırmadan önce tuttuğu gün sayısıdır. Varsayılan değer üç gündür ve en fazla yedi gün olarak ayarlayabilirsiniz.
  • log_min_messages ve log_min_error_statement. Kayıt deyimleri için uyarı ve hata düzeylerini belirtmek için bu parametreleri kullanın.

MySQL için Azure Veritabanı gibi, PostgreSQL için Azure Veritabanı tarafından oluşturulan günlük dosyaları Sunucu günlükleri sayfasında bulunur. Günlükleri Azure depolamaya kopyalamak için Tanılama ayarları sayfasını da kullanabilirsiniz.

Sorgu performansını izleme

Sorgu Deposu, Kötü çalışan sorguları belirlemenize ve izlemenize yardımcı olmak için Azure tarafından sağlanan ek bir özelliktir. bunu MySQL için Azure Veritabanı ve PostgreSQL için Azure Veritabanı ile kullanırsınız.

Sorgu performansı izlemeyi etkinleştirme

Sorgu Deposu bilgileri MySQL için Azure Veritabanı'daki mysql şemasına ve PostgreSQL için Azure Veritabanı'daki azure_sys adlı bir veritabanına kaydeder. Sorgu Deposu, sorgu yürütme hakkındaki veriler ve bekleme istatistikleriyle ilgili bilgiler olmak üzere iki tür bilgi yakalayabilir. Sorgu Deposu varsayılan olarak devre dışıdır. Bunu etkinleştirmek için:

  • MySQL için Azure Veritabanı kullanıyorsanız query_store_capture_mode ve query_store_wait_sampling_capture_mode sunucu parametrelerini ALL olarak ayarlayın.
  • PostgreSQL için Azure Veritabanı kullanıyorsanız, pg_qs.query_capture_modesunucu parametresini ALL veya TOP olarak ayarlayın ve pgms_wait_sampling.query_capture_mode parametresini ALL olarak ayarlayın.

Sorgu performansı verilerini analiz etme

Sorgu Deposu tarafından kullanılan tabloları doğrudan sorgulayabilirsiniz. MySQL için Azure Veritabanı çalıştırıyorsanız sunucunuza bağlanın ve aşağıdaki sorguları çalıştırın:

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

PostgreSQL için Azure Veritabanı kullanıyorsanız bunun yerine aşağıdaki sorguları çalıştırın:

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

Her iki durumda da ilk sorgu, son çalıştırılacak her sorgunun metnini ve sorgunun derlenip yürütülmesinin ne kadar sürdüğünü gösteren bir dizi istatistik görüntüler. İkinci sorguda bekleme olaylarıyla ilgili bilgiler görüntülenir. Bir sorgunun çalıştırılması engellendiğinde bir bekleme olayı oluşur çünkü başka bir sorgu tarafından tutulan kaynaklar gerekir.

Sorgu Deposu'nı doğrudan incelerseniz, kendi özel raporlarınızı oluşturabilir ve sistemin nasıl çalıştığını ayrıntılı bir şekilde kavrayabilirsiniz. Ancak, kullanılabilir veri miktarı neler olduğunu anlamayı zorlaştırabilir. MySQL için Azure Veritabanı/PostgreSQL, bu verilerde gezinmenize yardımcı olacak iki ek araç sağlar:Sorgu Performansı İçgörüleri ve Sorgu Öneriler.

Sorgu Performansı İçgörüleri, sunucunuzun Sorgu Performansı İçgörüleri sayfasında bulunan bir grafik yardımcı programdır. Uzun süre çalışan sorgular sekmesi, en uzun süre çalışan sorguların istatistiklerini görüntüler. Zaman aralığını belirtir ve birkaç dakika içinde yakınlaştırabilirsiniz. Göstergede, her sorgunun metni, sorgunun çalıştırıldığı süre ve sayı ile birlikte gösterilir. Grafik, her sorgunun süresine ilişkin karşılaştırmalı bir görünüm sağlar. Verileri her sorgu için ortalama süreye göre görüntülersiniz, ancak her sorgu için toplam süreyi (süre * yürütme sayısı) görüntülemek de öğreticidir. Aşağıdaki resimde bir örnek gösterilmektedir:

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Long running queries tab.

Bekleme İstatistikleri sekmesi her sorgu için bekleme olayı bilgilerini gösterir. Çeşitli kaynakları bekleyen bir sorgunun harcadığı süreyi görürsünüz.

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Wait statistics tab.

Bekleme olayları genellikle üç kategoriye ayrılır:

  • Beklemeleri kilitle. Bu olaylar, bir sorgu başka bir sorgu tarafından kilitlenen verileri okumaya veya değiştirmeye çalışırsa oluşur. Çok fazla sayıda kilit beklemesi yaşarsanız, uzun süre çalışan işlemleri veya son derece kısıtlayıcı yalıtım düzeyi kullanan işlemleri denetleyin.
  • GÇ beklemeleri. Bu tür bir bekleme, bir sorgu önemli miktarda GÇ gerçekleştiriyorsa oluşur. Bunun nedeni kötü tasarlanmış bir sorgu (WHERE yan tümcesini denetleme), verimsiz birleştirme işlemi veya eksik dizin nedeniyle tahakkuk eden tam tablo taraması olabilir.
  • Bellek beklemeleri. Bir sorguyu işlemek için yeterli bellek yoksa bellek beklemesi oluşur. Sorgunuz büyük miktarda veri okumaya çalışıyor olabilir veya belleğin tıkandığı diğer sorgular tarafından engellenebilir. Bu da dizinlerin eksik olduğunu ve sorguların tabloların tamamını belleğe okumasına neden olduğunu gösterebilir.

Ayrıca, bir bekleme biçiminin başka bir bekleme biçimini tetikleme olasılığı da yüksektir, bu nedenle bu sorunları yalıtarak inceleyemezsiniz. Örneğin, farklı tablolardaki verileri okuyan ve güncelleştiren bir işlem bellek beklemesine tabi olabilir. Buna karşılık, bu işlem başka bir işlemin kilit beklemesine neden olan verileri kilitlemiş olabilir.

Sunucunun Performans Öneriler sayfası Sorgu Deposu'nda tutulan bilgileri alır ve karşılaştığı iş yükleri için veritabanınızı ayarlama önerilerinde bulunmak üzere kullanır.