den Artikel \u00fcber Badushechka<\/a><\/noindex>, die dar\u00fcber geschrieben hat. Aber es gibt einen Punkt. Um diesen Aufruf herum gab es eine endlose Schleife, in der st\u00e4ndig versucht wurde, eine Nachricht in den Socket zu stecken. Das haben wir nicht bemerkt. Wir mussten die Bibliothek umschreiben. Seitdem hat sie sich mehrere Male ge\u00e4ndert, aber jetzt haben wir alle Blockierungen in allen Subsystemen beseitigt. Daher kann rsyslog gestoppt werden, und es wird nichts abst\u00fcrzen.<\/p>\n<\/p>\n
Wir m\u00fcssen die Gr\u00f6\u00dfe der Warteschlangen \u00fcberwachen, um nicht auf diese Probleme zu sto\u00dfen. Erstens k\u00f6nnen wir \u00fcberwachen, wann wir anfangen, Nachrichten zu verlieren. Zweitens k\u00f6nnen wir \u00fcberwachen, dass wir im Allgemeinen Probleme mit der Zustellung haben.<\/p>\n
<\/p>\n
Und ein weiteres unangenehmes Problem \u2013 die Amplitudierung um das Zehnfache in einer Mikroservices-Architektur \u2013 ist sehr einfach. Wir haben nicht so viele eingehende Anfragen, aber aufgrund des Graphen, \u00fcber den diese Nachrichten weiterlaufen, und aufgrund der Access-Logs erh\u00f6hen wir tats\u00e4chlich die Last der Logs ungef\u00e4hr um das Zehnfache. Leider habe ich nicht die genauen Zahlen gez\u00e4hlt, aber Mikroservices sind wie sie sind. Das muss man im Hinterkopf behalten. Dementsprechend ist das Log-Sammlungssystem derzeit das am st\u00e4rksten belastete in Lazada. <\/p>\n
<\/p>\n
<\/p>\n
Wie l\u00f6st man das Problem mit Elasticsearch? Wenn man schnell die Logs an einem Ort haben m\u00f6chte, um nicht auf allen Maschinen suchen zu m\u00fcssen, verwendet man eine Dateispeicherl\u00f6sung. Das funktioniert garantiert. Es kann von jedem Server eingerichtet werden. Man muss nur Festplatten anschlie\u00dfen und syslog installieren. Danach hat man garantiert alle Logs an einem Ort. Dann kann man in Ruhe Elasticsearch, Graylog oder etwas anderes einrichten. Aber man hat bereits alle Logs, und man kann 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 fast aufgeh\u00f6rt, in Dateien zu schreiben. Jetzt werden wir wahrscheinlich die Reste abschalten. Auf den lokalen Maschinen, auf denen die APIs laufen, werden wir nicht mehr in Dateien schreiben. Erstens gibt es einen Dateispeicher, der sehr gut funktioniert. Zweitens geht der Speicherplatz auf diesen Maschinen st\u00e4ndig zur Neige, man muss ihn st\u00e4ndig \u00fcberwachen.<\/p>\n
<\/p>\n
Dieser Teil mit Logstash und Graylog, der ist wirklich belastend. Daher m\u00fcssen wir ihn loswerden. Wir m\u00fcssen etwas ausw\u00e4hlen.<\/p>\n
<\/p>\n
<\/p>\n
Wir haben beschlossen, Logstash und Kibana abzulehnen. Denn wir haben eine Sicherheitsabteilung. Was hat das damit zu tun? Der Zusammenhang ist, dass Kibana ohne X-Pack und ohne Shield keine Zugriffsbeschr\u00e4nkungen f\u00fcr Logs erm\u00f6glicht. Deshalb haben wir Graylog genommen. Das gef\u00e4llt mir nicht, aber es funktioniert. Wir haben neue Hardware gekauft, frisches Graylog installiert und alle Logs mit strengen Formaten in ein separates Graylog \u00fcbertragen. Wir haben das Problem mit verschiedenen Typen derselben Felder organisatorisch gel\u00f6st.<\/p>\n
<\/p>\n
<\/p>\n
Was genau in das neue Graylog einflie\u00dft. Wir haben einfach alles in Docker aufgezeichnet. Wir haben eine Menge Server genommen, drei Instanzen Kafka ausgerollt, 7 Server Graylog in Version 2.3 (weil wir Elasticsearch in Version 5 wollten). All dies haben wir mit HDD-RAIDs hochgezogen. Wir sahen eine Indexierungsrate von bis zu 100.000 Nachrichten pro Sekunde. Wir sahen die Zahl von 140 Terabyte Daten pro Woche. <\/p>\n
<\/p>\n
<\/p>\n
Und wieder die gleichen Probleme! Bei uns stehen zwei Verkaufsaktionen bevor. Wir sind \u00fcber 6 Millionen Nachrichten umgezogen. Unser Graylog hat Schwierigkeiten, mitzuhalten. Irgendwie m\u00fcssen wir wieder \u00fcberleben. <\/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 sind noch nicht an die Grenze gesto\u00dfen, daher ist es noch unklar, wie viel wir wirklich aus diesem System herausziehen k\u00f6nnen. <\/p>\n
<\/p>\n
<\/p>\n
Das sind unsere Zukunftspl\u00e4ne. Darunter ist wahrscheinlich das Wichtigste die Hochverf\u00fcgbarkeit. Die haben wir bisher nicht. Einige Maschinen sind identisch konfiguriert, aber es l\u00e4uft alles \u00fcber eine Maschine. Wir m\u00fcssen Zeit investieren, um das Failover zwischen ihnen einzurichten.<\/p>\n
<\/p>\n
Metriken von Graylog sammeln.<\/p>\n
<\/p>\n
Ein Rate-Limit einrichten, damit uns eine verr\u00fcckte API nicht die Bandbreite und alles andere kaputt macht.<\/p>\n
<\/p>\n
Und schlie\u00dflich irgendein SLA mit den Entwicklern unterzeichnen, dass wir bis zu einem bestimmten Punkt unterst\u00fctzen k\u00f6nnen. Wenn Sie mehr schreiben, tut es uns leid.<\/p>\n
<\/p>\n
Und Dokumentation schreiben.<\/p>\n
<\/p>\n
<\/p>\n
Kurz gesagt, die Ergebnisse von allem, was wir durchgemacht haben. Erstens Standards. Zweitens, syslog \u2014 ein Kuchen. Drittens, rsyslog funktioniert genau so, wie auf der Folie dargestellt. Und lassen Sie uns zu den Fragen \u00fcbergehen.<\/p>\n
<\/p>\n
Fragen<\/strong>.<\/p>\n<\/p>\n
Frage<\/strong>: Warum haben wir uns entschieden, doch nicht\u2026 (filebeat?)<\/p>\n<\/p>\n
Antwort<\/strong>: Wir m\u00fcssen in eine Datei schreiben. Das wollte ich wirklich nicht. Wenn deine API Tausende von Nachrichten pro Sekunde schreibt, ist es trotzdem nicht m\u00f6glich, das einmal pro Stunde zu rotieren. Man kann in ein Pipe schreiben. Worauf die Entwickler mich fragten: \u201eWas passiert, wenn der Prozess, in den wir schreiben, abst\u00fcrzt?\u201c Ich wusste nicht, was ich ihnen antworten sollte, und sagte: \u201eNun gut, lass uns das nicht machen.\u201c<\/p>\n<\/p>\n
Frage<\/strong>: Warum schreiben Sie die Logs nicht einfach in HDFS?<\/p>\n<\/p>\n
Antwort<\/strong>: Das ist die n\u00e4chste Phase. Wir haben am Anfang dar\u00fcber nachgedacht, aber da wir derzeit keine Ressourcen daf\u00fcr haben, bleibt es als langfristige L\u00f6sung offen.<\/p>\n<\/p>\n
Frage<\/strong>: Das Spaltenformat w\u00e4re geeigneter.<\/p>\n<\/p>\n
Antwort<\/strong>: Ich verstehe alles. Wir sind mit beiden H\u00e4nden \"dabei\". <\/p>\n<\/p>\n
Frage<\/strong>: Sie schreiben in rsyslog. Dort kann man sowohl TCP als auch UDP verwenden. Aber wenn UDP, wie garantieren Sie dann die Lieferung?<\/p>\n<\/p>\n
Antwort<\/strong>: Es gibt zwei Punkte. Erstens sage ich sofort allen, dass wir die Lieferung der Logs nicht garantieren. Denn wenn Entwickler kommen und sagen: 'Lass uns dort finanzielle Daten schreiben, und ihr speichert sie irgendwo f\u00fcr den Fall, dass etwas passiert', antworten wir: 'Ausgezeichnet! Lass uns sicherstellen, dass ihr mit dem Schreiben in den Socket blockiert und das in Transaktionen macht, damit ihr uns das garantiert in den Socket legt und sicherstellt, dass wir es von der anderen Seite erhalten.' Und in diesem Moment verlieren alle sofort das Interesse. Wenn du nicht garantieren willst, dass in den Socket geschrieben wird, warum sollten wir dann die Lieferung garantieren? Wir geben unser Bestes. Wir versuchen wirklich, so viel und so gut wie m\u00f6glich zu liefern, aber wir geben keine 100 % Garantie. Deshalb sollten dort keine finanziellen Daten geschrieben werden. Daf\u00fcr gibt es Datenbanken mit Transaktionen.<\/p>\n<\/p>\n
Frage<\/strong>: Wenn das API eine Nachricht in das Log generiert und die Kontrolle an Mikrodienste \u00fcbergibt, sind Sie nicht auf das Problem gesto\u00dfen, dass Nachrichten von verschiedenen Mikrodiensten in falscher Reihenfolge eintreffen? Das f\u00fchrt zu Verwirrung.<\/p>\n<\/p>\n
Antwort<\/strong>: Es ist normal, dass sie in unterschiedlicher Reihenfolge ankommen. Darauf muss man vorbereitet sein. Denn jede Netzwerk\u00fcbertragung garantiert Ihnen keine Reihenfolge, oder man muss speziell Ressourcen daf\u00fcr aufwenden. Wenn wir Dateispeicher betrachten, speichert jedes API die Logs in seiner eigenen Datei. Genauer gesagt, rsyslog organisiert sie in Verzeichnissen. Jedes API hat dort seine Logs, wo man hingehen und nachsehen kann, und dann k\u00f6nnen sie sie nach dem Zeitstempel im Log vergleichen. Wenn sie in Graylog schauen, werden sie dort nach dem Zeitstempel sortiert. Dort wird alles gut sein.<\/p>\n<\/p>\n
Frage<\/strong>: Der Zeitstempel kann sich um Millisekunden unterscheiden.<\/p>\n<\/p>\n
Antwort<\/strong>: Der Zeitstempel wird vom API selbst generiert. Das ist eigentlich der ganze Punkt. Wir haben NTP. Das API generiert den Zeitstempel bereits in der Nachricht. Das f\u00fcgt nicht rsyslog hinzu.<\/p>\n<\/p>\n
Frage<\/strong>: Es ist nicht ganz klar, wie die Interaktion zwischen den Rechenzentren erfolgt. Innerhalb eines Rechenzentrums ist klar, wie die Protokolle gesammelt und verarbeitet werden. Wie findet die Interaktion zwischen den Rechenzentren statt? Oder jedes Rechenzentrum lebt sein eigenes Leben?<\/p>\n<\/p>\n
Antwort<\/strong>: Fast. Jedes Land befindet sich in einem bestimmten Rechenzentrum. Derzeit haben wir keine Verteilung, bei der ein Land in verschiedenen Rechenzentren untergebracht ist. Deshalb m\u00fcssen sie nicht zusammengef\u00fchrt werden. Innerhalb jedes Zentrums gibt es ein Log Relay. Das ist ein Rsyslog-Server. Tats\u00e4chlich gibt es zwei Management-Maschinen. Sie sind gleich konfiguriert. Aber bisher l\u00e4uft der Datenverkehr nur \u00fcber eine von ihnen. Sie aggregiert alle Protokolle. Sie hat eine Disk-Queue f\u00fcr alle F\u00e4lle. Sie komprimiert die Protokolle und sendet sie an das zentrale Rechenzentrum (in Singapur), wo sie dann nach Graylog weitergeleitet werden. Und in jedem Rechenzentrum gibt es einen eigenen Datei-Speicher. Falls die Verbindung verloren geht, haben wir alle Protokolle dort. Sie werden dort bleiben. Sie werden dort gespeichert.<\/p>\n<\/p>\n
Frage<\/strong>: Bekommen Sie in Ausnahmef\u00e4llenProtokolle von dort?<\/p>\n<\/p>\n
Antwort<\/strong>: Man kann dorthin (zum Dateispeicher) gehen und nachsehen.<\/p>\n<\/p>\n
Frage<\/strong>: Wie \u00fcberwachen Sie, dass Sie keine Protokolle verlieren?<\/p>\n<\/p>\n
Antwort<\/strong>: Tats\u00e4chlich verlieren wir sie, und wir \u00fcberwachen das. Die \u00dcberwachung haben wir vor einem Monat gestartet. In der Bibliothek, die das Go API verwendet, gibt es Metriken. Sie kann z\u00e4hlen, wie oft sie nicht in den Socket schreiben konnte. Derzeit gibt es dort eine ausgekl\u00fcgelte Heuristik. Es gibt einen Puffer. Er versucht, Nachrichten aus dem Puffer in den Socket zu schreiben. Wenn der Puffer \u00fcberl\u00e4uft, beginnt er, diese zu verwerfen. Und z\u00e4hlt, wie viele er verworfen hat. Wenn die Z\u00e4hler anfangen, sich zu f\u00fcllen, erfahren wir davon. Sie werden jetzt auch in Prometheus angezeigt, und in Grafana kann man die Grafiken ansehen. Man kann Benachrichtigungen einrichten. Aber es ist noch unklar, an wen sie gesendet werden sollen.<\/p>\n<\/p>\n
Frage<\/strong>: In Elasticsearch speichern Sie die Protokolle mit Sicherung. Wie viele Replikate haben Sie?<\/p>\n<\/p>\n
Antwort<\/strong>: Eine Replik.<\/p>\n<\/p>\n
Frage<\/strong>: Ist das nur eine Replik?<\/p>\n<\/p>\n
Antwort<\/strong>: Das ist ein Master und eine Replik. 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. Dies setzt uns sofort eine Grenze von 128 Kilobyte. Wir k\u00f6nnen nicht mehr als das hinein schreiben. Das haben wir im Standard festgelegt. Wer in die Speicher schreiben m\u00f6chte, der schreibt 128 Kilobyte. Die Bibliotheken k\u00fcrzen das sowieso und setzen ein Flag, dass die Nachricht gek\u00fcrzt wurde. In unserem Nachrichtensystem gibt es ein spezielles Feld, das anzeigt, ob es beim Schreiben gek\u00fcrzt wurde oder nicht. So haben wir die M\u00f6glichkeit, auch diesen Punkt nachzuvollziehen.<\/p>\n<\/p>\n
Frage<\/strong>: Schreiben Sie defekten JSON? <\/p>\n<\/p>\n
Antwort<\/strong>: Defekter JSON wird entweder w\u00e4hrend des Relays abgewiesen, weil das Paket zu gro\u00df ist, oder wird von Graylog abgewiesen, weil es den JSON nicht parsen kann. Aber hier gibt es Feinheiten, die behoben werden m\u00fcssen, und diese h\u00e4ngen gr\u00f6\u00dftenteils von rsyslog ab. Ich habe bereits einige Issues dazu eingetragen, an denen noch gearbeitet werden muss.<\/p>\n<\/p>\n
Frage<\/strong>: Warum Kafka? Haben Sie RabbitMQ ausprobiert? Funktioniert Graylog bei solchen Lasten nicht?<\/p>\n<\/p>\n
Antwort<\/strong>: Bei uns funktioniert Graylog nicht. Aber Graylog funktioniert bei uns. Es ist wirklich problematisch. Es ist eine spezielle Sache. Und eigentlich brauchen wir es nicht. Ich w\u00fcrde es vorziehen, direkt aus rsyslog in Elasticsearch zu schreiben und dann Kibana zu betrachten. Aber ich muss die Angelegenheit mit den Sicherheitsleuten kl\u00e4ren. Das w\u00e4re eine m\u00f6gliche Entwicklung f\u00fcr uns, wenn wir Graylog ausmisten und Kibana verwenden. Logstash macht keinen Sinn, weil ich alles genau so mit rsyslog machen kann. Und es hat ein Modul zum Schreiben in Elasticsearch. Mit Graylog versuchen wir irgendwie zu leben. Wir haben es sogar ein wenig optimiert. Aber da gibt es noch Verbesserungsbedarf.<\/p>\n<\/p>\n
Bez\u00fcglich Kafka. So hat es sich historisch ergeben. Als ich kam, war sie bereits vorhanden und es wurden bereits Protokolle geschrieben. Wir haben einfach unseren Cluster hochgefahren und die Logs dorthin verschoben. Wir managen ihn, wir wissen, wie es ihm geht. Bez\u00fcglich RabbitMQ... funktioniert es bei uns nicht mit RabbitMQ. Aber mit RabbitMQ l\u00e4uft es gut. Es ist in der Produktion und es gab Probleme damit. Kurz vor dem Sale haben wir es angepasst und jetzt funktioniert es einwandfrei. Aber davor war ich nicht bereit, es in die Produktion zu bringen. Ein weiterer Punkt ist, dass Graylog die Version AMQP 0.9 lesen kann, 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 verwenden wir momentan nur Kafka. Aber auch da gibt es einige Nuancen. Denn omkafka der rsyslog-Version, die wir verwenden, k\u00f6nnte den gesamten Nachrichtenpuffer verlieren, den sie aus rsyslog abgegriffen hat. Bis jetzt kommen wir damit klar. <\/p>\n
<\/p>\n
Frage<\/strong>: Verwenden Sie Kafka, weil es bereits vorhanden war? Wird es f\u00fcr keine anderen Zwecke verwendet?<\/p>\n<\/p>\n
Antwort<\/strong>: Die vorhandene Kafka wird vom Data Science-Team genutzt. Das ist ein ganz separates Projekt, \u00fcber das ich leider nichts sagen kann. Ich bin nicht informiert. Es war in der Verantwortung des Data Science-Teams. Als die Logs eingerichtet wurden, beschlossen sie, es zu verwenden, um nicht auch noch ein eigenes aufsetzen zu m\u00fcssen. Jetzt haben wir Graylog aktualisiert und die Kompatibilit\u00e4t verloren, weil dort eine alte Kafka-Version l\u00e4uft. Wir mussten unsere eigene aufsetzen. Au\u00dferdem haben wir uns von diesen vier Topics f\u00fcr jede API befreit. Wir haben ein gro\u00dfes Topic f\u00fcr alles Live und ein weiteres gro\u00dfes Topic f\u00fcr alles Staging und schie\u00dfen einfach alles dort hinein. Graylog sammelt das alles parallel ein.<\/p>\n<\/p>\n
Frage<\/strong>: Warum ist dieser Aufwand 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 dieser Frage besch\u00e4ftigten, war unsere Beziehung zu Docker angespannt. Es war Docker 1.0 oder 0.9. Docker selbst war seltsam. Au\u00dferdem, wenn man auch noch Logs einf\u00fcttern muss... Ich habe ein unbegr\u00fcndetes Gef\u00fchl, dass er alle Logs durch sich selbst, durch den Docker-Daemon, schleust. Wenn eine unserer APIs verr\u00fcckt spielt, dann sind die anderen APIs darauf angewiesen, dass sie stdout und stderr nicht senden k\u00f6nnen. Ich wei\u00df nicht, wohin das f\u00fchren wird. Ich habe das Gef\u00fchl, dass wir den syslog-Treiber von Docker an dieser Stelle besser nicht verwenden sollten. Unsere Abteilung f\u00fcr funktionale Tests hat einen eigenen kleinen Graylog-Cluster f\u00fcr Logs. Sie verwenden die Log-Treiber von Docker und es scheint bei ihnen zu funktionieren. Aber sie schreiben GELF direkt in Graylog. Als wir all dies in Angriff nahmen, mussten wir sicherstellen, dass es einfach funktioniert. Vielleicht, wenn irgendwann jemand kommt und sagt, dass es seit hundert Jahren einwandfrei l\u00e4uft, werden wir es ausprobieren.<\/p>\n<\/p>\n
Frage<\/strong>: Ihr macht die Zustellung zwischen den Rechenzentren mit rsyslog. Warum nicht mit Kafka?<\/p>\n<\/p>\n
Antwort<\/strong>: Wir machen es tats\u00e4chlich beides, und zwar aus zwei Gr\u00fcnden. Wenn die Verbindung v\u00f6llig kaputt ist, kommen selbst unsere komprimierten Logs nicht hindurch. Kafka erm\u00f6glicht es einfach, sie im Prozess zu verlieren. Mit dieser Methode vermeiden wir das Verhaken dieser Logs. In diesem Fall verwenden wir einfach direkt Kafka. Wenn unsere Verbindung gut ist und wir sie entlasten m\u00f6chten, dann verwenden wir rsyslog. Aber tats\u00e4chlich kann man ihn so konfigurieren, dass er das, was nicht durchkommt, selbst wegwirft. Momentan verwenden wir an einigen Stellen die Zustellung von rsyslog direkt, 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