log4j ?

[malyj_gorgan]

Слухайте, а хтось може в парі абзаців пояснити, що то таке сабж і з чим його їдят? Дідько з нею, з його vulterability'ею, я хочу зрозуміти, чим був такий хороший чи зручний чи потрібний сам log4j, що та вульнерабіліті виявилася такою проблємною? Тільки пояснити так, на хлопский розум, без відсилань в непотрібні абревіатури.
Дякую!

Comments

[sassa_nf]

log4j просто означає logging для джави.

Не знаю, чи треба пояснювати logging: це процес конспектування процесу виконання якого-небудь процесу і є ключовим артефактом у діагностиці несправностей систем. Таким чином, оскільки logs - ключовий артефакт, logging роблять усі. Так склалось, що у самій джаві система logging була недолуга та недосконала, так з'явилась opensource бібліотека log4j, яку використовують, можна сказати, усі системи на джаві. Ну, і the rest is history.

[juan_gandhi]

Казалось бы, пиши в System.out, да и все. Но людям хочется поконфигурировать, хочется писать в файлы по какой-нибудь policy, хочется ротацию файлов, вот это все. Самим лень писать (мне б не лень было, если случись), и используют эту жопу. А в этой жопе всякие прибамбасы вставлены, "нормальным людям" (вроде меня) не нужные. Типа "а давайте сходим на какой-нибудь сервер, чтобы что-нибудь еще вставить". И вот это вот "сходим куда-нибудь, а потом вычислим на месте, что прислали" - это большая дыра. Вычислить же можно и sudo rm -rf /.

[sassa_nf]

На поверхні - так, пиши собі в system.out

А насправді logs must be structured. Коли просто купа тексту в файлі - можна лише eyeball it і grep. Коли у вас 10 тисяч різних процесів, які взаємодіють між собою, гра в діагностику стає набагато складнішою.

[juan_gandhi]

Видимо, мне это как-то не особо всегда надо было. Грепа хватало; вот и сейчас хватает. Есть какие-то тулзы, я их все забываю. Но мне удобнее прямой доступ; если чо, так я и на скале наваляю выборку моей хрени.

Собственно, позавчера именно выдернул данные с помощью split (was it csplit?) и всякого такого, типа интеллиджея. Удобно, вставил потом эти данные в юниттест.

(Собственно, идея добираться до данных через скалу только что и пришла в голову; так и буду. Биг дил,

"scp theserver:/something/logs/my.log my.log" !
Source.fromFile("my.log").readLines.filter....

Был бы доступ только.

[malyj_gorgan]

Дякую
Тобто, це просто logging?
Якщо це просто логописалка, навіть структурована, то я не розумію, нафіга у неж в принципі була функціональність, яку можна було експлуатувати? Вписувати туди таку функціональність -- не просто робити місце для дірок, а і банальний приклад того, що називають overengineering.

[malyj_gorgan]

Я вперше зіткнувся з цим ділом, коли вперше почав не просто писати свій код, а ще і міняти чужий, правда, не Джаву чи всякі благородні Скали, а банальний Python. Виявив, що третина коду півторарічної і більше давності не працює, бо нема правильного логгера: той, який прописали, чи то не встановлений, чи то поміняв назву, чи то поміняв ще щось. Словом, у мене був період, коли починати працювати з чужим кодом треба було з того, щоби масово поміняти logging.info na sys.stdout.write, а loggin.debug sys.stderr.write
Помітив, що після мене джуніор дата саєнтісти робили те ж саме. Висновків не робитиму, хтозна, може, я комусь стиль зіпсував :)

[juan_gandhi]

Вот я тоже так же на эту хрень смотрю. Попроще надо. Но sassa-nf может разъяснить необходимость всякой такой фигни. Хорошо не в базу данных пишем логи.

[sassa_nf]

ну, там окремі фічі життя полегшують, а всі разом - діра.

log enrichment - додавати потрібні контекстні дані до логів, які або замахаєшся додавати сам, або забудеш. Так з'являється потреба ${ctx.something}.

