Els registres són una part important del sistema, ja que us permeten entendre que funciona (o no funciona) com s'esperava. En les condicions de l'arquitectura de microserveis, treballar amb registres es converteix en una disciplina separada de l'Olimpíada especial. Hi ha molts problemes que s'han de resoldre:
- com escriure registres des de l'aplicació;
- on escriure registres;
- com lliurar registres per a l'emmagatzematge i el processament;
- com processar i emmagatzemar els registres.
L'ús de tecnologies de contenidors populars actualment afegeix sorra al rasclet en el camp de les opcions de resolució de problemes.
Sobre això és la transcripció de l'informe de Yuri Bushmelev "Mapa d'un rasclet en el camp de la recollida i lliurament de troncs"
A qui li importa, si us plau, sota el gat.
Em dic Yuri Bushmelev. Treballo per a Lazada. Avui us parlaré de com hem fet els nostres registres, com els hem recollit i què hi escrivim.
D'on som? Qui sóm? Lazada és el minorista en línia número 1 a sis països del sud-est asiàtic. Tots aquests països es distribueixen entre centres de dades. Ara hi ha 4 centres de dades en total. Per què és important? Perquè algunes decisions es van deure al fet que hi ha un vincle molt feble entre els centres. Tenim una arquitectura de microservei. Em va sorprendre veure que ja tenim 80 microserveis. Quan vaig començar la tasca amb els registres, només n'hi havia 20. A més, hi ha una part bastant gran del llegat de PHP, amb la qual també he de viure i suportar. Tot això ens genera en aquests moments més de 6 milions de missatges per minut per al conjunt del sistema. A més, mostraré com estem intentant viure amb això i per què és així.
Has de viure amb aquests 6 milions de missatges d'alguna manera. Què hem de fer amb ells? Es necessiten 6 milions de missatges:
- enviar des de l'aplicació
- acceptar per al lliurament
- lliurar per a anàlisi i emmagatzematge.
- analitzar
- emmagatzemar d'alguna manera.
Quan hi havia tres milions de missatges, tenia més o menys el mateix aspecte. Perquè vam començar amb uns cèntims. És clar que els registres de l'aplicació s'escriuen allà. Per exemple, no es podia connectar a la base de dades, podria connectar-se a la base de dades, però no podia llegir alguna cosa. Però a més d'això, cadascun dels nostres microserveis també escriu un registre d'accés. Cada sol·licitud que arriba al microservei cau al registre. Per què estem fent això? Els desenvolupadors volen poder rastrejar. Cada registre d'accés conté el camp traceid, d'acord amb el qual una interfície especial desenrotlla tota la cadena i mostra el rastre de manera bella. El rastre mostra com va anar la sol·licitud, i això ajuda els nostres desenvolupadors a fer front a qualsevol brossa desconeguda més ràpidament.
Com viure-hi? Ara descriuré breument el camp de les opcions: com es soluciona generalment aquest problema. Com resoldre el problema de la recollida, transferència i emmagatzematge de registres.
Com escriure des de l'aplicació? Està clar que hi ha diferents maneres. En particular, hi ha bones pràctiques, com ens diuen els companys de moda. Hi ha dos tipus d'escola antiga, com deia l'avi. Hi ha altres maneres.
Amb la recollida de registres, la situació és aproximadament la mateixa. No hi ha tantes opcions per resoldre aquesta part en particular. N'hi ha més, però encara no tants.
Però amb el lliurament i l'anàlisi posterior, el nombre de variacions comença a explotar. No descriuré cada opció ara. Crec que les opcions principals són ben conegudes per tothom que estigui interessat en el tema.
Us ensenyaré com ho vam fer a Lazada i com va començar tot.
Fa un any vaig venir a Lazada i em van enviar al projecte de registre. Allà era així. El registre de l'aplicació es va escriure a stdout i stderr. Tot es va fer a la moda. Però aleshores els desenvolupadors ho van treure dels fluxos estàndard i, a continuació, els especialistes en infraestructures ho descobriran d'alguna manera. Entre els especialistes en infraestructures i els desenvolupadors, també hi ha llançadors que van dir: "Uh... bé, emboliquem-los en un fitxer amb un shell, i ja està". I com que tot això està en un contenidor, l'han embolicat directament al mateix contenidor, han mapejat el directori que hi ha dins i el van posar allà. Crec que és bastant obvi per a tothom el que va passar.
Mirem una mica més enllà. Com vam lliurar aquests registres. Algú va triar td-agent, que en realitat és fluent però no del tot. Encara no entenc la relació d'aquests dos projectes, però sembla que són més o menys el mateix. I aquest fluentd, escrit en Ruby, va llegir fitxers de registre, els va analitzar en JSON mitjançant algunes expressions regulars. Després van ser enviats a Kafka. A més, a Kafka, teníem 4 temes separats per a cada API. Per què 4? Perquè hi ha directe, hi ha posada en escena, i perquè hi ha stdout i stderr. Els desenvolupadors els produeixen i els treballadors d'infraestructura els han de crear a Kafka. A més, Kafka estava controlat per un altre departament. Per tant, va ser necessari crear un tiquet perquè hi creïn 4 temes per a cada API. Tothom se'n va oblidar. En general, es tractava d'escombraries i deixalles.
Què vam fer després amb ell? L'hem enviat a Kafka. Més lluny de Kafka, la meitat dels troncs van volar a Logstash. L'altra meitat dels registres es van compartir. Alguns van volar a un Graylog, alguns a un altre Graylog. Com a resultat, tot això va volar en un clúster Elasticsearch. És a dir, tot aquest embolic va caure al final allà. No has de fer això!
Això és el que sembla quan es veu des de dalt. No cal que facis això! Aquí, les àrees problemàtiques es marquen immediatament amb números. En realitat n'hi ha més, però 6 són realment problemàtiques, amb les quals cal fer alguna cosa. Ara els parlaré per separat.
Aquí (1,2,3) escrivim fitxers i, en conseqüència, aquí hi ha tres rascles alhora.
El primer (1) és que els hem d'escriure en algun lloc. No sempre és desitjable donar a una API la possibilitat d'escriure directament en un fitxer. És desitjable que l'API estigui aïllada en un contenidor i, encara millor, que sigui de només lectura. Sóc administrador del sistema, així que tinc una visió lleugerament alternativa d'aquestes coses.
El segon punt (2,3) és que tenim moltes sol·licituds que arriben a l'API. L'API escriu moltes dades en un fitxer. Els fitxers creixen. Els hem de girar. Perquè si no, no hi podreu desar cap disc. Girar-los és dolent perquè es redirigien a través de l'intèrpret d'ordres a un directori. No hi ha manera de poder girar-lo. No podeu dir a l'aplicació que torni a obrir les nanses. Perquè els desenvolupadors et miraran com un ximple: “Quins descriptors? Generalment escrivim a stdout. Els frameworks van fer copytruncate en logrotate, que només fa una còpia del fitxer i encaixa l'original. En conseqüència, entre aquests processos de còpia, normalment s'esgota l'espai en disc.
(4) Teníem formats diferents en diferents API. Eren lleugerament diferents, però l'expressió regular s'havia d'escriure de manera diferent. Com que tot estava gestionat per Puppet, hi havia un gran grup de classes amb les seves pròpies paneroles. A més, td-agent la major part del temps podia menjar memòria, ser estúpid, només podia fingir que treballava i no feia res. Exteriorment, era impossible entendre que no feia res. En el millor dels casos, caurà i algú el recollirà més tard. Més precisament, volarà una alerta i algú anirà a aixecar-la amb les mans.
(6) I la majoria d'escombraries i residus - va ser elasticsearch. Perquè era una versió antiga. Perquè en aquell moment no teníem mestres dedicats. Teníem registres heterogenis els camps dels quals podien superposar-se. Es podrien escriure diferents registres d'aplicacions diferents amb els mateixos noms de camp, però al mateix temps hi podria haver dades diferents a l'interior. És a dir, un registre ve amb un enter en un camp, per exemple, el nivell. Un altre registre ve amb una cadena al camp de nivell. En absència de mapes estàtics, resulta una cosa tan meravellosa. Si, després de la rotació de l'índex, va arribar primer un missatge amb una cadena a elasticsearch, llavors vivim amb normalitat. I si el primer va arribar amb Integer, tots els missatges posteriors que van arribar amb String simplement es descarten. Perquè el tipus de camp no coincideix.
Vam començar a fer aquestes preguntes. Vam decidir no buscar els culpables.
Però cal fer alguna cosa! El que és obvi és que hem d'establir estàndards. Ja teníem uns estàndards. Alguns els vam portar una mica més tard. Afortunadament, en aquell moment ja es va aprovar un format de registre únic per a totes les API. S'escriu directament als estàndards d'interacció del servei. En conseqüència, els que vulguin rebre registres haurien d'escriure'ls en aquest format. Si algú no escriu registres en aquest format, no garantim res.
A més, m'agradaria tenir un estàndard únic per als mètodes d'enregistrament, lliurament i recollida de registres. De fet, on escriure'ls i com lliurar-los. La situació ideal és quan els projectes utilitzen la mateixa biblioteca. Hi ha una biblioteca de registre independent per a Go, hi ha una biblioteca independent per a PHP. Tots els que tenim, tothom els hauria de fer servir. De moment, diria que ho estem aconseguint en un 80 per cent. Però alguns continuen menjant cactus.
I allà (a la diapositiva) el "SLA per al lliurament de registres" amb prou feines comença a aparèixer. Encara no hi és, però hi estem treballant. Perquè és molt convenient quan infra diu que si escrius en tal o tal format a tal o tal lloc i no més de N missatges per segon, és molt probable que el lliurarem allí. Treu molts mals de cap. Si hi ha un SLA, és genial!
Com vam començar a resoldre el problema? El rasclet principal era amb td-agent. No estava clar on van els nostres registres. S'entreguen? Van? On són de totes maneres? Per tant, es va decidir substituir td-agent pel primer ítem. Opcions per què substituir-lo, les vaig descriure breument aquí.
Fluentd. En primer lloc, em vaig trobar amb ell en una feina anterior, i també hi caia periòdicament. En segon lloc, això és el mateix, només de perfil.
ritme de fitxer. Com ens va anar bé? El fet que estigui a Go, i tenim una gran experiència en Go. En conseqüència, en qualsevol cas, podríem afegir-ho a nosaltres mateixos. Per això no l'hem agafat. Perquè ni tan sols hi hagués cap temptació de començar a reescriure-ho per tu mateix.
La solució òbvia per a l'administrador del sistema és tot tipus de syslogs en aquesta quantitat (syslog-ng/rsyslog/nxlog).
O escriu alguna cosa pròpia, però l'hem descartat, així com el filebeat. Si escrius alguna cosa, és millor escriure alguna cosa útil per als negocis. Per lliurar registres, és millor portar alguna cosa feta.
Per tant, l'elecció en realitat es va reduir a triar entre syslog-ng i rsyslog. Em vaig inclinar cap a rsyslog simplement perquè ja teníem classes per a rsyslog a Puppet i no vaig trobar una diferència òbvia entre elles. Què és syslog, què és syslog. Sí, hi ha documentació pitjor, d'altres millor. Ell sap d'aquesta manera, i ho fa de manera diferent.
I una mica sobre rsyslog. Primer, és genial perquè té molts mòduls. Té un RainerScript (llenguatge de configuració modern) llegible pels humans. Un avantatge impressionant és que podríem emular el comportament de td-agent amb les seves eines estàndard i res ha canviat per a les aplicacions. És a dir, canviem td-agent per rsyslog i encara no toquem tota la resta. I de seguida rebem un lliurament de treball. A continuació, mmnormalize és el millor de rsyslog. Us permet analitzar els registres, però no amb Grok i regexp. Fa un arbre de sintaxi abstracta. Analitza els registres de la mateixa manera que un compilador analitza el codi font. Això us permet treballar molt ràpid, menjar poca CPU i, en general, és una cosa molt interessant. Hi ha un munt d'altres bonificacions. No m'atendré a ells.
rsyslog té molts més desavantatges. Són aproximadament el mateix que les bonificacions. Els principals problemes són que cal poder cuinar-lo i seleccionar una versió.
Vam decidir que escriurem els registres en un sòcol Unix. I no a /dev/log, perquè allà tenim un embolic de registres del sistema, hi ha journald en aquest pipeline. Així que escrivim a un sòcol personalitzat. L'adjuntarem a un conjunt de normes a part. No interferim en res. Tot serà transparent i comprensible. Així que en realitat ho vam fer. El directori amb aquests sòcols està estandarditzat i enviat a tots els contenidors. Els contenidors poden veure el sòcol que necessiten, obrir-hi i escriure-hi.
Per què no un fitxer? Perquè tothom ha llegit , que va intentar reenviar el fitxer a Docker i va trobar que després de reiniciar rsyslog, el descriptor del fitxer canvia i Docker perd aquest fitxer. Manté oberta una altra cosa, però no la mateixa presa on escriuen. Vam decidir que evitaríem aquest problema i, al mateix temps, evitaríem el problema de bloqueig.
Rsyslog fa les accions indicades a la diapositiva i envia registres a relé o a Kafka. Kafka segueix l'antic camí. Rayleigh: vaig intentar utilitzar rsyslog pur per lliurar registres. Sense la cua de missatges, utilitzant eines rsyslog estàndard. Bàsicament, funciona.
Però hi ha matisos sobre com introduir-los més endavant en aquesta part (Logstash/Graylog/ES). Aquesta part (rsyslog-rsyslog) s'utilitza entre centres de dades. Aquí teniu un enllaç tcp comprimit, que us permet estalviar ample de banda i, en conseqüència, augmentar d'alguna manera la probabilitat que rebem alguns registres d'un altre centre de dades quan el canal estigui ple. Perquè tenim Indonèsia, on tot és dolent. Aquí és on rau el problema constant.
Hem pensat com podem controlar realment amb quina probabilitat els registres que hem gravat des de l'aplicació arriben a aquest final? Vam decidir començar les mètriques. Rsyslog té el seu propi mòdul de recollida d'estadístiques, que té algun tipus de comptadors. Per exemple, us pot mostrar la mida de la cua o quants missatges han arribat en tal o tal acció. Ja pots agafar alguna cosa d'ells. A més, té comptadors personalitzats que podeu configurar i us mostrarà, per exemple, el nombre de missatges que alguna API ha enregistrat. A continuació, vaig escriure rsyslog_exporter a Python i ho vam enviar tot a Prometheus i vam crear gràfics. Realment volíem mètriques de Graylog, però fins ara no hem tingut temps de configurar-les.
Quins són els problemes? El problema va sorgir amb el fet que vam descobrir (SOPTADAMENT!) que les nostres API en directe escriuen 50 missatges per segon. Això només és l'API en directe sense posada en escena. I Graylog només ens mostra 12 mil missatges per segon. I va sorgir una pregunta raonable, on són les restes? Del qual vam concloure que Graylog simplement no pot fer front. Vam mirar i, de fet, Graylog amb Elasticsearch no dominava aquest flux.
A continuació, altres descobriments que hem fet al llarg del camí.
Les escriptures al sòcol estan bloquejades. Com ha passat? Quan vaig utilitzar rsyslog per al lliurament, en algun moment vam trencar el canal entre els centres de dades. El lliurament va pujar en un lloc, el lliurament va pujar en un altre lloc. Tot això s'ha reduït a una màquina amb API que escriuen al sòcol rsyslog. Hi havia una cua. Aleshores es va omplir la cua per escriure al sòcol Unix, que per defecte és de 128 paquets. I el següent write() als blocs d'aplicació. Quan vam mirar la biblioteca que fem servir a les aplicacions Go, es va escriure allà que l'escriptura al sòcol es produeix en mode sense bloqueig. Estàvem segurs que no hi havia res bloquejat. Perquè hem llegit qui va escriure sobre això. Però hi ha un moment. També hi havia un bucle infinit al voltant d'aquesta trucada, en què hi havia un intent constant d'empènyer un missatge al sòcol. No el vam notar. Vaig haver de reescriure la biblioteca. Des de llavors, ha canviat diverses vegades, però ara ens hem desfer dels bloquejos en tots els subsistemes. Per tant, podeu aturar rsyslog i no caurà res.
Cal controlar la mida de les cues, cosa que ajuda a no trepitjar aquest rastell. En primer lloc, podem controlar quan comencem a perdre missatges. En segon lloc, podem controlar que bàsicament tenim problemes amb el lliurament.
I un altre moment desagradable: l'amplificació de 10 vegades en una arquitectura de microservei és molt fàcil. No tenim tantes sol·licituds entrants, però a causa del gràfic al llarg del qual s'executen aquests missatges, a causa dels registres d'accés, en realitat augmentem la càrrega dels registres unes deu vegades. Malauradament, no vaig tenir temps de calcular les xifres exactes, però els microserveis són el que són. Això s'ha de tenir en compte. Resulta que de moment el subsistema de recollida de registres és el més carregat de Lazada.
Com resoldre el problema elasticsearch? Si necessiteu obtenir registres ràpidament en un sol lloc, per no executar-los per totes les màquines i recollir-los allà, utilitzeu l'emmagatzematge de fitxers. Això està garantit per funcionar. Es fa des de qualsevol servidor. Només cal enganxar-hi els discos i posar el syslog. Després d'això, teniu la garantia de tenir tots els registres en un sol lloc. Aleshores, serà possible configurar lentament elasticsearch, graylog o una altra cosa. Però ja tindreu tots els registres i, a més, els podreu emmagatzemar, sempre que hi hagi prou matrius de discs.
En el moment del meu informe, l'esquema va començar a semblar així. Pràcticament hem deixat d'escriure al fitxer. Ara, molt probablement, desactivarem les restes. A les màquines locals que executen l'API, deixarem d'escriure als fitxers. En primer lloc, hi ha emmagatzematge de fitxers, que funciona molt bé. En segon lloc, aquestes màquines es queden constantment sense espai, cal controlar-lo constantment.
Aquesta part amb Logstash i Graylog, realment es dispara. Per tant, cal desfer-se'n. Has de triar-ne un.
Vam decidir deixar Logstash i Kibana. Perquè tenim un departament de seguretat. Quina és la connexió? La connexió és que Kibana sense X-Pack i sense Shield no permet diferenciar els drets d'accés als registres. Per tant, van agafar Graylog. Ho té tot. No m'agrada, però funciona. Vam comprar maquinari nou, vam instal·lar-hi un Graylog nou i vam traslladar tots els registres amb formats estrictes a un Graylog separat. Hem resolt el problema amb diferents tipus dels mateixos camps organitzativament.
Què s'inclou exactament al nou Graylog. Acabem d'escriure tot al docker. Vam agafar un munt de servidors, vam llançar tres instàncies de Kafka, 7 servidors Graylog versió 2.3 (perquè volia Elasticsearch versió 5). Tot això es va plantejar en incursions des del HDD. Vam veure una taxa d'indexació de fins a 100 mil missatges per segon. Vam veure la xifra de 140 terabytes de dades per setmana.
I de nou un rastell! Tenim dues vendes a punt. Hem superat els 6 milions de publicacions. Nosaltres Graylog no tenim temps de mastegar. D'alguna manera has de sobreviure de nou.
Així hem sobreviscut. S'han afegit uns quants servidors i SSD més. De moment vivim així. Ara ja estem mastegant 160 missatges per segon. Encara no hem arribat al límit, així que no està clar fins a quin punt en podem treure de manera realista.
Aquests són els nostres plans de futur. D'aquests, realment, el més important és probablement l'alta disponibilitat. Encara no el tenim. Diversos cotxes estan configurats de la mateixa manera, però fins ara tot passa per un cotxe. Cal dedicar temps a configurar un failover entre ells.
Recolliu mètriques de Graylog.
Feu un límit de velocitat perquè tinguem una API boja que no ens mati l'ample de banda i tota la resta.
I, finalment, signar algun tipus de SLA amb els desenvolupadors perquè puguem servir tant. Si escrius més, ho sento.
I escriure documentació.
Breument, els resultats de tot el que hem viscut. En primer lloc, els estàndards. En segon lloc, syslog és un pastís. En tercer lloc, rsyslog funciona exactament tal com està escrit a la diapositiva. I anem a les preguntes.
Les vostres preguntes.
Pregunta: Per què van decidir no prendre... (filebeat?)
Respondre: Cal escriure en un fitxer. Realment no ho volia. Quan la vostra API escriu milers de missatges per segon, fins i tot si gireu una vegada per hora, això encara no és una opció. Podeu escriure a pipe. A la qual cosa els desenvolupadors em van preguntar: "Què passarà si cau el procés en què escrivim"? Simplement no vaig trobar què respondre-los i vaig dir: "Bé, d'acord, no ho fem".
Pregunta: Per què no escriviu registres a HDFS?
RespondreA: Aquesta és la següent etapa. Ho vam pensar al principi, però com que no hi ha recursos per fer-hi front en aquests moments, penja en la nostra solució a llarg termini.
Pregunta: Un format de columna seria més adequat.
Respondre: Entenc. Estem "per" amb les dues mans.
Pregunta: Escriu a rsyslog. Tant TCP com UDP estan disponibles allà. Però si UDP, llavors com garanteix el lliurament?
RespondreR: Hi ha dos punts. En primer lloc, de seguida dic a tothom que no garantim el lliurament de registres. Perquè quan vénen els desenvolupadors i diuen: “Comencem a escriure les dades financeres allà, i ens les posareu en algun lloc per si passa alguna cosa”, els responem: “Genial! Comencem a bloquejar l'escriptura al sòcol i fem-ho en transaccions, de manera que tingueu la garantia de posar-lo al sòcol per nosaltres i assegurar-vos que el rebem de l'altre costat. I en aquest moment, tothom es torna immediatament innecessari. I si no, quines preguntes tenim? Si no voleu garantir una escriptura al sòcol, per què garantiríem el lliurament? Estem fent el millor esforç. Realment intentem lliurar el màxim possible i el millor possible, però no donem una garantia del 100%. Per tant, no cal que hi escriviu dades financeres. Hi ha bases de dades transaccionals per a això.
Pregunta: Quan l'API genera algun missatge al registre i transfereix el control als microserveis, us heu trobat amb el problema que els missatges de diferents microserveis arriben en un ordre incorrecte? Per això, sorgeix la confusió.
RespondreR: És normal que vinguin en un ordre diferent. Has d'estar preparat per a això. Perquè qualsevol lliurament a la xarxa no us garanteix l'ordre, o heu de gastar recursos especials en això. Si prenem emmagatzematge de fitxers, aleshores cada API desa els registres al seu propi fitxer. Més aviat, rsyslog els descompon en directoris allà. Cada API té els seus propis registres allà, on podeu anar a buscar i, a continuació, comparar-los mitjançant la marca de temps d'aquest registre. Si van a buscar a Graylog, allà s'ordenaran per marca de temps. Allà tot anirà bé.
Pregunta: La marca de temps pot variar en mil·lisegons.
Respondre: la marca de temps la genera la mateixa API. Aquest, de fet, és tot el punt. Tenim NTP. L'API genera una marca de temps ja al mateix missatge. No l'afegeix rsyslog.
Pregunta: La interacció entre centres de dades no és molt clara. En el marc del centre de dades, queda clar com es van recollir i processar els registres. Com és la interacció entre els centres de dades? O cada centre de dades viu la seva pròpia vida?
Respondre: Gairebé. Tenim cada país situat en un centre de dades. Actualment no tenim difusió, de manera que un país es col·loca en diferents centres de dades. Per tant, no cal combinar-los. Dins de cada centre hi ha un Relé de registre. Aquest és un servidor Rsyslog. De fet, dues màquines de gestió. Estan configurats de la mateixa manera. Però de moment, el trànsit només passa per un d'ells. Ella registra tot els agregats. Té una cua de disc per si de cas. Premeu els registres i els envia al centre de dades central (Singapur), on a més ja estan enverinats a Graylog. I cada centre de dades té el seu propi emmagatzematge de fitxers. En cas que perdem la connexió, hi tenim tots els registres. S'hi quedaran. S'hi guardaran.
Pregunta: Rebreu registres d'allà durant situacions anormals?
Respondre: Podeu anar-hi (a l'emmagatzematge de fitxers) i mirar.
Pregunta: Com controleu que no perdeu els registres?
Respondre: En realitat els estem perdent i ho estem vigilant. El seguiment va començar fa un mes. La biblioteca que utilitzen les API de Go té mètriques. Pot comptar quantes vegades no ha pogut escriure al sòcol. En aquests moments hi ha una heurística complicada. Allà hi ha un buffer. Intenta escriure un missatge des d'ell al sòcol. Si el buffer es desborda, comença a deixar-los caure. I compta quants els va caure. Si els comptadors comencen a desbordar-se allà, ho sabrem. Ara també arriben a prometheus, i podeu veure els gràfics a Grafana. Podeu configurar alertes. Però encara no està clar a qui enviar-los.
Pregunta: a elasticsearch, emmagatzemeu els registres amb redundància. Quantes rèpliques tens?
Respondre: Una rèplica.
Pregunta: És només una línia?
Respondre: Aquest és el mestre i la rèplica. Les dades s'emmagatzemen per duplicat.
Pregunta: Has ajustat la mida del buffer rsyslog d'alguna manera?
Respondre: escrivim datagrames a un sòcol Unix personalitzat. Això ens imposa immediatament una limitació de 128 kilobytes. No hi podem escriure més. Això ho hem escrit a l'estàndard. Qui vol entrar a l'emmagatzematge, escriu 128 kilobytes. Les biblioteques, a més, tallen, i posen una bandera que el missatge està tallat. Tenim un camp especial en l'estàndard del missatge en si, que mostra si es va tallar durant la gravació o no. Així que tenim l'oportunitat de seguir aquest moment.
Pregunta: Escriu JSON trencat?
Respondre: el JSON trencat es descartarà durant la retransmissió perquè el paquet és massa gran. O s'eliminarà Graylog, perquè no podrà analitzar JSON. Però aquí hi ha matisos que s'han d'arreglar, i majoritàriament estan lligats a rsyslog. Ja hi he emplenat uns quants temes, que encara s'han de treballar.
Pregunta: Per què Kafka? Has provat RabbitMQ? Graylog no suma amb aquestes càrregues?
Respondre: No funciona amb Graylog. I Graylog està prenent forma. És realment problemàtic per a ell. Ell és una mena de cosa. I, de fet, no és necessari. Prefereixo escriure directament des de rsyslog a elasticsearch i després veure Kibana. Però hem de resoldre el problema amb els guàrdies de seguretat. Aquesta és una possible variant del nostre desenvolupament quan llencem Graylog i utilitzem Kibana. Logstash no tindrà sentit. Perquè puc fer el mateix amb rsyslog. I té un mòdul per escriure a elasticsearch. Amb Graylog estem intentant viure d'alguna manera. Fins i tot l'hem retocat una mica. Però encara hi ha marge per millorar.
Sobre Kafka. Així va passar històricament. Quan vaig arribar, ja hi era i ja s'hi escrivien registres. Acabem d'aixecar el nostre clúster i hi vam moure els registres. El gestionem, sabem com se sent. Pel que fa a RabbitMQ... estem tenint problemes amb RabbitMQ. I RabbitMQ s'està desenvolupant per a nosaltres. El tenim en producció i hi va haver problemes. Ara, abans de la venda, seria xamanitzat, i començaria a treballar amb normalitat. Però abans d'això, no estava preparat per llançar-lo a producció. Hi ha un punt més. Graylog pot llegir la versió AMQP 0.9 i rsyslog pot escriure la versió AMQP 1.0. I no hi ha una única solució que pugui fer les dues coses al mig. Hi ha un o l'altre. Així que de moment només Kafka. Però també hi ha matisos. Com que omkafka de la versió de rsyslog que utilitzem pot perdre tot el buffer de missatges que va recollir de rsyslog. Sempre que ho aguantem.
Pregunta: Estàs utilitzant Kafka perquè el tens? No s'utilitza per a cap altre propòsit?
Respondre: Kafka, que va ser utilitzat per l'equip de Data Science. Aquest és un projecte completament separat, sobre el qual, malauradament, no puc dir res. No ho sé. Estava dirigida per l'equip de Data Science. Quan van començar els troncs, van decidir utilitzar-lo, per no posar els seus. Ara hem actualitzat Graylog i hem perdut la compatibilitat, perquè hi ha una versió antiga de Kafka. Havíem de fer el nostre. Al mateix temps, ens vam desfer d'aquests quatre temes per a cada API. Vam fer un top ample per a tots en directe, un ample ample per a tota la posada en escena i només rodem tot allà. Graylog recull tot això en paral·lel.
Pregunta: Per què necessitem aquest xamanisme amb endolls? Heu provat d'utilitzar el controlador de registre syslog per als contenidors.
Respondre: En el moment en què vam fer aquesta pregunta, teníem relacions tenses amb el docker. Era Docker 1.0 o 0.9. Docker en si era estrany. En segon lloc, si també hi introduïu registres... Tinc una sospita no verificada que passa tots els registres per si mateix, a través del dimoni docker. Si tenim una API que es torna boja, la resta de les API es trobaran amb el fet que no poden enviar stdout i stderr. No sé cap a on portarà això. Tinc la sospita a nivell de sensació que no és necessari utilitzar el controlador docker syslog en aquest lloc. El nostre departament de proves funcionals té el seu propi clúster Graylog amb registres. Utilitzen controladors de registre docker i sembla que tot va bé allà. Però de seguida escriuen GELF a Graylog. En el moment en què vam començar tot això, necessitàvem que només funcionés. Potser més endavant, quan vingui algú i digui que fa cent anys que funciona amb normalitat, ho intentarem.
Pregunta: Entreu entre centres de dades mitjançant rsyslog. Per què no a Kafka?
Respondre: Fem això, i així és com és realment. Per dos motius. Si el canal està completament mort, tots els nostres registres, fins i tot en forma comprimida, no hi pujaran. I kafka els permet simplement perdre en el procés. D'aquesta manera, desfer-nos de l'enganxament d'aquests troncs. Només estem utilitzant Kafka en aquest cas directament. Si tenim un bon canal i volem alliberar-lo, fem servir el seu rsyslog. Però, de fet, podeu configurar-lo perquè deixi caure allò que no ha passat. De moment només estem utilitzant el lliurament rsyslog directament en algun lloc, en algun lloc Kafka.
Font: www.habr.com