Héich Leeschtung an native Partitioning: Zabbix mat TimescaleDB Support

Zabbix ass e Iwwerwaachungssystem. Wéi all aner System, huet et dräi Haaptprobleemer vun all Iwwerwaachungssystemer: Sammelen a Veraarbechtung vun Donnéeën, Geschicht späicheren a botzen.

D'Etappe vum Empfang, Veraarbechtung an Opnam vun Daten huelen Zäit. Net vill, awer fir e grousse System kann dëst zu grousse Verspéidungen féieren. De Späicherproblem ass en Datezougang Thema. Si gi fir Berichter, Kontrollen an Ausléiser benotzt. Latenzen am Datezougang beaflossen och d'Performance. Wann Datenbanken wuessen, mussen irrelevant Daten geläscht ginn. Ewechzehuelen ass eng schwiereg Operatioun déi och e puer Ressourcen ësst.

Probleemer vu Verspéidungen während der Sammlung a Lagerung an Zabbix ginn duerch Cache geléist: verschidden Aarte vu Cache, Cache an der Datebank. Fir den drëtte Problem ze léisen, ass de Caching net gëeegent, sou datt Zabbix TimescaleDB benotzt. Hien wäert Iech doriwwer soen Andrey Gushchin - technesch Ënnerstëtzung Ingenieur Zabbix SIA. Andrey ënnerstëtzt Zabbix fir méi wéi 6 Joer an huet direkt Erfahrung mat Leeschtung.

Wéi funktionnéiert TimescaleDB, wéi eng Leeschtung kann et am Verglach zum normale PostgreSQL ginn? Wéi eng Roll spillt Zabbix fir d'TimescaleDB Datebank? Wéi vun Null unzefänken a wéi Dir vu PostgreSQL migréiert a wéi eng Konfiguratioun besser Leeschtung huet? Iwwer all dat ënner dem Schnëtt.

Produktivitéit Erausfuerderungen

All Iwwerwaachungssystem stellt spezifesch Leeschtungsfuerderunge vir. Ech wäert iwwer dräi vun hinnen schwätzen: Datesammlung a Veraarbechtung, Lagerung a Geschichtslässung.

Schnell Datensammlung a Veraarbechtung. E gudde Iwwerwaachungssystem soll séier all Donnéeën ophuelen an se no Ausléiserausdréck veraarbecht - no senge Critèren. No der Veraarbechtung muss de System dës Donnéeën och séier an der Datebank späicheren fir spéider ze benotzen.

Geschicht Stockage. E gudde Iwwerwaachungssystem soll d'Geschicht an enger Datebank späicheren an einfach Zougang zu Metriken ubidden. D'Geschicht ass néideg fir a Berichter, Grafiken, Ausléiser, Schwellen a berechent Alarmdatenartikelen ze benotzen.

Läscht Geschicht. Heiansdo kënnt en Dag wou Dir keng Metriken späichere musst. Firwat braucht Dir Daten, déi viru 5 Joer gesammelt goufen, e Mount oder zwee: e puer Node goufen geläscht, e puer Hosten oder Metriken sinn net méi gebraucht well se al sinn an net méi gesammelt sinn. E gudde Iwwerwaachungssystem soll historesch Daten späicheren an se vun Zäit zu Zäit läschen, sou datt d'Datebank net wiisst.

D'Botzen vun alen Donnéeën ass e kriteschen Thema deen d'Datebankleistung staark beaflosst.

Caching an Zabbix

An Zabbix ginn déi éischt an zweet Uruff mat Caching geléist. RAM gëtt benotzt fir Daten ze sammelen an ze veraarbecht. Fir Späicheren - Geschicht an Ausléiser, Grafiken a berechent Datenelementer. Op der Datebank Säit gëtt et e puer Cache fir Basisauswielen, zum Beispill Grafike.

Caching op der Säit vum Zabbix Server selwer ass:

• ConfigurationCache;
• ValueCache;
• GeschichtCache;
• TrendsCache.

Bedenkt se se méi detailléiert.

ConfigurationCache

