artikkelen om Badushechka<\/a><\/noindex>, som skrev om dette. Men der er et punkt. Rundt om denne opkald var der ogs\u00e5 en uendelig l\u00f8kke, hvor der konstant blev fors\u00f8gt at putte en besked i socketen. Det var det, vi ikke tog m\u00e6rke til. Vi m\u00e5tte omskrive biblioteket. Siden da har det \u00e6ndret sig flere gange, men nu har vi elimineret l\u00e5sninger i alle undersystemer. Derfor kan vi stoppe rsyslog, og intet vil falde.<\/p>\n<\/p>\n
Vi skal overv\u00e5ge st\u00f8rrelsen p\u00e5 k\u00f8erne, hvilket hj\u00e6lper med at undg\u00e5 disse faldgruber. For det f\u00f8rste kan vi overv\u00e5ge, hvorn\u00e5r vi begynder at miste beskeder. For det andet kan vi overv\u00e5ge, at vi overhovedet har problemer med levering.<\/p>\n
<\/p>\n
Og endnu en uheldig ting \u2014 amplification i 10 gange i mikrotjenesterarkitekturen \u2014 det er meget nemt. Vi har ikke s\u00e5 mange indg\u00e5ende anmodninger, men p\u00e5 grund af grafen, som disse beskeder l\u00f8ber videre p\u00e5, p\u00e5 grund af adgangsloggene, \u00f8ger vi virkelig belastningen p\u00e5 loggene med cirka ti gange. Jeg har desv\u00e6rre ikke f\u00e5et tid til at beregne de pr\u00e6cise tal, men mikrotjenester \u2014 de er s\u00e5dan. Det skal man have i mente. Det viser sig, at i \u00f8jeblikket er logindsamlingssystemet det mest belastede i Lazada. <\/p>\n
<\/p>\n
<\/p>\n
Hvordan l\u00f8ser man problemet med elasticsearch? Hvis du hurtigt har brug for at f\u00e5 loggene et sted, s\u00e5 du ikke skal l\u00f8be rundt p\u00e5 alle maskinerne og samle dem, s\u00e5 brug et filstorage. Det fungerer garanteret. Det laves fra enhver server. Du skal bare stikke nogle diske derhen og s\u00e6tte syslog op. Derefter har du garanteret alle loggene et sted. Derefter kan du stille og roligt begynde at konfigurere elasticsearch, graylog, eller noget andet. Men du har allerede alle loggene, og du kan opbevare dem, s\u00e5 l\u00e6nge diskomr\u00e5derne r\u00e6kker.<\/p>\n
<\/p>\n
<\/p>\n
P\u00e5 tidspunktet for mit foredrag s\u00e5 skemaet s\u00e5dan ud. Vi er stort set blevet stoppet med at skrive til filer. Nu slukker vi sandsynligvis for resten. P\u00e5 de lokale maskiner, hvor API'erne k\u00f8rer, stopper vi med at skrive til filer. For det f\u00f8rste er der et filstorage, som fungerer rigtig godt. For det andet l\u00f8ber der konstant pladsmangel p\u00e5 disse maskiner, og det skal overv\u00e5ges kontinuerligt.<\/p>\n
<\/p>\n
Denne del med Logstash og Graylog, den er virkelig frustrerende. Derfor skal vi slippe af med den. Vi skal v\u00e6lge et enkelt system.<\/p>\n
<\/p>\n
<\/p>\n
Vi har besluttet at skrotte Logstash og Kibana. Fordi vi har et sikkerhedsafdeling. Hvad er forbindelsen? Forbindelsen er, at Kibana uden X-Pack og uden Shield ikke giver mulighed for at adskille adgangen til logfilerne. Derfor valgte vi Graylog. Det er ikke mit favoritv\u00e6rkt\u00f8j, men det fungerer. Vi k\u00f8bte nyt hardware, installerede den nyeste Graylog p\u00e5 det og flyttede alle logs med strenge formater til en s\u00e6rskilt Graylog. Vi har l\u00f8st problemet med forskellige typer af identiske felter organisatorisk.<\/p>\n
<\/p>\n
<\/p>\n
Hvad der faktisk er inkluderet i den nye Graylog. Vi har blot skrevet alt ned i Docker. Vi tog en masse servere, satte tre instanser af Kafka op og syv Graylog-servere version 2.3 (fordi vi \u00f8nskede Elasticsearch version 5). Alt dette blev k\u00f8rt p\u00e5 RAID med HDD. Vi s\u00e5 en indekseringshastighed p\u00e5 op til 100.000 beskeder i sekundet. Vi s\u00e5 tallet 140 terabyte data om ugen. <\/p>\n
<\/p>\n
<\/p>\n
Og igen bump! Vi st\u00e5r over for to udsalg. Vi er flyttet over 6 millioner beskeder. Vores Graylog kan ikke f\u00f8lge med. Vi m\u00e5 finde en m\u00e5de at overleve igen. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5dan overlevede vi. Vi tilf\u00f8jede et par ekstra servere og SSD'er. P\u00e5 nuv\u00e6rende tidspunkt lever vi p\u00e5 denne m\u00e5de. Nu behandler vi allerede 160.000 beskeder i sekundet. Vi er endnu ikke n\u00e5et op til gr\u00e6nsen, s\u00e5 det er ikke klart, hvor meget vi reelt kan tr\u00e6kke ud af dette. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5dan ser vores fremtidsplaner ud. Af dem er det sandsynligvis det vigtigste h\u00f8j tilg\u00e6ngelighed. Vi har det ikke endnu. Flere maskiner er konfigureret ens, men alt g\u00e5r stadig gennem \u00e9n maskine. Vi skal bruge tid p\u00e5 at konfigurere failover mellem dem.<\/p>\n
<\/p>\n
Indsamle metrikker fra Graylog.<\/p>\n
<\/p>\n
Implementere rate limiting, s\u00e5 vores \u00e9n, der er blevet sindssyg API, ikke dr\u00e6ber vores b\u00e5ndbredde og alt andet.<\/p>\n
<\/p>\n
Og endelig skrive en SLA med udviklerne om, at vi kan h\u00e5ndtere s\u00e5 meget. Hvis I skriver mere, s\u00e5 beklager vi.<\/p>\n
<\/p>\n
Og skrive dokumentation.<\/p>\n
<\/p>\n
<\/p>\n
Kort opsummering af alt, hvad vi har gennemg\u00e5et. For det f\u00f8rste standarder. For det andet, syslog \u2014 kagen. For det tredje fungerer rsyslog pr\u00e6cis s\u00e5dan, som det st\u00e5r p\u00e5 sliden. Lad os g\u00e5 videre til sp\u00f8rgsm\u00e5l.<\/p>\n
<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>.<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: Hvorfor besluttede I s\u00e5 ikke at bruge\u2026 (filebeat?)<\/p>\n<\/p>\n
Svar<\/strong>: Man skal skrive til fil. Det var vi meget skeptiske overfor. N\u00e5r din API skriver tusindvis af beskeder i sekundet, er det stadig ikke en l\u00f8sning, selv hvis du roterer en gang i timen. Man kan skrive til en pipe. Til det spurgte udviklerne: \"Hvad sker der, hvis processen, som vi skriver til, crasher?\" Jeg fandt faktisk ikke et svar til dem og sagde: \"N\u00e5, okay, lad os lade v\u00e6re med at g\u00f8re det.\"<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: Hvorfor skriver du ikke logs direkte til HDFS?<\/p>\n<\/p>\n
Svar<\/strong>: Det er det n\u00e6ste skridt. Vi t\u00e6nkte p\u00e5 det i starten, men da vi ikke har ressourcer til at arbejde p\u00e5 det i \u00f8jeblikket, h\u00e6nger det som en langsigtet l\u00f8sning.<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: Kolonneformatet ville v\u00e6re mere passende.<\/p>\n<\/p>\n
Svar<\/strong>: Jeg forst\u00e5r det hele. Vi er \"for\" det med begge h\u00e6nder. <\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: Du skriver til rsyslog. Der kan man bruge b\u00e5de TCP og UDP. Men hvis man bruger UDP, hvordan garanterer du s\u00e5 leveringen?<\/p>\n<\/p>\n
Svar<\/strong>: Der er to aspekter. For det f\u00f8rste informerer jeg straks alle om, at vi ikke garanterer leveringen af logs. Fordi n\u00e5r udviklerne kommer og siger: 'Lad os begynde at skrive finansielle data der, og s\u00e5 kan I gemme dem til senere, hvis noget g\u00e5r galt', svarer vi 'Fantastisk! Lad os sige, at I begynder at blokere for skrivningen til socket og laver det i transaktioner, s\u00e5 I garanterer, at I sender det til os, og at I er sikre p\u00e5, at vi har modtaget det fra den anden side.' Og i det \u00f8jeblik bliver alle straks tilbageholdende. Og da de ikke \u00f8nsker det, hvad sp\u00f8rgsm\u00e5l har vi s\u00e5? Hvis I ikke \u00f8nsker at garantere skrivning til socket, hvorfor skal vi s\u00e5 garantere leveringen? Vi g\u00f8r vores bedste. Vi fors\u00f8ger virkelig at levere s\u00e5 meget som muligt og s\u00e5 godt som muligt, men vi giver ikke 100% garanti. Derfor skal der ikke skrives finansielle data der. Der er databaser med transaktioner til det.<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: N\u00e5r API'en genererer en logbesked og videregiver kontrollen til mikrotjenesterne, har I s\u00e5 ikke oplevet problemer med, at beskeder fra forskellige mikrotjenester ankommer i forkert r\u00e6kkef\u00f8lge? Det kan skabe forvirring.<\/p>\n<\/p>\n
Svar<\/strong>: Det er normalt, at de ankommer i forskellig r\u00e6kkef\u00f8lge. Man skal v\u00e6re forberedt p\u00e5 det. For enhver netv\u00e6rkslevering garanterer ikke r\u00e6kkef\u00f8lgen, eller man skal bruge specielle ressourcer til det. Hvis vi tager filsystemer, gemmer hver API logs i sin egen fil. Eller rettere sagt, rsyslog opdeler dem i mapper. Hver API har sine egne logs, som du kan g\u00e5 ind og se, og derefter kan du matche dem ved hj\u00e6lp af timestamp i loggen. Hvis de g\u00e5r ind og ser i Graylog, s\u00e5 bliver de sorteret efter timestamp. Der vil alt v\u00e6re i orden.<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: Timestamp kan variere med millisekunder.<\/p>\n<\/p>\n
Svar<\/strong>: Timestamp genereres af selve API'en. Det er i grunden hele pointen. Vi har NTP. API'en genererer timestamp allerede i selve beskeden. Det tilf\u00f8jes ikke af rsyslog.<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: Det er ikke helt klart, hvordan interaktionen mellem datacenterne fungerer. Inden for datacentret er det klart, hvordan loggene blev indsamlet og behandlet. Hvordan foreg\u00e5r interaktionen mellem datacenterne? Eller lever hvert datacenter sit eget liv?<\/p>\n<\/p>\n
Svar<\/strong>: N\u00e6sten. Hvert land er placeret i et bestemt datacenter. Vi har i \u00f8jeblikket ikke spredning, hvor et land er placeret i flere datacentre. Derfor beh\u00f8ver vi ikke at samle dem. Inden for hvert center er der en Log Relay. Det er en Rsyslog-server. Faktisk er der to administrationsmaskiner. De er indstillet ens. Men indtil videre g\u00e5r trafikken kun gennem den ene. Den aggregerer alle loggene. Den har en diskqueue i tilf\u00e6lde af noget. Den komprimerer logs og sender dem til det centrale datacenter (i Singapore), hvor de derefter sendes til Graylog. Og hvert datacenter har sin egen filopbevaring. I tilf\u00e6lde af, at vi mister forbindelsen, har vi alle loggene der. De vil forblive der. De vil blive gemt.<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: F\u00e5r I logs derfra i n\u00f8dsituationer?<\/p>\n<\/p>\n
Svar<\/strong>: Man kan g\u00e5 derhen (til filopbevaringen) og se.<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: Hvordan overv\u00e5ger I, at I ikke mister logs?<\/p>\n<\/p>\n
Svar<\/strong>: Vi mister dem faktisk, og vi overv\u00e5ger det. Overv\u00e5gningen blev startet for en m\u00e5ned siden. I biblioteket, der bruges af Go API, er der m\u00e5linger. Den kan t\u00e6lle, hvor mange gange den ikke kunne skrive til socket. Der er i \u00f8jeblikket en smart heuristik. Der er en buffer. Den fors\u00f8ger at skrive beskeder fra den til socket. Hvis bufferen fyldes op, begynder den at droppe dem. Og t\u00e6ller hvor mange den har droppet. Hvis t\u00e6llerne begynder at fylde op, f\u00e5r vi besked om det. De g\u00e5r ogs\u00e5 til Prometheus, og i Grafana kan man se grafer. Man kan indstille advarsler. Men det er stadig uklart, hvem de skal sendes til.<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: I Elasticsearch opbevarer I logs med backup. Hvor mange replikaer har I?<\/p>\n<\/p>\n
Svar<\/strong>: \u00c9n replika.<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: Er det kun \u00e9n replika?<\/p>\n<\/p>\n
Svar<\/strong>: Det er master og replika. Dataene opbevares i to eksemplarer.<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: Har I justeret st\u00f8rrelsen p\u00e5 rsyslog-bufferen p\u00e5 nogen m\u00e5de? <\/p>\n<\/p>\n
Svar<\/strong>: Vi skriver datagrammer til en tilpasset unix socket. Dette p\u00e5l\u00e6gger os straks en begr\u00e6nsning p\u00e5 128 kilobyte. Vi kan ikke skrive mere til det. Vi har angivet dette i standarden. De, der \u00f8nsker at komme ind i lagrene, skriver 128 kilobyte. Bibliotekerne sk\u00e6rer faktisk ned og s\u00e6tter et flag, der signalerer, at meddelelsen er blevet forkortet. I vores standard for selve meddelelsen er der et s\u00e6rligt felt, der viser, om det blev forkortet ved skrivning eller ej. S\u00e5 vi har mulighed for at spore dette aspekt.<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: Skriver du korrupt JSON? <\/p>\n<\/p>\n
Svar<\/strong>: Korrupt JSON vil blive afvist enten under relay, fordi pakken er for stor. Eller det vil blive afvist af Graylog, fordi det ikke kan parse JSON. Men her er der nuancer, som skal rettes, og de er for det meste knyttet til rsyslog. Jeg har allerede indsendt et par issues der, som der stadig skal arbejdes p\u00e5.<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: Hvorfor Kafka? Har du pr\u00f8vet RabbitMQ? Kan Graylog ikke klare s\u00e5danne belastninger?<\/p>\n<\/p>\n
Svar<\/strong>: Vi kan ikke f\u00e5 det til at fungere med Graylog. Men Graylog fungerer for os. Det er en besv\u00e6rlig st\u00f8rrelse. Og faktisk er det ikke n\u00f8dvendigt. Jeg ville foretr\u00e6kke at skrive direkte fra rsyslog til Elasticsearch og derefter se i Kibana. Men vi skal afklare sp\u00f8rgsm\u00e5lene med sikkerhedsfolkene. Dette er en mulig udviklingsvej for os, n\u00e5r vi fjerner Graylog og bruger Kibana. Det vil ikke give mening at bruge Logstash. Fordi jeg kan g\u00f8re alt dette med rsyslog. Og det har en modul til at skrive til Elasticsearch. Vi fors\u00f8ger at leve med Graylog. Vi har endda tweaket det lidt. Men der er stadig plads til forbedringer.<\/p>\n<\/p>\n
Om Kafka. Det er, som historien har udviklet sig. Da jeg kom, var det allerede der, og logfiler blev allerede skrevet til det. Vi rejste bare vores klynge op og flyttede loggene til den. Vi styrer det, vi ved, hvordan det har det. Om RabbitMQ... vi f\u00e5r det ikke til at fungere med RabbitMQ. Men vi f\u00e5r det til at fungere med RabbitMQ. Det er i produktionen, og der har v\u00e6ret problemer med det. Lige nu, f\u00f8r udsalget, fik vi det til at fungere, og det begyndte at fungere normalt. Men f\u00f8r det var jeg ikke parat til at udgive det i produktion. Der er ogs\u00e5 et andet punkt. Graylog kan l\u00e6se AMQP 0.9-versionen, mens rsyslog kan skrive AMQP 1.0-versionen. Der er ikke nogen l\u00f8sning, der kan g\u00f8re begge dele. Det er enten det ene eller det andet. Derfor er der kun Kafka lige nu. Men der er ogs\u00e5 sine nuancer der. Fordi omkafka af den version af rsyslog, vi bruger, kan miste hele bufferet af beskeder, som den har hentet fra rsyslog. Indtil videre m\u00e5 vi leve med det. <\/p>\n
<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: Bruger du Kafka, fordi det allerede var der? Til ingen andre form\u00e5l?<\/p>\n<\/p>\n
Svar<\/strong>: Den Kafka, der var, bruges af Data Science-teamet. Det er et helt separat projekt, som jeg desv\u00e6rre ikke kan sige noget om. Jeg er ikke opdateret. Det var under ledelse af Data Science-teamet. Da loggene blev oprettet, besluttede de at bruge det, s\u00e5 de ikke skulle installere deres egen. Nu har vi opdateret Graylog, og vi har mistet kompatibiliteten, fordi der var en gammel version af Kafka. Vi var n\u00f8dt til at oprette vores egen. Samtidig blev vi fri for de fire emner for hver API. Vi lavede et bredt emne til alt live, et bredt emne til alt staging, og s\u00e5 sender vi bare alt derind. Graylog henter alt dette parallelt.<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: Hvad er det der behov for det her magi med sockets? Har I pr\u00f8vet at bruge log-driver syslog til containerne.<\/p>\n<\/p>\n
Svar<\/strong>: P\u00e5 det tidspunkt, hvor vi stillede os selv dette sp\u00f8rgsm\u00e5l, var vores forhold til Docker sp\u00e6ndt. Det var Docker 1.0 eller 0.9. Docker i sig selv var m\u00e6rkelig. For det andet, hvis man ogs\u00e5 skal stoppe logs i det\u2026 Jeg har en ubevist mistanke om, at den lader alle logs passere igennem sig, gennem Docker-d\u00e6monen. Hvis vores API bliver sk\u00f8rt, s\u00e5 stopper de andre API\u2019er op, fordi de ikke kan sende stdout og stderr. Jeg ved ikke, hvad det vil f\u00f8re til. Jeg har en fornemmelse af, at man ikke burde bruge Docker's syslog-driver her. Vores afdeling for funktionel test har sin egen lille Graylog-klynge med logs. De bruger Docker-logdrivere, og det ser ud til at fungere fint. Men de skriver direkte GELF til Graylog. P\u00e5 det tidspunkt, da vi startede det hele, havde vi bare brug for, at det fungerede. M\u00e5ske senere, n\u00e5r nogen siger, at det har fungeret fint i lang tid, vil vi pr\u00f8ve det.<\/p>\n<\/p>\n
Sp\u00f8rgsm\u00e5l<\/strong>: I g\u00f8r leveringen mellem datacentrer med rsyslog. Hvorfor ikke med Kafka?<\/p>\n<\/p>\n
Svar<\/strong>: Vi g\u00f8r faktisk begge dele. Af to grunde. Hvis kanalen er helt nede, s\u00e5 kan vores logs, selv i komprimeret format, ikke komme igennem. Og Kafka tillader os simpelthen at miste dem undervejs. P\u00e5 den m\u00e5de slipper vi for, at logs sidder fast. I dette tilf\u00e6lde bruger vi Kafka direkte. Hvis vores kanal er god, og vi \u00f8nsker at frig\u00f8re den, s\u00e5 bruger vi rsyslog. Men man kan faktisk indstille rsyslog til at droppe det, der ikke kan komme igennem. I \u00f8jeblikket bruger vi s\u00e5 nogle steder rsyslog direkte, og andre steder Kafka.<\/p>\nKilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041b\u043e\u0433\u0438 \u2014 \u0432\u0430\u0436\u043d\u0430\u044f \u0447\u0430\u0441\u0442\u044c \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0430\u044f \u043f\u043e\u043d\u044f\u0442\u044c, \u0447\u0442\u043e \u043e\u043d\u0430 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 (\u043b\u0438\u0431\u043e \u043d\u0435 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442), \u043a\u0430\u043a \u043e\u0436\u0438\u0434\u0430\u0435\u0442\u0441\u044f. \u0412 \u0443\u0441\u043b\u043e\u0432\u0438\u044f\u0445 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u0440\u0430\u0431\u043e\u0442\u0430 \u0441 \u043b\u043e\u0433\u0430\u043c\u0438 \u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u0441\u044f \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u043e\u0439 \u0434\u0438\u0441\u0446\u0438\u043f\u043b\u0438\u043d\u043e\u0439 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u043e\u043b\u0438\u043c\u043f\u0438\u0430\u0434\u044b. \u041d\u0443\u0436\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c \u0441\u0440\u0430\u0437\u0443 \u043a\u0443\u0447\u0443 \u0432\u043e\u043f\u0440\u043e\u0441\u043e\u0432: \u043a\u0430\u043a \u043f\u0438\u0441\u0430\u0442\u044c \u043b\u043e\u0433\u0438 \u0438\u0437 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f; \u043a\u0443\u0434\u0430 \u043f\u0438\u0441\u0430\u0442\u044c \u043b\u043e\u0433\u0438; \u043a\u0430\u043a \u0434\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0442\u044c \u043b\u043e\u0433\u0438 \u0434\u043b\u044f \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438; \u043a\u0430\u043a \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c \u0438 \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u043b\u043e\u0433\u0438. \u041f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0435 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0445 \u043d\u044b\u043d\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24507,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32723","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Afspil](\"https:\/\/img.youtube.com\/vi\/NAeedJv-S3I\/hqdefault.jpg\")
\r\n