1.1, Аноним (-), 14:25, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +8 +/– |
Судя по неоднократному упоминанию "структурированных данных", основной формат хранения логов будет бинарным.
Ну наконец-то и линукс дошел до того, что в юниксе сделано уже двадцать лет назад.
| |
|
2.6, Аноним (-), 14:34, 02/03/2012 [^] [^^] [^^^] [ответить]
| +7 +/– |
А чем бинарный формат принципиально лучше текстового? Индексы и по текстовым строкам прекрасно делаются, сами журнальные записи тоже текстовые
| |
|
3.18, Аноним (-), 14:53, 02/03/2012 [^] [^^] [^^^] [ответить]
| +8 +/– |
> А чем бинарный формат принципиально лучше текстового? Индексы и по текстовым строкам
> прекрасно делаются, сами журнальные записи тоже текстовые
Основных причины две:
1. Недостаточная компактность. Особенно неприятно отсутствие возможности дедупликации повторяющихся данных (например, имя хоста). Соответственно, это сильно замедляет хранение, поиск и обработку. В частности, именно поэтому наиболее нагруженные лог-системы (в частности, юниксовый аудит) работают исключительно с бинарными логами.
2. Неструктурированность. Опять же сильно затрудняет обработку и поиск данных. Кроме того, порождает кучу проблем совместимости - добавление нового поля в структуру не ломает существующие анализаторы логов, в отличие от изменения форматной строки.
| |
|
4.30, anonymous (??), 15:05, 02/03/2012 [^] [^^] [^^^] [ответить]
| –4 +/– |
> Основных причины две:
> 1. Недостаточная компактность. Особенно неприятно отсутствие возможности дедупликации
> повторяющихся данных (например, имя хоста). Соответственно, это сильно замедляет хранение,
> поиск и обработку. В частности, именно поэтому наиболее нагруженные лог-системы (в
> частности, юниксовый аудит) работают исключительно с бинарными логами.
Это попытка переизобрести gzip?
> 2. Неструктурированность. Опять же сильно затрудняет обработку и поиск данных. Кроме того,
> порождает кучу проблем совместимости - добавление нового поля в структуру не
> ломает существующие анализаторы логов, в отличие от изменения форматной строки.
Феерический бред.
| |
|
5.37, Аноним (-), 15:11, 02/03/2012 [^] [^^] [^^^] [ответить]
| +4 +/– |
> Это попытка переизобрести gzip?
В какой-то степени. Но только такой gzip, который позволяет работать сразу со сжатым файлом, и при этом не замедляет доступ, а ускоряет его (за счет индекса).
> Феерический бред.
Да неужели? Вот, например, в приводимых вами ссылках автор rsyslog жалуется, что поддержка тайм-зоны в его rsyslog давно есть, но включить ее нельзя, потому что она сломает все существующие анализаторы логов.
Со структурированными данными при стабильном API такой проблемы нет в принципе.
| |
|
6.46, anonymous (??), 15:22, 02/03/2012 [^] [^^] [^^^] [ответить]
| –5 +/– |
>> Это попытка переизобрести gzip?
> В какой-то степени. Но только такой gzip, который позволяет работать сразу со
> сжатым файлом, и при этом не замедляет доступ, а ускоряет его
> (за счет индекса).
Кто мешает пожать и проиндексировать текстовый файл?
> Да неужели? Вот, например, в приводимых вами ссылках автор rsyslog жалуется, что
> поддержка тайм-зоны в его rsyslog давно есть, но включить ее нельзя,
> потому что она сломает все существующие анализаторы логов.
> Со структурированными данными при стабильном API такой проблемы нет в принципе.
Где ты увидел стабильный API, если количество полей и их содержимое меняется? Всё равно переписывать придётся. Впрочем, пока даже формат этого бинаря не документирован.
| |
|
7.50, Аноним (-), 15:45, 02/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Где ты увидел стабильный API, если количество полей и их содержимое меняется?
Если поля не удаляются, а только добавляются новые, то, по идее, старые анализаторы это не должно ломать.
| |
|
|
9.68, Аноним (-), 16:37, 02/03/2012 [^] [^^] [^^^] [ответить] | +1 +/– | Нет Речь шла о структурированном логе со специальным API для работы с ним Ес... текст свёрнут, показать | |
9.69, Wolfis (?), 16:38, 02/03/2012 [^] [^^] [^^^] [ответить] | +/– | Структурированные данные, индексируемые данные, множества данных Если кто не п... текст свёрнут, показать | |
|
10.107, XoRe (ok), 22:07, 02/03/2012 [^] [^^] [^^^] [ответить] | +4 +/– | В этой теме про него лучше не вспоминать А то, знаете как помянешь черта и о... текст свёрнут, показать | |
|
9.232, arisu (ok), 04:40, 06/03/2012 [^] [^^] [^^^] [ответить] | +/– | хорошо работают, если писались руками и изначально формат нормальный 171 перв... текст свёрнут, показать | |
|
|
7.76, Аноним (-), 17:20, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Кто мешает пожать и проиндексировать текстовый файл?
Современный текстовый лог представляет собой текстовую кашу, которую индексировать весьма проблематично. Индексы эффективны только на структурированных данных.
> Где ты увидел стабильный API, если количество полей и их содержимое меняется?
API для работы со структурированными данными по определению поддерживает произвольный набор полей различного типа. Абстракция, слышали такое слово?
| |
|
6.115, anonimous (?), 00:14, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Но только такой gzip, который позволяет работать сразу со сжатым файлом, и при этом не замедляет доступ, а ускоряет его (за счет индекса).
А индекс образуется сам собой, причём совершенно задаром.
| |
|
7.137, Аноним (-), 04:04, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> А индекс образуется сам собой, причём совершенно задаром.
А в случае текстаря его еще и хранить надо где-то сильно сбоку...
| |
|
|
5.86, Аноним (-), 17:40, 02/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Это попытка переизобрести gzip?
Gzip не позволяет доступ на ходу. А 20 гиговую портянку сам, пожалуйста, декомпрессуй своим гзипом. И да, если уж о скорости, тесктовые логи зачастую отключают т.к. на серверах все начинает упираться именно в запись логов.
| |
|
6.109, XoRe (ok), 22:11, 02/03/2012 [^] [^^] [^^^] [ответить]
| +3 +/– |
>> Это попытка переизобрести gzip?
> Gzip не позволяет доступ на ходу. А 20 гиговую портянку сам, пожалуйста,
> декомпрессуй своим гзипом. И да, если уж о скорости, тесктовые логи
> зачастую отключают т.к. на серверах все начинает упираться именно в запись
> логов.
Против 20гиговых логов есть ротация.
Кто не настроил, тот - ...)
На средненагруженном сервере в логи ничего не упирается.
А на высоконагруженном... там уже другие способы работы с логами.
Например, отправлять на специальный сервер логов, не храня у себя.
Кто не настроил - тот ...)
| |
|
7.124, Аноним (-), 03:12, 03/03/2012 [^] [^^] [^^^] [ответить] | –1 +/– | Угу, что однако не отменяет факта что логи могут быть большими даже с ротацией ... большой текст свёрнут, показать | |
|
|
|
|
11.163, zzz (??), 12:34, 03/03/2012 [^] [^^] [^^^] [ответить] | +/– | Целевой сервис не обязан интенсивно писать на диск, если что Более того, не у в... текст свёрнут, показать | |
|
|
13.218, Аноним (-), 17:35, 04/03/2012 [^] [^^] [^^^] [ответить] | +/– | Может, но насколько именно - весьма зависит от А еще можно логи хранить на отде... большой текст свёрнут, показать | |
|
|
|
|
11.219, Аноним (-), 17:45, 04/03/2012 [^] [^^] [^^^] [ответить] | +/– | Сервер отгружающий бочками файло и не готовый к интенсивному I O довольно странн... большой текст свёрнут, показать | |
|
|
|
8.147, XoRe (ok), 05:59, 03/03/2012 [^] [^^] [^^^] [ответить] | +5 +/– | могут быть - это предположение факт - это бл , вот это логи отожрали А с ф... большой текст свёрнут, показать | |
|
9.157, zzz (??), 07:54, 03/03/2012 [^] [^^] [^^^] [ответить] | +/– | Элементарно - минимальная атака на сервак где они в крейсерском режиме нормальны... большой текст свёрнут, показать | |
|
10.174, XoRe (ok), 14:18, 03/03/2012 [^] [^^] [^^^] [ответить] | +1 +/– | Уважаемый, вы бы посмотрели, на какие тезисы я отвечаю Там как раз хотели за су... большой текст свёрнут, показать | |
|
11.192, Аноним (-), 00:59, 04/03/2012 [^] [^^] [^^^] [ответить] | +/– | Во первых, заранее сложно сказать за какой интервал потребуются логи Во вторых,... большой текст свёрнут, показать | |
|
|
|
|
|
6.111, nobody (??), 22:19, 02/03/2012 [^] [^^] [^^^] [ответить]
| +9 +/– |
>> Это попытка переизобрести gzip?
> Gzip не позволяет доступ на ходу. А 20 гиговую портянку сам, пожалуйста,
> декомпрессуй своим гзипом. И да, если уж о скорости, тесктовые логи
> зачастую отключают т.к. на серверах все начинает упираться именно в запись
> логов.
Логи в продакшене отключают только идиоты. Вменяемые админы, если дисковое и/о из-за логов становится проблемой, пишут логи сразу на удаленный сервер логов, потому что сервис без логирования его работы никакому траблшутингу не поддаётся в принципе, а вменяемые админы не любят беспомощно разводить руками, когда случается внезапный service outage, им больше нравится возможность узнать из лога, что просходило с сервисом непосредственно перед отказом.
Кстати поэтому, вменяемых админов сабж врядли обрадует, тк если это будет бд в каком-то виде, то никогда нельзя быть уверенным, что сможешь быстро прогрепать логи, чтобы быстро найти причину и восстановить работоспособность сервиса в кратчайшие сроки. Зато точно понятно, что все написанные годами скрипты и парсеры идут лесом. А меж тем, эта новая бд может (а значит будет) крешиться, и тд - это дополнительный point of failure, усложнение на ровном месте, которое никаких серъезных преимуществ не даёт, зато имеет вполне очевидные недостатки. В общем, это печально всё... что так много, судя по выкрикам, ленартов поттерингов вокруг, для которых KISS и бритва оккама - пустые знаки.
| |
6.116, anonimous (?), 00:18, 03/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> ... И да, если уж о скорости, тесктовые логи
> зачастую отключают т.к. на серверах все начинает упираться именно в запись
> логов.
Мне пытаются впарить мысль, что DB (!!!) будет быстрее, чем plain-file на одном оборудовании. Или я что-то пропустил?
| |
|
7.122, VoDA (ok), 02:58, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> ... И да, если уж о скорости, тесктовые логи
>> зачастую отключают т.к. на серверах все начинает упираться именно в запись
>> логов.
> Мне пытаются впарить мысль, что DB (!!!) будет быстрее, чем plain-file на
> одном оборудовании. Или я что-то пропустил?
работа с БД в большинстве случаев быстрее plain-file. начиная с того, что нормализация уменьшает размер в 10-30 раз и продолжая индексами по любым требуемым полям. plain-file хорошо пока не нужно проводить анализ на больших объемах.
| |
|
|
Часть нити удалена модератором |
9.162, zzz (??), 12:28, 03/03/2012 [^] [^^] [^^^] [ответить] | –1 +/– | Значит формат должен допускать лобовой и быстрый инсерт максимально компактных з... текст свёрнут, показать | |
9.183, VoDA (ok), 15:06, 03/03/2012 [^] [^^] [^^^] [ответить] | +/– | А кто вас сказал чтоб это будет реляционная СУБД шарашить с спец формате расс... большой текст свёрнут, показать | |
|
|
11.227, VoDA (ok), 00:45, 06/03/2012 [^] [^^] [^^^] [ответить] | +/– | Однако, как указывает К Дейт, нормализация в точности и является теми принципам... большой текст свёрнут, показать | |
|
12.236, arisu (ok), 04:58, 06/03/2012 [^] [^^] [^^^] [ответить] | +/– | йопт на поиск 171 повторяющихся элементов 187 в словарях время уходит, нет ... большой текст свёрнут, показать | |
|
|
|
|
|
7.126, Аноним (-), 03:16, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Мне пытаются впарить мысль, что DB (!!!) будет быстрее, чем plain-file на
> одном оборудовании. Или я что-то пропустил?
Пытаются впарить мысль что запись эвента в минимальном бинарном виде без повторяющихся полей может весить в _разы_ меньше.
Так, похожий пример: жил был OSM. Хранил карту в XML. Когда карта мира стала весить в XML 250 гигов так что работать с ней стало невозможно, чуваки очень быстро осознали свои ошибки и сделали эффективный бинарный формат где все данные представлены настолько компактно насколько это можно сделать. И оно весит 14 гигз. Небольшая такая разница, всего примерно в 20 раз...
| |
|
8.237, arisu (ok), 05:00, 06/03/2012 [^] [^^] [^^^] [ответить] | +/– | ну и какой идиот изначально додумался базу с необходимым по дизайну random acces... текст свёрнут, показать | |
|
|
|
|
4.45, gaga (ok), 15:21, 02/03/2012 [^] [^^] [^^^] [ответить] | +1 +/– | Дедупликация подразумевает сложную структуру хранения, подобную реляционной или ... большой текст свёрнут, показать | |
|
5.77, Аноним (-), 17:23, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Дедупликация подразумевает сложную структуру хранения, подобную реляционной или какой-нибудь
> другой СУБД. Это усложняет демон не в разы, а на несколько
> порядков, и замедляет его на столько же. А лог должен быть
> максимально простым и быстрым.
То же самое можно сказать про любую SQL-совместимую СУБД. Но почему-то среди них популярны мускул, постргрес и скулайт, причем их бакэнды почему-то работают с бинарными форматами :)
> JSON и ему подобные форматы решают эту проблему.
Но проблему объема они не решают. Поэтому их рациональнее использовать на следующем этапе обработки - формирование отчетов и выборок по БД логов.
| |
|
6.238, arisu (ok), 05:02, 06/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
все твои улыбки в основном от того, что ты считаешь: one size fits all. и волшебные слова «база данных» понимаешь очень однобоко.
| |
|
5.80, Аноним (-), 17:29, 02/03/2012 [^] [^^] [^^^] [ответить] | +2 +/– | Угу, аж возможность референса в сторону - а вот это уже было, брать вон там вот... большой текст свёрнут, показать | |
|
|
3.59, Аноним (-), 16:17, 02/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> прекрасно делаются, сами журнальные записи тоже текстовые
Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно. В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать по критерию. В случае текста надо какие-то костыли. Грепать или индексить всю портянку на 20 гигз можно и задолбаться. А когда она уже в удобном виде - почему бы и нет?
| |
|
4.78, Аноним (-), 17:25, 02/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно.
> В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать
> по критерию. В случае текста надо какие-то костыли. Грепать или индексить
> всю портянку на 20 гигз можно и задолбаться. А когда она
> уже в удобном виде - почему бы и нет?
Заметим, что идея грепа лога сама по себе порочна. Добавление в строку нового поля, или изменение формулировки сообщения ломает работу всех хитроумных regexpов.
| |
|
5.83, Аноним (-), 17:34, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Заметим, что идея грепа лога сама по себе порочна.
Я бы сказал 50/50, потому что гибкость - хорошая, да. И позволяет завернуть очень хитрый критерий для аналитики, которого вот так сходу может и не быть. С другой стороны, грепать 20-гиговую портянку на каждую оказию - удовольствие ниже среднего.
> Добавление в строку нового поля, или изменение формулировки сообщения ломает
> работу всех хитроумных regexpов.
Ну вот поэтому я и полагаю что в принципе сабж имеет право на жизнь, ЕСЛИ оставят нормальный интерфейс для грепалок на случай когда надо завернуть какую-то хитрозагнутую аналитику, скорость которой не важна, а вот готового тулса не оказалось и все тут, так что цепочка грепов - единственный простой вариант.
| |
|
6.87, Аноним (-), 17:41, 02/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Я бы сказал 50/50, потому что гибкость - хорошая, да. И позволяет
> завернуть очень хитрый критерий для аналитики, которого вот так сходу может
> и не быть.
Хм. Вы когда-нибудь с SQL работали? Скажу по секрету: там возможностей для хитрой аналитики куда больше, чем в простом грепе =)
Логично, что для работы со структурированными данными, будет использоваться язык структурированных запросов (a.k.a. SQL), или некий его аналог.
| |
|
7.125, Anonymouse (?), 03:13, 03/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Хм. Вы когда-нибудь с SQL работали? Скажу по секрету: там возможностей для хитрой аналитики куда больше, чем в простом грепе =)
Practical Extraction and Report Language. На SQL-е - умахаешься.
Впрочем поЦерингов это не остановит :(
| |
7.130, Аноним (-), 03:50, 03/03/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Хм. Вы когда-нибудь с SQL работали? Скажу по секрету: там возможностей для
> хитрой аналитики куда больше, чем в простом грепе =)
1) Я не считаю что для анализа логов мне надо бросить все и стать DBA
2) Я не считаю что для анализа логов мне надо бросить все и стать SQL programmer.
3) Базы SQL в общем случае не отличаются скоростью и компактностью.
4) Оно слишком много всего умеет: перспектива словить SQL injection в системе логгинга - здорово придумано. А что, пусть хакер и ломится через систему логгинга сразу.
5) В общем случае SQL базы не дизайнились быть устойчивыми от хакинга, удаления записей задним числом без простого обнаружения этого факта, etc.
| |
7.213, cosmonaut (ok), 12:09, 04/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Скажу по секрету: там возможностей для хитрой аналитики куда больше, чем в простом грепе =)
Т.е. вы хотите сказать, что DSL, коим является SQL имеет больше возможностей, чем тьюринг-полный язык (bash+grep+tools+sed+awk)?
А где такая трава продается? :)
| |
|
|
5.99, Аноним (-), 18:38, 02/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Заметим, что идея грепа лога сама по себе порочна. Добавление в строку
> нового поля, или изменение формулировки сообщения ломает работу всех хитроумных regexpов.
Да, вспоминается, как аккуратненько добавил разок дополнительное поле в конец лог-строки апача. И все, вебалайзер тут же загнулся.
| |
|
4.117, anonimous (?), 00:26, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно.
> В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать
> по критерию. В случае текста надо какие-то костыли. Грепать или индексить
> всю портянку на 20 гигз можно и задолбаться. А когда она
> уже в удобном виде - почему бы и нет?
Узкое место --- не в чтении/парсинге/поиске, в записи. (поиск --- значительно более редкая и менее требовательная к скорости получения результата операция, по сравнению с записью).
| |
4.142, Имя и код (?), 05:16, 03/03/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> прекрасно делаются, сами журнальные записи тоже текстовые
> Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно.
> В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать
> по критерию. В случае текста надо какие-то костыли. Грепать или индексить
> всю портянку на 20 гигз можно и задолбаться. А когда она
> уже в удобном виде - почему бы и нет?
Не-а, бинарь в принципе не удобен. Эт раз.
Для первичного анализа берутся не сами логи, но уже очищенные от инфошума, эт два.
И тока ежели оно действительно дальше нуна (отрицательная вероятность), берётся часть простыни, локализированная по.
| |
|
5.166, zzz (??), 13:18, 03/03/2012 [^] [^^] [^^^] [ответить] | +/– | Бинарь в принципе ничем не отличается от текстаря Поскольку вы не читаете секто... большой текст свёрнут, показать | |
|
|
|
2.44, Аноним (-), 15:18, 02/03/2012 [^] [^^] [^^^] [ответить] | –4 +/– | Итак, давайте обдумаем Допустим что syslog действительно устарела устаревание ... большой текст свёрнут, показать | |
|
3.48, anonymous (??), 15:30, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
Слишком много букв. Но что делать, если утилита посчитает бинарный лог испорченным и пошлёт куда подальше? Представляется ли возможным что-то быстро предпринять на коленке в таком вот экстренном случае?
| |
|
4.51, Аноним (-), 15:47, 02/03/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
Снова на второстепенные вещи отвлекаетесь:
1. Много букв потому то в тексте подробности (внезапно?).
2. Утилита утилите рознь (тут надо смотреть на реализацию утилиты и, особенно, на формат логов (бинарность логов не обязательно подразумевает их архивацию в сполшной solid-архив; можно сжимать на уровне сообщения/строк/записи и т.д.) ).
| |
4.53, Аноним (-), 15:52, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
Это важный вопрос, но не первой важности, т.к. он не определяет архитектуру и возможности. А разговоры именно об этом
| |
|
5.57, Аноним (-), 16:01, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
Об этом и речь была. Цитирую: "разница между бинарными и текстовымы форматами хранения не несет сколько-нибудь принципиальной разницы". Ключевое здесь: "не несет принципиальной разницы". Просто часть читающих опеннета не осиливает текст моего сообщения (да куда там до понимания сути сообщения когда часть тут новости (пересказ в кратком изложении) не осиливает даже на половину).
| |
|
6.90, Аноним (-), 17:46, 02/03/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Об этом и речь была. Цитирую: "разница между бинарными и текстовымы форматами
> хранения не несет сколько-нибудь принципиальной разницы". Ключевое здесь: "не несет принципиальной
> разницы". Просто часть читающих опеннета не осиливает текст моего сообщения (да
> куда там до понимания сути сообщения когда часть тут новости (пересказ
> в кратком изложении) не осиливает даже на половину).
Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными.
Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами.
| |
|
7.100, Аноним (-), 19:17, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными.
Вы не врубаетесь в самую суть: формат хранения логов это второстепенные вещи и нет никакой проблемы перегнать с одного формата в другой.
>Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами.
Проблема сжать существующие логи? Или проблема навесить структуризацию на текущий способ?
| |
|
8.119, Deffic (?), 01:59, 03/03/2012 [^] [^^] [^^^] [ответить] | +2 +/– | Поддреживаю Собершенно непонятно вокруг чего проблема, если нужны структурирова... большой текст свёрнут, показать | |
8.123, VoDA (ok), 03:09, 03/03/2012 [^] [^^] [^^^] [ответить] | +/– | Проблема сделать логи структурированными Решение этой задачи попутно решит ряд ... большой текст свёрнут, показать | |
|
9.170, Аноним (-), 13:37, 03/03/2012 [^] [^^] [^^^] [ответить] | –1 +/– | Ну так перцы тоже решили реализовать стандарт А то что он бинарный - ну и болт ... текст свёрнут, показать | |
|
|
|
|
13.228, VoDA (ok), 00:54, 06/03/2012 [^] [^^] [^^^] [ответить] | +/– | gt оверквотинг удален Вы правы - это тайный набор знаний Его специально выдел... большой текст свёрнут, показать | |
|
|
|
|
9.185, VoDA (ok), 15:23, 03/03/2012 [^] [^^] [^^^] [ответить] | +/– | Сам MSG не структурирован Как по вашему задаются обязательные и дополнительные ... большой текст свёрнут, показать | |
|
|
11.229, VoDA (ok), 01:02, 06/03/2012 [^] [^^] [^^^] [ответить] | +/– | Аналогия интересна, но не верна Изначальный постулат, который я развиваю это не... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
4.131, Аноним (-), 03:52, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Слишком много букв. Но что делать, если утилита посчитает бинарный лог испорченным
Тогда с ним делать то же что и с испорченным текстовым логом. Открыли вы текстарь а там бред. Ну и чего?
| |
|
3.82, Аноним (-), 17:34, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Это я к тому что прикрутить к syslog хранение в бинарном представлении - это простое дело одного коммита (нужны всего лишь две функции кодирования и декодирования, которые можно выбросить в разделяемую библиотеку и позже предоставить API для возможности написания сторонних утилит).
А вы подумали о том, что старый API взаимодействия приложений с syslog не предназначен для передачи структурированных данных, и даже если ввести в современный rsyslog бинарный формат хранения, существенных бонусов это не даст.
> Вывод: текст вашего сообщения оказался низкокачественным де!!мом (вы со средне-серым образованием или обычный гуманитарии?)
Судя по вашей буйно реакции, а наступил на вашу любимую мозольку. Правда, пока не могу понять, где именно.
| |
|
4.160, Аноним (-), 10:31, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>А вы подумали о том, что старый API взаимодействия приложений с syslog не предназначен для передачи структурированных данных, и даже если ввести в современный rsyslog бинарный формат хранения, существенных бонусов это не даст.
Не вижу никаких проблем чтобы расширить API. Это дело одного коммита.
>Судя по вашей буйно реакции, а наступил на вашу любимую мозольку. Правда, пока не могу понять, где именно.
Длинное сообщение получилось лишь потому что я попытался описать часть картины более полно (не опуская важные детали). Понять вы не можете вполне закономерно: вы ошиблись в расчетах (реакция у меня вполне обычная, а не буйная (это, кстати, проблема вашего восприятия с уклоном в эмоциональный фон) ). Вы о себе слишком высокого мнения.
| |
|
5.240, arisu (ok), 05:09, 06/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Не вижу никаких проблем чтобы расширить API. Это дело одного коммита.
угу. один всемирный такой коммит, который автомагически поправит все клиенты.
| |
|
|
3.93, Аноним (-), 18:25, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Вывод: текст вашего сообщения оказался низкокачественным де!!мом (вы со средне-серым образованием или обычный гуманитарии?)
В чем-то вы правы =)
В своем посте я немножечко пожертвовал логичностью ради провокационности.
Действительно, ключевым моментом является введение API для работы со _структурированными_ данным. Бинарный формат лога - это лишь внешний атрибут, который сам по себе существенных бонусов не дает.
Просто меня забавляет реакция на это словосочетание ("бинарные логи") некоторых местных петушков, знакомых с юниксом исключительно понаслышке, но при этом обожающих рассказывать, что такое юниксвей, и как всем правильно жить =)
| |
|
4.121, Куяврик (?), 02:40, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
А мне вот не нравится идея бинарных логов. И бинарных конфигов. Просто - не нравится. Независимо от API. И совершенно неясно что в этом забавного. А вот забавно как раз наоборот - ваше отношение.
"Бинарный формат лога - это лишь внешний атрибут, который сам по себе существенных бонусов не дает."
"Просто меня забавляет реакция на это словосочетание ("бинарные логи")"
Расщепление сознания детектед?
| |
4.214, cosmonaut (ok), 12:37, 04/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Просто меня забавляет реакция на это словосочетание ("бинарные логи") некоторых местных
> петушков, знакомых с юниксом исключительно понаслышке, но при этом обожающих рассказывать,
> что такое юниксвей, и как всем правильно жить =)
Вот, если бы вы знали, что такое cat,grep,sed и другие умные слова для работы с текстовым форматом даных, то знали бы, что при парсинге глазами таких вот бинарных логов (что оч часто бывает полезным, представте) нужно будет либо конвертировать их перед этим в текстовые, либо писать аналоги всего выше сказанного (и не только), что, собственно, смахивает на промышленное велосипедостроение.
...хотя, да, это же дело одного коммита...
| |
|
3.143, Имя и код (?), 05:30, 03/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Вывод: текст вашего сообщения оказался низкокачественным де!!мом (вы со средне-серым образованием
> или обычный гуманитарии?)
На 100% выпускник какого-нибудь "ВУЗа" типа Мэждународного Университета Соломона, фак а-ля "экономическая кибернетика", сп-ть "визуализация табличных данных средствами MS Exhell".
Бакалавр околокомпьютерных наук со стажем.
| |
|
4.171, Аноним (-), 13:38, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Бакалавр околокомпьютерных наук со стажем.
Будем знакомы. И как оно вам, бакалаврам? :)
| |
|
5.206, Имя и код (?), 04:04, 04/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Бакалавр околокомпьютерных наук со стажем.
> Будем знакомы. И как оно вам, бакалаврам? :)
Нам такие как Вы бакалавры забавны :)))
| |
|
|
|
2.67, R (?), 16:34, 02/03/2012 [^] [^^] [^^^] [ответить]
| –4 +/– |
> Ну наконец-то и линукс дошел до того, что в юниксе сделано уже
> двадцать лет назад.
Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.
| |
|
3.84, Аноним (-), 17:36, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые
> логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.
А еще в UNIX auditd (который гораздо важнее syslog), и он пишет бинарные логи.
| |
|
4.154, Имя и код (?), 07:06, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые
>> логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.
> А еще в UNIX auditd (который гораздо важнее syslog), и он пишет
> бинарные логи.
А мексиканского кактуса бритого он важнее. аудитди не расскажет мне кто, аутентифицированный керберосом и авторизированный ЛДАПом, получил коннект через сквид.
И эта, советую поинтересовадзе сколько триггеров/рулз по дефолту в этом ди включено, почему это мизерная часть и шо будет, если этих цацок включить много.
| |
|
5.169, Аноним (-), 13:35, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> А мексиканского кактуса бритого он важнее. аудитди не расскажет мне кто, аутентифицированный
> керберосом и авторизированный ЛДАПом, получил коннект через сквид.
А вот в предлагаемой вон теми парнями схеме - чуть более другой сервис пойдет и расскажет кто и какого хрена. В более-менее унифицированном формате.
| |
|
6.207, Имя и код (?), 04:06, 04/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> А мексиканского кактуса бритого он важнее. аудитди не расскажет мне кто, аутентифицированный
>> керберосом и авторизированный ЛДАПом, получил коннект через сквид.
> А вот в предлагаемой вон теми парнями схеме - чуть более другой
> сервис пойдет и расскажет кто и какого хрена. В более-менее унифицированном
> формате.
Так вот в том-то и дело, шо нет! Просто из-за дурацкого формата будут оверхед и неудобства. Всё.
| |
|
|
|
3.95, Аноним (-), 18:30, 02/03/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые
> логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.
Я так понимаю - вы просто не знакомы с юниксом.
Действительного, когда в мире есть лишь две оси - винда и убунта, все, что не убунта, кажется виндой. Но на самом деле в мире гораздо больше решений, и такая примитивная логика не позволит их осмыслить.
| |
3.144, Имя и код (?), 05:37, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Ну наконец-то и линукс дошел до того, что в юниксе сделано уже
>> двадцать лет назад.
rfc3164 достаточно свежая хреннь.
> Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые
> логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.
Ну... Это неуспешно скрыто за зарослями бинарного формата хранения логофф. :)
| |
|
4.172, Аноним (-), 13:40, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Ну... Это неуспешно скрыто за зарослями бинарного формата хранения логофф. :)
Выбросьте бинарный гзип уже? Вы его деревья хаффмана в уме вообще не построите. И на тетрадном листочке - задолбаетесь.
| |
|
5.208, Имя и код (?), 04:09, 04/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Ну... Это неуспешно скрыто за зарослями бинарного формата хранения логофф. :)
> Выбросьте бинарный гзип уже? Вы его деревья хаффмана в уме вообще не
> построите. И на тетрадном листочке - задолбаетесь.
Ну да, ну да, а изчё выинты повыбрасываем - там коды царя соломона используют.
Тока ведь гзип-то, текстовой природы лога, сцуко, не меняет :)))
| |
|
|
|
|
1.2, Аноним (-), 14:28, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Наверное, стоило особо отметить, что к поддержке проекта уже присоединились компания Adicson, разрабатывающая rsyslog, и BalaBit, разрабатывающая syslog-ng.
| |
|
2.184, исчо_адын_аноним (?), 15:12, 03/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Наверное, стоило особо отметить, что к поддержке проекта уже присоединились компания Adicson,
> разрабатывающая rsyslog, и BalaBit, разрабатывающая syslog-ng.
app-admin/syslog-ng-3.3.4 [3.2.5] USE="hardened ipv6 pcre ssl tcpd -caps -json% -mongodb% (-selinux) -spoof-source -sql -static%"
все как у людей :) хош джисон - бери джисон, хош срать в монго ( угу, свалка ) - сри; скуль тож можно, НО! текст никто не отменя ;)
А идиоту поможет только евтаназия
| |
|
3.209, Имя и код (?), 04:10, 04/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> А идиоту поможет только евтаназия
Я против подобного милосердия! В назидание! :))
| |
3.242, Куяврик (?), 00:46, 13/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> все как у людей :) хош джисон - бери джисон, хош срать
> в монго ( угу, свалка ) - сри; скуль тож можно,
это не интересно. где научная ценность? где новизна диссертации? вот так взял и бэкэнд заменил. нет, надо раскататть в отдельный
| |
|
|
1.3, Аноним (-), 14:32, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Надеюсь, в линуксе наконец появится нормальный механизм удаленной репликации логов, с поддержкой шифрования и аутентификации.
| |
|
|
|
|
|
Часть нити удалена модератором |
|
7.63, Аноним (-), 16:21, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>>Нормальной репликации там нет
> Таки тролль. man rsyslog-mysql
А об ng-syslog никто из анонов, судя по всему, даже не слыхал никогда?
| |
7.85, Аноним (-), 17:37, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Таки тролль. man rsyslog-mysql
А ты сам-то читал, что там написано?
Особенно в части репликации логов с поддержкой шифрования и аутентификации, да в нативном формате.
| |
7.89, Аноним (-), 17:44, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Таки тролль. man rsyslog-mysql
Вы предлагаете конвертировать лог в бинарный формат, а потом реплицировать его средствами СУБД?
Замечательно, но зачем тогда вообще нужен rsyslog? Не проще ли приложениями сразу свой лог в бинарную БД писать, через клиентскую либу мускула?
| |
7.94, Аноним (-), 18:27, 02/03/2012 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Таки тролль. man rsyslog-mysql
Репликация средствами мускула? Лол.
С тем же успехом можно текстовые логи через scp по крону копировать. А че, шифрование и аутентификация есть.
Другое дело, что это, во-первых, костыли (и под требование "нормальности" не попадает), во-вторых, rsyslog, который и должен этим заниматься, оказывается какбэ не при делах.
| |
|
|
9.132, Аноним (-), 03:53, 03/03/2012 [^] [^^] [^^^] [ответить] | –1 +/– | Не, дядя, мускуль в обязательном порядке для всего лишь ведения логов - это мега... текст свёрнут, показать | |
|
|
|
|
|
|
|
|
1.4, Аноним (-), 14:32, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> В ходе встречи участники обсудили такие слабые места текущих подходов к ведению журнала событий как недостаточное внимание к журналированию со стороны разработчиков приложений, *разнообразие форматов журнальных записей*
Разнообразие форматов журналов следует из разнообразия решаемых задач и разнообразия видов отображаемой информации, хотя не всегда. Унификация, конечно, хороша, но тут главное не переборщить
| |
|
2.43, Аноним (-), 15:18, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> а почему сислог они считают устаревшим?
> чем аргументируют?
Не умеет работать со структурированными данными (нет поддержки соответствующих форматов и API).
| |
|
|
2.25, anonymous (??), 14:58, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Так что теперь будет с journald?
А ничего не будет. Он часть systemd и останется. Сделают пересылку в другой журнал, так же как сейчас пересылается в rsyslog. Дублирование журнала в разных форматов уже ни кого не пугает.
| |
2.29, VoDA (ok), 15:05, 02/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Так что теперь будет с journald?
К нему кроме его текущего API добавят ELAPT. А возможно ELAPI будет единственным API к jourland.
Плюс для back compatibility оставят некий интерфейс эмулирующий syslog.
| |
|
3.32, Аноним (-), 15:06, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> К нему кроме его текущего API добавят ELAPT. А возможно ELAPI будет единственным API к jourland.
Скорее второе - нынешний API journald пока не стабилизирован, поэтому сейчас его проще и удобнее подогнать под ELAPI.
| |
|
2.31, Аноним (-), 15:05, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Так что теперь будет с journald?
Судя по всем, Lamberjack - это и есть journald, с небольшими косметическими изменениями. Так что скорее всего эти проекты объединят.
| |
|
1.41, Michael Shigorin (ok), 15:15, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> Две недели назад компания Red Hat собрала в своем офисе
> разработчиков популярных систем ведения логов, чтобы обсудить
Радует то, что постарались обсудить, а не переть своим умом; удачи.
| |
|
2.61, Аноним (-), 16:19, 02/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Радует то, что постарались обсудить, а не переть своим умом; удачи.
А может, они с systemd/upstart еще повторят? Для полного счастья? :)
| |
|
3.66, Аноним (-), 16:25, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Радует то, что постарались обсудить, а не переть своим умом; удачи.
> А может, они с systemd/upstart еще повторят? Для полного счастья? :)
А может, они-таки наймут ОДНОГО вменяемого системного архитектора? И сделают ЕДИНОЕ решение? Совместимость-то важней и производительности и всего остального, если уж на то пошло. Актуальность этой максимы за 35 лет в ИТ посейчас не изменилась.
| |
|
4.71, Michael Shigorin (ok), 16:57, 02/03/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
> И сделают ЕДИНОЕ решение?
Даже у очень умных людей решения в стиле "вот, оно, единое" имеют тенденцию оказываться ущербными не в одном, так в другом. Именно поэтому юниксы с совместимостью по интерфейсам, а не искуственным вырождением поля реализаций, и живы вовсю до сих пор.
> Актуальность этой максимы за 35 лет в ИТ посейчас не изменилась.
Надо же, юниксы пятый десяток разменяли давно, а некоторые всё чуть ли не виндой мерить привыкли...
| |
|
5.179, Аноним (-), 14:45, 03/03/2012 [^] [^^] [^^^] [ответить] | +/– | Мы это видим с каждым новым дистром линукса, которые уже числом, тащемта, за шту... большой текст свёрнут, показать | |
|
4.73, Аноним (-), 17:04, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> И сделают ЕДИНОЕ решение?
А кто не согласен - будет расстрелян, так?
| |
|
|
6.167, zzz (??), 13:21, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> А у несогласных никуда всегда была gentoo.
А что делать тем кому не нравится пидон в каждой дырке в системе? :)
| |
|
|
|
3.91, Аноним (-), 17:50, 02/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А может, они с systemd/upstart еще повторят? Для полного счастья? :)
А что там повторять? Сейчас разработка upstart фактически превратилась в копипасту с systemd, так что понятно, кто в избе хозяин.
Вообще, на последнем фосдеме был слушок, что убунта собирается переходить на systemd начиная с 12.10 (сразу после выпуска LTS).
| |
|
4.133, Аноним (-), 03:55, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> А что там повторять? Сейчас разработка upstart фактически превратилась в копипасту с
> systemd, так что понятно, кто в избе хозяин.
Ну вот я как раз за то чтобы они собрались и обсудили как и чего. К systemd больно дофига предъяв - то usr ему не там, то run не там, то еще дерьмо какое-то случается. Почему-то с upstart таковых воплей было ровно НОЛЬ...
> Вообще, на последнем фосдеме был слушок,
Пруф? Мы тут не старые карги на лавочке, так что сарафанное радио нас не устраивает.
| |
|
5.217, qux (ok), 17:01, 04/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> К systemd больно дофига предъяв - то usr
> ему не там, то run не там, то еще дерьмо какое-то
> случается. Почему-то с upstart таковых воплей было ровно НОЛЬ...
>> Вообще, на последнем фосдеме был слушок,
> Пруф? Мы тут не старые карги на лавочке, так что сарафанное радио
> нас не устраивает.
Это вам-то пруф, с предъявами о usr?
Кто еще не видел: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
| |
|
|
|
|
1.110, pavlinux (ok), 22:17, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся жизни?!
Движок есть - mysql, pgsql, mssql,...sql
Формат есть - SQL
На SQL даже какой-то стандарт есть!
Осталось самую малость - заставить программистов писать SQL запросы.
| |
|
2.127, VoDA (ok), 03:16, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся
> жизни?!
бинарное хранение это следствие, а не причина.
причина же в API для структурированных данных. структурированные данные можно и текстом хранить (хоть в csv). но syslog имеет API для неструктурированных данных (просто текст). если поменять API то можно безболезненно заменить syslog на journald или иной логгер.
вся проблема в том, чтобы сменить API с "лапшового" на строго структурированный.
| |
2.134, Аноним (-), 03:59, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся
... всяким там возможным SQL-иньекциям? :)
И да, как sql база обеспечит защиту от удаления записи задним числом, например?
| |
|
3.222, pavlinux (ok), 01:24, 05/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> И да, как sql база обеспечит защиту от удаления записи задним числом, например?
REVOKE ALL ON logdbase TO logodmin@'localhost';
GRANT INSERT ON logdbase TO logodmin@'localhost' IDENTIFIED BY 'passwd';
| |
|
2.150, XoRe (ok), 06:15, 03/03/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся
> жизни?!
> Движок есть - mysql, pgsql, mssql,...sql
> Формат есть - SQL
> На SQL даже какой-то стандарт есть!
> Осталось самую малость - заставить программистов писать SQL запросы.
А зачем SQL запросы, когда есть NoSQL решения?
С хранением данных чисто в оперативке!
Вам что, жалко пару десятков гигабайт оперативки под логи)
| |
|
1.113, Аноним (-), 22:46, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Сколько же воплей в этом треде... Никаких lumberjack и journald не будет ближайшее время. Успокойтесь. А что плохо и что хорошо, будут решать люди поумнее нас.
| |
|
2.241, arisu (ok), 05:16, 06/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> люди поумнее нас.
я, например, раз уж ты себя не считаешь достойным.
| |
|
1.149, XoRe (ok), 06:13, 03/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
Название - игра слов.
log - бревно.
Lumberjack - дровосек.
Т.е. логоруб)
Нам предлагают систему, которая будет рубить логи.
На корню)
Логи пишутся, чтобы их прочитать, а не чтобы их записать.
Имхо, ради средства жертвуют целью - удобством чтения.
Процесс ради процесса.
<offtopic>
В последнее время стало модным внедрять что-то бинарное.
systemd, upstart, система логов от Поттеринга.
У Microsoft сначала были ini файлы.
Потом они разработали "реестр".
Если сделать дамп реестра и сравнить его формат с форматом ini файла, можно найти, что они похожи.
Примерно, как братья-близнецы.
Это тот же самый ini файл, только теперь в бинарном формате, раскиданный по нескольким файлам.
MS не придумал ничего лучше, чем сделать ini файлы в бинарном формате.
Что мы получили?
1. программы для дефрагментации реестра
2. файлы реестра раскиданы по разным местам
3. эти файлы просто так не скопировать, не открыть
4. а если их и скопировать, то чтобы открыть эти файлы, нужна специальная утилита
Прогресс, *ля.
Как я рад, что в *nix для системных и пользовательских настроек используется первобытный и допотопный plain text формат.
Что позволяет открыть логи и конфиги 20 летней давности даже сейчас.
Без риска получить ошибку "неподдерживаемый формат. пересохраните данные в новом формате."
</offtopic>
| |
|
2.156, Имя и код (?), 07:13, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Название - игра слов.
> log - бревно.
> Lumberjack - дровосек.
> Т.е. логоруб)
> Нам предлагают систему, которая будет рубить логи.
> На корню)
> Логи пишутся, чтобы их прочитать, а не чтобы их записать.
> Имхо, ради средства жертвуют целью - удобством чтения.
> Процесс ради процесса.
Адназначна! :)
| |
2.161, Аноним (-), 11:58, 03/03/2012 [^] [^^] [^^^] [ответить] | +1 +/– | Что мы получили 1 программы для дефрагментации реестра 2 файлы реестра раскид... большой текст свёрнут, показать | |
|
1.186, Аноним (186), 17:05, 03/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
ну скажем так. если требуется для каких-то целей строить по логам статистику - предложенный подход вполне оправдан. если у тебя 50 гигов жатых гзипом логов, делать по ним grep несколько накладно. однако такие задачи возникают редко. то что они пишут о парсерах - тоже правда. вот давеча добавил поле в логформат, пришлось пепенастраивать awstats (тоже описывать там новый логфорат). однако хранение логов в структурированном бинарном формате во многих случаях действительно неудобно. хотя есть дебаг логи где в лог пишется объект в json или что-нибудь такое, грепать по ним нереально.
| |
|
2.199, nobody (??), 02:37, 04/03/2012 [^] [^^] [^^^] [ответить] | +1 +/– | Если нужна статистика, то и сейчас вообще не проблема, например через пайп или п... большой текст свёрнут, показать | |
|
1.198, vi (?), 02:12, 04/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Похоже кто то хочет подзаработать на неграмотности админов.
Что ж, флаг им в руки. Им тоже денежки зарабатывать надо.
| |
|
2.216, Michael Shigorin (ok), 15:26, 04/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> модераторам: сообщение написано на стенке химическим карандашом.
Некоторые из нас понимают в красителях => способны без смывания и закрашивания развалить сопряжённые связи ;)
Что сказать-то хотели?
| |
|
|
4.224, Michael Shigorin (ok), 02:21, 05/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Если сильно постараются, то данный проект может вырасти и вместо
Это вообще какой-то виндузятник с перочинным топориком; непонятно, кто лесорубом назвал.
> получат вполне успешный результат типа
...способного отхватить ноги сразу двоим, если замешкаются?..
Так ведь не все на машине в булочную за углом ездють, есть и вменяемые люди. Технологии сейчас и так страдают недостатком человекопознаваемости в разумные сроки и как следствие -- диагностируемости.
PS: если что, у нас свою подсистему распределённого журналирования писали. И я ни разу не хочу столько сущностей у себя на ноутбуке, даже близко. На несколько тысяч хостов они оправданы, на один -- никак.
| |
|
|
|
|