Ihr Einstieg in Fastlys Echtzeit-Logs und Compute
Möchten Sie die Vorteile von Edge Computing selbst entdecken? Wir haben kürzlich eine kostenlose Testversion gestartet, um Ihnen die Möglichkeit zu geben, unsere Serverless-Plattform unverbindlich zu testen.
Bei der Entwicklung von WebAssembly (oder Wasm) Anwendungen für Fastlys Edge Caches auf Compute ist ein Umdenken gefragt: von der Konfiguration des CDN-Verhaltens über das VCL (Varnish Configuration Language) bis hin zu einer Form der Programmierung, die an die traditionelle Softwareentwicklung erinnert – sei es in Rust, JavaScript oder AssemblyScript.
Aber ganz gleich, ob Sie mit VCL bereits vertraut sind oder Compute für Sie komplettes Neuland ist, werden Sie irgendwann wissen wollen, wie die Ausgabe von Diagnosetexten aus Ihren Wasm Anwendungen funktioniert – sei es zur einmaligen Fehlersuche oder zur kontinuierlichen Erfassung von Schlüsselindikatoren.
Es gibt zwei Möglichkeiten, Ausgaben von Wasm Anwendungen auf Compute zu erzeugen. Und diese entsprechen zufällig zwei verschiedenen Kategorien von Zielorten für die Erfassung oder Speicherung der ausgegebenen Benachrichtigungen.
Klassisches STDIO
Die Ausgabe an die Dateideskriptoren stdout und stderr wird von der Hostumgebung erfasst und – ähnlich wie die Ausgabe, die an ein Terminal oder eine Datei umgeleitet wird – an ein Ziel weitergeleitet, das sich nachverfolgen lässt. Bei Compute wird diese Funktion als „Log Tailing“ bezeichnet und von der Fastly CLI unterstützt. Log Tailing erfasst und zeigt außerdem unbehandelte Laufzeitfehler aus Ihrer Wasm App an.Logging Framework
Das Compute Logging Framework unterstützt das Hinzufügen formeller Strukturen, die Kodifizierung von Absichten und die Konfiguration eines Zielsystems für die erzeugte Ausgabe. Als Ziele für Ihre Log-Benachrichtigungen eignen sich sämtliche Integrationen, die im Rahmen unserer Log-Streaming-Plattform zur Verfügung stehen und unter anderem auf Apache Kafka, S3 und Splunk abzielen. Sie können Ihre Protokolle nach Wichtigkeit klassifizieren, zum Beispiel als Information, Warnung oder nach Fehlerkategorie. Am Zielort angekommen, können die Protokolle anhand dieser und beliebiger anderer Kriterien automatisiert verarbeitet werden.
In diesem Blogpost führen wir Sie durch die grundlegenden Schritte der Ausgabe von Messages an STDIO und der Nachverfolgung dieses Outputs mithilfe der Fastly CLI sowie die Konfiguration eines Log Streaming Endpoints, die Ausgabe von Logs in Ihrer Anwendung und die Bestätigung der Übermittlung dieser Logs an das gewünschte Ziel. Für das Log Streaming verwenden wir Azure Event Hubs, einen Service Bus, der mit dem Apache Kafka Protokoll als angesteuertem Log-Aggregator kompatibel ist. Wenn Sie ein anderes Ziel wählen, müssen Sie die Konfiguration des Logging Endpoints entsprechend anpassen, wie in unserer Log-Streaming-Dokumentation beschrieben.
Projekt aufsetzen
Damit dieses Tutorial leichter zu befolgen ist, konzentrieren wir uns ausschließlich auf CLI-Tools. Wir gehen dabei davon aus, dass Sie bereits einen Fastly Account erstellt und die Fastly CLI sowie Rust installiert haben. Wenn nicht, dann ist jetzt der richtige Zeitpunkt, um dies zu tun. Hinweis: In diesem Tutorial beziehen wir uns auf Version 1.0.0 der Fastly CLI. Bei anderen Versionen können einige der Command Flags abweichen. Außerdem lassen sich dieselben Ziele auch mit JavaScript und AssemblyScript erreichen, auch wenn wir uns hier nur mit Rust beschäftigen.
Zunächst erstellen wir ein funktionsfähiges CLI-Token. Führen Sie als Administrator Ihres Accounts folgenden Befehl aus, um das API-Token für alle nachfolgenden Konfigurationsbefehle des CLI-Tools in diesem Tutorial zu generieren. Denken Sie auch daran, ein angemessenes Ablaufdatum und eine angemessene Ablaufzeit für Ihr Token anzugeben.
fastly auth-token create --password=<your-Fastly-acct-password> \--name='My WASM API Token' --scope=global \--expires 2021-12-31T23:59:59ZDer Output, den Sie erhalten, sollte in etwa so aussehen:
SUCCESS: Created token ‘<token-string>’ ...Der String zwischen den beiden einfachen Anführungszeichen entspricht dem Wert Ihres Fastly API-Tokens. Führen Sie nun den folgenden Befehl aus und geben Sie das erstellte Token an, wenn Sie dazu aufgefordert werden:
fastly configureSie sollten nun in der Lage sein, Ihre Fastly Services und Compute Wasm Anwendungen zu erstellen, zu konfigurieren und zu verwalten.
Verwenden Sie folgenden Befehl, um einen Wasm Service zu erstellen:
fastly service create --name=MyService --type=wasmHinweis: Der obige Befehl dient spezifisch der Erstellung eines Fastly Wasm Service und nicht eines herkömmlichen VCL Service. Bei Interesse können Sie diesen neuen Service jetzt auch in der Fastly Web-App sehen.
Ihr Service benötigt zumindest einen eigenen Domainnamen, damit seine Servicekonfiguration aktiviert werden kann. Zunächst brauchen wir aber die Service ID Ihres neuen Service. Diese erhalten Sie mit folgendem Befehl:
fastly service listDie Antwort enthält Ihre Service ID in der Spalte „ID“. Ebenfalls sollte der generierte Output Ihren Servicetyp – wasm – enthalten.
Führen Sie den folgenden Befehl aus und geben Sie einen konkreten Namen für die Subdomain an, um Ihrem Wasm Service eine Domain zuzuweisen:
fastly domain create --name=<your-name>.edgecompute.app \--version=latest --service-id=<your-Fastly-service-ID>Hinweis: Unsere Plattform setzt voraus, dass Compute Wasm Services Domainnamen mit edgecompute.app als übergeordnetem Suffix haben, da diese Top-Level-Domain mit unserer CDN-Infrastruktur verknüpft ist. Für Ihre Compute Produktivumgebungen können Sie durch CNAME-Einträge bei Ihrem DNS-Provider jedoch beliebige Aliasnamen festlegen.
Um Ihnen ein interessanteres Beispiel zu bieten, weisen wir unserem Wasm Service zwei Backend Origin Hosts zu, und zwar www.w3.org und www.iana.org. Diese stehen stellvertretend für Ihren eigentlichen Origin-Server, der Ihre Webinhalte bereitstellt. Führen Sie folgende beiden Befehle aus, um diese beiden Backends hinzuzufügen:
fastly backend create --name=backend_name --address=www.w3.org \--override-host=www.w3.org --use-ssl --ssl-sni-hostname=www.w3.org \--ssl-cert-hostname='*.w3.org' --version=latest \--service-id=<your-Fastly-service-ID>
fastly backend create --name=other_backend_name \--address=www.iana.org --override-host=www.iana.org --use-ssl \--ssl-sni-hostname=www.iana.org \--ssl-cert-hostname='*.iana.org' --version=latest \--service-id=<your-Fastly-service-ID>Wenn die Backend Origin Services konfiguriert sind, besteht der verbleibende Schritt für dieses anfängliche Wasm App-Setup darin, den tatsächlichen Wasm Code zu erstellen und hochzuladen. Glücklicherweise macht die CLI Ihnen diese Aufgabe mit ihren Wasm Starterkits unglaublich leicht.
Führen Sie den folgenden Befehl aus, bestätigen Sie Ihren Nutzernamen und wählen Sie die Option „Default starter for Rust“ (oder eine Option mit ähnlichem Namen) aus, die Sie verwenden möchten:
fastly compute init --language=Rust --directory=./MyEdgeComputeApp \--name=MyEdgeComputeApp \--description='My first Compute@Edge app'Wechseln Sie in das Verzeichnis MyEdgeComputeApp und überprüfen Sie dessen Inhalt – besonders die Dateien unter ./src. Bearbeiten Sie die Liste ./fastly.toml im Root-Verzeichnis des Projekts, um sie an Ihre Einstellungen for das Service Backend anzugleichen:
[setup]
[setup.backends]
[setup.backends.backend_name] address = "www.w3.org" description = "A backend able to serve `/articles` path" port = 443
[setup.backends.other_backend_name] address = "www.iana.org" description = "A backend able to serve `/anything` path" port = 443Sie können die obige Konfiguration vollständig entfernen und sich ausschließlich auf die CLI verlassen, um Ihre Backends zu verwalten. Der CLI Wasm Veröffentlichungsprozess kann jedoch auch die Datei ./fastly.toml verwenden, um die Backends automatisch für Ihre Wasm App zu konfigurieren.
Führen Sie folgende Befehle aus, um Ihre Wasm App zu erstellen und bereitzustellen:
fastly compute buildfastly compute deploy --service-id=<your-Fastly-service-ID>Nun wird Ihr Compute Wasm Service aktiviert und kann Requests ausliefern.
Sie können jede der folgenden URLs für Ihren Service abrufen und deren Antworten beobachten:
https://<your-name>.edgecompute.app/https://<your-name>.edgecompute.app/articleshttps://<your-name>.edgecompute.app/anything
Die Pfade /articles und /anything sollten zu HTTP-404-„landing page“-Antworten von www.w3.org und www.iana.org führen. Als kleine Übung überlasse ich es Ihnen, herauszufinden, wie Sie den Rust Code in ./src/main.rs dazu bringen, diese Pfade zu gültigen Seiten aufzulösen und Pfade für Seitenartefakte auf den beiden Websites aufzulösen .
Glückwunsch! Sie haben Ihre Compute Wasm App bereitgestellt und können jetzt mit der Ausgabe von Programmdaten und der Protokollierung in externen Log-Kollektoren aus Ihrer Anwendung heraus beginnen. In den nächsten drei Abschnitten zeigen wir Ihnen, wie Sie diese Ziele der Reihe nach erreichen können.
Print Debugging mit der CLI
In diesem Abschnitt zeigen wir Ihnen, wie Sie einfache Druckanweisungen von Ihrer Compute Wasm Anwendung aus versenden und überwachen können.
Gehen Sie zurück zu Ihrer MyEdgeComputeApp aus dem vorherigen Schritt und fügen Sie folgende Zeile zu ./src/main.rs, unter fn main(mut req: Request) -> Result<Response, Error> { hinzu:
fn main(mut req: Request) -> Result<Response, Error> { // Log request path to stdout. println!("Request received for path {}", req.get_path()); // Filter request methods... match req.get_method() { ...Erstellen Sie einen Build und stellen Sie Ihre Wasm App erneut bereit:
fastly compute buildfastly compute deploy --service-id=<your-Fastly-service-ID>Hinweis: Dieser Schritt stellt automatisch die nächste Version der Wasm Servicekonfiguration für Sie bereit und aktiviert sie mit dem neu veröffentlichten Wasm App-Paket.
Geben Sie in Ihrem Terminal den folgenden Befehl ein, um das Log Tailing des Outputs von Ihrer Wasm App zu starten:
fastly log-tail --service-id=<your-Fastly-service-ID>Möglicherweise werden Ihnen unmittelbar einige Benachrichtigungen angezeigt, die Sie darauf hinweisen, dass Log Tailing für Ihren Wasm Service aktiviert wurde. Dies ist aber lediglich eine Folge der Ersteinrichtung.
Um das Log Tailing des Outputs Ihrer Anwendung in Aktion zu sehen, rufen Sie die URL für Ihren Wasm Service ab, zum Beispiel https://<ihr-name>.edgecompute.app/. Rufen Sie anschließend die beiden anderen virtuellen Pfade für dieselbe Subdomain ab: /articles und /anything.
Zumindest sollte das Ergebnis der oben genannten Fetch-Anfragen einen Output ergeben, der so ähnlich wie Folgender aussieht:
stdout | 5ee29b16 | Request received for path /stdout | f438ba38 | Request received for path /articlesstdout | 44c848ca | Request received for path /anythingWenn Sie Ihre Requests von einem Webbrowser aus gestellt haben, können Sie zusätzliche Einträge für JavaScript und Bildartefakte sehen. Wenn Sie zunächst keine der erwarteten Outputs sehen, versuchen Sie erneut, die Fetch-Anfragen abzurufen. Bei dem Hash-Wert neben jeder Output-Benachrichtigung handelt es sich um eine Korrelations-ID für jeden Request, wobei eine einzige Anfrage zu mehreren Output-Benachrichtigungen führen kann. Sehen wir uns das Ganze doch mal in Aktion an. Drücken Sie zum Beenden ^C.
Kehren Sie zu Ihrer MyEdgeComputeApp zurück und fügen Sie unter "/articles" => { folgenden Code hinzu:
"/articles" => { eprintln!("Request will be redirected to {}", BACKEND_NAME); // Request handling logic could go here... E.g., send the request to an origin backend ...Erstellen Sie einen weiteren Build und stellen Sie Ihre Wasm App erneut bereit:
fastly compute buildfastly compute deploy --service-id=<your-Fastly-service-ID>Starten Sie das Log Tailing des Outputs von Ihrer Wasm App erneut:
fastly log-tail --service-id=<your-Fastly-service-ID>Stellen Sie anschließend eine Fetch-Anfrage an https://<ihr-name>.edgecompute.app/articles und beobachten Sie den Output, der in etwa wie folgt aussehen sollte:
stdout | ad3d576e | Request received for path /articlesstderr | ad3d576e | Request will be redirected to backend_nameKlingt nicht besonders spektakulär, oder? Bei genauerem Hinsehen werden Sie allerdings feststellen, dass hier eine Reihe von Dingen geschehen:
Es werden zwei Benachrichtigungen an zwei verschiedene Output Streams gesendet:
stdoutundstderrBeide Outputs wurden aus der Bearbeitung einer einzigen Anfrage generiert, die im Beispiel oben mit
ad3d576ebezeichnet wurde.
Sie können den Output mit der CLI auch nach Streaming-Typ filtern.
Was haben wir in diesem Abschnitt beobachtet? Mithilfe der Output Streams STDOUT und STDERR in Rust können Sie aussagekräftige Informationen von Ihrer Compute Wasm Anwendung übermitteln und mit fastly log-tail, lässt sich der emittierte Output lokal auf Ihrem System nachverfolgen und anzeigen. Schließlich können Sie mit fastly log-tail, auch historischen Output anzeigen, der innerhalb eines bestimmten Zeitintervalls erfasst wurde. Mehr dazu erfahren Sie in der entsprechenden Dokumentation.
Sie sind von Ihrer Compute Wasm Anwendung ganz bestimmt begeistert. Was aber, wenn Sie sie in der Produktivumgebung einsetzen, aber entweder nicht die Standard Output Streams Ihres Terminals anzapfen wollen oder bessere Möglichkeiten zum Speichern und Abfragen der ausgegebenen Log-Informationen haben möchten? Und was, wenn Sie die Log-Analyse zur Erkennung von Anomalien oder wichtiger Geschäftschancen anhand der Requests, die Ihre Wasm App erhält, automatisieren möchten?
Glücklicherweise haben wir mit unserer Log-Streaming-Plattform die richtige Lösung für diese Herausforderung. Sie ist gleichermaßen für Wasm Services und Anwendungen wie für herkömmliche VCL Konfigurationen verfügbar. In den nächsten Abschnitten befassen wir uns mit den Einzelheiten der Konfiguration und des Sendens von Logs an ausgeklügelte Log-Aggregations-Endpoints von Ihrer Wasm Anwendung aus. Gleichzeitig stellen wir sicher, dass die Logs auf der anderen Seite für Ihre Analyseplattform verfügbar sind.
Logging Endpoints konfigurieren
Um Aggregationssysteme mit unseren Logs anzusteuern, müssen wir zunächst einige tatsächliche Endpoints einrichten. Wir konfigurieren einen Kafka Cloud Endpoint und einen in Azure mit Event Hubs. Für unser Beispiel verwenden wir die einfachste Konfiguration und verweisen für weitere Informationen über den Service auf die Dokumentation auf der Microsoft Azure Plattform. Außerdem nutzen wir hier nur wenige Kafka Tools, da die eigentliche End-to-End-Integration unser einziger Schwerpunkt ist.
Wenn Sie die Azure CLI installiert und einen Azure Account erstellt haben (Testversion genügt), loggen Sie sich über die CLI in ihren Account ein. Hinweis: Sie müssen sich möglicherweise mit Ihrer Tenant ID anmelden, um sich korrekt zu authentifizieren:
az login --tenant <your-tenant-ID>Im Output des obigen Befehls sollten Sie Ihre aktiven Azure Abonnements sehen können, wobei Basic völlig ausreicht. Notieren Sie sich Ihre Abonnement-ID aus dem Output des Befehls. Führen Sie die folgenden Befehle aus, um einen Event Hubs Cluster in Azure einzurichten. Die folgenden Befehle verwenden die Region „West Central US“ als Zielort, aber Sie können ihn durch einen Ort Ihrer Wahl ersetzen, indem Sie az account list-locations ausführen.
az group create --location westcentralus --name MyAzureGroup \--subscription <your-subscription-ID>
az eventhubs namespace create --name <your-unique-namespace> \--resource-group MyAzureGroup --enable-kafka true \--location westcentralus --sku Standard \--subscription <your-subscription-ID> \--enable-auto-inflate false
az eventhubs eventhub create --resource-group MyAzureGroup \--namespace-name <your-unique-namespace> --name MyEventHub \--message-retention 1 --partition-count 1 --enable-capture false \--subscription <your-subscription-ID>
az eventhubs eventhub authorization-rule create \--eventhub-name MyEventHub --name Fastly \--namespace-name <your-unique-namespace> \--resource-group MyAzureGroup --rights Listen Send \--subscription <your-subscription-ID>
az eventhubs eventhub authorization-rule keys list \--eventhub-name MyEventHub --name Fastly \--namespace-name <your-unique-namespace> \--resource-group MyAzureGroup \--subscription <your-subscription-ID>Wenn der Name Ihres Event Hubs Namensraums nicht verfügbar ist, versuchen Sie es mit einem anderen Namen. Der Letzte der oben genannten Befehle zeigt die sichere Azure Event Hubs Verbindungszeichenfolge an („<b>primaryConnectionString</b>“ ), die Sie in den nächsten Schritten in Ihrer Fastly Log-Streaming-Endpoint-Konfiguration für Kafka verwenden müssen.
Mit den obigen Befehlen wird ein einzelner Event Hub eingerichtet, der einem Kafka Topic ähnelt. Was aber, wenn wir zwei verschiedene Datenverarbeitungspipelines für unterschiedliche Arten von Ereignissen haben und diese Kategorien von Ereignissen unabhängig voneinander analysieren möchten? Für dieses Szenario richten wir einen weiteren Event Hub ein. Führen Sie die folgenden Befehle aus, um einen sekundären Ereignis-Bus für verschiedene Ereignisse zu initialisieren:
az eventhubs eventhub create --resource-group MyAzureGroup \--namespace-name <your-unique-namespace> --name MyOtherEventHub \--message-retention 1 --partition-count 1 --enable-capture false \--subscription <your-subscription-ID>
az eventhubs eventhub authorization-rule create \--eventhub-name MyOtherEventHub --name Fastly \--namespace-name <your-unique-namespace> \--resource-group MyAzureGroup --rights Listen Send \--subscription <your-subscription-ID>
az eventhubs eventhub authorization-rule keys list \--eventhub-name MyOtherEventHub --name Fastly \--namespace-name <your-unique-namespace> \--resource-group MyAzureGroup \--subscription <your-subscription-ID>Wie bereits erwähnt, zeigt der Letzte der oben genannten Befehle die sichere Azure Event Hubs Verbindungszeichenfolge an („<b>primaryConnectionString</b>“ ), die Sie besonders für den zweiten Endpoint in Ihrer Fastly Log-Streaming-Endpoint-Konfiguration für Kafka verwenden müssen.
Führen Sie den folgenden CLI-Befehl aus, um den ersten erstellten Azure Event Hubs Endpoint zu Ihrem Compute Wasm Service hinzuzufügen:
fastly logging kafka create --name=AzureEventHubs --version=latest \--topic=MyEventHub \--brokers=<your-unique-namespace>.servicebus.windows.net:9093 \--service-id=<your-Fastly-service-ID> --required-acks=-1 --use-tls --max-batch-size=2048 \--use-sasl --auth-method=plain --username='$ConnectionString' \--password='<value-of-first-Azure-primaryConnectionString>' --autoclone --placement=noneBitte beachten Sie dabei, dass nach Ausführung des obigen Befehls eine neue Service-Entwurfsversion Ihrer Servicekonfiguration erstellt wird, diese jedoch nicht aktiv ist. Wir aktivieren sie später bei Veröffentlichung des aktualisierten Codes für Ihre Wasm App. Beachten Sie auch, dass der obige Befehl diesen Logging Endpoint als „AzureEventHubs“ benannt hat und dass Sie auf diesen Namen des Logging Endpoints in Ihrem Wasm Anwendungscode verweisen müssen.
Führen Sie den folgenden CLI-Befehl aus, um den zweiten erstellten Azure Event Hubs Endpoint zu Ihrem Compute Wasm Service hinzuzufügen:
fastly logging kafka create --name=AnotherAzureEventHubs --version=latest \--topic=MyOtherEventHub \--brokers=<your-unique-namespace>.servicebus.windows.net:9093 \--service-id=<your-Fastly-service-ID> --required-acks=-1 --use-tls --max-batch-size=2048 \--use-sasl --auth-method=plain --username='$ConnectionString' \--password='<value-of-second-Azure-primaryConnectionString>' --autoclone --placement=noneWie bereits erwähnt, lautet der Name dieses zweiten Logging Endpoints „AnotherAzureEventHubs“. Sie verweisen auf ihn in Ihrem Code, um bestimmte Ereignisse ausschließlich an das zugehörige Logging-Ziel weiterzuleiten.
Sie können die erfolgreiche Konfiguration der beiden Logging Endpoints für Ihren Compute Wasm Service bestätigen, indem Sie den folgenden Befehl ausführen:
fastly logging kafka list --version=latest --service-id=<your-Fastly-service-ID>Im Output sollten beide Endpoints, „AzureEventHubs“ und „AnotherAzureEventHubs“, nebeneinander angezeigt werden.
Für die Produktivumgebung geeignete Logs hinzufügen
Nachdem wir nun die Logging Endpoints für Ihren Wasm Service konfiguriert haben, können wir auf sie im Wasm Anwendungscode verweisen.
Als Erstes müssen wir zu unserem Rust Projekt „MyEdgeComputeApp“ die erforderlichen Abhängigkeiten hinzufügen. Suchen und bearbeiten Sie die Datei ./Cargo.toml, um die Abhängigkeiten wie folgt einzufügen:
[dependencies]fastly = "^0.8.0"log-fastly = "0.8.0"log = "0.4.14"fern = "0.6"chrono = "0.4"Die Dokumentation für log-fastly finden Sie online.
Wenn Ihr Editor mit der Programmiersprache Rust kompatibel ist, kann er diese Abhängigkeiten direkt übernehmen, oder sie werden heruntergeladen, wenn Sie das nächste Mal diese Wasm App erstellen. Hinweis: Möglicherweise haben sich die aufgelisteten Versionen der Abhängigkeiten bereits geändert, wenn Sie dieses Tutorial lesen. Vergewissern Sie sich, dass Sie immer die neuesten Versionen verwenden.
Fügen Sie innerhalb von ./src/main.rs den folgenden Initialisierungscode unter fn main(mut req: Request) -> Result<Response, Error> { hinzu:
fn main(mut req: Request) -> Result<Response, Error> { let logger: Box<dyn log::Log> = Box::new(log_fastly::Logger::builder() .max_level(log::LevelFilter::Info) .default_endpoint("AzureEventHubs") .endpoint("AnotherAzureEventHubs").build() .expect("Unable to init Fastly logger")); fern::Dispatch::new() .format(|out, message, record| { out.finish(format_args!( "{}[{}] {}", chrono::Local::now().format("[%Y-%m-%d][%H:%M:%S]"), record.level(), message )) }) .chain(logger) .apply()?;
...Suchen Sie nach der Match-Klausel "/articles" und fügen Sie darunter ebenfalls ein Log Statement ein:
"/articles" => { log::info!("Processing request to {}", req.get_path()); ...Suchen Sie die Pfad-Präfix-Match-Klausel "/anything" und fügen Sie darunter ebenfalls ein Log Statement ein:
path if path.starts_with("/anything") => { log::warn!(target: "AnotherAzureEventHubs", "Processing request to {}", req.get_path()); ...Erstellen Sie einen Build und stellen Sie Ihre Wasm App erneut bereit:
fastly compute buildfastly compute deploy --service-id=<your-Fastly-service-ID>Hinweis: Bei dieser Bereitstellung wird die neueste Version der Entwurfskonfiguration Ihres Wasm Service verwendet und aktiviert.
Stellen Sie vier oder fünf Fetch-Anfragen an https://<ihr-name>.edgecompute.app/articles und anschließend an https://<ihr-name>.edgecompute.app/anything.
Als Nächstes rufen wir die Benachrichtigungen ab, die Ihre Wasm App an die verschiedenen Azure Event Hubs Endpoints gesendet haben sollte.
Laden Sie Apache Kafka von https://kafka.apache.org/downloads herunter und entpacken Sie es, aber beachten Sie, dass wir nur den Kafka Client aus dieser Distribution verwenden werden. Die Kafka Distribution erfordert die Installation von Java auf Ihrem System, aber Sie können gerne einen anderen Kafka Client wie kafkacat/kcat verwenden und Ihre Kommandozeilen-Flags entsprechend anpassen. Nachdem Sie die Kafka Artefakte extrahiert und Ihr aktuelles Verzeichnis auf das Stammverzeichnis dieses Archivs geändert haben, ändern Sie das aktuelle Verzeichnis auf ./bin.
Erstellen Sie eine Datei, ./azure_client.properties, mit folgendem Inhalt:
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \ username="$ConnectionString" \ password="<value-of-first-Azure-primaryConnectionString>";sasl.mechanism=PLAINsecurity.protocol=SASL_SSLFühren Sie den folgenden Befehl aus, um veröffentlichte Kafka Events von Ihrer ersten Azure Event Hubs Instanz aus zu lesen:
./kafka-console-consumer.sh --bootstrap-server \<your-unique-namespace>.servicebus.windows.net:9093 \--topic MyEventHub \--consumer.config ./azure_client.properties --from-beginningIn der Antwort sollte ein Output erscheinen, die in etwa dem Folgenden entspricht:
[2021-09-16][21:00:08][INFO] Processing request to /articles[2021-09-16][21:00:08][INFO] Processing request to /articles[2021-09-16][21:00:09][INFO] Processing request to /articles[2021-09-16][21:00:09][INFO] Processing request to /articles[2021-09-16][21:00:09][INFO] Processing request to /articlesDrücken Sie zum Beenden von kafka-console-consumer.sh ^C.
Hinweis: Wenn Sie die erwarteten Benachrichtigungen (siehe oben) nicht sehen und der Output darauf hinweist, dass der Kafka Client getrennt wurde, wird möglicherweise die Konnektivität zwischen kafka-console-consumer.sh und Azure Event Hubs entweder durch die Firewall Ihres Betriebssystems oder durch die Firewall auf Ihrem lokalen Netzwerkgerät blockiert. Erlauben Sie daher bitte den Zugriff auf Port 9093 auf der Domain windows.net unter den jeweiligen Firewall-Einstellungen.
Der Zeitstempel in jeder Log-Benachrichtigung gibt den Zeitpunkt an, zu dem die Benachrichtigung erstellt wurde. Wie Sie sehen, erscheint die Log-Zeile, die wir zu unserem Rust Code für die Bearbeitung von „/articles“-Anfragen hinzugefügt haben, als Benachrichtigung in unserem ersten Azure Event Hub. Diese werden auf der Log-Ebene INFO protokolliert. Beachten Sie auch, dass wir keine Log-Benachrichtigungen im Zusammenhang mit der Bearbeitung von „/anything“-Anfragen sehen.
Erstellen Sie nun eine weitere Datei, ./another_azure_client.properties, mit folgendem Inhalt:
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \ username="$ConnectionString" \ password="<value-of-second-Azure-primaryConnectionString>";sasl.mechanism=PLAINsecurity.protocol=SASL_SSLFühren Sie den folgenden Befehl aus, um veröffentlichte Kafka Events von Ihrer zweiten Azure Event Hubs Instanz aus zu lesen:
./kafka-console-consumer.sh --bootstrap-server \<your-unique-namespace>.servicebus.windows.net:9093 \--topic MyOtherEventHub \--consumer.config ./another_azure_client.properties --from-beginningIn der Antwort sollte ein Output erscheinen, die in etwa dem Folgenden entspricht:
[2021-09-16][21:02:06][WARN] Processing request to /anything[2021-09-16][21:02:07][WARN] Processing request to /anything[2021-09-16][21:02:07][WARN] Processing request to /anything[2021-09-16][21:02:10][WARN] Processing request to /anything[2021-09-16][21:02:10][WARN] Processing request to /anythingDrücken Sie zum Beenden von kafka-console-consumer.sh ^C. Hinweis: Wir sehen keine Log-Benachrichtigungen im Zusammenhang mit der ausschließlichen Bearbeitung von „/anything“-Anfragen, die auf der Log-Ebene WARN protokolliert werden. Wir sehen auch keine Benachrichtigungen für die Bearbeitung von „/articles“-Anfragen.
Die oben beschriebene Ausrichtung auf verschiedene Logging Endpoints kann auf die Ausrichtung auf verschiedene Cloud- und Serviceanbieter ausgeweitet werden, und zwar nicht nur in Bezug auf Kafka. Sie können verschiedene Log-Benachrichtigungen eindeutig oder redundant an verschiedene Integrationsziele leiten, die unser Log Streaming unterstützt, darunter Amazon S3 Speicher, Google BigQuery, Splunk und viele andere. Die Nutzung unserer Log-Streaming-Funktion durch Compute Wasm Services versetzt Sie in die Lage, Ihre Log-Benachrichtigungen nach Absicht (wie Anomalieerkennung oder Business Intelligence) segmentiert an unterschiedliche Ziele weiterzuleiten.
Wenn Sie dieses Tutorial abgeschlossen haben, lesen Sie bitte die Dokumentation für die Azure CLI, um die bereitgestellten Ressourcen, wie beispielsweise die Ressourcengruppe, abzubauen. Der zugrunde liegende Event Hub und Event Hubs Namensraum muss möglicherweise entfernt werden, bevor die Gruppe entfernt werden kann.
Fazit
Glückwunsch! In diesem Tutorial haben Sie gelernt, wie Sie einen Compute Wasm Service konfigurieren und Ihre Rust Anwendung für diesen Service erstellen und veröffentlichen können. Außerdem haben wir uns damit befasst, wie Sie Ausgaben an STDOUT und STDERR senden und von der Command Line aus verfolgen. Zu guter Letzt haben wir Azure Event Hubs als Ziel für das Log Streaming konfiguriert, Ihre Wasm App in Rust mit formalen Log Statements aufgepeppt und die erfolgreiche Übermittlung der Logs an ihr Azure Event Hubs Ziel überprüft.
Nehmen Sie sich ruhig die Zeit, um die verschiedenen Aspekte unsererCLI, der Compute Wasm Services und unseres Log Streamings genauer unter die Lupe zu nehmen. Falls Sie Compute noch nicht nutzen, bieten wir Ihnen nur für kurze Zeit die Gelegenheit, diese Technologie selbst auszuprobieren – während einer kostenlosen dreimonatigen Test- und Konfigurationsphase und mit bis zu 100.000 US-Dollar monatlichem Guthaben für sechs Monate.
