# Логирование Squid и Exchange **URL:** \ **Category:** Вопросы на русском языке\ **Created:** [September 20, 2019, 6:50pm UTC](https://discuss.elastic.co/t/squid-exchange/200476 "2019-09-20T18:50:56Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![KOTOXJle6](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kotoxjle6/32/131136_2.png) [@KOTOXJle6](https://discuss.elastic.co/u/KOTOXJle6)\ **Post date:** [September 20, 2019, 6:50pm UTC](https://discuss.elastic.co/t/squid-exchange/200476/1 "2019-09-20T18:50:56Z")
Добрый день. Возникло желание для этих двух систем настроить долговременное хранение логов. Поиск готовых решений привел к некоторым результатам, но есть некоторые проблемы: 1. Squid. Он генерирует огромное, для нашей инфраструктуры, количество логов. Порядка 100ГБ в день в ежедневном индексе. Хотелось бы как-то их ужать, но не знаю как. Из пришедших в голову вариантов было попытаться писать больше информации в один документ, возможно через multiline. Либо создавать под каждого пользователя свой индекс и всю информацию по пользователю писать туда. Но есть подозрение что если это и получится реализовать, то искать информацию будет очень сложно. 2. Exchange. Я хотел бы вести логи журнала MessageTracking для 4 серверов. Они генерируют меньше логов, хотя объем тоже получается большой. Идея была распарсить лог через фильтр grok, затем вырезать лишние поля, в надежде что лог будет меньше и искать данные в индексах будет проще. Но надежды на простое решение разбились об регулярные выражения. Через grok debugger я вывел вот такую регулярку: `(%{TIMESTAMP_ISO8601:date_time}),,(%{HOSTNAME:client_hostname}),,(%{HOSTNAME:server_hostname}),(%{GREEDYDATA:source_context}),,(%{GREEDYDATA:connector_id}),(%{WORD:source}),(%{WORD:event_id}),<(%{GREEDYDATA:internal_message_id})>,(%{UUID:message_id}),(?[a-zA-Z0-9_.+=(%{NUMBER:total-bytes}):-]+@[0-9A-Za-z][0-9A-Za-z-]{0,62}(?:\.(?:[0-9A-Za-z][0-‌​9A-Za-z-]{0,62}))*),(%{DATA:recipient_status}),(%{NUMBER:total_bytes}),(%{NUMBER:recipient_count}),,,(%{DATA:message_subject}),(?[a-zA-Z0-9_.+=(%{NUMBER:total-bytes}):-]+@[0-9A-Za-z][0-9A-Za-z-]{0,62}(?:\.(?:[0-9A-Za-z][0-‌​9A-Za-z-]{0,62}))*),(?[a-zA-Z0-9_.+=(%{NUMBER:total-bytes}):-]+@[0-9A-Za-z][0-9A-Za-z-]{0,62}(?:\.(?:[0-9A-Za-z][0-‌​9A-Za-z-]{0,62}))*),(%{GREEDYDATA:message_info})?,(%{WORD:directionality})?,(%{GREEDYDATA:tenant_id})` В дебаггере она отрабатывает идеально, но если вставлять это в конфиг фильтра logstash в таком виде ``` filter { if "exchange" in [tags] { grok { match => { "message" => "(%{TIMESTAMP_ISO8601:date_time}),,и далее до конца" } } } } ``` То logstash просто перестает принимать логи со всех серверов вообще. В логе filebeat появляются такие сообщения ``` ERROR pipeline/output.go:100 Failed to connect to backoff(async(tcp://10.0.215.141:5044)): dial tcp 10.0.215.141:5044: connectex: No connection could be made because the target machine actively refused it. ``` Если менять ту часть, где выделяется email, на (%{EMAILADDRESS:email}), то в дебаггере появляется ошибка Compile ERROR (причем судя по темам с названием grok EMAILADDRESS, проблема не только у меня). А в logstash логи приходят с тегом \_grokparsefailure. В logstash\_plain.log есть такое: ``` [ERROR][logstash.javapipeline] Pipeline aborted due to error {:pipeline_id=>"main", :exception=>#:main, :action_type=>LogStash::ConvergeResult::FailedAction, :message=>"Could not execute action: PipelineAction::Create
, action_result: false", :backtrace=>nil} ``` Проблема точно связана с %{EMAILLOCALPART}, но непонятно что с этим можно сделать. Регулярка до части с почтой отрабатывает в Logstash отлично и в ES приходит правильно. Вопросы: Возможно ли сделать с размером логов squid/exchange то, что хотелось бы или такой рост документов норма и нужно смириться? В чем может быть ошибка регулярного выражения? Это проблема именно с логами Exchange или EMAILLOCALPART в таком виде не работает у всех? Адеватно ли вообще собирать эти логи через ELK или я трачу время впустую? ---
**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\ **Post date:** [September 20, 2019, 7:36pm UTC](https://discuss.elastic.co/t/squid-exchange/200476/2 "2019-09-20T19:36:35Z")
С гроком я так на вскидку сказать где проблема не могу, что касается размеров логов - то вопрос в том, какая у Вас цель? Что Вы в этих логах squid собираетесь найти? ---
**Author:** ![KOTOXJle6](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kotoxjle6/32/131136_2.png) [@KOTOXJle6](https://discuss.elastic.co/u/KOTOXJle6)\ **Post date:** [September 20, 2019, 8:00pm UTC](https://discuss.elastic.co/t/squid-exchange/200476/3 "2019-09-20T20:00:48Z")
Со squid хотелось бы получать данные о том, куда какой пользователь ходил за последние пол года. Для этих целей уже есть lightsquid+sqstat, но мне бы хотелось держать все логи в одном месте. Для Exchange в идеале хотелось бы видеть аналог powershell команды "Get-MessageTrackingLog -Sender [mailto:user@domain.com](mailto:user@domain.com) | ft Timestamp, sender, recipient, message, subject-AutoSize" и тоже держать эти логи вместе с остальными. ---
**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\ **Post date:** [September 20, 2019, 8:05pm UTC](https://discuss.elastic.co/t/squid-exchange/200476/4 "2019-09-20T20:05:49Z")
> [@KOTOXJle6](#): > > Со squid хотелось бы получать данные о том, куда какой пользователь ходил за последние пол года. В этом случае URL - это, наверное, самая большая часть и единственно что можно порезать - это вытащить из URL домейн. Но не уверен, что это имеет смысл. ---
**Author:** ![KOTOXJle6](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kotoxjle6/32/131136_2.png) [@KOTOXJle6](https://discuss.elastic.co/u/KOTOXJle6)\ **Post date:** [September 21, 2019, 5:07am UTC](https://discuss.elastic.co/t/squid-exchange/200476/5 "2019-09-21T05:07:45Z")
Я так понимаю сейчас объем такой большой из-за того что под каждую строку создается отдельный документ? Можно как-нибудь рассчитать насколько увеличивается объем строчки лога, когда она загружается в elasticsearch? А если попытаться класть больше одной строки в один документ, это может помочь? Только в этом случае наверно придется отказаться от фильтров. Или если лить как сейчас, но удалять лишние поля? У меня сейчас grok разбирает message на отдельные поля по коду, ip источника, ip хоста и т.д. Половина полей точно не нужна. ---
**Author:** ![KOTOXJle6](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kotoxjle6/32/131136_2.png) [@KOTOXJle6](https://discuss.elastic.co/u/KOTOXJle6)\ **Post date:** [September 21, 2019, 6:09am UTC](https://discuss.elastic.co/t/squid-exchange/200476/6 "2019-09-21T06:09:34Z")
Еще немного потестировал регулярки для Exchange, понял что хорошо работает такая: `(%{TIMESTAMP_ISO8601:date_time}),,(%{HOSTNAME:client_hostname}),,(%{HOSTNAME:server_hostname}),(%{DATA:source_context}),,(%{DATA:connector_id}),(%{WORD:source}),(%{WORD:event_id}),<(%{DATA:internal_message_id})>,(%{UUID:message_id}),(%{DATA:recipient_address}),(%{DATA:recipient_status}),(%{NUMBER:total_bytes}),(%{NUMBER:recipient_count}),,,(%{DATA:message_subject}),(%{DATA:sender_address}),(%{DATA:message_info}),(%{WORD:directionality}),(%{DATA:tenant_id})` Но еще оказалось что записи в журналах Exchange выглядят по-разному. У всех одна структура: `#Fields: date-time,client-ip,client-hostname,server-ip,server-hostname,source-context,connector-id,source,event-id,internal-message-id,message-id,network-message-id,recipient-address,recipient-status,total-bytes,recipient-count,related-recipient-address,reference,message-subject,sender-address,return-path,message-info,directionality,tenant-id,original-client-ip,original-server-ip,custom-data` Но поля могут быть заполненными, а могут быть пустыми. Там, где заполненные поля совпадают с регуляркой, все супер. А где отличаются - там parse error. Пока не придумал как это победить. ---
**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\ **Post date:** [September 21, 2019, 7:42pm UTC](https://discuss.elastic.co/t/squid-exchange/200476/7 "2019-09-21T19:42:06Z")
А сначала [разбить по запятым](https://www.elastic.co/guide/en/logstash/7.4/plugins-filters-csv.html), а потом возиться с каждым полем отдельно не пробовали? ---
**Author:** ![KOTOXJle6](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kotoxjle6/32/131136_2.png) [@KOTOXJle6](https://discuss.elastic.co/u/KOTOXJle6)\ **Post date:** [September 23, 2019, 12:28pm UTC](https://discuss.elastic.co/t/squid-exchange/200476/8 "2019-09-23T12:28:17Z")
Попробовал, понравилось намного больше. В logstash отрезал поля, которые получил из csv, а в filebeat удалил лишние системные поля. Спасибо. А по предыдущему вопросу про объем документов сможете подсказать? ---
**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\ **Post date:** [September 23, 2019, 1:55pm UTC](https://discuss.elastic.co/t/squid-exchange/200476/9 "2019-09-23T13:55:09Z")
Если вам только статистику надо знать, то можно выключить \_source и индексацию полей c URL, оставить только docvalues. То есть проиндескировать только timestamp и оставить docvalues только для пользователей, timestamp и URL. Думаю, это должно уменьшить размер раза в 2-3. Но кроме статистики по тому какие сайты кто посещал, вы больше ничего не получите. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [October 21, 2019, 1:55pm UTC](https://discuss.elastic.co/t/squid-exchange/200476/10 "2019-10-21T13:55:10Z")
Closed on October 21, 2019, 1:55pm UTC This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.