Category: Наблюдение и управление

Експлоатация на сървъри. Част 1. Натоварване

  • Кое е оптималното натоварване на един сървър?
  • Под какво натоварване може да смятаме, че инфраструктурата се използва неефективно?
  • Над какво натоварване считаме, че сървърът е претоварен?

В тази статия ще дам някои насоки и възможни отговори. IT инфраструктурата е комплекс от много взаимозависимости и няма еднозначен отговор. Освен това натоварването само по себе си не е проблем, проблем са страничните ефекти от него.

Винаги, когато планираме и експлоатираме IT инфраструктура (за целите на статията нека разглеждаме уеб сървър), следва да отчитаме TCO (Total Cost of Ownership) като параметър. Като пример за важността – в рамките на средностатистическия полезен живот на хардуера, управлението на електрическата консумация е съществена необходимост (грубо може да се приеме, че 10% от свързания оперативен разход подлежи на оптимизация).

Изключително важно е да си осигурим добра видимост към инфраструктурата, което предполага тотален (но разумен и не изкривяващ профила на натоварването) мониторинг върху работата на системите. Добрият мониторинг дава възможност за предвиждане и изследване потенциалните проблеми още преди да сме стигнали до етапа на продукция.

Нещата са кардинално различни, ако ги оценяваме в клауд инфраструктура (т.е. имаме чиста себестойност от тип „сървис като инфраструктура“) или уебсървъра работи върху „собствен“ сървър, консумиращ „собствено“ електричество и топлоотделящ в „собственото“ помещение, което отново „собствено“ охлаждаме. На тази тема ще посветя една от следващите статии.

TCO зависи от хардуера и начина, по който го експлоатираме. Най-силна и видима е зависимостта от броя и типа сървърни захранвания. Това е така, защото ефективността на захранването е най-висока, ако натоварването му е над 60% и оптимална при ~80%.

Ако сървърът е слабо натоварен, с малко памет и дискове – консумацията му е ниска и ако използва две балансиращи натоварването захранвания – то всяко от тях ще работи извън оптималния си режим.

  • В този случай е необходимо ръчно конфигуриране за работа в режим hot/cold stand-by на едно от захранванията
  • Така другото ще се натовари повече и ще работи в оптималните граници
  • По-новите сървъри поддържат автоматизирано управление на консумацията, но е необходимо да са включени в съответния режим (обикновено не е по подразбиране)

От гледна точка разходи за електричество – колкото повече натоварите сървъра – толкова по-добре, стига системата да се държи предвидимо. Друга зависимост се проявява в случаите, когато сървърът работи върху bare metal или виртуализиран хардуер. Ако е виртуализиран, хайпървайзъра ще се погрижи голямо натоварване (70%+) на сървъра да не се отрази (в някакви граници) на латентността на другите виртуализирани услуги.

Някои конкретни съвети

Насочени са основно към системни администратори и devops. Всъщност препоръчително е CIO и IT мениджърите да са наясно с материята, доколкото TCO и качеството на услугите са тяхна отговорност.

  • Някои комбинации сървърен софтуер (например Apache/PHP) предизвикват и въобще са чувствителни към латентност. Не допускайте в продукция всичко да зависи от фронтенд перманентно натоварен над, да речем, 50%, защото:
    • Няма място за реакция на инцидентни (пикови натоварвания)
    • Влияе и усложнява откриването на други свързани или несвързани проблеми
    • В крайна сметка усложнява и оскъпява експлоатацията на цялостната система
  • Планирайте и от самото начало използвайте лоудбалансър(и) и поне два фронтенда
    • Може да бъдат виртуализирани напълно или да се използва хибридна схема за оптимално TCO
    • Когато натоварването нарастне, за да си струва – тогава може да преминете към bare metal хардуер
  • В общи линии най-изгодно е инфраструктурата да е виртуализирана (контейнеризирана в частност)
  • Контролирайте (по възможност) архитектурата на приложението и качествения код на разработчиците
  • По възможност (особено, ако разработвате бизнес критични системи) избягвайте да съчетавате множество функции в един сървър (например уеб, дейтабейс, файлов и прочие)
    • Ако това не е възможно – оставете достатъчно резерв например средно натоварване на сървърен процес под 20% (за да имате резерв за абсорбиране на пикови натоварвания)
    • Не лош вариант е да управлявате прецизно натоварването в рамките на един сървър с cgroups, но е доста времеемко, а крайният резултат не винаги е достатъчен и често проблемите само се отлагат за известно време

