Gibt es eine Möglichkeit festzustellen, warum Azure App Service neu gestartet wurde?

Also, es scheint, die Antwort darauf lautet: "Nein, du kannst nicht wirklich wissen warum , du kannst einfach daraus schließen, dass es getan hat."

Ich meine, Sie können einige Application Insights wie

und Sie werden mit "The application is shutting down because of 'ConfigurationChange'." oder "The application is shutting down because of 'HostingEnvironment'." enden, aber es sagt Ihnen nicht wirklich, was auf der Host-Ebene vor sich geht.

Was ich akzeptieren musste, ist, dass App Service die Dinge von Zeit zu Zeit neu startet und mich fragt, warum ich mich darum kümmerte. App Service sollte intelligent genug sein, um darauf zu warten, dass der Anwendungspool aufgewärmt wird, bevor Anforderungen an ihn gesendet werden (wie überlappendes Recycling). Dennoch würden meine Apps nach einem Recycling-Vorgang für 1-2 Minuten im CPU-Knirschen bleiben.

Es hat eine Weile gedauert, bis ich herausgefunden hatte, aber der Übeltäter war, dass alle meine Apps eine Rewrite-Regel hatten, um von HTTP zu HTTPS umzuleiten. Dies funktioniert nicht mit dem Application Initialization-Modul: Es sendet eine Anfrage an den Stamm, und alle bekommt es eine 301 Redirect von der URL-Rewrite-Modul, und die ASP.NET-Pipeline wird überhaupt nicht getroffen, die harte Arbeit war nicht t tatsächlich gemacht. App Service / IIS dachte dann, der Worker-Prozess sei bereit und sendet dann Datenverkehr an ihn. Aber die erste "echte" Anfrage folgt tatsächlich der 301-Weiterleitung zu der HTTPS-URL, und bam! dieser Benutzer trifft den Schmerz eines Kaltstarts.

Ich habe eine Rewrite-Regel hinzugefügt hier beschrieben , um das Application Initialization-Modul davon abzuhalten, HTTPS zu benötigen. Wenn es also den Root der Site erreicht, löst es tatsächlich die Seitenladung und damit die gesamte Pipeline aus:

Es ist einer von vielen Einträgen in einem Tagebuch, in dem alte Apps in Azure verschoben werden. Es stellt sich heraus, dass es eine Menge Dinge gibt, mit denen man es schaffen kann, wenn etwas auf einer herkömmlichen VM läuft, die nur selten neu startet Erarbeiten Sie die Knicke, wenn Sie in unsere schöne neue Welt in der Wolke migrieren ....

-

UPDATE 27.10.2017: Seit dieser Schrift hat Azure ein neues Tool unter "Probleme diagnostizieren und lösen" hinzugefügt. Klicken Sie auf "Web App Restarted" (Neu gestartet), und Sie erhalten den Grund dafür, normalerweise aufgrund von Speicherwartezeiten oder Upgrades der Infrastruktur. Das Obenstehende steht jedoch immer noch darin, dass beim Wechsel zum Azure App Service der beste Weg nach vorne ist, wenn Sie Ihre App nur dazu bringen müssen, mit zufälligen Neustarts vertraut zu werden.

-

UPDATE 2/11/2018: Nachdem ich mehrere Legacy-Systeme auf eine einzelne Instanz eines mittleren App-Service-Plans (mit viel CPU- und Arbeitsspeicher-Overhead) umgestellt hatte, hatte ich ein ärgerliches Problem Bereitstellungen von Staging-Slots würden nahtlos funktionieren, aber jedes Mal, wenn ich aufgrund der Azure-Infrastrukturwartung auf einen neuen Host hochgefahren würde, würde alles mit einer Ausfallzeit von 2-3 Minuten verkehren. Ich habe mich selbst in die Irre geführt, um herauszufinden, warum das passierte, weil der App Service warten sollte, bis er eine erfolgreiche Antwort von Ihrer App erhält, bevor er Sie zum neuen Host hochfährt.

Ich war so frustriert, dass ich bereit war, App Service als Enterprise-Müll einzustufen und zu IaaS-VMs zurückzukehren.

Es stellte sich heraus, dass es sich um mehrere Probleme handelte, und ich vermute, dass andere auf sie stoßen werden, während sie ihre eigenen ASP.NET-Apps in den App Service portieren. Ich dachte, ich würde sie alle hier durchgehen.

Als Erstes müssen Sie in Ihrem Application_Start wirklich arbeiten. Zum Beispiel benutze ich NHibernate, was zwar bei vielen Dingen gut ist, aber beim Laden der Konfiguration ein ziemliches Problem ist, also stelle ich sicher, dass SessionFactory während Application_Start erstellt wird, um sicherzustellen, dass die harte Arbeit erledigt ist.

Das zweite zu überprüfende Element ist, wie oben erwähnt, dass Sie keine Rewrite-Regel für SSL haben, die die Warmup-Prüfung von App Service beeinträchtigt. Sie können die Warmup-Prüfungen wie oben erwähnt von Ihrer Rewrite-Regel ausschließen. Oder, in der Zeit, seit ich diese Arbeit geschrieben habe, hat App Service ein Nur HTTPS -Flag, mit dem Sie die HTTPS-Umleitung am Load Balancer anstelle der Datei web.config ausführen können. Da es auf einer Ebene der Indirektion über Ihrem Anwendungscode gehandhabt wird, müssen Sie nicht darüber nachdenken, also würde ich das HTTPS Only Flag als den Weg empfehlen.

