Notiz. übersetzen: Die Autorin dieses Materials ist Cindy Sridharan, eine Ingenieurin bei imgix, die sich auf API-Entwicklung und insbesondere Microservice-Tests spezialisiert hat. In diesem Material teilt sie ihre detaillierte Sicht auf aktuelle Probleme im Bereich des verteilten Tracings, wo es ihrer Meinung nach an wirklich wirksamen Werkzeugen zur Lösung drängender Probleme mangelt.
[Abbildung entnommen aus über verteiltes Tracing.]
Es wird angenommen, dass schwierig umzusetzen, und die Rendite darauf . Es gibt viele Gründe, warum die Ablaufverfolgung problematisch ist. Häufig wird der Aufwand angeführt, der mit der Konfiguration jeder Systemkomponente für die Übertragung der entsprechenden Header bei jeder Anfrage verbunden ist. Obwohl dieses Problem besteht, ist es keineswegs unüberwindbar. Das erklärt übrigens nicht, warum Entwickler Tracing nicht wirklich mögen (auch wenn es bereits funktioniert).
Die größte Herausforderung bei der verteilten Nachverfolgung besteht nicht darin, Daten zu sammeln, Formate für die Verteilung und Präsentation der Ergebnisse zu standardisieren oder festzulegen, wann, wo und wie Proben entnommen werden sollen. Ich versuche es mir nicht vorzustellen trivial Diese „Verständlichkeitsprobleme“ sind in der Tat von erheblicher technischer Bedeutung und (wenn wir wirklich Open Source in Betracht ziehen) ) politische Herausforderungen, die bewältigt werden müssen, damit diese Probleme als gelöst gelten.
Wenn wir jedoch davon ausgehen, dass alle diese Probleme gelöst sind, besteht eine hohe Wahrscheinlichkeit, dass sich daran nichts Wesentliches ändern wird Endbenutzererfahrung. In den gängigsten Debugging-Szenarien ist die Ablaufverfolgung möglicherweise immer noch nicht von praktischem Nutzen – selbst nach der Bereitstellung.
So eine andere Spur
Die verteilte Ablaufverfolgung umfasst mehrere unterschiedliche Komponenten:
- Ausstattung von Anwendungen und Middleware mit Steuerungstools;
- verteilte Kontextübertragung;
- Sammlung von Spuren;
- Spurenspeicherung;
- deren Extraktion und Visualisierung.
In vielen Gesprächen über verteiltes Tracing wird es tendenziell als eine Art unärer Vorgang behandelt, dessen einziger Zweck darin besteht, bei der vollständigen Diagnose des Systems zu helfen. Dies ist größtenteils darauf zurückzuführen, wie sich die Vorstellungen zum verteilten Tracing historisch entwickelt haben. IN , erstellt, als die Zipkin-Quellen geöffnet wurden, wurde dies erwähnt Es [Zipkin] macht Twitter schneller. Auch erste kommerzielle Angebote zur Nachverfolgung wurden beworben .
Notiz. übersetzen: Um den weiteren Text leichter verständlich zu machen, definieren wir zwei Grundbegriffe gemäß :
- Spannweite – das Grundelement der verteilten Ablaufverfolgung. Dabei handelt es sich um eine Beschreibung eines bestimmten Arbeitsablaufs (z. B. einer Datenbankabfrage) mit Namen, Start- und Endzeiten, Tags, Protokollen und Kontext.
- Spans enthalten normalerweise Links zu anderen Spans, sodass mehrere Spans kombiniert werden können Spur – Visualisierung des Lebens einer Anfrage, während sie sich durch ein verteiltes System bewegt.
Traces enthalten unglaublich wertvolle Daten, die bei Aufgaben wie Produktionstests, Disaster-Recovery-Tests, Fehlerinjektionstests usw. hilfreich sein können. Tatsächlich nutzen einige Unternehmen die Rückverfolgung bereits für ähnliche Zwecke. Beginnen wir mit hat neben dem einfachen Verschieben von Spans in das Speichersystem noch andere Verwendungszwecke:
- Zum Beispiel Uber Nachverfolgung der Ergebnisse zur Unterscheidung zwischen Testverkehr und Produktionsverkehr.
- Facebook Trace-Daten für die Analyse kritischer Pfade und für die Verkehrsumschaltung während regelmäßiger Disaster-Recovery-Tests.
- Auch soziales Netzwerk Jupyter-Notebooks, die es Entwicklern ermöglichen, beliebige Abfragen für Trace-Ergebnisse auszuführen.
- Anhänger (Abstammungsgesteuerte Fehlerinjektion) Verteilte Traces zum Testen mit Fehlerinjektion.
Keine der oben aufgeführten Optionen trifft vollständig auf das Szenario zu DebuggenDabei versucht der Ingenieur, das Problem anhand der Spur zu lösen.
Wenn es kommt noch Das Debugging-Skript erreicht, die primäre Schnittstelle bleibt das Diagramm Traceview (obwohl manche es auch nennen "Gantt-Diagramm" oder „Wasserfalldiagramm“). Unter Traceview я alle Spannen und zugehörigen Metadaten, die zusammen den Trace bilden. Jedes Open-Source-Tracing-System sowie jede kommerzielle Tracing-Lösung bietet eine Traceview Benutzeroberfläche zur Visualisierung, Detaillierung und Filterung von Traces.
Das Problem bei allen Tracing-Systemen, die ich bisher gesehen habe, ist, dass das Ergebnis Visualisierung (Traceview) spiegelt die Merkmale des Trace-Generierungsprozesses fast vollständig wider. Selbst wenn alternative Visualisierungen vorgeschlagen werden: Heatmaps, Servicetopologien, Latenzhistogramme, kommt es letztendlich immer noch darauf an Traceview.
Früher habe ich auf die sich die meisten „Innovationen“ im UI/UX-Tracing zu beschränken scheinen Zusätzliche Metadaten im Trace, in die Informationen mit hoher Kardinalität investiert werden (hohe Kardinalität) oder Bereitstellung der Möglichkeit, einen Drilldown in bestimmte Bereiche durchzuführen oder Abfragen auszuführen Inter- und Intra-Trace. In diesem Fall Traceview bleibt das primäre Visualisierungstool. Solange dieser Zustand anhält, wird Distributed Tracing (bestenfalls) den 4. Platz als Debugging-Tool einnehmen, nach Metriken, Protokollen und Stack-Traces, und im schlimmsten Fall wird es sich als Geld- und Zeitverschwendung herausstellen.
Problem mit Traceview
Zweck Traceview – ein vollständiges Bild der Bewegung einer einzelnen Anfrage über alle Komponenten des verteilten Systems hinweg liefern, mit dem sie in Zusammenhang steht. Mit einigen fortschrittlicheren Verfolgungssystemen können Sie einen Drilldown in einzelne Bereiche durchführen und eine Aufschlüsselung im Zeitverlauf anzeigen innen ein Prozess (wenn Bereiche funktionale Grenzen haben).
Die Grundvoraussetzung der Microservices-Architektur ist die Idee, dass die Organisationsstruktur mit den Bedürfnissen des Unternehmens wächst. Befürworter von Microservices argumentieren, dass die Verteilung verschiedener Geschäftsaufgaben auf einzelne Dienste es kleinen, autonomen Entwicklungsteams ermöglicht, den gesamten Lebenszyklus solcher Dienste zu kontrollieren und diese Dienste unabhängig zu erstellen, zu testen und bereitzustellen. Der Nachteil dieser Verteilung ist jedoch der Verlust von Informationen darüber, wie die einzelnen Dienste mit anderen interagieren. Unter solchen Bedingungen soll die verteilte Nachverfolgung ein unverzichtbares Werkzeug sein Debuggen komplexe Interaktionen zwischen Diensten.
Wenn du wirklich , dann kann es kein einziger Mensch im Kopf behalten полную Bild. Tatsächlich ist die Entwicklung eines Tools auf der Grundlage der Annahme, dass es überhaupt möglich ist, so etwas wie ein Anti-Pattern (ein ineffektiver und unproduktiver Ansatz). Idealerweise erfordert das Debuggen ein Tool, das hilft Grenzen Sie Ihren Suchbereich ein, sodass sich Ingenieure auf eine Teilmenge von Dimensionen (Dienste/Benutzer/Hosts usw.) konzentrieren können, die für das betrachtete Problemszenario relevant sind. Um die Ursache eines Fehlers zu ermitteln, müssen Ingenieure nicht verstehen, was während des Fehlers passiert ist Alle Leistungen auf einmal, da eine solche Anforderung der eigentlichen Idee der Microservice-Architektur widersprechen würde.
Traceview ist jedoch genau Das. Ja, einige Tracing-Systeme bieten komprimierte Trace-Ansichten an, wenn die Anzahl der Spans im Trace so groß ist, dass sie nicht in einer Visualisierung angezeigt werden können. Aufgrund der großen Menge an Informationen, die selbst in einer so reduzierten Visualisierung enthalten ist, müssen Ingenieure jedoch immer noch gezwungen „Durchsuchen“ Sie die Auswahl und schränken Sie die Auswahl manuell auf eine Reihe von Diensten ein, die Probleme verursachen. Leider sind Maschinen in diesem Bereich viel schneller als Menschen, weniger fehleranfällig und ihre Ergebnisse sind reproduzierbarer.
Ein weiterer Grund, warum ich Traceview für falsch halte, ist, dass es sich nicht für hypothesengesteuertes Debuggen eignet. Im Kern geht es um das Debuggen iterativ ein Prozess, der mit einer Hypothese beginnt, gefolgt von der Überprüfung verschiedener Beobachtungen und Fakten, die aus dem System entlang verschiedener Vektoren gewonnen wurden, Schlussfolgerungen/Verallgemeinerungen und einer weiteren Bewertung der Wahrheit der Hypothese.
Gelegenheit schnell und günstig Hypothesen zu testen und das mentale Modell entsprechend zu verbessern, ist Grundstein Debuggen Jedes Debugging-Tool sollte vorhanden sein interaktiv und den Suchraum einschränken oder dem Benutzer im Falle eines falschen Hinweises ermöglichen, zurückzugehen und sich auf einen anderen Bereich des Systems zu konzentrieren. Das perfekte Werkzeug erledigt dies proaktivund lenkt die Aufmerksamkeit des Benutzers sofort auf potenzielle Problembereiche.
Ach Traceview kann nicht als Tool mit interaktiver Schnittstelle bezeichnet werden. Das Beste, was Sie bei der Verwendung erwarten können, ist, eine Quelle erhöhter Latenz zu finden und sich alle damit verbundenen möglichen Tags und Protokolle anzusehen. Dies hilft dem Ingenieur nicht bei der Identifizierung Muster im Verkehr, etwa die Besonderheiten der Verzögerungsverteilung, oder erkennen Korrelationen zwischen verschiedenen Messungen. kann helfen, einige dieser Probleme zu umgehen. Wirklich, Erfolgreiche Analyse mithilfe von maschinellem Lernen, um anomale Spannen zu identifizieren und eine Teilmenge von Tags zu identifizieren, die möglicherweise mit anomalem Verhalten verbunden sind. Ich habe jedoch noch keine überzeugenden Visualisierungen von Erkenntnissen aus maschinellem Lernen oder Data Mining gesehen, die auf Spannen angewendet wurden, die sich deutlich von einer Traceansicht oder einem DAG (gerichteter azyklischer Graph) unterscheiden.
Die Spannen sind zu niedrig
Das grundlegende Problem bei Traceview ist Folgendes Spannweiten sind sowohl für die Latenzanalyse als auch für die Ursachenanalyse zu niedrigstufige Grundelemente. Es ist so, als würde man einzelne Prozessorbefehle analysieren, um zu versuchen, eine Ausnahme aufzulösen, obwohl man weiß, dass es wesentlich komfortablere Tools wie Backtrace gibt, mit denen man viel einfacher arbeiten kann.
Darüber hinaus erlaube ich mir Folgendes zu behaupten: Im Idealfall brauchen wir das nicht Gesamtbild Während des Anforderungslebenszyklus ist ein Fehler aufgetreten, der durch moderne Tracing-Tools dargestellt wird. Stattdessen ist eine Form der Abstraktion auf höherer Ebene erforderlich, die Informationen darüber enthält, was ging schief (ähnlich wie Backtrace), zusammen mit etwas Kontext. Anstatt die gesamte Spur zu beobachten, ziehe ich es vor, sie zu sehen часть, wo etwas Interessantes oder Ungewöhnliches passiert. Derzeit wird die Suche manuell durchgeführt: Der Ingenieur erhält die Spur und analysiert selbstständig die Spannen auf der Suche nach etwas Interessantem. Der Ansatz von Leuten, die auf Spans in einzelnen Traces starren, in der Hoffnung, verdächtige Aktivitäten zu entdecken, lässt sich überhaupt nicht skalieren (insbesondere, wenn sie alle in verschiedenen Spans codierten Metadaten, wie Span-ID, RPC-Methodenname, Span-Dauer, verstehen müssen). 'a, Protokolle, Tags usw.).
Alternativen zu Traceview
Trace-Ergebnisse sind am nützlichsten, wenn sie auf eine Weise visualisiert werden können, die einen nicht trivialen Einblick in das Geschehen in miteinander verbundenen Teilen des Systems bietet. Bis dies geschieht, bleibt der Debugging-Prozess weitgehend erhalten untätig und hängt von der Fähigkeit des Benutzers ab, die richtigen Zusammenhänge zu erkennen, die richtigen Teile des Systems zu überprüfen oder die Teile des Puzzles zusammenzusetzen – im Gegensatz dazu Werkzeug, um dem Benutzer bei der Formulierung dieser Hypothesen zu helfen.
Ich bin kein visueller Designer oder UX-Spezialist, aber im nächsten Abschnitt möchte ich ein paar Ideen teilen, wie diese Visualisierungen aussehen könnten.
Konzentrieren Sie sich auf bestimmte Dienstleistungen
In einer Zeit, in der sich die Branche um Ideen konsolidiert , erscheint es vernünftig, dass einzelne Teams der Sicherstellung, dass ihre Dienste auf diese Ziele ausgerichtet sind, Priorität einräumen sollten. Es folgt dem serviceorientiert Für solche Teams ist die Visualisierung am besten geeignet.
Traces, insbesondere ohne Sampling, sind eine Fundgrube an Informationen über jede Komponente eines verteilten Systems. Diese Informationen können einem intelligenten Prozessor zugeführt werden, der die Benutzer versorgt serviceorientiert Befunde. Sie können bereits im Vorfeld identifiziert werden – noch bevor der Nutzer die Spuren betrachtet:
- Latenzverteilungsdiagramme nur für sehr prominente Anfragen (Ausreißeranfragen);
- Diagramme der Verzögerungsverteilung für Fälle, in denen Service-SLO-Ziele nicht erreicht werden;
- Die „allgemeinsten“, „interessantesten“ und „seltsamsten“ Tags in Suchanfragen, die am häufigsten vorkommen werden wiederholt;
- Latenzaufschlüsselung für Fälle, in denen Abhängigkeiten Dienste erreichen ihre SLO-Ziele nicht;
- Latenzaufschlüsselung für verschiedene Downstream-Dienste.
Einige dieser Fragen werden durch integrierte Metriken einfach nicht beantwortet, was Benutzer dazu zwingt, Spannen genau zu prüfen. Dadurch verfügen wir über einen äußerst benutzerfeindlichen Mechanismus.
Dies wirft die Frage auf: Wie sieht es mit komplexen Interaktionen zwischen verschiedenen Diensten aus, die von verschiedenen Teams gesteuert werden? Nicht wahr? Traceview wird nicht als das am besten geeignete Instrument angesehen, um eine solche Situation hervorzuheben?
Mobile Entwickler, Besitzer zustandsloser Dienste, Besitzer verwalteter zustandsbehafteter Dienste (wie Datenbanken) und Plattformbesitzer könnten an etwas anderem interessiert sein Präsentation verteiltes System; Traceview ist eine zu generische Lösung für diese grundlegend unterschiedlichen Bedürfnisse. Selbst in einer sehr komplexen Microservice-Architektur benötigen Dienstbesitzer keine tiefgreifenden Kenntnisse über mehr als zwei oder drei Upstream- und Downstream-Dienste. Im Wesentlichen müssen Benutzer in den meisten Szenarien nur Fragen zu beantworten begrenztes Leistungsangebot.
Es ist, als würde man eine kleine Untergruppe von Diensten durch ein Vergrößerungsglas betrachten, um sie genauer zu untersuchen. Dadurch kann der Benutzer dringendere Fragen zu den komplexen Interaktionen zwischen diesen Diensten und ihren unmittelbaren Abhängigkeiten stellen. Dies ähnelt dem Backtrace in der Dienstleistungswelt, wo der Ingenieur Bescheid weiß dass falsch, und hat auch ein gewisses Verständnis dafür, was in den umliegenden Diensten geschieht, um zu verstehen warum.
Der von mir befürwortete Ansatz ist das genaue Gegenteil des auf Traceviews basierenden Top-Down-Ansatzes, bei dem die Analyse mit dem gesamten Trace beginnt und sich dann schrittweise auf einzelne Bereiche herunterarbeitet. Im Gegensatz dazu beginnt ein Bottom-up-Ansatz mit der Analyse eines kleinen Bereichs in der Nähe der potenziellen Ursache des Vorfalls und erweitert dann den Suchraum nach Bedarf (mit der Möglichkeit, andere Teams hinzuzuziehen, um ein breiteres Spektrum an Diensten zu analysieren). Der zweite Ansatz eignet sich besser, um erste Hypothesen schnell zu testen. Sobald konkrete Ergebnisse vorliegen, kann mit einer gezielteren und detaillierteren Analyse begonnen werden.
Aufbau einer Topologie
Dienstspezifische Ansichten können unglaublich nützlich sein, wenn der Benutzer Bescheid weiß was? Ein Dienst oder eine Gruppe von Diensten ist dafür verantwortlich, die Latenz zu erhöhen oder Fehler zu verursachen. In einem komplexen System kann die Identifizierung des fehlerhaften Dienstes jedoch während eines Fehlers eine nicht triviale Aufgabe sein, insbesondere wenn von den Diensten keine Fehlermeldungen gemeldet wurden.
Der Aufbau einer Diensttopologie kann eine große Hilfe sein, um herauszufinden, bei welchem Dienst ein Anstieg der Fehlerraten oder eine Erhöhung der Latenz auftritt, die zu einer spürbaren Verschlechterung des Dienstes führt. Wenn ich über den Aufbau einer Topologie spreche, meine ich das nicht Karte der Dienstleistungen, zeigt alle im System verfügbaren und für ihre Funktion bekannten Dienste an . Diese Ansicht ist nicht besser als die Traceansicht, die auf einem gerichteten azyklischen Graphen basiert. Stattdessen würde ich es gerne sehen dynamisch generierte Service-Topologie, basierend auf bestimmten Attributen wie Fehlerrate, Reaktionszeit oder einem beliebigen benutzerdefinierten Parameter, der zur Klärung der Situation bei bestimmten verdächtigen Diensten beiträgt.
Nehmen wir ein Beispiel. Stellen wir uns eine hypothetische Nachrichtenseite vor. Homepage-Service (Titelseite) tauscht Daten mit Redis, mit einem Empfehlungsdienst, mit einem Werbedienst und einem Videodienst aus. Der Videodienst übernimmt Videos von S3 und Metadaten von DynamoDB. Der Empfehlungsdienst empfängt Metadaten von DynamoDB, lädt Daten von Redis und MySQL und schreibt Nachrichten an Kafka. Der Werbedienst empfängt Daten von MySQL und schreibt Nachrichten an Kafka.
Nachfolgend finden Sie eine schematische Darstellung dieser Topologie (viele kommerzielle Routing-Programme erstellen die Topologie). Dies kann nützlich sein, wenn Sie Dienstabhängigkeiten verstehen müssen. Allerdings während DebuggenWenn ein bestimmter Dienst (z. B. ein Videodienst) eine längere Reaktionszeit aufweist, ist eine solche Topologie nicht sehr nützlich.
Servicediagramm einer hypothetischen Nachrichtenseite
Das Diagramm unten wäre besser geeignet. Es liegt ein Problem mit dem Dienst vor (Video) genau in der Mitte abgebildet. Der Benutzer merkt es sofort. Aus dieser Visualisierung wird deutlich, dass der Videodienst aufgrund einer Erhöhung der S3-Reaktionszeit abnormal funktioniert, was sich auf die Ladegeschwindigkeit eines Teils der Hauptseite auswirkt.
Dynamische Topologie, die nur „interessante“ Dienste anzeigt
Dynamisch generierte Topologien können effizienter sein als statische Service-Maps, insbesondere in elastischen, automatisch skalierenden Infrastrukturen. Durch die Möglichkeit, Servicetopologien zu vergleichen und gegenüberzustellen, kann der Benutzer relevantere Fragen stellen. Genauere Fragen zum System führen eher zu einem besseren Verständnis der Funktionsweise des Systems.
Vergleichsdarstellung
Eine weitere nützliche Visualisierung wäre eine vergleichende Darstellung. Derzeit eignen sich Spuren nicht sehr gut für direkte Vergleiche, daher sind Vergleiche dies normalerweise der Fall Spannweiten. Und die Hauptidee dieses Artikels ist genau, dass Spannen zu niedrig sind, um die wertvollsten Informationen aus den Trace-Ergebnissen zu extrahieren.
Der Vergleich zweier Spuren erfordert keine grundlegend neuen Visualisierungen. Tatsächlich reicht so etwas wie ein Histogramm aus, das dieselben Informationen wie eine Traceansicht darstellt. Überraschenderweise kann selbst diese einfache Methode viel mehr Erfolg bringen, als nur zwei Spuren einzeln zu untersuchen. Noch mächtiger wäre die Möglichkeit visualisieren Vergleich von Spuren zusammen. Es wäre äußerst nützlich zu sehen, wie sich eine kürzlich bereitgestellte Datenbankkonfigurationsänderung zur Aktivierung von GC (Garbage Collection) auf die Antwortzeit eines Downstream-Dienstes in einer Größenordnung von mehreren Stunden auswirkt. Wenn das, was ich hier beschreibe, wie eine A/B-Analyse der Auswirkungen von Infrastrukturänderungen klingt in vielen Diensten Wenn Sie die Trace-Ergebnisse verwenden, sind Sie nicht allzu weit von der Wahrheit entfernt.
Abschluss
Ich zweifle nicht an der Nützlichkeit der Nachverfolgung selbst. Ich bin der festen Überzeugung, dass es keine andere Methode zum Sammeln von Daten gibt, die so umfangreich, kausal und kontextbezogen ist wie die in einer Spur enthaltene. Allerdings glaube ich auch, dass alle Tracing-Lösungen diese Daten äußerst ineffizient nutzen. Solange Tracing-Tools in der Traceview-Darstellung hängen bleiben, sind sie nur eingeschränkt in der Lage, die wertvollen Informationen optimal zu nutzen, die aus den in den Traces enthaltenen Daten extrahiert werden können. Darüber hinaus besteht die Gefahr, dass eine völlig unfreundliche und nicht intuitive visuelle Benutzeroberfläche weiterentwickelt wird, die die Möglichkeiten des Benutzers, Fehler in der Anwendung zu beheben, erheblich einschränkt.
Das Debuggen komplexer Systeme ist selbst mit den neuesten Tools unglaublich schwierig. Tools sollen dem Entwickler helfen, eine Hypothese zu formulieren und zu testen, aktiv bereitstellen relevante Informationen, Identifizierung von Ausreißern und Feststellung von Merkmalen in der Verteilung von Verzögerungen. Damit die Ablaufverfolgung zum Werkzeug der Wahl für Entwickler wird, wenn sie Produktionsausfälle beheben oder Probleme lösen, die sich über mehrere Dienste erstrecken, sind originelle Benutzeroberflächen und Visualisierungen erforderlich, die besser mit dem mentalen Modell der Entwickler übereinstimmen, die diese Dienste erstellen und betreiben.
Es erfordert erhebliche mentale Anstrengungen, ein System zu entwerfen, das die verschiedenen in den Trace-Ergebnissen verfügbaren Signale auf eine Weise darstellt, die für eine einfache Analyse und Schlussfolgerung optimiert ist. Sie müssen darüber nachdenken, wie Sie die Systemtopologie während des Debuggens so abstrahieren können, dass der Benutzer blinde Flecken überwinden kann, ohne auf einzelne Spuren oder Bereiche achten zu müssen.
Wir benötigen gute Abstraktions- und Layering-Fähigkeiten (insbesondere in der Benutzeroberfläche). Solche, die gut in einen hypothesengesteuerten Debugging-Prozess passen würden, bei dem Sie iterativ Fragen stellen und Hypothesen testen können. Sie lösen nicht automatisch alle Beobachtbarkeitsprobleme, aber sie helfen Benutzern, ihre Intuition zu schärfen und intelligentere Fragen zu formulieren. Ich fordere einen durchdachteren und innovativeren Ansatz zur Visualisierung. Hier besteht eine echte Perspektive, den Horizont zu erweitern.
PS vom Übersetzer
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «".
Source: habr.com