Loki немесе OpenSearch логтар үшін: шағын командаға салыстыру

Неліктен Loki мен OpenSearch-ті салыстыру керек

Логтар аз болғанда кез келген схема ыңғайлы көрінеді: файлға жазамыз, grep қолданамыз, кейде бәрін бір индекске түсіреміз және болашақты ойламаймыз. Бірақ сервис саны көбейгенде және логтар күн сайын ондаған гигабайтқа жеткенде әдеттегі проблема шығады: қажетті жол минуттармен ізделеді, дискілер кенеттен таусылады, ал команда өнім емес, апаттарды шешуге уақыт береді.

Сондықтан "Loki немесе OpenSearch логтар үшін" деген сұрақ қызығушылықтан емес, шаршаудан туындайды. Сақтау таңдау бюджетке (қанша және қандай дискілер қажет, қанша күн сақтау керек) және команданың нервіне (қолдау, жаңарту және ақаудан қалпына келтіру қанша уақыт алады) тікелей әсер етеді.

Логтау әртүрлі тапсырмаларды шешеді, және олар жүйені әртүрлі бағытқа тартады. Әдетте қажет:

• trace-id немесе хабарлама фрагменті бойынша қатені тез табу
• инцидент алдындағы оқиғалар тізбегін қалпына келтіру (таймлайн)
• аудит жүргізу: кім, қашан және не істегенін тексеру
• логтардан қарапайым есептер мен метрикалар алу

Loki мен OpenSearch әрқайсысы ыңғайлылық үшін әрқалай «төлем етеді». Біреу сақтау жағынан арзан болуы мүмкін, екіншісі іздеуде жылдам әрі икемдірек, бірақ ресурстар мен эксплуатация жағынан едәуір қымбат.

Алдағы бөлімде күрделендірмей: шағын команданы елестетейік — жүйені өзі ұстайды, уақыты шектеулі және болжамды шығындарды қалайды, ал жарты жылға созылатын жоба емес.

Негізгі түсініктер қарапайым тілмен

Логтың жолы әдетте қарапайым: қосымша жолдар (немесе JSON) жазады, агент оларды ұстап алады, сақтауға жібереді, ал сіз интерфейсте іздеп көресіз. Loki мен OpenSearch айырмашылығы дәл сақтау және іздеу сатыларында басталады.

OpenSearch (және Elasticsearch сияқты) индекстерге сүйенеді. Индексті мазмұнды жылдам табуға көмектесетін мазмұндық каталог деп ойлауға болады. Жылдамдық үшін дискі мен ресурстарға төленеді, өйткені тек бастапқы мәтін ғана емес, іздеу үшін қосымша деректер те сақталады.

Loki көбіне логтарды «архивке» жақын сақтайды: негізгі басымдық — қысылған мәтін және меткалар (labels). Идея мынадай: меткалар арқылы сіз керек ағымды тез тарылтасыз (мысалы, service=api және env=prod), ал таңдалған ауқым ішінде текст бойынша іздейсіз. Мәтіннің индекстеуі әдетте аз, сондықтан сақтау арзан түседі, бірақ "әр жерде кез келген сөз бойынша" іздеу ауыр болуы мүмкін. Бұл меткалардың қаншалықты ойластырылғанына тәуелді.

Екі тәсілді қысқаша:

• OpenSearch: құрылым және индекстер көп, күрделі сұраулар жылдам, сақтау мен эксплуатация қымбатырақ.
• Loki: индекстер аз, сақтау арзан, меткаларға тәртіп маңызды, мәтін бойынша іздеу жиі алдын ала сүзгілеуді талап етеді.

Қандай жүйе болса да айналасында бірдей компоненттер болады: түйіндердегі лог жинағыш, жеткізу (буфер және қайталау), сақтау және визуализация, дашбордтар мен алерттер. Шағын команда болса, бастапқыда кім өрістер немесе меткалар схемасына, сақтау мерзіміне және рұқсаттарға жауапты екенін айқындап алыңыз. Бұл "кішігірім" шешімдер кейін жылдамдықты, бағаны және түнгі инциденттер санын анықтайды.

