Inspirace pražskou policií.

Logování

Na projektech, kterých se účastním, se ještě dnes setkávám kódem, který považuje logování pomocí System.out za výborný nápad. Proto bych v tomto článku chtěl rozebrat, co považuji konci roku 2013 za nejlepší logovací řešení.

Přehled

V javě máme několik možností, jak logovat:

1. System.out respektive System.err,
2. java.util.logging (JUL),
3. Jakarta (Apache) commons logging (JCL),
4. log4j,
5. slf4j a
6. logback.

System.out resp. System.err

Tuto variantu používám jen při zkoušení izolovaných věcí a záměrně odřezávám nepotřebné závislosti. Funguje na všech verzí javy.

Hlavní důvody, proč nepoužívat System.out

• Nelze konfiguračně vypnout na různých prostředích což má za následek výkonostní a bezpečnostní problémy a
• nelze konfiguračně nastavit úroveň zpráv.

Java Util Logging (JUL)

Tato možnost již máme v JRE myslím od verze 1.5. Kupodivu jsem ji  na komerčních projektech ani v open-source projektech nepotkal. Podle mě se neujala, protože přišla tak trochu s křížkem po funuse. 

log4j

Tuto možnost jsem používal na SE i EE projektech před pěti a více lety. Nenarážel jsem na limity tohoto řešení a byl jsem s ním byl spokojen. Možnosti konfigurovatelnosti ale daleko zaostávají za jeho nástupcem - logback.  

Jakarta Commons Logging (JCL)

Toto řešení mělo za cíl unifikovat rozhraní mezi různými logovacími frameworky. Samo o sobě logování neřeší, jen posílá zprávy do konkrétních implentací - log4i, JUL.  Rozhraní je skutečně jednoduché a můj oblíbený spring framework je tímto api prolezlý skrz naskrz. Toto řešení bohužel sebou nese některé problémy, kvůli kterým bych toto řešení nedoporučoval. 

slf4j

Tato knihovna řeší stejný problém jako JCL - tedy unifikace rozhraní nad různými logovacími API. Nové komerční projekty i řada open-source projektů dnes používá právě toto api. Dnes ho používám na několika komerčních i sranda projektech k plné spokojenosti. 

logback

Autorem je tvůrce log4j i slf4j - Ceki Gülcü.

Důvody, proč přejí z log4j na logback sám sepsal v článku Logback: Reasons to Switch 

Mě osobně nejvíce oslovily dvě vlastnosti:

1. podmíněná konfigurace, kterou používám pro nastavení úrovně logování v závislosti na prostředí. 
2. SiftingAppender, který umožňuje logovat dle dynamického parametru, např zalogovaného uživatele.

Závěr

• Nepoužívejte System.out resp. System.err
• Používejte slf4j spolu s logback.

Logování pomalých dotazů v PostgreSQL

Na produkčním prostředí jsem se snažil zjistit, které dotazy databázi nejvíce vytěžují.

Mile mě překvapilo, jak mocný je v tomto ohledu PostgreSQL.

Jednoduché logování dotazů, jejichž čas zpracování trvá více jak monitorovaný čas mě umožnil identifikovat dotazy, o kterých jsem ani netušil, že by mohli dělat problém.

Stačí v postgresql.conf zapnout magický přepínač log_min_duration_statement, který je defaultně vypnutý.

Pokud ho nastavím takto

log_min_duration_statement=100

tak mi do logu databáze zapíše dotazy, které trvají více jak 100ms.
Pak už přichází ke slovu klasický explain a refaktoring.

Nejkrásnější filmová melodie

Nedělní odpoledne se sedmi statečnými

Moje první video

Continuous delivery v jPower8

Náš produkt nasazujeme produkci každé dva týdny. Máme tak nastavený sprint cyklus.

 Celý proces je (skoro) plně automatický.


Zdrojáky verzujeme v svn (migraci na git plánujeme).

Stabilitu buildu udržuje TeamCity, které

• provádí unit testy,
• spouští seleniové (integrační) testy,
• nasazuje na testovací prostředí a
• provádí statickou analýzu kódu.

Doba od commitu do nasazení na test je cca 15 minut.

Pro upečení stabilního verze používáme maven-release-plugin, který se postará o to, že zvedne verzi ve všech pomech, otaguje verzi v svn a uloží upečený build do artifactory. To vše se děje jedním stiskem tlačítka na TeamCity.

Posledním krokem je samotné nasazení waru na produkční prostředí. To dělám kvůli svému pocitu důležitosti ještě stále ručně (a protože nechci, aby TeamCity mělo na produkci přístup).

Samostatnou kapitolou je aplikace migračního databázového skriptu. Ještě donedávna jsme ji prováděli ručně, což sebou neslo riziko lidské chyby a hlavně velkého opruzu.

Pokud je například potřeba přejmenovat sloupec do tabulky, přidat index, změnit constraint, vývojář commitnul migrační sql sript do svn. Dále musel změnu aplikovat u sebe lokálně minimálně na dvou databázích - jedna pro unit testy a druhá pro lokální vývoj. Dále musel změnu provést na testovacím prostředí na dalších třech databázích. Ostatní vývojáři si také museli tuto změnu aplikovat u sebe lokálně. No prostě opruz až na půdu.

Tuto příjemnou činnost jsme hodili na framework flyway. Má přesně takovou složitost, jakou jsme byli ochotni akceptovat. Do databáze přidal jednu tabulku, ze které je naprosto zřejmé, které migrační skripty už v databázi jsou aplikované. Vše je plně automatické a v režii spring beany. Jednoduché jako facka.

A jak jste se zaváděním continuous delivery vy?