Die dritte Sache, die Sie beachten sollten, ist, ob Sie den Lokale App-Dienst-Cache-Option . Kurz gesagt, dies ist eine Option, bei der der App Service die Dateien Ihrer App in den lokalen Speicher der ausgeführten Instanzen und nicht in eine Netzwerkfreigabe kopiert und eine großartige Option ist, die aktiviert werden kann, wenn es Ihrer App egal ist Verliert Änderungen, die in das lokale Dateisystem geschrieben wurden. Es beschleunigt die I / O-Leistung (was wichtig ist, weil, App Service läuft auf Kartoffeln ) und beseitigt Neustarts, die durch die Wartung von Netzwerkfreigaben verursacht werden. Aber es gibt eine bestimmte Subtilität bezüglich Die Infrastruktur-Upgrades von App Service sind nur unzureichend dokumentiert, und Sie müssen wissen, dass die lokale Cache-Option im Hintergrund in einer separaten App-Domäne nach der ersten Anforderung initiiert wird und Sie dann bei der lokalen Anwendung zur Anwendungsdomäne wechseln Das bedeutet, dass der App Service eine Aufwärmanforderung für Ihre Site anfordert, eine erfolgreiche Antwort erhält, den Datenverkehr auf diese Instanz verweist, aber (hoppla!) jetzt Local Cache E / A im Hintergrund mahlt, und wenn ja Bei vielen Websites in dieser Instanz ist die App-Service-E / A-Anwendung nicht mehr funktionstüchtig. Wenn Sie nicht wissen, dass dies geschieht, sieht sie in den Protokollen unheimlich aus, weil es so aussieht, als würde Ihre App zweimal gestartet auf der gleichen Instanz (weil es ist). Die Lösung ist dies zu folgen Jet-Blogpost und erstellen Sie eine Warmup-Seite für die Anwendungsinitialisierung, um die Umgebungsvariable zu überwachen, die Ihnen mitteilt, wann Der lokale Cache ist bereit. Auf diese Weise können Sie den App-Dienst zwingen, das Starten der neuen Instanz zu verzögern, bis der lokale Cache vollständig vorbereitet ist. Hier ist eine, mit der ich sicherstellen kann, dass ich auch mit der Datenbank sprechen kann:

Denken Sie auch daran, eine Route zuzuordnen und fügen Sie die Anwendungsinitialisierung Ihr web.config :

Die vierte Sache, die Sie beachten sollten, ist, dass manchmal App Service Ihre App scheinbar aus Müllgründen neu startet. Es scheint, dass das Festlegen der Eigenschaft fcnMode auf Disabled hilfreich sein kann. Es verhindert, dass die Runtime Ihre App neu startet, wenn jemand mit Konfigurationsdateien oder Code auf dem Server beschäftigt ist. Wenn Sie Bereitstellungsslots verwenden und Bereitstellungen auf diese Weise durchführen, sollte dies Sie nicht stören. Aber wenn Sie erwarten, dass Sie in der Lage sind, mit einer Datei zu fdpd zu gehen und diese Änderung in der Produktion widerzuspiegeln, dann verwenden Sie diese Option nicht:

Die fünfte Sache, die Sie beachten sollten, und das war in erster Linie mein Problem , ist, ob Sie Staging-Slots verwenden, bei denen die Option AlwaysOn aktiviert ist. Die AlwaysOn -Option funktioniert, indem Sie Ihre Site jede Minute oder so anpingen, um sicherzustellen, dass sie warm ist, damit IIS sie nicht herunterfährt. Unerklärlicherweise Dies ist keine fixe Einstellung , also haben Sie AlwaysOn sowohl in Ihrem Produktions- als auch in Ihrem Staging-Bereich aktiviert, damit Sie sich nicht jedes Mal damit anlegen müssen. Dies führt zu einem Problem mit Upgrades der App Service-Infrastruktur, wenn sie von einem neuen Host gestartet werden. Folgendes passiert: Nehmen wir an, Sie haben 7 Websites auf einer Instanz gehostet, jede mit einem eigenen Staging-Slot, alles mit AlwaysOn aktiviert. App Service führt die Warmup- und Anwendungsinitialisierung für Ihre 7 Produktions-Slots durch und wartet pflichtgemäß darauf, dass diese erfolgreich reagieren, bevor der Datenverkehr umgeleitet wird. Dies wird jedoch nicht für die Staging-Slots verwendet. So leitet es den Traffic zu der neuen Instanz weiter, aber AlwaysOn tritt in 1-2 Minuten später auf den Staging-Slots auf, also haben Sie jetzt 7 weitere Websites starten gleichzeitig. Denken Sie daran, App Service läuft auf Kartoffeln , so dass all diese zusätzlichen I / O-Vorgänge stattfinden Gleichzeitig wird die Leistung Ihrer Produktions-Slots zerstört und wird als Ausfallzeit wahrgenommen.

Die Lösung besteht darin, AlwaysOn in Ihren Staging-Slots zu belassen, damit Sie nach einem Infrastrukturupdate nicht von diesem simultanen I / O-Rummel getroffen werden. Wenn Sie ein Auslagerungsskript über PowerShell verwenden, ist das Beibehalten dieses "Aus beim Staging, bei der Produktion" überraschend ausführlich:

Dieses Skript setzt den Staging-Slot so, dass AlwaysOn aktiviert ist, macht den Swap, so dass Staging jetzt Produktion ist, und setzt dann den Staging-Slot so, dass AlwaysOn ausgeschaltet ist Infrastruktur-Upgrade.

Sobald dies funktioniert, ist es in der Tat gut, ein PaaS zu haben, das Sicherheitsupdates und Hardwarefehler für Sie handhabt. In der Praxis ist es etwas schwieriger zu erreichen, als die Marketingmaterialien vermuten lassen. Hoffe, das hilft jemandem.