OpenShift izleme için pratik rehber

Kutudan neler çıkıyor?

OpenShift Container Platform 4, openshift-monitoring ad alanına Cluster Monitoring Operator tarafından yönetilen bir metrik yığını kurar. Bu yığın platformun kendisini kapsar: düğümler, kontrol düzlemi bileşenleri, etcd, API sunucusu, Kubernetes nesneleri. Hazır alarm kurallarıyla gelir, web konsolu metrikleri, alarmları ve panelleri Observe menüsünde gösterir.

Neyin çalıştığını görün:

oc get pods -n openshift-monitoring
oc get clusteroperator monitoring

Operatörler ve sürümleri OpenShift sürümleri arasında değişir, kendi sürümünüzün belgelerini kontrol edin. Platform yığınının varsayılan saklama süresi kısa, ölçeği sınırlıdır. Kümeyi sağlıklı tutmak için tasarlanmıştır, uzun vadeli metrik deponuz olmak için değil.

1. adım: Platform alarmlarını birine ulaştırın

Yeni bir kümede kimseye ulaşmayan alarmlar çalışır durumdadır. Konsol da alıcı tanımlanana kadar bunu hatırlatır. İlk işiniz Administration > Cluster Settings altındaki alarm yönlendirme ayarlarına e-posta, webhook veya nöbet sistemi alıcılarını eklemek olsun.

Watchdog alarmına dikkat edin. Tasarım gereği hep çalışır, bir ölü adam anahtarıdır. Onu, gelmediğinde alarm veren harici bir sisteme yönlendirin. Aksi hâlde ölmüş bir izleme yığını sakin bir geceyle aynı görünür.

Kısıtlı ağlarda alıcılara küme içinden erişildiğini doğrulayın. Bloke bir SMTP veya webhook yolu, nöbetçi açısından sessizce başarısız olur.

2. adım: Kullanıcı iş yükü izlemeyi açın

Uygulamalarınız metrik sunuyorsa kullanıcı iş yükü katmanını açın. Bu katman openshift-user-workload-monitoring ad alanında ayrı bileşenlerle çalışır.

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    enableUserWorkload: true

oc apply -f cluster-monitoring-config.yaml
oc get pods -n openshift-user-workload-monitoring

ConfigMap zaten varsa üzerine yazmayın, düzenleyin; yoksa mevcut ayarları kaybedersiniz. Sonrasında ekipler kendi ad alanlarında özel kaynaklarla toplama hedeflerini ve alarm kurallarını tanımlar, geliştiriciler verilerini kendi projelerinin Observe menüsünde görür. Erişimi belgelerdeki rollerle verin, örneğin monitoring-edit:

oc policy add-role-to-user monitoring-edit dev-user -n odeme

Bu katmanın saklama süresi dahil ayarları kendi ad alanındaki user-workload-monitoring-config ConfigMap'inde durur. Sürümünüzde desteklenen alanları kontrol edin. Operatörün yönettiği kaynakları doğrudan değiştirmeyin: operatör geri alır ve desteklenmeyen bir duruma düşebilirsiniz.

Bu katmandaki ana risk metrik çeşitliliğidir. Kullanıcı kimliği veya istek yolu içeren tek bir etiket çok fazla bellek tüketebilir. Ekiplerin sunduklarını gözden geçirin ve belgelenmiş örnek sınırlarını kullanın.

3. adım: Olay anında ilk komutlar

Panel açmadan önce şu komutlar ilk soruların çoğunu cevaplar:

oc get clusterversion
oc get clusteroperators
oc get nodes
oc get machineconfigpool
oc adm top nodes
oc adm top pods -n odeme --sort-by=cpu
oc get events -n odeme --sort-by=.lastTimestamp | tail -30
oc get pods -n odeme -o wide
oc describe pod <pod> -n odeme
oc logs <pod> -n odeme --previous

Her birinin anlattığı:

• **clusteroperators** DEGRADED veya AVAILABLE olmayan platform bileşenlerini gösterir. Kimlik doğrulama, ingress veya izleme operatörünün kendisi bozuksa uygulama belirtileriniz platformdan geliyor olabilir.
• **machineconfigpool** düğümlerin bir yapılandırma güncellemesinin ortasında olup olmadığını gösterir. Boşaltılıp yeniden başlayan düğümler çok sayıda pod hareketini açıklar. Bu OpenShift'e özgü, sık unutulan bir nedendir.
• **--previous** konteynerin son çökmesinden önce yazdıklarını gösterir. Bu bayrak olmadan yalnızca taze konteyneri görürsünüz.
• **events** kısa ömürlüdür, varsayılan olarak kısa süre sonra silinir. Erken alın veya başka yere aktarın.

Destek talebi veya derin inceleme için oc adm must-gather büyük bir tanı paketi toplar. İmajının erişilebilir olması gerekir, kapalı kümede bunu önceden planlayın. Paketi de hassas veri sayın.

Tanımanız gereken alarmlar

Platform alarmlarını yabancı geldiği için susturmayın, önce araştırın. Konsoldaki alarm ayrıntı sayfasında açıklama bulunur, birçok kuralda runbook bağlantısı vardır. Kapalı ağda bu bağlantılar açılmayabilir, güvendiğiniz runbook'ların kopyasını içeride tutmayı düşünün.

Yerleşik yığının söylemedikleri

Platform izleme "küme sağlıklı mı?" ve "bu pod ne kadar kullanıyor?" sorularına cevap verir. Ekipler sonra şu boşluklara takılır.