Dëst ass den Haaptcache wou mir Metriken, Hosten, Dateartikelen, Trigger späicheren - alles wat mir brauchen fir PreProcessing a fir Datensammlung.

All dëst gëtt am ConfigurationCache gespäichert fir net onnéideg Ufroen an der Datebank ze kreéieren. Nodeems de Server ufänkt, aktualiséieren mir dëse Cache, kreéieren a periodesch aktualiséieren Konfiguratiounen.

Datensammlung

D'Diagramm ass zimmlech grouss, awer d'Haapt Saach an et ass pickers. Dëst si verschidde "Poller" - Versammlungsprozesser. Si si verantwortlech fir verschidden Aarte vu Versammlung: Si sammelen Daten iwwer SNMP, IPMI, a transferéieren se alles op PreProcessing.

D'Sammler sinn an orange duergestallt.

Zabbix huet Aggregatiounsartikele berechent déi néideg sinn fir Kontrollen ze aggregéieren. Wa mir se hunn, sichen mir d'Donnéeën fir si direkt vum ValueCache.

PreProcessing HistoryCache

All Sammler benotzen ConfigurationCache fir Aarbechtsplazen ze kréien. Duerno transferéiere se se op PreProcessing.

PreProcessing benotzt ConfigurationCache fir PreProcessing Schrëtt ze kréien. Et veraarbecht dës Donnéeën op verschidde Manéieren.

No der Veraarbechtung vun den Donnéeën mat PreProcessing späichere mir se am HistoryCache fir d'Veraarbechtung. Dëst endet d'Datesammlung a mir ginn op den Haaptprozess an Zabbix - Geschicht Synchroniséierung, well et eng monolithesch Architektur ass.

Bemierkung: PreProcessing ass eng zimlech schwéier Operatioun. Mat v 4.2 gouf et op Proxy geplënnert. Wann Dir e ganz grousse Zabbix mat enger grousser Zuel vun Datenelementer a Sammelfrequenz hutt, da mécht dat d'Aarbecht vill méi einfach.

ValueCache, Geschicht & Trends Cache

Geschicht Synchroniséierung ass den Haaptprozess deen all Dateelement atomesch veraarbecht, dat heescht all Wäert.

Geschicht Synchroniséierung hëlt Wäerter aus HistoryCache a kontrolléiert d'Konfiguratioun fir d'Präsenz vun Trigger fir Berechnungen. Wann se existéieren, berechent et.

Geschicht Synchroniséierung erstellt en Event, Eskalatioun fir Alarmer ze kreéieren wann néideg duerch Konfiguratioun, an records. Wann et Ausléiser fir déi spéider Veraarbechtung gëtt, späichert et dëse Wäert am ValueCache fir net op d'Geschichtstabelle ze kommen. Dëst ass wéi ValueCache mat Daten gefëllt ass, déi néideg sinn fir Ausléiser a berechent Elementer ze berechnen.

Geschicht Synchroniséierung schreift all Daten an d'Datebank, an et schreift op Scheif. De Veraarbechtungsprozess endet hei.

Cache an der Datebank

Op der Datebank Säit ginn et verschidde Cache wann Dir Grafiken oder Berichter iwwer Eventer kucke wëllt:

• Innodb_buffer_pool op der MySQL Säit;
• shared_buffers op der PostgreSQL Säit;
• effective_cache_size op der Oracle Säit;
• shared_pool op der DB2 Säit.

Et gi vill aner Cache, awer dës sinn d'Haaptvirdeeler fir all Datenbanken. Si erlaben Iech Daten am RAM ze späicheren déi dacks fir Ufroen gebraucht ginn. Si hunn hir eege Technologien fir dëst.

D'Datebankleistung ass kritesch

Den Zabbix Server sammelt konstant Daten a schreift se. Wann et nei gestart gëtt, liest et och aus der Geschicht fir de ValueCache ze fëllen. Benotzt Scripten a Berichter Zabbix API, déi op engem Web Interface gebaut ass. Zabbix API kritt Zougang zu der Datebank an recuperéiert déi néideg Donnéeën fir Grafiken, Berichter, Eventlëschten a lescht Themen.