remote log destination - писати в локальний файл - це годиться для невеликої кількості процесів. Якщо у нас ферма із кількасот або тисяч процесів, з'являється потреба скидати все в одне місце. (ну і, звісно, enrich логи ще й ${ctx.hostname})

(скажімо, з отих двох можна побудувати ще й log censoring - фільтрувати або обскурувати потрібні контекстні дані, залежно від log destination. gdpr, і таке інше)

different types of log destination - а що, є один-єдиний стандарт і протокол передачі логів і одна-єдина архітектура організації процесу передачі логів?

ну, і от тепер все разом взяти докупи - маємо діру. З одного боку щось виймати з контексту - класна і потрібна річ, з іншого боку - якщо для контексту використовувати JNDI, маємо змогу з контексту виймати arbitrary stuff, або зациклити. Ну, і от arbitrary stuff, виявляється, може бути вказівкою JNDI піти поговорити з іншим сервером, який підтримується JNDI - наприклад, лівий LDAP. Але це вже пішли абревіатури.

[sassa_nf]

тут кілька питань, найпростіше з яких - а звідки знати, з якого сервера зкачувати логи? і про логи якого процесу на тому сервері йде мова?

Для ілюстрації. Маємо понад два десятки датацентрів, у кожному десятки, а в деяких і сотні машин, на них із десяток контейнерів, у кожному по одному-два-три процеси. Маємо також користувача, який каже, що йому видають 429 - overload. Як дійти від цього до знання, що упав один кластер in-memory cache, і тому отакі і отакі процеси тепер failed over до бази даних, яка не встигає, а в результаті - pile up of requests на сервісі кілька hops away від сервісу, який власне розмовляє з базою даних?

Нас рятує можливість подивитись на весь зоопарк у кібані. А для цього потрібно мати логи всього-всього в "одному" місці, а не на окремих серверах, і індексувати це по важливих аспектах, а не грепати все підряд тексти всіх повідомлень, щоб можна було швидко визначати, на які сервери треба подивитись уважніше.

[juan_gandhi]

О! Действительно же. Убедительный пример.

Кстати, я не понимаю, у нас в HealthExpense было 500 серверов - и вот не припомню что-то проблем. Странно. Хм.

[malyj_gorgan]

Звичайном, не в базу даних, а в якийсь дешевий storage. В базу даних пишемо лише метадані з логів, достатні, щоби всі потрібні поля були searchable і щоби можна було знати, де шукати повний лог в тому storage'і.
Не скажу, де я таке геніальне рішення бачив.

[malyj_gorgan]

Теж правда.
Це часта лажа: якісь рішення, зручні з близької розробникам точки зору, масово поширюються без обдумування можливих проблем і ризиків з усіх інших точок зору, і вуаля: то зручно писати логи -- і діра в безпеці, то зручно тримати в одному місці докер імаджі -- і щось стається з quay.io, і паніка на всю індустрію, то придумали хороші безпечні gdpr -- і кожному першому сервісові доводиться писати окремий код і інфраструктуру даних для Європи (що кидає тінь і на gdpr, і на дизайн кожного першого сервіса)
Комплексні підходи з продуманою архітектурою без дір на півстіни попадаються нечасто. (Чи то ми ще просто ще тих дір не знайшли?) І зрозуміло чому: бо поки ти придумуєш нормальний літак, випробовуєш, шліфуєш, покращуєш, у конкурентів уже куплять єраплан з гівна і палок, склепаний бандою китайських програмістів, яким плювати на якість, які одне одного не розуміють, а індійського PM'а так вже точно, але пробивні американські сейлзи уже зароблять свої відсотки з продажу, так що всьо чотко.
Як з цим боротися -- не знаю. Чекаю, коли хтось зламає github або, краще, Atlassian suite і вкраде пів-інтернету.

[sassa_nf]

Ну, так ось ELK і маємо: elastic search, logstash, kebana, чи щось таке :)

[juan_gandhi]

Во, прекрасное решение. И если не брать логи, то довольно стандартное. Data Lake. Ну так и логи туда же можно фигачить. Огромное спасибо за идейку.

[sassa_nf]

