Moien alleguer, mäin Numm ass Alexander, ech schaffen beim CIAN als Ingenieur an sinn an der Systemadministratioun an der Automatisatioun vun Infrastrukturprozesser involvéiert. An de Kommentaren zu engem vun de fréieren Artikele goufe mir gefrot ze soen wou mir 4 TB Logbicher pro Dag kréien a wat mir mat hinnen maachen. Jo, mir hu vill Logbicher, an e separaten Infrastrukturcluster gouf erstallt fir se ze veraarbechten, wat eis erlaabt séier Problemer ze léisen. An dësem Artikel wäert ech schwätzen iwwer wéi mir et am Laf vun engem Joer adaptéiert hunn fir mat engem ëmmer wuessende Flux vun Daten ze schaffen.
Wou hu mer ugefaang?
An de leschte Joren ass d'Laascht op cian.ru ganz séier gewuess, a vum drëtten Trimester vun 2018 erreecht de Ressourceverkéier 11.2 Milliounen eenzegaarteg Benotzer pro Mount. Zu där Zäit hu mir a kriteschen Momenter bis zu 40% vun de Logbicher verluer, dofir konnte mir net séier mat Tëschefäll ëmgoen a vill Zäit an Effort verbruecht hunn fir se ze léisen. Mir konnten och dacks d'Ursaach vum Problem net fannen, an e géif sech no enger Zäit erëmfannen. Et war Häll an eppes huet misse gemaach ginn.
Zu där Zäit hu mir e Stärekoup vun 10 Dateknäppchen mat ElasticSearch Versioun 5.5.2 mat Standard Index Astellunge benotzt fir Logbicher ze späicheren. Et gouf viru méi wéi engem Joer als populär a bezuelbar Léisung agefouert: dann war de Floss vu Logbicher net sou grouss, et war kee Sënn fir net-Standard Konfiguratiounen ze kommen.
Veraarbechtung vun erakommen Logbicher gouf vum Logstash op verschiddene Ports op fënnef ElasticSearch Koordinatoren zur Verfügung gestallt. Een Index, onofhängeg vun der Gréisst, bestoung aus fënnef Schnëtt. Eng Stonn an alldeeglech Rotatioun gouf organiséiert, als Resultat sinn all Stonn ongeféier 100 nei Schiermer am Cluster opgetaucht. Och wann et net ganz vill Logbicher waren, huet de Stärekoup gutt gepackt a keen huet op seng Astellungen opmierksam gemaach.
D'Erausfuerderunge vun rapid Wuesstem
De Volume vun generéierte Logbicher ass ganz séier gewuess, well zwee Prozesser sech iwwerlappt hunn. Engersäits ass d'Zuel vun de Benotzer vum Service gewuess. Op der anerer Säit hu mir ugefaang aktiv op eng Mikroservicearchitektur ze wiesselen, eis al Monolithen an C # a Python ze gesinn. E puer Dutzend nei Mikroservicer, déi Deeler vum Monolith ersat hunn, hunn wesentlech méi Logbicher fir den Infrastrukturcluster generéiert.
Et war Skaléieren déi eis zum Punkt gefouert huet wou de Stärekoup praktesch onmanéierbar gouf. Wann d'Logbicher ugefaang hunn mat enger Rate vun 20 Tausend Messagen pro Sekonn ze kommen, heefeg nëtzlos Rotatioun erhéicht d'Zuel vun de Schiermer op 6 Tausend, an et waren méi wéi 600 Stécker pro Node.
Dëst huet zu Probleemer mat der Allokatioun vum RAM gefouert, a wann e Knuet erofgefall ass, hunn all Schiermer ugefaang gläichzäiteg ze plënneren, de Traffic multiplizéieren an aner Wirbelen ze lueden, wat et bal onméiglech gemaach huet Daten an de Cluster ze schreiwen. A während dëser Period ware mir ouni Logbicher verlooss. A wann et e Problem mam Server war, hu mir am Fong 1/10 vum Stärekoup verluer. Eng grouss Zuel vu klenge Indexen huet Komplexitéit bäigefüügt.
Ouni Logbicher hu mir d'Grënn fir den Tëschefall net verstanen a konnten desto oder spéider erëm op déiselwecht Rake trëppelen, an an der Ideologie vun eisem Team war dat inakzeptabel, well all eis Aarbechtsmechanismen entwéckelt sinn fir just de Géigendeel ze maachen - ni widderhuelen déi selwecht Problemer. Fir dëst ze maachen, brauche mir de ganze Volume vu Logbicher an hir Liwwerung bal an Echtzäit, well e Team vun on-duty-Ingenieuren iwwerwaacht Alarmer net nëmme vu Metriken, awer och vu Logbicher. Fir d'Skala vum Problem ze verstoen, war deemools de Gesamtvolumen vun de Logbicher ongeféier 2 TB pro Dag.
Mir setzen e Goal fir de Verloscht vu Logbicher komplett ze eliminéieren an d'Zäit vun hirer Liwwerung an den ELK-Cluster op maximal 15 Minutten während der Force Majeure ze reduzéieren (mir hunn spéider op dës Figur als intern KPI vertraut).
Neie Rotatiounsmechanismus a waarm-waarm Noden
Mir hunn d'Cluster Konversioun ugefaang andeems d'ElasticSearch Versioun vun 5.5.2 op 6.4.3 aktualiséiert gëtt. Nach eng Kéier ass eis Versioun 5 Stärekoup gestuerwen, a mir hu beschloss et auszeschalten a komplett ze aktualiséieren - et sinn nach ëmmer keng Logbicher. Also hu mir dësen Iwwergang an nëmmen e puer Stonnen gemaach.
Déi gréissten Transformatioun op dëser Etapp war d'Ëmsetzung vum Apache Kafka op dräi Wirbelen mat engem Koordinator als Zwëschenbuffer. De Message Broker huet eis gerett fir Logbicher ze verléieren wärend Probleemer mat ElasticSearch. Zur selwechter Zäit hu mir 2 Wirbelen an de Cluster bäigefüügt an op eng waarm-waarm Architektur mat dräi "waarm" Knäpper gewiesselt, déi a verschiddene Racken am Rechenzentrum sinn. Mir hunn d'Logbicher op si ëmgeleet mat enger Mask déi ënner kengen Ëmstänn verluer sollt ginn - nginx, souwéi Applikatiounsfehlerprotokoller. Kleng Logbicher goufen op déi verbleiwen Node geschéckt - Debug, Warnung, asw., an no 24 Stonnen goufen "wichteg" Logbicher vun "waarm" Node transferéiert.
Fir d'Zuel vu klengen Indexen net ze erhéijen, hu mir vun der Zäitrotatioun op de Rollovermechanismus gewiesselt. Et gouf vill Informatioun op de Foren datt d'Rotatioun duerch Indexgréisst ganz onzouverlässeg ass, also hu mir décidéiert d'Rotatioun duerch d'Zuel vun den Dokumenter am Index ze benotzen. Mir hunn all Index analyséiert an d'Zuel vun den Dokumenter opgeholl, no deenen d'Rotatioun funktionnéiert. Sou hu mir déi optimal Shard Gréisst erreecht - net méi wéi 50 GB.
Cluster Optimisatioun
Mir hunn d'Problemer awer net ganz lass gelooss. Leider sinn nach ëmmer kleng Indizes opgetaucht: si hunn net de spezifizéierte Volumen erreecht, goufen net rotéiert a goufen duerch global Reinigung vun Indexen méi al wéi dräi Deeg geläscht, well mir d'Rotatioun no Datum ewechgeholl hunn. Dëst huet zu Datenverloscht gefouert wéinst der Tatsaach, datt den Index aus dem Stärekoup komplett verschwonnen ass, an e Versuch, op en net existéierenden Index ze schreiwen, huet d'Logik vum Curator gebrach, dee mir fir d'Gestioun benotzt hunn. Alias fir Schreiwen gouf an en Index ëmgewandelt an huet d'Rolloverlogik gebrach, wat onkontrolléiert Wuesstum vun e puer Indexen bis zu 600 GB verursaacht.
Zum Beispill, fir d'Rotatiounskonfiguratioun:
сurator-elk-rollover.yaml
---
actions:
1:
action: rollover
options:
name: "nginx_write"
conditions:
max_docs: 100000000
2:
action: rollover
options:
name: "python_error_write"
conditions:
max_docs: 10000000
Wann et kee Rollover Alias gouf, ass e Feeler geschitt:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Mir hunn d'Léisung fir dëse Problem fir déi nächst Iteratioun verlooss an en anert Thema opgeholl: mir hunn op d'Pulllogik vu Logstash gewiesselt, déi erakommen Logbicher veraarbecht (onnéideg Informatioun ewechhuelen an ze beräicheren). Mir hunn et am Docker gesat, dee mir iwwer Docker-compose lancéieren, a mir hunn och de Logstash-Exporter do gesat, deen Metriken un de Prometheus schéckt fir operationell Iwwerwaachung vum Log Stream. Op dës Manéier hu mir eis d'Méiglechkeet ginn, d'Zuel vun de Logstash-Instanzen, déi verantwortlech fir d'Veraarbechtung vun all Typ vu Logbicher verantwortlech ass, glat z'änneren.
Wärend mir de Stärekoup verbessert hunn, ass de Verkéier vum cian.ru op 12,8 Milliounen eenzegaarteg Benotzer pro Mount eropgaang. Als Resultat huet et erausgestallt datt eis Transformatiounen e bëssen hannert den Ännerungen an der Produktioun waren, a mir ware mat der Tatsaach konfrontéiert datt déi "waarm" Knäpper net mat der Laascht eens konnten an d'ganz Liwwerung vu Logbicher verlangsamen. Mir kruten "waarm" Donnéeën ouni Feeler, awer mir hu missen an d'Liwwerung vum Rescht intervenéieren an eng manuell Rollover maachen fir d'Index gläichméisseg ze verdeelen.
Zur selwechter Zäit ass d'Skaléierung an d'Ännerung vun den Astellunge vu Logstash-Instanzen am Cluster komplizéiert vun der Tatsaach datt et e lokalen Docker-Compose war, an all Handlunge goufen manuell gemaach (fir nei Enden ze addéieren, war et néideg fir manuell duerch all d'Serveren a maachen docker-compose up -d iwwerall).
Log Ëmverdeelung
Am September vun dësem Joer hu mir nach ëmmer de Monolith ofgeschnidden, d'Belaaschtung op de Stärekoup ass eropgaang, an de Floss vu Logbicher koum 30 Tausend Messagen pro Sekonn un.
Mir hunn déi nächst Iteratioun mat engem Hardware Update ugefaang. Mir gewiesselt vu fënnef Koordinatoren op dräi, ersat Daten Wirbelen a gewannen am Sënn vun Suen an Stockage Plaz. Fir Node benotze mir zwou Konfiguratiounen:
- Fir "waarm" Wirbelen: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 fir Hot1 an 3 fir Hot2).
- Fir "waarm" Noden: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Bei dëser Iteratioun hu mir den Index mat Zougangsprotokoller vu Mikroservicer geplënnert, déi dee selwechte Raum wéi Frontline nginx Logbicher ophuelen, an déi zweet Grupp vun dräi "waarm" Noden. Mir späicheren elo Daten op "waarm" Wirbelen fir 20 Stonnen, a transferéieren se dann op "waarm" Wirbelen op de Rescht vun de Logbicher.
Mir hunn de Problem vu klengen Indexen geléist déi verschwannen andeems se hir Rotatioun nei konfiguréieren. Elo ginn d'Indexen op alle Fall all 23 Stonnen rotéiert, och wann et wéineg Daten do ass. Dëst huet d'Zuel vun de Schnëtt liicht erhéicht (et waren ongeféier 800 vun hinnen), awer aus der Siicht vun der Clusterleistung ass et tolerabel.
Als Resultat waren et sechs "waarm" an nëmme véier "waarm" Wirbelen am Cluster. Dëst verursaacht e liichte Verspéidung op Ufroen iwwer laang Zäitintervaller, awer d'Erhéijung vun der Unzuel vun Noden an der Zukunft wäert dëse Problem léisen.
Dës Iteratioun huet och de Problem vum Mangel u semi-automatesch Skala fixéiert. Fir dëst ze maachen, hu mir en Infrastruktur Nomad Cluster ofgesat - ähnlech wéi dat wat mir schonn an der Produktioun ofgesat hunn. Fir de Moment ännert de Betrag vu Logstash net automatesch ofhängeg vun der Belaaschtung, awer mir kommen op dëst.
Pläng fir d'Zukunft
Déi implementéiert Konfiguratioun skaléiert perfekt, an elo späichere mir 13,3 TB vun Daten - all Logbicher fir 4 Deeg, wat fir Noutfallanalyse vun Alarmer noutwendeg ass. Mir konvertéieren e puer vun de Logbicher a Metriken, déi mir op Graphite addéieren. Fir d'Aarbecht vun Ingenieuren méi einfach ze maachen, hu mir Metriken fir den Infrastrukturcluster a Skripte fir semi-automatesch Reparatur vu gemeinsame Probleemer. No der Erhéijung vun der Zuel vun den Dateknäppchen, déi fir d'nächst Joer geplangt ass, wiessele mir op Datelagerung vu 4 op 7 Deeg. Dëst wäert genuch fir operationell Aarbecht sinn, well mir probéieren ëmmer Tëschefäll sou séier wéi méiglech z'ënnersichen, a fir laangfristeg Ermëttlungen gëtt et Telemetrie-Daten.
Am Oktober 2019 war de Traffic op cian.ru scho op 15,3 Milliounen eenzegaarteg Benotzer pro Mount gewuess. Dëst gouf e seriöse Test vun der architektonescher Léisung fir Logbicher ze liwweren.
Elo preparéiere mir d'Aktualiséierung vun ElasticSearch op d'Versioun 7. Wéi och ëmmer, dofir musse mir d'Mapping vu villen Indexen an ElasticSearch aktualiséieren, well se vun der Versioun 5.5 geplënnert sinn an als deprecéiert an der Versioun 6 deklaréiert goufen (si existéieren einfach net an der Versioun 7). Dëst bedeit datt während dem Updateprozess definitiv eng Aart vu Force Majeure wäert sinn, déi eis ouni Logbicher verloosse wann d'Thema geléist gëtt. Vun der Versioun 7 freeë mir eis am meeschten op Kibana mat engem verbesserten Interface an neie Filteren.
Mir hunn eist Haaptzil erreecht: mir hunn opgehalen Logbicher ze verléieren an d'Dauer vum Infrastrukturcluster vun 2-3 Crashen pro Woch op e puer Stonnen Ënnerhaltsaarbecht pro Mount reduzéiert. All dës Aarbecht an der Produktioun ass bal onsichtbar. Wéi och ëmmer, elo kënne mir genau bestëmmen wat mat eisem Service geschitt, mir kënnen et séier an engem rouege Modus maachen a keng Suergen datt d'Logbicher verluer sinn. Am Allgemengen si mir zefridden, glécklech a preparéieren op nei Ausnotzen, iwwer déi mir spéider schwätzen.
Source: will.com