Bloğa geri dön

Journalctl ile Systemd Günlüklerini Görüntüleme ve Düzenleme

Journalctl ile Systemd Günlüklerini Görüntüleme ve Düzenleme

Sistem ve süreç günlükleme, systemd'nin en önemli avantajlarından sadece ikisidir. Günlükler sistem geneline dağıldığında, birden fazla uygulamayı kapsadığında ve farklı süreçler ile arka plan programları (daemon) tarafından işlendiğinde, bunları yorumlamak zor olabilir. Systemd, tüm çekirdek ve kullanıcı alanı süreç günlüklerini journal (günlük) olarak bilinen bir derleme ortamında yönetmek için merkezi bir çözüm sunar. systemd hakkında daha fazla bilgiyi systemctl ile systemd hizmetlerini ve birimlerini nasıl yöneteceğinize dair eğitimimizden öğrenebilirsiniz. Bir günlükteki hizmetler, initrd, çekirdekler vb. tarafından oluşturulan tüm iletiler journal arka plan programı (journal daemon) tarafından işlenir. Bu kılavuzun amacı, journalctl kullanarak journal verilerine nasıl erişileceğini ve bunların nasıl işleneceğini göstermektir.

Temel Prensip

Bir mesajın nereden kaynaklandığına bakılmaksızın, systemd'nin birincil amaçlarından biri bunların yönetiminin merkezileştirilmesine izin vermektir. Önyükleme işlemlerinin çoğu ve hizmet yönetiminin büyük kısmı systemd süreci tarafından üstlenildiğinden, günlüklerin derlenme ve bunlara erişilme şekli standartlaştırılmalıdır. Mevcut tüm kaynaklardan verileri her şeyi kapsayan tek bir araçta toplayan journald, bunları ikili (binary) formatta saklar. Bu, verilerin dinamik ve basit bir şekilde işlenmesi için hazır bulunmasını sağlar.

Bu yaklaşımın birkaç önemli avantajı vardır. Tüm verileri toplamak için merkezi bir yere sahip olan yöneticiler, filtreleme yaparak yalnızca ihtiyaç duydukları tarihi görüntüleyebilirler. Örneğin, üç sistem önyüklemesi öncesine ait önyükleme verileri görüntülenebilir. Bu aynı zamanda ilgili hizmetlerden gelen girdilerin ardışık olarak günlüğe kaydedilmesi ve aralarındaki bir iletişim sorununun daha etkili bir şekilde izlenmesi anlamına da gelebilir.

İkili depolama sayesinde veriler, kullanıcının o andaki ihtiyaçlarına bağlı olarak çeşitli çıktı biçimlerinde görüntülenebilir. Örneğin, günlük bir günlük standart bir syslog biçiminde görüntülenebilir. Ancak hizmet kesintilerini bir grafik biçiminde trend haline getirmeniz gerekiyorsa, girdi bir JSON nesnesi olarak çıktı alınabilir ve bu da bir grafik oluşturma hizmetiyle çalıştırılabilmesini sağlar. Durumsal taleplere bağlı olarak biçimleri değiştirmeniz gerektiğinde, veriler ikili olduğundan ve diske düz metin olarak yazılmadığından herhangi bir dönüştürme işlemine gerek kalmaz.

İhtiyaçlara bağlı olarak, systemd journal'ı mevcut bir syslog ile uygulayabilir veya bu işlevin yerini almasını sağlayabilirsiniz. Systemd, mevcut günlükleme mekanizmalarını bile tamamlayabilir. Örneğin, tek bir sistemdeki birden fazla hizmetin derlenmiş verileri, systemd journal ile tek bir sistemde birbiriyle harmanlanabilir.

Sistem Saatini Ayarlama

Systemd, varsayılan olarak sonuçları yerel saatte görüntüler; bu, günlük kayıtlarının nasıl görüntülenebileceği konusunda ikili journal günlüklemesinin bir avantajıdır. Alternatif olarak, UTC olarak da görüntülenebilirler. Bu nedenle, journal günlüklemesine başlamadan önce saat diliminin doğru ayarlandığından emin olmak önemlidir. Bunu yapmak için systemd, timedatectl adlı bir araçla donatılmıştır. list-timezones seçenekleriyle bir liste görüntüleyerek hangi saat dilimlerinin kullanılabileceğini görerek başlıyoruz:

Sunucunuzun konumu için uygun saat dilimini bulduktan sonra, saat dilimi set-timezone seçeneği kullanılarak ayarlanabilir:

Saat diliminin artık düzgün görüntülendiğini test etmek ve doğrulamak için timedatectl komutunu tek başına veya 'status:' ekleyerek kullanabilirsiniz:

timedatectl status

İlk satır yerel saati gösterir. Bu satır, yerel bölgeniz için doğru saati içermelidir.

Genel Günlük Görüntüleme

journalctl komutu, journald arka plan programının topladığı günlükleri görüntülemenizi sağlayacaktır. journalctl kullandığınızda, sistemdeki her journal girdisi ekran sayfasında görüntülenecek ve en eski girdiler üst kısma doğru listelenecektir. Ancak verilerin tam listesi on binlerce satır uzunluğunda olacaktır.

journalctl

Standart syslog günlüğünü kullanmış olanlar formatı tanıdık bulacaktır, ancak syslog yönteminin aksine, bu veri derlemesinin birçok kaynaktan dahil edildiğini akılda tutmak önemlidir. Günlükler; erken önyükleme sürecini, initrd’yi, çekirdeği ve uygulama standart hatalarını içerecektir.

Artık yerel saat ayarlandığına göre, tüm girişler yerel saatle yerleştirilmiş zaman damgalarıyla başlayacaktır ve bu yeni bilgiler kullanılarak tüm mantık görüntülenecek şekilde sistemde kayıtlı olan her günlük için mevcuttur. Ancak yerel saatle sınırlı değilsiniz. –utc bayrağını kullanarak zaman damgalarını UTC olarak da görüntüleyebilirsiniz:

Zamana Göre Günlük Filtreleme

Bu kadar çok verinin mevcut olması harika, ancak bunları taramak ve özümseyebilmek, zihinsel olarak işlemeyi bir kenara bırakın, göz korkutucu bir görev olabilir. Bunu akılda tutarak, journalctl işlevinin en önemli kısmına ulaşıyoruz: filtreleme.

Mevcut Önyüklemeye Ait Günlüklerin Görüntülenmesi

Günlükte en son yeniden başlatmaya ait verileri arıyorsanız, journalctl işlevini -b bayrağıyla kullanabilirsiniz. Bu, sisteminizin en son yeniden başlatılmasına ait tüm ilgili günlük bilgilerini görüntüleyecektir. Bu komut, mevcut çalışma ortamıyla en ilgili bilgileri bulmanızı ve yönetmenizi sağlayacaktır:

İzleyici her bir girişi ayrı ayrı değerlendirmemeyi seçerse, journalctl, journalctl içinde kullanışlı ‘Reboot’ ayırıcılarıyla görüntülenecek bir günden fazla önyüklemeyi gösterecektir. Bu, inceleme için farklı önyükleme oturumlarından gelen bilgileri mantıksal olarak ayırmaya yardımcı olur:

Geçmiş Önyükleme Bilgileri

Mevcut önyükleme bilgilerini görüntülemek genellikle en yararlısı olsa da, geçmiş önyükleme bilgilerinin yardımcı olacağı durumlar da vardır. Journal, önceki birden fazla önyükleme için bilgileri kaydeder, bu nedenle journalctl herhangi bir zaman dilimine ait bilgileri kolayca görüntüleyebilir.

Bazı dağıtımlar önceki önyükleme bilgilerinin kaydedilmesini devre dışı bırakırken, diğerlerinde bu varsayılan olarak etkindir. Kalıcı önyükleme bilgilerinin etkinleştirilmesi, aşağıdakiler yazılarak günlüğün depolanması için bir dizin oluşturularak gerçekleştirilebilir:

Alternatif olarak, günlük yapılandırma dosyasını aşağıdaki şekilde düzenleyebilirsiniz:

[Journal] bölümü altındaki Storage= seçeneğini “persistent” olarak ayarlamak kalıcı günlüğe kaydetmeyi etkinleştirecektir:

journalctl configuration

Bu etkinleştirildiğinde, journalctl bu önyüklemeleri bölme birimleri olarak belirlemenize yardımcı olan belirli komutları kullanılabilir hale getirir. journald içinde kaydedilen önyüklemeleri görüntülemek için journalctl aracılığıyla –list-boots seçeneğini kullanabilirsiniz:

list boots journalctl