Fir Visualiséierung - grafana. Dëst ass eng populär Léisung ënnert eise Benotzer. Et kann direkt Ufroen duerch d'Zabbix API an d'Datebank schécken, a schaaft e gewësse Concours fir Daten ze kréien. Dofir ass méi fein a besser Ofstëmmung vun der Datebank gebraucht fir mat der schneller Liwwerung vu Resultater an Tester ze passen.

Haushälterin

Déi drëtt Leeschtung Erausfuerderung an Zabbix ass d'Geschicht Clearing mat Haushalter. Et follegt all Astellungen - d'Datenelementer weisen wéi laang d'Dynamik vun Ännerungen (Trends) an Deeg gespäichert gëtt.

Mir berechnen TrendsCache op der Flucht. Wann d'Donnéeën ukommen, aggregéiere mir et fir eng Stonn a notéieren se an Tabellen fir d'Dynamik vun Trendännerungen.

Hausmeeschter fänkt un an läscht Informatiounen aus der Datebank benotzt déi üblech "auswielt". Dëst ass net ëmmer effikass, wéi aus de Performance Grafike vun intern Prozesser gesi kann.

Déi rout Grafik weist datt de History Syncer dauernd beschäftegt ass. Déi orange Grafik uewen ass Housekeeper, déi stänneg leeft. Hie waart op d'Datebank fir all d'Zeilen ze läschen, déi hien uginn huet.

Wéini sollt Dir Housekeeper deaktivéieren? Zum Beispill gëtt et eng "Item ID" an Dir musst déi lescht 5 dausend Reihen bannent enger gewësser Zäit läschen. Natierlech geschitt dat duerch Index. Awer normalerweis ass den Dataset ganz grouss, an d'Datebank liest nach ëmmer vun der Disk a setzt se an de Cache. Dëst ass ëmmer eng ganz deier Operatioun fir d'Datebank an, ofhängeg vun der Gréisst vun der Datebank, kann zu Leeschtungsproblemer féieren.

Hausmeeschter ass einfach ze deaktivéieren. Am Web-Interface gëtt et eng Astellung an "General Administratioun" fir Hausmeeschter. Mir deaktivéieren intern Housekeeping fir intern Trendgeschicht an et geréiert et net méi.

Haushälterin war ausgeschalt, d'Grafiken ausgeglach - wéi eng Problemer kéinten et an dësem Fall sinn a wat kéint hëllefen déi drëtt Leeschtungsfuerderung ze léisen?

Partitionéieren - Partitionéieren oder Partitionéieren

Typesch ass d'Partitionéierung op eng aner Manéier op all relational Datebank konfiguréiert déi ech opgelëscht hunn. Jiddereen huet seng eege Technologie, awer si sinn allgemeng ähnlech. D'Erstelle vun enger neier Partition féiert dacks zu bestëmmte Problemer.

Typesch sinn d'Partitionen ofhängeg vum "Setup" konfiguréiert - d'Quantitéit vun Daten déi an engem Dag erstallt ginn. Als Regel, Partitioning gëtt an engem Dag erausginn, dëst ass de Minimum. Fir Trends vun enger neier Batch - 1 Mount.

D'Wäerter kënne änneren wann de "Setup" ganz grouss ass. Wann e klenge "Setup" bis zu 5 nvps (nei Wäerter pro Sekonn) ass, ass e mëttelméisseg vu 000 bis 5, dann ass e groussen iwwer 000 nvps. Dëst si grouss a ganz grouss Installatiounen déi virsiichteg Konfiguratioun vun der Datebank erfuerderen.

Op ganz groussen Installatiounen kann eng Period vun engem Dag net optimal sinn. Ech hunn MySQL Partitionen vun 40 GB oder méi pro Dag gesinn. Dëst ass eng ganz grouss Quantitéit un Donnéeën déi Problemer verursaache kënnen a musse reduzéiert ginn.

Wat gëtt Partitioning?

