den Artikel \u00fcber Badushka<\/a><\/noindex>, die dar\u00fcber geschrieben hat. Es gibt jedoch einen Punkt. Rund um diesen Aufruf gab es eine endlose Schleife, in der st\u00e4ndig versucht wurde, eine Nachricht in den Socket zu stecken. Das haben wir \u00fcbersehen. Die Bibliothek musste neu geschrieben werden. Seitdem hat sie sich mehrmals ge\u00e4ndert, aber jetzt haben wir alle Blockierungen in den Untereinheiten beseitigt. Daher k\u00f6nnen wir rsyslog stoppen, ohne dass etwas ausf\u00e4llt.<\/p>\n<\/p>\n
Wir m\u00fcssen die Gr\u00f6\u00dfe der Warteschlangen \u00fcberwachen, um nicht auf dieselben Probleme zu sto\u00dfen. Erstens k\u00f6nnen wir \u00fcberwachen, wann wir anfangen, Nachrichten zu verlieren. Zweitens k\u00f6nnen wir erkennen, dass wir grunds\u00e4tzlich Probleme mit der Zustellung haben.<\/p>\n
<\/p>\n
Und noch ein unangenehmer Punkt \u2013 die Amplikation um das Zehnfache in einer Microservices-Architektur ist sehr einfach. Wir haben nicht so viele eingehende Anfragen, aber aufgrund des Graphen, in dem diese Nachrichten laufen, und der Access-Logs erh\u00f6hen wir tats\u00e4chlich die Last der Logs ungef\u00e4hr um das Zehnfache. Leider hatte ich nicht die Zeit, die genauen Zahlen zu berechnen, aber Microservices sind eben so. Das sollte man im Hinterkopf behalten. Im Moment ist das Logsammelsystem die am st\u00e4rksten belastete Komponente bei Lazada. <\/p>\n
<\/p>\n
<\/p>\n
Wie l\u00f6st man das Problem mit Elasticsearch? Wenn Sie schnell alle Protokolle an einem Ort abrufen m\u00f6chten, um nicht auf allen Maschinen suchen zu m\u00fcssen, verwenden Sie ein Dateispeicher. Das funktioniert garantiert. Es kann auf jedem Server eingerichtet werden. Man muss nur ein paar Festplatten anschlie\u00dfen und syslog installieren. Danach sind alle Protokolle garantiert an einem Ort vorhanden. Dann k\u00f6nnen Sie in Ruhe Elasticsearch, Graylog oder etwas anderes konfigurieren. Aber Sie haben bereits alle Protokolle und k\u00f6nnen sie so lange speichern, wie der Speicherplatz reicht.<\/p>\n
<\/p>\n
<\/p>\n
Zum Zeitpunkt meines Vortrags sah das Schema so aus. Wir haben nahezu aufgeh\u00f6rt, in die Datei zu schreiben. H\u00f6chstwahrscheinlich schalten wir die Reste jetzt ab. Auf den lokalen Maschinen, auf denen die API l\u00e4uft, werden wir auch nicht mehr in Dateien schreiben. Erstens gibt es ein Dateispeicher, das sehr gut funktioniert. Zweitens ist der Platz auf diesen Maschinen st\u00e4ndig knapp, und man muss ihn fortlaufend \u00fcberwachen.<\/p>\n
<\/p>\n
Dieser Teil mit Logstash und Graylog ist wirklich problematisch. Deshalb m\u00fcssen wir uns davon trennen. Wir m\u00fcssen uns f\u00fcr etwas entscheiden.<\/p>\n
<\/p>\n
<\/p>\n
Wir haben uns entschieden, Logstash und Kibana abzulehnen. Der Grund ist, dass wir eine Sicherheitsabteilung haben. Was hat das miteinander zu tun? Nun, Kibana erlaubt ohne X-Pack und ohne Shield keine differenzierten Zugriffsrechte auf die Logs. Daher haben wir Graylog verwendet. Es ist nicht mein Favorit, aber es funktioniert. Wir haben neue Hardware gekauft, haben frisches Graylog installiert und alle Logs mit strikten Formaten in eine separate Graylog-Instanz verschoben. Dadurch haben wir das Problem mit den verschiedenen Typen identischer Felder organisatorisch gel\u00f6st.<\/p>\n
<\/p>\n
<\/p>\n
Was genau ist in das neue Graylog integriert? Wir haben einfach alles in Docker aufgenommen. Wir haben einige Server genommen, drei Instanzen von Kafka ausgerollt und 7 Server mit Graylog in Version 2.3 (weil wir Elasticsearch in Version 5 wollten) aufgebaut. Das Ganze haben wir auf RAID-Systemen mit HDDs laufen lassen. Wir haben eine Indexierungsrate von bis zu 100.000 Nachrichten pro Sekunde erreicht und gesehen, dass wir 140 Terabyte Daten pro Woche verarbeiten. <\/p>\n
<\/p>\n
<\/p>\n
Und wieder die gleichen Probleme! Uns stehen zwei Verkaufsaktionen bevor. Wir haben \u00fcber 6 Millionen Nachrichten umgezogen. Graylog schafft es nicht, damit hinterherzukommen. Wir m\u00fcssen uns irgendwie wieder durchschlagen. <\/p>\n
<\/p>\n
<\/p>\n
So haben wir \u00fcberlebt. Wir haben noch ein paar Server und SSDs hinzugef\u00fcgt. Momentan leben wir auf diese Weise. Jetzt verarbeiten wir bereits 160.000 Nachrichten pro Sekunde. Wir haben noch nicht die Grenze erreicht, daher ist es bisher unklar, wie viel wir tats\u00e4chlich aus diesem System herausholen k\u00f6nnen. <\/p>\n
<\/p>\n
<\/p>\n
Das sind unsere Pl\u00e4ne f\u00fcr die Zukunft. Davon ist wahrscheinlich High Availability am wichtigsten. Das haben wir momentan noch nicht. Einige Maschinen sind gleich konfiguriert, aber der gesamte Traffic l\u00e4uft bisher \u00fcber eine Maschine. Wir m\u00fcssen Zeit investieren, um das Failover zwischen ihnen einzurichten.<\/p>\n
<\/p>\n
Metriken mit Graylog sammeln.<\/p>\n
<\/p>\n
Ein Rate Limit einrichten, damit uns eine \u00fcberlastete API nicht den Bandbreite und alles andere kaputt macht.<\/p>\n
<\/p>\n
Und schlie\u00dflich einen SLA mit den Entwicklern vereinbaren, dass wir bis zu einem bestimmten Umfang betreuen k\u00f6nnen. Wenn ihr mehr schreibt, tut mir leid.<\/p>\n
<\/p>\n
Und die Dokumentation schreiben.<\/p>\n
<\/p>\n
<\/p>\n
Kurz zusammengefasst, die Ergebnisse von allem, was wir durchgemacht haben. Erstens, Standards. Zweitens, Syslog \u2013 ein Kuchen. Drittens, Rsyslog funktioniert genau so, wie es auf der Folie steht. Und lasst uns zu den Fragen \u00fcbergehen.<\/p>\n
<\/p>\n
Fragen<\/strong>.<\/p>\n<\/p>\n
Frage<\/strong>: Warum haben Sie sich entschlossen, nichts zu nehmen\u2026 (Filebeat?)<\/p>\n<\/p>\n
Antwort<\/strong>: Wir m\u00fcssen in eine Datei schreiben. Das wollte ich wirklich nicht. Wenn dein API Tausende von Nachrichten pro Sekunde schreibt, ist es einfach nicht praktikabel, sogar einmal pro Stunde zu rotieren. Man k\u00f6nnte in eine Pipe schreiben. Daraufhin fragten die Entwickler: \u201eWas passiert, wenn der Prozess, in den wir schreiben, abst\u00fcrzt?\u201c Ich konnte nichts darauf antworten und sagte: \u201eNa gut, dann machen wir das nicht.\u201c<\/p>\n<\/p>\n
Frage<\/strong>: Warum schreiben Sie die Logs nicht einfach in HDFS?<\/p>\n<\/p>\n
Antwort<\/strong>: Das ist der n\u00e4chste Schritt. Wir haben am Anfang dar\u00fcber nachgedacht, aber da wir momentan keine Ressourcen daf\u00fcr haben, bleibt es eine langfristige L\u00f6sung.<\/p>\n<\/p>\n
Frage<\/strong>: Ein Spaltenformat w\u00e4re passender.<\/p>\n<\/p>\n
Antwort<\/strong>: Ich verstehe. Wir sind \u201edaf\u00fcr\u201c mit beiden H\u00e4nden. <\/p>\n<\/p>\n
Frage<\/strong>: Sie schreiben in rsyslog. Dort kann man sowohl TCP als auch UDP verwenden. Aber wenn Sie UDP verwenden, wie gew\u00e4hrleisten Sie dann die Zustellung?<\/p>\n<\/p>\n
Antwort<\/strong>: Es gibt zwei Punkte. Erstens sage ich sofort allen, dass wir die Lieferung von Logs nicht garantieren. Denn wenn Entwickler kommen und sagen: \u201eLass uns da Finanzdaten reinschreiben, und ihr legt die irgendwo ab, f\u00fcr den Fall, dass etwas passiert\u201c, antworten wir: \u201eSuper! Fangt an, euch beim Schreiben in den Socket zu blockieren und macht das in Transaktionen, damit ihr uns das garantiert in den Socket schreibt und sicherstellt, dass wir es auf der anderen Seite erhalten haben.\u201c In diesem Moment ist es allen sofort nicht mehr wichtig. Wenn es nicht wichtig ist, welche Fragen haben wir dann? Wenn ihr keine Garantie f\u00fcr das Schreiben in den Socket geben wollt, warum sollten wir dann die Lieferung garantieren? Wir geben unser Bestes. Wir bem\u00fchen uns wirklich, so viel wie m\u00f6glich und so gut wie m\u00f6glich zu liefern, aber wir geben keine 100% Garantie. Daher sollte man keine Finanzdaten dort schreiben. Daf\u00fcr sind Datenbanken mit Transaktionen da.<\/p>\n<\/p>\n
Frage<\/strong>: Wenn die API eine Nachricht im Log generiert und die Kontrolle an Microservices \u00fcbergibt, habt ihr dann nicht das Problem, dass Nachrichten von verschiedenen Microservices in der falschen Reihenfolge ankommen? Dadurch entsteht Verwirrung.<\/p>\n<\/p>\n
Antwort<\/strong>: Es ist normal, dass sie in unterschiedlicher Reihenfolge ankommen. Darauf sollte man vorbereitet sein. Denn bei jeder Netzwerk-Zustellung ist die Reihenfolge nicht garantiert, oder man muss speziell Ressourcen daf\u00fcr aufwenden. Wenn wir uns Dateispeicher betrachten, speichert jede API ihre Logs in ihren eigenen Dateien. Genauer gesagt, rsyslog ordnet diese in Verzeichnissen an. Jede API hat ihre eigenen Logs, in die man gehen und nachsehen kann, und dann k\u00f6nnen sie anhand des Zeitstempels in diesen Logs abgeglichen werden. Wenn sie in Graylog schauen, werden sie dort nach Zeitstempel sortiert. Dort ist alles in Ordnung.<\/p>\n<\/p>\n
Frage<\/strong>: Der Zeitstempel kann sich um Millisekunden unterscheiden.<\/p>\n<\/p>\n
Antwort<\/strong>: Der Zeitstempel wird von der API selbst generiert. Darin liegt eigentlich der ganze Trick. Wir haben NTP. Die API generiert den Zeitstempel bereits in der Nachricht selbst. Dieser wird nicht von rsyslog hinzugef\u00fcgt.<\/p>\n<\/p>\n
Frage<\/strong>: Die Interaktion zwischen den Rechenzentren ist nicht ganz klar. Innerhalb eines Rechenzentrums ist es klar, wie die Logs gesammelt und verarbeitet werden. Wie erfolgt die Interaktion zwischen den Rechenzentren? Oder lebt jedes Rechenzentrum sein eigenes Leben?<\/p>\n<\/p>\n
Antwort<\/strong>: Fast. In jedem Land befindet sich unsere Infrastruktur in einem bestimmten Rechenzentrum. Derzeit gibt es keine Verteilung, sodass ein Land in mehreren Rechenzentren gehostet wird. Daher ist eine Zusammenf\u00fchrung nicht notwendig. Innerhalb jedes Rechenzentrums gibt es einen Log Relay. Dies ist ein Rsyslog-Server. Tats\u00e4chlich betreiben wir zwei Management-Server, die identisch eingerichtet sind. Aktuell l\u00e4uft der gesamte Verkehr \u00fcber einen von ihnen, der alle Protokolle aggregiert. Dieser Server hat eine Festplattenwarteschlange f\u00fcr den Notfall. Er komprimiert die Logs und sendet sie an unser zentrales Rechenzentrum in Singapur, wo sie dann an Graylog weitergeleitet werden. Au\u00dferdem gibt es in jedem Rechenzentrum einen eigenen Dateispeicher. Sollte die Verbindung mal ausfallen, haben wir dort alle Logs. Sie werden dort verbleiben und bleiben erhalten.<\/p>\n<\/p>\n
Frage<\/strong>: Erhalten Sie die Logs in Notfallsituationen von dort?<\/p>\n<\/p>\n
Antwort<\/strong>: Kann man dorthin (zum Dateispeicher) gehen und nachsehen?<\/p>\n<\/p>\n
Frage<\/strong>: Wie \u00fcberwachen Sie, dass keine Logs verloren gehen?<\/p>\n<\/p>\n
Antwort<\/strong>: Wir verlieren sie tats\u00e4chlich, und wir \u00fcberwachen das. Die \u00dcberwachung wurde vor einem Monat gestartet. In der Bibliothek, die die Go API nutzt, gibt es Metriken. Sie kann z\u00e4hlen, wie oft sie nicht in den Socket schreiben konnte. Aktuell gibt es eine raffinierte Heuristik. Es gibt einen Puffer. Er versucht, Nachrichten aus diesem zu schreiben. Wenn der Puffer \u00fcberl\u00e4uft, beginnt er, diese zu verwerfen. Und z\u00e4hlt, wie viele er verworfen hat. Wenn die Z\u00e4hler beginnen, \u00fcberzulaufen, erfahren wir davon. Sie kommen jetzt auch nach Prometheus, und in Grafana kann man die Diagramme ansehen. Man kann Benachrichtigungen einrichten. Aber momentan ist unklar, an wen sie gesendet werden sollen.<\/p>\n<\/p>\n
Frage<\/strong>: Speichern Sie Protokolle in Elasticsearch mit einer Sicherung. Wie viele Replikate haben Sie?<\/p>\n<\/p>\n
Antwort<\/strong>: Eine Replikat.<\/p>\n<\/p>\n
Frage<\/strong>: Ist das nur ein Replikat?<\/p>\n<\/p>\n
Antwort<\/strong>: Das ist Master und Replikat. Die Daten werden in zwei Exemplaren gespeichert.<\/p>\n<\/p>\n
Frage<\/strong>: Haben Sie die Gr\u00f6\u00dfe des rsyslog-Puffers irgendwie angepasst? <\/p>\n<\/p>\n
Antwort<\/strong>: Wir schreiben Datagramme in einen benutzerdefinierten Unix-Socket. Das setzt uns sofort eine Grenze von 128 Kilobyte. Mehr k\u00f6nnen wir nicht darin speichern. Das haben wir in den Standard aufgenommen. Wer Zugriff auf die Speicherplatz haben m\u00f6chte, muss 128 Kilobyte beachten. Die Bibliotheken k\u00fcrzen die Nachrichten und setzen ein Flag, das angibt, dass die Nachricht gek\u00fcrzt wurde. In unserem Standard f\u00fcr die Nachricht gibt es ein spezielles Feld, das zeigt, ob sie beim Schreiben gek\u00fcrzt wurde oder nicht. So k\u00f6nnen wir diesen Aspekt ebenfalls nachvollziehen.<\/p>\n<\/p>\n
Frage<\/strong>: Schreiben Sie kaputte JSON-Daten? <\/p>\n<\/p>\n
Antwort<\/strong>: Kaputte JSON-Daten werden entweder w\u00e4hrend des Relays verworfen, weil das Paket zu gro\u00df ist, oder von Graylog zur\u00fcckgewiesen, weil es die JSON-Struktur nicht parsen kann. Aber es gibt einige Details, die behoben werden m\u00fcssen, und diese h\u00e4ngen gr\u00f6\u00dftenteils mit rsyslog zusammen. Ich habe bereits einige Issues dort eingetragen, an denen noch gearbeitet werden muss.<\/p>\n<\/p>\n
Frage<\/strong>: Warum Kafka? Haben Sie es mit RabbitMQ versucht? Funktioniert Graylog bei solch hohen Lasten nicht?<\/p>\n<\/p>\n
Antwort<\/strong>: Graylog stellt sich als nicht ideal f\u00fcr uns heraus. Tats\u00e4chlich sind wir mit Graylog nicht zufrieden. Es gibt viele Probleme damit. Es ist eine eigenwillige L\u00f6sung. Und ehrlich gesagt, brauchen wir es nicht. Ich w\u00fcrde es vorziehen, direkt von rsyslog in Elasticsearch zu schreiben und dann Kibana zu nutzen. Doch wir m\u00fcssen zuerst die Sicherheitsfragen kl\u00e4ren. Das k\u00f6nnte eine m\u00f6gliche Entwicklungsrichtung f\u00fcr uns sein, wenn wir Graylog abschaffen und Kibana verwenden. Logstash w\u00e4re nicht sinnvoll, denn alles, was ich brauche, kann ich auch mit rsyslog erledigen. Es hat sogar ein Modul zum Schreiben in Elasticsearch. Mit Graylog versuchen wir, irgendwie zurechtzukommen. Wir haben es sogar ein wenig optimiert. Aber es gibt noch Raum f\u00fcr Verbesserungen.<\/p>\n<\/p>\n
\u00dcber Kafka. Das hat sich historisch so ergeben. Als ich kam, war sie bereits vorhanden und es wurden schon Logs geschrieben. Wir haben einfach unseren Cluster hochgefahren und die Logs dorthin verschoben. Wir verwalten ihn und wissen, wie es ihm geht. Zur RabbitMQ... wir haben keine gute Erfahrung mit RabbitMQ. Aber unsere RabbitMQ-Instanz l\u00e4uft gut. Wir haben sie in der Produktion und hatten einige Probleme damit. Kurz vor der Verkaufsaktion wurde sie optimiert und funktioniert jetzt gut. Aber davor war ich nicht bereit, sie in die Produktion zu bringen. Es gibt noch einen weiteren Punkt. Graylog kann die Version AMQP 0.9 lesen, w\u00e4hrend rsyslog die Version AMQP 1.0 schreiben kann. Es gibt keine L\u00f6sung, die beides kann. Entweder das eine oder das andere. Daher nutzen wir momentan nur Kafka. Aber auch da gibt es eigene Nuancen. Denn omkafka der rsyslog-Version, die wir verwenden, kann den gesamten Nachrichtenpuffer verlieren, den sie von rsyslog abgezogen hat. Momentan nehmen wir das in Kauf. <\/p>\n
<\/p>\n
Frage<\/strong>: Nutzen Sie Kafka, weil es bereits vorhanden war? F\u00fcr keine anderen Zwecke wird es nicht verwendet?<\/p>\n<\/p>\n
Antwort<\/strong>: Kafka, die verwendet wird, wird vom Data Science Team genutzt. Es ist ein ganz eigenes Projekt, \u00fcber das ich leider nichts sagen kann. Ich bin unwissend dar\u00fcber. Es war in der Verantwortung des Data Science Teams. Als die Logs eingerichtet wurden, haben wir beschlossen, sie zu verwenden, um nicht zus\u00e4tzlich unsere eigene einzurichten. Jetzt haben wir Graylog aktualisiert und dabei die Kompatibilit\u00e4t verloren, da dort eine \u00e4ltere Version von Kafka ist. Wir mussten unsere eigene einrichten. So haben wir auch diese vier Topics f\u00fcr jede API losgeworden. Wir haben ein breites Topic f\u00fcr alle Live-Umgebungen erstellt, ein breites Topic f\u00fcr alle Staging-Umgebungen und schieben einfach alles dort hinein. Graylog filtert das alles parallel heraus.<\/p>\n<\/p>\n
Frage<\/strong>: Warum ist dieses Schamanenwerk mit den Sockets notwendig? Haben Sie versucht, den Log-Treiber Syslog f\u00fcr Container zu verwenden?<\/p>\n<\/p>\n
Antwort<\/strong>: Zu der Zeit, als wir uns mit diesem Thema befassten, war unsere Beziehung zu Docker angespannt. Es war Docker 1.0 oder 0.9. Docker selbst war irgendwie seltsam. Zweitens, wenn man auch noch Logs hineinschieben will\u2026 Ich habe das unbegr\u00fcndete Gef\u00fchl, dass er alle Logs durch sich selbst, durch den Docker-Daemon, leitet. Wenn eine API verr\u00fcckt spielt, sto\u00dfen die anderen APIs auf das Problem, dass sie stdout und stderr nicht senden k\u00f6nnen. Ich wei\u00df nicht, wohin das f\u00fchrt. Ich habe das Gef\u00fchl, dass wir in diesem Fall den Syslog-Treiber von Docker nicht verwenden sollten. Unsere Abteilung f\u00fcr funktionale Tests hat ihren eigenen kleinen Graylog-Cluster f\u00fcr Logs. Sie nutzen die Log-Treiber von Docker und scheinbar l\u00e4uft alles gut. Aber sie schreiben GELF direkt in Graylog. Zu dem Zeitpunkt, als wir damit anfingen, mussten wir sicherstellen, dass es einfach funktioniert. Eventuell, wenn jemand kommt und sagt, dass es schon seit Jahren problemlos l\u00e4uft, werden wir es ausprobieren.<\/p>\n<\/p>\n
Frage<\/strong>: Die Lieferung zwischen den Rechenzentren erfolgt \u00fcber rsyslog. Warum nicht \u00fcber Kafka?<\/p>\n<\/p>\n
Antwort<\/strong>: Wir machen es tats\u00e4chlich auf beide Arten. Aus zwei Gr\u00fcnden. Wenn der Kanal v\u00f6llig \u00fcberlastet ist, passen unsere Protokolle selbst im komprimierten Format nicht mehr hindurch. Und Kafka erm\u00f6glicht es, sie w\u00e4hrend des Prozesses einfach zu verlieren. Auf diese Weise vermeiden wir das Festh\u00e4ngen dieser Protokolle. In diesem Fall nutzen wir Kafka direkt. Wenn wir jedoch einen guten Kanal haben und ihn entlasten m\u00f6chten, verwenden wir rsyslog. Tats\u00e4chlich kann man es so einstellen, dass es automatisch das herausfiltert, was nicht hindurch passt. Momentan verwenden wir an einigen Stellen die direkte Zustellung \u00fcber rsyslog und an anderen Stellen Kafka.<\/p>\nQuelle: 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
![\"Video](\"https:\/\/img.youtube.com\/vi\/NAeedJv-S3I\/hqdefault.jpg\")
\r\n