https://www.elastic.co/what-is/elk-stack - and a pretty standard solution too

[sassa_nf]

Dunno. Може, повезло, а може ви на останній ланці діагностики і пошуком проблеми займався хтось інший?

[malyj_gorgan]

Дві роботи тому ми пробували безплатним ELK'ом замінити дорогущий Splunk. Правда, Logstash не тягнув потужність потоку даних, тому ми замінили його на fluentd, вийшов EFK стек. :) Я, правда, саме тим Ф'ом і займався, з Е і К працювали інші, але те, що я бачив, мені не дуже. Я концептуально не люблю latest and greatest tools most convenient for the task, в більшості випадків, вони лише знижують ефективність всього

[juan_gandhi]

Кому там еще заниматься-то. Когда СТО ушел, я стал за все ответчик. Не, у нас просто проблем почти не было. Скала. Монады. Zero warnings. Zero NPE.

[sassa_nf]

чудово.

остання проблема, в діагностиці якої я приймав участь - all the threads are waiting on connection pool. Everyone is tormenting the DB connection pool team to get them to make connection pool more efficient. Looking at the heap dump it became clear there are no connection at all, and it is not about efficiency of borrowing connections. What then? Digging through the logs we see login timeouts during connection establishment. Looking at the flight recordings for the said time, we see the connection getting closed, but we do not see long IO operation causing the timeout. What then?

Well...looking at the flight recordings, we see CPU spiked for minutes, and we see almost all of it is spent on DH key negotiation - during DB connection establishment. Why does it take minutes? Because it switched from compiled and optimised to interpreted mode. So the fix is in working out why it switched to interpreted mode all of a sudden.

I don't know how many production issues caused by NPEs and the absence of monads were fixed without me lending a hand. But I get a feeling that stuff just breaks.

[sassa_nf]

Класно. Ну, власне, чи ELK, чи EFK, чи Splunk, ми прийшли до того, чому саме логи мають бути структуровані, і чому логерам може бути потрібно не просто в stdout викидати все, а може надсилати кудись ще (щоб не заводити ще й fluentd який небудь, хто б потім підгрібав все, що в stdout накидано).

[juan_gandhi]

You are pointing at a typical issue that has been driving me nuts for years. Not at that company where we had monads and no NPE, but at all other companies.

[sassa_nf]

I suppose you mean connection pooling. Unfortunately this is a resource sharing question. Tracking lifetimes becomes unavoidable. Additionally, connections consume resources on two ends, so you can't assume that both ends are going to be fine if you create a connection any time you like: for you it may be 1 a second; for them it may be 1000 a second.

[mprotsenko]

Ще можна додати, що log4j2 мав (підозрюю, що і зараз має, але ліньки перевіряти) найкращий перфоманс.

При 10-20к RPS на сервер перформанс logging системи - це не така вже й тривіальна проблема.

І порада писати все в System.out тут є дуже шкідливою. Починаючи з того, що це не дуже ефективно з точки зору перформансу, і закінчуючи тім, що якщо ти хочеш мати можливість налаштовувати logging level динамічно (тут не друкувати DEBUG-level logs, а тут друкувати), то кожен System.out.println доведеться загортати в "if", і можливо навіть не один (що, собсна, теж не айс з точки зору перформансу).

[mprotsenko]

Чекаю, коли хтось зламає github або, краще, Atlassian suite і вкраде пів-інтернету.

Сенсу нема. :)

Якщо хтось вкраде наш source code - то (а) нічого особливо секретного в 99% коду він не знайде, усі ідеї давно є публічними, (б) без відповідної інфраструктури (включно з людьми) фіг ти той код запустиш.

[mprotsenko]

Як з цим боротися -- не знаю.

Одягаю Captain Obvious' cape: треба оптимізувати процеси під MTTR, бо спроба оптимізувати під MTTF зазвичай веде до погіршення як MTTF, так і MTTR.

(Я пам'ятаю, ти просив без абревіатур, вибач!)

UPD: мова, звісно, не про safety-critical інфраструктуру, там інші проблеми, і інші методи їх вирішення.