Логтарды сақтау: көлем, мерзім және диск түрлері

Сақтау Loki мен OpenSearch туралы даулы сұрақтардың көп бөлігін шешеді. Бұл жүйелер деректерді әртүрлі сақтайды және сол себепті әртүрлі дисктерді тұтынады.

OpenSearch-та логтар индекстерге және диск上的 сегменттерге айналады. Бұл күрделі іздеу үшін ыңғайлы, бірақ индекс бастапқы мәтінен елеулі түрде үлкен болуы мүмкін. Әдетте локальды SSD қолданады, кейде деректерді "ыстық" және "суық" деңгейлерге бөледі.

Loki-да индекс минималды (негізінен меткалар), ал логтар қысылған чанктерде сақталады. Шағын команда үшін ең үнемді вариант — чанктер объектілік сақтау (S3-қа ұқсас немесе аналог) үстінде жатуы, ал локальды дискіде тек жұмыс және кэшке қажет заттардың қалуы.

Көлем өсімі көбіне қызмет саны ғана емес, жазу деңгейіне (INFO vs DEBUG), біртекті оқиғалардың жиілігі мен форматқа байланысты. Әр оқиға үлкен JSON ретінде дублирленген өрістермен жазылса, сақтау айтарлықтай өседі.

Retention (сақтау мерзімі) диск түрінен әлдеқайда маңыздырақ. 7 күн мен 30 күн арасында айырмашылық тек аз ғана емес — орын көлемі 4 есе және одан да көп болуы мүмкін, яғни бағаға, бэкапқа және қалпына келтіруге әсері зор.

Шығынды бақылау үшін алдын ала не ыстық (соңғы 3–7 күн SSD-те) екенін, не суыққа өте алатынын шешіңіз. Сонымен қатар қандай логтарды қысқартуға болатынын (мысалы, debug) және қай өрістер әр хабарламада міндетті емес екенін анықтаңыз.

Қарапайым мысал: команда күн сайын 50 ГБ лог жазады. 30 күн сақтау — 1,5 ТБ бастапқы деректер; индекстер, репликалар және өсу запасын қоссақ, көлем бірнеше есе артады. Сондықтан "қанша күн сақтау" пен "суық қабатты қайда сақтау" көбіне диск түрінен артық әсер береді.

Іздеудің жылдамдығы: нені әсер етеді

"Жылдамдық" дегенде әдетте мына негізгі тапсырмалар түсініледі: trace-id бойынша қатені табу, нақты қолданушы оқиғаларын көру, 500 қатесіндегі жауаптарды сүзу немесе соңғы 15 минуттағы қызмет бойынша таңдау. Мұнда маңыздысы платформа ғана емес, сіз деректерді қалай сипаттағаныңыз.

OpenSearch-та жылдамдық индекстер мен өрістерге сүйенеді. Егер сіз алдын ала қажетті өрістерді (trace_id, user_id, status_code, service, env) бөліп, индекс болса, нүктелік сұраулар үлкен көлемде де тез жұмыс істейді. Ал бәрі бір үлкен мәтін ретінде жинақталса, жүйеге ауыр жүк түседі және жауап уақыты өседі.

Loki-та кілтті рөл меткалар мен алдын ала сүзгілеу ойнайды. Жақсы сұрау алдымен бірнеше метка бойынша ағынды тарылтады (мысалы, service + env + pod), содан соң мәтін ішінен іздейді. Егер меткалар аз немесе өте жалпы болса, Loki көп дерек оқиды да іздеу баяулайды.

Екі модельде де іздеуді жылдамдататын ортақ тәсілдер: анық схема (өрістердің атауы), тар уақыт терезесі, көз бойынша сүзгілер (қызмет, орта, кластер) және содан кейін ғана толық мәтіндік іздеу. Құрылымдалған JSON форматтары әдетте "барлығы туралы мәтін" қарағанда сүзгіден өткізу оңайырақ.