İstek düzeyindeki sorular. /odeme bazı kullanıcılar için neden yavaş? CPU ve bellek grafikleri bunu söyleyemez. Trace veya en azından uygulama metrikleri gerekir. OpenTelemetry operatörü OpenShift'te bunun yoludur.

Korelasyon. Metrik, log ve trace ayrı görünümlerdir. Gecikme sıçramasından etkilenen isteklerin loglarına gitmek, trace kimliği ve bağlantılar eklemediyseniz elle yapılır.

Değişiklik geçmişi. Olay kaydı ve rollout geçmişi vardır, ama gecikme grafiğinizle hizalı değildir. "Hatalar artmadan dört dakika önce ConfigMap değişmiş" çoğu zaman cevabın kendisidir ve görmesi zordur.

Uzun vadeli eğilimler. Kısa saklama süresiyle bu ayı geçen çeyrekle karşılaştırmak ayrı bir depo ister.

Boyutlandırma. Veri vardır, ama her iş yükü için sorgulayıp yorumlamanız gerekir.

Birden fazla küme. Bir kümenin konsolu o kümeyi gösterir.

Küme dışındaki servisler. Denetimli ortamların çoğunda OpenShift dışında önemli Linux sunucular ve veritabanları durur. Siz eklemedikçe sağlıkları burada görünmez.

Yetkiler ve ajanlar

Eklediğiniz her izleme ajanı OpenShift'in güvenlik modeline uymak zorundadır. Birçok ürün ayrıcalıklı DaemonSet, hostPath bağlaması veya hostNetwork ister, yani varsayılan dışı SCC verilmesi gerekir. Güvenlik ekipleri haklı olarak nedenini sorar. Kurmadan önce her pod'un hangi SCC'yi istediğini ve bu yetkiyle ne yaptığını öğrenin. Kurulumdan sonra doğrulamak için:

oc get pods -n izleme -o custom-columns='POD:.metadata.name,SCC:.metadata.annotations.openshift\.io/scc'

Admission webhook'ları da düşünün. Pod'lara enjekte eden ajanlar mutating webhook kullanır, kötü ayarlanmış biri yükseltme sırasında bile tüm kümede pod oluşturmayı engelleyebilir. failurePolicy ve namespaceSelector alanlarına bakın, openshift-* ad alanlarının hariç tutulduğundan emin olun.

Bağlantısız kümeler

Bağlantısız bir OpenShift kümesinde sürüm imajlarını ve operatör kataloglarını iç registry'ye yansıtırsınız. İzleme açısından:

• Uzaktan sağlık raporlama dışarı veri gönderemez, başarısız olmaya bırakmak yerine belgelendiği şekilde kapatmayı düşünün.
• Runbook bağlantılarının iç kopyası gerekebilir.
• Her ek operatör yansıya dahil edilmelidir.
• Alarm alıcılarının tamamı içeride olmalıdır.
• must-gather imajı da yansıtılmalıdır.

Genel çerçeve için kapalı ağ izleme yazısına bakın.

Wrentrix OpenShift'te nereye oturur?

Wrentrix varsayılan restricted-v2 SCC altında, en az yetkili pod'larla, root ve ek SCC olmadan çalışır, operatör veya Helm chart ile kurulur. Arayüzden kümeyi ekler, üretilen YAML dosyasını indirip oc apply -f wrentrix-k8s-agent.yaml komutuyla uygularsınız; düğümler ve pod'lar yaklaşık iki dakikada görünür. Platformun verdiklerinin üzerine iş yükleri, olaylar, HPA, boyutlandırma ipuçları, değişiklik korelasyonu ve trace'ler ekler. Yerleşik yığının yerini almaz, platform alarmları için onu koruyun. Ayrıntı için Kubernetes ve pod izleme sayfasına, ekranlar için canlı demoya bakın.

Sık sorulan sorular

OpenShift'te hazır izleme var mı?

Evet. OpenShift 4, Cluster Monitoring Operator tarafından yönetilen bir metrik ve alarm yığını ile web konsolunda paneller getirir. Varsayılan olarak platformu kapsar, kendi uygulamalarınız için kullanıcı iş yükü izlemeyi açabilirsiniz. Loglama ve trace için ek operatörler gerekir.

OpenShift'te kullanıcı iş yükü izleme nasıl açılır?

openshift-monitoring ad alanındaki cluster-monitoring-config ConfigMap'inin config.yaml kısmına enableUserWorkload: true yazın. Bileşenler openshift-user-workload-monitoring ad alanında başlar. Geliştiricilerin toplama hedefi ve kural yönetebilmesi için projelerinde uygun izleme rolleri gerekir.

Watchdog alarmı neden hep çalışıyor?

Tasarım gereği böyledir, alarm hattının çalıştığını kanıtlar. Onu, gelmediğinde alarm veren harici bir sisteme yönlendirin. Susturursanız izlemenin ayakta olduğunu gösteren en basit kontrollerden birini kaybedersiniz.

Yerleşik OpenShift izleme uzun süreli depo olarak kullanılabilir mi?

Bunun için tasarlanmamıştır, saklama süresi ve ölçeği sınırlıdır. Red Hat, metrikleri başka bir sisteme gönderen bir remote write seçeneği belgeler. Sürümünüzde desteklenen ayarları kontrol edin, yerel saklamayı artırırken boyutu dikkatle hesaplayın.

İzleme ajanları OpenShift'te ayrıcalıklı erişim ister mi?

Birçoğu, özellikle sunucu metrikleri ve log okuma için ister, ama hepsi istemez. Kurulumdan sonra her pod'daki openshift.io/scc notuna bakın. Bir araç varsayılan dışı SCC istiyorsa her yetkinin ne için olduğunu sorun ve güvenlik ekibinize inceletin.