Log Aggregation
Bir uygulamanın birden çok servisten oluştuğu bir kullanım örneği düşünün. İstekler genellikle birden çok servis örneğini(instance) kapsar.
Her servis, standartlaştırılmış bir biçimde bir günlük(log) dosyası oluşturur. Her servisin günlükleri toplayan merkezi bir günlük(centralized logging) kaydı servisine ihtiyacımız var. Kullanıcılar günlükleri arayabilir ve analiz edebilir. Günlüklerde belirli mesajlar göründüğünde tetiklenen uyarıları yapılandırabilirler.
Örneğin, AWS Cloud Watch veya Elasticsearch-Kibana bu amaç için kullanılabilir.
Performance Metrics
Bir mikro servis mimarisi nedeniyle servis portföyü arttığında, işlemlerin izlenmesi kritik hale gelir, böylece belirli kalıplar-yapılar izlenebilir ve bir sorun olduğunda uyarılar gönderilebilir.
Tek tek işlemlerle ilgili istatistikleri toplamak için bir ölçüm hizmeti gereklidir. Raporlama ve uyarı sağlayan bir uygulama servisinin metriklerini toplamalıdır. Metrikleri toplamak için iki model vardır:
- Push — Servis, metrikleri metrik servisine aktarır, ör. NewRelic, AppDynamics (APM)
- Pull — metrik servisleri, servisten metrikleri alır, ör. Prometheus
Distributed Tracing
Bir mikro servis mimarisinde, istekler genellikle birden çok servisi kapsar. Her servis, birden çok serviste bir veya daha fazla işlem gerçekleştirerek bir isteği yerine getirir. Sorun gidermede bir isteği uçtan uca izleyebilir olmak önemlidir.
Çözüm, bir işlem kimliği(Request ID) tanıtmaktır. Aşağıdaki yaklaşımlar kullanılabilir;
- Her harici talebe(request) benzersiz bir harici istek kimliği(Unique Request ID) atar.
- Harici istek kimliğini tüm servislere aktarır.
- Tüm günlük mesajları(log) harici istek kimliğini içerir.
Health Check
Mikro servis mimarisi uygulandığında, bir servisin işlem yapamama ihtimali vardır. Her servisin, health check gibi uygulamanın sağlığını kontrol etmek için kullanılabilecek bir uç noktasına sahip olması gerekir.
Bu API, sunucu durumunu, diğer servislere / altyapıya olan bağlantıyı ve herhangi bir belirli mantığı(logic) kontrol etmelidir.