В тази връзка препоръчваме виртуализация на ниво сървърна услуга (например уеб сървър), а още по-добре контейнеризация, защото получавате възможност за много по-фино настройване на производителност и отказоустойчивост и прецизен контрол по отношение на сигурност. Повече по темата:

Виртуализация –

Контейнеризация –

Traccar

Кратко описание

Traccar е Java базиран GPS tracking сървър. Поддържа практически всички популярни протоколи и устройства и е изключително подходящ за организации, които искат да следят, визуализира и анализират движението на устройства и превозни средства.

Вградените му възможности за визуализация и анализ го правят приложим както за автоматизация дейността на център за експлоатация в организацията, но така също и за извършване на бизнес анализ в областта на проследяването на превозни средства (AVL – Automatic Vehicle Location).

Подходящ за:
  • Бизнес аналитична дейност в организацията
  • AVL
  • Споделяне на информация в организацията и външни потребители
  • Поддръжка на активни и атрактивни табла за визуализация
  • Изпращане на съобщения при достигане или промяна на ключови параметри 
Неподходящ за:
  • В размките на своята ниша, Traccar е подходящ за всички дейности
За повече информация:
Защо Traccar:
  • Предлага цялата си функционалност в безплатна версия
  • Документацията е на приемливо ниво
  • Интеграция с LDAP
Недостатъци:
  • Traccar е монолитно java приложение и предполага грамотно поддържана база данни и сървърен ресурс
Оценка на необходимите ресурси при внедряване:
  • Лесно и бързо внедряване
Степен на завършеност на решението:
  • Завършено
Съвети към IT мениджъра:
  • Струва си – Traccar е функционална AVL система

ELK Stack – Elastic Stack

Кратко описание

Elastic Stack (известен по-рано като ELK Stack) е решение за обработка на лог информация. Представлява лог сървър с вградени колектор, процесор, система за съхранение, обработка, анализ, визуализация и изпращане на алерти, базиран е на отворен и свободен код.

Основните му компоненти са:

  • Elastic Search – система за съхранение и индексиране на информацията
  • Logshtash – система за събиране и препроцесинг на log информация
  • Beats – система от агенти за събиране на информация и изпращане към централната система
  • Kibana – система за визуализация и обработка на информацията

Еластик стек е дефакто стандарт за събиране и управление на лог информация, особено в клауд инфраструктура. Позволява изграждане на системи за наблюдение и анализ бизнес клас. Накратко:

  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Богата функционалност в основна безплатна версия
  • Наличие на комерсиални версия и поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите

Подходящ за:

  • Внедряване на надеждни системи за събиране и управление на логове
  • Средство да получите и централизирано обработите/съхраните цялата необходима информация за отстраняване на проблеми и увеличаване на ефективност
  • Единна система, която може да агрегира лог информация от локални, отдалечени и клауд базирани източници
  • Може да бъде използван както за наблюдение на системи и инфраструктура, така също на приложения и услуги
Неподходящ за:
  • В рамките на специализацията си като лог сървър, Elastic Stack е подходящ да изпълнява всевъзможни задачи
