10 Колекционери с отворен код за централизирана сеч

Разликата между посредствените продукти и страхотните продукти е сеч. Научете защо е така и как да свържете всичко това заедно.


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

Преди да преминем към централизираното регистриране, нека първо разгледаме защо регистрацията е толкова голяма работа.

Два вида (нива) на сеч

Компютрите са детерминизирани системи, освен когато не са.

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

Сега, както виждам, сечта е от два вида: автоматично генерирано трупи и програмист генерирани трупи. Моля, обърнете внимание, че това не е различие в учебниците и цитирането ми в тази терминология ще ви създаде проблеми. ��

Изображението по-горе показва какво може да се нарече като автоматично генериран дневник.

В този конкретен случай това е система на WordPress, регистрираща неочаквано условие (Известие), когато стартира някакъв PHP код. Журнали като тези се генерират неуморно през цялото време – от инструменти за база данни като MySQL, уеб сървъри като Apache, езици и среди за програмиране, мобилни устройства и дори операционни системи.

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

Но автоматично генерираните регистрационни файлове могат да помогнат само толкова много. Ако например няколко души имат администраторски достъп до сайт и някой от тях се случи да изтрие съществена информация, не е възможно да се открие виновникът с използването на автоматично генерирани регистрационни файлове. От гледна точка на системите, свързани като приложението, това беше просто още един ден в работата – някой имаше необходимите правомощия за изпълнение на задача и системата я изпълни.

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

Източник: joomlatools.com

Записването е сила

И така, като се имат предвид тези два типа трупи в системата, ето как можете да ги използвате и да увеличите въздействието.

Да останеш пред клиента

„Удоволствие на клиентите“ стана известен като безполезен маркетингов трик, но благодарение на вписването, той може да стане много истински. Знам за дигитални продукти, които следят своите журнали като ястреб и веднага щом клиент счупи нещо на страницата, може да се обади на клиента и да предложи да помогне.

Само помислете за това – в рамките на секунди след като получите грозна грешка, получавате обаждане от компанията, което казва: „Ей, разбирам, че се опитвахте да добавите този продукт в количката, но той продължаваше да умира. Добре ли е да добавя този път и да попълня поръчката за вас? “

Възхитен клиент? Вие залагате!

Екип на морала и производителност

Както казах преди, когато бъговете продължават да бъдат непроследени за дълго време, разработчиците във вашия екип се обезсърчават и губят все повече и повече време, преследвайки опашките си. И тук е нещата с отстраняването на грешки – това изисква свеж, любопитен ум от самото начало. Ако WTF мисли толкова много, колкото влезе в мозъка ви, целият процес преминава към хвърляне.

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

Особено си спомням случай, в който молбата не отговаряше и никой не знаеше защо. Няколко дни по-късно виновникът беше достигнатия лимит на дисковия вход / изход поради прекомерния трафик. Понеже никой не си направи труда да погледне там, никой не можеше да разбере защо.

Одитни пътеки

Какво става, ако две години по линия на клиента ви кажат, че всички тези поръчки не са направени от тях, а от някакъв хакер?

Какъв аргумент би трябвало да забавлява или отхвърля искането им? Ако имате обширна регистрация (IP адрес, дата и час, кредитна карта и т.н.), ще можете да анализирате всичко това и да вземете решение. Добър или лош, той ще има поне някаква обективна основа, вместо да прилича на изстрел в тъмното.

Източник: подпис-reads.com

Същото е вярно, ако попаднете под някаква регулаторна леща или се изисква да преминете одит на трети страни като част от нов, важен проект. Ако нямате здрава система за регистрация, ще ви покажете в лоша светлина.

Подобряване на съществуващите системи

Как ще подобрите текущата система?

Трябва ли просто да хвърлите повече RAM и CPU нишки към него? Какво става, ако приложението ви е бавно, въпреки достатъчно ресурси? Къде е тясното място? Отговорът е по-често, отколкото не.

Например, всички основни системи от бази данни разполагат с функция за регистриране бавни заявки.

Източник: speedawarenessmonth.com

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

Няма преброяване по колко начина ви помага дадена добра система за регистриране. Може би най-добрият аргумент е, че това е автоматизирана дейност, която веднъж е настроена, няма нужда от мониторинг и ще ви спести от разруха някой ден.

Като изключим това, нека разгледаме някои от невероятните отворени източници на дневници с отворен код (унифицирани инструменти за регистриране). Само в случай, че се чудите, в по-ранна публикация покрихме комерсиални инструменти, базирани на облаци.

Graylog

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

Докато Graylog е централизирана система за регистрация, той има необходимата гъвкавост, което ви позволява да персонализирате сигнали, табла за управление и други.

Greylog е отворен код, но има бизнес план, ако вашите нужди са сложни.

С клиенти като SAP, Cisco и LinkedIn в списъка си, Graylog е инструмент, на който можете да се доверите със затворени очи.

Logstash

Ако сте фен или потребител на стека Elastic, Logstash си струва да проверите (стека ELK вече е нещо, в случай че не сте знаели). Подобно на други инструменти за регистриране в този списък, Logstash ако е напълно отворен код, което ви позволява свободата да разполагате и използвате по ваше желание.

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

