Metriklerin efendisi Prometheus! – Episode 1 – Doğuş ve Mimari

Prometheus, son zamanlarda gezindiğim makalelerde adını sık sık duyduğum, benim de mimarisini çok merak ettiğim, ismine “Next generation monitoring system” ünvanı yakıştırılan, ufacık bir projeden tutun da büyük ölçekli mimarilerde bile rahatlıkla kullanılabilen bir ekosistem. Evet, “ekosistem” diyorum çünkü bu yazılımlar bütününe basitçe bir “monitoring tool” demek oldukça yüzeysel bir tanım olur, hatta ayıp bile olur düşüncesindeyim.

Bu hafta sonu, biraz fırsat bulmuşken, yine birkaç saat verimli bir şeyler yapmak adına bu sistemi incelemeye karar verdim. Yine spontane olarak, öncesinde bilgilenip bu bilgilerin de kendimce Türkçe çevirilerini yapıp, yorumlayıp, kaynaklardan aktara aktara makaleyi şekillendirmek istiyorum. Kullanılan kaynaklar yine konuya hakim kişilerin çeşitli sunumlarda kullanılan pdf’ler, alıntılamaya değer makaleler şeklinde olacak. Biraz Stalking yapmanın kimseye zararı olmaz sanırım 🙂 Galiba yine uzunca bir yazı olacağa benziyor. Tedbirinizi alınız. 

Konu ile ilgili birçok net ve yalın tanımlar orada olduğundan -Sansürlü olmasına rağmen- Wikipedia’ya linkler vereceğim; bu nedenle direkt erişilemeyen linkler için üzgünüm.

Makalede bol bol Soundcloud firmasına atıfta bulunacağım çünkü Prometheus‘un doğduğu topraklar orası. 🙂 Hatta birazcık da şirketin genel Infrastructure durumuna derinleşebilirim. Belki bir gün firmayı sadece Monitoring odaklı değil, komple Monolitik mimariden Mikroservis mimarisine geçiş sonrası yaptıkları paylaşımlarla ilgili bir inceleme fırsatı bulabilirim.

Öncelikle, o havalı isminin nereden geldiğini kısaca anlatalım, Prometheus, Yunan mitolojisinden oldukça havalı bir titan abimiz. “Mitolojiye göre insanlığın yaratıcısı ve onun en büyük yardımcısı. Ateşi, Olympus dağından çalarak insanoğluna armağan etmiştir.” diyor  Wikipedia. Tabii, bu sadece özetin de özeti bir açıklama. Arka planda neler dömüş, neler bitmiş pek bilmiyorum tabii. ¯\_(ツ)_/¯

Prometheus nedir?

Prometheus, Google’ın Borgmon adındaki Monitoring çözümünden ilham alınarak ortaya çıkan bir Open-Source Monitoring uygulaması.

europace_grafana_1-cbbe3751886

Grafana & Prometheus | Source: https://prometheus.io/blog/2017/04/06/interview-with-europace/

Proje 2012 yılında, her ikisi de Ex-Googler olan Matt T. Proud ve Julius Volz tarafından Soundcloud şirketinde geliştirilmeye başlanmış. Ar-Ge aşamalarında C, C++, Java ve Go kullanılmış. Veritabanı olarak Cassandra ve bir Google ürünü olan LevelDB seçilmiş. LevelDB hızlı bir key-value store kütüphanesi. Araştırmalar Şubat 2012’de başlamış. Matt, Eylül 2012’de, Juilus Ekim 2012’de şirkete katılmış. Sanırım şirkete girer girmez direkt Prometheus’a yoğunlaşmışlar. Yalnız, bu arada Matt için “Ex” demişim ama 1 yıllık Soundcloud macerası ardından tekrar Google’da devam ediyormuş. Sonradan farkına vardım.

 prometheus

İhtiyaç/Çözüm

Konuyu aktarmadan önce böyle bir yapıda karşılaşılabilecek Monitoring zorluklarından bahsedelim.

  • Container’lardan metriklerin toplanması
  • Container Orchestrator’lardan (Kubernetes, Mesos) metriklerin toplanması
  • Container içinde koşan uygulamalardan metriklerin toplanması
  • Distributed yapıda izlemenin yapılması
  • Toplanan metriklerin işlenmek üzere saklanması
  • Toplanan verilerin analiz edilmesi, esnek sorgulamalarla aksiyon alınması
  • Senaryoya göre Centralized veya Decentralized kullanım