За повече информация:
Защо Elastic Stack:
  • Много добър за проактивен мониторинг на сървъри, системи, цели инфраструктури и услуги
  • Поддържа всевъзможни лог формати
  • Множество плъгин модули, които разширяват съществуваща или добавят нова функционалност
  • Добре се вписва в корпоративна среда (LDAP) 
  • Добра интеграция и поддръжка от Elastic
  • Може да се използва като SIEM система, дори в безплатната версия, но все още липсват съществени интеграции, които има в специализираните за целта средства (като например AlienVault OSSIM)
  • В платената версия има ML (Machine Learning) възможности за специализиран лог анализ
Недостатъци:
  • Непълна поддръжка на организационни йерархии (multitenancy)
  • Няма много материали на български език
Оценка на необходимите ресурси при внедряване:
  • Инсталация на ELK- при използване на базови настройки за малка до средна инфраструктура – лесна. 
  • Предлагат се готови контейнер базирани инсталации за всички популарни клауд и контейнер инфраструктури
  • Има вградена поддръжка на разпределена инфраструктура, както за приемане, така и за обработка и съхраняване на лог информация
    • Необходимите ресурси са в линейна зависимост от големината и комплексността на наблюдаваните системи, мрежи и услуги
  • Добре се вписва в налични среди за виртуализация
  • Добра документация
Степен на завършеност на решението:
  • Напълно завършено решение, но в безплатната версия са необходими множество времеемки интеграции, за да е напълно функциoнален. 
Съвети към IT мениджъра:
  • Elastic Stack е особено подходящ да замени класически лог сървъри (rsyslog, syslog-ng) като централен агрегатор и процесор на лог информация
  • Архитектурата му позволява да работи практически във всякакъв мащаб – от събиране на информация от няколко хоста до големи комплексни системи, които генерират огромен брой съобщения и трафик
  • Допълнително разработените агенти (beats) позволяват мониторинг на всевъзможни системи
  • Позволява изграждане на напълно функционална система без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • ELK е изключително всеобхватен и универсален продукт – поради това е необходимо да се инвестира време, за да се използват ефективно пълните му възможности. 

 

Graylog

Кратко описание

Graylog е лог сървър с вградени колектор, процесор, система за съхранение, обработка, анализ, визуализация и изпращане на алерти, базиран на отворен и свободен код. Позволява изграждане на системи за наблюдение и анализ бизнес клас. Накратко:

  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Богата функционалност в основна безплатна версия
  • Наличие на комерсиални версия и поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите

Подходящ за:

  • Внедряване на надеждни системи за събиране и управление на логове
  • Средство да получите и централизирано обработите/съхраните цялата необходима информация за отстраняване на проблеми и увеличаване на ефективност
  • Единна система, която може да агрегира лог информация от локални, отдалечени и клауд базирани източници
  • Може да бъде използван както за наблюдение на системи и инфраструктура, така също на приложения и услуги
Неподходящ за:
  • В рамките на специализацията си като лог сървър, Graylog е подходящ да изпълнява всевъзможни задачи
За повече информация:
Защо Graylog:
  • Много добър за проактивен мониторинг на сървъри, системи, цели инфраструктури и услуги
  • Поддържа всевъзможни лог формати
  • Множество плъгин модули, които разширяват съществуваща или добавят нова функционалност
  • Добре се вписва в корпоративна среда (LDAP) 
  • Поддръжка на организационни йерархии (multitenancy)
  • Поддръжка на потребители и групи
  • Допълнително REST API
Недостатъци:
  • В безплатната (за разлика от платената) версия липсва механизъм, за правене на корелации между регистрираните и обработени събития
    • Все пак, с помощта на допълнителни плъгин модули е възможно да се постигне приемливо корелиране
  • Дребно неудобство – не поддържа стандартни лог портове, например UDP514, тъй като Java машината не работи с привилегировани портове
  • Няма много материали на български език
Оценка на необходимите ресурси при внедряване:
  • Инсталация на Graylog – при използване на базови настройки за малка до средна инфраструктура – лесна
  • Има вградена поддръжка на разпределена инфраструктура, както за приемане, така и за обработка и съхраняване на лог информация
    • Необходимите ресурси са в линейна зависимост от големината и комплексността на наблюдаваните системи, мрежи и услуги
  • Добре се вписва в налични среди за виртуализация
  • Добра документация
