Преди да започнете да разглеждате инструмента за наблюдение на SQL сървър, помислете за вашата конкретна среда:
- Колко екземпляра искате да наблюдавате?
- На едно място ли са или разпръснати?
- Трябва ли да наблюдавате операционната система и/или хипервизора?
- Колко история ви е необходима, за да получите точна представа за границите на действие на вашия екземпляр?
- Всички те ли са на място или някои са в облака?
- Разпределени ли са вашите екипи?
- Купувате ли софтуер в рамките на бюджет за капиталови или оперативни разходи?
- Можете ли да си позволите да инвестирате еднократна сума предварително в инфраструктура и лиценз или предпочитате да разпределите разходите си във времето?
- Имате ли налични инфраструктура и екземпляри от база данни, които да посветите на инструмент за наблюдение?
- Имате ли време да изградите инфраструктура за наблюдение?
- Имате ли постоянно висок опит в екипа си?
- Използвате ли младши ресурси за първоначално сортиране или разчитате на вашите експерти за всичко?
- Имате ли време или ресурси вътрешно, за да поддържате инфраструктура за наблюдение?
Трябва ли да въртя своя собствен?
Мога да декларирам нашата пристрастност тук. Quest Software създава инструменти за наблюдение на производителността през последните 20 години. Има отлична причина ние и много други като нас да останем в този сегмент толкова дълго и защо имаме нарастваща клиентска база. Наблюдението на ефективността, направено добре, не е лесно!
Наистина има някои страхотни начини за събиране на показатели от SQL Server с помощта на PerfMon, следи, DMV и XEvents, за да споменем няколко. Правенето на това еднократно за един проблем е добре и добре – ако имате време да инвестирате в проучване къде и как да съберете данните за този проблем. След като проблемите започнат да се увеличават и броят на случаите се увеличава, това бързо става нескачаемо.
Налични са няколкостотин метрики, които си струва да проследите, за да получите пълна представа за здравето на производителността на вашия SQL Server. В допълнение към това има SQL код, който се изпълнява, и планове за заявка, свързани с всяко изпълнение на същото. Някои показатели трябва да се събират всяка секунда, други всеки час, а някои въз основа на това кога се изпълнява кодът. Някои методи за събиране могат да повлияят на наблюдавания екземпляр и трябва да се избягват.
Всеки показател ще има различни прагове, които ще определят състоянието му. Конкретни случаи може да имат нива, които са нестандартни. След това трябва да съхранявате всичко това. Обемът на данните се натрупва МНОГО бързо. Ще трябва да създадете стратегия за редовно изчистване на подробни данни и след това, ако е необходимо за тенденцията, да обобщите тези данни за отчитане.
Това е МНОГО работа... и разбира се, всеки път, когато излезе нова версия на SQL Server, трябва да се справите с главоболие от регресия. Освен ако всъщност не искате да продадете инструмент за наблюдение, силно бих посъветвал да не пускате свой собствен, освен ако обемът на проблемите е малък и проблемите, които трябва да решите, са много специфични.
Какво ще кажете за безплатните инструменти?
Безплатните инструменти често си струва да се обмислят, особено за по-малки екипи с по-малко критични случаи. Мислете за това като за следващата стъпка в стълбата на мащабируемостта след „развъртете своето“. Много от началните търговски инструменти за мониторинг на SQL сървъри трябва да имат подобни съображения. Помислете за следното:
- Инструментът покрива ли достатъчен обхват от показатели, за да ви даде адекватно покритие за всички случаи на употреба във вашите наблюдавани екземпляри? Много безплатни инструменти ще дадат някакъв вид „персонализиране“, за да добавите свои собствени показатели. Когато „персонализирането“ се използва за запълване на пропуски във функционалността, тогава бързо ще откриете, че екипът ви в крайна сметка „включва собствените си“ с необходимото главоболие за разсейване и поддръжка.
- Инструментът поддържа ли предупреждение? Предварително конфигуриран ли е? Конфигурирането на сигнали може да отнеме много време. Предупрежденията извън кутията са задължителни, за да се предотврати много загубени човекочасове при конфигуриране на инструмента на някой друг. Освен това трябва да улесни персонализирането на сигналите за крайните случаи, които не отговарят на настройките по подразбиране.
- Как и къде се съхраняват данните? Повечето безплатни инструменти оставят на вас да управлявате съхранението на данни за производителността. Внимавайте с „безплатно“ наблюдение от доставчици в облак. Те таксуват за съхранението и това може бързо да стане голямо и скъпо!
Така че, по всякакъв начин, използвайте безплатните инструменти, които са там. Просто имайте предвид техните ограничения и внимавайте за класическите анти-модели във вашия екип, като например:
- Повече време, прекарано в поправяне или поддръжка на инструмента, което използва за отстраняване на проблеми
- Повече пари, изразходвани за инфраструктура и съхранение
- Много данни, но без прозрения
- Няма достатъчно дълбочина в диагностиката за решаване на проблеми
- Не е достатъчно мащабируем, за да отговаря на вашите нужди
Ако забележите някое от горните, това трябва да сочи към необходимостта от надстройка до по-стабилно решение.
Типична архитектура на система за наблюдение на SQL сървър
Когато обмисляте дали да изберете традиционно локално решение или хостван софтуер като услуга (SaaS), полезно е да вземете предвид архитектурата на приложението за наблюдение. Ето обобщение на ключовите архитектурни компоненти.
Основното отклонение между SaaS и on-premises е свързано с това къде се съхраняват данните за производителността и кой управлява това хранилище. За локално решение това е отговорност на крайния потребител. Тези хранилища могат бързо да станат големи, така че трябва да бъдат внимателно управлявани. Инфраструктурата трябва да бъде планирана и бюджетирана (повече по-долу).
В SaaS решение за мониторинг на SQL сървър тези ключови инфраструктурни компоненти се хостват и управляват вместо вас.
| Традиционно локално решение | SaaS решение |
|
|
За повече подробности вижте нашия блог, Архитектура на системата за мониторинг на бази данни.