Bunlara ek olarak ise servis bazlı ortamlarda yaşanan monitoring zorlukları;

  • Mikroservis mimarisindeki her servis bir çok Instance’a sahip
  • Bir host üzerinde bir servise ait çok fazla sayıda Instance’ın çalışması
  • Bu instance’lar sürekli değişim halindeler; deploy edilirler, stop edilebilirler, bozulmuş olabilirler
  • Bütün yapıyı tek noktadan görebilme
  • Oluşan sorunun sebep olduğu instance’ı bir an önce görebilme
  • Anlamlı alerting. Yani, symptom-based (belirti tabanlı) durumlarda Info gelirken, cause-based (Problem/Olay-tabanlı) durumlarda Warning uyarısı gönderebilmek.

Bu başlıklardan ziyade daha derin bir şekilde işin uzmanlarından Container bazlı mimarilerde yaşanan en büyük zorlukların dile getirildiği gerçek best practise‘lerin anlatıldığı harika bir makaleye ulaşmak isterseniz şu linkten devam ediniz.

En büyük zorluk ise sanırım bütün katmanlarda, her şeyin her katmanda monitör edilmesi. “Her katman” yaklaşımını biraz açalım ve Prometheus tarafındaki çözümlerini inceleyelim:

  • Network katmanında;
    • Router, Switch, aktif-pasif bütün altyapının monitör edilmesi
  • Fiziksel Host katmanında;
    • Donanım hataları, provisiong ve deploying hataları, host kaynakları (Ram, Cpu, HDD)
  • Container katmanında:
    • Kaynak kullanımı, container performans karakteristikleri
      • Prometheus için Metrikleri sağlayan sistem: cAdvisor
  • Uygulama katmanında:
    • Gecikme(Latency), hatalar, QPS (Queries per second), container durumu
      • Prometheus için Metrikleri sağlayan sistem: Kendinize özel geliştirilmiş kod opsiyonu.
  • Orchestration katmanında: 
    • Cluster kaynakları, Scheduling
      • Prometheus için Metrikleri sağlayan sistem: Kubernetes komponentleri

Birazdan Prometheus mimarisini incelerken yukarıda ismi geçen tanımları biraz daha yakından tanıyacağız.

Bu noktada Black-Box Monitoring ve White-Box monitoring hakkında birkaç noktaya değinelim; diyelim ki bir Host monitör ediyoruz. Black-Box tekniğinde hostun ulaşılabilir durumda olup olmadığı, Uzaktan Login’e müsait olup olmadığı kontrol edilir (Rdp, SSH). Aynı Host White-Box tekniği ile monitör edilseydi, anlık CPU, Uptime, Load, Memory, Disk IO, Disk Error (SMART), NIC metrikleri gibi değerleri toplayarak analiz edecektik. Black-Box yaklaşımında “Bu sunucu ping’e cevap veriyor mu?“, “Web sunucudan web sitesi sağlıklı fetch ediliyor mu?“, “Sitenin içeriği doğru içerik mi?” şeklinde bir monitoring durumu yapılır.  Bu konuda detay için Aaron S. Joyner (Google, Sr. System Administrator)’ın harika bir sunumu mevcut.

Prometheus sisteminin ana yaklaşımı bireysel sunucular ve uygulamalar yerine, dağıtık uygulamalar ve servislerin monitör edilmesi. Zaten Soundcloud ortamında da bu ihtiyaçtan dolayı ortaya çıkmış.  Soundcloud, Mikroservis mimarisine geçiş yaparken yüzlerce servis ve birkaç bin Instance sahibi olduklarından mevcut Monitoring uygulaması bu yapının ihtiyaçları için yetersiz kalmış. Mevcut Monitoring set-up’ları çoğunlukla  StatsD ve Graphite bileşiminden oluşuyormuş. Haliyle birçok kısıtlamalarla karşı karşıya kalıyorlarmış.

Onlarca servisin yönetimi otonom bir şekilde olurken Monitoring yaklaşımının manuel olması, son kullanıcı tarafında yaşanan gecikme ve hata oranlarının servis bazında ölçülmesi bir diğer ihtiyaç ve eksiklik gibi görünüyor.

Bir titan doğuyor, açılın!