Разбира се, единственото ограничение е, че работи само с пакета от продукти Elastic, но ако започвате и искате скоро да мащабирате, Logstash е начинът да продължите!

Fluentd

Сред централизираните инструменти за регистрация, които работят като среден слой за приемане на данни, Flutend е първа сред равни. С отлична библиотека с плъгини, Fluentd е в състояние да улавя данни от практически всяка производствена система, да я замесва в желаната структура, да изгражда персонализиран тръбопровод и да го подава към любимата си платформа за анализи, било то MongoDB или Elasticsearch.

Fluentd е изграден върху Ruby, е изцяло отворен код, и е широко популярен поради своята гъвкавост и модулност.

С големи компании като Microsoft, Atlassian и Twilio, използващи платформата, Fluentd няма какво да докаже. ��

воденичен улей

Ако наистина наистина големи масиви от данни са вашето предизвикателство и в крайна сметка искате да подадете всичко в нещо като Hadoop, воденичен улей е един от най-добрите възможности за избор. Това е „чист“ проект с отворен код, в смисъл, че се поддържа от нашата любима фондация Apache, което означава, че няма бизнес план.

Това може или не е това, което точно търсите. ��

Източник: извънcoder.com

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

Octopussy

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

Според мен Octopussy покрива нуждите на повечето продукти навън (прогнозните статистически данни са безполезни, но ако трябваше да предполагам, бих казал, че се грижи за 80% от случаите на употреба в реалния свят).

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

LOGalyze

LOGalyze беше търговски продукт, който наскоро беше направен с отворен код. Въпреки че не можах да направя проекта в GitHub, те правят инсталатор на Windows и всички изходни кодове могат да се изтеглят.

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

LOGalyze е сравнително гъвкаво и мощно предложение, което ще работи добре за едносистемни внедрявания, които се стремят да комбинират логване от известни източници като Postfix, Apache и др., И да произвеждат резултатите в CSV, PDF, HTML или подобни формати. Да, това не прави всичко, но тъй като едно време беше търговски продукт, това го прави доста добре.

LogPacker

Що се отнася до избора на инструмент за работата, имам два критерия: той трябва да бъде съсредоточен и трябва да бъде подкрепен от активен бизнес модел. Проблемът със софтуера с отворен код, като цяло, е, че няколко месеца / години надолу шансовете за стагнация или смърт са високи. Няма брой на колко инструмента за регистриране с пълна сила са били пуснати, само за да бъдат намерени сега в гробището на GitHub.

Измерва се с този мерник, LogPacker е фаворит за мен.

Както можете да разберете от екранната снимка, LogPacker се отнася до дневници и нищо друго. Техният тласък определено е към облачните им предложения, но вие сте повече от добре дошли да ги изтеглите и инсталирате на сървърите си (страница на GitHub тук).

Клъстеризирането и обобщаването са достъпни за тези, които искат да го използват в нетривиален мащаб, и са налични корпоративни планове, които искат да работят с API или се нуждаят от по-големи внедрения. Според мен един освежаващо минималистичен (съсредоточен, макар и не беден на функции) поема управление на сеч, според мен!

Logwatch

Сигурен съм, че има и такива сред нас, които не искат цялата церемония, свързана с „единна“, „централизирана“ система за регистрация. Техният бизнес идва от единични сървъри и те търсят нещо бързо и ефективно за гледане на техните лог файлове. Е, кажи здравей Logwatch.

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

Ако сте наркоман от CLI и обичате старата школа да правите нещата, ще харесате Logwatch!

Syslog-нг

Най- Syslog-нг инструмент е разработен като начин за обработка на syslog (установен клиент-сървър протокол за системно регистриране) файлове с данни в реално време. С течение на времето обаче се стигна до поддръжка на други формати на данни: неструктуриран, SQL и NoSQL. Как работи протоколът syslog, е добре обобщен в следващата илюстрация.

Syslog-нг е надежден инструмент за събиране и класифициране на дневници, който е написан на C и дълго време е утвърдено име в индустрията. Най-добрата част е нейната разширяемост, която ви позволява да пишете плъгини в C, Python, Java, Lua или Perl.

LNAV

Кратко за (Log Navigator), LNAV е чист терминален инструмент, който работи на една машина, една директория. Той е за онези, които регистрират регистрацията си в една директория или искат да филтрират и показват дневници в реално време от един източник.

Ако смятате, че lnav не е нищо повече от прославен tailf | grep, ще сбъркате. Има няколко функции, които ще ви накарат да се влюбите в него: изглед на времеви серии, красиво отпечатване (за JSON и други формати), цветно кодирани източници на журнали, мощни филтри, възможност за разбиране на няколко протокола за регистрация и други.

Просто понякога искате нулева караница, нулева настройка, може би временен слой за логване и lnav пасва перфектно на сметката!

заключение

И там го имате!

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

От глупави команден ред, без инструменти за настройка до пълноценни джунглаутчета за данни, всичко е тук! Пропуснах ли нещо? Разбира се, че го направих! Моля, уведомете ме в коментарите и ще се радвам да го добавя тук (разбира се, с кредити!).

ЕТИКЕТИ:

  • Отворен код

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map