Uygulamalarınızın ve altyapınızın sağlığını gerçek zamanlı olarak takip etmek, sorunları proaktif bir şekilde tespit etmek ve hızlıca müdahale etmek mi istiyorsunuz? Bu kapsamlı rehberde, AWS üzerinde Terraform kullanarak nasıl güçlü, ölçeklenebilir ve otomatik bir log izleme ve uyarı sistemi kuracağınızı adım adım keşfedeceğiz. Başlangıçtan ileri seviyeye kadar tüm detayları öğrenin.
Modern yazılım geliştirme ve altyapı yönetimi süreçlerinde, sistemlerin sorunsuz çalışmasını sağlamak en temel önceliklerden biridir. Ancak, karmaşık dağıtık sistemlerde her zaman beklenmedik durumlar ortaya çıkabilir. İşte tam bu noktada loglar, sistemlerin “kara kutusu” haline gelir. Loglar, uygulamanızın veya sunucunuzun her anında ne olup bittiğine dair paha biçilmez bilgiler sağlayan dijital ayak izleridir. Bir hatanın kaynağını bulmaktan, performans darboğazlarını tespit etmeye, hatta güvenlik ihlallerini anlamaya kadar geniş bir yelpazede kritik rol oynarlar.
Peki, bu kadar değerli bilgilere sahip logları sadece toplamak yeterli midir? Kesinlikle hayır. Yüzlerce, binlerce hatta milyonlarca satır log verisi içerisinde manuel olarak gezinmek, iğne aramak gibidir. İşte bu yüzden gerçek zamanlı log izleme ve uyarı sistemleri vazgeçilmezdir. Gerçek zamanlı izleme, potansiyel bir sorun daha kritik hale gelmeden önce anında fark etmenizi sağlar. Örneğin, uygulamanızın belirli bir hata kodu döndürmeye başlaması veya bir sunucunun CPU kullanımının aniden fırlaması gibi durumlar, hızla ele alınmadığında büyük kesintilere yol açabilir. Bir gerçek zamanlı uyarı sistemi sayesinde, bu tür anormallikler belirlenen eşik değerleri aştığında veya belirli bir örüntü tespit edildiğinde ilgili ekiplere otomatik bildirimler gönderilir. Bu, olaylara müdahale süresini (MTTR – Mean Time To Resolution) önemli ölçüde azaltır ve sistemlerinizin daha yüksek kullanılabilirliğe sahip olmasına katkıda bulunur.
Bu makalede, bu kritik ihtiyacı AWS’in güçlü hizmetleriyle nasıl karşılayacağımızı ele alacağız. AWS CloudWatch, log toplama, depolama ve analizinde bize yardımcı olurken, Simple Notification Service (SNS) uyarılarımızı dağıtacak. Tüm bu altyapıyı ise Infrastructure as Code (IaC) felsefesiyle, yani kod aracılığıyla yönetilebilir ve tekrarlanabilir bir şekilde Terraform ile inşa edeceğiz. Terraform’un sağladığı avantajlar sayesinde, bu sistemi farklı ortamlara (geliştirme, test, üretim) kolayca dağıtabilir, versiyonlayabilir ve sürdürebiliriz. Böylece, manuel yapılandırma hatalarını en aza indirerek hem hız hem de güvenilirlik kazanmış olacağız. Hazırsanız, bu heyecan verici yolculuğa çıkalım ve AWS üzerinde gerçek zamanlı log izleme ve uyarı sistemlerinin nasıl kurulduğunu adım adım keşfedelim.
Temel Kavramlar: AWS, Terraform ve Log Mekanizmaları Nelerdir?
Gerçek zamanlı bir log izleme ve uyarı sistemi kurmaya başlamadan önce, projemizin temel yapı taşlarını oluşturan AWS hizmetlerini ve Terraform’un prensiplerini anlamak büyük önem taşır. Bu bölümde, bu kilit teknolojilerin ne işe yaradığını ve neden projemiz için ideal olduklarını detaylandıracağız.
AWS CloudWatch ve CloudTrail’in Gücü Nasıl Kullanılır?
AWS CloudWatch, Amazon Web Services’ın izleme ve gözlem hizmetidir. Log toplama, metrik izleme ve alarm oluşturma yetenekleriyle bilinir. CloudWatch’ı bir sistemin kalp atışlarını izleyen bir elektrokardiyogram (EKG) cihazı gibi düşünebiliriz. Uygulamalarınızdan, altyapınızdan ve diğer AWS hizmetlerinden logları merkezi bir konumda toplar ve depolar. Bu loglar daha sonra analiz edilebilir, filtrelenebilir ve belirli olaylara göre metrikler oluşturulabilir.
- CloudWatch Logs: Uygulama loglarını, işletim sistemi loglarını, AWS Lambda, Amazon ECS gibi servislerin loglarını ve daha fazlasını toplar ve depolar. Loglar, belirli log grupları altında düzenlenir ve her log grubu içerisinde log akışları bulunur. Bu sayede, log verileriniz düzenli bir yapıya kavuşur ve kolayca aranabilir hale gelir. Ayrıca, loglar için belirli bir saklama süresi (retention policy) tanımlayarak depolama maliyetlerini optimize edebilirsiniz.
- CloudWatch Metrics: AWS kaynaklarınızdan otomatik olarak metrikler toplar (CPU kullanımı, disk I/O, ağ trafiği vb.) ve kendi özel metriklerinizi de yayınlamanıza olanak tanır. Örneğin, uygulamanızdaki hata sayısını bir metrik olarak tanımlayabiliriz. Bu metrikler, sisteminizin performansının ve sağlığının sayısal göstergeleridir.
- CloudWatch Alarms: Tanımladığınız metrikler belirli eşik değerlerini aştığında otomatik olarak bildirim gönderen veya eylemler gerçekleştiren mekanizmalardır. Örneğin, bir sunucunun CPU kullanımı %90’ın üzerine çıktığında bir alarm tetikleyebiliriz. Bu alarmlar, sisteminizdeki anormallikleri hızla tespit etmenizi sağlar.
CloudTrail ise, AWS hesabınızdaki API etkinliklerini ve kaynak değişikliklerini kaydeder. Güvenlik denetimi, operasyonel sorun giderme ve uyumluluk için vazgeçilmezdir. CloudTrail, kimin, ne zaman, nerede hangi API çağrısını yaptığını size göstererek, hesabınızdaki tüm hareketliliğin izini sürmenizi sağlar. Örneğin, kritik bir S3 bucket’ın izinsiz değiştirilmesi gibi durumları CloudTrail logları aracılığıyla tespit edebilirsiniz.
Terraform ile Altyapıyı Kod Olarak Yönetmek Neden Önemli?
Infrastructure as Code (IaC), altyapınızı (sunucular, ağlar, veritabanları vb.) kod dosyaları aracılığıyla yönetme ve sağlama pratiğidir. Geleneksel manuel yöntemlerin aksine, IaC altyapı dağıtımını otomatikleştirmeyi, tutarlılığı sağlamayı ve hataları azaltmayı hedefler. Terraform, HashiCorp tarafından geliştirilen açık kaynaklı bir IaC aracıdır. Çok çeşitli bulut sağlayıcılarını (AWS, Azure, GCP gibi) ve diğer platformları desteklemesiyle öne çıkar.
- Deklaratif Yapı: Terraform’da, altyapınızın nihai durumunu tanımlarsınız (örneğin, “bir EC2 örneği ve bir S3 kovası istiyorum”). Terraform, mevcut durumu hedef duruma getirmek için gerekli adımları otomatik olarak belirler ve uygular. Bu, “nasıl yapılacağını” değil, “ne yapılacağını” belirtmeniz anlamına gelir.
- Tekrarlanabilirlik: Kodlanmış altyapı, her zaman aynı şekilde dağıtılabilir. Bu, geliştirme, test ve üretim ortamları arasında tutarlılık sağlar ve “benim makinemde çalışıyor” sorununu ortadan kaldırır.
- Versiyon Kontrolü: Altyapı kodunu Git gibi versiyon kontrol sistemlerinde saklayabilirsiniz. Bu, değişikliklerin izlenmesini, geri alınmasını ve işbirliğini kolaylaştırır.
- Durum Yönetimi (State Management): Terraform, dağıttığı kaynakların mevcut durumunu bir “state” dosyasında (genellikle
terraform.tfstate) tutar. Bu dosya, Terraform’un altyapınızı yönetmek için bir referans noktasıdır. Büyük projelerde bu state dosyasını S3 gibi merkezi ve güvenli bir yerde saklamak önemlidir.
Terraform, AWS kaynaklarımızı tanımlarken, CloudWatch log gruplarından SNS konularına kadar her şeyi kod aracılığıyla oluşturmamızı, güncellememizi ve silmemizi sağlayacak. Bu sayede, karmaşık bir log izleme sistemini birkaç komutla kurabilir ve yönetebiliriz.
Log Kaynaklarından Uyarı Mekanizmalarına Geçiş Nasıl Yapılır?
Bir log izleme sisteminin temel adımları genellikle şu şekildedir: Log Toplama, Log Taşıma, Log Depolama, Log Analizi ve Log Uyarıları. Bu makale kapsamında odaklanacağımız ana akış:
- Log Kaynakları: EC2 örnekleri üzerindeki uygulamalar, AWS Lambda fonksiyonları, ECS/EKS konteynerleri, API Gateway gibi hizmetler log üreten başlıca kaynaklardır. Bu loglar, genellikle CloudWatch Logs’a gönderilir.
- CloudWatch Logs: Toplanan loglar burada merkezi olarak depolanır ve yönetilir.
- CloudWatch Metric Filters: Depolanan loglar içerisinden belirli desenlere (örneğin, “ERROR”, “Failed Login”) göre metrikler oluşturulur. Örneğin, “son 5 dakikada kaç tane ERROR kelimesi geçti?” gibi.
- CloudWatch Alarms: Oluşturulan metrikler belirli bir eşiği aştığında (örneğin, “ERROR sayısı 5 dakikada 10’u geçtiğinde”), bir alarm tetiklenir.
- Amazon SNS (Simple Notification Service): Alarmlar tetiklendiğinde, SNS bir bildirim servisi olarak devreye girer. SNS, bildirimleri çeşitli abonelik uç noktalarına (e-posta, SMS, Lambda fonksiyonları, SQS kuyrukları vb.) dağıtabilir. Bu sayede, alarm durumu ilgili ekiplere anında iletilir.
Bu temel akışı anlayarak, bir sonraki bölümde sistemimizin mimarisini detaylandırabilir ve ardından Terraform ile nasıl kodlayacağımıza geçebiliriz.
Mimari Tasarım: Gerçek Zamanlı Log Akışı Nasıl Kurulur?
Etkili bir gerçek zamanlı log izleme ve uyarı sistemi kurmak için sağlam bir mimari taslağına ihtiyacımız var. Bu bölümde, sistemimizin bileşenlerini ve logların bu bileşenler arasında nasıl akacağını detaylandıracağız. Amacımız, hem ölçeklenebilir hem de maliyet etkin bir çözüm sunmak.
Genel olarak, sistemimiz aşağıdaki adımları takip edecektir:
- Log Üretimi: Uygulamalarımız ve AWS servislerimiz logları oluşturur.
- Log Toplama: Bu loglar merkezi bir log servisine yönlendirilir.
- Log Filtreleme ve Metrik Oluşturma: Toplanan loglar arasından anlamlı veriler çıkarılır ve metrikler halinde işlenir.
- Alarm Tetikleme: Oluşturulan metrikler belirli eşik değerlerini aştığında alarmlar tetiklenir.
- Bildirim Gönderme: Tetiklenen alarmlar, ilgili kullanıcılara veya sistemlere bildirim olarak ulaştırılır.
- Log Arşivleme (İsteğe Bağlı): Uzun vadeli analiz veya uyumluluk için loglar güvenli bir yerde arşivlenir.
Temel Mimari Bileşenleri
Bu akışı desteklemek için AWS üzerinde aşağıdaki ana bileşenleri kullanacağız:
- Log Kaynakları (EC2, Lambda, ECS, vb.): Uygulamalarımızın çalıştığı ve log ürettiği yerlerdir. Örneğin, bir web uygulamasının Apache veya Nginx erişim logları, bir Node.js uygulamasının konsol logları veya bir Python Lambda fonksiyonunun print çıktıları. Bu kaynaklar, CloudWatch Agent veya doğrudan servis entegrasyonları aracılığıyla loglarını CloudWatch Logs’a gönderirler.
- Amazon CloudWatch Logs: Logların toplandığı, depolandığı ve yönetildiği merkezi hizmet. Her bir uygulama veya hizmet için ayrı log grupları oluşturarak düzenli bir yapı sağlayabiliriz. Log grupları, logların yaşam döngüsünü (ne kadar süreyle saklanacağı gibi) yönetmemizi sağlar.
- Amazon CloudWatch Metric Filters: CloudWatch Logs içindeki log akışlarında belirli desenleri (örneğin, “ERROR”, “Exception”, “404 Not Found”) aramak ve bu desenlerin sayısına göre özel metrikler oluşturmak için kullanılır. Örneğin, son 5 dakika içinde kaç tane “ERROR” kelimesinin geçtiğini sayan bir metrik filtre tanımlayabiliriz. Bu filtreler, log verilerini sayısal göstergelere dönüştürerek izlenebilir hale getirir.
- Amazon CloudWatch Alarms: Metric filters tarafından oluşturulan metrikler belirli bir eşik değerini aştığında tetiklenen mekanizmalardır. Örneğin, “ERROR” metriği 5 dakika içinde 5’i geçerse bir alarmı tetikle. Alarmlar, sistem sağlığının otomatik olarak kontrol edilmesini sağlar ve proaktif müdahale için kritik önem taşır.
- Amazon Simple Notification Service (SNS): Bir mesajlaşma hizmetidir. CloudWatch Alarms tarafından tetiklenen bildirimleri (mesajları) alır ve önceden tanımlanmış abonelik uç noktalarına (e-posta adresleri, SMS numaraları, AWS Lambda fonksiyonları, SQS kuyrukları veya HTTP/S uç noktaları) dağıtır. Bu sayede, alarm durumunda ilgili kişilere veya diğer sistemlere anında bildirim gönderilir.
- Log Arşivleme (Amazon S3 – Opsiyonel): Uzun vadeli saklama, büyük veri analizi veya uyumluluk gereksinimleri için CloudWatch Logs’tan logları S3’e aktarabiliriz. Bu işlem genellikle AWS Kinesis Firehose veya bir Lambda fonksiyonu aracılığıyla gerçekleştirilir. S3’te arşivlenen loglar daha sonra Amazon Athena veya Amazon Redshift gibi servislerle analiz edilebilir.
Uzman İpucu: Log gruplarınıza anlamlı ve tutarlı isimler vererek (örneğin, /aws/lambda/MyApp-Prod veya /ec2/WebApp-AccessLogs) yönetim ve filtreleme süreçlerini kolaylaştırın. Ayrıca, log retention policy’lerini dikkatlice ayarlayarak maliyetleri optimize edebilirsiniz.
Gerçek Zamanlı Log Akışı Senaryosu
Hayali bir senaryo düşünelim: Bir e-ticaret uygulamasının arka ucu (backend) bir EC2 örneği üzerinde çalışıyor ve hatalarını /var/log/myapp/error.log dosyasına yazıyor. Bu logları gerçek zamanlı olarak izlemek ve önemli hatalar oluştuğunda anında bildirim almak istiyoruz.
- EC2 örneğindeki uygulamamız bir hata (örneğin, veritabanı bağlantı hatası) üretir ve bu hatayı
/var/log/myapp/error.logdosyasına yazar. - EC2 üzerinde çalışan CloudWatch Agent, bu log dosyasını izler ve yeni log satırlarını
WebApp-Errorsadlı bir CloudWatch Log Group’una gönderir. WebApp-ErrorsLog Group’u içerisinde tanımlanmış bir CloudWatch Metric Filter, “ERROR” kelimesini içeren log satırlarını arar. Her tespit ettiği “ERROR” için bir metrik sayacı artırır.- Bu sayaç, 5 dakikalık bir süre zarfında belirli bir eşiği (örneğin, 3 hatayı) aştığında, CloudWatch Alarm tetiklenir.
- Tetkilenen CloudWatch Alarm,
Application-Error-Alertsadlı bir SNS Topic’ine bir mesaj yayınlar. Application-Error-AlertsSNS Topic’ine abone olan tüm e-posta adresleri (örneğin, operasyon ekibinin e-postası) ve/veya SMS numaraları bu uyarı mesajını alır.
Bu mimari, basit ama güçlü bir gerçek zamanlı izleme döngüsü sağlar. Bir sonraki bölümde, bu mimariyi Terraform kullanarak AWS üzerinde nasıl adım adım hayata geçireceğimizi göstereceğiz. Kod blokları ve detaylı açıklamalarla kendi sisteminizi kurmanız için size rehberlik edeceğiz.
Terraform ile AWS Kaynaklarını Kodlamak: Adım Adım Uygulama
Şimdi teoriden pratiğe geçme zamanı! Bu bölümde, yukarıda tanımladığımız mimariyi Terraform kullanarak AWS üzerinde adım adım nasıl inşa edeceğimizi göreceğiz. Tüm kod örnekleri ve açıklamalar, kendi sisteminizi kolayca kurmanızı sağlayacak.
Temel Terraform Yapılandırması ve Provider Tanımlaması Nasıl Yapılır?
Terraform projemize başlamadan önce, temel bir yapılandırma dosyası oluşturmamız gerekiyor. Bu dosya, Terraform’un hangi bulut sağlayıcısını kullanacağını ve bazı genel ayarları içerecek. Genellikle bu ayarları main.tf veya versions.tf adında bir dosyada tutarız.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0" # AWS provider'ın 5.x versiyonunu kullan
}
}
required_version = "~> 1.0" # Terraform'un 1.x versiyonunu kullan
}
provider "aws" {
region = "eu-central-1" # Kaynakların oluşturulacağı AWS bölgesi (örneğin, Frankfurt)
}
Yukarıdaki kod bloğu:
terraformbloğu: Terraform'un ve AWS sağlayıcısının minimum gerekli versiyonlarını belirtir. Bu, tutarlılık ve uyumluluk için önemlidir.provider "aws"bloğu: Terraform'un AWS ile nasıl iletişim kuracağını tanımlar. Burada kaynaklarımızın hangi AWS bölgesinde (örneğin,eu-central-1- Frankfurt) oluşturulacağını belirtiyoruz.
Bu yapılandırmayı yaptıktan sonra, terminalinizde terraform init komutunu çalıştırarak gerekli AWS sağlayıcısını indirebilirsiniz.
CloudWatch Log Group'ları Oluşturma: Kod Blokları ve Açıklamalar
Loglarımızı toplamak için CloudWatch Log Group'larına ihtiyacımız var. Her bir uygulamanız veya hizmetiniz için ayrı bir log grubu oluşturmak, yönetimi kolaylaştırır.
resource "aws_cloudwatch_log_group" "app_error_logs" {
name = "/my-app/error-logs" # Log grubunun adı
retention_in_days = 30 # Logların saklama süresi (gün olarak)
tags = {
Environment = "Production"
Project = "MyApp"
}
}
resource "aws_cloudwatch_log_group" "app_access_logs" {
name = "/my-app/access-logs"
retention_in_days = 90
tags = {
Environment = "Production"
Project = "MyApp"
}
}
Bu Terraform kodu:
aws_cloudwatch_log_groupkaynağı, CloudWatch'ta bir log grubu oluşturur.name: Log grubunun benzersiz adını belirtir. Uygulama adı ve log tipi kombinasyonları iyi bir isimlendirme stratejisidir.retention_in_days: Logların kaç gün boyunca saklanacağını belirler. 0, logların süresiz saklanacağı anlamına gelir. Bu değer, maliyetleri doğrudan etkilediği için dikkatli seçilmelidir.tags: Kaynaklarınızı kategorize etmek ve maliyet takibi yapmak için faydalıdır.
Log Metrikleri ve Alarm Tanımlamaları: Hata Sayısını İzleme
Şimdi, oluşturduğumuz log grupları içindeki belirli desenleri izleyerek metrikler oluşturacağız ve bu metrikler belirli bir eşiği aştığında tetiklenecek alarmlar tanımlayacağız.
resource "aws_cloudwatch_metric_filter" "error_count_filter" {
name = "ApplicationErrorCount"
log_group_name = aws_cloudwatch_log_group.app_error_logs.name
metric_transformation {
name = "ErrorCount"
namespace = "MyApp/Errors"
value = "1" # Her eşleşen log satırı için metriği 1 artır
default_value = "0"
}
pattern = "[...]*ERROR[...]*" # Log satırında "ERROR" kelimesini ara
}
resource "aws_cloudwatch_metric_alarm" "high_error_alarm" {
alarm_name = "MyApp-HighErrorRate"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = "1" # Tek bir dönem (5 dakika) içinde
metric_name = aws_cloudwatch_metric_filter.error_count_filter.metric_transformation[0].name
namespace = aws_cloudwatch_metric_filter.error_count_filter.metric_transformation[0].namespace
period = "300" # 5 dakika (saniye cinsinden)
statistic = "Sum" # Dönem içindeki hata sayılarının toplamı
threshold = "5" # Eşik değeri: 5 veya daha fazla hata
# Alarm durumunda bildirim gönderilecek SNS konusu
alarm_actions = [aws_sns_topic.app_notifications.arn]
ok_actions = [aws_sns_topic.app_notifications.arn] # Alarm durumu düzeldiğinde de bildirim gönder
actions_enabled = true
}
Bu kod bloğu şunları yapar:
aws_cloudwatch_metric_filter:app_error_logsgrubunda "ERROR" kelimesini içeren log satırlarını arayan bir filtre tanımlar. Her eşleşme içinMyApp/Errorsnamespace'indeErrorCountadında bir metrik oluşturur ve değerini 1 artırır.aws_cloudwatch_metric_alarm:ErrorCountmetriği için bir alarm tanımlar. Eğer 5 dakikalık bir dönemde (300 saniye)ErrorCountdeğeri 5'ten büyükse, alarm tetiklenir.alarm_actionsveok_actions: Alarm tetiklendiğinde veya normale döndüğünde hangi SNS konusuna bildirim gönderileceğini belirtir. Bu sayede, sorunun hem başlangıcında hem de çözüldüğünde haberdar olursunuz.
Bildirim Mekanizması: SNS Konusu ve Abonelikleri Nasıl Oluşturulur?
Alarmlarımızın bildirimlerini alabilmek için bir SNS konusu ve bu konuya abone olacak kişiler veya sistemler tanımlamamız gerekiyor.
resource "aws_sns_topic" "app_notifications" {
name = "MyApp-Alerts-Topic" # SNS konusunun adı
policy = jsonencode({
Version = "2012-10-17"
Id = "__default_policy_ID"
Statement = [
{
Sid = "__default_statement_ID"
Effect = "Allow"
Principal = {
AWS = "*"
}
Action = [
"SNS:Publish",
]
Resource = "arn:aws:sns:eu-central-1:123456789012:MyApp-Alerts-Topic" # Kendi AWS hesabınızın ID'sini ve bölgenizi kullanın
Condition = {
StringEquals = {
"AWS:SourceOwner" = "123456789012" # Kendi AWS hesabınızın ID'sini kullanın
}
}
},
# CloudWatch'un bu SNS konusuna mesaj yayınlamasına izin veren izin
{
Sid = "Allow_CloudWatch_to_Publish"
Effect = "Allow"
Principal = {
Service = "cloudwatch.amazonaws.com"
}
Action = "sns:Publish"
Resource = "arn:aws:sns:eu-central-1:123456789012:MyApp-Alerts-Topic" # Kendi AWS hesabınızın ID'sini ve bölgenizi kullanın
},
]
})
}
resource "aws_sns_topic_subscription" "email_subscription" {
topic_arn = aws_sns_topic.app_notifications.arn
protocol = "email"
endpoint = "devops-team@example.com" # Bildirimlerin gönderileceği e-posta adresi
}
resource "aws_sns_topic_subscription" "sms_subscription" {
topic_arn = aws_sns_topic.app_notifications.arn
protocol = "sms"
endpoint = "+905551234567" # Bildirimlerin gönderileceği telefon numarası
}
Yukarıdaki kod:
aws_sns_topic:MyApp-Alerts-Topicadında yeni bir SNS konusu oluşturur.policybloğu, kimlerin bu konuya mesaj yayınlayabileceğini veya kimlerin bu konuya abone olabileceğini belirleyen IAM politikasıdır. Özellikle CloudWatch'ın bu konuya mesaj yayınlamasına izin veren bir politikaya ihtiyacımız var.aws_sns_topic_subscription: Bu konuya e-posta ve SMS üzerinden abone olan iki farklı uç nokta (endpoint) tanımlar. E-posta aboneliği için belirtilen adrese bir onay e-postası gönderilecektir; aboneliği etkinleştirmek için bu e-postayı onaylamanız gerekmektedir. SMS aboneliği ise genellikle hemen aktif olur.
Uzman İpucu: SNS topic policy'sini yazarken, Resource ARN'lerini ve AWS:SourceOwner kısmını kendi AWS hesabınızın ID'si ve bölgenizle güncellemeyi unutmayın. Güvenlik prensiplerine uygun olarak wildcard (*) kullanımını minimumda tutmaya çalışın.
Bir Vaka Analizi: EC2 Hata Loglarını İzlemek
Tüm bu parçaları bir araya getirerek, bir EC2 örneğindeki uygulama hata loglarını nasıl izleyebileceğimize dair bir senaryoyu özetleyelim:
- EC2 örneği üzerinde AWS CloudWatch Agent'ı kurun ve yapılandırın. Agent, uygulamanızın
/var/log/myapp/error.logdosyasını izleyerek logları, yukarıda oluşturduğumuz/my-app/error-logsCloudWatch Log Group'una gönderecek şekilde yapılandırılmalıdır. - Uygulamanız, kritik bir hata durumunda "ERROR" kelimesini içeren bir log kaydı oluşturduğunda, CloudWatch Agent bunu
/my-app/error-logsgrubuna iletir. ApplicationErrorCountmetrik filtresi bu "ERROR" kelimesini tespit eder veMyApp/Errorsnamespace'indekiErrorCountmetriğini artırır.- Eğer 5 dakika içinde bu hata sayısı 5'i geçerse,
MyApp-HighErrorRatealarmı tetiklenir. - Alarm,
MyApp-Alerts-TopicSNS konusuna bir bildirim yayınlar ve bu konuya abone olandevops-team@example.come-posta adresine ve+905551234567numarasına uyarı mesajı gönderilir.
Bu adımları tamamlamak için Terraform kodunuzu uygulamanız yeterlidir:
terraform plan
terraform apply --auto-approve
Bu komutlar, tanımladığınız tüm AWS kaynaklarını oluşturacak ve gerçek zamanlı log izleme ve uyarı sisteminizi devreye alacaktır. Artık uygulamanızın hataları hakkında anında bilgi sahibi olabilirsiniz.
İleri Düzey Optimizasyonlar ve En İyi Uygulamalar
Temel log izleme ve uyarı sistemini kurduktan sonra, daha karmaşık senaryoları ele almak, sistemi optimize etmek ve güvenliğini artırmak için bazı ileri düzey konulara değinebiliriz. Bu bölüm, sisteminizi daha da geliştirmek için ipuçları ve en iyi uygulamalar sunar.
Log Verilerini Zenginleştirme ve Gelişmiş Analizler (Lambda, Kinesis)
Bazen sadece metrik filtrelemek yeterli olmaz; log verilerini daha derinlemesine analiz etmek veya belirli formatlara dönüştürmek isteyebilirsiniz. İşte burada AWS Lambda ve Kinesis gibi hizmetler devreye girer:
- AWS Lambda ile Özel Log İşleme: CloudWatch Logs, log akışlarını bir Lambda fonksiyonuna tetikleyici olarak gönderme yeteneğine sahiptir. Bu sayede, log verileri üzerinde özel işlemler gerçekleştirebilirsiniz:
- Veri Zenginleştirme: Loglardaki kullanıcı ID'lerini alıp, bir veritabanından kullanıcı bilgilerini çekerek log kaydına ekleyebilirsiniz.
- Format Dönüşümü: Logları farklı bir formata (örneğin, JSON'dan Avro'ya) dönüştürebilirsiniz.
- Gelişmiş Filtreleme: Karmaşık mantık gerektiren filtreleme kurallarını uygulayabilirsiniz.
- Hedefe Yönlendirme: Logları farklı bir depolama alanına (örneğin, Elasticsearch Service) veya başka bir analitik araca gönderebilirsiniz.
resource "aws_lambda_function" "log_processor" { # ... Lambda fonksiyonu tanımı (kod, çalışma zamanı, IAM rolü vb.) ... } resource "aws_cloudwatch_log_subscription_filter" "to_lambda" { name = "SendErrorsToLambda" log_group_name = aws_cloudwatch_log_group.app_error_logs.name destination_arn = aws_lambda_function.log_processor.arn filter_pattern = "[...]*ERROR[...]*" # Sadece hata loglarını Lambda'ya gönder } resource "aws_lambda_permission" "allow_cloudwatch" { statement_id = "AllowExecutionFromCloudWatch" action = "lambda:InvokeFunction" function_name = aws_lambda_function.log_processor.function_name principal = "logs.${data.aws_region.current.name}.amazonaws.com" source_arn = "${aws_cloudwatch_log_group.app_error_logs.arn}:*" }Bu kod,
/my-app/error-logsgrubundaki "ERROR" içeren logları bir Lambda fonksiyonuna yönlendirir. Lambda fonksiyonunun bu logları işleyebilmesi için gerekli izin de tanımlanmıştır. - Amazon Kinesis Firehose ile Log Arşivleme ve Analiz: Daha büyük ölçekli log akışları için Kinesis Firehose, logları S3'e, Redshift'e veya Elasticsearch Service'e güvenilir bir şekilde aktarabilir. Özellikle uzun vadeli analizler (Amazon Athena ile S3 üzerindeki logları sorgulama) ve uyumluluk gereksinimleri için idealdir.
resource "aws_kinesis_firehose_delivery_stream" "s3_archive" { name = "MyApp-LogToS3" destination = "s3" s3_configuration { role_arn = aws_iam_role.firehose_role.arn bucket_arn = aws_s3_bucket.log_archive_bucket.arn prefix = "raw_logs/" error_output_prefix = "error_logs/" buffer_size = 5 # MB buffer_interval = 300 # Saniye } # ... diğer ayarlar ... } resource "aws_cloudwatch_log_destination" "firehose_destination" { name = "MyAppLogFirehoseDestination" target_arn = aws_kinesis_firehose_delivery_stream.s3_archive.arn role_arn = aws_iam_role.log_destination_role.arn }Bu örnek, CloudWatch loglarını Kinesis Firehose üzerinden bir S3 kovasına arşivlemeyi gösterir. Firehose, logları toplu halde S3'e yazar, bu da maliyetleri düşürür ve performansı artırır.
Maliyet Yönetimi ve Güvenlik İpuçları
AWS'te çalışırken maliyetleri ve güvenliği göz ardı etmemek gerekir:
- Log Saklama Süreleri (Retention Policies): Her CloudWatch Log Group için uygun bir
retention_in_daysdeğeri belirleyin. Gereksiz yere uzun süre log saklamak maliyetleri artırabilir. Yalnızca yasal veya operasyonel gereksinimler için ihtiyacınız olan kadarını saklayın ve daha uzun vadeli veriler için S3'e arşivlemeyi düşünün. - IAM Rolleri ve Politikaları: Her AWS servisine yalnızca işini yapması için minimum gerekli izinleri verin (Least Privilege Principle). Örneğin, CloudWatch Agent'ın logları göndermesi için yalnızca
logs:PutLogEventsvelogs:CreateLogStreamizinlerine ihtiyacı vardır. SNS konusunda, CloudWatch'un yayın yapmasına izin veren politikayı doğru yapılandırdığınızdan emin olun. - KMS Şifrelemesi: Hassas log verilerini depoluyorsanız, CloudWatch Log Group'larınızı ve S3 arşiv kovalarınızı AWS Key Management Service (KMS) anahtarlarıyla şifrelemeyi düşünün. Bu, verilerinizin depoda bile korunmasını sağlar.
resource "aws_kms_key" "log_encryption_key" { description = "KMS key for CloudWatch Logs encryption" deletion_window_in_days = 7 policy = <
Çoklu Hesap ve Bölge Stratejileri
Büyük kuruluşlar genellikle birden fazla AWS hesabı ve bölgesi kullanır. Bu durumda log yönetimi daha karmaşık hale gelir:
- Çapraz Hesap Log Agregasyonu: Birden fazla AWS hesabındaki logları merkezi bir güvenlik veya operasyon hesabına toplamak için CloudWatch Log Subscription Filters veya Kinesis Firehose kullanabilirsiniz. Bu, tüm loglarınızın tek bir yerden izlenmesini ve analiz edilmesini sağlar.
- Çoklu Bölge Log İzleme: Uygulamalarınız farklı AWS bölgelerinde dağıtılmışsa, her bölgede benzer bir log izleme altyapısı kurmanız gerekecektir. Terraform modülleri kullanarak bu yapılandırmayı tekrarlamak kolaylaşır. Ana uyarı mekanizmanızı (SNS) merkezi bir bölgede tutabilir ve diğer bölgelerdeki alarmları bu merkezi SNS konusuna yönlendirebilirsiniz.
Uzman İpucu: Terraform modüllerini kullanarak log izleme altyapınızın bileşenlerini (log grubu, metrik filtre, alarm, SNS konusu) tekrar kullanılabilir birimler halinde paketleyin. Bu, birden fazla uygulama veya ortam için kolayca dağıtım yapmanızı sağlar ve "boilerplate" kodu azaltır.
Bu ileri düzey optimizasyonlar ve en iyi uygulamalar, log izleme sisteminizi daha sağlam, güvenli, ölçeklenebilir ve maliyet etkin hale getirecektir. Unutmayın, iyi bir izleme sistemi sadece sorunları tespit etmekle kalmaz, aynı zamanda sistemlerinizin genel sağlığını ve performansını anlamanıza da yardımcı olur.
Sonuç: Güvenilir Log Yönetiminin Önemi ve Geleceği
Bu makale boyunca, AWS üzerinde Terraform kullanarak gerçek zamanlı bir log izleme ve uyarı sisteminin nasıl kurulacağını detaylı bir şekilde inceledik. Log yönetiminin temel prensiplerinden başlayarak, AWS CloudWatch, SNS ve Terraform gibi kilit hizmetlerin ne işe yaradığını öğrendik. Ardından, mimari tasarımını anladık ve adım adım kod örnekleriyle kendi sistemimizi nasıl inşa edebileceğimizi gördük. Son olarak, sistemimizi daha da optimize etmek, güvenliğini artırmak ve ileri düzey senaryoları ele almak için pratik ipuçlarını paylaştık.
Modern DevOps ve bulut ortamlarında, log yönetimi sadece bir "gereklilik" olmaktan çıkıp, uygulamaların ve altyapının proaktif olarak yönetilmesi için vazgeçilmez bir araç haline gelmiştir. Gerçek zamanlı uyarılar sayesinde, potansiyel sorunlara hızlıca müdahale edebilir, kesinti sürelerini minimize edebilir ve kullanıcı deneyimini iyileştirebiliriz. Terraform'un altyapıyı kod olarak yönetme yaklaşımı ise, bu sistemleri güvenilir, tekrarlanabilir ve ölçeklenebilir bir şekilde kurmamıza olanak tanır. Manuel hataları ortadan kaldırır ve ekiplerin altyapı yönetimine harcadığı zamanı azaltır, böylece daha çok inovasyona odaklanabilirler.
Unutmamak gerekir ki, teknoloji dünyası sürekli gelişiyor. Log yönetiminde de yapay zeka ve makine öğrenimi destekli anomali tespiti gibi yeni yaklaşımlar giderek daha fazla önem kazanmaktadır. Bu sistemler, önceden tanımlanmış eşiklerin ötesine geçerek, log verilerindeki beklenmedik desenleri otomatik olarak öğrenir ve sizi potansiyel sorunlar hakkında uyarır. AWS'in CloudWatch Anomaly Detection gibi özellikleri bu alanda bize yardımcı olabilir.
Özetle, güçlü bir log izleme ve uyarı sistemi kurmak, dijital varlıklarınızın güvenliğini, performansını ve sürekliliğini sağlamanın temelidir. Bu rehberde edindiğiniz bilgilerle, siz de AWS ve Terraform'un gücünü birleştirerek kendi güvenilir izleme altyapınızı kurabilir ve yönetebilirsiniz. Gelecekte, log verilerinizi daha derinlemesine analiz ederek operasyonel zekayı artırmaya ve daha akıllı, daha dirençli sistemler inşa etmeye devam edeceksiniz.
Sıkça Sorulan Sorular (SSS)
1. Terraform ile oluşturulan AWS kaynaklarını nasıl silebilirim?
Terraform ile oluşturduğunuz tüm kaynakları temizlemek için projenizin kök dizininde terraform destroy komutunu çalıştırabilirsiniz. Bu komut, Terraform state dosyasında izlenen tüm kaynakları AWS'ten kaldıracaktır. İşlem öncesinde bir önizleme (plan) isteyecektir ve onayınızı bekleyecektir.
2. CloudWatch Agent'ı EC2 örneğine nasıl kurup yapılandırabilirim?
CloudWatch Agent'ı EC2'ye kurmak için AWS belgelerindeki talimatları izlemeniz gerekir. Genellikle amazon-cloudwatch-agent paketini yükler, ardından bir yapılandırma dosyası (config.json) oluşturursunuz. Bu dosya, hangi log dosyalarının hangi CloudWatch Log Group'una gönderileceğini belirtir. Ardından sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -s komutu ile agent'ı başlatırsınız. Agent'ın logları göndermesi için gerekli IAM izinlerine sahip bir rolün EC2 örneğine atanmış olması gerektiğini unutmayın.
3. SNS e-posta aboneliğim neden onay bekliyor?
SNS, e-posta abonelikleri için güvenlik amacıyla bir onay adımı gerektirir. Terraform ile aboneliği oluşturduğunuzda, belirtilen e-posta adresine bir onay e-postası gönderilir. Aboneliğin aktif hale gelmesi ve bildirimleri alabilmeniz için bu e-postadaki onay bağlantısına tıklamanız gerekmektedir. Bu, istenmeyen e-posta alıcılarına bildirim gitmesini engeller.
4. Log izleme sisteminin maliyetini nasıl optimize edebilirim?
Maliyet optimizasyonu için birkaç anahtar nokta vardır:
- Log Saklama Süreleri (Retention): CloudWatch Log Group'ları için
retention_in_daysdeğerini dikkatlice belirleyin. Sadece gerekli süre boyunca logları saklayın. - Gereksiz Logları Filtreleme: Yalnızca önemli ve eyleme dönüştürülebilir logları CloudWatch Logs'a gönderin veya gereksiz logları filtrelemek için CloudWatch Agent'ın yapılandırma dosyasını kullanın.
- S3'e Arşivleme: Uzun vadeli veya arşivleme amaçlı loglar için CloudWatch Logs'tan daha ucuz olan S3'e taşıma ve daha sonra Athena ile sorgulama yöntemlerini kullanın.
- Metrik Filtre ve Alarm Sayısı: Yalnızca gerçekten ihtiyacınız olan metrik filtreleri ve alarmları oluşturun. Çok fazla metrik ve alarm, maliyeti artırabilir.
5. Terraform state dosyasını güvenli bir şekilde nasıl yönetebilirim?
Terraform state dosyası (terraform.tfstate), AWS'te oluşturduğunuz tüm kaynakların bir haritasını içerir ve hassas bilgiler içerebilir. Bu dosyayı yerel diskinizde bırakmak yerine, merkezi ve güvenli bir yerde saklamanız şiddetle tavsiye edilir. Genellikle Amazon S3 kovası ve Amazon DynamoDB (kilitlenme için) birlikte kullanılır. Bu yapılandırmayı backend bloğunda tanımlayabilirsiniz:
terraform {
backend "s3" {
bucket = "my-terraform-state-bucket-12345" # Kendi benzersiz kova adınızı kullanın
key = "path/to/my-app/terraform.tfstate"
region = "eu-central-1"
encrypt = true
dynamodb_table = "terraform-lock-table" # Terraform state kilitlemesi için
}
}
Bu şekilde, state dosyanız şifrelenmiş olarak S3'te saklanır ve takım üyeleri arasında güvenli bir şekilde paylaşılabilir.