Gösterildiği gibi, her bir önyükleme kendi satırında listelenecektir ve ilk sütun en eskiden en yeniye doğru önceki önyüklemeleri yansıtacaktır. Daha kesin bir referans gerekiyorsa, ikinci sütun önyükleme kimliğini içerir. Bundan sonra, listelenen iki zaman özelliği vardır. Belirli bir önyüklemeye ait günlük bilgilerini görüntülemek için birinci veya ikinci sütundaki bilgiler kullanılabilir. Örneğin, en son yeniden başlatmadan bir öncekine ait bilgileri görüntülemek için göreli önyükleme işaretçisi -1 ile -b bayrağını kullanabilirsiniz:

Benzer şekilde, ikinci sütundaki önyükleme kimliği de bu şekilde kullanılabilir:

Zaman Pencereleri

Önyüklemeleri (boot) kimliğe göre görüntülemek bir seçenektir, ancak belirli önyüklemelerle tam olarak eşleşmesi gerekmeyen geçmişteki bir zaman aralığına göre önceki önyüklemelere başvurabilmek genellikle daha yararlıdır. Örneğin bu durum, sık sık yeniden başlatılmayan ve uzun süredir çalışan sunucularla çalışırken geçerlidir. Zaman sınırlarının filtrelenmesi isteğe bağlı zaman sınırlarıyla yapılabilir. Bu, yalnızca belirli bir zaman aralığına denk gelen yeniden başlatmalar hakkındaki bilgileri görüntüler. Bu aralığın parametreleri –since ve –until seçenekleriyle belirlenir. Zaman seçenekleri için kullanılabilir birkaç biçim vardır. Mutlak zaman değeri biçimi aşağıdaki gibidir:

Dolayısıyla, 10 Ocak 2015 saat 17:15'ten bu yana gerçekleşen tüm önyüklemeleri görmek istiyorsanız aşağıdaki komutu yazın:

Bileşenlerden herhangi biri atlanırsa, yerleşik varsayılan değerler kullanılır. Ayrıca, bir tarih belirtilmezse varsayılan olarak geçerli tarih alınır. Zaman bileşeni yoksa, varsayılan değer gece yarısıdır (00:00:00). Zaman bileşeninden saniyeleri çıkarırsanız, varsayılan olarak o dakikanın başlangıç noktası (00) alınır:

Journal; “today” (bugün), “tomorrow” (yarın), “yesterday” (dün) ve “now” (şimdi) gibi zamanla ilgili kısayolları anlayabilir. Cümle yapısında bir komut oluşturmak için “-” ve “+” ön ek belirteçleriyle birlikte “ago” (önce) gibi kelimeler kullanılabilir:

Saat 09:00'da başlayan bir hizmet kesintisinden haberdar edildiyseniz ve journal günlüklerini bir saat öncesine kadar kontrol etmek istiyorsanız, bunu aşağıdaki komutla yapabilirsiniz:

Görüldüğü gibi, istenen girdileri görüntülemek için esnek bir zaman aralığı tanımlamak oldukça basittir.

Mesaj İlgi Alanına Göre Filtreleme

Günlüğü zaman kısıtlamalarına göre filtrelemenin yanı sıra, veriler ilgilenilen hizmet bileşenine göre de filtrelenebilir. Systemd bunu yapmak için birkaç yöntem sunar.

Birimine Göre

Kuşkusuz en yararlı filtreleme parametresi, ilgilenilen birime göredir. Birime göre filtrelemek için -u seçeneğinden yararlanılabilir. Örneğin, Nginx birimiyle ilgili tüm günlükleri görmek istiyorsanız aşağıdaki komutu yazın:

Gerçekçi olmak gerekirse, ilgilendiğiniz satırları görüntülemek için bunu bir zaman filtresiyle eşleştirmek istersiniz. Yukarıdaki hizmeti ve bugün nasıl performans gösterdiğini kontrol etmek istiyorsanız aşağıdakileri yapabilirsiniz:

Bu, özellikle journal'ın birden fazla birimden (özellikle de birlikte çalışan birimlerden) kayıtları derleme yeteneğinden yararlanırken çok kullanışlıdır. Nginx işlemi, dinamik içerik işleme için bir PHP-FPN birimine bağlıysa, her iki birim de belirtilerek girdiler kronolojik sırayla birleştirilebilir:

Bu, program etkileşimini gözlemlemeye büyük ölçüde yardımcı olabilir ve tek tek işlemler yerine sistemlerde hata ayıklamayı kolaylaştırabilir.

Grup Kimliği, İşlem veya Kullanıcıya Göre

