This is a viewer only at the moment see the article on how this works.
To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk
This is a preview from the server running through my markdig pipeline
Kirjautuminen on OF Course kriittinen osa sovelluksia, mutta näen sen usein väärinymmärrettynä / väärinkäytettynä ASP.NET-sovelluksissa. Tämä on osa postia ja osa manifestia siitä, miten kirjautua tehokkaasti ASP.NET-sovelluksiin.
Tämä ei ole täydellinen opas kirjautumiselle, vaan siellä on paljon ihmisiä, vaan kyse on pikemminkin tehokkaasta kirjausstrategiasta ASP.NET-sovelluksillesi.
Päähakkuiden tulisi olla käyttökelpoisia, oli se sitten kirjautumista, kun kehität tai kirjaudut tuotantoon, siitä pitäisi olla hyötyä sinulle / tiimillesi / käyttäjillesi.
Liian usein puunkorjuuta pidetään "vain silloin, kun poikkeuksia on". Mielestäni tässä ymmärretään väärin, mitä puunkorjuun pitäisi olla.
LÖYDÖINTI EI OLE KYSYMYKSIÄ
Yleisesti ottaen sinun pitäisi pystyä hoitamaan merkittävä osa sovelluksestasi paikallisesti, tässä yhteydessä log.LogInformation Hän on ystäväsi.
Olen kirjoittanut koodia 30 vuoden aikana. Olen nähnyt muutamia esimerkkejä hyvästä puunkorjuusta ja lisää esimerkkejä huonosta puunkorjuusta.
Hyvän puunkorjuun periaatteet:
Muista, että kirjautuminen aina heikentää sovellussuoritustasi. Sinun pitäisi kirjata, mitä tarvitset ongelman diagnosoimiseksi, mutta ei enää tuotannossa / missä suorituskyky on kriittinen (esim. älä tee suoritustestiä käyttäessäsi täyttä vianetsintäloggausta).
ASP.netissä on jo rakennettu hakkuujärjestelmä; Microsoft.Extensions.Logging...................................................................................................................................... Tämä on hyvä puunkorjuujärjestelmä, mutta se ei ole yhtä joustava kuin Serilog. Serilog on joustavampi puunkorjuujärjestelmä, jonka avulla voit kirjautua useisiin pesualtaisiin (tuotokset) ja rikastuttaa lokkejasi lisätiedoilla.
Tämä on kirjaus, joka tapahtuu, kun hakemuksesi käynnistyy. Se on ensimmäinen asia, joka tapahtuu, ja se on ensimmäinen asia, joka sinun pitäisi nähdä, kun teet hakemuksen. ASP.NETissä erityisesti konfiguraatiota käytettäessä on tärkeää ymmärtää, mitä tapahtuu, kun sovellus käynnistyy. Se on ASP.NET-sovelluksissa erittäin yleinen ongelmalähde.
Esimerkiksi Serilogissa voit tehdä tämän:
Log.Logger = new LoggerConfiguration()
.WriteTo.Console()
.WriteTo.File("logs/boot-*.txt", rollingInterval: RollingInterval.Day, retainedFileCountLimit: 7)
.CreateBootstrapLogger();
HUOMAUTUS: Tämä on rajoitettua, koska sinulla ei ole pääsyä kokoonpanoon tässä vaiheessa, joten esimerkiksi käyttää AppInsights todennäköisesti tarvitset #if RELEASE block to set the approach the approach the key.
Tämä antaa sinulle tietoja kaikista sovelluksessasi olevista startup-ongelmista. Se kirjoittaa sekä konsoliksi että tiedostoksi. On myös tärkeää varmistaa, että et tallenna KAIKKIa lokitiedostoja; näet tästä, että säästämme vain 7 päivän edestä lokitietoja.
Voit myös paketoida startup-menetelmäsi (tässä sovelluksessa käytän uutta Program.cs menetelmä) try/catch ja kirjata mahdolliset poikkeukset, jotka tapahtuvat siellä.
try
{
..all your startup code
}
catch (Exception ex)
{
if(args.Contains("migrate"))
{
Log.Information("Migration complete");
return;
}
Log.Fatal(ex, "Application terminated unexpectedly");
}
finally
{
Log.CloseAndFlush();
}
Loki.CloseAndFlush() on tärkeä, koska se varmistaa, että kaikki lokit on kirjoitettu levylle (sovelluksesi kaatuu niin, että muuten se poistuu ennen tätä).
Havaitsen tässä myös, onko sovellus käynnissä siirtymätilassa, ja jos on, kirjaudun ylös ja poistun.
Log.Fatal on vakavin hirsitaso; sitä käytetään, kun sovelluksesi on kaatumassa.
Kaikki poikkeukset eivät ole kohtalokkaita - sinun pitäisi käyttää Log.Error Heille (paitsi jos he tarkoittavat, että APP (ei pyyntö) ei voi jatkua tämän pisteen ohi).
ASP.NETissä (ja.NET-verkossa yleisemmin) on useita lokitasoja:
Log.Fatal - Tämä on vakavin hirsitaso; sitä käytetään, kun sovellus on kaatumassa.Log.Error - Tätä käytetään silloin, kun tapahtuu poikkeus, joka tarkoittaa, että APP (ei pyyntö) ei voi jatkaa tämän pisteen yli.Log.Warning - Tätä käytetään silloin, kun jotain sellaista tapahtuu, joka ei ole virhe, mutta josta sinun pitäisi olla tietoinen (esimerkiksi huonokuntoinen palvelu / jotain ei ihan oikein mutta ei virhe).Log.Information - Tätä käytetään yleisenä tietona siitä, mitä hakemuksessasi tapahtuu.Log.Debug - Tätä käytetään tietoihin, joista on hyötyä vain silloin, kun olet vioittamassa sovellustasi (se on EveryWHERE kehitteillä, mutta se pitäisi sammuttaa tuotannossa).Tuotantoa varten olisin yleensä asettanut puunkorjuun Log.Fatal, Log.Error sekä Log.Warning Vain.
Toisin kuin startup-rekisteröinti, tämä on hakkuri, joka tapahtuu, kun hakemuksesi on käynnissä. Tämä on hakkuri, joka kertoo, mitä hakemuksessasi tapahtuu tiettynä ajankohtana.
Esimerkiksi käyttääksesi näitä Serilogissa tekisit näin:
"Serilog": {
"Enrich": ["FromLogContext", "WithThreadId", "WithThreadName", "WithProcessId", "WithProcessName", "FromLogContext"],
"MinimumLevel": "Warning",
"WriteTo": [
{
"Name": "Seq",
"Args":
{
"serverUrl": "http://seq:5341",
"apiKey": ""
}
},
{
"Name": "Console"
},
{
"Name": "File",
"Args": {
"path": "logs/applog-.txt",
"rollingInterval": "Day"
}
}
],
"Properties": {
"ApplicationName": "mostlylucid"
}
},
Kuten näette, olen aika suuri Serilogin fani; se on hieno ja joustava puunkorjuukirjasto. Yksi asia, josta pidän siinä, on kyky rikastuttaa lokitietoja lisätiedoilla. Tästä voi olla paljon hyötyä hakemukseesi liittyvien ongelmien diagnosoinnissa. Yllä olevassa esimerkissä näet, että rikastutan lokkejani langan tunnistuksella, langannimellä, prosessitunnuksella ja prosessinimellä. Tästä voi olla paljon hyötyä hakemukseesi liittyvien ongelmien diagnosoinnissa.
Asetin myös kirjauksen menemään useisiin "sinkkuihin" (tuotteisiin); tässä tapauksessa lähetän sen konsolille, tiedostolle ja Seqille (hakkuripalvelu).
Useita pesualtaita on kätevää, jos yksi epäonnistuu, tässä tapauksessa paras puunkorjuupalveluni on Seq, joten lähetän sen sinne ensin. Jos se ei onnistu, lähetän sen konsolille ja tiedostolle.
Asetin myös ApplicationName -ominaisuuden lokiin. Tämä voi olla hyödyllistä, jos samaan palveluun on kirjautunut useita hakemuksia (mikä usein tulee levitetyissä sovelluksissa sekä vastaavuustunnus, jolla lokit sidotaan yhteen yhtä pyyntöä varten).
Esimerkiksi jos sinulla on JS-etuosa ja.NET-taustaosa, voit asettaa korreloivan ID:n etuosaan ja siirtää sen takaosaan. Näin näet kaikki lokit yhtä pyyntöä varten yhdessä paikassa. TAI jos käytät HttpClientiä backendissäsi, voit siirtää korrelointitunnuksen otsikoissa toiselle palvelulle.
Aiheesta on paljon tietoa: https://josef.codes/addrend-correlation-id-to-all-log-entries-in-asp-net-core/, mutta maksan sen myöhemmin.
Strukturoitu puunkorjuu on tapa, joka helpottaa lokkien etsintää ja suodattamista. Serilogissa voit tehdä tämän käyttämällä Log.Information("This is a log message with {Property1} and {Property2}", property1, property2); syntaksi. Tämä helpottaa tietyn kiinteistön tukkien etsintää.
Serilogin avulla voit myös käyttää LogContext.PushProperty lisätä lokiin ominaisuuksia, joilla on merkitystä vain tietyn alueen kannalta. Tästä voi olla paljon hyötyä hakemukseesi liittyvien ongelmien diagnosoinnissa.
Serilog on superjoustava siinä, että sen avulla voit määrittää sen sekä koodilla että konfiguroinnin kautta. Esimerkiksi käyttääksesi yllä olevaa kokoonpanoa tekisit näin:
builder.Host.UseSerilog((context, services, configuration) =>
{
configuration
.MinimumLevel.Warning()
.Enrich.FromLogContext()
.Enrich.WithThreadId()
.Enrich.WithThreadName()
.Enrich.WithProcessId()
.Enrich.WithProcessName()
.WriteTo.Seq("http://seq:5341", apiKey: "")
.WriteTo.Console()
.WriteTo.File("logs/applog-.txt", rollingInterval: RollingInterval.Day)
.Enrich.WithProperty("ApplicationName", "mostlylucid");
});
Tämä on sama kuin yllä olevassa konfiguraatiossa, mutta koodilla. Tämä on hyödyllistä, jos haluat kirjautua koodilla; se on todella sinusta kiinni, miten teet sen.
ASP.NETissä voit käyttää poikkeusfilttereitä poikkeusten kiinnittämiseen ja kirjaamiseen. Tämä on hyvä tapa varmistaa, että kirjaudut hakemukseesi kaikki poikkeukset. Se ei kuitenkaan korvaa menetelmätason kirjausta, vaan kirjaudut silti menetelmätasolla, jotta näet yksityiskohtaisesti, mitä sovelluksessasi tapahtuu. Poikkeussuodatin näyttää vain, mitä tapahtuu, kun koko pyyntöpino on auki ja voi usein olla hyvin hämmentävää selvittää, mitä on tapahtunut.
Tämä muuttui ASP.NET Core 8:ssa, ja näillä voit tehdä TON:n uusia piirteitä.
Vikataan uudestaan samat periaatteet; kirjaudutaan menetelmätasolla, jotta näet yksityiskohtaisesti, mitä sovelluksessasi tapahtuu. Poikkeussuodattimet / tilakäsittelijät vain näyttävät, mitä tapahtuu, kun koko pyyntöpino on auki ja voi usein olla hyvin hämmentävää selvittää, mitä on tapahtunut.
Kirjauksen tulisi olla ympäristön kannalta tarkoituksenmukaista. Kehitystyössä kirjataan kaikki, jotta näet, mitä sovelluksen jokaisessa vaiheessa tapahtuu, mutta Testissä tarvitaan vähemmän kirjauksia (ehkä lokitietoja tässä) ja tuotannossa vielä vähemmän (Varoitus ja yli).
On houkuttelevaa kirjata kaikki tuotantoon, mutta se on huono ajatus. Sinun pitäisi kirjata kaikki mitä tarvitset diagnosoidaksesi ongelman, mutta ei enää. Pilvipalvelujen tarjoajissa voit helposti veloittaa hakkuupalveluun lähettämäsi datan määrän, joten sinun kannattaa olla tarkkana siitä, mihin kirjaudut ja kuinka kauan näitä lokitietoja säilytetään (Application Insights -varastojen lokit ovat oletuksena 90 päivää; tämä on usein liian pitkä ja maksaa sinulle niin kauan kuin lokitietoja säilytetään).
Hyvin "aktiiviseen" sovellukseen et vain tarvitse pitkäaikaista tietojen kirjausta; sinulla on hyvä käsitys siitä, mitä sovelluksessa tapahtuu viime päivien lokitietojen perusteella.
Kun yleinen kysymys on tuotannossa, näen, että hakkuut epäonnistuvat, vaikka ne voivat olla mielenkiintoisia (kukaan ei halua 404 / 401), ne voivat olla valtava määrä dataa, ja ne voivat olla erittäin kalliita tallentaa. Sinun pitäisi vain kirjata asioita aiot korjata, 404 voi olla, että tämä on tärkeää, koska se voi osoittaa rikkinäisen linkin hakemuksessasi; 401 voi olla, että tämä on tärkeää, koska se voi kertoa rikkoutuneesta tunnistusjärjestelmästä.
Kuten edellä mainitsin, näitä käsitellään paremmin koodissa, jossa ne todellisuudessa esiintyvät (401). Warning tai Error Koodissa, joka itse asiassa tuottaa 401.
Serilogiin kirjautumiseksi voit tehdä tämän:
app.UseSerilogRequestLogging();
Tämä kirjautuu hakemukseesi kaikki pyynnöt; se on hieno tapa nähdä, mitä hakemuksessasi tapahtuu korkealla tasolla, mutta jälleen on syytä olla varovainen sen suhteen, mitä kirjaat ja kuinka kauan säilytät näitä lokitietoja.
Application Insights -palvelussa voit silti haluta kirjautua tietotasolle, koska se antaa sinulle näppärän käyttäjämatkaominaisuuden. Tämä on hyvä tapa nähdä, miten käyttäjät käyttävät sovellustasi ja voivat olla erittäin hyödyllisiä diagnosoitaessa ongelmia. Kuitenkin nämäkin nousevat nopeasti, joten kannattaa olla tarkka siitä, mihin kirjaudut ja kuinka kauan säilytät näitä lokitietoja.
Siinä kaikki, nopea läpikäynti siitä, miten kirjaudutaan ASP.net-sovelluksiin. Suuri osa siitä on reaktio yli-innokkaisiin, hyödyttömiin lokkeihin, joita näen monissa tuotantosovelluksissa. Kehitystyössä haluat nähdä miten sovellus kulkee; tuotannossa haluat nähdä miten sovellus epäonnistuu. Metsästäminen on liian usein hyödytön ja kallis osa sovelluskehitystä. Kuten kaikessa ohjelmistokehityslokituksessa tulisi keskittyä USR:ään, oli se sitten sinä tai muut kehittäjät IDE-sovelluksessa / paikallisesti työskennellessäsi tai selvittämässä tuotannon ongelmia nopeasti ja tehokkaasti.