Керісінше баяулататындар: шектеусіз толық мәтіндік іздеу, мақсатсыз "айынағы барлық қателерді көрсет" сияқты кең сұраулар, өте жалпы меткалар немесе өрістер, сондай-ақ меткаларда бақылаусыз өсетін бірегей мәндер (мыс., request_id).

Адал бағалау үшін бірдей деректер көлемі мен бірдей сұраулар бойынша сынақ жасаңыз. Команда жүзетін 3–5 типтік сценарийді (trace-id, қолданушы, 500, нақты қызмет, жүктеме шыңы) таңдап, бірдей кезеңде орындаңыз. Көп жағдайда баяу — Loki немесе OpenSearch емес, логтардың құрылымсыз жазылуынан болады: сүзгілейтін ештеңе қалмайды.

Шығын: дискілер, ресурстар және жасырын шығындар

Шығын әдетте дискіден басталады, бірақ соңында қанша нодты жылдамдық үшін ұстап тұру керегіне барып аяқталады.

Бюджеттің құрамына: деректер орны, қабылдау мен сұраулар үшін CPU мен RAM, желі (пиктерде), бэкаптар және қолдауға кететін адамдар уақыты кіреді. OpenSearch-та тек көлемге ғана емес, индекстердің жады мен I/O талабына да ақша жұмсайсыз. Loki-да сақтау жиі арзан (объектілік сақтау қолданғанда), бірақ күрделі сұраулар мен жоғары параллелизм ресурсты қажет етеді.

Арзан диск кейін қымбатқа айналуы мүмкін егер ол баяу болса. HDD-ге көшу кейде 1 ТБ үшін бағаны арзандатады, бірақ баяу оқу/жазу себебінен жоғарыда көбірек нод қажет болып, жалпы шығын өседі. Қорытынды шоты үлкен болуы мүмкін, ал команда жиі апаттарды талдайды.

Көбінесе өсу 2–3 есе жылына ескерілмейді, пиктер, репликалар (көбінесе x2 дискіге) және апаттан кейін деректерді қайта құруға арналған запас ұмытылып кетеді. Сондай-ақ бэкаптар, қалпына келтіру тесттері және компакцияға арналған уақытша файлдар есепке алынуы керек. Уақыттың құны да бар: егер іздеу баяу болса, инженер сағаттар жұмсайды, минуттар емес.

Оңай есептеу тәсілі: қажетті сақтау мерзімімен 1 ТБ үшін ай сайынғы бағаны есептеңіз. Күнделікті орташа көлемді алу, күндерге көбейту, өсу мен пиктерге (+50% сияқты) запас қосу және репликация коэффициентін қолдану арқылы нақты төленетін терабайт саны шығады. Содан кейін екі сценарийді салыстырасыңыз: арзанырақ орынмен ауыр іздеу немесе аз орынмен жылдам іздеу, қайсысы сізге операциялық шығындарды аз жұмсатады.

Шағын командада эксплуатация: қай жерде ауыр болады

Екі-үш адам бүкіл инфрақұрылымды ұстайтын болса, басты сұрақ "не тезірек" емес, "не түнде оятады емес". Құралдар функционалға қарай таңдалады, бірақ жеңіске сол нұсқа жетеді, оны арнайы SRE болмаған жағдайда оңай ұстауға болады.

Қай нәрселер уақытты жұтады

Ауырлық бірінші күннен емес, 2–4 апта өткенде байқалады, логтар өсіп, өнім тапсырмалары азапты қалғанда. Уақыт көбінесе жаңартулар мен үйлесімділікке (агенттер, сақтау, визуализация), retention пен диск толуын бақылауға, бэкап пен қалпына келтіруге, алерттер мен жалған срабатыванияларды талқылауға кетеді. Жеке категория — инциденттер, мысалы "іздеу ештеңе таппайды", бірақ проблема нақты болғанда.

OpenSearch-та операциялық тапсырмалар көбіне көп: кластер, шардинг, индекстер күйі, ресурс жоспарлау. Ол Elasticsearch-пен жұмыс істегендерге таныс келеді. Loki сақтау жағынан жеңілірек болуы мүмкін, бірақ меткаларға тәртіп қажет: бәрін меткаға салып жіберсеңіз кардиналдылық өсіп, жүктеме мен шығындар тез артады.