Birçok hizmet, belirli işleri gerçekleştirmek için çok sayıda alt işlem (child process) başlatır. Belirli bir işlemin kimliği (ID) biliniyorsa, _PID alanı belirtilerek de filtreleme yapılabilir. İlgilenilen PID 8088 ise aşağıdakiler yapılabilir:

Ayrıca belirli bir gruptan veya belirli bir kullanıcıdan kaydedilen girdileri de görmek isteyebilirsiniz. Bu, _GID ve _UID filtreleri kullanılarak gerçekleştirilebilir. Bir web sunucusu www-data kullanıcısı altında çalışıyorsa, aşağıdaki komut gerekli kimliği bulabilir:

find id

Bu kimliği kullanarak, filtrelenmiş journal sonuçlarını görüntüleyebilirsiniz:

Systemd, filtreleme amacıyla birçok alanı kullanılabilir hale getirir. Bazı alanlar, günlük kaydı sırasında sistemden toplanan bilgilere dayanarak journald tarafından uygulanırken, diğerleri o sırada günlüğe kaydedilen işlemden aktarılır.

_PID ön niteleyicisi, bilginin günlük kaydı sırasında sistemden toplandığını gösterir. Günlük, filtreleme özelliğini daha sonra kullanılabilir hale getirmek için günlük kaydı işlemi sırasında PID'yi otomatik olarak kaydeder ve dizine ekler. Kullanılabilir günlük alanları hakkında bilgi edinmek için şunu yazabilirsiniz:

Bunlardan bazılarını bu kılavuzun ilerleyen kısımlarında ele alacağız, ancak şimdilik bu alanlarla ilgili diğer bazı yararlı seçeneklere değineceğiz. Belirli bir günlük alanı için mevcut tüm değerleri görmek istiyorsanız -F seçeneğini kullanabilirsiniz. Systemd günlüğünün grup kimlikleri (GID) için neye sahip olduğunu görmek istiyorsanız, aşağıdakiler yapılabilir:

possible gid Journalctl

Bu, günlük grubu kimliği alanının depoladığı değerlerin tam bir listesini sağlayarak filtrelerin oluşturulmasına yardımcı olabilir.

Bileşen Yoluna Göre

Filtreleme, bir yol konumu sağlanarak da gerçekleştirilebilir. Yol bir yürütülebilir dosyaya aitse, bu yürütülebilir dosyayı içeren journalctl girdileri görüntülenecektir. İlgilendiğiniz yürütülebilir dosya 'bash' ise şunu yazabilirsiniz:

Bazen bunu yapmak mümkün olmasa da, yürütülebilir dosyanın birimi mevcutsa filtreleme için daha net ve daha bilgilendirici bir yöntem oluşturabilir.

Çekirdek Mesajlarını Görüntüleme

Genellikle dmesg çıktısında bulunan çekirdek mesajları da günlükten alınabilir. Yalnızca bu mesajların görüntülenmesini sağlamak için komutumuzun bir parçası olarak -k veya -dmesg bayraklarını kullanırız:

Varsayılan olarak mevcut önyüklemeden gelen mesajlar görüntülenir, ancak önceki önyüklemeler daha önce belirtilen seçim bayrağı kullanımıyla belirtilebilir. Beş önyükleme öncesine ait mesajları arıyorsanız, bunu yazmak size gerekli sonuçları verecektir:

Önceliğe Göre

Sistem yöneticileri genellikle önceliğe göre filtrelemeyi tercih eder. Düşük öncelikli günlükler, görüntülenmesi genellikle yararlı olsa da, kafa karıştırıcı olabilir ve birçok dikkat dağıtıcı unsur içerebilir, bu da analiz sırasında anlaşılmalarını zorlaştırır. Journalctl'de -p seçeneğinin kullanılması, diğer tüm öncelikleri filtreleyerek yalnızca belirtilen öncelikteki mesajları görüntüler. Hata seviyesi veya üzerindeki girdileri göstermek istiyorsanız, aşağıdakini girin:

Bu komut, standart syslog mesajlaşma seviyelerini kullanan günlük ile hata, uyarı (alert), acil durum (emergency) veya kritik (critical) olarak belirtilen tüm mesajları döndürecektir. Öncelik seviyeleri, en yüksekten en düşüğe doğru sıralanan sayısal bir değere göre tanımlanır:

  • 0: emerg
  • 1: alert
  • 2: crit
  • 3: err
  • 4: warning
  • 5: notice
  • 6: info
  • 7: debug

