Trzymanie i przeglądanie dużej ilosci logów


#1

W appce nad którą pracuję chcę zrobić bardzo dobre logowanie, które pozwoli łatwo odkryć przyczynę problemu. Pliki tekstowe odpadają.
Ogólnie log będzie miał format mniej więcej taki:

[user_id][request_id][some, tags, foo, bar] message

Chodzi o to bym mógł łatwo przeczytać wszystkie wiadomości dla usera_1 i requestu id =12342143 filtrując po tagach some i bar. Fajnie by było jakby się dało takie zapytania definiować.

Dodatkowo logi będą zbierane z większej ilosci maszyn. Znacie takie narzędzia?

PS. Z radością przywitam wszelkie linki do porad jak zrobić dobre logowanie.

EDIT Pliki tekstowe odpadają, bo łączenie danych z kilku serwerów jest bolesne.


#2

hmn zapis do plików csv? wystarczy później je przez jakiś prosty parser przemaglować i będzie Ci zwracało pożądane wpisy.

EDIT:
alternatywne rozwiązanie (na szybko zrodzone w mojej chorej głowie:) ) to nie mogłoby wiązać się z zapisywaniem do bazy danych i archiwizacji? ostatnio akurat miałem na uczelni co nieco o hurtowniach danych - temat powinien Cię zainteresować :slight_smile:

EDIT2:
Materiał z wiki może rozjaśni Ci co nieco: http://pl.wikipedia.org/wiki/Hurtownia_danych
Lub slajdy mojego wykładowcy: http://www.cs.put.poznan.pl/kjankiewicz/hd_zaoczne_iwpb.shtml


#3

Raczej mi chodzi o coś w stylu greylog 2.


#4

Jeżeli to może być hostowane zewnętrznie, to możesz spróbować np. https://papertrailapp.com/

Wiem też, że niektórzy używają http://www.lwes.org/, jest szybki i wysyłasz informacje we wcześniej przygotowanych strukturach, więc możesz zamieścić różnego rodzaju dodatkowe info. tenderlove mówił, że tego u nich w AT&T używają i że sie dobrze sprawuje.

Ilya pisał kiedyś o splanku: http://www.igvita.com/2008/10/22/distributed-logging-syslog-ng-splunk/

Facebook używa ichniego scribe’a: https://github.com/facebook/scribe

Rozwiązania dla hurtowni danych to kobyły, do logowania moim zdaniem to się nadawać nie będzie.


#5

następna opcja to Kibana + ElasticSearch + Fluentd http://docs.fluentd.org/articles/free-alternative-to-splunk-by-fluentd

Duża ilość logów czyli ile MB|GB|TB/day ?


#6

aha - bo w sumie do tej pory byłem przekonany, że zbieranie logów to też zalicza się do kobyły - dzięki za uświadomienie :slight_smile:


#7

To jeszcze zależy od wielkości tych logów, od tego co dokładnie nazwiemy “hurtowniami danych” i do czego chcesz tego używać. Wydaje mi się, że nawet do niektórych systemów, które są podlinkowane powyżej można by zastosować definicję hurtowni danych. W mojej wypowiedzi bardziej mi chodziło o to, że z reguły systemy, których się używa do hurtowni danych są wielkimi kobyłami, więc imho nie warto w poszukiwaniach się kierować w tą stronę, ale raczej w stronę rozwiązań, które są wykorzystywane konkretnie do zbierania logów (i tutaj czy już je nazwiesz hurtowniami danych czy nie, to jest inna sprawa, w wielu przypadkach może to być zasadne).


#8

Generalnie ja zawsze używałem do tego bazy danych.

w application_controler.rb

def set_request
Thread.current[:current_request] = request
end

id :integer not null, primary key

tags: array / text (array dla PG)

message: text

env: string

session_id :string(255)

request_id :string(255)

user_agent :text

ip :string(255)

page_url :text

language :string(255)

created_at :datetime not null

updated_at :datetime not null