Öncelikle konudan hafif ayrılarak Prometheus öncesi Soundcloud Infrastructure yapısına hızlıca bir bakış atalım;  Container orchestration için oldukça gelişmiş bir yapı mevcut. Adı Bazooka!  Soundcloud yeni servislerin hızlı bir şekilde dinamik deployment sürecini bu sistemle başarmış. Bazooka ile 12 Factor App metodolojisine uygun deployment sağlanmış. Bundan önce yapı tamamen monolitik mimari odaklı bir Rails uygulamasıymış. 200’ü aşkın repository’e sahiplermiş ve çoğunlukla mimari web servis mimarisindeymiş. Load Balancer, Application Server, Cache ve Database sunucuları bu monolitik yapıyı çalıştırıyormuş.

Monitoring tarafında ise çoğunlukla Nagios, Graphite, StatsD, Ganglia, Cacti ve Munin gibi mevcut open-source araçları ile çalışılıyormuş. Ops takımlarından birinde bulunan çağrı cihazı ile alarmlardan haberdar olunuyor, ilk Infrastructure takımı aranıyormuş. Bütün bu araçlara rağmen Enstrümantasyon yani ölçme işlemleri oldukça verimsizmiş. StatsD ve Graphite’in scalability yani ölçeklenme sorunları nedeni ile sorunlar yaşanmaktaymış.

service_monitoring

service_monitoring2

Service monitoring with StatsD and Graphite | Source: https://www.usenix.org/sites/default/files/conference/protected-files/srecon15europe_slides_prometheus.pdf

Konuyu bölmeden az önce ismi geçen StatsD ve Graphite‘e kısaca değinelim;  StatsD,  Etsy firması (DIY ve el işi/hobi tutkunlarının daimi mekanı) tarafından geliştirilmiş, Node.js platform tabanlı bir Network servisidir. Basitçe bu servis UDP portu üzerinden gelen mesajları dinler. Gelen mesajları parse eder, metrik dataları ayrıştırır ve periyodik olarak Graphite‘e veya farklı bir Backend servise aktarır. Graphite’in tanımına geçmeden önce de “Neden UDP?” sorusuna cevap verelim. Hız! Performansı ölçerken yavaş bir network protokol istemeyiz değil mi? StatsD ile ilgili daha fazla detaya şu linkten ulaşabilirsiniz.

Graphite ise kurumsal ölçekte bir Monitoring aracı, time-series data saklayıcı ve bu datalardan anlık olarak grafik oluşturucu. 🙂 Biliyorum, ilginç bir tanım oldu ama tam olarak böyle bir şey. Graphite datayı collect edemez. Birlikte çalıştığı çeşitli araçlarla bunu başarır. Projenin mottosu bana göre “an enterprise-scale monitoring tool that runs well on cheap hardware.” şeklinde. Sektörde yoğun bir şekilde kullanılmakta olduğunu da belirtelim.

Eski yapıda Alerting işlemleri için Nagios (Oldum olası çok severim kendisini) kullanılmaktaymış. Eski ama etkili. Ona değinmeden olmaz!

nagios

Alerting with Nagios | Source: https://www.usenix.org/sites/default/files/conference/protected-files/srecon15europe_slides_prometheus.pdf

Nagios, eksi görünümlü arabirimine rağmen güçlü bir Monitoring tool. Sahip olduğu Event-Scheduler, Event Processor ve Alert yöneticisi ile basit ama etkili bir araç. Onlarca (pardon, yüzlerce) farklı mevcut plug-in ile her türlü monitoring ihtiyacına cevap verebilmekte. C dili ile yazılmış bir “daemon” ile native bir şekilde Linux ve *nix sistemlerde çalışabilmekte. SNMP veya WMI desteği olan cihaz, uygulama Agentless olarak izlenebilir. Agent bazlı olarak hem Windows hem de Linux ve *nix ortamlar için daha detaylı metrik izleme yapılabilir. Bir ofisteki SNMP destekli bir yazıcının kağıt haznesinde kalan kağıt sayısını veya bir Personel takip sisteminden o gün kaç kişi geçiş yapmış izlenmesi, bir sunucudaki fan hızının durumundan, ESXi Cluster üzerideki hostların durumlarına kadar geniş bir yelpazede monitoring yapılabilmekte. Nagios’u burada bitirelim, yoksa ben bütün makaleyi Nagios anlatarak geçirebilirim. (Gözler kalp, kalp, kalp <3)

