KING: Aha, to sem tak nějak předpokládál že bude pro populární jazyky a frameworky vyřešené™. V tom případě lepší, než jsem myslel, díky.

ALMAD: 90% konfigurace je prave o parsovani tech logu. To bohuzel moc self- nejde. Proto ta poznamko o tom logovat v jsonu (nebo cemkoliv jinem strukturovanem) - pak tohle nemusis resit a mas vyhrano. Staci jen pridat nejake filtry na enrichment tech dat (geoip, useragent, dns, ...) a nakonfigurovat ES cluster coz je super jednoduche.

KING: papertrail unsupported? ;)

Ale zajimalo by me proc to nemuze byt selfconfigured. Prozkoumam vic to demo, diky.

SATAI: tak my si klidne take vezmeme vase penize, ale chapu :)

ALMAD: nene, tak jednoduche to zatim bohuzel neni, to bys musel pouzit to loggly nebo splunk (podle toho kolik mas penez a jestli chces aby to bezelo u tebe).

Z vlastni zkusenosti ale muzu rict, ze to neni nijak obtizne, staci rozjet Elasticsearch (pripadne http://found.no/) a pak nakonfigurovat ten logstash - coz ciste zalezi na aplikacich. Kdyz dokazes prinutit aplikace logovat v jsonu, mas vyhrano a veskery config je v tom mem Docker demu (vcetne fronty v redisu).

KING: ...tak právě skript co se zeptá na pár otázek a nastaví přes API? :)

ALMAD: tak to je v podstate to demo co jsem linkoval (jen pres docker compose, transpozice na ECS by mela byt easy). Problem je konfigurace - coz je 99% toho vseho a co se musi delat per-nasazeni. Do budoucna (logstash 2.0) by melo byt lepsi reseni kdy LS bude taky cluster a bude mit API na konfiguraci misto prosteho spolehani se na conf soubory. Pak to bude o hodne snazsi.

NIXIMOR: zajimave, mas trochu vic informaci proc a jak to pada?

SATAI: jen ta cena je jina ;)

KING: FWIW, nemate na ELK stack nekde "pust tenhle shellscript pro vybudovani beziciho clusteru na ECS"?

KING: etcd, Dobrý vědět, asi to zkusime.

I když teda furt čekám, že přijde microservice as a service co prostě tyhlecty discovery a secret věci implementuje za mě, ale to ještě hádám bude trvat...

Ad Docker, já vim...akorát pak jsem došel k tomu že buď naberu zookeeper department, nebo si chvíli počkám. Vim že je to složitý protože to řeší složitej problém, ale stejně ;)

NIXIMOR: to zni uplne presne jako Splunk ;)

KING: ano, logstash mame, na nem napojenou kibanu. Funguje to, ale ma to tendence obcas padat, a podle murphyho zakonu schvalnosti logstash stavkuje presne v momente, kdy nutne potrebujes resit nejaky provozni problem ke kteremu potrebujes logy - zbytek casu funguje 100% spolehlive :D
Takze jsme radi ze se dostanem i k cistym logfile nez je neco prechrousta, tam se nastesti uz nema co po** :)

NIXIMOR: Logstash idealne - agregovat vsechny logy na jedno misto. Idealne do Elasticsearch aby se s tim neco dalo delat. Tam uz je to vyreseny problem co se da delat, kolik to bude stat atp. Pripadne z logstashe treba do loggly nebo tak (== elasticsearch co provozuje nekdo jiny).

Existuje uz spousta vice ci mene oficialnich napojeni docker->ls

Disclaimer: Elasticsearch me zivi :)

ALMAD: syslog historicky neumime, logujeme do souboru... takze logy ukladame do volume.

ALMAD: jestli chces production ready, tak zookeeper je skutecne super neprustrelny, ale vyzaduje HODNE pevne nervy na to ho rozbehat dobre a hodne se toho naucit, to bych radsi risknul to etcd, znam dost firem co to spokojene bezi na produkci.

SATAI: Aha :(

SATAI: ...jo, rádi vás tu uvidíme ;)

NIXIMOR: my všechno řešíme přes syslog stream ven, děje se vám to i tak? Nebo logy ukládáte na volume v kontejnerech?

NIXIMOR: My zatim máme dědictví heroku, takže hacky okolo env proměnných...o etcd jsem slyšel dobré věci, ale někdo (myslim že šéfka devops v parsu) mi říkala, že to ještě neni production ready, ale už si nepamatuju proč.

Docker Prague (Prague)- Meetup
http://www.meetup.com/Docker-Prague-Czech-Republic/

ALMAD: My v nem (nebo ve vagrantu) mivame jenom zabalene lokalni vyvojove zalezitosti, aby si kazdy nemusel resit trebas hadoopy. Na produkci to chteli kluci z ops postupne protlacit, ale pak to nedopadlo AFAIK ciste z toho duvodu, ze se Jakub Veverka vydal za zelenejsimi pastvinami.

A jeste by me zajimal evergreen, jak resite logovani. docker logs je hodne omezeny, neumi moc dobre tail a ma tendenci bobtnat kdyz aplikace bezi dlouho. My nakonec skoncili tak, ze mountujeme externi volume do kontejneru kam se ukladaji perzistentne logy, abychom k nim meli pristup nezavisle na zivotnosti kontejneru i hodne zpetne (obcas je potreba neco dohledat i par mesicu pote co udalost nastala).

Mame docker v produkci, na nekterych dilcich vecech jak webovku tak backend, postupne se snazime pridavat dalsi veci, ale casto to znamena dost zmen. Pomoci Mesos + Marathon + Chronos. Problemy s DNS nevim, nejsem admin.

Me by zajimalo, jak resite konfiguraci. U nas mame striktne oddelene provozni a vyvojove prostredi, vyvoj nema pristup do provozu a admini zas nevrtaji do devackych veci. Tim padem v devu nemame pristup k provozni konfiguraci, takze ji ani nepridavame do image. Zkousime si tedy ted hrat s etcd, pomoci ktereho generujeme konfiguraci pro aplikaci podle toho, na ktery etcd cluster se aplikace pripoji (coz ji pri startu predame pres env promenne). Vyhoda je rychly deploy, kdy admini nemusi prebalovat dalsi layer nad nasim image ve kterem by byla jejich konfigurace.