Қажет практикалар, олар болмаса қиындық шығады

Шағын команда алдын ала минималды ережелер туралы келісіп алғаны дұрыс, әйтпесе жүйе біртіндеп "шашылады".

• Лог жүйесін өзін мониторингтеу керек: ingestion кешігуі, жазу қателері, диск толымы, сұраулар латенттігі.
• Өсу бақылауы: көлемге шектеулер, prod пен stage үшін сақтау мерзімі, тұрақты қайтара қарау.
• Қол жеткізуді бөлу: кім барлығын көреді, кім тек өз сервисін көре алады, құпиялар қай жерде.
• Апат жағдайындағы әрекет жоспары: диск толған кезде, сақтау қолжетімсіз болғанда немесе нод құлаған кезде не істеледі.

Лог форматында келісу де маңызды: бірдей өрістер (service, env, trace_id) болу үшін, әйтпесе іздеу болжамсыз болады. Мысалы, біреу Loki-ге user_id меткасын қосса, апта ішінде кардиналдылық шарықтап кетуі мүмкін. Немесе OpenSearch-та тым детальды индекстеу қосып қойсаңыз, кластер CPU-ны сегменттерге жұмсайды. Мұндай заттар бірден байқалмайды, сондықтан қысқа регламент пен күнделікті лог денсаулығын бір жерде қарау пайдалы.

Таңдау: команданың үшін қадамдық жоспар

Аты-жөнінен құралдарды бастамаңыз — адамдардың нақты қалай іздейтінін анықтаудан бастаңыз. Сол кезде таңдау гипотезаларды тексеруге айналады, таластарға емес.

30 минутқа команда жинап, қадамдардан өтіңіз:

• 3–5 ең жиі қолданылатын сұрауды жазыңыз: қызмет бойынша, қате бойынша, қолданушы бойынша, инцидент уақыты бойынша. Агрегациялар қажет пе (мыс., күн бойынша жоғарғы қателер) немесе көбінесе "нақты ізі табу" ма — бұл маңызды.
• Сақтау мерзімін және қабылданатын кешігу уақытын анықтаңыз: 7 күн бе, әлде 90 күн ме; соңғы логтардың бірнеше минут ішінде келуі керек пе; 5–10 минут кешігу қолайлы ма.
• Формат пен минималды өрістерді бекітіңіз: timestamp, деңгей (info/warn/error), сервис, орта (prod/stage), trace_id немесе request_id және хабарлама мәтіні әдетте жеткілікті.
• 7–14 күнге нақты деректермен пилот жасаңыз: сол көлем, сол көздер, сол типтік сұраулар.
• Қорытындыны кестеге салыңыз: 30 күнге нақты көлем бойынша сақтау құны мен өсуі, типтік сұраулардың жылдамдығы, аптасына қолдауға кеткен сағаттар (жаңарту, retention, алерттер), жүйеге жаңадан келген адамға қаншалықты түсінікті екені.

Және лог жазу ережелерін бекітіңіз: кім құрылымға жауапты, өрістер қалай аталады, не жазуға болмайды (құпиялар, ПД), шықпас бұрын лог сапасын қалай тексересіз. Бір қысқа құжат көп жағдайда жүйені ауыстырудан гөрі көбірек пайда әкеледі.

Тұрақты қателер мен тұзақтар

Ең көп кездесетін проблема — "барлығын сақтап қой" ойы. Продта ең жоғары детализацияны қосып, көлемге шектеу қоймай, шуды (health-check, кітапханалардың debug-жазбалары, жиі болатын 404) кеспегенде диск тез таусылады және іздеу қиын болады.

Екінші тұзақ — өрістер мен меткаларды атаудың ережесінің болмауы. Loki-да бұл меткалардың «қарқынды өсуі» ретінде, OpenSearch-та әр түрлі сервистердегі бірдей оқиғаның әртүрлі сипатталуы ретінде көрінеді. Нәтиже бірдей: сұрау деректермен сәйкес келмей, адамдар шикі жолдар бойынша "көзбен іздеуге" көшеді.