Konuyu çok dağıtmadan tekrar Soundcloud ortamındaki Prometheus’un doğuş macerasına dönecek olursak; StatsD ve Graphite bazlı mevcut Monitoring set-up yüzlerce servisin monitor edilmesinde yetersiz kalınca şu ihtiyaçlara çözüm sunabilecek bir yapı inşa edilmeye başlanmış. Mevcut monitoring ihtiyaçlarını sıralamışlar;

  • Çok-Boyutlu (Multi-Dimensional ) bir data modeli gereksinimi ve böylece datanın ihtiyaca göre (service, instance, endpoint, method) dilimlenebilmesinin sağlanması.
api_http_requests_total{method="GET", endpoint="/api/tracks", status="200"} 2034834
  • Operasyonel basitlik; (Operational simplicity) yani bir Monitoring Server’ın  nerede ve ne zaman isteniyorsa anında canlıya alınabilmesi. Bu bir lokal Developer Workstation’da olabilir veya bir Distibuted Storage Backend sistem de.
$ go build
$ ./prometheus
  • Ölçeklenebilir data toplama (Scalable data collection) ve merkezi olmayan bir mimari. Böylece bir çok servisi güvenli ve birbirinden bağımsız bir şekilde izlenmesi.
#single static binary, no dependencies
$ go get github.com/prometheus/prometheus/cmd/...
$ prometheus
  • Son olarak da, güçlü bir sorgulama dili. Bu dil ile anlamlı data takibi, alert işlemleri ve grafik oluşturma yapılabilmeli.
topk(3, sum(rate(bazooka_instance_cpu_time_ns[5m])) by (app, proc))
sort_desc(sum(bazooka_instance_memory_limit_bytes -
 bazooka_instance_memory_usage_bytes) by (app, proc))

En çok CPU kullanan Docker image’larının sorgulanması:

topk(5,
 sum by (image)(
 rate(container_cpu_usage_seconds_total{
id=~"/system.slice/docker.*"}[5m]
 )
 )
)

Bütün bu ihtiyaçların zaten halihazırda sektördeki çoğu alternatif sistemler mevcut olduğunu görmüşler ama 2012 yılı itibarı ile hepsini tek bir üründe toparlayan ve bir anda projeye dahil edilebilecek tek bir ürün olmadığından projenin başlatılmasına karar verilmiş. Böylece Prometheus doğmuş. Doğuş sonrası diğer süreçlerle ilgiliyseniz şu linkten devam edebilirsiniz.

Prometheus mimarisine bakış

prometheus_architecture

Prometheus, enstrümante edilmiş işlerin oluşturduğu metrikleri direkt olarak ya da Short-Lived görevler için, Push Gateway‘ler yolu ile toparlar. Daha sonra bütün bu toparlanan örnekler lokal olarak saklanır.  Bu datalardan yeni time-serileri veya alarmlar oluşturmak için çeşitli kurallar uygulanır. Görselleştiriciler veya diğer API istemcileri bu ham dataları kullanarak görselleştirme yapar.

Evet, yine karmaşık gibi görünen cümleler kurduk. Elimizden geldiğince tanımları açıklayalım;  Enstrümantasyonun şurada çok güzel bir tanımı var. Kısaca diyor ki, Enstrümantasyon, bilgisayar programcılığında, bir ürünün performans seviyesinin, hata teşhisi veya hata ayıklama işlemleri için monitör edilmesi ya da ölçülmesi. Metrik, bir yazılım sisteminin herhangi bir niteliğinin ölçümüdür.  Time-Series; veri serisinin grafiksel olarak izlenmesi, değişimlerin gözlenmesi amacı ile veri noktalarının sıklığıdır. Düzenli zaman aralıklarında ardışık olarak ölçülür. Örneğin Dolar’ın günlük kapanış fiyatı, bir nehrin aylık akış debisi grafiği gibi.  Verilerden anlamlı istatistikler almak için kullanılır. Örneğin bu serilere bakarak bir hisse senedinin o günkü açılış fiyatını öngörebilir, analizler yapılabilir.

Prometheus ekosisteminin bileşenlerine yakından bakalım

