Prometheus 2-dəki zaman seriyası verilənlər bazası (TSDB) məlumatların toplanması və sorğuların icra sürəti və resurs səmərəliliyi baxımından Prometheus 2 saxlama v1 üzərində əhəmiyyətli təkmilləşdirmələr təklif edən mühəndislik həllinin gözəl nümunəsidir. Biz Prometheus 2-ni Percona Monitorinq və İdarəetmədə (PMM) tətbiq edirdik və mənim Prometheus 2 TSDB-nin performansını anlamaq fürsətim oldu. Bu yazıda bu müşahidələrin nəticələri haqqında danışacağam.
Prometheus Orta İş Yükü
Ümumi təyinatlı verilənlər bazası ilə məşğul olanlar üçün tipik Prometheus iş yükü olduqca maraqlıdır. Məlumatların yığılma sürəti sabit olmağa meyllidir: adətən nəzarət etdiyiniz xidmətlər təxminən eyni miqdarda göstəricilər göndərir və infrastruktur nisbətən yavaş dəyişir.
İnformasiya sorğuları müxtəlif mənbələrdən gələ bilər. Onlardan bəziləri, siqnallar kimi, sabit və proqnozlaşdırıla bilən bir dəyər hədəfləyir. Digərləri, məsələn, istifadəçi sorğuları, sıçrayışlara səbəb ola bilər, baxmayaraq ki, bu, əksər iş yükləri üçün belə deyil.
Yük sınağı
Test zamanı mən məlumat toplamaq qabiliyyətinə diqqət yetirdim. Mən bu skriptdən istifadə edərək Linode xidmətində Go 2.3.2 (PMM 1.10.1-ün bir hissəsi kimi) ilə tərtib edilmiş Prometheus 1.14-ni yerləşdirdim: . Bununla ən real yük generasiyası üçün Hər biri 10 Linux/MySQL qovşağını təqlid edən real yüklə (Sysbench TPC-C Testi) bir neçə MySQL qovşağını işlətmişəm.
Aşağıdakı testlərin hamısı səkkiz vCore və 32 GB yaddaşa malik Linode serverində 20 MySQL instansiyasına nəzarət edən 800 yük simulyasiyası ilə həyata keçirilib. Və ya Prometey baxımından 440 hədəf (hədəf), saniyədə 380 ödəniş (scrapes), saniyədə 1,7 min qeyd (nümunə) və XNUMX milyon aktiv zaman seriyası.
Layihə
Prometheus 1.x tərəfindən istifadə edilən də daxil olmaqla adi ənənəvi verilənlər bazası yanaşması . Əgər yükü idarə etmək kifayət deyilsə, siz yüksək gecikmə ilə qarşılaşacaqsınız və bəzi sorğular yerinə yetirilməyəcək. Prometheus 2-də yaddaş istifadəsi açar vasitəsilə konfiqurasiya edilə bilər storage.tsdb.min-block-duration, bu, qeydlərin diskə atılmadan əvvəl yaddaşda nə qədər saxlanılacağını müəyyən edir (standart olaraq 2 saatdır). Tələb olunan yaddaşın miqdarı vaxt seriyalarının, etiketlərin və qırıntıların sayından, həmçinin xalis girişdən asılı olacaq. Disk sahəsi baxımından Prometheus hər yazma üçün 3 baytdan istifadə etməyi hədəfləyir (nümunə). Digər tərəfdən, yaddaş tələbləri daha yüksəkdir.
Blok ölçüsünü konfiqurasiya etmək mümkün olsa da, onu əl ilə təyin etmək tövsiyə edilmir, ona görə də Prometeyə iş yükünüz üçün lazım olan qədər yaddaş vermək vəzifəsi qalır.
Daxil olan ölçüləri dəstəkləmək üçün kifayət qədər yaddaş yoxdursa, Prometey yaddaşdan düşəcək və ya OOM qatili tərəfindən tutulacaq.
Prometheus yaddaşı bitdikdə qəzanı gecikdirmək üçün dəyişdirmə əlavə etmək həqiqətən kömək etmir, çünki bu funksiyadan istifadə yaddaş partlayışlarına səbəb olur. Düşünürəm ki, söhbət Go, onun zibil toplayıcısı və onun dəyişdirmə ilə necə işləməsi haqqındadır.
Başqa bir maraqlı yanaşma, baş blokunu prosesin başladığı vaxtdan hesablamaq əvəzinə, müəyyən bir zamanda diskə yuyulacaq şəkildə qurmaqdır.
Qrafikdən göründüyü kimi, diskə axınlar hər iki saatdan bir baş verir. Əgər min-blok müddəti parametrini bir saata dəyişsəniz, bu sıfırlamalar yarım saatdan başlayaraq hər saat baş verəcəkdir.
Bunu və digər qrafikləri Prometheus quraşdırmanızda istifadə etmək istəyirsinizsə, bundan istifadə edə bilərsiniz . O, PMM üçün nəzərdə tutulmuşdur, lakin bir neçə modifikasiya ilə istənilən Prometheus quraşdırmasına uyğun gəlir.
Bizim yaddaşda saxlanılan baş blok adlanan aktiv blokumuz var; köhnə məlumatları olan bloklar vasitəsilə mövcuddur mmap(). Bu, keşi ayrıca konfiqurasiya etmək ehtiyacını aradan qaldırır, həm də o deməkdir ki, baş blokdan daha köhnə məlumatları sorğulamaq istəyirsinizsə, əməliyyat sisteminin keşi üçün kifayət qədər yer buraxmalısınız.
Bu həm də o deməkdir ki, Prometeyin virtual yaddaş istehlakı kifayət qədər yüksək görünəcək, bu da narahat olmağa dəyməz.
Başqa bir maraqlı dizayn nöqtəsi WAL-ın istifadəsidir (qabaqda yazın). Repozitor sənədlərindən göründüyü kimi, Prometey qəzaların qarşısını almaq üçün WAL-dan istifadə edir. Təəssüf ki, məlumatların sağ qalmasına zəmanət verən xüsusi mexanizmlər yaxşı sənədləşdirilməyib. Prometheus 2.3.2 WAL-ı hər 10 saniyədən bir diskə silir və bu parametr istifadəçi tərəfindən konfiqurasiya edilə bilməz.
Möhürlər
Prometheus TSDB LSM yaddaşının (Log Structured birləşməsi - log-structured birləşmə ağacı) təsvirində nəzərdə tutulmuşdur: baş blok vaxtaşırı diskə yuyulur, sıxılma mexanizmi isə sorğular üzrə çoxlu blokları skan etməmək üçün bir neçə bloku birləşdirir. Burada bir günlük yükləmədən sonra test sistemində müşahidə etdiyim blokların sayını görə bilərsiniz.
Yaddaş haqqında daha çox öyrənmək istəyirsinizsə, mövcud bloklar və onların necə yarandığı haqqında məlumat olan meta.json faylına baxa bilərsiniz.
{
"ulid": "01CPZDPD1D9R019JS87TPV5MPE",
"minTime": 1536472800000,
"maxTime": 1536494400000,
"stats": {
"numSamples": 8292128378,
"numSeries": 1673622,
"numChunks": 69528220
},
"compaction": {
"level": 2,
"sources": [
"01CPYRY9MS465Y5ETM3SXFBV7X",
"01CPYZT0WRJ1JB1P0DP80VY5KJ",
"01CPZ6NR4Q3PDP3E57HEH760XS"
],
"parents": [
{
"ulid": "01CPYRY9MS465Y5ETM3SXFBV7X",
"minTime": 1536472800000,
"maxTime": 1536480000000
},
{
"ulid": "01CPYZT0WRJ1JB1P0DP80VY5KJ",
"minTime": 1536480000000,
"maxTime": 1536487200000
},
{
"ulid": "01CPZ6NR4Q3PDP3E57HEH760XS",
"minTime": 1536487200000,
"maxTime": 1536494400000
}
]
},
"version": 1
}Prometeydəki möhürlər baş blokunun diskə yuyulduğu vaxta bağlıdır. Bu nöqtədə bir neçə belə əməliyyat həyata keçirilə bilər.
Görünür ki, sıxılmalar heç bir şəkildə məhdudlaşdırılmır və icra zamanı böyük disk I/O sıçrayışlarına səbəb ola bilər.
CPU yükü sıçrayışları
Əlbəttə ki, bu, sistemin sürətinə kifayət qədər mənfi təsir göstərir və eyni zamanda LSM anbarları üçün ciddi problemdir: çox yüklənmədən yüksək sorğu sürətlərini dəstəkləmək üçün sıxılmaları necə etmək olar?
Sıxılma prosesində yaddaşın istifadəsi də olduqca maraqlı görünür.
Sıxlaşdırıldıqdan sonra yaddaşın əksəriyyətinin vəziyyəti Keşlənmişdən Azad vəziyyətə necə dəyişdiyini görə bilərik: bu, potensial dəyərli məlumatın oradan silinməsi deməkdir. Maraqlıdır ki, burada istifadə olunub fadvice() və ya başqa bir minimuma endirmə texnikası, yoxsa keşin sıxılma nəticəsində məhv edilmiş blokların boşaldılması ilə bağlıdır?
Uğursuzluğun Bərpası
Fəlakətin bərpası vaxt tələb edir və bunun yaxşı səbəbi var. Saniyədə bir milyon qeyddən ibarət gələn bir axın üçün bərpa SSD sürücüsünü nəzərə alaraq təxminən 25 dəqiqə gözləməli oldum.
level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Starting Prometheus" version="(version=2.3.2, branch=v2.3.2, revision=71af5e29e815795e9dd14742ee7725682fa14b7b)"
level=info ts=2018-09-13T13:38:14.096599879Z caller=main.go:223 build_context="(go=go1.10.1, user=Jenkins, date=20180725-08:58:13OURCE)"
level=info ts=2018-09-13T13:38:14.096624109Z caller=main.go:224 host_details="(Linux 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 1bee9e9b78cf (none))"
level=info ts=2018-09-13T13:38:14.096641396Z caller=main.go:225 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2018-09-13T13:38:14.097715256Z caller=web.go:415 component=web msg="Start listening for connections" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Starting TSDB ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="router prefix" prefix=/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL corruption detected; truncating" err="unexpected CRC32 checksum d0465484, want 0" file=/opt/prometheus/data/.prom2-data/wal/007357 pos=15504363
level=info ts=2018-09-13T14:05:19.471459777Z caller=main.go:543 msg="TSDB started"
level=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Loading configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Completed loading of configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Server is ready to receive web requests."Bərpa prosesinin əsas problemi yüksək yaddaş istehlakıdır. Normal vəziyyətdə server eyni həcmdə yaddaşla stabil işləyə bilsə də, çökərsə, OOM səbəbindən yüksəlməyə bilər. Tapdığım yeganə həll yolu məlumatların toplanmasını söndürmək, serveri işə salmaq, onu bərpa etmək və kolleksiyanı aktivləşdirərək yenidən yükləməkdir.
İstiləşmə
İstiləşmə zamanı nəzərə alınmalı olan başqa bir davranış, işə başladıqdan dərhal sonra aşağı performansın yüksək resurs istehlakına nisbətidir. Bəzi başlanğıclarda, lakin hamısında deyil, CPU və yaddaşda ciddi bir yük müşahidə etdim.
Yaddaş istifadəsində azalmalar göstərir ki, Prometheus əvvəldən bütün ödənişləri konfiqurasiya edə bilmir və bəzi məlumatlar itirilir.
Yüksək CPU və yaddaş istifadəsinin dəqiq səbəblərini öyrənməmişəm. Güman edirəm ki, bu, baş blokda yüksək tezlikli yeni zaman sıralarının yaradılması ilə bağlıdır.
CPU sıçrayışları
Kifayət qədər yüksək I/O yükü yaradan sıxlaşmalara əlavə olaraq, hər iki dəqiqədən bir CPU yükündə ciddi sıçrayışlar müşahidə etdim. Partlayışlar yüksək gələn trafiklə daha uzun olur və Go zibil kollektorundan qaynaqlanır, ən azı bəzi nüvələr tam yüklənir.
Bu sıçrayışlar o qədər də əhəmiyyətsiz deyil. Belə görünür ki, onlar baş verdikdə, Prometey daxili giriş nöqtəsi və ölçüləri əlçatmaz olur və eyni vaxt intervallarında məlumatların azalmasına səbəb olur.
Prometheus ixracatçısının bir saniyəlik bağlandığını da görə bilərsiniz.
Zibil toplama (GC) ilə əlaqəni görə bilərik.
Nəticə
Prometheus 2-dəki TSDB sürətlidir, milyonlarla zaman seriyasını və eyni zamanda kifayət qədər təvazökar avadanlıqdan istifadə edərək saniyədə minlərlə yazmağı idarə edə bilir. CPU və disk I/O istifadəsi də təsir edicidir. Mənim nümunəm hər istifadə olunan nüvəyə saniyədə 200-ə qədər göstərici göstərdi.
Genişlənməni planlaşdırmaq üçün kifayət qədər yaddaş olduğunu xatırlamaq lazımdır və bu, real yaddaş olmalıdır. Müşahidə etdiyim istifadə olunan yaddaşın miqdarı, daxil olan axının saniyədə 5 qeydinə təxminən 100 GB idi ki, bu da əməliyyat sisteminin önbelleği ilə ümumilikdə təxminən 000 GB işğal edilmiş yaddaş verir.
Əlbəttə ki, CPU və disk giriş/çıxış sıçrayışlarını ram etmək üçün hələ çox iş görülməlidir və bu təəccüblü deyil, çünki gənc TSDB Prometheus 2 InnoDB, TokuDB, RocksDB, WiredTiger ilə müqayisə olunur, lakin onların hamısında var idi. həyat dövrünün başlanğıcında oxşar problemlər.
Mənbə: www.habr.com