Журналдар системанын маанилүү бөлүгү болуп саналат, ал күтүлгөндөй иштейт (же иштебейт) экенин түшүнүүгө мүмкүндүк берет. Микросервис архитектурасынын шарттарында журналдар менен иштөө атайын олимпиаданын өзүнчө дисциплинасына айланат. Чечилиши керек болгон көптөгөн маселелер бар:
- тиркемеден журналдарды кантип жазуу керек;
- журналдарды кайда жазуу керек;
- сактоо жана кайра иштетүү үчүн журналдарды кантип жеткирүү керек;
- журналдарды кантип иштетүү жана сактоо керек.
Учурда популярдуу контейнерлештирүү технологияларын колдонуу көйгөйлөрдү чечүү жолдору жаатында тырмоонун үстүнө кум кошот.
Мына ушулар женунде Юрий Бушмелевдун «Дагы жыйноо жана ташып жеткируу тармагындагы тырмоолордун картасы» деген докладынын стенограммасы.
Кимге кызык, мышыктын астында сураныч.
Менин атым Юрий Бушмелев. Мен Lazada үчүн иштейм. Бүгүн мен журналыбызды кантип жасаганыбыз, аларды кантип чогултканыбыз жана ал жерде эмнелерди жазганыбыз жөнүндө сүйлөшөм.
Биз кайданбыз? Биз кимбиз? Lazada Түштүк-Чыгыш Азиядагы алты өлкөдө №1 онлайн сатуучу болуп саналат. Бул өлкөлөрдүн бардыгы маалымат борборлорунун ортосунда бөлүштүрүлгөн. Азыр бардыгы болуп 4 маалымат борбору бар.Бул эмне үчүн маанилүү? Анткени кээ бир чечимдер борборлордун ортосундагы байланыштын өтө начардыгынан улам болгон. Бизде микросервис архитектурасы бар. Бизде 80 микросервис бар экенин көрүп таң калдым. Мен журналдар менен тапшырманы баштаганда, алардын 20сы гана бар болчу.Андан тышкары, PHP мурасынын бир топ чоң бөлүгү бар, мен дагы аны менен жашап, чыдашым керек. Мунун баары биз үчүн учурда бүтүндөй система үчүн мүнөтүнө 6 миллиондон ашык билдирүүлөрдү жаратат. Мындан ары мен муну менен кантип жашоого аракет кылып жатканыбызды жана эмне үчүн мындай болгонун көрсөтөм.
Сиз бул 6 миллион билдирүү менен кандайдыр бир жол менен жашашыңыз керек. Алар менен эмне кылышыбыз керек? 6 миллион билдирүү керек:
- колдонмодон жөнөтүү
- жеткирүү үчүн кабыл алуу
- талдоо жана сактоо үчүн жеткирүү.
- кароо
- кандайдыр бир жол менен сактоо.
Үч миллион билдирүү болгондо, менде окшош эле көрүнүш бар болчу. Анткени биз бир аз тыйын менен баштадык. Ал жерде арыз журналдары жазылганы көрүнүп турат. Мисалы, маалымат базасына кошула алган жок, маалымат базасына кошула алган, бирок бир нерсени окуй алган жок. Бирок мындан тышкары, биздин ар бир микросервис кирүү журналын жазат. Микросервиске келген ар бир суроо журналга түшөт. Эмне үчүн биз муну кылып жатабыз? Иштеп чыгуучулар байкоо жүргүзүүнү каалашат. Ар бир кирүү журналы traceid талаасын камтыйт, ага ылайык атайын интерфейс андан кийин бүт чынжырды ачып, изди сонун көрсөтөт. Из сурамдын кантип өткөнүн көрсөтөт жана бул биздин иштеп чыгуучуларга белгисиз таштандыларды тезирээк чечүүгө жардам берет.
Аны менен кантип жашаш керек? Эми мен кыскача варианттар тармагын сүрөттөп берем - бул маселе жалпысынан кантип чечилет. Журналдарды чогултуу, өткөрүп берүү жана сактоо маселесин кантип чечүү керек.
Арыздан кантип жазуу керек? Ар кандай жолдору бар экени түшүнүктүү. Айрыкча, алдыцкы тажрыйба бар, деп модалуу жолдоштор айтышат. Чоң аталар айткандай, эски мектептин эки түрү бар. Башка жолдору бар.
журналдарды чогултуу менен, абал болжол менен бирдей. Бул өзгөчө бөлүгүн чечүү үчүн көп варианттар жок. Алар дагы көп, бирок азырынча анчалык көп эмес.
Бирок жеткирүү жана андан кийинки талдоо менен вариациялардын саны жарылып баштайт. Мен азыр ар бир вариантты сүрөттөп бербейм. Негизги варианттар темага кызыккандардын баарына белгилүү деп ойлойм.
Мен муну Лазада кантип жасаганыбызды жана баары кантип башталганын көрсөтөм.
Бир жыл мурун мен Лазадага келип, журнал долбооруна жиберилдим. Ал жерде ушундай болгон. Тиркемедеги журнал stdout жана stderrге жазылган. Баары модалуу түрдө жасалды. Бирок андан кийин иштеп чыгуучулар аны стандарттуу агымдардан чыгарып салышты, анан инфраструктура боюнча адистер аны кандайдыр бир жол менен аныкташат. Инфраструктура адистери менен иштеп чыгуучулардын ортосунда: "Ух ... жакшы, аларды жөн гана кабык менен файлга ороп алалы, ушуну менен бүттү" деп айткан чыгаруучулар бар. Мунун баары контейнерде болгондуктан, аны туура эле идишке ороп, ичиндеги каталогду картага түшүрүп, ошол жерге коюшту. Менимче, эмне болгону баарына ачык эле көрүнүп турат.
Келгиле, дагы бир аз карап көрөлү. Бул журналдарды кантип жеткирдик. Кимдир бирөө td-агентти тандап алды, ал чындыгында эркин сүйлөйт, бирок такыр жакшы эмес. Мен дагы эле бул эки долбоордун мамилесин түшүнө албайм, бирок алар бир эле нерсеге байланыштуу окшойт. Жана бул эркин, Ruby тилинде жазылган, журнал файлдарын окуп, кээ бир кадимки туюнтмалардын жардамы менен аларды JSONге талдап чыкты. Андан кийин аларды Кафкага жөнөтүштү. Мындан тышкары, Кафкада бизде ар бир API үчүн 4 өзүнчө тема бар болчу. Эмне үчүн 4? Анткени жандуу берүү бар, сахналаштыруу бар жана stdout жана stderr бар. Иштеп чыгуучулар аларды чыгарышат, ал эми инфраструктура кызматкерлери аларды Кафкада түзүшү керек. Анын үстүнө Кафканы башка бөлүм көзөмөлдөгөн. Демек, алар ал жерде ар бир api учун 4 теманы тузушу учун билет тузуу керек эле. Аны баары унутуп калышты. Жалпысынан бул таштанды жана таштанды болчу.
Биз аны менен эмне кылдык? Кафкага жибердик. Кафкадан ары карай, жыгачтардын жарымы Логсташка учуп кетти. Журналдардын калган жарымы бөлүштүрүлдү. Кээ бир Грейлогго учуп кетишти, кээ бири экинчи Грейлогго. Натыйжада, мунун баары бир Elasticsearch кластерине учуп кетти. Башкача айтканда, бул баш аламандыктын баары акыры ошол жерге түштү. Сиз муну кылуунун кереги жок!
Жогору жактан караганда ушундай көрүнөт. Сиз муну кылуунун кереги жок! Бул жерде көйгөйлүү жерлер дароо сандар менен белгиленет. Чынында алардын саны дагы көп, бирок 6сы чындап эле көйгөйлүү, алар менен бир нерсе кылуу керек. Алар тууралуу азыр өзүнчө айтып берем.
Бул жерде (1,2,3) биз файлдарды жазабыз жана ошого жараша бул жерде бир эле учурда үч тырмоо бар.
Биринчиси (1) биз аларды бир жерге жазышыбыз керек. API'ге файлга түз жазуу мүмкүнчүлүгүн берүү дайыма эле каалабайт. API контейнерде обочолонуп, андан да жакшысы, окуу үчүн гана болушу керек. Мен системалык администратормун, андыктан бул нерселерге бир аз альтернативалуу көз карашым бар.
Экинчи пункт (2,3) бизде API'ге көптөгөн суроо-талаптар келип жатат. API файлга көп маалыматтарды жазат. Файлдар өсүп жатат. Биз аларды ротациялашыбыз керек. Анткени антпесе ал жерде эч кандай дискти сактай албай каласыз. Аларды айлантуу жаман, анткени алар кабык аркылуу каталогго багытталат. Аны айланта албайбыз. Колдонмого туткаларды кайра ачууну айта албайсыз. Анткени иштеп чыгуучулар сени келесоодой карашат: “Кандай дескрипторлор? Биз көбүнчө stdoutке жазабыз. Фреймворктар copytruncate файлын логротатка айлантты, ал жөн гана файлдын көчүрмөсүн жасап, түпнускасын түптөйт. Демек, бул көчүрүү процесстеринин ортосунда, адатта, диск мейкиндиги түгөнөт.
(4) Бизде ар кандай API'лерде ар кандай форматтар бар болчу. Алар бир аз башкачараак болчу, бирок regexp башкача жазылышы керек болчу. Мунун баарын Куурчак башкаргандыктан, алардын таракандары бар чоң топ класстар бар болчу. Мындан тышкары, td-агент көпчүлүк учурда эс тутумун жеп, келесоо болуп, ал жөн гана иштеп жаткандай түр көрсөтүп, эч нерсе кылбай калчу. Сыртынан эч нерсе кылбай жатканын түшүнүү мүмкүн эмес эле. Эң жакшысы жыгылып калат, кийин бирөө көтөрүп кетет. Тагыраак айтканда, сигнал учуп кирип, бирөө барып колу менен көтөрөт.
(6) Жана эң таштанды жана таштанды - бул elasticsearch болду. Анткени ал эски версия болчу. Анткени ал кезде бизде өз ишин арнаган устаттар жок болчу. Бизде гетерогендүү журналдар бар болчу, алардын талаалары бири-бирине дал келет. Ар кандай тиркемелердин ар кандай журналдары бирдей талаа аталыштары менен жазылышы мүмкүн, бирок ошол эле учурда ичинде ар кандай маалыматтар болушу мүмкүн. Башкача айтканда, бир журнал талаада бүтүн сан менен келет, мисалы, деңгээл. Башка журнал деңгээл талаасында String менен келет. Статикалык карта жок болгон учурда ушундай сонун нерсе чыгат. Эгерде индекстин айлануусунан кийин сап менен билдирүү алгач elasticsearchке келсе, анда биз кадимкидей жашайбыз. Эгерде биринчиси бүтүн сан менен келсе, анда String менен келген кийинки билдирүүлөрдүн баары жөн эле жок кылынат. Анткени талаа түрү дал келбейт.
Биз бул суроолорду бере баштадык. Күнөөлүүлөрдү издебейли деп чечтик.
Бирок бир нерсе кылуу керек! Ачык нерсе, биз стандарттарды түзүшүбүз керек. Бизде мурунтан эле кээ бир стандарттар бар болчу. Кээ бирлерин бир аздан кийин алып келдик. Бактыга жараша, бардык API'лер үчүн бирдиктүү журнал форматы ошол убакта бекитилген. Бул түздөн-түз кызматтын өз ара аракеттенүү стандарттарына жазылган. Демек, журналдарды алууну каалагандар аларды ушул форматта жазышы керек. Эгер кимдир бирөө бул форматта журналдарды жазбаса, анда биз эч нерсеге кепилдик бербейбиз.
Андан ары мен журналдарды жазуу, жеткирүү жана чогултуу ыкмалары үчүн бирдиктүү стандартка ээ болгум келет. Чынында, аларды кайда жазуу керек жана кантип жеткирүү керек. Идеалдуу жагдай - долбоорлор бир эле китепкананы колдонгондо. Go үчүн өзүнчө журнал китепканасы бар, PHP үчүн өзүнчө китепкана бар. Бизде ар ким бар, бардыгы колдонушу керек. Учурда 80 пайызга ийгиликке жетишип жатабыз деп айтат элем. Бирок кээ бирлери кактустарды жей беришет.
Жана ал жерде (слайдда) "Журналдарды жеткирүү үчүн SLA" эптеп пайда боло баштады. Ал азырынча жок, бирок биз анын үстүндө иштеп жатабыз. Анткени инфра эгер баланча жерге баланча форматта жана секундасына N билдирүүдөн көп эмес жазсаңыз, анда биз аны ошол жерге жеткиребиз деп айтканда абдан ыңгайлуу. Ал көп баш ооруну кетирет. Эгерде SLA бар болсо, анда бул эң сонун!
Биз көйгөйдү кантип чече баштадык? Негизги рейк td-агент менен болгон. Биздин журналдар кайда кетип жатканы белгисиз болчу. Алар жеткирилдиби? Алар барабы? Алар баары бир кайда? Ошондуктан td-агентти биринчи пунктка алмаштыруу чечими кабыл алынды. Аны эмне менен алмаштыруунун варианттары, мен бул жерде кыскача айтып бердим.
Fluentd. Биринчиден, мен аны мурунку жумушта кезиктирдим, ал да мезгил-мезгили менен ошол жерге жыгылды. Экинчиден, бул бир эле, профилде гана.
filebeat. Биз үчүн кандай жакшы болду? Анын Go-да экендиги жана бизде Go боюнча чоң тажрыйба бар. Демек, эгер кандайдыр бир нерсе болсо, биз аны кандайдыр бир жол менен өзүбүзгө кошо алабыз. Ошон үчүн биз алган жокпуз. Аны өзүңүз үчүн кайра жазууга азгырык болбошу үчүн.
sysadmin үчүн ачык чечим бул сандагы syslogs бардык түрлөрү (syslog-ng/rsyslog/nxlog).
Же өзүңүздүн бир нерсеңизди жазыңыз, бирок биз аны жокко чыгардык, ошондой эле filebeat. Эгер сиз бир нерсе жазсаңыз, анда бизнес үчүн пайдалуу нерсе жазганыңыз жакшы. журналдарды жеткирүү үчүн, ал даяр нерсени алып жакшы.
Демек, тандоо чындыгында syslog-ng жана rsyslog ортосундагы тандоого келди. Мен rsyslogке ыктадым, анткени бизде Куурчакта rsyslog үчүн класстар болгон жана алардын ортосунда ачык айырманы тапкан жокмун. syslog деген эмне, syslog деген эмне. Ооба, кээ бир документтер начар, кээ бир жакшы. Ал муну билет жана аны башкача кылат.
Жана rsyslog жөнүндө бир аз. Биринчиден, бул абдан сонун, анткени анын көп модулдары бар. Анын адам окуй турган RainerScript (заманбап конфигурация тили) бар. Эң сонун бонус, биз анын стандарттык куралдары менен td-агенттин жүрүм-турумун туурай алабыз жана колдонмолор үчүн эч нерсе өзгөргөн жок. Башкача айтканда, биз td-агентти rsyslog деп өзгөртөбүз жана калганына азырынча тийбейбиз. Жана дароо эле биз жумушчу жеткирүүнү алабыз. Кийинки, mmnormalize rsyslog жөнүндө сонун нерсе. Бул сизге журналдарды талдоо мүмкүнчүлүгүн берет, бирок Grok жана regexp менен эмес. Ал абстракттуу синтаксис дарагын түзөт. Ал журналдарды компилятор баштапкы кодду талдайт. Бул абдан тез иштөөгө, бир аз CPU жеп, жалпысынан алганда, бул абдан сонун нерсе. Башка көптөгөн бонустар бар. Мен аларга токтолбой эле коёюн.
rsyslog дагы бир топ кемчиликтери бар. Алар бонустар менен бирдей. Негизги көйгөйлөр - аны бышыра билүү керек жана версиясын тандоо керек.
Биз журналдарды unix розеткасына жазалы деп чечтик. Жана /dev/log ичинде эмес, анткени бизде системалык журналдардын башаламандыгы бар, бул түтүктө журналдар бар. Ошентип, келгиле, атайын розеткага жазалы. Биз аны өзүнчө эрежелер топтомуна тиркеп коёбуз. Эч нерсеге кийлигишпейли. Баары ачык-айкын жана түшүнүктүү болот. Ошентип, биз чындыгында кылдык. Бул розеткалары бар каталог стандартташтырылган жана бардык контейнерлерге жөнөтүлөт. Контейнерлер керектүү розетканы көрүп, ачып, ага жаза алышат.
Эмне үчүн файл эмес? Анткени баары окуган , файлды докерге жөнөтүүгө аракет кылган жана rsyslog кайра күйгүзүлгөндөн кийин файлдын дескриптору өзгөрүп, докер бул файлды жогото турганын аныктаган. Ал башка нерсени ачат, бирок алар жазган розетка эмес. Биз бул көйгөйдү кыйгап өтүп, ошол эле учурда блокировка маселесин да айланып өтүүнү чечтик.
Rsyslog слайдда көрсөтүлгөн аракеттерди жасайт жана журналдарды релеге же Кафкага жөнөтөт. Кафка эски жол менен жүрөт. Rayleigh - Мен журналдарды жеткирүү үчүн таза rsyslog колдонууга аракет кылдым. Message Queue жок, стандарттуу rsyslog куралдарын колдонуу. Негизинен, ал иштейт.
Бирок аларды кийинчерээк бул бөлүккө кантип толтуруу керектиги боюнча нюанстар бар (Logstash/Graylog/ES). Бул бөлүк (rsyslog-rsyslog) маалымат борборлорунун ортосунда колдонулат. Бул жерде кысылган tcp шилтемеси бар, ал өткөрүү жөндөмдүүлүгүн үнөмдөөгө жана ошого жараша канал толгондо башка маалымат борборунан кандайдыр бир журналдарды алуу ыктымалдыгын жогорулатат. Анткени бизде Индонезия бар, анда баары начар. Туруктуу маселе мына ушунда.
Биз чындыгында кантип көзөмөлдөп жатканыбыз жөнүндө ойлондук, биз тиркемеден жазган журналдар кандай ыктымалдуулук менен ошол аягына жетет? Биз метрикаларды баштоону чечтик. Rsyslog өзүнүн статистикалык чогултуу модулуна ээ, анын кандайдыр бир эсептегичтери бар. Мисалы, ал кезектин көлөмүн, же тигил же бул иш үчүн канча билдирүү келгенин көрсөтө алат. Сиз алардан бир нерсе ала аласыз. Мындан тышкары, анын сиз конфигурациялай турган ыңгайлаштырылган эсептегичтери бар жана ал сизге, мисалы, кээ бир API жазып алган билдирүүлөрдүн санын көрсөтөт. Андан кийин мен Pythonдо rsyslog_exporter жаздым жана биз анын баарын Прометейге жөнөтүп, план түздүк. Биз Graylog метрикасын чындап кааладык, бирок азырынча аларды орнотууга үлгүрө элекпиз.
Кандай көйгөйлөр бар? Көйгөй биздин Live API'лерибиз секундасына 50 миң билдирүү жазаарын билип калганыбыздан улам келип чыкты. Бул этапсыз гана Live API. Ал эми Graylog бизге секундасына 12 миң билдирүүнү гана көрсөтөт. Ал эми калдыктар кайда? Андан биз Graylog жөн эле туруштук бере албайт деген жыйынтыкка келдик. Биз карап көрдүк жана чындыгында Elasticsearch менен Graylog бул агымды өздөштүргөн жок.
Андан кийин, биз жолдо жасаган башка ачылыштар.
Розеткага жазуулар бөгөттөлгөн. Бул кандайча болду? Мен жеткирүү үчүн rsyslog колдонгондо, бир учурда биз маалымат борборлорунун ортосундагы каналды бузуп койдук. Бир жерге доставка көтөрүлдү, бир жерде доставка көтөрүлдү. Мунун баары rsyslog розеткасына жазган API'лери бар машинага келди. Кезек пайда болду. Андан кийин unix розеткасына жазуу кезеги толду, ал демейки боюнча 128 пакетти түзөт. Ал эми кийинки жазуу() колдонмо блокторунда. Go тиркемелеринде колдонгон китепкананы караганыбызда, розеткага жазуу бөгөттөлбөгөн режимде болот деп жазылган. Биз эч нерсе тоскоол болбогонуна ишенчүбүз. Анткени биз окудук бул тууралуу ким жазган. Бирок бир учур бар. Ошондой эле бул чакырыктын айланасында чексиз цикл болгон, анда розеткага билдирүү түртүүгө дайыма аракет болгон. Биз аны байкаган жокпуз. Мен китепкананы кайра жазууга туура келди. Андан бери ал бир нече жолу өзгөрдү, бирок азыр биз бардык подсистемаларда кулпулардан арылдык. Ошондуктан, сиз rsyslog токтото аласыз жана эч нерсе түшпөйт.
Бул тырмоо басып калбоого жардам берген кезектердин өлчөмүн көзөмөлдөө зарыл. Биринчиден, биз кабарларды жоготуп баштаганда көзөмөлдөй алабыз. Экинчиден, биз негизинен жеткирүү менен көйгөйлөр бар экенин көзөмөлдөй алабыз.
Жана дагы бир жагымсыз учур - микросервис архитектурасында 10 эсеге күчөтүү абдан оңой. Бизде мынчалык көп келүүчү суроо-талаптар жок, бирок бул билдирүүлөр андан ары уланып жаткан графиктен улам, кирүү журналдарынан улам, биз журналдардагы жүктү болжол менен он эсеге көбөйтөбүз. Тилекке каршы, мен так сандарды эсептегенге үлгүргөн жокмун, бирок микросервистер - бул. Муну эстен чыгарбоо керек. Көрсө, учурда журналдарды чогултуу подсистемасы Лазада эң көп жүктөлгөн.
elasticsearch маселесин кантип чечсе болот? Эгер сиз журналдарды бир жерден тез алуу керек болсо, бардык машиналарды аралап, ошол жерден чогултуп албаш үчүн, файл сактагычын колдонуңуз. Бул иштөөгө кепилдик берилет. Бул каалаган серверден жасалат. Сиз жөн гана ал жерге дисктерди жабышыңыз жана syslog коюшуңуз керек. Андан кийин, сиз бир жерде бардык журналдар болушу үчүн кепилдик берилет. Андан кийин акырындык менен elasticsearch, graylog же башка нерсени конфигурациялоого болот. Бирок сизде мурунтан эле бардык журналдар болот, андан тышкары, диск массивдери жетиштүү болсо, аларды сактай аласыз.
Мен отчет берип жаткан учурда схема ушундай боло баштады. Биз иш жүзүндө файлга жазууну токтоттук. Эми, кыязы, калдыктарды өчүрөбүз. API иштеткен жергиликтүү машиналарда биз файлдарга жазууну токтотобуз. Биринчиден, файл сактагыч бар, ал абдан жакшы иштейт. Экинчиден, бул машиналар тынымсыз орун түгөнүп жатат, аны дайыма көзөмөлдөп туруу керек.
Logstash жана Graylog менен бул бөлүк, ал чындап эле көтөрүлөт. Ошондуктан, андан арылуу керек. Сиз бирин тандоо керек.
Биз Логсташ менен Кибананы таштоону чечтик. Анткени бизде коопсуздук бөлүмү бар. Кандай байланыш бар? Байланыш X-Pack жок жана Shieldсиз Kibana журналдарга кирүү укуктарын айырмалоого мүмкүндүк бербейт. Ошондуктан, алар Graylog алышты. Анын баары бар. Мага жакпайт, бирок ал иштейт. Биз жаңы жабдыктарды сатып алдык, ал жерде жаңы Graylog орноттук жана катуу форматтагы бардык журналдарды өзүнчө Graylogго көчүрдүк. Биз уюштуруу жагынан бир эле талаалардын ар кандай түрлөрү менен маселени чечтик.
Жаңы Грейлогго эмнелер кирет. Биз бардыгын докерге жаздык. Биз бир топ серверлерди алдык, үч Кафка инстанциясын, 7 Graylog серверинин 2.3 версиясын чыгардык (анткени мен Elasticsearch 5 версиясын кааладым). Мунун баары HDD рейддеринде көтөрүлгөн. Биз секундасына 100 миң билдирүүгө чейин индекстөө ылдамдыгын көрдүк. Биз жумасына 140 терабайт маалымат деген цифраны көрдүк.
Жана дагы бир тырмоо! Бизде эки сатуу келе жатат. Биз 6 миллион посттордун чегинен аштык. Биз Грейлогдун чайнаганга убактысы жок. Кандайдыр бир жол менен кайра аман калууга туура келет.
Мына ушинтип аман калдык. Дагы бир нече серверлер жана SSD кошулду. Учурда биз ушинтип жашап жатабыз. Азыр биз секундасына 160 миң билдирүүнү чайнап жатабыз. Биз чекке жете элекпиз, андыктан андан канчалык реалдуу чыга аларыбыз белгисиз.
Булар биздин келечектеги пландарыбыз. Алардын ичинен эң негизгиси, балким, жогорку жеткиликтүүлүк. Бизде али жок. Бир нече унаалар ушундай эле орнотулган, бирок азырынча баары бир машина аркылуу өтүп жатат. Бул алардын ортосунда ишке ашпай коюу үчүн убакыт сарптоо зарыл.
Graylog'ден метрикаларды чогултуңуз.
Бизде өткөрүү жөндөмдүүлүгүн жана башка нерселердин баарын өлтүрбөгөн бир жинди API болушу үчүн тарифти чектеңиз.
Акырында, иштеп чыгуучулар менен кандайдыр бир SLAга кол коюңуз, ошондо биз ошончолук көп кызмат кыла алабыз. Көбүрөөк жазсаңыз, кечиресиз.
Жана документ жаз.
Кыскача айтканда, биз башынан өткөргөн нерселердин бардыгынын натыйжалары. Биринчиден, стандарттар. Экинчиден, syslog бул торт. Үчүнчүдөн, rsyslog слайдда кандай жазылган болсо, дал ошондой иштейт. Ал эми суроолорго келели.
суроолор.
суроо: Эмне үчүн алар албоо чечимин кабыл алышты ... (filebeat?)
жооп: Файлга жазуу керек. Мен чындап каалабадым. Сиздин API секундасына миңдеген билдирүүлөрдү жазганда, сиз саатына бир жолу айлансаңыз да, бул дагы деле вариант эмес. Трубага жазсаңыз болот. Иштеп чыгуучулар менден: "Эгер биз жазып жаткан процесс төмөндөп кетсе эмне болот" деп сурашты? Мен аларга эмне деп жооп береримди таппай: «Макул, андай кылбайлы» дедим.
суроо: Эмне үчүн сиз жөн гана журналдарды HDFSге жазбайсыз?
жоопЖ: Бул кийинки кадам. Биз бул жөнүндө эң башында ойлогонбуз, бирок учурда аны чечүү үчүн эч кандай ресурстар жок болгондуктан, бул биздин узак мөөнөттүү чечимибизде илинип турат.
суроо: Колонна форматы ылайыктуураак болмок.
жооп: Мен баарын түшүнөм. Биз эки колубуз менен “үчүн”бүз.
суроо: Сиз rsyslogке жазасыз. TCP жана UDP экөө тең ал жерде жеткиликтүү. Бирок UDP болсо, анда жеткирүүгө кантип кепилдик бересиз?
жоопЖ: Эки пункт бар. Биринчиден, мен дароо бардыгына айтам, биз журналдарды жеткирүүгө кепилдик бербейбиз. Анткени иштеп чыгуучулар келип: "Келгиле, ошол жерден каржылык маалыматтарды жазалы, эгер бир нерсе болуп калса, аны биз үчүн бир жерге коёсуңар" десе, биз аларга: "Сонун! Келгиле, розеткага жазууну блоктоп баштайлы жана транзакцияларда жасайлы, ошондо сиз аны биз үчүн розеткага салып, биз аны башка тараптан алганыбызга кепилдик бересиз. Ал эми бул учурда, ар бир адам дароо керексиз болуп калат. А эгер андай болбосо, анда бизде кандай суроолор бар? Эгер сиз розеткага жазууга кепилдик бергиңиз келбесе, анда эмне үчүн жеткирүүгө кепилдик беребиз? Биз эң жакшы аракетибизди жасап жатабыз. Биз чындап эле мүмкүн болушунча жана мүмкүн болушунча мыкты жеткирүүгө аракет кылабыз, бирок 100% кепилдик бербейбиз. Ошондуктан, ал жерде каржылык маалыматтарды жазуунун кереги жок. Бул үчүн транзакциялык маалымат базалары бар.
суроо: API журналга кандайдыр бир билдирүү жасап, башкарууну микросервистерге өткөрүп бергенде, сиз ар кандай микросервистерден келген билдирүүлөр туура эмес тартипте келген көйгөйгө туш болдуңуз беле? Ушундан улам баш аламандык пайда болот.
жоопЖ: Алардын башка тартипте келгени кадыресе көрүнүш. Сиз буга даяр болушуңуз керек. Анткени ар кандай тармак жеткирүү сизге тартипке кепилдик бербейт, же бул үчүн атайын ресурстарды коротуу керек. Эгер биз файл сактагычтарын алсак, анда ар бир API журналдарды өзүнүн файлына сактайт. Тескерисинче, rsyslog аларды ошол жерде каталогдорго ажыратат. Ар бир API'нин өзүнүн журналдары бар, ал жакка барып, карап көрсөңүз болот, андан кийин аларды бул журналдагы убакыт белгиси боюнча салыштыра аласыз. Эгерде алар Graylog'до издөөгө барышса, анда алар убакыт белгиси боюнча иргелет. Ал жерде баары жакшы болот.
суроо: Убакыт белгиси миллисекунд менен өзгөрүшү мүмкүн.
жооп: Убакыт белгиси API өзү тарабынан түзүлөт. Бул, чынында, бардык пункт болуп саналат. Бизде NTP бар. API билдирүүнүн өзүндө мурунтан эле убакыт белгисин түзөт. Ал rsyslog тарабынан кошулган эмес.
суроо: Маалымат борборлорунун ортосундагы өз ара аракеттенүү так эмес. Дата-борбордун алкагында журналдар кандайча чогултулганы жана иштетилгени ачык көрүнүп турат. Маалымат борборлорунун өз ара аракеттенүүсү кандай? Же ар бир маалымат борбору өз жашоосун жашайбы?
жооп: Дээрлик. Бизде ар бир өлкө бир маалымат борборунда жайгашкан. Учурда бизде жайылуу жок, ошондуктан бир өлкө ар кандай маалымат борборлоруна жайгаштырылат. Ошондуктан, аларды бириктирүүнүн кереги жок. Ар бир борбордун ичинде журнал реле бар. Бул Rsyslog сервери. Чынында, эки башкаруу машина. Алар ошол эле жол менен орнотулган. Бирок азырынча трафик алардын бири аркылуу өтүп жатат. Ал баарын топтоп журналга алат. Анын диск кезеги бар. Ал журналдарды басып, аларды борбордук маалымат борборуна (Сингапур) жөнөтөт, ал жерде андан ары алар Грейлогдо ууланган. Жана ар бир маалымат борборунда өзүнүн файл сактагычы бар. Байланыш үзүлүп калса, анда бизде бардык журналдар бар. Алар ошол жерде калышат. Алар ошол жерде сакталат.
суроо: Сиз анормалдуу кырдаалдарда журналдарды ошол жерден аласызбы?
жооп: Сиз ал жакка (файл сактагычка) барып, карап көрсөңүз болот.
суроо: Журналдарды жоготуп албашыңызды кантип көзөмөлдөйсүз?
жооп: Биз чындыгында аларды жоготуп жатабыз жана биз муну көзөмөлдөп жатабыз. Мониторинг бир ай мурун башталган. Go API'лери колдонгон китепканада көрсөткүчтөр бар. Ал розеткага канча жолу жаза албай калганын санай алат. Ал жерде учурда татаал эвристика бар. Ал жерде буфер бар. Андан розеткага билдирүү жазууга аракет кылат. Буфер толуп кетсе, аларды түшүрүп баштайт. Анан канчасын түшүргөнүн санайт. Ал жерде эсептегичтер толуп баштаса, бул тууралуу билебиз. Алар азыр прометейге да келе жатышат, сиз Графанадагы графиктерди көрө аласыз. Сиз эскертүүлөрдү орното аласыз. Бирок аларды кимге жөнөтүү азырынча белгисиз.
суроо: Elasticsearchте сиз журналдарды ашыкча сактайсыз. Канча көчүрмөңүз бар?
жооп: Бир реплика.
суроо: Бул бир эле сызыкпы?
жооп: Бул мастер жана реплика. Маалыматтар эки нускада сакталат.
суроо: Сиз rsyslog буферинин өлчөмүн кандайдыр бир жол менен өзгөрттүңүзбү?
жооп: Биз уникс розеткасына датаграммаларды жазабыз. Бул дароо бизге 128 килобайт чектөө киргизет. Биз ага көбүрөөк жаза албайбыз. Биз муну стандартка жаздык. Ким сактагычка киргиси келсе, алар 128 килобайт жазышат. Китепканалар, анын үстүнө, кесип, кабарды кесип деп желек коюшат. Бизде билдирүүнүн стандартында атайын тилке бар, ал жаздыруу учурунда үзүлгөнүн же өчүрүлгөнүн көрсөтөт. Ошентип, бизде бул учурду байкоого мүмкүнчүлүк бар.
Суроо: Сиз бузулган JSON жазасызбы?
жооп: Бузулган JSON реле учурунда жок кылынат, анткени пакет өтө чоң. Же Graylog өчүрүлөт, анткени ал JSON талдай албайт. Бирок бул жерде оңдоону талап кылган нюанстар бар жана алар негизинен rsyslog менен байланышкан. Мен ал жерде бир нече маселени толтурдум, алар дагы эле иштеши керек.
Суроо: Эмне үчүн Кафка? Сиз RabbitMQ сынап көрдүңүз беле? Graylog мындай жүктөрдүн астында кошулбайт?
жооп: Бул Graylog менен иштебейт. Ал эми Graylog калыптанып жатат. Ал үчүн чындап эле көйгөйлүү. Ал кандайдыр бир нерсе. Жана, чынында, бул кереги жок. Мен rsyslog'дон түз эле elasticsearchке жазып, андан кийин Кибананы көргүм келет. Бирок коопсуздук кызматкерлери менен маселени чечишибиз керек. Бул Graylog ыргытып, Kibana колдонгондо биздин өнүгүүбүздүн мүмкүн болгон варианты. Logstash мааниси жок болот. Анткени мен rsyslog менен да ушундай кыла алам. Жана анын elasticsearchке жазуу модулу бар. Graylog менен биз кандайдыр бир жол менен жашоого аракет кылып жатабыз. Ал тургай, биз аны бир аз оңдоп койдук. Бирок дагы эле жакшыртууга мүмкүнчүлүк бар.
Кафка жөнүндө. Тарыхый жактан ушундай болгон. Мен келгенде ал жерде экен, ага журналдар жазылып жаткан. Биз жөн гана кластерибизди көтөрүп, ага журналдарды көчүрдүк. Биз аны башкарабыз, анын кандай сезимде экенин билебиз. Ал эми RabbitMQ... биз RabbitMQ менен кыйынчылыкка дуушар болуп жатабыз. Жана RabbitMQ биз үчүн өнүгүп жатат. Бизде өндүрүштө бар, аны менен көйгөйлөр болгон. Эми сатуунун алдында шамандаштырып, кадимкидей иштей баштачу. Бирок ага чейин өндүрүшкө чыгарууга даяр эмес болчумун. Дагы бир нерсе бар. Graylog AMQP 0.9 версиясын окуй алат жана rsyslog AMQP 1.0 версиясын жаза алат. Ал эми ортодо экөөнү тең кыла турган бир да чечим жок. Бири же экинчиси бар. Демек, азырынча Кафка гана. Бирок нюанстар да бар. Анткени биз колдонгон rsyslog версиясынын omkafka rsyslogтен чогулткан билдирүү буферин толугу менен жоготуп алышы мүмкүн. Биз буга чыдаганыбызча.
Суроо: Кафканы сизде болгон үчүн колдонуп жатасызбы? Башка максатта колдонулбайбы?
жооп: Кафка, аны Data Science командасы колдонгон. Бул таптакыр өзүнчө долбоор, ал тууралуу мен, тилекке каршы, эч нерсе айта албайм. Билбейм. Аны Data Science командасы башкарган. журналдар башталганда, алар өз алдынча коюп эмес, ошондуктан, аны колдонууну чечишти. Азыр биз Graylog жаңырттык жана биз шайкештикти жоготтук, анткени Кафканын эски версиясы бар. Биз өзүбүздү өзүбүз жасашыбыз керек болчу. Ошол эле учурда, биз ар бир API үчүн бул төрт темадан арылдык. Биз бардыгы үчүн бир кенен чокусун түздүк, бардык сахналаштыруулар үчүн бир кең чокусун жасап, баарын ошол жерден тартабыз. Graylog мунун баарын параллелдүү түрдө чыгарат.
Суроо: Бул розеткалуу шаманизмдин бизге эмне кереги бар? Контейнерлер үчүн syslog журналынын драйверин колдонуп көрдүңүз беле.
жооп: Биз бул суроону берген учурда докер менен мамилебиз чыңалган болчу. Бул докер 1.0 же 0.9 болгон. Докердин өзү кызык болчу. Экинчиден, эгер сиз ага журналдарды да киргизсеңиз... Менде ал бардык журналдарды өзү аркылуу, докер демону аркылуу өткөрөт деген текшерилбеген шектенүү бар. Эгерде бизде бир API жинди болуп калса, калган API'лер stdout жана stderr жөнөтө албай калышат. Бул кайда алып барарын билбейм. Бул жерде докер syslog драйверин колдонуунун кереги жок деген сезимдин деңгээлинде менде шектенүү бар. Биздин функционалдык тестирлөө бөлүмүндө журналдары бар өзүнүн Graylog кластери бар. Алар докер журналынын драйверлерин колдонушат жана ал жерде баары жакшы окшойт. Бирок алар дароо Graylogке GELF деп жазышат. Ушунун баарын баштаган учурда бизге жөн эле иштөө үчүн керек болчу. Балким, кийин бирөө келип, жүз жылдан бери кадимкидей иштеп жатат десе, аракет кылабыз.
Суроо: Сиз rsyslog аркылуу маалымат борборлорунун ортосунда жеткиресиз. Эмне үчүн Кафкада эмес?
жооп: Биз муну жасайбыз жана чындыгында ушундай. Эки себеп менен. Эгерде канал толугу менен өлүп калса, анда биздин бардык журналдар, ал тургай, кысылган түрдө да, ал аркылуу өтпөйт. Жана кафка аларга процессте жөн эле утулуп калууга мүмкүндүк берет. Ушундай жол менен биз бул дөңгөчтөрдүн жабышып калышынан кутулабыз. Бул учурда биз Кафканы түз эле колдонуп жатабыз. Эгерде бизде жакшы канал болсо жана аны бошоткубуз келсе, анда биз алардын rsyslog'ун колдонобуз. Бирок, чындыгында, сиз аны өтпөгөн нерсесин түшүргүдөй кылып орното аласыз. Учурда биз жөн гана rsyslog жеткирүүсүн түздөн-түз бир жерде, бир жерде Кафка колдонуп жатабыз.
Source: www.habr.com