Степен на завършеност на решението:
  • Завършено решение, макар че по отношение на визуализация има какво да се желае
    • Има положителна тенденция в последните години за развитие на тази функционалност
    • Относително лесно е да се добави и използва външна технология за визуализация, например Grafana
Съвети към IT мениджъра:
  • Graylog е особено подходящ да замени класически лог сървъри (rsyslog, syslog-ng) като централен агрегатор и процесор на лог информация
  • Архитектурата му позволява да работи практически във всякакъв мащаб – от събиране на информация от няколко хоста до големи комплексни системи, които генерират огромен брой съобщения и трафик
  • Позволява изграждане на напълно функционална система без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • Kривата на обучение е приемлива, дори администратори с малко опит бързо усвояват необходимите умения, за да го използват ефективно

 

Security Onion Hybrid Hunter

Кратко описание

Security Onion Hybrid Hunter е следващата версия на Security Onion и текущо е в алфа тест. Отделям внимание на този незавършен продукт, защото като замисъл тази версия трябва да отстрани основните недостатъци на SO и може би си струва да се изчака и евентуално използва SO HH за реализация на мащабни open source SIEM системи в големи организации. 

За повече информация:
Защо Security Onion Hybrid Hunter:
  • SO-HH вероятно ще реши проблемите на SO като добави интегрирани възможности за корелация, анализ и управление на действия
  • В допълнение – модерната, базирана на контейнери архитектура на HH, би могла да предопредели дълъг живот и улеснена поддръжка на системата
Недостатъци:
  • На този етап е рано да се прецени
Оценка на необходимите ресурси при внедряване:
  • Тъй като SO HH представлява appliance – инсталацията и базовата конфигурация на сървър и агенти е лесна и бърза
  • Началната конфигурация – стартиране на базов мониторинг на сигурността, отнема 4-8 часа
  • Разширени конфигурации – рано е за оценка
  • Дори за средна по мащаб на използваните информационни технологии организация, е необходимо да се осигури хардуер, способен да осигури необходимата производителност
  • Добре се виртуализира и може да спестите използването на физически сървър. Все пак – отделете необходимия ресурс. 
Степен на завършеност на решението:
  • Ранна алфа версия
  • Множество проблеми
Съвети към IT мениджъра:
  • Изчакайте. SO HH може да е добра основа за изграждане на SIEM решение за Вашата организация. 
  • Никога не считайте, че използването на SIEM система и каквато и да е технология за защита е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

Security Onion

Кратко описание

Security Onion е SIEM (Security Information and Event Management) система с отворен код и представлява Linux дистрибуция за откриване на прониквания, наблюдение на сигурността на организацията и управление на логове. Основни функции:

  • Събиране на информация от мрежата в реално време (full realtime packet capture)
  • Мрежови и хост-базирани системи за откриване на проникване (NIDS и HIDS)
  • Мощни инструменти за анализ

Включва:

  • ELK Stack – Elasticsearch, Logstash, Kibana – събиране, съхранение, обработка и визуализация на информация
  • Snort – използва се като система за откриване на проникване базирана на правила (Rule driven IDS  – Intrusion Detection System)
  • Suricata – използва се като система за откриване на проникване базирана на правила (Rule driven IDS  – Intrusion Detection System)
  • Bro – използва се като система за откриване на проникване базирана на анализ (Analysis driven IDS  – Intrusion Detection System)
  • OSSEC – хост базиранa системи за откриване на проникване (HIDS)
  • Wazuh – използва се като система за откриване на проникване в сървъри (Host based IDS  – Intrusion Detection System)
  • Sguil – Система за анализ
  • Squert – Уеб интерфейс към Squil
  • И много други инструменти за сигурност