Көбіне сақтау мерзімі кездейсоқ таңдалады: "90 күн болсын". Бірақ күндік көлем, сығымдау, репликация және диск түрін бағамдамай бұл лотереяға айналады. Әсіресе қазіргі кішкентай көлемге қарап шешім қабылданса, қауіп бар.

Тағы бір қауіп — барлығына барлыққа қолжетімділік. Логтарда пайдаланушылардың аттары, токендер, адрестер, қате деректері болуы мүмкін. Рөлдер мен маскирлеусіз бұл утечка тәуекелі жоғарылайды. Қауіпсіздік талаптары бар ұйымдар үшін (мемлекеттік немесе қаржы) бұл жобаны бөгейтін факторға айналуы мүмкін.

Соңында, кішкентай көлемдегі пилот "бәрі жылдам" деген жалған сезім береді. 5 ГБ/күнде бәрі тез болуы мүмкін, ал бірнеше айдан кейін 200–500 ГБ/күнге жеткенде дискі, жады және қолдау уақытын қайта қарау керек болады.

Қысқа тексеріс, ол жиі көмектеседі:

• Продта лог деңгейлерін шектеңіз және шуды кесіңіз.
• Біртұтас өріс аттарын және міндетті меткаларды бекітіңіз (service, env, версия).
• Шығынды нақты фактілер бойынша есептеңіз: ГБ/күн × сақтау күндері × репликация, сонда диск таңдау айқын болады.
• Командалар мен орталар бойынша рөлдер мен қолжетімділікті орнатыңыз.
• Қолданыстағы көлемді "алдағы алты айдағы өсім" деңгейінде тексеріп шығыңыз, не бүгінгі күндегі көлемде емес.

Шешімге дейінгі қысқа чек-лист

Түсінбестікті жою үшін 20 минутта бірнеше сұраққа жауап жинаңыз.

Алдымен нақты цифрлар: қазіргі лог көлемі және 3–6 айға прогноз. Қате — апталық орташа алып, пиктерді ұмыту. Пиктер көбіне дискі мен нод санын шешеді.

Содан кейін сақтау ережелерін нақтылаңыз: логтарды типтер бойынша бөлу және әрқайсысының мерзімін анықтау. Әртүрлі сақтау мерзімі баға мен тәуекелдірақ басқаруға көмектеседі.

Күнделікті қандай іздеулер жасалатынын тексеріңіз. 10-ға жуық ең жиі сұрауды жазып, қайсысы жылдам ашылуы керек екенін белгілеңіз — әдетте бұл сервис бойынша қателер мен уақыт, қолданушы немесе request-id бойынша іздеу және инцидентті тергеу үшін бірнеше өріс бойынша таңдаулар.

Тәуекелдер бойынша талапты бекітіңіз: логтар бойынша іздеу 1 сағатқа болмайтын жағдайда не болады және апаттан кейін қалпына келтіруге қанша уақыт бөліп отырсыз.

Соңғы және практикалық пункт: жүйенің дежурилігін кім атқарады. Платформа иесін тағайындап, аптасына қанша уақыт жұмсайтыныңызды адал бағалаңыз. Егер "шамамен ешкім" болса, аз қолмен жұмысы бар шешімді таңдаңыз.

Шынайы мысал: шағын команда және лог көлемінің өсуі

8 адамнан тұратын команда 6 сервиске қызмет көрсетеді: екі монолит VM-де және төрт контейнерлік сервис. Релиздер аптасына 2–3 рет шығады, басты мәселе — релизден кейін қатені тез табу. Кейде инциденттер болып, тәуліктік не екі күндік тізбекті қалпына келтіру керек.

Платформа инженері бөлек жоқ. Логтарды кезекпен қарайды: бүгін әзірлеуші, ертең дежурный. Дискілерге бюджет шектеулі, сондықтан бәрін айлап сақтау мүмкін емес. Команда бастапқыда 30 күн сақтау ойлайды және кейін қайта қарайды.

