Bästa svaret
Vi gjorde faktiskt en omfattande analys på Dun och Bradstreet Credibility Corp (inte att förväxla med D&B Proper), om loggfilanalys. Jag har använt Splunk sedan version 1.0 i liten kapacitet (det kunde inte hantera mycket då) och fem år senare på ett distribuerat sätt med flera noder med en 100G / dag-licens.
Jag har hittat att med Splunk har du ett brett utbud av konfigurationsalternativ, nästan för många om du vill. Om du vill lägga till ett nytt fält för att kunna sökas måste du redigera några konfigurationsfiler, ladda om din Splunk-server och sedan definiera dina frågor . Det är robust, men nackdelen är kostnad och komplexitet.
Logstash, det enda andra livskraftiga alternativet jag har hittat för Splunk bortsett från något hemma som Flume / Scribe (massor av ingenjörsarbete för att realistiskt gör detta) är utmärkt på de flesta sätt. Används i kombination med Kibana (http://rashidkpc.github.com/Kibana/) destillerar alla de bästa funktionerna i Splunk (som facetterad sökning, aggegations, topp tio fel, deltor , etc) till ett lättanvänt system. Kudos till Mr. Sissel för denna uppfinning, det är ett exempel på utmärkt programvara.
Men ven med ett system som Kibana / Logstash, är det ingenjörsarbete ansträngt, vilket väcker frågan, vill du konstruera vad du använder för att hitta problem och trender i din infrastruktur?
Svaret är, det beror på. Om du är ett stort företag (som Etsy) och har resurser, eller en dedikerad ingenjör för att hantera denna process, kanske det är vettigt. Om du är en liten butik med en liten budget, kommer du förmodligen inte att köpa något och kommer att hantera ansträngningen och tiden för att underhålla ett sådant system.
Om du är någonstans däremellan, så där saker blir svåra. Detta beror på:
1) Hur snabbt du behöver den här lösningen 2) Den verkliga kostnaden för denna lösning (”gratis” som i en gratis valp) 3) Kultur för köp mot byggnad 4) Pålitlighet och tillgängligt stöd
Det fanns många andra faktorer i vårt betygssystem, men det här är de viktigaste beslutspunkterna.
Vi bestämde i vårt fall att även om vi verkligen gillar Logstash måste det mogna lite innan den övervägs som en lösning är vi villiga att till exempel använda på produktionsmaskiner.
Dessa huvudskäl är: – Tillgängligt stöd (kommersiellt / icke) – Kräver dedikerad teknisk insats / ingenjörsdesign – Distro-stöd den ska förpackas i deb / rpm-paket) – JVM-fotavtryck (det verkar vara en 400M-process för oss, kanske detta var ett konfigurationsproblem. – Inga instrumentpaneler
I slutändan bestämde vi oss för SumoLogic, för det var : – snabb att distribuera (installera java binär, aktivera, installera nyckel, klar) – flera plattformar – avancerade instrumentpaneler – varning – rapportering – kraftfullare söksyntax
Svar
Det finns många bra produkter men Splunk var en av de första som använde en sökmotor för att indexera data och tillhandahålla analys över loggar på ett så flexibelt sätt.
Splunk skapades 2003. Det integreras med många källor eftersom samhället är starkt och har en mycket kraftfull transaktionssökningsfunktion. Ändå har Splunk yngre konkurrenter som utnyttjar de senaste ergonomiska och tekniska förbättringarna.
Är Splunk bäst? Som andra sa beror det verkligen på dina behov. Så kom ihåg dessa punkter och bestäm själv. Här är en hjärndump av vad som kan göra skillnad:
- Lokal vs SaaS: även om det definitivt är ledaren för lokala lösningar erbjuder många SaaS-konkurrenter en annan bra metod för att lösa maskindatautmaningen. Lokalt är vanligtvis dyrare, kräver mer underhållstid och versionuppdateringar är smärtsamma – men det garanterar också att dina data inte flyter ut ur din infrastruktur. Även om Splunk-Cloud är ett försök att ta Splunk till molnet så vitt jag förstod var de första versionerna inte framgångsrika och de avbröt tjänsten för att starta om den senare.
- Datakällor: vad är den information du vill ta in. Vilka källor vill du hantera? Vissa projekt är relaterade till loggar, mätvärden och ”datamaskin” och andra handlar mer om databasbackups, excel-filer. Splunk är en allmän lösning, SaaS-baserade lösningar är ofta mer specifika (och ofta bättre än generalister).
- Felsökning jämfört med applikativ BI: Splunk-användare tillbringar vanligtvis mycket av sin tid i huvudvyn, söker i loggar och använder den rörbaserade sökfältet. Splunk tillåter också användare att skapa instrumentpaneler från analyser – men de är ganska statiska och visar endast KPI. Och jag tror verkligen att det är en stor brist på Splunk.Indeed, om du nu vill tillhandahålla ett verktyg som kan användas av icke-tekniska personer i företaget – som kundsupport, försäljning osv …Du vill antagligen ha klickbara instrumentpaneler där någon enkelt kan skära och tärna och få svar snabbt. Kibana gör detta mycket bra som en öppen källlösning och för SaaS Logmatic.io har också den här fantastiska funktionen som verkligen gör en verklig skillnad.
- Vilka är dina slutanvändare ?: Är det ett verktyg bara för din IT-teamet, eller planerar du att lägga det i händerna på affärsmän som support-, marknadsförings- eller ledningsgrupper? I många projekt är framgångsnyckeln enkel att använda lösningen. Från min erfarenhet är Splunk för tekniskt och vanligtvis använder Devops det varje dag men det har rykte om att ha dålig användbarhet bland andra som graverar runt målapplikationer, även utvecklare … Nyare lösningar som de jag nämnde i den sista punkten ha bättre antagningsgrader.
- Hemgjord kontra produkt: som valet på plats vs SaaS, jag tror att det handlar mer om din affinitet , vill du ha ditt eget verktyg och ta dig tid att bygga det, eller en extern produkt med stöd. Om du bestämmer dig för att gå till ElasticSearch och Kibana: skulle det misslyckas när du behöver det mest så får ditt lag mycket tryck med ingen annan att hantera det. Med Splunk eller Logmatic.io, är supporten och rådgivningen över loggningsstrategier och andra relaterade ämnen vanligtvis riktigt effektiva. Du tar då vanligtvis bättre beslut och sover tätt.
Eftersom frågan var väldigt öppen var mitt svar lite långt men jag hoppas att jag gav lite vägledning och det hjälper till med ditt beslut!: )