Yukarıdakilerden herhangi biri -p seçeneği ile birbirinin yerine kullanılabilir. Yukarıda belirtilen önceliklerden herhangi birinin seçilmesi, o seviyedeki ve üzerindeki tüm öncelikleri filtreleyecektir.

Günlükteki Görünümü Değiştirme

Girdi seçimi için filtreleme kullanmanın yanı sıra, çıktıyı değiştirerek journalctl'in görünümünü ihtiyaçlarımıza göre uyarlamak için başka yöntemlerimiz de vardır.

Çıktıyı Kısaltma/Genişletme

Journalctl'in verileri daraltıp daraltmayacağını veya genişletip genişletmeyeceğini ayarlayarak çıktımızın görünümünü ayarlayabiliriz. Journalctl'in varsayılan davranışı, girdinin tamamını göstermek ve daha uzun girdileri ekranın sağına doğru kaydırmaktır. Sağ ok tuşuyla kaydırarak girdileri bütünüyle görüntüleyebilirsiniz. Bir kullanıcı bunun yerine, aksi takdirde ekrandan taşacak olan satırlarda üç nokta gösterilecek şekilde çıktıyı kısaltmak isteyebilir. Bunun için bir –no-full seçeneği kullanılabilir:

no full option Journalctl

Alternatif olarak, -a bayrağını kullanarak uzunluğuna veya yazdırılamayan karakterler içerip içermediğine bakılmaksızın her şeyin görüntülenmesine de izin verebilirsiniz:

Standart Çıktıya Aktarma

Journalctl varsayılan olarak çıktıyı bir sayfalayıcıda (pager) görüntüler, ancak verileri metin düzenleme araçlarıyla işlemek istiyorsanız, çıktının standart bir çıktı seçeneğine oluşturulmasını isteyebilirsiniz. Bunu –no-pager seçeneğiyle gerçekleştirebilirsiniz:

Kullanıcının ihtiyaçlarına bağlı olarak bu, diskteki bir dosyaya veya bir işleme aracına yönlendirilebilir.

Çıktı Biçimleri

Veriler, daha kolay tüketilebilir bir biçimde sunulduğunda her zaman daha kolay ayrıştırılır. Günlük (journal), -o niteleyicisinin ardından özel olarak belirtilen bir biçim kullanılarak görüntüleme için birden fazla seçenek sunar.

Günlük girdilerini bir JSON biçiminde çıktı olarak almak istiyorsanız, bunu aşağıdaki şekilde yapabilirsiniz:

service logs in json

Bu strateji, özellikle ayrıştırma araçları kullanırken yararlıdır. json-pretty biçimi, veri yapılarını JSON tüketicisine aktarmadan önce görüntülemek için daha iyi olabilir:

output format json pretty Journalctl

Görüntüleme için kullanabileceğiniz birkaç biçim vardır:

  • cat: Yalnızca mesaj alanının kendisini görüntüler.
  • export: Aktarma veya yedekleme için uygun bir ikili (binary) biçim.
  • json: Satır başına bir girdi içeren standart JSON.
  • json-pretty: İnsan tarafından daha kolay okunabilmesi için biçimlendirilmiş JSON
  • json-sse: Sunucu tarafından gönderilen olaylarla (server-sent event) uyumlu hale getirmek için sarmalanmış JSON biçimli çıktı
  • short: Varsayılan syslog tarzı çıktı
  • short-iso: ISO 8601 duvar saati zaman damgalarını gösterecek şekilde genişletilmiş varsayılan biçim.
  • short-monotonic: Monotonik zaman damgalarına sahip varsayılan biçim.
  • short-precise: Mikrosaniye hassasiyetine sahip varsayılan biçim
  • verbose: Genellikle dahili olarak gizlenenler de dahil olmak üzere, girdi için mevcut olan her günlük alanını gösterir.

Yukarıdaki seçenekler, günlüğün tercih ettiğiniz biçimde görüntülenmesini sağlar.

Aktif Süreç İzleme

Günlük, başka bir araca ihtiyaç duymadan aktif veya son etkinlikleri izleme özelliklerine erişim sağlar. Bunu bir 'tail' işleviyle journalctl komutunu kullanarak yapabilirsiniz.

  • Son Günlükleri Görüntüleme

-n seçeneğinin kullanılması (tıpkı tail -n komutu gibi çalışır), belirli miktarda kaydın görüntülenmesini sağlayacaktır:

Görüntülenmesini istediğiniz girdi sayısı, -n niteleyicisinden sonra belirli bir sayı ile belirtilebilir:

  • Günlükleri Takip Etme