Security Onion представлява колекция от инструменти, предназначени да подпомогнат процеса на поддръжка на информационната сигурност – откриването, управление на последици и предотвратяване на прониквания. Представлява security appliance – специализирана Линукс дистрибуция, работеща върху отделен физически или виртуализиран сървър. Поддържа агенти, които могат отдалечено да събират и изпращат информация към разпределената система за обработка и визуализация. SO предоставя на системни и мрежови администратори, DevSecOps и аналитици в областта необходимите средства за събиране, обработване, анализ, представяне и визуализация на информация. 

Подходящ за:
  • Поставяне основи на SOC (Security Operations Center) на организацията
  • Управление информационната сигурност на голяма организация – SO позволява изграждането на разпределена система от колектори, процесори на информация и сторидж системи
Неподходящ за:
  • Решаване на проблемите с информационната сигурност в организации, които нямат съответните човешки ресурси
За повече информация:
Защо Security Onion:
  • Зрял проект с дългогодишно развитие и широка база от разработчици на много от неговите компоненти
  • Предлага съществена функционалност в безплатна версия
  • За разлика от конкурентни продукти (например AlenVault OSSIM) има вграден и много добър механизъм за събиране, обработка и визуализация на логове (ELK stack)
  • Има комерсиална поддръжка
  • Безплатната версия има относително добра документация, както и някаква поддръжка от общността на потребителите
Недостатъци:
  • Макар положените усилия за сглобяване и интегриране на различните средства, дистрибуцията е доста насипна и еклектична комбинация от отделни продукти, които в повечето случаи се конфигурират и управляват през множество разположени във файловата система конфигурационни файлове без единен интерфейс
  • Макар да решава много задачи,  SO не позволява изграждането на тотално, цялостно и автоматизирано решение за информационна сигурност
  • Липсват възможности за организиране на йейрархии и управление на действия при секюрити събития
  • Липсва единен механизъм за изпращане на алерти
  • Редки ъпдейти
Оценка на необходимите ресурси при внедряване:
  • Тъй като SO представлява appliance – инсталацията и базовата конфигурация на сървър и агенти е лесна и бърза
  • Началната конфигурация – стартиране на базов мониторинг на сигурността, отнема 2-4 часа
  • Разширените конфигурации са в зависимост от мащаба на организацията и може да са необходими много дни за постигане на удовлетворяващи резултати
  • Дори за средна по мащаб на използваните информационни технологии организация, е необходимо да се осигури хардуер, способен да осигури необходимата производителност
  • Добре се виртуализира и може да спестите използването на физически сървър. Все пак – отделете необходимия ресурс. 
Степен на завършеност на решението:
  • Насипно решение.
  • Някои компоненти работят добре и веднага, други изизкват много време за конфигурация. 
Съвети към IT мениджъра:
  • Security Onion е добра начална стъпка за осигуряване на информационна сигурност в голяма организация и може да се използва за обучение на персонал и развитие на вътрешна за организацията експертиза
  • Доколкото информационната сигурност е процес – развитието на SO в рамките на организацията е също непрекъсната и регулярна задача и следва да се подплати с необходимите хора, технически средства, време и обучение
  • Необходима е специализирана в областа на информационната сигурност експертиза
  • Ако нямате добри системни и мрежови администратори, R&D персонал и достатъчно време да поддържате насипно решение от различни компоненти с отворен код – по-скоро рано, отколкото късно – ще се наложи да търсите и мигрирате към комерсиално решение ИЛИ да аутсорснете информационната си сигурност към външна организация
  • Никога не считайте, че използването на SIEM система и каквато и да е технология за защита е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

AlienVault OSSIM

Кратко описание

AlienVault OSSIM (Open Source Security Information Management) е SIEM (Security Information and Event Management) система с отворен код, интегрираща набор от инструменти, предназначени да подпомогнат процеса на поддръжка на информационната сигурност – откриването, управление на последици и предотвратяване на прониквания. Представлява security appliance – специализирана Линукс дистрибуция, работеща върху отделен физически или виртуализиран сървър. Понастоящем, AlienVault OSSIM е част от AT&T Cybersecurity. 

