Die verskil tussen middelmatige produkte en wonderlike produkte is om te log. Lees waarom dit so is, en hoe om dit alles saam te bind.
Net soos sekuriteit, is aanmelding 'n ander belangrike onderdeel van webtoepassings (of toepassings in die algemeen) wat gekantel word weens ou gewoontes en die onvermoë om vooruit te sien. Wat baie mense sien as nuttelose digitale band, is kragtige instrumente om in u toepassings te kyk, foute reg te stel, swak gebiede te verbeter en kliënte te verheug..
Voordat ons met gesentraliseerde houtkap begin, moet ons eers kyk waarom dit so 'n groot probleem is om aan te meld.
0.1 Twee tipes (vlakke) houtkap
0.2 Teken is krag
0.3 Bly voor die kliënt
Twee tipes (vlakke) houtkap
Rekenaars is deterministiese stelsels, behalwe as dit nie so is nie.
As 'n professionele ontwikkelaar, Ek het in baie gevalle teëgekom waar die waargenome gedrag van die app almal dae lank aan bande gelê het, maar die sleutel was altyd in die logboeke. Elke sagteware wat ons gebruik, produseer (of moet ten minste genereer) logboeke, wat ons vertel wat dit deurgemaak het toe die problematiese situasie plaasgevind het..
Teken, soos ek dit sien, is nou van twee soorte: Outomaties gegenereerde logs en -Programmeerder gegenereer logs. Let daarop dat dit nie 'n onderskeid tussen die handboeke is nie, en as u my aanhaal oor hierdie terminologie, sal u in die moeilikheid beland. ��
Die afbeelding hierbo toon wat as 'n 's' genoem kan word outomaties gegenereerde log.
In hierdie spesifieke geval is dit 'n WordPress-stelsel wat 'n onverwagse toestand ('n kennisgewing) aanteken as u 'n PHP-kode gebruik. Logs soos hierdie word deurgaans onvermoeid gegenereer – deur databasishulpmiddels soos MySQL, webbedieners soos Apache, programmeertale en omgewings, mobiele toestelle en selfs bedryfstelsels.
Dit bevat selde baie waarde, en programmeerders hoef nie eens die moeite te doen om dit na te gaan nie, behalwe as iets verkeerd gaan. Op sulke oomblikke grawe hulle diep in die houtblokke en probeer verstaan ​​wat verkeerd geloop het.
Maar outo-gegenereerde logboeke kan net soveel help. As 'n aantal mense byvoorbeeld administratiewe toegang tot 'n webwerf het, en een daarvan die geval is om 'n belangrike inligting uit te vee, is dit onmoontlik om die skuldige op te spoor met die gebruik van outo-gegenereerde logs. Vanuit die perspektief van die stelsels wat as die toepassing saamgebind is, was dit net nog 'n dag in die baan – iemand het die nodige gesag gehad om 'n taak uit te voer, en die stelsel het dit dus uitgevoer.
Wat hier nodig is, is 'n ekstra laag eksplisiete, uitgebreide houtkap wat roetes skep vir die menslike kant van dinge. Dit is wat ek noem programmeerder-gegenereerde logboeke, en dit vorm die ruggraat van sensitiewe bedrywe soos bankwese. Hier is 'n voorbeeld van hoe so 'n aanmeldskema kan lyk:
Teken is krag
Dus, gegewe hierdie twee soorte logs in 'n stelsel, is dit hoe u dit kan gebruik en die impak kan verhoog.
Bly voor die kliënt
'Klantgenot' het bekend gestaan ​​as 'n nuttelose bemarkings-gimmick, maar danksy aanmelding kan dit baie werklik gemaak word. Ek weet van digitale produkte wat hul logboeke soos 'n valk monitor, en sodra 'n kliënt iets op die bladsy breek, kan hulle die kliënt skakel en aanbied om te help.
Dink net daaraan – binne sekondes nadat u 'n lelike fout gekry het, kry u 'n oproep van die onderneming wat sê: 'Haai, ek verstaan ​​dat u hierdie item in die waentjie probeer voeg het, maar dit het aanhou sterf. Is dit goed dat ek hierdie keer byvoeg en die bestelling vir u voltooi? "
Verheug kliënt? Jy wed!
Span moraal en produktiwiteit
Soos ek al voorheen gesê het, as die foute vir 'n lang ruk onbewaak word, raak die ontwikkelaars in u span gefrustreerd en verloor hulle meer en meer tyd om hul sterte na te jaag. En hier is die ding met ontfouting – dit verg van die begin af 'n vars, nuuskierige gedagte. As 'n WTF soveel gedink het as wat u brein binnedring, gaan die hele proses van die hand.
En wat maak ontfouting moeilik? In my ervaring, 'n gebrek aan houtkap, of 'n gebrek aan kennis van houtkap. Vir die begin, sal u dalk nie besef dat u gunsteling databasis ook net nog 'n stuk sagteware is wat logs genereer nie, of dat u nie breedvoerig in u aansoek aanteken nie (sien logboeke wat deur programmeerder gegenereer word hierbo).
Ek onthou veral 'n geval waar die aansoek reageer, en niemand geweet het hoekom nie. 'N Paar dae later was die skuldige die I / O-limiet op die skyf weens oormatige verkeer. Omdat niemand die moeite gedoen het om daar te kyk nie, kon niemand agterkom hoekom nie.
Wat nou as u kliënt twee jaar later sê dat al die bestellings nie deur hulle geplaas is nie, maar deur een of ander hacker?
Watter argument sal hul versoek moet vermaak of verwerp? As u uitgebreide registrasie het (IP-adres, datum en tyd, kredietkaart, ens.), Kan u dit alles ontleed en tot 'n besluit neem. Goed of sleg, dit sal ten minste 'n objektiewe basis hê, eerder as om in die donker te lyk.
Dieselfde geld as u onder een of ander regulatoriese lens kom of as u 'n derdeparty-oudit moet ondergaan as deel van 'n nuwe, belangrike projek. As u nie 'n robuuste houtstelsel het nie, sal u in 'n slegte lig sien.
Verbetering van bestaande stelsels
Hoe kan u te werk gaan om 'n huidige stelsel te verbeter??
Moet u bloot meer RAM- en CPU-drade daarop gooi? Wat as u app stadig is ondanks genoeg bronne? Waar is die bottelnek? Logging is die antwoord meer gereeld as nie.
Byvoorbeeld, al die belangrikste databasisstelsels het 'n funksie om aan te meld stadige navrae.
As u die stadige navraaglogboek gereeld besoek, sal u weet watter bewerkings die meeste tyd neem, en dus klein maar belangrike gebiede wat werk nodig het, ontdek. Dikwels werk 'n klein verandering soos hierdie beter as om die hardeware se kapasiteit te verdubbel.
U kan nie tel hoeveel maniere 'n goeie aanmeldstelsel u help nie. Miskien is die beste argument dat dit 'n outomatiese aktiwiteit is wat eenmaal opgestel is, geen monitering nodig het nie, en dat u die een of ander dag sal verwoes..
Laat ons kyk na enkele van die ongelooflike open source-logversamelaars (verenigde houtkapinstrumente) daar buite. In geval u dit wonder, het ons in 'n vroeëre pos kommersiële loggebaseerde log-gereedskap gedek.
Graylog is een van die voorste name in die industrie as dit kom by die aanmeld- en visualiseringsvermoëns van die industrie. Dit is ook uniek in die sin dat dit u versamelde logboeke skandeer vir tekens van sekuriteits kwesbaarhede en u onmiddellik in kennis stel.
Terwyl Graylog 'n gesentraliseerde aantekeningstelsel is, het dit die buigsaamheid wat u benodig, waardeur u waarskuwings, dashboards en meer kan aanpas.
Greylog is oop bron, maar daar is 'n ondernemingsplan as u behoeftes ingewikkeld is.
Met kliënte soos SAP, Cisco en LinkedIn op die puntelys, is Graylog 'n instrument waarop u met u oë toe kan vertrou.
As u 'n aanhanger of gebruiker van die Elastic-stapel is, Logstash is die moeite werd om na te gaan (die ELK-stapel is al 'n ding, ingeval jy nie daarvan geweet het nie). Soos ander log-gereedskap op hierdie lys, Logstash indien volledig oop bron, waardeur u die vryheid kan gee om te gebruik en te gebruik soos u wil.
Maar moenie mislei word nie: Logstash is 'n moederskip met vermoëns wat swaarder weeg as enige nederige houtkapinstrument. Dit is in staat om groot hoeveelhede data van verskeie platforms te versamel, dit stel u in staat om u eie datapypleidings te definieer en uit te voer, sin te maak vir ongestruktureerde log-dumps en meer.
Die enigste beperking is natuurlik dat dit slegs met die Elastic-reeks produkte werk, maar as u binnekort begin skaal, is Logstash die manier om te gaan!
Onder gesentraliseerde houtkapinstrumente wat werk as 'n middellaag vir die inname van data, Flutend is 'n eerste onder gelykes. Met 'n uitstekende biblioteek met plugins, kan Fluentd data vanaf feitlik enige produksiestelsel opneem, dit in die gewenste struktuur knie, 'n pasgemaakte pypleiding bou en dit na u gunsteling analitiese platform voer, of dit nou MongoDB of Elasticsearch is..
Fluentd is gebou op Ruby, is heeltemal oop bron, en is ekstensief gewild vanweë sy buigsaamheid en modulariteit.
Met groot maatskappye soos Microsoft, Atlassian en Twilio wat die platform gebruik, het Fluentd niks om te bewys nie. ��
As dit regtig is, is regtig groot datastelle jou uitdaging, en jy wil uiteindelik alles in iets soos Hadoop voer, Flume is een van die beste keuses rondom. Dit is 'n "suiwer" open source-projek, in die sin dat dit deur ons geliefde Apache-stigting onderhou word, wat beteken dat daar geen ondernemingsplan is nie.
Dit is of nie wat u presies soek nie. ��
Flume se bronkode is geskryf in Java (wat my steeds verbaas as dit by baanbrekende tegnologie kom) oop. Flume is die beste vir u as u op soek is na 'n verspreide, fouttolerante data-inname-platform vir swaar dinge.
Ek gee dit nul uit tien vir naamgewing van produkte, maar Octopussy kan 'n goeie keuse wees as u behoeftes eenvoudig is en u wonder waaroor al die ophef rakende pypleidings, inname, samevoeging, ens. gaan..
Na my mening dek Octopussy die behoeftes van die meeste produkte daar buite (geskatte statistieke is nutteloos, maar as ek moes raai, sou ek sê dit sorg vir 80% van die gebruiksgevalle in die regte wêreld).
Octopussy het nie 'n uitstekende UI nie (sien hier) hoegenaamd nie, maar dit maak voorsiening vir spoed en gebrek aan opblaas. Die bron is beskikbaar op GitHub, soos verwag, en ek vind dit die moeite werd om 'n ernstige blik op te stel.
LOGalyze was 'n kommersiële produk wat onlangs open source gemaak is. Alhoewel ek nie die projek op GitHub kon doen nie, maak hulle tog 'n Windows-installeerder en alle bronkode af te laai.
As u 'n gemeenskap wil hê, kan u besonderhede van 'n e-poslys vind hier.
LOGalyze is 'n betreklik buigsame en kragtige aanbod wat goed kan werk vir ontplooiing van enkelstelsels wat poog om logs vanaf bekende bronne soos Postfix, Apache, ens. Te kombineer, en die uitvoer in CSV, PDF, HTML of soortgelyke formate te lewer. Ja, dit doen nie alles nie, maar omdat dit op 'n keer 'n kommersiële produk was, doen dit dit nogal goed.
As dit kom by die keuse van 'n instrument vir die werk, het ek twee kriteria: dit moet gefokus wees, en dit moet ondersteun word deur 'n aktiewe sakemodel. Die probleem met open source sagteware is oor die algemeen dat die kans op stagnasie of die dood 'n paar maande / jare onderweg groot is. Daar is geen telling op hoeveel houtkapgereedskap met gusto bekendgestel is nie, maar nou net in die GitHub-begraafplaas te vinde.
Gemeet aan hierdie maatstaf, LogPacker is 'n gunsteling vir my.
Soos u op die skermkiekie kan sien, gaan LogPacker oor logs en niks anders nie. Hulle stoot beslis na hul wolkaanbiedinge, maar u is welkom om dit op u bedieners af te laai en te installeer (GitHub-bladsy hier).
Groepering en samevoeging is beskikbaar vir diegene wat dit op 'n nie-triviale skaal wil gebruik, en ondernemingsplanne is beskikbaar wat met die API wil werk of groter ontplooiings benodig. Na my mening is 'n verfrissende minimalistiese (gefokusde, hoewel nie funksionele swak) logbestuur nie!
Ek is seker daar is onder ons wat nie die seremonie wil hê wat verband hou met 'n "verenigde," "gesentraliseerde" aanmeldstelsel nie. Hul besigheid kom van enkelbedieners, en hulle is op soek na iets vinnig en doeltreffend om na hul loglêers te kyk. Wel, sê hallo vir Logwatch.
Sodra dit geïnstalleer is, kan LogWatch u stelsellogboeke skandeer en 'n verslag skep van die tipe wat u wil hê. Dit is 'n ietwat gedateerde stuk sagteware (lees 'betroubaar') en is in Perl geskryf. U sal dus Perl 5.6+ op u bediener benodig om dit te laat loop. Ek het geen skermkiekies om te deel nie, want dit is 'n suiwer opdragreël, gedemoniseerde proses.
As jy 'n CLI-junkie is en 'n voorliefde het vir die ou skool manier van dinge doen, sal jy lief wees vir Logwatch!
Die Syslog-ng instrument is ontwikkel as 'n manier om syslog ('n gevestigde kliënt-bedienerprotokol vir stoorlogvorming) datalêers intyds te verwerk. Met verloop van tyd het dit egter gekom om ander dataformate te ondersteun: ongestruktureerd, SQL en NoSQL. Hoe die syslog-protokol werk, word in die volgende illustrasie mooi opgesom.
syslog-ng is 'n betroubare versameling- en klassifiseringshulpmiddel vir produksie-grade wat in C geskryf is en al lank 'n gevestigde naam in die bedryf is. Die beste deel is die uitbreiding daarvan, waardeur u plugins in C, Python, Java, Lua of Perl kan skryf..
Verkort (Log Navigator), lnav is 'n suiwer terminale instrument wat op 'n enkele gids werk. Dit is vir diegene wat hul aanmelding in 'n enkele gids verenig het, of wat intydse logboeke uit 'n enkele bron wil filter en vertoon.
As u gedink het dat lnav niks anders is as verheerlikte stert | grep nie, sou u verkeerd wees. Daar is verskillende funksies waarmee u verlief kan raak op die tydreeks: mooi drukwerk (vir JSON en ander formate), kleurgekodeerde logbronne, kragtige filters, die vermoë om verskillende protokolprotokol te verstaan, en meer.
Dit is net so dat u soms 'n nul-moeite, 'n nul-opstelling, miskien 'n tydelike aanmeldlaag wil hê, en dat dit perfek pas by die rekening!
En daar het jy dit!
Dit was 'n moeilike lys om op te stel, om eerlik te wees, aangesien die aanmelding nie so gewild is soos, byvoorbeeld, inhoudsbestuur nie, en dit blyk dat al drie of vier instrumente aangepak is. Tog is almal se behoeftes verskillend, en ek het probeer om hulle breedvoerig te dek.
Van dwase opdragreël, geen instellingsinstrumente tot volwaardige data-juggernauts, dit is alles hier! Het ek iets gemis? Natuurlik het ek dit gedoen! Laat weet my asseblief in die kommentaar, en ek sal dit graag hier byvoeg (met krediete natuurlik!).