Nota. transl.: Presentámosche detalles técnicos sobre os motivos do tempo de inactividade recente no servizo na nube mantido polos creadores de Grafana. Este é un exemplo clásico de como unha función nova e aparentemente extremadamente útil deseñada para mellorar a calidade da infraestrutura... pode causar danos se non se prevén os numerosos matices da súa aplicación nas realidades da produción. É xenial cando aparecen materiais coma este que che permiten aprender non só dos teus erros. Os detalles están na tradución deste texto do vicepresidente de produtos de Grafana Labs.
O venres 19 de xullo, o servizo Hosted Prometheus en Grafana Cloud deixou de funcionar durante aproximadamente 30 minutos. Pido desculpas a todos os clientes afectados pola interrupción. O noso traballo é proporcionar as ferramentas de vixilancia que necesitas, e entendemos que non telas dispoñibles pode dificultar a túa vida. Tomámonos este incidente moi en serio. Esta nota explica o que pasou, como respondemos e o que estamos facendo para que non se repita.
prehistoria
O servizo de Grafana Cloud Hosted Prometheus baséase — Proxecto CNCF para crear un servizo Prometheus multi-inquilino, escalable horizontalmente e de alta dispoñibilidade. A arquitectura Cortex está formada por un conxunto de microservizos individuais, cada un dos cales realiza a súa propia función: replicación, almacenamento, consultas, etc. Cortex está en desenvolvemento activo e engade constantemente novas funcións e mellora o rendemento. Implementamos regularmente novas versións de Cortex en clústeres para que os clientes poidan aproveitar estas funcións; afortunadamente, Cortex pódese actualizar sen tempo de inactividade.
Para actualizacións sen problemas, o servizo Ingester Cortex require unha réplica adicional de Ingester durante o proceso de actualización. (Nota. transl.: - o compoñente básico da corteza. O seu traballo é recoller un fluxo constante de mostras, agrupalas en anacos de Prometheus e almacenalas nunha base de datos como DynamoDB, BigTable ou Cassandra.) Isto permite que os antigos Ingesters reenvíen os datos actuais aos novos Ingesters. Paga a pena notar que os inxestores demandan recursos. Para que funcionen, cómpre ter 4 núcleos e 15 GB de memoria por pod, é dicir. 25% da potencia de procesamento e da memoria da máquina base no caso dos nosos clústeres Kubernetes. En xeral, adoitamos ter moitos máis recursos sen utilizar no clúster que 4 núcleos e 15 GB de memoria, polo que podemos facer que estes inxestores adicionais poidan activar facilmente durante as actualizacións.
Non obstante, adoita ocorrer que durante o funcionamento normal ningunha das máquinas ten este 25% de recursos non utilizados. Si, nin sequera nos esforzamos: a CPU e a memoria sempre serán útiles para outros procesos. Para resolver este problema, decidimos usar . A idea é darlle a Ingesters unha maior prioridade que outros microservizos (sen estado). Cando necesitamos executar un inxestor adicional (N+1), desprazamos temporalmente outras vainas máis pequenas. Estes pods transfírense a recursos gratuítos noutras máquinas, deixando un "burato" suficientemente grande para executar un Ingester adicional.
O xoves, 18 de xullo, lanzamos catro novos niveis de prioridade para os nosos clústeres: crítico, alto, media и baixo. Probáronse nun clúster interno sen tráfico de clientes durante aproximadamente unha semana. Por defecto, recibíronse pods sen unha prioridade especificada media prioridade, a clase foi establecida para Ingesters con alto prioridade. Crítico reservouse para a monitorización (Prometheus, Alertmanager, node-exporter, kube-state-metrics, etc.). A nosa configuración está aberta e podes ver o PR .
Bater
O venres 19 de xullo, un dos enxeñeiros lanzou un novo clúster Cortex dedicado para un cliente grande. A configuración deste clúster non incluía novas prioridades de pods, polo que a todos os novos pods se lles asignou unha prioridade predeterminada: media.
O clúster de Kubernetes non tiña recursos suficientes para o novo clúster Cortex e o clúster Cortex de produción existente non se actualizou (os Ingesters quedaron sen alto prioridade). Xa que os Ingesters do novo clúster tiñan por defecto media prioridade e os pods existentes en produción funcionaron sen prioridade, os Ingesters do novo clúster substituíron os Ingesters do clúster de produción Cortex existente.
ReplicaSet para o Ingester desaloxado no clúster de produción detectou o pod desaloxado e creou un novo para manter o número especificado de copias. O novo pod asignouse por defecto media prioridade, e outro "vello" Ingester en produción perdeu os seus recursos. O resultado foi proceso de avalancha, o que provocou o desprazamento de todas as vainas de Ingester para os clústeres de produción de Cortex.
Os inxestores teñen estado e almacenan datos das 12 horas anteriores. Isto permítenos comprimilos de forma máis eficiente antes de escribilos no almacenamento a longo prazo. Para conseguilo, Cortex divide os datos entre series mediante unha táboa de hash distribuída (DHT) e replica cada serie en tres inxestores utilizando a coherencia do quórum ao estilo Dynamo. Cortex non escribe datos en Ingesters que estean desactivados. Así, cando un gran número de Ingestores saen do DHT, Cortex non pode proporcionar suficiente replicación das entradas e colócanse.
Detección e Remediación
Novas notificacións de Prometheus baseadas no "orzamento de erro" (baseado en erros orzamentarios — os detalles aparecerán nun artigo futuro) comezou a soar a alarma 4 minutos despois do inicio da parada. Durante os próximos cinco minutos aproximadamente, realizamos algúns diagnósticos e ampliamos o clúster de Kubernetes subxacente para albergar os clústeres de produción novos e existentes.
Despois de outros cinco minutos, os antigos Ingesters escribiron con éxito os seus datos, os novos puxéronse en marcha e os clústeres Cortex volveron estar dispoñibles.
Pasáronse outros 10 minutos diagnosticando e corrixindo erros sen memoria (OOM) dos proxies inversos de autenticación situados diante de Cortex. Os erros de OOM foron causados por un aumento de dez veces no QPS (creemos que debido a solicitudes excesivamente agresivas dos servidores Prometheus do cliente).
Resultado
O tempo total de inactividade foi de 26 minutos. Non se perdeu ningún dato. Os inxestores cargaron con éxito todos os datos da memoria no almacenamento a longo prazo. Durante a interrupción, elimináronse os servidores Prometheus do cliente (remoto) gravacións utilizando baseado en WAL (escrito por de Grafana Labs) e repetiu as escrituras erradas despois do accidente.
Operacións de escritura do clúster de produción
Descubrimentos
É importante aprender deste incidente e tomar as medidas necesarias para evitar a súa repetición.
En retrospectiva, non deberíamos ter establecido o valor predeterminado media prioridade ata que todos os inxestores en produción teñan recibido alto unha prioridade. Ademais, era necesario coidalos con antelación alto prioridade. Agora está todo arranxado. Agardamos que a nosa experiencia axude a outras organizacións a considerar usar as prioridades de pod en Kubernetes.
Engadiremos un nivel adicional de control sobre a implantación de calquera obxecto adicional cuxas configuracións sexan globais para o clúster. A partir de agora, tales cambios serán avaliados bоmáis xente. Ademais, a modificación que causou o fallo considerouse demasiado pequena para un documento de proxecto separado; só se discutiu nun problema de GitHub. A partir de agora, todos estes cambios nas configuracións irán acompañados da documentación adecuada do proxecto.
Finalmente, automatizaremos o cambio de tamaño do proxy inverso de autenticación para evitar a sobrecarga OOM que presenciamos, e revisaremos a configuración predeterminada de Prometheus relacionada coa reserva e a escala para evitar problemas similares no futuro.
O fracaso tamén tivo algunhas consecuencias positivas: ao recibir os recursos necesarios, Cortex recuperouse automaticamente sen intervención adicional. Tamén adquirimos unha valiosa experiencia traballando - o noso novo sistema de agregación de rexistros, que axudou a garantir que todos os inxestores se comportasen correctamente durante e despois do fallo.
PS do tradutor
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com