Partitioning Dëscher. Dacks sinn dës separat Dateien op Disk. De Ufroplang wielt eng Partition méi optimal. Normalerweis gëtt d'Partitionéierung vum Range benotzt - dëst ass och wouer fir Zabbix. Mir benotzen "Zäitstempel" do - Zäit zënter dem Ufank vun der Ära. Dëst sinn normal Zuelen fir eis. Dir setzt den Ufank an Enn vum Dag - dëst ass eng Partition.

Schnell Entfernung - DELETE. Ee Fichier / Ënnertabell ass ausgewielt, anstatt eng Auswiel u Reihen fir ze läschen.

Beschleunegt d'Datenrecuperatioun bedeitend SELECT - benotzt eng oder méi Partitionen, anstatt de ganzen Dësch. Wann Dir Zougang zu Daten kritt, déi zwee Deeg al sinn, ginn se méi séier aus der Datebank zréckgezunn, well Dir braucht nëmmen eng Datei an de Cache ze lueden an zréckzeginn, net e groussen Dësch.

Dacks ginn och vill Datenbanken beschleunegt INSERT - Inserts an d'Kannertabelle.

ZäitplangDB

Fir v 4.2 hu mir eis op TimescaleDB opmierksam gemaach. Dëst ass eng Extensioun fir PostgreSQL mat engem nativen Interface. D'Extensioun funktionéiert effektiv mat Zäitseriedaten, ouni d'Virdeeler vun relational Datenbanken ze verléieren. TimescaleDB partitionéiert och automatesch.

TimescaleDB huet e Konzept hypertable (hypertabel) déi Dir erstellt. Et enthält Stécker - Partitionen. Chunks sinn automatesch verwaltete hypertable Fragmenter déi net aner Fragmenter beaflossen. All Stéck huet säin eegent Zäitraum.

TimescaleDB vs PostgreSQL

TimescaleDB funktionnéiert wierklech effizient. D'Fabrikanten vun der Extensioun behaapten datt se e méi korrekten Ufroveraarbechtung Algorithmus benotzen, besonnesch inserts . Wéi d'Datesets Insertgréisst wiisst, hält den Algorithmus konstant Leeschtung.

No 200 Millioune Reihen fänkt PostgreSQL normalerweis wesentlech un a verléiert d'Performance op 0. TimescaleDB erlaabt Iech effizient "Inserts" fir all Quantitéit vun Daten anzeginn.

Kader

TimescaleDB installéieren ass zimmlech einfach fir all Package. IN Dokumentatioun alles gëtt am Detail beschriwwen - et hänkt vun den offiziellen PostgreSQL Packagen of. TimescaleDB kann och manuell gebaut a kompiléiert ginn.

Fir d'Zabbix Datebank aktivéiere mir einfach d'Extensioun:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

Dir aktivéiert extension a kreéiert et fir d'Zabbix Datebank. De leschte Schrëtt ass eng Hypertable ze kreéieren.

Migratioun vun Geschichtstabellen op TimescaleDB

Et gëtt eng speziell Funktioun fir dëst create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

D'Funktioun huet dräi Parameteren. Éischten - Dësch an der Datebank, fir deen Dir musst en Hypertable erstellen. Zweeten - Gebitt, no deem Dir musst schafen chunk_time_interval - Intervall vun Partition Stécker ze benotzen. A mengem Fall ass den Intervall een Dag - 86.

Drëtte Parameter - migrate_data. Wann Dir setzt true, da ginn all aktuell Donnéeën op virgeschaafte Stécker transferéiert. Ech hunn et selwer benotzt migrate_data. Ech hat ongeféier 1 TB, wat iwwer eng Stonn gedauert huet. Och an e puer Fäll, wärend dem Test, hunn ech historesch Daten vu Charaktertypen geläscht, déi net fir d'Späichere erfuerderlech waren, fir se net ze transferéieren.

De leschte Schrëtt - UPDATE: an v db_extension setzen timescaledbsou datt d'Datebank versteet datt dës Extensioun existéiert. Zabbix aktivéiert et a benotzt d'Syntax an d'Ufroen an d'Datebank korrekt - déi Funktiounen déi néideg sinn fir TimescaleDB.

Hardware Configuratioun

Ech hunn zwee Serveren benotzt. Éischten - VMware Maschinn. Et ass relativ kleng: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz Prozessoren, 16 GB RAM an eng 200 GB SSD.

