Obsah:
Od zaměstnanců Techopedia, 9. května 2016
Take away : Host Eric Kavanagh rozhovory s Markem Madsenem, Dez Blanchfieldem a Bullett Manaleem o latenci a výkonu.
Momentálně nejste přihlášeni. Chcete-li zobrazit video, přihlaste se nebo se zaregistrujte.
Partner obsahu Techopedia
Zaměstnanci Techopedia jsou spojeni se společností Bloor Group a lze je kontaktovat pomocí možností na pravé straně. Informace o tom, jak spolupracujeme s průmyslovými partnery, najdete zde.- Profil
- webová stránka
Eric Kavanagh: Dámy a pánové, ahoj a vítejte zpět v Hot Technologies! Ano vskutku! Jmenuji se Eric Kavanagh, toto je naše přehlídka Hot Tech, partnerství s našimi dobrými přáteli z Techopedia. Hop online na Techopedia.com pro všechny nejnovější v široké oblasti podnikových technologií; samozřejmě také pokrývají spotřební věci. Zaměřujeme se na podnik zde na našem programu, takže to budeme dělat dnes.
Je tu místo o vás opravdu a dost o mě, zasáhli mě na Twitteru @eric_kavanagh, miluji Twitter, miluji kontrolu těchto věcí, je to skvělý způsob, jak zůstat v kontaktu s lidmi a mít dobré konverzace a jednorázové jediné konverzace.
O čem tedy mluvíme? Tento rok je horký, je to celý vesmír příležitostí, na který se dnes díváme ve světě správy informací, a to, o čem dnes hovoříme, bude dotazy, zrychlení dotazů.
Myslím, že jsem zapomněl zmínit název „Performance Play: Say Goodbye to Latency.“ Kdo chce latenci? Nikdo nechce latenci, latence je, když tam sedíte, kliknete na tlačítko a počkáte, až se něco stane, a nikdo to nechce. Děti se to nelíbí, nemyslí si, že je to super, ani dospělí. Všichni jsme zkaženi rychlostí webu a my chceme věci rychle, chceme věci hned a o tom dnes budeme mluvit na naší show.
Analytik Mark Madsen je dnes s námi z Third Nature, jednoho z našich pravidelných. Náš nový datový vědec, Dez Blanchfield, volající ze Sydney v Austrálii. A pak Bullett Manale, ano, vlastně to je jeho jméno, ve skutečnosti by to měla být dvě T. Bullett Manale je na, protože náš host z Idery, velmi, velmi zajímavé společnosti, dělá spoustu věcí. Už o nich vím, jedním z nich bylo, že si koupili společnost s názvem Precise. Znal jsem jejich generálního ředitele Zohar Gilad, jak je to jméno? Byl to jeden sakra chytrého chlapa.
Ale lidé, hrajete významnou roli v tomto webcastu v otázkách, které se ptáte, takže se nemusíte stydět, posílat své dotazy kdykoli - můžete tak učinit pomocí komponenty Q&A webové konzole, která je tam dole v pravém dolním rohu. Můžete mi také povídat a já si to promluvím s reproduktory. Už máme někoho, kdo volá z Itálie, takže „Ciao, ciao. Pojď stai? “Dobře, s tím, že budu tlačit Markovu první linii, jdu předat balíček Markovi. Mark, nyní máte WebEx. Vezměte to pryč, podlaha je na vás.
Mark Madsen: Díky, Ericu. Nezačnu však uprostřed, začnu od začátku. Takže jen pár komentářů k zahájení diskuse s Dez a Iderou, jakýsi stav státu s vývojem, databázemi a operacemi. A víte, pokud se na to podíváte, máme na trhu databází a aplikací stále tyto dva problémy na světě, protože vývojáři považují DBA za lidi, kteří je hádají. Musíte vytvořit datové modely, k nim nemáte přístup, nemůžete vytvořit tu věc, nemůžete umístit index do každého sloupce každé tabulky v databázi, aby byl rychlejší. A samozřejmě, proč potřebujeme modely? Jsou to jen datové struktury, pokud je změníme, nemůžete je jednoduše napsat v serializované podobě?
Problém je v tom, že vývojáři znají kód a aplikace, ale dvě věci, které často neznají, jsou souběžnost, souběžné programování a databáze a operační systémy pod nimi. Když jsem byl vývojářem jádra a operačními systémy a databázemi, mohu říci, že souběžnost a paralelismus jsou opravdu těžké, a tak se spousta věcí, které se naučíte získat dobrý výkon z vašeho kódu, začne opravdu rozpadat, když jste práce s databází. A výkon vypadá skvěle, testovací prostředí vypadá skvěle a prostředí Q&A, a pak zasáhne skutečný systém a najednou to není tak skvělé. Protože je mnohostranný, jak kód pracuje s databází, jak pracuje s prostředím a opravdu jednoduché postupy mohou mít drastické efekty v závislosti na tom, jaké měřítko používáte.
A když začnete mluvit o externích aplikacích, samozřejmě, navenek orientované aplikace, webové aplikace, mohou být opravdu obtížné, protože věci jsou skvělé, až najednou narůstají a nejsou. Zasáhnete tyto zajímavé plošiny, které vyžadují hodně nuance, abyste porozuměli.
Druhou věcí je pohled DBA. Názor DBA je, že existují operace, tráví většinu času, 80 až 90 procent, v ops a možná 10 až 20 procent se zabývají vývojem, který se děje předem. Z tohoto pohledu buď platíte nyní, nebo platíte později, a pokud trávíte veškerý čas předem, pak budete mít mnohem lepší šanci později, na rozdíl od vývoje, který má tendenci zkoumat funkci prostoru a snaží se zjistit, jak nejlépe dělat věci. Máme tedy problémy a nyní máme nekompatibilní metodiky - nepřetržité nasazování, rozbalování vašich aplikací, kdykoli jsou připraveny, pravidelné provádění kódu, práce v obchodě, který praktikuje dev ops. Tato věc urychluje vývoj, ale všechny praktiky v databázi a to, co DBA dělají a co systémoví manažeři byli vyškoleni, IT operace nezachovávaly tempo.
Pokud o tom přemýšlíte, většina databází DBA pracuje v prostředí pro řízení změn oproti prostředí pro nepřetržité nasazení. Je to všechno o stabilitě a kontrole, versus rychlost změn a reverzibilita. Neustálé nasazení, pokud se nemůžete vrátit ze změn, máte potíže, takže všechno musí být postaveno tak, aby bylo snadno reverzibilní a přepínatelné kódem, což není způsob, jakým fungují relační databáze, vývojové postupy a postupy správy. .
Také se setkáváte s těmito problémy, že musíte být aktivnější, pokud jako DBA můžete, protože v době, kdy uslyšíte o problému, vyplní stovky tisíc lidí na vašem webu stížnosti. To vás nechá potřebovat nějaké nové věci, které nevystoupíte ze svého starého prostředí. Víte, věci jako lepší monitorování a varování. Zároveň se databáze množí, máme více aplikací než kdy jindy, abychom podporovali více věcí než kdy jindy, jsou uvnitř, jsou venku, jsou všude. A čím více nezávislých sad dat pro analýzy, lidé začínají s databázemi po celém světě, protože teď je samozřejmě snadné, můžete si nastavit virtuální stroj. Pokud máte poskytovatele cloudu nebo interního cloudu, můžete věci okamžitě zobrazit a to změní vaši celou cestu nákupu.
Stará cesta zadávání veřejných zakázek byla: „Mám čas na to, abych získal server, strčil ho do stojanu, přidělil prostor, získal úložiště, nainstaloval databázi a dělal věci, “ versus někdo přejel kreditní kartou a odešel za pět minut. Pokud tak učiníte, moderní vývojové prostředí pracuje tempem, které je velmi odlišné, a proto je snadné vytvářet databáze a to jen vytváří tento problém proliferace, jako nic, co jsme předtím neviděli. A to se děje již deset let, to není nikomu nic nového, ale také to znamená, že operační prostředí rostla ve složitosti.
Celé prostředí klientského serveru se opravdu změnilo, protože už to není svět klientských serverů. Tehdy jste měli server, měli jste databázi, pokud jste něco špatně věděli, na který server jít, věděli jste, jak na něm spravovat zdroje, protože nejlepší praxí byla jedna databáze, jeden server. Virtualizace to začala rozpadat, cloud ji rozbila ještě více, protože to, co si myslíte, že je databázový server, je jen software. Prostředí tedy není skutečné. Je to to, co obsahuje prostředí, které je realitou, a může to být regál lopatek nebo velký server vyřezaný na kousky, to opravdu nevíte.
Vše kolem správy databází a správy výkonu a jaké databáze byly vytvořeny na základě přísné kontroly s jedním serverem nebo hrstkou serverů a několika databází, nemůžete ovládat všechno. Sedíte tam na počítači, ale šířku pásma nelze snadno rozdělit pomocí virtuálních manažerů, takže všechno může být v pořádku s pamětí a CPU, ale jste omezeni na nějaký zdroj, který nelze řešit, a pak, když pokusíte se to opravit, starý model by byl v tvrdé práci, získat větší server a udělat něco takového, nyní by to mohlo být opravdu jednoduché, stačí přidat virtuální kurz, stačí přidat paměť do VM a je to vyřešeno. Co se však stane, pokud je váš VM na přeplněném serveru a potřebuje migrovat? Nebo co se stane, pokud máte velikost systému AWS a byla dosažena maximální velikost, kam se teď vydáte?
Takže máte všechny tyto problémy, kde je nyní prostředí součástí databáze, zabalíte prostředí do databáze, všechny speciální prostředky, vše v aplikaci, která je součástí konfigurace, konfigurace se odtlačí ven. Toto je z databázového prostředí, je mnohem těžší spravovat a ovládat.
Pokud se podíváte na to, co databázová centra dělala, seděli na svých rukou, že? Od této myšlenky léčby databází a serverů, jako jsou domácí mazlíčci, jsme se vzdálili. Servery mají jména, zachází s nimi jako s individuálně jedinečnými věcmi, zachází s nimi jako s dobytek, řídí stádo. A problém se správou stád spočívá v tom, že pokud je neovládáte, mohou nakonec upadnout, a zbabělec není dobrá věc. Potřebujeme lepší monitorovací nástroje, potřebujeme lepší způsoby, jak se s těmito věcmi vypořádat, a vědět, co bylo ovlivněno. Ve starém modelu to bylo snazší, protože vám to pověděly vaše operační systémy a všechny vaše řídicí systémy, ale když je název vašeho serveru kód UPC, je těžké něco vymyslet.
Nemůžete si dovolit falešná upozornění, nemůžete si dovolit věci, které říkají: „S tímto strojem je problém a stroj hostuje 30 databází.“ Nemůžete si dovolit, aby vám věci nedaly žádnou historii. Monitorovací konzole jsou skvělé, když se rozsvítí, ale pokud se červené světlo znovu rozsvítí zeleně a nevíte proč, a nemáte historii, abyste se mohli vrátit zpět k tomu, co vedlo k tomu a co kontext byl, máte potíže. Potřebujeme systémy, které pro nás budou sledovat, potřebujeme lepší monitorování, které řeší občasné přerušované problémy, které udržují tuto historii dat.
Lepší věci a jednoduché prahy metrik, které nám poskytují klíčové metriky, ale nevedou nás přímo k tomu, co je normální, co je neobvyklé a jak často se tyto problémy vyskytují. O čem opravdu mluvíme, je kombinace monitorovacího prostředí a jednání s výkonem a prodejci seděli na svých rukou. Nedali nám lepší nástroje. Máme systémy s větším počtem CPU a paměti, než víme, co s tím se vším, a přesto se stále spoléháme na modely ručních zásahů, stroj jsme neuváděli do provozu, aby nás vedl, aby nás nedostal k problémům, nedostali jsme se k tomuto novému stylu, který je: „Je zde problém, můžete to opravit, “ nebo „Je tu problém s výkonem, je to vlastně s tímto konkrétním příkazem SQL, zde jsou tři věci, které byste mohli použijte k opravě tohoto příkazu SQL. “Použití heuristiky, použití modelů strojového učení, které se mohou podívat na vzorce využití vašeho systému, aby zjistily problémy a vyhnuly se falešným upozorněním. Použití stroje k tomu, co dělá stroj nejlépe, k posílení DBA nebo k posílení osoby, která se musí vypořádat s problémy s výkonem.
To je nový způsob, na rozdíl od starého stylu. Existuje problém s touto databází, věci jsou pomalé, a proto máme nové techniky, nové způsoby, jak to udělat, a měli bychom je používat, a to je místo, kam směřuje trh. Vidíte, že se to začíná objevovat, ne u velkých prodejců, ale u společností třetích stran, a to odráží něco, co se stalo před 20 lety, když dodavatelé databází neposkytli jednu věc, která by pomohla spravovat systémy. Takže to je jaký je směr trhu, a tím bych ho chtěl vrátit zpět Ericovi.
Eric Kavanagh: Dobře, předám to Dezovi. A Dez, vezmi to pryč, podlaha je tvoje.
Dez Blanchfield: Děkuji, Marku. Odvedli jste fantastickou práci na pokrytí jeho technické složky. Jdu na to z trochu jiného úhlu, abych zdůraznil, co se stalo ve zbytku světa, pokud jde o dopad na podniky a databáze kolem nich. Dovolte mi jen skočit na můj první snímek.
Na zadní straně toho, co jste právě pokryli z technické stránky věcí a vývojářské stránky věcí, vidím podniky, které musejí čelit zejména výzvě dat a databází, a samozřejmě jsme zaznamenali tento významný posun směrem k Tento koncept velkých dat, ale databáze jsou stále srdcem a duší toho, kde si organizace uchovávají své obchodní informace, a to od předních dveří až po back office. Každá část organizace se dotýká databáze nějakého druhu a je poháněna databází, a velmi zřídka chodím do diskusí o projektu nebo do nějaké formy inovativního strategického rozhovoru v organizaci, kde je téma databáze nebo databázového systému. nepřichází a vždy existují otázky týkající se typů věcí, které jsme právě slyšeli, co se týče výkonu a bezpečnosti a jak vývoj přichází k této výzvě a kam se databáze hodí, a naše znalosti prostředí a aplikací prostředí, se kterými mluvíte, co zařízení a mobilita?
Je to stále velmi, velmi žhavé téma a bylo to jedno po dlouhou a dlouhou dobu ve velkém schématu věcí, pokud jde o moderní technologie. V tomto ohledu se domnívám, že je to fakt, že téměř všechno, co děláme v našem každodenním životě, v našem každodenním životě, to znamená, že je nyní podporováno nějakou formou databáze. Když přemýšlíme o všech věcech kolem nás, ať už jde o účet, který přichází každý den v poště za nějakou službu, kterou kupujeme, nevyhnutelně je vytištěn systémem, který mluví do databáze, a jsme tam. Naše telefony mají v nich databáze s kontakty a záznamy hovorů a dalšími věcmi.
Kamkoli jdeme, za řečí a systémy, které používáme, existuje určitá forma databáze, a častěji než ne, jsou pro nás celkem transparentní, ale faktem je, že jsou tam. Takže jsem si myslel, že bych se rychle zabýval tím, proč se to stalo ve velmi krátké době trochu problémem. Zpočátku koncept databáze pocházel od tohoto krásného pána, Edgara Codda. Při práci v IBM změnil svět, pokud jde o správu dat, vytvořením konceptu, který nyní označujeme jako relační databázi.
Zpočátku byla databáze databáze a život byl dobrý, byl docela přímočarý jak ve sloupcích, v referencích atd., Tak v tabulkách a vývoj softwaru byl docela jednoduchý a výkon nebyl ve skutečnosti tak velkým problémem - byla to nová vzrušující technologie. Do databází jsme vstoupili prostřednictvím nějaké formy terminálu a na konci terminálu 3270 na mainframe můžete opravdu vytvořit tolik chaosu, a vždy další typy terminálů, tyto další systémy přišly. A ve většině případů byly terminály ve starém stylu velmi podobné současným webovým prostředím, a to je to, že byste vyplnili formulář na obrazovce na samotném terminálu a stiskli Enter a vypnuli by to, bylo by to vystřelit jako jeden paket, jako žádost, a back-end systém by se s tím vypořádal. To je v zásadě to, co se děje ve webovém prohlížeči v těchto dnech, když do webového prohlížeče zadáte odkaz a ten formulář se obvykle nevrací v reálném čase zpět do systému, ačkoli u AJAX v těchto dnech to není úplně pouzdro.
Ale pak se něco stalo, budoucnost dorazila, a nedávno internet, a téměř včera, v sec web 2.0, a hned za rohem máme internet věcí. A v procesu budoucího dění svět databází právě explodoval a interakce s databázemi se prostě staly věcí, kterou jsme všichni ve výchozím nastavení udělali, nebylo to tak, že byste šli někam něco udělat, například koupit lístek do letadla a chtěl cestovat na druhou stranu planety, někdo musel do terminálu zadat všechny vaše údaje a jít do databáze a vytisknout si lístek.
Téměř vše, co nyní děláme, ať už volá Google s kabinou s aplikací, ať už jde o skákání na internetovém bankovnictví, všechno, co děláme každý den, s nějakým druhem systému, je poháněno databází. A když internet přišel, bylo to o něco jednodušší přivést nás, náš každodenní život prostřednictvím webového prohlížeče a poté se objevil web 2.0 a věci se staly mobilními a rozsah věcí právě explodoval. Ve skutečnosti můj oblíbený řádek v tomto tématu je, že „Internet připojil vše, web 2.0 z něj učinil mobilní a sociální a věci se staly velmi, velmi velkými a nyní máme internet a věci a, a IoT… Yikes !!“ Ještě jsme si ani nezačali představit dopad internetu věcí na svět databázových systémů.
Takže v moderním smyslu se to, co jsme si mysleli jako terminál, skutečně stalo těmito věcmi, jsou to mobilní telefony, jsou to různé druhy tablet, buď osobní spotřebitelské nebo podnikové velkoplošné tablety, jsou to notebooky a je to tradiční stolní počítač v nějaké formě. Na tomto obrázku můžete vidět téměř všechny formy rozhraní, které nyní používáme pro rozhovory s databázovými systémy a aplikacemi, které jsou poháněny těmi, z malých gadgetů v našich rukou, které chodí kolem a zdá se, že jsme k nim přilepeni. cesta k mírně větším verzím, iPadům a dalším tabletům a Microsoft Surfaces, k každodenním notebookům, které se nyní v profesionálním prostředí a tak dále stávají. Lidé inklinují k získání notebooku a ne k pevné ploše, ale podle mého názoru jsou moderním terminálem a součástí toho důvodu, že databáze čelí všem druhům problémů v oblasti výkonu správy v našich životech, nejen v rozvoji.
Předpokládám tedy, že je to jedna z největších výzev, kterým podniky stále čelí každý den. Všichni si mysleli, že databáze jsou naše jediné problémy, nejsou. Takže o čem to všechno je? Když jdeme z jednoho konce na druhý se vším, co souvisí s databázemi, z komerčního smyslu, a Mark's pokryje technické komponenty velmi, velmi dobře, ale v komerčním smyslu, jako organizace, přemýšlíme o databázích. Zabýváme se věcmi od základní konstrukce a vývoje frontendu. Když podnik začne, přemýšlí o vývoji aplikací, rozvoji schopností nebo dokonce implementaci existující aplikace v nějaké formě. Musí se uskutečnit určitá forma designu a vývoje a je třeba věnovat velkou pozornost úvahám o tom, jak budou tyto databázové systémy implementovány, podporovány a spravovány a sledovány výkony atd.
Integrace databázového prostředí a aplikací a typů API, typů přístupu, které jsou nyní poskytovány, jsou stále náročnější a složitější. Každodenní správa, podpora a zálohy jsou opět věci, o nichž jsme si mysleli, že byly vyřešeny, ale najednou se měřítko zvětšilo a věci se pohybovaly rychleji a objem je mnohem větší; vzhledem k velikosti prostředí musely databázové systémy podporovat rychlost, s jakou se transakce pohybují.
Přemýšlejte o databázi ve velmi, velmi vysokofrekvenčním obchodním prostředí. Neexistuje žádný způsob, jak by s tím lidé mohli sledovat, je to jen shluk strojů bojujících proti jinému shluku strojů za účelem vysokofrekvenčního obchodování, nákupu a prodeje a objemu na ke kterým transakcím dochází. Přemýšlejte o moderním scénáři, jako o dřívějším vydání filmu Netflix, kde nemluvíte jen o stovkách nebo tisících nebo dokonce stovkách tisíců, potenciálně milionech lidí, kteří chtějí vidět tento film od jeho prvního vydání. Všechny tyto informace jsou zachyceny a sledovány, protokolovány a analyzovány v databázové platformě.
A pak je tu stále svět, ve kterém nyní žijeme, 24/7, a to nejen následovat Slunce, ale vždy je tu někdo o půlnoci, kdo chce něco udělat, a pracovní hodiny po Slunci po celém světě. Takže provozuschopnost a dostupnost jsou ve výchozím nastavení klima, výpadek opravdu není přijatelnou věcí. A nadbytečnost, pokud se vyskytne problém s výkonem nebo pokud potřebujeme okno údržby, abychom mohli provést upgrade nebo opravu nebo zabezpečení, opravdu, musíme být schopni snížit z jednoho databázového prostředí do druhého a provést to hladce a automaticky.
Zabezpečení a standardy a dodržování předpisů, ve světě pozdě, zejména v GFC, se odehrály některé velmi velké věci, a proto máme celou řadu nových výzev, které musíme splnit ohledně dodržování předpisů a zabezpečení a odpovídajících standardů, a my potřebujeme být schopen podat o nich zprávy v reálném čase a nejlépe ve formě dashboardu. Nechceme poslat tým opic do datového centra, které se snaží najít věci, potřebujeme systém, abychom nám to okamžitě řekli v reálném čase.
A ty dvě velké zábavné, o kterých téměř nikdo nikdy nemluví, obvykle je tlačíme pod koberec a doufáme, že nikdy nezvednou svou ošklivou hlavu, ale zotavení po katastrofě a kontinuitu podnikání - to jsou také věci, které by měly z větší části se stane automaticky, pokud to bude potřeba.
Mohli bychom strávit dny povídáním o druzích věcí, které se mohou v databázových prostředích pokazit a že lidé obecně reagovali, ale nyní potřebujeme systémy a nástroje, abychom to pro nás udělali. Jedním příkladem je narušení dat, a tak, když přemýšlíme o databázích, položím tuto otázku zcela otevřeně v různých formách: co se stane s databázemi, když sejdeme z očí, a něco kritického se pokazí? Zejména pokud neexistuje systém sledující výkon a zabezpečení a další hlavní aspekty provozování databází.
Co se může stát, je to, tohle je screenshot některých nedávných porušení za poslední dva až tři roky. Vždy to všechno pochází z databázového systému a vždy se objevil nějaký problém v zabezpečení nebo kontrole nebo přístupu, který nastal, av levém horním rohu se díváme na 152 milionů účtů Adobe, kde každý detail z těchto zákazníků bylo porušeno. A kdyby to bylo v případě vhodných nástrojů, které by mohly být použity ke sledování a zachycení incidentu a kontrole bezpečnosti, mohli jsme se vyhnout některým z nich, prvních pár stovek odcizených záznamů by nás mohlo upozornit, a my bychom měli zastavil dalších sto padesát milionů.
Pak se dostaneme ke klíčovému bodu celé této cesty, který nás provede, to je: proč potřebujeme lepší systémy? Proč nemůžeme na tuto věc prostě hodit více těl, že jsme podle mého názoru dobře překročili bod zvratu, a určitě věřím, že existuje případ, který byl důkazem toho, že došlo pozdě, který hází více DBA, správců a více lidí na tato věc problém nevyřeší. Potřebujeme lepší sadu nástrojů a lepší sadu systémů.
Tady je mých pět hlavních důvodů, které to podle mého názoru podporují, a jsou seřazeny podle důležitosti na základě toho, co vidím napříč těmito soukromými podniky a státy, které jsou řízenými prostředími, problémy, kterým čelí databázová prostředí, a jejich řízení.
Bezpečnost a soulad - číslo jedna. Víte, ovládáte, kdo má přístup, odkud mají přístup, kdy mají přístup, jak často mají přístup, odkud k němu mají přístup. Potenciálně zařízení, kterých se skutečně dotkli a typy věcí, na které se podívali, a dodržování předpisů, které to obejdou. Když mají lidské bytosti zprávy o 30 dní později, aby nám řekly, zda jsou věci v pořádku, prostě už není vhodné, musí se to stát v reálném čase.
Výkon a monitorování - vypadá to, že není žádný inteligence, ale vždy to tak není. Ať už používáme nástroje s otevřeným zdrojovým kódem nebo některé komerční nástroje třetích stran, vždy jsme nezmeškali loď, v mnoha ohledech, s typem monitorování výkonu, které je vyžadováno, s podrobnostmi, které jsou schopny včas reagovat .
Detekce incidentů a reakce - musí to být okamžitá věc v reálném čase a vždy potřebujeme systém, abychom to pro nás udělali, nebo alespoň nás rychle varovali, abychom to mohli řešit, aby bylo vyřešeno několik vznikajících problémů s rychlostí a nevyhazujte se z kaskády.
Správa a správa - opět si myslíme, že tyto problémy jsou vyřešeny, nejsou. Cílem problémů, kterým čelí databázové týmy, zejména databází DBA, kde by se o nás systém měl starat, jsme tento problém dosud nevyřešili, stále je to skutečná věc.
A hned od začátku s návrhem a vývojem, když začneme tyto nástroje budovat, budujeme databázová prostředí, budeme moci hodit příslušné nástroje při vývoji a testování a integraci platforem. To pro nás stále není snadné a celá tato cesta nás vede ke stejné zprávě, že podle mého názoru potřebujeme lepší systémy a lepší nástroje, které nám pomohou dosáhnout výsledků, které potřebujeme od v našem databázovém prostředí, takže podniky, které zvyšují hodnotu od našich zákazníků. Nemůžeme jen házet více těl a více DBA, měřítko je příliš velké, rychlost je příliš vysoká a hlasitost je příliš vysoká. S tím, Ericu, bych ti mohl vrátit.
Eric Kavanagh: Líbí se mi, máme tam hodně lidí pokrytých lidmi, spoustu potenciálních náskoků, a my jdeme dopředu a předáme klíče k Bullettovi během jedné sekundy.
Bullett Manale: Dobře.
Eric Kavanagh: Oh, pojďme to pryč a Bullett, teď ti to podám a podlaha je tvoje.
Bullett Manale: Dobře, děkuji. Myslím, že bylo zaznamenáno mnoho dobrých bodů. Chtěl jsem jen na chvilku rychle promluvit o Iderě, kdo jsme, a pak skočíme dovnitř. Budu mluvit o nástroji, o kterém si myslím, že hodně z těchto věcí, o kterých mluvíme, můžeme druh sady a druh diskuse o některých oblastech, kde se tyto nástroje spojují s tímto nástrojem s produktem Diagnostic Manager.
Teď to, co chci udělat první, je jen trochu vám dát trochu pozadí o tom, kdo je Idera; byli jsme asi od roku 2003, a tak jsme začali s pouhými nástroji SQL Server a na to se dnes budeme soustředit, je produkt Diagnostic Manager. Ale můžete vidět všechny kbelíky věcí, které tu máme, a nedávno jsme, jak již bylo zmíněno, získali přesnost a prostřednictvím akvizice, máme také Embarcadero, a tak máme docela dobré portfolio produktů.
Pokud jde o sledování výkonu, z hlediska serveru SQL je produktem, o kterém chci mluvit, který sladí tato témata, o nichž diskutujeme, je Diagnostic Manager. Teď je to produkt, který byl asi od začátku dne Idery, a měl jsem to štěstí, že jsem součástí toho od roku 2005. A viděl jsem mnoho změn, pokud jde o SQL Server, posun od fyzického k virtuálnímu, vše, co se stalo, a také potřeby DBA s růstem prostředí a tyto typy věcí.
Začal jsem tím, že typickým uživatelem našeho produktu je DBA, a když tedy poprvé hovoříme s lidmi, potenciálními zákazníky, jedná se většinou o DBA, se kterými mluvíme. Nemluvíme s IT manažery nebo řediteli, může se to v určitém okamžiku dostat na tuto úroveň, ale počáteční začátek je ten, že DBA má problém, DBA se snaží problém vyřešit a mnohokrát V rámci toho půjdu a stáhnu a vyzkouším produkt. Buď získáš správce dat nebo DBA nebo fungující DBA, chlapa, který má to štěstí, že v některých případech je v dané místnosti nejtechničtější. Nyní, když se dostanete do větších podnikových prostředí, pochopitelně, pak dostanete plně rozvinuté databáze DBA, které obvykle používají nástroje. A já jsem šel napřed a právě jsem sem přidal trochu blupu z Wikipedie. Jak říká Wikipedie, jde o to, jak se děje, zodpovědnost DBA.
Pokud zde projdete seznam, spousta těchto věcí, nebudu to číst, ale dostanete spoustu typických věcí, na které si vzpomenete, a na jedné z nich máte monitorování a optimalizaci výkonu databáze, a to je docela velká. A co je zajímavé, je to, když mluvíte s DBA, jsou to vždy ti, kdo jsou obviňováni první, když jde o problémy, a nemusí to být opravdu jejich chyba, ale když nastane problém s výkonem, obvykle s aplikací, která je spojen s databází DBA, oni jsou ti, kdo obviňují, takže vždy hledají důvody, proč to není jejich chyba. V mnoha případech jim mohou tento nástroj, Diagnostický manažer, pomoci, aby jim pomohli.
Ale na konci dne, také, pokud databáze nefunguje, pak hodně z těchto dalších věcí opravdu nezáleží, vaše aplikace nefungují, pak to opravdu nezáleží pro mnoho z nich věci. V první řadě se chceme ujistit, že se uživatelská zkušenost tak, jak ji známe, nezmenšila, je to něco, o co se DBA vždy snaží. A myslím si, že pokud se podíváte na důvody, proč lidé obvykle kupují a používají produkt SQL Diagnostic Manager, jeden z prvních důvodů, pravděpodobně ne nejpřednější, v neposlední řadě, ale je to celkem stejné, a v závislosti na tom, s kým mluvíte, tyto důvody, téměř jeden nebo dva z nich, jsou vždy, existuje nějaká potřeba.
Ale první z nich je schopen mít centralizovaný pohled na instance jako SQL, který spravují. A zábavné je, že v mnoha případech, pokud se zeptáte DBA, „Kolik případů spravujete?“ Počet se mění tak často, že si v některých případech nejsou jistí. Takže potřebujete něco víc, než jen to, že budete moci všechno hodit na obrazovku. Chcete tyto informace uchopit, chcete je pochopit, a proto je to jedna z věcí, s nimiž Diagnostický manažer může určitě pomoci, aby vám mohl poskytnout takovýto pohled do životního prostředí.
A nejedná se pouze o pohled do prostředí, ale o pohled, s nímž je správce databáze DBA pohodlný, a je to konzola, která je DBA centrická, pokud chcete. Je určen pro správce databáze. Existuje spousta monitorovacích nástrojů, existuje spousta výkonných nástrojů, ale jak jsem řekl, na konci dne, DBA chce nástroj, který je navržen pro DBA, protože existuje spousta věcí specifických pro to, co dělají v jejich den co den.
A s tím řekl, máte SCOM, máte HPF, máte všechny tyto další technologie, ale chtějí něco, co je specifické pro to, co dělají. Myslím, že můžeme v této oblasti pomoci s tímto produktem, uvidíte, až se do něj vteřinu vrhneme. Druhou věcí, kterou vidíme s DBA, která je rozhodně jednou z věcí, kterých jsme se dříve dotkli, je, že musí být schopni vidět, co se děje, a samozřejmě musí být schopni se podívat na celý podnik. a klidně vědět, co se děje. Ale zároveň tam nesedí a hledí na konzole.
Pamatujete si všechny ty odrážky, které jste viděli na tomto seznamu, které jsem právě vytáhl? Musí také dělat tyto další věci, takže nejde jen o čekání na oheň. V mnoha případech se budou konat schůzky nebo spousta oken údržby souvisejících se správcem databáze běží uprostřed noci, když spí, takže musí mít možnost vrátit se a podívat se, co se stalo . V mnoha případech, pokud něco nezachytíte, když se to stane, jakmile problém zmizí, nebo alespoň s SQL Serverem, stává se takovým problémem, kdy se vypořádáváte se situací, kdy nemáte mít ještě nějaké zbytky tohoto problému. A tyto problémy zmizí, stejně jako zbytky, což znamená, že máte méně problémů s řešením, máte méně informací pro práci.
S tím řekl, že rozhodně je jedna z věcí, které může Diagnostický manažer pomoci, poskytnout vám pohled do minulosti, abyste mohli dotazovat informace z minulosti: „Měl jsem varování s blokováním, měl jsem problémy se zablokováním, Měli jsme věci, které se děly, pokud jde o naše zdroje? “Můžu se vrátit a zeptat se na tyto informace. Dokážu vrtat do konkrétních bodů v čase. Všechny tyto věci bych mohl dělat přímo z nástroje.
Všechny tyto věci, bez ohledu na to, zda je to interní nebo externí aplikace, DBA chtějí vědět, protože chtějí vidět, co způsobuje problém. Nezáleží na tom, jestli to byl někdo uvnitř organizace, nebo někdo mimo organizaci, který kód napsal; stále chtějí být schopni to izolovat, aby věděli, že k problému dochází, a věděli, odkud to pochází.
Výkon a odpovědnost jsou tedy klíčovou součástí toho, co náš produkt dělá. Můžeme poskytnout všechny tyto podrobnosti, a co je pěkné, je to, že máte možnost podrobně se rozhlédnout. Pokud existuje úzký profil, můžete to korelovat s aplikací, uživatelem, databází, dotazem. A znovu, je to druh kouření. Získáte přímou korelaci mezi spuštěním tohoto dotazu, co to dělá? A nejde jen o samotný dotaz, pokud jde o jeho provádění samo o sobě, ale také o to, jak se časem zhoršuje? A na tyto věci lze odpovědět také pomocí produktu, což je určitě něco, co když se snažíte být proaktivní, je hezké říci: „Hej, tady je dotaz, který dopadl špatně, ale chlapec se na to podívej jak to běží dál, vidíme, že běží ještě horší a horší, můžu s tím něco udělat. ““
Pokud půjdeme do další oblasti, a to je pravděpodobně - řekl bych, že je to jeden z velkých. Jednou z otázek, které se ptám, když ukazuji náš produkt, je vždy dotaz administrátora databáze: „Jak slyšíte problém týkající se vašich databází SQL Server?“ A je to velmi zábavné, protože většinu času - nyní udělené, většinu času se dívají na náš produkt, protože v mnoha případech se snaží vyřešit konkrétní potřebu. Ale je zajímavé slyšet počáteční věc - přinejmenším s SQL Serverem, je to, že to bylo takové - víte, že v prvních dnech SQL Serveru jste měli SQL Server a poté jste měli Oracle. A všichni měli Oracle a SQL Server byl tak trochu jako, pro nedostatek lepšího výrazu, zrzavá nevlastní databáze databází, když byla poprvé spuštěna.
A když k tomu Microsoft přidal další funkce, stal se trochu více podnikovým nástrojem. A od té doby je to očividně daleko. Jde ale o to, že jednou jste mohli argumentovat, že databáze nebyly považovány za kritické zpět. A to se časem měnilo. Nyní proto v mnoha případech se lidé snaží dostat ruce kolem a říkají: „Víš co? Mám všechny tyto databáze serveru SQL, snažím se o to zvládnout. “A spíše než o slyšení o problémech z helpdesku nebo o problémech od konkrétních lidí, kteří - stejně jako samotní uživatelé, hledají nějaké způsoby, jak to obejít. Hledají způsoby, jak si být vědomi těchto situací dříve, než k nim dojde.
A s Diagnostickým manažerem je to jedna z věcí, kterou se také snažíme udělat, je přinejmenším schopen učinit, že DBA je první, kdo o těchto situacích nebo problémech ví, aby mohli dělat něco o tom, buď správně, když k tomu dojde, nebo to udělat ještě o krok dále, analyzovat tyto systémy, že je to monitorování. A být schopen poskytovat vám proaktivní radu, která zlepší výkon této instance, a být schopen to dělat pravidelně. Například musíme přidat index založený na pracovní zátěži; ty druhy věcí, nástroje, které jsou schopny také dělat. Takže to uvidíme v nástroji.
Další věc a poslední věc, která je na tomto seznamu, což je spíše obecný popis, ale určitě to stojí za zmínku. A obzvláště, když se dostanete do větších typů situací na úrovni podniku, kde máte spoustu případů, vždy bude existovat nějaká nejasná věc, kterou budu chtít sledovat, pokud jsem administrátor databáze, pro příklad. Snažíme se tedy předvídat, co bude chtít sledovat typická DBA.
S tím, co bylo řečeno, byste také byli schopni, pokud jde o - vždycky bude něco nového. Poskytli jsme vám tedy způsob, jak přidat jakékoli metriky, které je třeba sledovat a spravovat po přidání bodu instalace. Takže jakékoli čítače PerfMon, čítače WMI, čítačové objekty SQL Server; všechny tyto mohou být začleněny do nástroje. Máte možnost přidat další dotazy, které mohou být začleněny do vašich intervalů dotazování.
A poslední věcí, která stojí za zmínku, je to, že můžeme přidat, a ve skutečnosti komunikovat jak s vCenter, tak s Hyper-V, abychom mohli z těchto prostředí vytáhnout metriky. Protože jednou z věcí, které jsme identifikovali s DBA, je to, že obvykle nejsou součástí operací konkrétně. A nemusí mít nutně obvykle k dispozici prostředí vCenter nebo takové věci, které mají k dispozici.
Problém tedy spočívá v tom, že pokud se zabývají instancí serveru SQL Server a byly jim přiděleny zdroje, ale tato instance je virtualizována, může to vypadat, že mají všechny zdroje na světě, když pouze monitorují, co je v hostujícím operačním systému. Realita je, že na hostiteli může být 30 nebo 40, nebo 50 nebo 100 dalších virtuálních počítačů, k nimž se pokoušejí přistupovat, a mají stejné zdroje. A jediný způsob, jak to skutečně vidět, je komunikovat s těmito dalšími prostředími a s těmito rozhraními, v tomto případě, které děláme.
Máte možnost přidat tyto další typy čítačů do nástroje. Teď nejde jen o to, aby bylo možné tyto čítače sledovat, ale také o to, aby se tyto nové čítače mohly vyrobit, které vám představí produkt, učinit z nich součást nástroje, jako by to byla metrika out of the-the-box . Neobvyklá věc, kterou byste chtěli sledovat; takže to znamená, že je lze začlenit do jejich dashboardů. Znamená to, že je můžete přidat do svých vlastních přehledů, umět je samozřejmě nastavit prahové hodnoty a upozornit na ně, ale také je vytyčit a umět je nastavit prahové hodnoty s určitými znalostmi, kde je nastavit na základě věcí, jako je vaše základní linie a co je normální. Takže máte spoustu takových věcí, které jsou také produktem.
To, co jsem vám poskytl, je to, čemu říkám „hlavní výstupy pro Diagnostický manažer“, a mohu jít dopředu a jen to trochu ochutnat tím, že půjdu do produktu. Co budu dělat, je podělte se o mou obrazovku, dobře, a prostě to přetáhnete. Takže to, co uvidíte, je konzola pro Diagnostický manažer. A jak jsem již zmínil, přejdu k prvnímu základnímu výstupu, který se bude moci podívat na věci z jakéhokoli pohledu na úrovni podniku. V nástroji je mnoho různých příkladů. Máme určitý náhled, máme více zobrazení jako mřížku. Z hlediska flexibility máme také mají také webovou konzoli. Webová konzola má další pohledy, které máte k dispozici, například klíčové mapy a podobné věci. Jde ale o to, že máte takovou schopnost se na věci dívat a vidět je na vysoké úrovni. Ale když nastanou problémy, vyrazíte o kousek dále do nástroje a skutečně uvidíte konkrétní problém lemy a určitým způsobem pochopit a vědět, co se děje. A to je samozřejmě velmi důležité.
Nyní, co se týče schopnosti skutečně vidět, co se stalo v minulosti; Pokud se dívám na problém, který se stal včera nebo před týdnem, pak v této situaci, víte, budete muset jít do konkrétní instance SQL. Dobrou zprávou je, že pokud víte, kolik času se v produktu vyskytlo, můžete přejít přímo do prohlížeče historie. A mohu ukázat na konkrétní denní dobu; mohlo to být před pár týdny, mohlo to být od včerejška. Ale bez ohledu na to, z jakého dne v kalendáři vyberu, dostanu se s různými intervaly voleb. V tom případě nyní vidím, co bych viděl, kdybych viděl konzoli 20. dubna v 13:37
Takže jsem schopen vrátit se v čase a poté, co to udělám, všechny různé karty, které zde vidíme, budou odrážet tento konkrétní časový okamžik, včetně dotazů, které by mohly běžet špatně, včetně toho, zda Měl jsem sezení s blokováním. Všechny tyto druhy věcí by se objevily v nástroji, a to mi umožní zjevně využít ty historické informace, abych mohl, víte, vyřešit problém. Nyní, když mluvíme o historii, další věc, kterou stojí za zmínku, je to, že nejde pouze o použití historie k vyřešení problémů. Tato historie je samozřejmě velmi cenná z jiných důvodů. A jeden z velkých má být schopen činit rozhodnutí efektivně a být schopen rychle se rozhodovat se správnými informacemi. Takže celou tu historii, všechny informace, které shromažďujeme, můžeme nahlásit.
Pokud někdo přijde ke mně a řekne: „Mám tuto opravdu skvělou novou aplikaci. Změní to svět, jak ho známe. Oh, mimochodem, to vyžaduje databázi, a oh, mimochodem, opravdu to zavěsí I / O na počítači, kde je tato databáze. " Pokud vím, že se do toho dostanu, mohu tyto informace využít k tomu, abych mohl poskytnout hodnocení všech svých produkčních serverů, možná na základě posledních sedmi dnů sběru. A byl bych schopen velmi rychle dojít k závěru, ve kterých případech má největší smysl tuto databázi použít. Takže je to ten typ historických informací, který je samozřejmě také velmi cenný.
Pokud jde o samotné dotazy; z hlediska pohledu na dotazy máme v nástroji mnoho různých způsobů, jak to udělat. A ten, na který se rád dívám, je Query Waits View, protože Query Waits View je velmi užitečný, pokud jde o jeho schopnost posoudit. Pokud mám problém, který se vyskytuje, být schopen v podstatě identifikovat všechny různé oblasti, které ovlivňují tento konkrétní, konkrétní dotaz; nejen samotný dotaz a jaký je dopad tohoto dotazu, ale také víte, ze které aplikace pochází, ze které relace pochází, od které ho uživatel volal a všechny tyto věci, vidím, samozřejmě, informace v reálném čase, ale mám také možnost podívat se na ta data z minulosti. A to je jedna z věcí, které jsem zde spustil, a odstartoval jsem scénář, ale musím počkat, až to vyskočí.
Zatímco na to počkáme, chci - a vím, že máme málo času, takže jsem chtěl trochu promluvit také o aktivním upozorňování na upozornění. A když mluvíte o takovém druhu věcí, jak jsem řekl, protože je proaktivní součástí, existuje spousta nástrojů, které varují. Tvrdá část neposílá e-mail. Tvrdá část nezapisuje do protokolu událostí ani negeneruje trap SNMP. Nejtěžší je vědět, kdy odeslat upozornění ve vhodnou dobu. A tak s tím přichází spousta nutnosti provádět některé výpočty, musí být pochopeno: „Co je to o této konkrétní instanci a co je normální, pokud se týká této instance?“
A tak pro všechny metriky, které to mají smysl, stanovíme tyto metriky. Ve skutečnosti vám ukážeme základní linii, ukážeme vám práh, který je aktuálně nastaven. A pak další pěknou věcí na tom je, že řekněme, že jsem nastavil své prahové hodnoty v tomto případě na šest a deset právě pro tento příklad. Šest týdnů od nynějška, pokud se vrátím k této instanci, se tato základní linie může úplně změnit, protože jednou z věcí, které děláme, když vypočítáváme základní hodnotu, je ve výchozím nastavení klouzavý sedmidenní výpočet. Takže mi vždy dává aktuální verzi základní linie. A co se stane, když se tato základní linie posune na mé prahy? V tomto případě vidím a varuji doporučení, která v zásadě říká: „Hej, máš práh, který je pravděpodobně nastaven nesprávně, konkrétně pro to, kde práh vidíme, a samozřejmě tam, kde je základní linie, pravděpodobně půjdeš dostat upozornění na něco, co je normální. “
A tak spíše než zacházet s příznakem něčeho, co je normální, dokážu identifikovat ten typ situace, kdy je skutečná prahová hodnota nastavena nesprávně. A to mi samozřejmě umožňuje dělat prahy podle toho, kde dostanu výstrahu. Je to něco, o čem vím, že je to spíše výzva k akci než vyšetřování, abych zjistil, zda je to opravdu problém. A myslím si, že část nástroje je opravdu užitečná, pokud jde o samotnou základní linii, a je schopna vypočítat.
Nyní s tímto produktem máte možnost vlastně mít více základních linií; můžete je nastavit na různá časová období a můžete dynamicky upravovat prahové hodnoty na základě vašich základních linií, což je také velmi důležitá součást přizpůsobování se změnám, ke kterým dochází každý den vašim instancím serveru SQL. . Nyní, v tomto případě, zde pokrýváme spoustu nastavení prahů a ukazujeme základní linie. Pokud však jde o skutečná upozornění, samotné oznámení, skvělá věc v nástroji Diagnostic Manager, je, že vám poskytuje více profilů upozornění. Pokud tedy máte například profil během hovoru, který je od 2:00 do 5:00, mohu mít profil specifický právě pro tento časový rozsah a zde mohu nastavit všechny podmínky a příslušná nastavení za mou odpověď.
Nyní jde o odpověď na to, že v některých případech ano, mohu poslat e-mail, nebo můžu střílet a generovat SNMP pasti nebo zapisovat do protokolu událostí. Můžeme dělat spoustu dalších věcí, ale když mluvím s DBA, opravdu se jim líbí, že ve většině případů je hodně práce, která se provádí, opakující se věci. Jsou to věci, které vědí přesně, když se problém odehrává, co mají dělat, aby to vyřešili. Musí prostě jít a zasáhnout. A tak, jak rostete své prostředí, máte více případů, což se stává mnohem obtížnější. Takže jedna z věcí, které můžete udělat v nástroji, o kterém si myslím, že stojí za zmínku, je, že máte možnost nastavit podmínku, ale na základě této podmínky můžete nastavit odpověď pro spuštění skriptu, spuštění úkol, spustit spustitelný soubor. A jde o to, že pokud se rozhodnete spustit skript, mohu použít parametry, uvnitř tohoto skriptu, které budou v době běhu, naplněné skutečnými informacemi.
Pokud tedy existují problémy s konkrétní databází, bude skript navržen tak, aby běžel přímo proti databázi, kde se problém vyskytuje. Můžete tedy dynamicky řešit problémy automatizovaným způsobem, a pak mohu stále dostávat e-mail, abych se vrátil a řekl mi: „Hej, vyskytl se problém, ale mimochodem, byl vyřešen.“ Skript byl spuštěn a jako DBA o tom víte, ale ve skutečnosti jste nemuseli jít a zasahovat. Nyní, ve stejné poznámce o tom, že jsme aktivní, je zde samozřejmě také další funkce, kterou je funkce „Analyzovat“. A to, co to udělá, je, že bude provádět pravidelnou kontrolu, proti instanci SQL. A v některých případech to udělá hlubší ponor, pokud jde o to, co hledá. Provedou se věci jako hypotetická analýza indexu. Přidám index? Odstraním index? A všechny tyto věci zřejmě pomohou s mým výkonem, ale znovu, je to všechno o aktivitě. Jde o to, že se dokážeme rozhodnout před tím, než se věci rozbijí, a aby to fungovalo lépe. A tak v mnoha případech se to opravdu snažíme udělat.
Vracíme se k Query Waits, o kterém jsme mluvili dříve; jak vidíte, je tu velký hrot. Spustil jsem skript dříve, který právě způsobil nějakou čekací aktivitu, a jak jsem již zmínil dříve, máme opravdu jedinečný způsob, jak se můžete dostat do této informace. Pokud chci vidět, jaké to bylo; Vidím, že to pocházelo z aplikace NoSQL. Byli bychom schopni vidět databázi, na kterou byla navázána, relaci, uživatele, a pak, pokud chci, mohu to zařadit podle svých čekání. Mohu tedy říci, ze všech čekání, která se odehrála v tom časovém okně, které z nich se dělaly nejvíce? A když vidím, že když se to stalo nejvíce, opravdu pěkné je, že mohu vrtat do toho typu čekání a vidím všechny příkazy. Podíváte-li se sem, dělali to čekání. A také vidím primárně, jaká aplikace to byla, která způsobovala to čekání.
Takže to trčí jako bolavý palec. Okamžitě mohu jít a říci: „Toto je příčina, která způsobuje můj úzký profil. Teď, jaký byl dotaz, který byl spuštěn? Který uživatel to spustil? S jakou databází se spustil?“ Atd. Doufejme, že to dává smysl a to také pomáhá, pokud jde o zajištění, že ve vašem prostředí nemáte latenci, protože se to týká vašich databází. Doufejme, že je to užitečné. V tomto bodě půjdu dopředu a předám to zpět, a myslím, že můžeme odtud pokračovat.
Eric Kavanagh: Jistě. Takže myslím, že to hodím jen našim odborníkům dne. Marku, možná nejdřív chceš komentovat a zeptat se na pár otázek. Pak Dez, můžete zazvonit.
Mark Madsen: Ano, díky, opravdu jsem si to trochu užil. Je to mnohem inteligentnější monitorování, než na co jsem zvyklý. Jsem zvědavý na správu dat za tím; správa metrik, které můžete sledovat, a víte, hledejte věci jako posunutí základních linií, které jsou jedním z mých bodů bolesti domácích mazlíčků, s dashboardy. Jak se s těmito údaji vypořádáte, a druhá část toho je, víte, základní metriky, jako je druh posunu - máte schopnost automaticky posunout prahy také, takže nemusím vrátit se zpět a resetovat prahy ručně, když se změní základní linie?
Bullett Manale: Ano, a tak je na tom hezké, že se můžete rozhodnout. Můžete udělat buď. Mohu nastavit práh a učinit z něj statické nastavení, nebo mohu zaškrtnout políčko říkat: „Udělejte z tohoto dynamický práh, který se změní, jak se změní moje základní linie.“ A mám schopnost a nástroj nastavit výchozí okno času pro mou základní linii. Ale pak, pokud to budu potřebovat, možná budu mít samostatné základní okno, například z mého udržovacího okna od 2:00 ráno, řekněme do 5:00, protože budu zdanit své CPU, mé disky a všechno ostatní, protože v tom případě, když provádíme veškerou naši údržbu. Pak by se automaticky, pokud bych si to vybral, automaticky upravilo mé prahové hodnoty tak, aby byly mimo to, co je pro ty metriky normální, Rozhodl jsem se, že to udělám. To by mi to umožnilo. V zásadě máte v nástroji možnost nastavit okna času, která jsou vaše výchozí okna, a každé okno lze považovat za samostatnou entitu, pokud jde o dynamické přizpůsobení baselingu, které lze provést. A můžete přidat tolik oken své základní linie jako yo u potřeba, pokud to dává smysl. Mohli byste mít víkendové okno, pracovní den v pracovní době, údržbové okno, které se děje uprostřed noci a tak dále a tak dále.
Mark Madsen: Díky.
Bullett Manale: Myslím, že se vracím k první části otázky, máme, a shromažďuji všechny tyto informace. Opravdu jsem nemluvil o architektuře, ale máme back-end repozitář, že máte úplnou kontrolu nad uchováváním těchto dat, ale také máme službu, která běží uprostřed noci, která chodí a dělá všechny naše základní výpočty a tato data bere, shromažďuje a dává jim smysl. A samozřejmě máte také řadu přehledů, které můžeme použít k vykazování podle vašich základních linií pro konkrétní metriky. A dokonce máte schopnost porovnávat základní linie stejného serveru pro stejnou metriku pro různá časová období. Uvidíte, zda existují rozdíly, které se vyskytly nebo co je delta. Existuje také mnoho těchto typů možností.
Eric Kavanagh: Dez.
Dez Blanchfield: Mám pro vás jednu rychlou otázku - existuje široké spektrum toho, co tento nástroj dokáže. Vidíte v jeho používání v počátečním stadiu vývoje absorpci, nebo je to stále především nástroj produkčního prostředí? Jinými slovy, získávají vývojáři přístup a používání prostřednictvím jejich raného vývoje a poté testují integrační fázi? Nebo se stále používá převážně v produkčním prostředí?
Bullett Manale: Řekl bych, že to většinou vidíme v produkčních prostředích. Závisí to na situacích, ale z větší části bych řekl především výrobu a my - a je také spravedlivé zmínit, že máme různé ceny pro prostředí dev a test, takže je to o něco atraktivnější. Vidíme lidi, kteří je používají v těchto prostředích, ale řekl bych, že kdybych vám musel dát odpověď tak či onak, řekl bych, že je to především stále produkční prostředí, kde vidíme lidi, jak investují do tohoto produktu .
Dez Blanchfield: Jistě, ano a bylo zajímavé slyšet, že máte různé cenové body, protože zjevně existují různé pracovní zátěže a těžší práce budou tam, kde se děje veškerá skutečná práce. Ale vidím mnoho organizací, zejména ve vládě a určitě v obraně, kde vývoj nyní získává stejnou úroveň investic do nástrojů a systémů jako produkční prostředí, protože provádějí mnohem více prvotních testů. Na obranu například existují týmy, které provádějí miliardy testů, stovky miliard testů na aplikacích, systémech a nástrojích a sledují je před tím, než začnou testovat integraci, protože se chtějí ujistit, že je vytvořen kód a databáze sedí pod tím. Dostane se na sto a milion iterací nebo tak něco, zatímco vy jste na terénu střílet na někoho, nejde to "třesk".
Bullett Manale: Jasně.
Dez Blanchfield: Ve světě starých databází podle mých zkušeností se domnívám, že databázové prostředí je něco, co právě zůstalo v datech a někteří z vás vědí, jsou velmi zřídka vidět a jen zřídka se o nich mluví, takže když nyní dostaneme místo, kde nástroje a vyvíjejí se aplikace, zejména s analytickými platformami, nyní jsou v našich telefonech a našich zařízeních. Vidíte, jak klienti přinášejí konverzaci výkonu databází a správu databází v každodenní diskusi na rozdíl od čistě technických techniků? A vím, že jste se zmínil dříve, že převážně mluvíte s DBA, ale existuje trend, kdy je to v obecné slovní zásobě, vidíte lidi, kde diskutují o těchto tématech, na rozdíl od pouhé geeků?
Bullett Manale: No, je to těžké říct. Jak jsem řekl z větší části, myslím, že lidé, s nimiž se v souvislosti s prodejním procesem zabýváme, jsou i tak praktici, kteří jsou DBA. Takže pokud jde o vaši otázku, jen říkáte: „Obecně si lidé v IT organizaci uvědomují více databáze?“ Myslím, že je to otázka, a pravděpodobně bych řekl, že odpověď je „ano“. Asi to tak moc nevidím, podle toho, kde jsem, na každodenním základě, ale myslím, že pokud rozumím vaší otázce, byla by to moje odpověď, myslím.
Dez Blanchfield: Ano, to je v pořádku. Je to pravděpodobně naložená otázka, promiňte, protože zjevně vaše dominantní zájmy ve vašem světě jsou technickou stránkou věcí. Jsem zvědavý, že ve svých každodenních činnostech vidím organizace, které to začnou do konverzace přivést velmi brzy. Když tedy mluví o nových iniciativách, nových projektech, nových pracovních programech, jednou z věcí, které přicházejí okamžitě, je: „Jak ji sledujeme, jak ji sledujeme, jak řešíme problémy, které se objevují, na rozdíl od spuštění, bude žít? “
Bullett Manale: Řekl bych, že -
Dez Blanchfield: Promiňte, jděte do toho.
Bullett Manale: Chtěl jsem říct, že vidím trend, o kterém bych měl říci - víte, mnohokrát v minulosti jste dostali: „Měli jsme problém, a tak nyní potřebujeme nástroj. " A myslím si, že vidíme trochu více souhlasu s tím, že máme nástroj na místě, než dojde k problému, pokud to má smysl. Takže bych řekl, že to určitě začíná být normálnější, víte: „Hej, potřebujeme monitorovací nástroj, potřebujeme něco.“ A lidé rozhodně vidí hodnotu tohoto produktu, protože, jak jste již řekli dříve, stačí přidat DBA a přidávání nových instancí potřebujete něco, co to zvládne. Potřebujete něco, co pomůže s jeho správou, a proto také v tomto produktu vidíme mnoho akceptace, nebo máme.
Dez Blanchfield: Rychlá otázka. Kde to musí žít? Musí to sedět přímo na zadní straně vypalovat v LAN, v datovém centru, co nejblíže databázovým prostředím, nebo je to pohodlně umístěno někde, potenciálně v cloudu, cloudu třetích stran s nějakým druhem VPN tunel nebo vzdálený přístup do různých prostředí? Kam to musí sedět, pokud jde o prostředí a monitorování?
Bullett Manale: Pokud jde o architekturu, existuje back-end úložiště, a to je databáze SQL Server. Máme konzoli, která může být buď tlustým klientem, nebo tenkým klientem; dáváme vám možnost obou. A máme také tenkého klienta, který je skutečně zaměřen konkrétně na mobilní zařízení. Ale pokud jde o to, kde to skutečně může sedět; může sedět v prostředí, ve skutečnosti je o to složitější, z mnoha informací, které musíme shromažďovat, vyžaduje správní práva, v některých případech nebo v mnoha případech. Teď vás to nenutí; pokud chcete, můžete sbírat data a jen za věci, které nemůžeme shromáždit, protože nemáme administrátorská práva, pouze vám necháme tyto informace vidět, pokud je to volba, kterou uděláte.
V závislosti na chuti, jako kdybyste mluvili o AWS, v některých prostředích, to funguje lépe než v jiných, ale pokud jde o samotné samotné prostředí, vše, co je potřeba, obvykle je buď použití autentizace SA ke sběru dat proti instancím. Nebo pokud se jedná o nedůvěryhodnou doménu, obvykle byste to chtěli udělat, ale více domén; pokud mezi nimi existuje důvěra, můžeme je shromažďovat proti nim. Nezáleží na tom, jestli je to na LAN nebo na WAN, samotná samotná kolekce je z hlediska množství dat, které shromažďujeme, zanedbatelná. Pokud máme připojení WAN dostatečné velikosti, není to problém. Viděl jsem prostředí, kde mají pobočky, kde mají SQL servery po celých Spojených státech. A je to jeden server na každém z těchto různých míst a oni jej centrálně monitorují. Choulostivou částí je jen zajistit, aby k tomu bylo slušné množství připojení. Doufejme, že to odpoví na vaši otázku, bylo to trochu po celé mapě.
Dez Blanchfield: Ano, rozhodně ano. Děkuji. Takže dvě rychlé otázky, které dnes ráno přišlo prostřednictvím účastníků; jedním z nich je: jaký je dopad - často vidíme, že nástroje pro monitorování systému vytvářejí zátěž sami pouhým sledováním věcí, takže otázka byla, omlouvám se, že to teď sklouzlo z mé obrazovky, ale jen ji parafrázujeme; monitorováním vytváříme zátěž sami? Existuje měřitelný dopad nástroje, jen sledují životní prostředí, nebo je to zanedbatelný dopad?
Bullett Manale: Bude to vždycky mít trochu dopad, protože musí dotazovat instanci serveru SQL, aby stáhl data zpět. Otázka, jak jste řekl, zní: „Je to zanedbatelné nebo významné?“ Krabice, která ukazuje na instanci, je zanedbatelná. Dělali jsme to pro, jak jsem řekl, už nějakou dobu. Máme více než 20 000 zákazníků a mohu vás ujistit, že pokud by to mělo významný dopad na výkon, nebyli bychom v podnikání. Díky tomu také umožňujeme uživateli rozhodnout se, co chtějí sledovat. Takže si myslím, že je důležité zmínit, že každé prostředí je trochu jiné.
Příkladem by s komponentou pro sledování dotazů byla jedna z věcí, které máme schopnost dělat, a můžeme nastavit práh toho, co považujete za vaši hranici normality. Mohlo by to tedy být založeno na době provedení dotazu. Mohlo by to být založeno na CPU, I / O, ale jako příklad řekněme, že jsem nastavil svůj čas spuštění na nulu milisekundy. Efektivním nástrojem, který mám tomuto nástroji říci, je shromáždit všechny dotazy, které proběhly od posledního intervalu tahání, a také učinit tuto část mé historické sbírky.
Nyní, když to uděláme, budeme shromažďovat jakékoli množství dotazů, které jsme běželi na krabici od posledního dotazování. Nyní je to volitelné a uživatel má možnost to udělat. Říkáme: „To je to, co byste měli udělat“? Ne. Ale také vám dáme možnost to udělat v případě, že chcete vzorek dat, který vám umožní tyto informace shromáždit. Obecně řečeno, máte prostředky uvnitř nástroj k jeho nastavení a vyladění přesně podle toho, jak chcete, na základě toho, co vám vyhovuje. Máte však možnost ji opravdu otevřít, pokud chcete, a shromažďovat spoustu dalších informací, které nemusíte nutně pravidelně sbírejte, pokud to má smysl.
Dez Blanchfield: Ano, absolutně. Vím, že běháme trochu dlouho, ale jsou tu dvě opravdu skvělé otázky, které na vás chci hodit, než se sbalím. Oba přicházejí přímo ke mně, ale myslím, že je nejlepší, když na ně odpovíte. Obecně se jednalo o otázku: „Jaký je rozsah dosahu nástroje, pokud jde o znalosti existujících systémů?“ Můžeme to jednoduše připojit a nechat jej automaticky detekovat platformu, která je tam, a vědět, co je pro tuto platformu normální, a okamžitě vyzvedněte si, o čem Mark mluvil dříve? Některé základní znalosti platforem vložením, víte, já nevím, může to být Microsoft Dynamics. Jaký je rozsah znalostí platformy s tím, co je normální a v některých současných běžných nástrojích, které se používají v podnikání?
Bullett Manale: Řekl bych, že obecně, když začneme sbírat data na instanci SQL, začneme s osvědčenými postupy, pokud jde o naše prahy a kde jsou nastaveny. To znamená, že si také uvědomujeme, že s kýmkoli, s kým mluvíte, je z hlediska osvědčených postupů každé prostředí odlišné. Co uděláme zpočátku jen shromažďujeme data a co doporučujeme lidem, můžete produkt vyzkoušet o 14 dní déle, pokud potřebujete. Ale asi po dvou dnech se začnou zobrazovat základní data. Jakmile bude mít dostatek vzorových informací, s nimiž bude možné pracovat, začne vám poskytovat kontext, pokud jde o základní linii, kde je rozsah, a všechny takové věci. Pak odtud, pokud chcete, můžete automaticky nastavit své prahové hodnoty z těchto shromážděných informací. Trvá trochu počáteční kolekce a dotazování, aby bylo možné začít určovat, co je normální, takže můžete začít posouvat své prahové hodnoty.
Ale myslím si, že stojí za zmínku také to, že když změníte tyto prahové hodnoty, lze to provést skupinově podle vašich instancí. Může to být specifické pro jednu instanci nebo to můžete udělat proti všem svým instancím a také ke schopnosti vytvářet věci, jako jsou šablony, takže můžete říci: „Toto je produkční instance, ale toto je šablona, kterou chci přiřadit k tomu. “ A když se tedy nová produkční instance dostane do režimu online, automaticky na ni použijeme tyto prahy, protože má stejný typ hardwaru a obvykle má stejné pracovní zatížení, takže bychom to mohli také udělat. Doufejme, že to pomůže, pokud jde o otázku.
Dez Blanchfield: Ano, rozhodně ano. Ve skutečnosti jste skutečně odpověděli na další otázku, která ke mně právě přišla, a to bylo: „Existuje zkušební verze ke stažení?“ Vím, že na to mohu odpovědět. Určitě potvrdíte, že je ke stažení zdarma, a myslím, že jste řekl, že to bylo 14 dní od webu. Můžete si ji stáhnout a hrát s ní. Hádám však s tím jen velmi rychle: „Jaké prostředí potřebuji, abych mohl zkušební verzi spustit? Mohu ji spustit na svém notebooku a hrát si s ní nebo opravdu potřebuji server?“
Bullett Manale: Hlavní věcí, kterou potřebuje, je úložiště, databáze SQL Server, která je od roku 2005 nebo vyšší. Kromě toho existují určité minimální požadavky na zdroje, požadavek .NET a to je vše. Jedná se tedy pouze o instalaci produktu a vytvoření databáze.
Dez Blanchfield: Perfektní. Jedna poslední otázka, kterou na vás hodím, protože nám právě teď chybí čas, ale rychle se mě asi dva nebo tři lidé zeptali: „Musím být DBA, abych se ve skutečnosti dokázal postavit a běhat tohle a hrát si s tím? “
Bullett Manale: Ne. Řekl bych, že pokud jste DBA, budete tento nástroj používat různě. Myslím, že bude pravděpodobně o něco větší hodnotu, pokud jsi ostřílený DBA. Uvidíte mnohem větší hloubku nástroje, ze kterého byste mohli využít. Ale také jako nový DBA, nebo dokonce jako osoba, která není DBA, máme mnoho doporučení, a právě teď jsem na této stránce. Tato doporučení se budou pravidelně objevovat a opravdu příjemná věc ohledně doporučení je, že vám poskytnou důvody, proč jsou doporučení vydávána. Kromě toho však budou mít také odkazy na externí obsah, který podrobněji popisuje důvody, proč jsou tato doporučení také vydávána. To bude odkazovat na externí weby společnosti Microsoft, blogy a všechny podobné věci, to je externí.
Ale abych odpověděl na vaši otázku, je to druh, víte, že pokud jste starší DBA, budou tady věci, pravděpodobně využijete, že byste pravděpodobně jako začínající DBA nebyli. Ale zároveň je to také druh učebního nástroje, protože když procházíte těmito doporučeními, začnete některé z těchto věcí začít vyzvedávat na vlastní kůži pomocí doporučení.
Dez Blanchfield: Fantastický. Děkuji. Demo část jsem si opravdu užil. Prezentace byla skvělá. Demo bylo fantastické. Rychle z paměti je na vašem webu celé středisko zdrojů, které doporučuji lidem, aby se na něj také podívali. Vzpomínám si, jak jsem tu včera procházel, abych získal nějaké podrobnosti. Máte celou řadu věcí, od vašich blogů a dat a konverzací až po paměť, máte většinu dokumentace k produktu také online, ano?
Bullett Manale: Ano, je to správné a myslím si, že forma, na kterou odkazujete, je web community.idera.com. A ještě jednu věc, o které bych se zmínil, dříve, když jste se ptali: „Rozpozná prostředí?“ Co se týče nových instancí nebo přidávání instancí, máme další nástroj, který máme k nalezení instancí. A je to všechno o inventáři a správě vašeho inventáře. Chtěl bych vás jen trochu poukázat tímto směrem, pokud jde o skutečné objevování případů. Ale pokud jde o výkon a monitorování, všechno, o čem jsme hovořili, to je místo, kde by diagnostický manažer vstoupil do hry.
Dez Blanchfield: Fantastický. Podívejte, skvělé pokrytí. Vaše prezentace se opravdu líbila. Miloval jsem živé demo a to je ode mě dnes ráno, protože vím, že jsme odešli asi 10 minut v čase. Ericu, půjdu ti zpátky.
Eric Kavanagh: Dobře. Jen jsem miloval demo. Jsem rád, že jste provedli demo. Jsem rád, že jsme se na to měli pěkně podívat, když jsme procházeli otázkami a odpověďmi.
Bullett Manale: Skvělé.
Eric Kavanagh: Protože to dává lidem představu o tom, na co se díváte, a opravdu mě trochu ohromuje, když si myslím, že se stále učíme o tom, jak mluvit s těmito počítači, když se k tomu dostanete přímo. Myslím, že tato úroveň diagnostiky je velmi sofistikovaná a každým dnem se zlepšuje. Zjišťujeme mnohem více o tom, co se ve skutečnosti děje. Ale opravdu potřebujete osobu, která by tyto věci přehlédla, přečetla a uvedla kognitivní schopnosti za to, co děláte, že?
Bullett Manale: Ano, v mnoha případech myslím - přál bych si, abych vám mohl říct, že v krabici je DBA, ale stále se děje příliš mnoho věcí. Chci říct, poskytujeme pokyny a pomáháme, ale na konci dne to vyžaduje, aby se lidé rozhodovali o údajích, které předkládáme. Nemyslím si, že se to brzy změní.
Eric Kavanagh: No, to je dobrá zpráva pro skutečné lidi, lidi.
Bullett Manale: Správně.
Eric Kavanagh: Budete chtít, aby to někdo sledoval, tým, který to sleduje, a dozvíte se, jak jste tady slyšeli od Bulletta, při pohledu na tato doporučení si vyzvednete, co se děje. A myslím, že z této historie, a myslím, že jste se toho dotkli, Bullette, ale velmi rychle, tato historie vám umožní rozpoznat významné vzorce a poté je být schopen je identifikovat, když k nim dojde v budoucnosti, že?
Bullett Manale: To je pravda. Jednou z věcí, které můžeme udělat, je sledovat výkon dotazu v průběhu času. Můžeme se samozřejmě podívat i na jiné věci, jako jsou základní linie, a vidět, jak se mění, a samozřejmě, když se to stane, dostávat upozornění a podobné věci, takže tuto schopnost určitě máte.
Eric Kavanagh: To zní dobře, lidi. Nebyli bychom tu dlouho, ale chtěl jsem se k těmto otázkám dostat. Děkuji mnohokrát za váš čas a pozornost. Všechna tato webová vysílání archivujeme. Hop online na Techopedia.com nebo InsideAnalysis.com, uvidíte odkazy z obou míst.
A s tím vám nabízíme rozloučení. Ještě jednou díky, lidi, dohlédneme vás příští týden, další tři webcasty příští týden, úterý, středa, čtvrtek. Takže s vámi budeme mluvit příští týden, lidi. Opatruj se. Ahoj.
Partner obsahu Techopedia
Zaměstnanci Techopedia jsou spojeni se společností Bloor Group a lze je kontaktovat pomocí možností na pravé straně. Informace o tom, jak spolupracujeme s průmyslovými partnery, najdete zde.- Profil
- webová stránka
