malyj_gorgan (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
malyj_gorgan) wrote2021-12-24 01:04 pm
malyj_gorgan) wrote2021-12-24 01:04 pm
Entry tags:
log4j ?
Слухайте, а хтось може в парі абзаців пояснити, що то таке сабж і з чим його їдят? Дідько з нею, з його vulterability'ею, я хочу зрозуміти, чим був такий хороший чи зручний чи потрібний сам log4j, що та вульнерабіліті виявилася такою проблємною? Тільки пояснити так, на хлопский розум, без відсилань в непотрібні абревіатури.
Дякую!
Дякую!
no subject
А насправді logs must be structured. Коли просто купа тексту в файлі - можна лише eyeball it і grep. Коли у вас 10 тисяч різних процесів, які взаємодіють між собою, гра в діагностику стає набагато складнішою.
no subject
Видимо, мне это как-то не особо всегда надо было. Грепа хватало; вот и сейчас хватает. Есть какие-то тулзы, я их все забываю. Но мне удобнее прямой доступ; если чо, так я и на скале наваляю выборку моей хрени.
Собственно, позавчера именно выдернул данные с помощью split (was it csplit?) и всякого такого, типа интеллиджея. Удобно, вставил потом эти данные в юниттест.
(Собственно, идея добираться до данных через скалу только что и пришла в голову; так и буду. Биг дил,
"scp theserver:/something/logs/my.log my.log" ! Source.fromFile("my.log").readLines.filter....Был бы доступ только.
no subject
Для ілюстрації. Маємо понад два десятки датацентрів, у кожному десятки, а в деяких і сотні машин, на них із десяток контейнерів, у кожному по одному-два-три процеси. Маємо також користувача, який каже, що йому видають 429 - overload. Як дійти від цього до знання, що упав один кластер in-memory cache, і тому отакі і отакі процеси тепер failed over до бази даних, яка не встигає, а в результаті - pile up of requests на сервісі кілька hops away від сервісу, який власне розмовляє з базою даних?
Нас рятує можливість подивитись на весь зоопарк у кібані. А для цього потрібно мати логи всього-всього в "одному" місці, а не на окремих серверах, і індексувати це по важливих аспектах, а не грепати все підряд тексти всіх повідомлень, щоб можна було швидко визначати, на які сервери треба подивитись уважніше.
no subject
О! Действительно же. Убедительный пример.
Кстати, я не понимаю, у нас в HealthExpense было 500 серверов - и вот не припомню что-то проблем. Странно. Хм.
no subject
no subject
Кому там еще заниматься-то. Когда СТО ушел, я стал за все ответчик. Не, у нас просто проблем почти не было. Скала. Монады. Zero warnings. Zero NPE.
no subject
остання проблема, в діагностиці якої я приймав участь - 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.
no subject
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.
no subject