OSSIM не само събира различни средства с отворен код, но ги интегрира в общ интерфейс за управление, обмен на данни, възможност за корелиране на събития и управление на инциденти свързани със сигурността. Така OSSIM предоставя на системни и мрежови администратори, DevSecOps и аналитици в областта необходимите средства за събиране, обработване, анализ, представяне и визуализация на информация. 

AlienVault OSSIM има автоматизирани механизми за събиране на инвентарна (сканиране на мрежи, детекция на операционни системи, работещи услуги) и лог информация. Сканира за уязвимости, управлява събития, техния контекст и взаимна корелация. Генерира аларми, предписания и ескалира действия в рамките на SOC (Security Operations Center) на организацията. 

Чрез активиране на сървър и агенти в различните офиси/локации на организацията, може да се обхване цялостната и дейност в единна система. 

Компоненти:

  • PRADS – използва се за идентифициране на хостове и услуги чрез пасивно наблюдение на мрежовия трафик
  • Suricata – използва се като система за откриване на проникване (IDS  – Intrusion Detection System)
  • Tcptrack – използва се за анализ на данни от TCP сесии, да предоставя полезна информация за корелиращите механизми
  • Munin – използва се за трафичен анализ и наблюдение на услуги
  • NFSen / NFDump – използва се за събиране и анализ на NetFlow 
  • FProbe – използва се за генериране на NetFlow от уловен трафик
  • Nagios – използва се за наблюдение на хостове и услуги
  • OpenVas – използва се за оценка на уязвимостта на наблюдавани хостове и услуги
  • В допълнение OSSIM включва разработени от AlienVault инструменти, като най-важният е генерален механизъм за корелация с логическа поддръжка на директиви и обработка на лог информация със специализирани процесори
Подходящ за:
  • Поставяне основи на SOC (Security Operations Center) на организацията
Неподходящ за:
  • Решаване на проблемите с информационната сигурност в организации, които нямат съответните човешки ресурси. 
  • Управление информационната сигурност на голяма организация – същественото ограничение е, че OSSIM обработва информацията само на един сървър
За повече информация:
Защо OSSIM:
  • Зрял проект с дългогодишно развитие и широка база от разработчици 
  • Предлага доста от необходимата функционалност в безплатната версия
  • Има комерсиална версия с повече възможности и разширена поддръжка
  • Безплатната версия има много добра документация, както и достатъчно надеждна поддръжка от общността на потребителите
  • Много добра документация, включително обучаващи клипове и редовни уебинари по различни аспекти на информационната сигурност
Недостатъци:
  • OSSIM е opensource вариант на комерсиален и скъп продукт, има мек натиск за преминаване към платената версия
  • Макар да решава много задачи, OSSIM не позволява изграждането на тотално, цялостно и автоматизирано решение за информационна сигурност
  • Съществуват дребни (но отнемащи време на администраторите на OSSIM) проблеми, които не се отстраняват с години. Все пак следва да се отчита, че големите проблеми се отстраняват достатъчно бързо
  • Редовните ъпдейти на OSSIM – няколко пъти седмично, отнемат доста време и понякога се налага отстраняване на проблеми предизвикани от самия ъпдейт
Оценка на необходимите ресурси при внедряване:
  • Тъй като OSSIM представлява appliance – инсталацията и базовата конфигурация на сървър и агенти е лесна и бърза
  • Началната конфигурация – стартиране на базов мониторинг на сигурността, отнема 2-4 часа
  • Разширените конфигурации, включително дефинирането на необходимите за спецификата на организацията корелационни правила, отнема време в зависимост от мащаба на организацията и може да отнеме дни
  • Дори за средна по мащаб на използваните информационни технологии организация, е необходимо да се осигури хардуер, способен да осигури необходимата производителност
  • Добре се виртуализира и може да спестите използването на физически сървър. Все пак – отделете необходимия ресурс. 
