Os rexistros son unha parte importante do sistema, o que lle permite comprender que funciona (ou non funciona) como se esperaba. Baixo as condicións da arquitectura de microservizos, traballar con rexistros convértese nunha disciplina separada da Olimpiada Especial. Hai moitos problemas que hai que abordar:
- como escribir rexistros desde a aplicación;
- onde escribir rexistros;
- como entregar rexistros para almacenamento e procesamento;
- como procesar e almacenar rexistros.
O uso das tecnoloxías de contenerización actualmente populares engade area enriba do rastrillo no campo das opcións de resolución de problemas.
Só isto é a transcrición do informe de Yuri Bushmelev "Mapa dun anciño no campo da recollida e entrega de rexistros"
A quen lle importa, por favor debaixo do gato.
Chámome Yuri Bushmelev. Traballo para Lazada. Hoxe falarei de como fixemos os nosos rexistros, de como os recollemos e de que alí escribimos.
De onde somos? Quen somos? Lazada é o venda polo miúdo en liña número 1 en seis países do sueste asiático. Todos estes países distribúense entre centros de datos. Agora hai 4 centros de datos en total. Por que é importante? Porque algunhas decisións foron debido a que existe un vínculo moi débil entre os centros. Temos unha arquitectura de microservizos. Sorprendeume descubrir que xa temos 80 microservizos. Cando comecei a tarefa con rexistros, só había 20. Ademais, hai un anaco bastante grande do legado de PHP, que tamén teño que vivir e soportar. Todo isto xera para nós neste momento máis de 6 millóns de mensaxes por minuto para o conxunto do sistema. Ademais mostrarei como estamos tentando vivir con isto e por que é así.
Tes que vivir con estes 6 millóns de mensaxes dalgún xeito. Que debemos facer con eles? 6 millóns de mensaxes necesarias:
- enviar desde a aplicación
- aceptar para entrega
- entregar para análise e almacenamento.
- analizar
- almacenar dalgún xeito.
Cando había tres millóns de mensaxes, tiña máis ou menos o mesmo aspecto. Porque comezamos cuns céntimos. Está claro que alí están escritos os rexistros das aplicacións. Por exemplo, non puido conectarse á base de datos, podería conectarse á base de datos, pero non puido ler algo. Pero ademais disto, cada un dos nosos microservizos tamén escribe un rexistro de acceso. Cada solicitude que chega ao microservizo cae no rexistro. Por que facemos isto? Os desenvolvedores queren poder rastrexar. Cada rexistro de acceso contén o campo traceid, segundo o cal unha interface especial desenrola toda a cadea e mostra a traza de xeito fermoso. O rastro mostra como foi a solicitude, e isto axuda aos nosos desenvolvedores a xestionar máis rápido calquera lixo descoñecido.
Como vivir con el? Agora describirei brevemente o campo das opcións: como se resolve xeralmente este problema. Como resolver o problema de recoller, transferir e almacenar rexistros.
Como escribir desde a aplicación? Está claro que hai diferentes formas. En particular, hai boas prácticas, como nos din os compañeiros de moda. Hai dous tipos de escola antiga, como dicían os avós. Hai outras formas.
Coa recollida de rexistros, a situación é aproximadamente a mesma. Non hai tantas opcións para resolver esta parte en particular. Hai máis deles, pero aínda non tantos.
Pero coa entrega e a posterior análise, o número de variacións comeza a explotar. Non vou describir cada opción agora. Creo que as principais opcións son coñecidas por todos os que estaban interesados no tema.
Vouvos amosar como o fixemos en Lazada e como comezou todo.
Hai un ano, vin a Lazada e enviáronme ao proxecto de troncos. Alí foi así. O rexistro da aplicación escribiuse en stdout e stderr. Todo fíxose de forma elegante. Pero entón os desenvolvedores deixárono fóra dos fluxos estándar e, a continuación, os especialistas en infraestrutura descubriráno dalgún xeito. Entre os especialistas en infraestruturas e os desenvolvedores, tamén hai liberadores que dixeron: "uh... ben, imos envolvelos nun ficheiro cun shell, e xa está". E como todo isto está nun recipiente, envolvérono xusto no propio recipiente, mapearon o directorio dentro e puxérono alí. Creo que é bastante obvio para todos o que pasou.
Vexamos un pouco máis alá. Como entregamos estes rexistros. Alguén escolleu td-agent, que en realidade é fluido pero non moi fluido. Aínda non entendo a relación destes dous proxectos, pero parece que son máis ou menos o mesmo. E este fluentd, escrito en Ruby, lía ficheiros de rexistro, analizounos en JSON usando algunhas expresións regulares. Despois foron enviados a Kafka. Ademais, en Kafka, tiñamos 4 temas separados para cada API. Por que 4? Porque hai directo, hai posta en escena, e porque hai stdout e stderr. Os desenvolvedores prodúcense e os traballadores das infraestruturas deben crealos en Kafka. Ademais, Kafka estaba controlado por outro departamento. Por iso, foi necesario crear un ticket para que creasen alí 4 temas para cada api. Todo o mundo se esqueceu del. En xeral, era lixo e lixo.
Que fixemos despois con el? Enviámosllo a kafka. Máis lonxe de Kafka, a metade dos troncos voou a Logstash. A outra metade dos rexistros foron compartidas. Algúns voaron a un Graylog, outros a outro Graylog. Como resultado, todo isto voou nun clúster Elasticsearch. É dicir, todo este lío caeu ao final alí. Non tes que facelo!
Así se ve visto desde arriba. Non tes que facelo! Aquí, as áreas problemáticas están inmediatamente marcadas con números. En realidade hai máis deles, pero 6 son realmente problemáticos, cos que hai que facer algo. Vou falar deles por separado agora.
Aquí (1,2,3) escribimos ficheiros e, en consecuencia, hai tres rake aquí á vez.
O primeiro (1) é que necesitamos escribilos nalgún lugar. Non sempre é desexable darlle a unha API a posibilidade de escribir directamente nun ficheiro. É desexable que a API estea illada nun contedor, e aínda mellor, que sexa de só lectura. Son administrador do sistema, polo que teño unha visión lixeiramente alternativa destas cousas.
O segundo punto (2,3) é que temos moitas solicitudes que chegan á API. A API escribe moitos datos nun ficheiro. Os ficheiros están crecendo. Temos que rotalos. Porque se non, non poderás gardar ningún disco alí. Rotalos é malo porque son redirixidos a través do shell a un directorio. Non hai forma de que poidamos rotalo. Non pode dicirlle á aplicación que volva abrir os controladores. Porque os desenvolvedores miraránche coma un parvo: “Que descritores? Xeralmente escribimos a stdout. Os frameworks fixeron copytruncate en logrotate, que só fai unha copia do ficheiro e trunca o orixinal. En consecuencia, entre estes procesos de copia, o espazo no disco adoita esgotar.
(4) Tivemos diferentes formatos en diferentes API. Eran lixeiramente diferentes, pero as expresións regulares tiñan que escribirse de forma diferente. Como todo estaba xestionado por Puppet, había un gran grupo de clases coas súas propias cascudas. Ademais, o axente td a maior parte do tempo podía comer memoria, ser estúpido, só podía finxir que estaba a traballar e non facer nada. Exteriormente, era imposible entender que non estaba facendo nada. Ao mellor, caerá, e alguén o recollerá máis tarde. Máis precisamente, entrará unha alerta e alguén irá levantala coas mans.
(6) E a maioría de lixo e residuos - foi elasticsearch. Porque era unha versión antiga. Porque daquela non tiñamos mestres dedicados. Tiñamos rexistros heteroxéneos cuxos campos podían superpoñerse. Pódense escribir diferentes rexistros de diferentes aplicacións cos mesmos nomes de campo, pero ao mesmo tempo pode haber diferentes datos dentro. É dicir, un rexistro vén cun número enteiro nun campo, por exemplo, o nivel. Outro rexistro vén cunha cadea no campo de nivel. En ausencia de mapeo estático, resulta unha cousa tan marabillosa. Se, despois da rotación do índice, chegou primeiro unha mensaxe cunha cadea en elasticsearch, entón vivimos normalmente. E se o primeiro chegou con Integer, todas as mensaxes posteriores que chegaron con String simplemente descartanse. Porque o tipo de campo non coincide.
Comezamos a facer estas preguntas. Decidimos non buscar aos culpables.
Pero hai que facer algo! O obvio é que hai que establecer normas. Xa tiñamos algúns estándares. Algúns trouxemos un pouco máis tarde. Afortunadamente, xa se aprobou un único formato de rexistro para todas as API nese momento. Está escrito directamente nos estándares de interacción do servizo. En consecuencia, aqueles que queiran recibir rexistros deben escribilos neste formato. Se alguén non escribe rexistros neste formato, non garantimos nada.
Ademais, gustaríame ter un único estándar para os métodos de gravación, entrega e recollida de rexistros. En realidade, onde escribilos e como entregalos. A situación ideal é cando os proxectos usan a mesma biblioteca. Hai unha biblioteca de rexistro separada para Go, hai unha biblioteca separada para PHP. Todos os que temos, todos deberían usalos. De momento, diría que o estamos conseguindo nun 80 por cento. Pero algúns seguen comendo cactos.
E alí (na diapositiva) o "SLA para a entrega de rexistros" apenas comeza a aparecer. Aínda non está aí, pero estamos traballando niso. Porque é moi conveniente cando infra di que se escribes en tal ou tal formato a tal ou cal lugar e non máis de N mensaxes por segundo, o máis probable é que o entreguemos alí. Quita moitas dores de cabeza. Se hai un SLA, é xenial!
Como comezamos a resolver o problema? O rake principal foi con td-agent. Non estaba claro onde van os nosos rexistros. Son entregados? Vanse? Onde están de todos os xeitos? Polo tanto, decidiuse substituír td-agent polo primeiro elemento. Opcións por que substituílo, describín brevemente aquí.
Fluido. En primeiro lugar, atopeino nun traballo anterior, e tamén caía alí periódicamente. En segundo lugar, isto é o mesmo, só de perfil.
filebeat. Como nos foi bo? O feito de que estea en Go, e temos unha gran experiencia en Go. En consecuencia, en todo caso, poderiamos engadilo a nós mesmos. Por iso non o levamos. Para que nin sequera houbese tentación de comezar a reescribilo por si mesmo.
A solución obvia para o administrador do sistema é todo tipo de syslog nesta cantidade (syslog-ng/rsyslog/nxlog).
Ou escribe algo propio, pero descartámolo, así como filebeat. Se escribes algo, entón é mellor escribir algo útil para os negocios. Para entregar rexistros, é mellor levar algo listo.
Polo tanto, a elección en realidade reduciuse a elixir entre syslog-ng e rsyslog. Inclineime por rsyslog simplemente porque xa tiñamos clases para rsyslog en Puppet, e non atopei unha diferenza obvia entre elas. Que é syslog, que é syslog. Si, algunha documentación é peor, outra mellor. El sabe deste xeito, e faino doutro xeito.
E un pouco sobre rsyslog. En primeiro lugar, é xenial porque ten moitos módulos. Ten un RainerScript (linguaxe de configuración moderna) lexible por humanos. Unha vantaxe incrible é que poderiamos emular o comportamento de td-agent coas súas ferramentas estándar, e nada cambiou para as aplicacións. É dicir, cambiamos td-agent a rsyslog e aínda non tocamos todo o demais. E inmediatamente recibimos unha entrega de traballo. A continuación, mmnormalize é o interesante de rsyslog. Permítelle analizar rexistros, pero non con Grok e expresión regular. Fai unha árbore de sintaxe abstracta. Analiza os rexistros do mesmo xeito que un compilador analiza o código fonte. Isto permíteche traballar moi rápido, comer pouca CPU e, en xeral, é algo moi chulo. Hai unha morea de outros bonos. Non vou determe neles.
rsyslog ten moitas máis desvantaxes. Son aproximadamente o mesmo que os bonos. Os principais problemas son que debes poder cociñalo e debes seleccionar unha versión.
Decidimos que escribiriamos rexistros nun socket Unix. E non en /dev/log, porque alí temos unha lea de rexistros do sistema, hai journald nesta canalización. Entón, imos escribir nun socket personalizado. Axuntarémolo a un conxunto de regras separado. Non interfiramos en nada. Todo será transparente e comprensible. Entón o fixemos. O directorio con estes sockets está estandarizado e envíase a todos os contedores. Os contedores poden ver o socket que necesitan, abrir e escribir nel.
Por que non un ficheiro? Porque todo o mundo leu , que intentou reenviar o ficheiro a docker e descubriu que despois de reiniciar rsyslog, o descritor do ficheiro cambia e docker perde este ficheiro. Mantén aberta outra cousa, pero non a mesma toma onde escriben. Decidimos evitar este problema e, ao mesmo tempo, evitar o problema de bloqueo.
Rsyslog realiza as accións indicadas na diapositiva e envía rexistros a relé ou a Kafka. Kafka segue o vello camiño. Rayleigh: intentei usar rsyslog puro para entregar rexistros. Sen Message Queue, usando ferramentas rsyslog estándar. Basicamente, funciona.
Pero hai matices sobre como enchelos máis tarde nesta parte (Logstash/Graylog/ES). Esta parte (rsyslog-rsyslog) úsase entre centros de datos. Aquí tes unha ligazón tcp comprimida, que che permite aforrar ancho de banda e, en consecuencia, aumentar dalgún xeito a probabilidade de que recibamos algúns rexistros doutro centro de datos cando a canle estea chea. Porque temos Indonesia, onde todo está mal. Aí está o problema constante.
Pensamos en como supervisamos realmente, con que probabilidade chegan a ese fin os rexistros que gravamos na aplicación? Decidimos comezar as métricas. Rsyslog ten o seu propio módulo de recollida de estatísticas, que ten algún tipo de contadores. Por exemplo, pode mostrarche o tamaño da cola ou cantas mensaxes entraron para tal ou cal acción. Xa lles podes sacar algo. Ademais, ten contadores personalizados que podes configurar e mostrarache, por exemplo, o número de mensaxes que rexistrou algunha API. A continuación, escribín rsyslog_exporter en Python e enviámosllo todo a Prometheus e trazamos. Realmente queriamos métricas de Graylog, pero ata agora non tivemos tempo de configuralas.
Cales son os problemas? O problema xurdiu co feito de que descubrimos (¡SÚPETO!) que as nosas API en directo escriben 50 mensaxes por segundo. Esta é só unha API en directo sen posta en escena. E Graylog só nos mostra 12 mil mensaxes por segundo. E xurdiu unha pregunta razoable, onde están os restos? Do que concluímos que Graylog simplemente non pode facer fronte. Miramos e, de feito, Graylog con Elasticsearch non dominaba este fluxo.
A continuación, outros descubrimentos que fixemos no camiño.
As escrituras no socket están bloqueadas. Como pasou? Cando usei rsyslog para a entrega, nalgún momento rompemos a canle entre os centros de datos. A entrega subiu nun lugar, a entrega subiu noutro lugar. Todo isto reduciuse a unha máquina con API que escriben no socket rsyslog. Había unha cola. Entón encheuse a cola para escribir no socket Unix, que por defecto é de 128 paquetes. E o seguinte write() nos bloques da aplicación. Cando miramos a biblioteca que usamos nas aplicacións Go, alí estaba escrito que a escritura no socket ocorre en modo sen bloqueo. Estabamos seguros de que nada estaba bloqueado. Porque lemos quen escribiu sobre iso. Pero hai un momento. Tamén houbo un bucle infinito ao redor desta chamada, no que houbo un intento constante de meter unha mensaxe no socket. Non nos fixamos nel. Tiven que reescribir a biblioteca. Desde entón, cambiou varias veces, pero agora desfixémonos dos bloqueos en todos os subsistemas. Polo tanto, pode deter rsyslog e non caerá nada.
É necesario controlar o tamaño das filas, o que axuda a non pisar este anciño. En primeiro lugar, podemos controlar cando comezamos a perder mensaxes. En segundo lugar, podemos controlar que basicamente temos problemas coa entrega.
E outro momento desagradable: amplificación 10 veces nunha arquitectura de microservizos é moi doado. Non temos tantas solicitudes entrantes, pero debido ao gráfico ao longo do cal estas mensaxes corren máis adiante, debido aos rexistros de acceso, en realidade aumentamos a carga dos rexistros unhas dez veces. Desafortunadamente, non tiven tempo para calcular os números exactos, pero os microservizos son o que son. Isto hai que telo presente. Resulta que nestes momentos o subsistema de recollida de troncos é o máis cargado de Lazada.
Como resolver o problema de elasticsearch? Se precisas obter rapidamente rexistros nun só lugar, para non executar todas as máquinas e recollelos alí, utiliza o almacenamento de ficheiros. Isto está garantido para funcionar. Faise desde calquera servidor. Só tes que pegar os discos alí e poñer o syslog. Despois diso, ten a garantía de ter todos os rexistros nun só lugar. Entón será posible configurar lentamente elasticsearch, graylog ou outra cousa. Pero xa terás todos os rexistros e, ademais, poderás almacenalos, sempre que haxa suficientes matrices de discos.
No momento do meu informe, o esquema comezou a verse así. Practicamente deixamos de escribir no ficheiro. Agora, moi probablemente, desactivaremos os restos. Nas máquinas locais que executan a API, deixaremos de escribir nos ficheiros. En primeiro lugar, hai almacenamento de ficheiros, que funciona moi ben. En segundo lugar, estas máquinas están constantemente quedando sen espazo, cómpre supervisalo constantemente.
Esta parte con Logstash e Graylog, realmente sobe. Polo tanto, cómpre desfacerse del. Tes que escoller un.
Decidimos abandonar Logstash e Kibana. Porque temos un departamento de seguridade. Cal é a conexión? A conexión é que Kibana sen X-Pack e sen Shield non permite diferenciar dereitos de acceso aos rexistros. Polo tanto, tomaron Graylog. Teno todo. Non me gusta, pero funciona. Compramos hardware novo, instalamos alí un Graylog novo e movemos todos os rexistros con formatos estritos a un Graylog separado. Resolvemos o problema con diferentes tipos dos mesmos campos organizativamente.
Que se inclúe exactamente no novo Graylog. Acabamos de escribir todo no docker. Collemos un montón de servidores, lanzamos tres instancias de Kafka, 7 servidores Graylog versión 2.3 (porque quería a versión 5 de Elasticsearch). Todo isto xurdiu nas incursións desde o HDD. Vimos unha taxa de indexación de ata 100 mil mensaxes por segundo. Vimos a cifra de 140 terabytes de datos por semana.
E outra vez un anciño! Temos dúas vendas próximas. Superamos os 6 millóns de publicacións. Nós Graylog non temos tempo para mastigar. Dalgunha maneira tes que sobrevivir de novo.
Así sobrevivimos. Engadíronse algúns servidores e SSD máis. De momento vivimos así. Agora xa estamos mastigando 160 mensaxes por segundo. Aínda non alcanzamos o límite, polo que non está claro o que podemos conseguir de forma realista.
Estes son os nosos plans para o futuro. Deles, realmente, o máis importante é probablemente a alta dispoñibilidade. Aínda non o temos. Varios coches están configurados do mesmo xeito, pero ata agora todo pasa por un só coche. É necesario dedicar tempo a configurar un failover entre eles.
Recolle métricas de Graylog.
Establece un límite de taxa para que teñamos unha API tola que non nos mate o ancho de banda e todo o demais.
E, finalmente, asina algún tipo de SLA cos desenvolvedores para que poidamos servir tanto. Se escribes máis, desculpa.
E escribir documentación.
Brevemente, os resultados de todo o que vivimos. En primeiro lugar, os estándares. En segundo lugar, syslog é unha torta. En terceiro lugar, rsyslog funciona exactamente como está escrito na diapositiva. E imos ás preguntas.
preguntas.
Pregunta: Por que decidiron non levar... (filebeat?)
Responder: É necesario escribir nun ficheiro. Realmente non quería. Cando a túa API escribe miles de mensaxes por segundo, aínda que xires unha vez por hora, esta aínda non é unha opción. Podes escribir a pipe. Ao que os desenvolvedores me preguntaron: "Que pasará se cae o proceso no que escribimos"? Simplemente non atopei que responderlles e dixen: "Ben, vale, non o fagamos".
Pregunta: Por que non escribes rexistros no HDFS?
ResponderR: Esta é a seguinte etapa. Pensámolo ao principio, pero como non hai recursos para tratalo neste momento, pende da nosa solución a longo prazo.
Pregunta: un formato de columna sería máis axeitado.
Responder: Entendo. Estamos "para" coas dúas mans.
Pregunta: Escribes a rsyslog. Tanto TCP como UDP están dispoñibles alí. Pero se UDP, como garante a entrega?
ResponderR: Hai dous puntos. En primeiro lugar, inmediatamente dígolles a todos que non garantimos a entrega de rexistros. Porque cando veñen os desenvolvedores e din: "Imos comezar a escribir datos financeiros alí, e poñeranos nalgún lugar para nós por se ocorre algo", contestámoslles: "Xenial! Comecemos a bloquear ao escribir no socket e facelo nas transaccións, para que teñas a garantía de que o poñerás no socket e asegúrese de que o recibimos do outro lado. E neste momento, todo o mundo tórnase inmediatamente innecesario. E se non, que preguntas temos? Se non queres garantir unha escritura no socket, entón por que garantiríamos a entrega? Estamos facendo o mellor esforzo. Realmente intentamos entregar o máximo posible e o mellor posible, pero non damos unha garantía do 100%. Polo tanto, non precisa escribir datos financeiros alí. Existen bases de datos transaccionais para iso.
Pregunta: Cando a API xera algunha mensaxe ao rexistro e transfire o control aos microservizos, atopou o problema de que as mensaxes de diferentes microservizos chegan na orde incorrecta? Por iso, xorde a confusión.
ResponderR: É normal que veñan nunha orde diferente. Ten que estar preparado para isto. Porque calquera entrega de rede non lle garante a orde, ou precisa gastar recursos especiais para iso. Se tomamos almacenamento de ficheiros, cada API garda rexistros no seu propio ficheiro. Pola contra, rsyslog os descompón en directorios alí. Cada API ten alí os seus propios rexistros, onde podes ir e buscar, e despois podes comparalos usando a marca de tempo deste rexistro. Se van a buscar en Graylog, alí serán ordenados por marca de tempo. Todo estará ben alí.
Pregunta: a marca de tempo pode variar en milisegundos.
Responder: a marca de tempo é xerada pola propia API. Este, de feito, é todo o punto. Temos NTP. A API xera unha marca de tempo xa na propia mensaxe. Non é engadido por rsyslog.
Pregunta: A interacción entre os centros de datos non está moi clara. No marco do centro de datos, está claro como se recolleron e procesaron os rexistros. Como é a interacción entre os centros de datos? Ou cada centro de datos vive a súa propia vida?
Responder: Case. Temos cada país situado nun centro de datos. Actualmente non temos difusión, polo que un país colócase en distintos centros de datos. Polo tanto, non hai necesidade de combinalos. Dentro de cada centro hai un relevo de rexistro. Este é un servidor Rsyslog. De feito, dúas máquinas de xestión. Están configurados do mesmo xeito. Pero polo momento, o tráfico só pasa por un deles. Ela rexistra todo o agregado. Ten unha cola de disco por se acaso. Preme os rexistros e envíaos ao centro de datos central (Singapur), onde ademais xa están envelenados en Graylog. E cada centro de datos ten o seu propio almacenamento de ficheiros. No caso de que perdamos a conexión, temos todos os rexistros alí. Alí quedarán. Almacenaranse alí.
Pregunta: Recibes rexistros de alí durante situacións anormais?
Responder: Podes ir alí (ao almacenamento de ficheiros) e mirar.
Pregunta: Como controlas que non perdas rexistros?
Responder: Realmente estamos perdendoos, e estamos vixiándoo. A vixilancia comezou hai un mes. A biblioteca que usan as API de Go ten métricas. Pode contar cantas veces non puido escribir no socket. Neste momento hai unha heurística complicada. Hai un buffer alí. Tenta escribir unha mensaxe desde el ao socket. Se o búfer se desborda, comeza a soltalos. E conta cantos os deixou caer. Se os contadores comezan a desbordar alí, saberémolo. Agora tamén están chegando a prometheus, e podes ver os gráficos en Grafana. Podes configurar alertas. Pero aínda non está claro a quen mandalos.
Pregunta: En elasticsearch, almacena os rexistros con redundancia. Cantas réplicas tes?
Responder: Unha réplica.
Pregunta: É só unha liña?
Responder: Este é o mestre e a réplica. Os datos gárdanse por duplicado.
Pregunta: Axustaches o tamaño do búfer rsyslog dalgún xeito?
Responder: Escribimos datagramas nun socket Unix personalizado. Isto impónnos inmediatamente unha limitación de 128 kilobytes. Non podemos escribir máis nel. Escribimos isto no estándar. Quen queira entrar no almacenamento, escribe 128 kilobytes. As bibliotecas, ademais, cortan, e poñen unha bandeira de que a mensaxe está cortada. Temos un campo especial no estándar da propia mensaxe, que mostra se foi cortada durante a gravación ou non. Así que temos a oportunidade de seguir este momento.
Pregunta: Escribes JSON roto?
Responder: JSON roto descartarase durante a retransmisión porque o paquete é demasiado grande. Ou eliminarase Graylog, porque non poderá analizar JSON. Pero aquí hai matices que hai que corrixir, e principalmente están ligados a rsyslog. Xa cubrín alí algúns temas que aínda hai que traballar.
Pregunta: Por que Kafka? Xa probaches RabbitMQ? Graylog non se suma a tales cargas?
Responder: Non funciona con Graylog. E Graylog vai collendo forma. É realmente problemático para el. É unha especie de cousa. E, de feito, non é necesario. Prefiro escribir desde rsyslog directamente a elasticsearch e despois ver Kibana. Pero hai que resolver o problema cos gardas de seguridade. Esta é unha posible variante do noso desenvolvemento cando tiramos Graylog e usamos Kibana. Logstash non terá sentido. Porque podo facer o mesmo con rsyslog. E ten un módulo para escribir en elasticsearch. Con Graylog estamos tentando vivir dalgún xeito. Ata o modificamos un pouco. Pero aínda hai marxe de mellora.
Sobre Kafka. Así aconteceu historicamente. Cando cheguei, xa estaba alí, e xa se lle estaban escribindo rexistros. Acabamos de levantar o noso clúster e mover os rexistros nel. Xestionámolo, sabemos como se sente. En canto a RabbitMQ... estamos tendo problemas con RabbitMQ. E RabbitMQ está a desenvolver para nós. Témolo en produción, e houbo problemas con el. Agora, antes da venda, xamanizaríase, e comezaría a traballar con normalidade. Pero antes diso, non estaba preparado para publicalo en produción. Hai unha cousa máis. Graylog pode ler a versión AMQP 0.9 e rsyslog pode escribir a versión AMQP 1.0. E non hai unha única solución que poida facer as dúas cousas polo medio. Hai un ou outro. Así que de momento só Kafka. Pero tamén hai matices. Porque omkafka da versión de rsyslog que usamos pode perder todo o búfer de mensaxes que colleu de rsyslog. Sempre que o aguantemos.
Pregunta: Estás usando Kafka porque o tiñas? Non se usa para ningún outro propósito?
Responder: Kafka, que foi utilizado polo equipo de Data Science. Este é un proxecto completamente separado, sobre o que, por desgraza, non podo dicir nada. Eu non sei. Foi dirixida polo equipo de Data Science. Cando comezaron os troncos, decidiron usalo, para non poñer os seus. Agora actualizamos Graylog e perdemos a compatibilidade, porque hai unha versión antiga de Kafka. Tivemos que facer o noso. Ao mesmo tempo, desfixémonos destes catro temas para cada API. Fixemos un top ancho para todos en directo, un top ancho ancho para todas as escenificacións e só filmamos todo alí. Graylog analiza todo isto en paralelo.
Pregunta: Por que necesitamos este chamanismo con enchufes? Tentou usar o controlador de rexistro de syslog para contedores.
Responder: No momento en que fixemos esta pregunta, tiñamos relacións tensas co estibador. Era docker 1.0 ou 0.9. O propio Docker era raro. En segundo lugar, se tamén metes rexistros nel... Teño unha sospeita non verificada de que pasa todos os rexistros por si mesmo, a través do daemon docker. Se temos unha API toleando, o resto das API atoparase co feito de que non poden enviar stdout e stderr. Non sei a onde vai levar isto. Teño a sospeita de que non é necesario usar o controlador docker syslog neste lugar. O noso departamento de probas funcionais ten o seu propio clúster Graylog con rexistros. Usan controladores de rexistro docker e todo parece estar ben alí. Pero inmediatamente escriben GELF a Graylog. No momento en que comezamos todo isto, necesitábamos que só funcionase. Quizais despois, cando alguén veña e diga que leva cen anos funcionando con normalidade, intentaremos.
Pregunta: Entregas entre centros de datos mediante rsyslog. Por que non en Kafka?
Responder: Facemos isto, e así é realmente. Por dúas razóns. Se a canle está completamente morta, todos os nosos rexistros, mesmo en forma comprimida, non subirán por ela. E kafka permítelles simplemente perder no proceso. Deste xeito, desfarámonos do pegado destes rexistros. Só estamos usando Kafka neste caso directamente. Se temos unha boa canle e queremos liberala, entón usamos o seu rsyslog. Pero de feito, pode configuralo para que deixe caer o que non pasou. Polo momento só estamos a usar a entrega de rsyslog directamente nalgún lugar, nalgún lugar de Kafka.
Fonte: www.habr.com