Ech installéiert PostgreSQL 10.8 op et mat Debian 10.8-1.pgdg90+1 OS an xfs Dateisystem. Ech hunn alles minimal konfiguréiert fir dës speziell Datebank ze benotzen, minus wat Zabbix selwer benotzt.

Op der selwechter Maschinn war e Zabbix Server, PostgreSQL an Luede Agenten. Ech hat 50 aktiv Agenten déi benotzt hunn LoadableModulefir ganz séier verschidde Resultater ze generéieren: Zuelen, Strings. Ech hunn d'Datebank mat vill Daten gefëllt.

Ufanks enthält d'Konfiguratioun 5 Elementer Daten pro Host. Bal all Element enthält en Ausléiser fir et ähnlech wéi real Installatiounen ze maachen. A verschiddene Fäll gouf et méi wéi een Ausléiser. Fir een Netzknuet gouf et 3-000 Ausléiser.

Dateartikel Update Intervall - 4-7 Sekonnen. Ech hunn d'Belaaschtung selwer geregelt andeems ech net nëmmen 50 Agenten benotzen, awer méi derbäi. Och mat Datenelementer hunn ech d'Laascht dynamesch ugepasst an d'Aktualiséierungsintervall op 4 s reduzéiert.

PostgreSQL. 35 nvps

Meng éischt Laf op dëser Hardware war op pure PostgreSQL - 35 Tausend Wäerter pro Sekonn. Wéi Dir gesitt, dauert d'Aféierung vun Daten Fraktiounen vun enger Sekonn - alles ass gutt a séier. Dat eenzegt ass datt en 200 GB SSD Disk séier fëllt.

Dëst ass e Standard Zabbix Server Performance Dashboard.

Déi éischt blo Grafik ass d'Zuel vun de Wäerter pro Sekonn. Déi zweet Grafik op der rietser ass d'Luede vu Bauprozesser. Déi drëtt ass lueden intern Bauprozesser: Geschichtssynchroniséierer an Haushalter, déi scho laang hei leeft.

Déi véiert Grafik weist d'GeschichtCache Benotzung. Dëst ass eng Zort Puffer ier Dir an d'Datebank setzt. Déi gréng fënneft Grafik weist ValueCache Notzung, dat ass, wéi vill ValueCache Hits fir Ausléiser - dat ass e puer dausend Wäerter pro Sekonn.

PostgreSQL. 50 nvps

Duerno hunn ech d'Laascht op 50 Tausend Wäerter pro Sekonn op der selwechter Hardware erhéicht.

Beim Luede vum Haushalter huet d'Aféierung vun 10 Tausend Wäerter 2-3 Sekonnen gedauert.

Hausmeeschter fänkt schonn un d'Aarbecht ze stéieren.

Déi drëtt Grafik weist, datt, am Allgemengen, d'Laascht op Trapper a Geschicht Syncher nach bei 60% ass. An der véierter Grafik fänkt HistoryCache scho ganz aktiv un während der Housekeeper Operatioun ze fëllen. Et ass 20% voll, dat ass ongeféier 0,5 GB.

PostgreSQL. 80 nvps

Duerno hunn ech d'Laascht op 80 Tausend Wäerter pro Sekonn erhéicht. Dëst ass ongeféier 400 Tausend Datenelementer an 280 Tausend Ausléiser.

D'Laaschtkäschte vun drësseg Geschicht Syncher si scho relativ héich.

Ech hunn och verschidde Parameteren erhéicht: Geschicht Syncer, Cache.

Op menger Hardware ass d'Luede vu Geschichtssynchronisateuren op de Maximum eropgaang. HistoryCache séier mat Daten gefëllt - Daten fir d'Veraarbechtung haten am Puffer gesammelt.

All dës Kéier hunn ech observéiert wéi de Prozessor, RAM an aner Systemparameter benotzt goufen, a fonnt datt d'Disknutzung maximal war.