Степен на завършеност на решението:
  • Завършено в голяма степен решение, но в безплатната версия липсат необходими компоненти – например сървър за запазване и обработка на историческа лог информация
  • Необходимо е дефиниране нужните на организацията корелационни правила
Съвети към IT мениджъра:
  • Струва си – AlienVault OSSIM е добра начална стъпка за осигуряване на информационна сигурност и може да се използва за обучение на персонал и развитие на вътрешна за организацията експертиза
  • Доколкото информационната сигурност е процес – развитието на OSSIM в рамките на организацията е също непрекъсната и регулярна задача и следва да се подплати с необходимите хора, технически средства, време и обучение
  • Необходима е специализирана в областа на информационната сигурност експертиза
  • Ако нямате R&D персонал и достатъчно време да създавате корелатори на събития и отчети за конкретните си нужди на – по-скоро рано, отколкото късно – ще се наложи ИЛИ да преминете към комерсиалната версия ИЛИ да аутсорснете информационната си сигурност към външна организация
  • Никога не считайте, че използването на SIEM система и каквато и да е технология за защита е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

ZabDash и Grafana plugin за Zabbix

Кратко описание

Забикс предлага визуализация на състоянието на наблюдаваните мрежи и системи чрез табла за наблюдение (dashboard). Макар с течение на времето възможностите му да се развиват и подобряват, те все пак са относително ограничени.

Благодарение на разработеното API към Забикс могат да бъдат свързани външни системи за визуализация като ZabDash (добавка към Забикс) и плъгин за използване на популярното средство за визуализация – Grafana. 

Подходящ за:
  • Подобряване на възможностите за визуализация на Забикс при мониторинг на мрежи и системи.
  • Дефиниране на различни табла за наблюдение за различни групи потребители и цели
    • Администратори
    • Поддръжка от различни нива
    • Мениджмънт
Неподходящ за:
  • Самостоятелна работа
За повече информация:
Защо ZabDash и Grafana plugin:
  • Подобряване на възможностите за визуализация
  • По-добра представителност на извършваното наблюдение
  • Поддръжка на специализирани табла за наблюдение, които отговарят на специфични изисквания за дизайн и цветова схема
Недостатъци:
  • Все пак това са само визуализации и не заменят добрата конфигурация и смислените неща за наблюдаване
  • Развитието при ЗабДаш е по-бавно
Оценка на необходимите ресурси при внедряване:
  • И двете добавки се инсталират бързо и безпроблемно
Степен на завършеност на решението:
  • Завършени решения
  • И двете добавки разполагат с предефинирани табла и възможности.
    • Графана е в по-насипно състояние, но благодарение на своята архитектура дава повече възможности, но и повече работа. 
    • ЗабДаш e написан на PHP и добавянето на нови възможности е свързано с модификации на кода. Вградените му визуализации са много и покриват основни сценарии на използване
Съвети към IT мениджъра:
  • Струва си да разширите възможностите на Zabbix базираната система за наблюдение и управление с тези добавки

SLA Калкулатор

DevOps Roadmap 2020

Кратко описание

Това, според Kamran Ahmed, е DevOps технологичният стек за началото на 2020г. 

 

Съвети към IT мениджъра:
  • Без претенции за всеобхватност и валидност за целия devops спектър, схемата дефинира примерен модел, който може да се следва от технологичните организации за изграждане и поддържане на модерна IT инфраструктура
  • Схемата е особено подходяща за фукционална визуализация на devops и sysadmin процесите в организацията и идентифицирането на необходимите ресурси и технологично ноу-хау
  • Препоръчително е CIO и IT мениджърите да имат предвид или да разработят подобна схема, която да подпомага процеса на търсене на нови и обучение служителите на организацията
  • Не че е невъзможно, но не е препоръчително да реализирате целия технологичен стек без по-тясна специализация и разпределение на роли в екипа