Ayrıca -f bayrağı ile sisteme yazılan günlükleri aktif olarak takip edebilirsiniz. Bu da tail -f komutuyla aynı şekilde çalışır:

Günlük Bakımı

Günlükler yer kaplar. Yer açmak amacıyla eski günlüklerin bazılarını temizlemek için bunu incelemeye değer.

Mevcut Disk Kullanımını Bulma

–disk-usage bayrağı, günlük kaydının şu anda diskte ne kadar yer kapladığını belirlemeye yardımcı olabilir:

disk usage Journalctl

Eski Günlükleri Silme

systemd sürüm 218 (ve sonraki sürümler) ile günlüğü iki farklı şekilde küçültebilirsiniz. Birincisi –vacuum-size seçeneğidir. Bu, boyutunu belirterek günlüğü küçültebilir. Başka bir deyişle, kaplanan alan istenen parametreye ulaşana kadar eski girdiler günlükten temizlenecektir:

–vacuum-time seçeneği, bir sınır süresi belirterek günlüğün kapladığı alanı küçültebilir; bu sürenin ötesindeki tüm girdiler silinirken, belirtilen süreden sonra oluşturulanlar korunur. Yalnızca son takvim yılına ait girdileri saklamak istiyorsanız şunu kullanabilirsiniz:

Günlük Genişlemesini Sınırlandırma

Günlüğün kaplayacağı alan miktarını da sınırlandırabilirsiniz. Bu, /etc/systemd.journald.conf dosyası düzenlenerek gerçekleştirilir. Günlük büyümesi aşağıdaki yöntemlerden herhangi biri kullanılarak sınırlandırılabilir:

  • SystemMaxUse=: Günlüğün kalıcı depolamada kullanmasına izin verilen maksimum disk alanını belirtir.
  • SystemKeepFree=: Günlük öğeleri kalıcı depolamaya eklendiğinde ne kadar alanın boş bırakılması gerektiğini belirtir.
  • SystemMaxFileSize=: Günlük dosyalarının kalıcı depolamada rotasyona uğramadan önce ne kadar büyümesine izin verileceğini belirtir.
  • RuntimeMaxUse=: Geçici depolamada (/run dosya sistemi içinde) ne kadar disk alanı kullanılmasına izin verileceğini belirtir.
  • RuntimeKeepFree=: Geçici depolamaya veri yazarken, bu işlev diğer kullanımlara ayrılması gereken alan miktarını belirtir (/run dosya sistemi içinde).
  • RuntimeMaxFileSize=: Tek bir günlük kaydının, rotasyona tabi tutulmadan önce geçici depolamada (/run dosya sistemi içinde) ne kadar yer kaplayabileceğini belirtir.

Bu seçeneklerin tümü, günlük tarafından tüketilen depolama alanının kontrol edilmesine yardımcı olabilir. Dikkat edilmesi gereken önemli bir husus, SystemMaxFileSize ve RuntimeMaxFileSize seçeneklerinin belirtilen sınırlara ulaşmak için arşivlenmiş dosyaları hedef alacağıdır. Bu, temizleme (vacuuming) işlemleri sonrasındaki dosya sayılarını yorumlarken akılda tutulması gereken önemli bir gerçektir.

Sonuç

systemd günlüğünün yararlanılabilecek inanılmaz derecede faydalı bir araç olduğu açıktır; faydalarının büyük bir kısmı günlüklerin’ merkezi yapısından ve kaydedilen meta verilerin kapsamlı hacminden kaynaklanmaktadır. Günlüğün kapsamlı özelliklerinden, journalctl komutunun kullanılmasıyla yararlanılabilir; bu da uygulama bileşenlerinin ilişkisel hata ayıklamasını gerçekleştirmenin yanı sıra kapsamlı sistem analizi yapmayı kolaylaştıran bir yöntem sunar.

Keyifli Bilişimler!

author

Akshay Nagpal

Yazar · CloudSigma

Preslav Dobrev, CloudSigma'da Kreatif Tasarımcı olarak görev yapmakta olup geleneksel ve yenilikçi pazarlama kanallarını kullanarak tutarlı bir kurumsal kimlik oluşturmaya odaklanmaktadır. Sanatsal vizyonu stratejik pazarlamayla harmanlayarak etkili marka anlatıları oluşturma konusunda oldukça yeteneklidir.

Yorumlar

Henüz yorum yapılmamış. İlk siz olun.