Салыстыру әділ болуы үшін пилотты бірдей енгізеді: бірдей көздер (API логтары, воркер, прокси базасы және ingress) және бірдей сұраулар: "соңғы 15 минуттағы қателер", "барлық оқиғалар request_id бойынша", "релизден кейін 5xx пиктері". Алдын ала келісу маңызды: жоғарғы халықаралық жылдамдықтан тек қозғалтқыш жылдамдығын емес, сұрау енгізіп нәтижеге дейінгі толық уақытты есептеу керек.

Табыстың критерийлері қарапайым:

• шың уақыттардағы 3–5 типтік сұраудың жауап уақыты
• нақты көлеммен 30 күнге сақтау құны (репликаларды есепке алып)
• аптасына қанша қолмен әрекет керек (ротация, алерттер, жаңарту, апаттар)
• жаңадан келген адамға қаншалықты оңай табу (сұрау шаблондары, түсінікті өрістер)
• жүйе екі есе өскенде қалай жүретіні

Көп жағдайда нәтиже былай шығады: егер сіз негізінен меткалар мен уақыт бойынша сүзгі жасасаңыз, Loki оңай ұсталып, диск жағынан үнемді. OpenSearch күрделі мәтіндік және көп өрістер бойынша іздеу керек болса жеңіп шығады, бірақ индекстер, ресурстар және эксплуатация жағынан қымбатырақ.

Келесі қадамдар: пилот, инфрақұрылым және қолдау

Салыстырудан кейін бірден "жеңімпазды" таңдамайсын. 2–3 архитектуралық вариантты нақтылап, дежуритіндермен талқылаңыз. Практикада дау көбіне адамдардың қалай нақты қателер іздейтінінен және жүйені кім ұстайтынынан шешіледі.

Пилотты бастамас бұрын бағалау критерийлерін бекітіңіз. Әйтпесе екі аптадан кейін әркім "ыңғайлығын" өзше өлшеп, деректер қате жиналуы мүмкін.

Мини-пилот: не тексеру керек

Пилот қысқа әрі адал болуы керек: 7–14 күн, нақты логдар, нақты жүктеме. Бір маңызды сервис пен бір "шулы" сервис алыңыз, шет жағдайларды көру үшін.

Тексеру керек:

• 3–5 типтік сұрауға жауап уақыты (қатынастар бойынша қателер, trace-id бойынша іздеу, latency шарықтауы)
• сақтау құны: күнделікті орын және 30–90 күнге болжам
• сенімділік: агент немесе нод құлаған кезде не болады, қабылдау қаншалықты тез қалпына келеді
• операциялық тапсырмалар: жаңарту, бэкаптар, ротация, бұл жұмыстарды кім және қалай орындайды
• қауіпсіздік пен қолжетімділік: командалар мен орталар бойынша шектеулер

Инфрақұрылым және қолдау

Өсуге запас бойынша дискілер мен жадты жоспарлаңыз: логтардың көлемі әдетте күткеннен тез өседі. Егер логтау өндірістік қызметке әсер етсе, сақтау мен іздеу ресурстарын бизнес-сервисерден бөлу жақсы. Мұндай жұмыстар үшін көбіне GSE S200 Series деңгейіндегі стойкалық серверлер қолданылады — есептеуді қосымшалардан бөліп, сыйымдылықты жоспарлау оңайлайды.

Қазақстанда тұрақты жеткізілім мен сервисті ұнатсаңыз, GSE-мен (gse.kz) жергілікті өндіруші және жүйелік интегратор опциясын алдын ала қарастыруға болады. Бұл жабдықты, енгізуді және кейінгі қолдауды жабатын жағдайда командада қолмен құрастыруға уақыт аз болса ыңғайлы.

Соңғы қадам — жауаптыларды тағайындау: лог платформа иесі, қолжетімділіктерге жауапты және пилот нәтижелері бойынша шешім қабылдайтын адам мен нақты мерзім.