Има нарастващ брой страхотни системи за наблюдение на производителността на базата данни. Напоследък към по-традиционните локални решения се присъединиха софтуерни решения като услуга (SaaS).
Този блог контрастира типичната архитектура на локално решение с тази на SaaS решение. Разбира се, компонентите ще се различават по име и структура от един доставчик до друг, но ключовите концепции, обсъждани тук, ще бъдат представени в една или друга форма.
Разлики между локалните и SaaS решения
Като цяло, ето някои от ключовите компоненти на всяко решение:
Традиционно локално решение
- Процес за събиране на данни.
- Хранилище за [диагностика] за краткосрочна ефективност.
- Хранилище за дългосрочни аналитични/отчетни данни.
- клиент за Windows или браузър.
- Всяка инфраструктура за отказване, необходима за инфраструктурата за наблюдение.
SaaS решение
- Процес за събиране на данни (за локални цели).
- Клиент на браузъра.
- Мобилно приложение.
- Доставчикът на SaaS управлява приложението и съхранението на данни в задния край.
Обърнете внимание, че имената на различните компоненти ще варират от едно решение до друго. В някои случаи функционалността може да бъде разделена между множество услуги или източници на данни.
Локални решения
Процес за събиране на данни
Колекторът на данни обикновено е локална услуга без агент, която събира данни от всяка локална наблюдавана крайна точка. Този процес дирижира как и кога се събират данните. Той трябва да може да събира данни на различни честоти, за да балансира нуждата от повече подробности с въздействието върху наблюдаваното работно натоварване. Честотите на събиране и праговете за предупреждение трябва да са предварително конфигурирани за всеки показател.
Всеки ще има „шумен” екземпляр, който не отговаря на стандартните прагове. Това може да доведе до много фалшиви положителни резултати. За да се справи с това, системата трябва да има способността да създава правила на ниво инстанция за справяне с изключителни обстоятелства. Това избягва „умората от алармата“ от фалшиви положителни резултати.
В някои случаи тази услуга също организира сигнали и известия. В големите организации със стотици наблюдавани екземпляри може да се наложи да се балансира натоварването чрез „обединяване“ между редица събирачи на данни. Федерацията синхронизира колекциите и конфигурацията в разпръсната система.
Хранилище за краткосрочна диагностика
Тук се съхраняват подробни данни. Това ще включва данни от DMV, регистрационни файлове, XEvents и други източници на данни на SQL Server. Източниците, които биха могли да упражняват натиск върху наблюдаваните екземпляри, трябва да се избягват, например повечето следи са неподходящи за наблюдение в реално време.
Тъй като честотите на събиране могат да бъдат толкова често, колкото всяка секунда и се събират по-големи парчета данни, като TSQL и планове, това хранилище може бързо да стане голямо. В резултат на това повечето системи обикновено ограничават историята до между седмица и месец (тези ограничения не важат за SaaS решение). Това хранилище е силно транзакционно по природа.
Дългосрочно отчитане/хранилище за анализи
В края на предварително определено време тези подробни данни се обобщават и съхраняват в хранилище за отчети за анализ на високо ниво и тенденции. Количеството запазени детайли ще окаже значително влияние върху евентуалния размер на това хранилище и изчислителния капацитет, който може разумно да се очаква от потребителя да предостави на разположение, за да го анализира. Това има тенденция да варира значително от едно решение до друго. Решенията, които поддържат по-задълбочени анализи, ще имат поддържащи архитектури и могат да използват OLAP архитектури за улесняване на многоизмерния анализ.
Мащабиране на локално решение за наблюдение
Ще бъдат проектирани по-сложни решения, за да улеснят разпределената архитектура на ключовите компоненти за поддържане на мащаба. Услугата за събиране на данни ще има горен брой наблюдавани връзки, които може да поддържа. След като този лимит бъде достигнат, допълнителен събирач на данни трябва да бъде „обединен“, за да координира събирането на данни и да организира съхранението на данните.
Самите хранилища с данни за производителността могат да споделят един екземпляр или могат да бъдат разпределени в няколко екземпляра, за да поддържат мащаб. Хранилището, което те изискват, ще бъде право пропорционално на броя на наблюдаваните връзки и обема на запазените данни. Структурата и архитектурата на хранилището за анализи също ще повлияят на общия капацитет.
Потребителско изживяване
Повечето локални инструменти ще имат преден край на Windows. Някои имат предни части на браузъра, базирани на локално хоствано внедряване. Отдалеченият достъп до тях може да бъде сложен и обикновено изисква VPN. Те рядко поддържат мобилни приложения.
Висока наличност
Софтуерът за наблюдение, който следи критичните за мисията натоварвания, трябва да бъде устойчив сам по себе си. Трябва да се предвиди разпоредба за справяне с бедствия, които могат да изключат структурата за наблюдение. Това също трябва да се разглежда от гледна точка на архитектурата и разходите.
SaaS решения
Процес за събиране на данни
Въпреки че SaaS предложението се хоства предимно, то често ще поддържа локален колектор на данни за локални работни натоварвания. Това помага за справяне с ограниченията за производителност и сигурност. По този начин всички връзки на ниво екземпляр се осъществяват чрез локалния колектор, който след това препраща наблюдаваните данни за производителността на базата данни към услугата за влизане в облак. Всички данни трябва да бъдат криптирани при пренасяне.
Хранилища за диагностика и отчитане/аналитика
Добрата новина тук е, че доставчикът на SaaS обработва цялото ви съхранение на данни. Не е нужно да се притеснявате за изправяне на екземпляри за диагностичните хранилища, хранилища за отчети, прочистване на диагностичното хранилище или много от другите главоболия, свързани с локално внедряване.
Хостваните решения ще се основават на различни стратегии за съхранение в задния край, за да улеснят комбинацията от транзакционна и аналитична дейност, според случая. Те могат да използват облачни ресурси, за да обработват по-големи обеми данни и необходимата обработка, необходима за анализ; например Spotlight Cloud съхранява една година подробни данни. Така че не само можете да отчитате година назад във времето, но също така можете да възпроизведете натовареността си до една година в миналото. Това е наистина мощна способност.
SaaS решение за мониторинг на производителността на базата данни може да използва различни стратегии за съхранение в задния край не само, за да отговаря на по-транзакционния характер на диагностиката и мониторинга, но и да улесни високоинтензивното пресичане на числа, свързано с дългосрочните анализи. Доставчикът на SaaS може да използва значителни икономии от мащаба, за да използва много по-мощна инфраструктура, която би била на разположение на отделните организации.
Как да мащабирате SaaS решение
Мащабирането на SaaS решение е отговорност на доставчика, а не на потребителя. Всяко SaaS решение за мониторинг на производителността на базата данни трябва да бъде изградено така, че да се мащабира от първия ден и в резултат на това то има тенденция да се справя с мащаба с бързи темпове.
Потребителско изживяване
SaaS приложенията ще бъдат по подразбиране за браузър Ux и много от тях ще имат и цялостни мобилни приложения. Това улеснява разпръснатите и отдалечени екипи.
Сигурност и съответствие
Повечето SaaS решения ще бъдат изградени на една от водещите облачни инфраструктури, като Azure или Amazon. Много от водещите доставчици разполагат със сложни инфраструктури за сигурност. Те инвестират сериозно в подкрепа на нуждите на своите клиенти за съответствие.
Висока наличност
Добрата новина тук отново е, че това е отговорност на продавача. Струва си да се консултирате с вашия доставчик, за да разберете какви разпоредби са направили по отношение на отказ и висока наличност. SaaS приложенията трябва да бъдат проектирани така, че да бъдат много устойчиви. Различните услуги, които съставляват SaaS приложение, обикновено са проектирани да бъдат индивидуално устойчиви. Могат да се предвидят и прекъсвания на центъра за данни, при които приложението ще премине от един център за данни към друг в случай на прекъсване на центъра за данни.