Yukarıdaki mimariyi biraz inceleyelim, kim neyden sorumlu açıklayalım.

  • Mimarinin merkezinde bulunan PROMETHEUS SERVER time-series datayı toplar ve saklar. (Ben “toplar” diyorum ama Türkçe’sini bilmiyorum pek. Orijinal hali “Scraping”)
  • CLIENT LIBRARIES (İstemci Kütüphaneleri) uygulama kodunu ölçmek için kullanılır.
    • Bir servisi monitör etmeden önce,  uygulama kodunun içine Prometheus Client Library kullanarak bir Enstrüman eklenmesi gerekir. Bunun sayesinde Prometheus metrikleri uygulamaya eklenmiş olur.
    • Official olarak Go, Java veya Scala, Python, Ruby kütüphaneleri mevcutken Unofficial olarak da birçok dil için kütüphane desteği bulunuyor.
  • PUSH GATEWAY kısa-ömürlü görevlerde destek verir.
    • Bir Push Gateway kısa süreli veya batch bir job için vardır. Bu görevler işleri bittiğinde var olmayacağından metrikleri anlık olarak Push etmeleri gerekir. Anlık yapılan Push’ları karşılayan sistem Push Gateway’dir.
  • Özel amaçlı EXPORTER‘lar (HAProxy, StatsD, Graphite vb.)
    • Üçüncü parti sistemlerden Prometheus’un anlamlandırabileceği  şekilde metrikler üreten bir dizi library veya server vardır. Bunun faydalı olduğu durumlar, Prometheus metriklerinin direkt uygulanamadığı HAProxy veya Linux sistem metrikleri gibi durumlarda işe yararlar. Aracı köprü gibi iş yaparlar. Bu Exporter’lara şu linkten ulaşılabilir.
  • ALERT MANAGER ise istemciler tarafından gönderilen alarmları işler. Alarmları tekilleştirme, gruplama ve doğru alıcılara yönlendirmeyi sağlar.

Elleri kirletme vakti!

Bütün bu teorik bilgi sonrası Docker yardımı ile bir test Prometheus container ayağa kaldırıp web arabirimden test edelim.

Mevcut sisteminizde Docker kurulu olduğunu varsayarak direkt olarak “run” komutumuzu girelim.

$ docker run --name prometheus -d -p 9090:9090 quay.io/prometheus/prometheus

docker_promet_cli

Container up olduğunda web interface ile durum kontrol edilebilir.

promet_docker

Şu ana kadar ben makaleden epey keyif aldım. Benim için oldukça verimliydi. Sizler için de öyle olmasını umuyorum. Şimdilik bu kadar.  2. bölümde biraz daha derinlere inmeye çalışacağım.

Teşekkürler.

Hakan Orcan

Kullanılan kaynaklar:

https://docs.google.com/presentation/d/1X1rKozAUuF2MVc1YXElFWq9wkcWv3Axdldl8LOH9Vik/edit#slide=id.g598ef96a6_2_19
https://prometheus.io/blog/2017/04/06/interview-with-europace
https://docs.google.com/presentation/d/1ni1BFiVMTLN_8q34si-qPfl0F6w2W3oPVKqSMfcs_XA/edit#slide=id.p
https://blog.openshift.com/wp-content/uploads/Prometheus-OpenShift-Commons-Briefing-1.pdf
https://www.infoq.com/articles/monitoring-containers-at-scale
https://devops.jaxlondon.com/wp-content/uploads/2016/05/Monitoring-a-Kubernetes-backed-microservice-architecture-with-Prometheus_Fabian-Reinartz-Bj%C3%B6rn-Rabenstein.pdf
https://github.com/prometheus/snmp_exporter
https://github.com/prometheus/node_exporter
https://github.com/google/cadvisor
ttps://en.wikipedia.org/wiki/Queries_per_second
https://developers.soundcloud.com/blog/prometheus-monitoring-at-soundcloud
https://www.usenix.org/sites/default/files/conference/protected-files/srecon15europe_slides_prometheus.pdf
https://github.com/etsy/statsd
https://codeascraft.com/2011/02/15/measure-anything-measure-everything
https://en.wikipedia.org/wiki/Parsing
http://www.haproxy.org/
http://graphite.readthedocs.io/en/latest/tools.html
https://prometheus.io/
https://soundcloud.com/
https://en.wikipedia.org/wiki/Greek_mythology
https://www.nagios.org/projects/nagios-core/
https://en.wikipedia.org/wiki/Decentralised_system
https://blog.openshift.com/wp-content/uploads/Prometheus-OpenShift-Commons-Briefing-1.pdf
https://english.stackexchange.com/questions/60732/instrumented-what-is-a-good-explanation-definition-of-the-word-english-tech
https://prometheus.io/docs/instrumenting/clientlibs/
https://github.com/prometheus/pushgateway
http://www.haproxy.org
http://www.ncsysadmin.org/meetings/1010/Monitoring_and_Alerting.pdf
https://12factor.net/

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s