Биз Badooдо жаңы технологияларды тынымсыз көзөмөлдөп турабыз жана аларды системабызда колдонуу керекпи же жокпу баалайбыз. Биз бул изилдөөлөрдүн бирин коомчулук менен бөлүшкүбүз келет. Ал Локиге, журналдарды бириктирүү тутумуна арналган.
Loki журналдарды сактоо жана көрүү үчүн чечим болуп саналат жана бул стек аларды талдоо жана Prometheus'га маалыматтарды жөнөтүү үчүн ийкемдүү системаны камсыз кылат. Май айында дагы бир жаңыртуу чыгарылды, аны жаратуучулар жигердүү өнүктүрүшөт. Бизди Локи эмне кыла алат, ал кандай мүмкүнчүлүктөрдү берет жана ал азыр биз колдонуп жаткан ELK стекке альтернатива катары канчалык деңгээлде иштей аларына кызыктык.
Локи деген эмне
Grafana Loki - бул толук каттоо системасы үчүн компоненттердин жыйындысы. Башка ушул сыяктуу системалардан айырмаланып, Loki журналдын метаберилиштерин гана индекстөө идеясына негизделген - энбелгилер (Прометейдегидей) жана журналдарды өзүнчө бөлүктөргө жанаша кысуу.
,
Локи менен эмне кыла аларыңызды түшүнгөнгө чейин, мен "метаберилиштерди гана индекстөө идеясы" эмнени билдирерин тактагым келет. Келгиле, Loki ыкмасын жана Elasticsearch сыяктуу салттуу чечимдердеги индекстөө ыкмасын салыштырып көрөлү, nginx журналындагы сызык мисалында:
172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"Салттуу системалар бүт сапты, анын ичинде көптөгөн уникалдуу user_id жана item_id маанилери бар талааларды талдап, баарын чоң индекстерде сактайт. Бул ыкманын артыкчылыгы сиз татаал сурамдарды тез аткара аласыз, анткени дээрлик бардык маалыматтар индексте. Бирок бул үчүн төлөшүңүз керек, анткени индекс чоң болуп калат, бул эстутум талаптарын которот. Натыйжада, журналдардын толук тексттик индекси журналдардын өздөрү менен салыштырууга болот. Аны тез издөө үчүн индексти эс тутумга жүктөө керек. Ал эми журналдар канчалык көп болсо, индекс ошончолук тез өсөт жана эстутум ошончолук көп сарпталат.
Локи ыкмасы саптан керектүү маалыматтарды гана алууну талап кылат, анын маанилеринин саны аз. Ошентип, биз кичинекей индекске ээ болобуз жана аны убакыт жана индекстелген талаалар боюнча чыпкалоо аркылуу маалыматтарды издей алабыз, андан кийин калганын кадимки туюнтмалар же субсап издөөлөр менен сканерлей алабыз. Процесс эң тез көрүнбөйт, бирок Локи суроо-талапты бир нече бөлүккө бөлүп, аларды параллелдүү аткарып, кыска убакыттын ичинде чоң көлөмдөгү маалыматтарды иштеп чыгат. Алардагы сыныктардын жана параллелдүү сурамдардын саны конфигурацияланат; Ошентип, убакыт бирдигине иштетиле турган маалыматтардын көлөмү берилген ресурстардын көлөмүнө сызыктуу көз каранды.
Бул чоң ылдам индекс менен кичинекей параллелдүү катаал күч индексинин ортосундагы соодалоо Lokiге системанын баасын көзөмөлдөөгө мүмкүндүк берет. Ал ийкемдүү конфигурацияланган жана муктаждыктарыңызга жараша кеңейтилиши мүмкүн.
Loki стек үч компоненттен турат: Promtail, Loki, Grafana. Promtail журналдарды чогултуп, аларды иштетип, Локиге жөнөтөт. Локи аларды сактайт. Жана Grafana Локиден маалыматтарды сурап, көрсөтө алат. Жалпысынан алганда, Loki журналдарды сактоо жана алар аркылуу издөө үчүн гана эмес, колдонулушу мүмкүн. Бүткүл стек Prometheus жолу менен келген маалыматтарды иштеп чыгуу жана талдоо үчүн чоң мүмкүнчүлүктөрдү берет.
Орнотуу процессинин сүрөттөмөсүн тапса болот .
Журнал издөө
Сиз журналдарды атайын Grafana — Explorer интерфейсинен издей аласыз. Суроолор Prometheus колдонгон PromQLге абдан окшош LogQL тилин колдонушат. Негизи, аны бөлүштүрүлгөн grep катары кароого болот.
Издөө интерфейси төмөнкүдөй көрүнөт:
Сурамдын өзү эки бөлүктөн турат: селектор жана чыпка. Selector – журналдарга дайындалган индекстелген метаберилиштер (белгилер) боюнча издөө, ал эми чыпка – селектор тарабынан аныкталган жазууларды чыпкалоочу издөө саптары же regexp. Берилген мисалда: Тармал кашааларда - селектор, андан кийин бардыгы - чыпка.
{image_name="nginx.promtail.test"} |= "index"Loki иштөө ыкмасына байланыштуу, сиз селекторсуз сурамдарды жасай албайсыз, бирок энбелгилерди өзүм билемдик менен жалпы кылып койсоңуз болот.
Селектор тармал кашаалардагы маанинин ачкыч-маании. =, != операторлорунун же кадимки туюнтмалардын жардамы менен селекторлорду бириктирип, ар кандай издөө шарттарын белгилей аласыз:
{instance=~"kafka-[23]",name!="kafka-dev"}
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev Чыпка - бул селектор тарабынан алынган бардык маалыматтарды чыпкалай турган текст же regexp.
Метрика режиминде алынган маалыматтардын негизинде атайын графиктерди алууга болот. Мисалы, сиз индекс сапты камтыган жазуунун nginx журналдарынан пайда болуу жыштыгын биле аласыз:
Функциялардын толук сыпаттамасын документациядан тапса болот .
Журнал талдоо
журналдарды чогултуу үчүн бир нече жолдору бар:
- Промтайлдын жардамы менен журналдарды чогултуу үчүн стектин стандарттык компоненти.
- Түздөн-түз докер контейнеринен
- Lokiге маалыматтарды жөнөтө турган Fluentd же Fluent Bit колдонуңуз. Promtailден айырмаланып, алар журналдын дээрлик бардык түрү үчүн даяр талдоочуларга ээ жана көп саптык журналдарды да иштете алышат.
Адатта Promtail талдоо үчүн колдонулат. Ал үч нерсени кылат:
- Маалымат булактарын табат.
- Аларга энбелгилерди чаптаңыз.
- Lokiге дайындарды жөнөтөт.
Учурда Promtail локалдык файлдардан жана системалык журналдан журналдарды окуй алат. Ал журналдар чогултулган ар бир машинага орнотулушу керек.
Kubernetes менен интеграция бар: Promtail автоматтык түрдө Kubernetes REST API аркылуу кластердин абалын аныктайт жана түйүндөн, кызматтан же поддон журналдарды чогултуп, Kubernetes метаберилиштеринин негизинде энбелгилерди дароо жарыялайт (поддун аты, файлдын аты ж.б.).
Сиз ошондой эле Pipeline аркылуу журналдагы маалыматтардын негизинде энбелгилерди илип койсоңуз болот. Promtail түтүгү төрт этаптан турушу мүмкүн. Кененирээк маалымат - in , Мен дароо айрым нюанстарды белгилей кетейин.
- Талдоо этаптары. Бул RegEx жана JSON баскычы. Бул этапта, биз алынган карта деп аталган журналдарга маалыматтарды чыгарып. Сиз JSONдан бизге керектүү талааларды чыгарылган картага көчүрүү менен же кадимки туюнтмалар (RegEx) аркылуу чыгарып алсаңыз болот, мында аталган топтор чыгарылган картага "картага түшүрүлөт". Чыгарылган карта ачкыч-маанилердин сактагычы, мында ачкыч талаанын аталышы, ал эми маани журналдардагы анын мааниси.
- Трансформация этаптары. Бул этапта эки вариант бар: трансформация, мында трансформация эрежелерин орнотобуз жана булак - алынган картадан трансформация үчүн маалымат булагы. Эгерде алынган картада мындай талаа жок болсо, анда ал түзүлөт. Ошентип, алынган картага негизделбеген энбелгилерди түзүүгө болот. Бул этапта, биз бир кыйла күчтүү колдонуу менен алынган картадагы маалыматтарды манипуляциялай алабыз . Мындан тышкары, талдоо учурунда алынган карта толугу менен жүктөлгөнүн эстен чыгарбашыбыз керек, бул, мисалы, андагы маанини текшерүүгө мүмкүндүк берет: “{{if .tag}тегдин мааниси бар{end}}”. Шаблон шарттарды, циклдерди жана алмаштыруу жана кыркма сыяктуу кээ бир сап функцияларын колдойт.
- Аракет этаптары. Бул этапта, сиз алынган менен бир нерсе кыла аласыз:
- Чыгарылган маалыматтардан энбелги түзүңүз, ал Loki тарабынан индекстелет.
- Журналдан окуянын убактысын өзгөртүү же коюу.
- Локиге бара турган маалыматтарды (лог текстин) өзгөртүңүз.
- Метрикаларды түзүү.
- Фильтрлөө этаптары. Дал келүү баскычы, анда биз /dev/null кереги жок жазууларды жөнөтө алабыз же аларды андан ары иштетүү үчүн жөнөтө алабыз.
Жөнөкөй nginx журналдарын иштетүү мисалында, мен Promtail аркылуу журналдарды кантип талдоо болорун көрсөтөм.
Сыноо үчүн өзгөртүлгөн nginx jwilder/nginx-proxy:alpine сүрөтүн жана nginx-прокси катары HTTP аркылуу өзүн сурай алган кичинекей демонду алалы. Демондун бир нече акыркы чекиттери бар, аларга ар кандай өлчөмдөгү, ар кандай HTTP статустары жана ар кандай кечигүү менен жооп бере алат.
Биз журналдарды /var/lib/docker/containers/ жолунда тапса болот докер контейнерлеринен чогултабыз. / -json.log
docker-compose.yml ичинде биз Promtail орнотуп, конфигурациянын жолун аныктайбыз:
promtail:
image: grafana/promtail:1.4.1
// ...
volumes:
- /var/lib/docker/containers:/var/lib/docker/containers:ro
- promtail-data:/var/lib/promtail/positions
- ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
command:
- '-config.file=/etc/promtail/promtail.yml'
// ...
promtail.yml дарегине журналдарга жолду кошуңуз (конфигурацияда бир сапта дал ушундай кылган "докер" опциясы бар, бирок бул анчалык ачык болбойт):
scrape_configs:
- job_name: containers
static_configs:
labels:
job: containerlogs
__path__: /var/lib/docker/containers/*/*log # for linux onlyБул конфигурация иштетилгенде, Loki бардык контейнерлерден журналдарды алат. Мунун алдын алуу үчүн, биз docker-compose.yml ичиндеги nginx сынагынын жөндөөлөрүн өзгөртөбүз - тег талаасына журнал жазуусун кошобуз:
proxy:
image: nginx.test.v3
//…
logging:
driver: "json-file"
options:
tag: "{{.ImageName}}|{{.Name}}"promtail.yml түзөтүү жана Pipeline орнотуу. Журналдар төмөнкүдөй:
{"log":"u001b[0;33;1mnginx.1 | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /api/index HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.096"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1 | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /200 HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.000"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}түтүк этаптары:
- json:
expressions:
stream: stream
attrs: attrs
tag: attrs.tagКирүүчү JSONдон агым, attrs, attrs.tag талааларын (эгер бар болсо) чыгарып, аларды алынган картага салабыз.
- regex:
expression: ^(?P<image_name>([^|]+))|(?P<container_name>([^|]+))$
source: "tag"Эгерде алынган картага тег талаасын коюу мүмкүн болсо, анда regexpди колдонуу менен биз сүрөттүн жана контейнердин атын чыгарабыз.
- labels:
image_name:
container_name:Биз энбелгилерди дайындайбыз. Эгерде алынган маалыматтарда image_name жана container_name баскычтары табылса, анда алардын маанилери тиешелүү энбелгилерге ыйгарылат.
- match:
selector: '{job="docker",container_name="",image_name=""}'
action: dropimage_name жана container_name коюлган энбелгилери жок бардык журналдарды жокко чыгарабыз.
- match:
selector: '{image_name="nginx.promtail.test"}'
stages:
- json:
expressions:
row: logImage_name nginx.promtail.test менен барабар болгон бардык журналдар үчүн булак журналынан журнал талаасын чыгарып, аны сап баскычы менен алынган картага салыңыз.
- regex:
# suppress forego colors
expression: .+nginx.+|.+[0m(?P<virtual_host>[a-z_.-]+) +(?P<nginxlog>.+)
source: logrowКиргизүү сабын кадимки туюнтмалар менен тазалап, nginx виртуалдык хостун жана nginx журнал сызыгын чыгарабыз.
- regex:
source: nginxlog
expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?Nginx журналын кадимки туюнтмалар менен талдоо.
- regex:
source: request_url
expression: ^.+.(?P<static_type>jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
- regex:
source: request_url
expression: ^/photo/(?P<photo>[^/?.]+).*$
- regex:
source: request_url
expression: ^/api/(?P<api_request>[^/?.]+).*$request_url талдоо. Regexp жардамы менен биз сурамдын максатын аныктайбыз: статикага, сүрөттөргө, APIге жана алынган картага тиешелүү ачкычты орнотобуз.
- template:
source: request_type
template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"Үлгүдөгү шарттуу операторлорду колдонуу менен биз алынган картада орнотулган талааларды текшеребиз жана request_type талаасына керектүү маанилерди коебуз: фото, статикалык, API. Эгер ишке ашпай калса, башканы дайындаңыз. Эми request_type суроонун түрүн камтыйт.
- labels:
api_request:
virtual_host:
request_type:
status:Чыгарылган картага эмнелерди киргизе алганыбыздын негизинде api_request, virtual_host, request_type жана статус (HTTP статусу) энбелгилерин койдук.
- output:
source: nginx_log_rowЧыгууну өзгөртүү. Эми алынган картадан тазаланган nginx журналы Локиге барат.
Жогорудагы конфигурацияны иштеткенден кийин, ар бир жазуу журналдан алынган маалыматтардын негизинде белгиленгенин көрө аласыз.
Көп сандагы баалуулуктар (кардиналдуулук) бар энбелгилерди алуу Lokiди бир топ жайлатышы мүмкүн экенин унутпаңыз. Башкача айтканда, индекске киргизбешиңиз керек, мисалы, user_id. Бул тууралуу кененирээк макаладан окуңуз". Бирок бул индекссиз user_id боюнча издөө мүмкүн эмес дегенди билдирбейт. Издөөдө фильтрлерди колдонуу керек («маалыматтар боюнча кармап алуу») жана бул жерде индекс агымдын идентификатору катары иштейт.
Журналдын визуализациясы
Loki LogQL аркылуу Grafana диаграммалары үчүн маалымат булагы катары иштей алат. Төмөнкү өзгөчөлүктөр колдоого алынат:
- ылдамдыгы - секундасына жазуулардын саны;
- убакыттын өтүшү менен эсептөө - берилген диапазондогу жазуулардын саны.
Ошондой эле Sum, Avg жана башкаларды бириктирүүчү функциялар бар. Сиз абдан татаал графиктерди түзө аласыз, мисалы, HTTP каталарынын санынын графигин:
Loki'нин демейки маалымат булагы Prometheus маалымат булагына караганда бир аз азыраак иштейт (мисалы, легенданы өзгөртө албайсыз), бирок Loki Prometheus тибиндеги булак катары туташса болот. Бул документтештирилген жүрүм-турум экенине ишенбейм, бирок иштеп чыгуучулардын жообуна караганда "”, мисалы, бул толук мыйзамдуу жана Loki PromQL менен толук шайкеш келет.
Lokiди Prometheus түрү менен маалымат булагы катары кошуңуз жана URL /loki кошуңуз:
Прометейдин көрсөткүчтөрү менен иштеп жаткандай графиктерди түзө аласыз:
Функционалдык айырмачылык убактылуу жана аны иштеп чыгуучулар келечекте оңдойт деп ойлойм.
Метрикалар
Loki журналдардан сандык көрсөткүчтөрдү чыгарып, аларды Прометейге жөнөтүү мүмкүнчүлүгүн берет. Мисалы, nginx журналы жооп үчүн байттардын санын, ошондой эле стандарттык журнал форматынын белгилүү бир модификациясы менен жооп берүүгө кеткен секундадагы убакытты камтыйт. Бул маалыматтарды казып алып, Прометейге жөнөтсө болот.
promtail.yml үчүн дагы бир бөлүм кошуу:
- match:
selector: '{request_type="api"}'
stages:
- metrics:
http_nginx_response_time:
type: Histogram
description: "response time ms"
source: response_time
config:
buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
selector: '{request_type=~"static|photo"}'
stages:
- metrics:
http_nginx_response_bytes_sum:
type: Counter
description: "response bytes sum"
source: bytes_out
config:
action: add
http_nginx_response_bytes_count:
type: Counter
description: "response bytes count"
source: bytes_out
config:
action: incБул параметр алынган картадан алынган маалыматтардын негизинде метрикаларды аныктоого жана жаңыртууга мүмкүндүк берет. Бул көрсөткүчтөр Lokiге жөнөтүлбөйт - алар Promtail /metrics акыркы чекитинде көрүнөт. Prometheus бул этаптан маалыматтарды алуу үчүн конфигурацияланышы керек. Жогорудагы мисалда request_type="api" үчүн гистограмма метрикасын чогултабыз. Бул типтеги көрсөткүчтөр менен пайыздык көрсөткүчтөрдү алуу ыңгайлуу. Статика жана сүрөттөр үчүн биз орточо эсепти эсептөө үчүн байттардын суммасын жана байт алган саптардын санын чогултабыз.
Көрсөткүчтөр жөнүндө көбүрөөк окуңуз .
Promtail портун ачуу:
promtail:
image: grafana/promtail:1.4.1
container_name: monitoring.promtail
expose:
- 9080
ports:
- "9080:9080"promtail_custom префикси бар көрсөткүчтөр пайда болгонун текшеребиз:
Прометейди орнотуу. Жумуш сунушун кошуу:
- job_name: 'promtail'
scrape_interval: 10s
static_configs:
- targets: ['promtail:9080']Жана графикти тартыңыз:
Ушундай жол менен, мисалы, эң жай төрт суроону таба аласыз. Бул көрсөткүчтөр үчүн мониторингди конфигурациялай аласыз.
Масштабдоо
Loki бир экилик режимде да, майдаланган (горизонталдык масштабдалуучу режимде) болушу мүмкүн. Экинчи учурда, ал булуттагы маалыматтарды сактай алат, ал эми бөлүктөр жана индекстер өзүнчө сакталат. 1.5 версиясында бир жерде сактоо мүмкүнчүлүгү ишке ашырылган, бирок аны өндүрүштө колдонуу азырынча сунушталбайт.
Бөлүктөрдү S3 шайкеш сактагычында сактаса болот, индекстерди сактоо үчүн горизонталдуу масштабдалуучу маалымат базаларын колдонуңуз: Cassandra, BigTable же DynamoDB. Loki'нин башка бөлүктөрү - Дистрибьюторлор (жазуу үчүн) жана Querier (суроолор үчүн) - жарандыгы жок жана ошондой эле горизонталдуу масштабда.
DevOpsDays Vancouver 2019 конференциясында катышуучулардын бири Каллум Стян Локи менен анын долбоорунда жалпы көлөмүнүн 1% дан азыраак индекси бар петабайттар бар экенин жарыялады: "«.
Loki жана ELK салыштыруу
Индекс өлчөмү
Натыйжадагы индекстин өлчөмүн текшерүү үчүн мен nginx контейнеринен журналдарды алдым, ал үчүн жогорудагы Pipeline конфигурацияланган. Журнал файлында жалпы көлөмү 406 МБ болгон 624 109 сап камтылган. Журналдар бир сааттын ичинде түзүлдү, секундасына болжол менен 100 жазуу.
Журналдан эки саптын мисалы:
ELK тарабынан индекстелгенде, бул 30,3 МБ индекс өлчөмүн берди:
Локиде, бул болжол менен 128 КБ индексти жана 3,8 МБга жакын маалыматтарды бөлүктөргө берди. Белгилей кетсек, журнал жасалма жол менен түзүлгөн жана ар кандай маалыматтарды камтыган эмес. Түпнуска Docker JSON журналындагы жөнөкөй gzip маалыматтары менен 95,4% кысуу берди жана Loki'ге тазаланган nginx журналы гана жөнөтүлгөнүн эске алсак, 4 МБга кысуу түшүнүктүү. Loki энбелгилери үчүн уникалдуу маанилердин жалпы саны 35ти түздү, бул индекстин кичинекей өлчөмүн түшүндүрөт. ELK үчүн журнал да тазаланды. Ошентип, Локи баштапкы маалыматтарды 96%, ал эми ELK 70% кысылган.
Эстутум керектөө
Эгерде биз Prometheus жана ELK стектерин салыштырсак, анда Локи бир нече эсе аз "жейт". Go кызматы Java кызматына караганда азыраак керектелет жана Heap Elasticsearch JVM өлчөмүн жана Loki үчүн бөлүнгөн эстутумду салыштыруу туура эмес, бирок ошентсе да Loki эстутумду азыраак колдоноорун белгилей кетүү керек. Анын CPU артыкчылыгы ушунчалык ачык эмес, бирок ал дагы бар.
ылдамдык
Локи журналдарды тезирээк "жутат". Ылдамдык көптөгөн факторлордон көз каранды - кандай журналдар, биз аларды канчалык татаал талдайбыз, тармак, диск ж. Бул Локи индекске азыраак маалыматтарды киргизип, ошого жараша индекстөө үчүн аз убакыт коротушу менен түшүндүрүлөт. Бул учурда, кырдаал издөө ылдамдыгы менен тескери болот: Loki бир нече гигабайттан чоңураак маалыматтарды басаңдатат, ал эми ELK үчүн издөө ылдамдыгы маалыматтардын өлчөмүнөн көз каранды эмес.
Журнал издөө
Локи журналдарды издөө мүмкүнчүлүктөрү боюнча ELKтен кыйла төмөн. Регулярдуу сөз айкаштары менен Grep күчтүү нерсе, бирок ал чоңдордун маалымат базасынан төмөн. Диапазондун суроо-талаптарынын жоктугу, энбелгилер боюнча гана топтоо, энбелгисиз издөө мүмкүн эместиги - мунун бардыгы бизди Lokiде кызыктырган маалыматты издөөнү чектейт. Бул Loki аркылуу эч нерсе табууга болбойт дегенди билдирбейт, бирок Prometheus диаграммаларында көйгөйдү биринчи жолу таап, андан кийин бул энбелгилерди колдонуп журналдардан эмне болгонун издегенде, журналдар менен иштөө агымын аныктайт.
колдонмо
Биринчиден, бул сулуу (кечиресиз, туруштук бере алган жокмун). Grafana жакшы көрүнгөн интерфейси бар, бирок Kibana алда канча функционалдык.
Loki жакшы жана жаман жактары
Плюстун ичинен Локи Prometheus менен интеграцияланганын белгилей кетүү керек, биз көрсөткүчтөрдү жана эскертүүлөрдү кутудан алабыз. Бул журналдарды чогултуу жана аларды Kubernetes Pods менен сактоо үчүн ыңгайлуу, анткени анда Prometheus'тан мураска калган кызмат ачылышы бар жана автоматтык түрдө энбелгилерди чаптайт.
Минустары - начар документтер. Промтайлдын өзгөчөлүктөрү жана мүмкүнчүлүктөрү сыяктуу кээ бир нерселерди мен кодду изилдөө процессинде гана ачтым, ачык булактын пайдасы. Дагы бир жетишпеген жагы - алсыз талдоо мүмкүнчүлүктөрү. Мисалы, Loki көп сап журналдарын талдай албайт. Ошондой эле, кемчиликтер Loki салыштырмалуу жаш технология экенин камтыйт (релиз 1.0 2019-жылы ноябрда болгон).
жыйынтыктоо
Loki – бул 100% кызыктуу технология, ал чакан жана орто долбоорлорго ылайыктуу, журналдарды бириктирүү, журналдарды издөө, журналдарды көзөмөлдөө жана талдоо боюнча көптөгөн маселелерди чечүүгө мүмкүндүк берет.
Биз Loki'ди Badoo'до колдонбойбуз, анткени бизде бизге ылайыктуу ELK стек бар жана ал көптөгөн жылдар бою ар кандай ыңгайлаштырылган чечимдер менен толуп калган. Биз үчүн мүдүрүлүүчү блок журналдардан издөө болуп саналат. Күнүнө дээрлик 100 ГБ журналдар менен, биз үчүн бардыгын жана бир аз көбүрөөк таап, аны тез арада жасоо маанилүү. Диаграммаларды түзүү жана мониторинг жүргүзүү үчүн биз муктаждыктарыбызга ылайыкталган жана бири-бири менен интеграцияланган башка чечимдерди колдонобуз. Локи стекинин сезилерлик пайдасы бар, бирок ал бизге бизде бар нерседен көптү бербейт жана анын пайдасы миграциялык чыгымдардан такыр ашпайт.
Изилдөөдөн кийин биз Loki колдоно албасыбыз айкын болгонуна карабастан, бул пост сизге тандоодо жардам берет деп үмүттөнөбүз.
Макалада колдонулган код менен репозиторий жайгашкан .
Source: www.habr.com