class DbLogger < AR::Base
def log(*tags, message)
request = Thread.current[:current_request]
create!(
:env => Rails.env.to_s,
:tags => tags,
:message => message,
:ip => request.remote_ip,
:user_agent => request.user_agent,
:language => request.env[‘HTTP_ACCEPT_LANGUAGE’].to_s.scan(/^[a-z]{2}/).first,
:page_url => request.fullpath,
:session_id => request.session_options[:id],
:request_id => request.uuid,
})
end

%w[ error notice debug info ].each do |m|
define_method(msg) do lwrite(m, msg)
end
end

Po czym Rails.logger= DbLogger

oczywiscie dużo to pseudokod, piany na szybciocha, ale jak postawisz piwo to opakuję to ładnie w gema, szczególnie że uzywam 2 czy 3 różnych wersji tego rozwiązania w różnych projektach.

Indeksujesz oczywiscie po tagach, session_id, request_id itp. Jak uzywasz jak człowiek postgresa to ustawiasz GIN indeks (albo ten drugi nie pamiętam który daje szybszy insertion) na tags i masz piększne indeksowanie tablic.
Logi wyciągasz prościutko poprzez konsole SQL lub używajac railsowego modelu.

PS. Dla Mongo: https://github.com/customink/central_logger - można się zawsze wzorować.


#9

Gadałem niedawno na lokalnym user group z jednym kolesiem, który próbował użyć ElasticSearch do czegoś takiego. Przeszukują dużo logów i dotychczas grepowali po production.log, więc postanowili wrzucać to do ElasticSearch. Po paru miesiącach wrócili do grepowania po production.log, bo potrzebowali więcej maszyn z ElasticSearch do zapisu logów niż maszyn na produkcji do ich generowania.


#10

@slawosz: podałeś za mało szczegółów:

  1. O jakiej ilości danych mówimy? Jaki jest dobowy przyrost nowych danych (ile [mega/giga/tera]bajtów). Za jaki okres czasu masz logi i ile logi będą trzymane w czasie?
  2. Jaka jest charakterystyka zbioru danych:
    • ile jest user_id
    • czy request_id jest unikalny globalnie, czy jest unikalny tylko w w zbiorze user_id
  3. Jaki jest wymagany czas dostępu do danych, jaki jest akceptowalny czas, w którym dostaniemy wynik naszego zapytania. Będziemy przeszukiwać coś na żywo, czy raczej będziemy przygotowywać raporty (zapytania mogą trwać po kilka godzin i nas to nie boli).
  4. Rozumiem, że poprzez logi rozumiemy coś co tylko przyrasta (jedyne operacje to wstawianie nowych danych i odczyt). Dane nie będą modyfikowane, ani usuwane (np. usuwamy dane na życzenie klienta).

Jeśli danych będzie mało tj. w przeciągu najbliższego roku nie przewidujesz więcej niż kilkadziesiąt-kilkaset gigabajtów danych to możesz spróbować iść w bazy danych. PostgreSQL, czy też oracle, gdy będzie dobrze skonfigurowany i będzie działał na dobrym sprzęcie to sobie powinien z tym poradzić, chyba że zajedzie go liczbą zapytań.

Jeśli danych masz więcej (u mnie w firmie średni dobowy przyrost logów to kilkaset gigabajtów po spakowaniu z ratio 85-90%) to możesz iść albo po prostu w pliki tekstowe, albo uszyć coś swojego.


#11

Niekoniecznie. Jeśli pierwszą wartością będzie timestamp czy inny sensownie sformatowany czas to sort -m nie musi boleć.


#12

Odswieze topic, bo moze sie komus przydac. Otoz obecnie uzywamy splunk’a, ktory agreguje logi z plikow i jest genialny. Nie tylko jest w stanie fajnie wyszukiwac, ma wiele innych mozliwosci takie jak funkcje agregacji itp. Polecam!


#13

W Nokaucie część logów pchaliśmy do logstasha, który pod spodem miał ElasticSearcha. Całkiem dobrze działało.


#14

+1 logstash


#15

Odświeżam.

Z czego korzystacie w roku 2015?

Zestawiłem ELK, jest bardzo przyjemne do agregowania logów ustrukturyzowanych, natomiast wydaje się lekką przesadą dla danych, których nie chcę aż tak szczegółowo analizować.