Ech hunn d'Benotzung erreecht maximal Scheif Kënnen op dëser Hardware an op dëser virtueller Maschinn. Mat esou enger Intensitéit huet PostgreSQL ugefaang Daten zimlech aktiv ze spülen, an d'Disk hat keng Zäit méi ze schreiwen a liesen.

Zweeten Server

Ech hunn en anere Server geholl, dee schonn hat 48 Prozessoren an 128 GB RAM. Ech hunn et ofgestëmmt - gesat et op 60 Geschicht Synchroniséierung, an erreecht akzeptabel Leeschtung.

Tatsächlech ass dëst schonn d'Limite vun der Produktivitéit, wou eppes muss gemaach ginn.

Zäitskala DB. 80 nvps

Meng Haaptaufgab ass d'Fäegkeeten vun TimescaleDB géint Zabbix Last ze testen. 80 Tausend Wäerter pro Sekonn ass vill, d'Frequenz vun de Metriken ze sammelen (ausser Yandex, natierlech) an e relativ grousse "Setup".

Et gëtt en Dip an all Grafik - dat ass genau d'Datemigratioun. No Feeler am Zabbix-Server huet de Luedeprofil vum Geschichtssynzer vill geännert - et ass dräimol erofgaang.

TimescaleDB erlaabt Iech Daten bal 3 Mol méi séier anzeginn a manner HistoryCache ze benotzen.

Deementspriechend kritt Dir Donnéeën op eng fristgerecht Manéier.

Zäitskala DB. 120 nvps

Duerno hunn ech d'Zuel vun den Datenelementer op 500 Tausend erhéicht. D'Haaptaufgab war d'Fäegkeeten vun TimescaleDB ze testen - ech krut e berechent Wäert vun 125 Tausend Wäerter pro Sekonn.

Dëst ass e funktionnéierende "Setup" dee fir eng laang Zäit funktionnéiert. Awer well meng Disk nëmmen 1,5 TB war, hunn ech se an e puer Deeg ausgefëllt.

Déi wichtegst Saach ass datt gläichzäiteg nei TimescaleDB Partitionen erstallt goufen.

Dëst ass komplett onmerkbar fir d'Leeschtung. Wann zum Beispill Partitionen am MySQL erstallt ginn, ass alles anescht. Dëst geschitt normalerweis an der Nuecht well et allgemeng Insertion blockéiert, schafft mat Dëscher a kann Servicedegradatioun erstellen. Dëst ass net de Fall mat TimescaleDB.

Als Beispill wäert ech eng Grafik vu villen an der Gemeinschaft weisen. Am Bild ass TimescaleDB aktivéiert, dank deem d'Laascht op d'Benotzung vum io.Weight op de Prozessor erofgaang ass. D'Benotzung vun intern Prozess Elementer och ofgeholl. Ausserdeem ass dëst eng gewéinlech virtuell Maschinn op gewéinleche Pancake Disken, net eng SSD.

Conclusiounen

TimescaleDB ass eng gutt Léisung fir kleng "Setup", déi d'Performance vun der Disk beaflossen. Et erlaabt Iech weider gutt ze schaffen bis d'Datebank sou séier wéi méiglech op d'Hardware migréiert gëtt.

TimescaleDB ass einfach ze konfiguréieren, gëtt Leeschtung Gewënn, Wierker gutt mat Zabbix an huet Virdeeler iwwer PostgreSQL.

Wann Dir PostgreSQL benotzt an net plangt et z'änneren, ech recommandéieren benotzt PostgreSQL mat der TimescaleDB Extensioun a Verbindung mat Zabbix. Dës Léisung funktionnéiert effektiv bis zu engem mëttleren "Setup".

Wa mir soen "héich Leeschtung" mir mengen HighLoad++. Dir wäert net laang waarden fir iwwer d'Technologien a Praktiken ze léieren, déi Servicer erlaben Millioune Benotzer ze déngen. Lëscht Rapporten fir 7. an 8. November hu mir schonn zesummegesat, mä hei treffen méi kënne proposéiert ginn.

Abonnéiert Iech op eis Newsletter и Hëllefe profitéieren, an deem mir d'Features vun der kommender Konferenz verroden, an erausfannen, wéi mir dat Bescht dovunner kréien.

Source: will.com