Статистику SOLR надо переносить отдельно, а stat-general и stat-monthly уже лет 15 показывают полную ерунду, со времен DSPACE4 кажется. Там вся активность SOLR логгируется как пользователская, в итоге для маленьких репозиториев возможно рост показателей в десятки и даже сотни раз.

Её грозились выпилить еще в 6 версии, но видимо убрали в 7.

IdeaFix написал(а):
-------------------------------------------------------
> Статистику SOLR надо переносить отдельно

Подскажите по поводу переноса, видимо что то делаю неверно.

[wiki.lyrasis.org]

Тут всё описано. По сути надо экспортировать статистику из кастомного SOLR который ранее был в составе dspace в новый отдельный solr, который теперь просто ставится из репов...

Цитата:

Statistics data: what to back up depends on what you were using before: the options are the default SOLR Statistics, or the legacy statistics. Legacy stats utilizes the dspace.log files, while SOLR Statistics stores data in [dspace]/solr/statistics. A simple copy of the logs or the Solr core directory tree should give you a point of recovery, should something go wrong in the update process. We can't stress this enough: your users depend on these statistics more than you realize. You need a backup.
Authority data: stored in [dspace]/solr/authority. As with the statistics data, making a copy of the directory tree should enable recovery from errors.

Цитата:

[dspace]/bin/dspace solr-export-statistics -i authority
[dspace]/bin/dspace solr-export-statistics -i statistics

Но реально, просто внимательно статью про апгрейду чего угодно до 7 версии еще раз прочтите, может там добавилось чего с момента когда Вы обновляли.

К сожалению, скрипт «solr-export-statistics» был создан только в DSpace 5.x. Поэтому вы не сможете обновить статистику с версии 4.x и ниже, если предварительно не обновитесь до версии 5.x или 6.x. Это обновление можно выполнить в тестовой среде, чтобы экспортировать статистику (и импортировать её в версии 7.x и ниже). К сожалению, прямого способа миграции Solr Statistics из версии 4.x (или 3.x, или 1.x.x) в версию 7.x нет.

Тоесть перенести статистику без постепенного обновления нет возможности?

А какая версия то была? Третья? Моё имхо - всё же обновиться до 5.11, и потом посмотрев на это всё, на нём и остаться. Без смайлика в конце предложения.

К слову, обновления с ранних третьих версий (не с 3.6+) на 5.х тоже требовали полуручного ребилда статистики - [wiki.lyrasis.org]



Редактировано 1 раз. Последний раз 26.10.2025 13:02 пользователем IdeaFix.

Здравствуйте,
Dspace version-7.6.1
1. Проблема с подсчетом статистики в analytics.google и яндекс метрике.
наблюдаются следующие проблемы:
а) Значимое различие в показателях посещений google(session_start - 13276) и яндекс (визиты -337343), а также first_visit у google -3734 против яндекс 279740
б) Скачивания файлов практически не регистрируются, либо регистрируются в мизерном количестве( что невозможно) , у яндекс метрики в отчетах по загрузке файлов отслеживаются неверные url адреса( например указывает, что произошло 1000 загрузок в результате перехода по страницам по страницам /home; /browse/; /search? А должно быть /bitstreams/) в гугл включена Улучшенная статистика и ползунок Скачивание файлов, но в разделе событий и целевых страницах статистика либо вообще не отображается, либо критически мало. Примечание, в 2023 году проблем с загрузками не было.
в local.cfg # For Google Analytics 4
google.analytics.key = G-XXXXX
данная строка присутствует
2.Попытался перевести интерфейс, из документации узнал, что сделать это можно при помощи файла ru.json, расположенного /src/assets/i18n ( текущая версия Dsdpace 7.6.1) ссылка на документацию:[wiki.lyrasis.org]). После внесения изменения перезапуска tomcat и ui. Никаких изменений не произошло. Более того, даже переименовав папку в которой располагаются переводы и выполнив перезапуск, изменений не было отмечено. Как же тогда перевести интерфейс item? (картинка 1) [ibb.co]
3. Есть ли в dspace возможность сделать так чтобы слова в поле description на странице item было гиперссылкой, которая ведет на страницу со всеми публикациями, содержащие аналогичное description слово(поле), например, все публикации с таким же description полем Английский язык или Анестезия в стоматологии и другое. Вот пример как это выглядит для авторов (картинка 2,3) При нажатии на слово на картинке 2( [ibb.co])перенаправляет на страницу как на 3 картинке [ibb.co]
Буду рад совету, подсказке, может кто-то сталкивался и поделится опытом.

Приветствую.

1. Это нормально, так и должно быть
Гугл аналитика использует не код отслеживания, а механизм с пушем сервера. Т.е. если клиент сделал запрос к ресурсу (и даже включил do not track и вообще весь такой безопасный), сервер (dspace) не отдаст ему контент, пока не отправит пуш в гугл и не получит ответа что клиент посчитан. Таким образом, в гугл аналитике считаются даже клики по прямым ссылкам на PDF с внешних ресурсов.
Яндекс в свою очередь опирается в основном на код отслеживания и на интеграцию аналитики с вебмастером, и в принципе едва ли способен посчитать прямые переходы по ссылкам на PDF (зато генерит бредоотчеты по типам файлов, да), и так же код отслеживания яндекса в общем by default забанен в firefox. Поэтому бросайте вы эти внешние инструменты и анализируйте логи веб-сервера, если хотите иметь представление о реальной нагрузке и посещаемости. IMHO.
2. Не могу прокомментировать. Мало данных. Не понятно что именно кроме файла перевода Вы делали. Какие-то легаси хвосты по локалям до сих пор в конфиге ядра/бэкенда сидят - [github.com]
3. По картинкам на самом деле мало понятно, но видимо речь идет о поисковом/просмотровом индексе по ключевым словам (тематикам)? Если да, то исторически в dublin core их принято складывать в dc.subject. А сделать просмотровый индекс еще и browseable раньше можно было просто через конфиг для webui/jspui. Не думаю что сейчас что-то сильно поменялось.
[github.com]

Если оно у Вас в другом поле сидит и Вас всё устраивает - просто постройте просмотровый индекс по этому полю. В общем это 1-2 строчки в конфиге и перестройка index-discovery (долго).

Здравствуйте,
Dspace version 7.6.1
Попытался сделать индексы как в 3 вопросе в сообщении ранее
в итоге слова в description:(https://ibb.co/Psj7GWQm), стали кликабельны и browseable но при клике происходит следующее:(https://ibb.co/LzbtqzFB).
В dspace.cfg добавил строки description:
Webui.browse.index.5 (https://ibb.co/n8tZkJVN).
Webui.browse.link.2 (https://ibb.co/s9JMjndh).
Вот как выглядит description в submission-forms (https://ibb.co/5hNYRK3Z).
systemctl restart tomcat9.service и pm2 restart dspace-ui выполнял, далее выполнял (dspace)/bin/dspace index-discovery –b а также (dspace)/bin/dspace index-discovery –f запускал в фоне nohup ./dspace index-discovery -b > full-index.log 2>&1 &
ошибка сохраняется также пробовал добавлять bean в discovery.xml также строчку <ref bean="searchFilterDescription" /> в двух местах
(https://ibb.co/TM1XsdCS) также выполнил перезапуск tomcat и ui и (dspace)/bin/dspace index-discovery –f и –b.
Просмотрел множество страниц и документации, но ничего не нашел.

Про вопрос 2, с переводом постараюсь дать больше данных.
Пытался изменить и/или перевести выделенные фрагменты текста
(https://ibb.co/ybhkvZ7)
в документации (https://wiki.lyrasis.org/pages/viewpage.action?pageId=117735441#DSpace7TranslationInternationalization(i18n)Localization(l10n)-Translations(forexample,nl.json5)
Нашел что локализация располагается в папке i18n /Front/DspaceAngular/src/assets/i18n в файле ru.json5, вот расположение папки в программе winscp (https://ibb.co/wZfkLW0b) и ее папки (https://ibb.co/ynWQp1QS) в конечном итоге изменений не происходит, хотя все указывает что именно данные файлы отвечают за локализацию.
Спасибо, что подсказали со статистикой, стал брать из логов nginx, а также из solr(заодно обнаружил, что solr криво считает скачивания bitstreams, но с детектом посещений все в порядке).
Буду благодарен за подсказку, если есть возможность.



Редактировано 1 раз. Последний раз 04.03.2026 12:12 пользователем LibMed.

1. А если сделать ровно так же как в subject? Т.е.

webui,browse.index.5 = description:metadata:dc.description.*:text

2. По переводу мне не очевидно на самом деле, т.к. опыта с 7 нет, но... а dspace-ui точно достаточно перезапустить?

3. По поводу SOLR - всё он нормально считает, просто он и служебное считает - почти все проблемы решает вычитание из его логов [localhost|127\.0\.0\.1]

Здравствуйте. Вернулась проблема 2023 года. Версия dspace 5.5, ОС CentOS 7.9. На веб-мордашке «Внутренняя системная ошибка», в логах dspace “FATAL: remaining connection slots are reserved for non-replication superuser connections”. Проблема возникает днем в рабочее время, но не вечером или ночью. По вашей прошлой рекомендации пробовал поиграться с maxconnections, ставил 400-500. Сервис просто вис, страница переставала грузиться вообще. Пытался установить и настроить PgBouncer, но он не помог. При подключении этого прокси база данных успешно тестируется через dspace database test, но на веб-мордашке при этом «Внутренняя системная ошибка». Логи томката смотрел, там нет какого-то конкретного адреса, с которого якобы харвестится сервис. Такое ощущение, что его или ддосят или БД просто падает из-за большого количества обычных поисковых запросов. Какие есть еще варианты решения проблемы, не предполагающие переустановку\обновление сервиса подскажите, пожалуйста? Сейчас пока, к сожалению, нет возможности обновиться&#9785; Спасибо.

1. Какое значение соединений к базе в dspace.cfg?
2. Какое значение в postgresql.conf? Лежит в /var/lib/pgsql/data/postgresql.conf если у Вас ванильный postgresql 9.x

Параметр max_connections.

ИМХО, в postgresql.conf надо устанавливать значение немного больше чем в dspace.cfg, т.е. 600 и 550 например.

Насчет ДДОСа.... [ideafix.su] у меня bytedance генерирует в течении последних двух недель примерно 90% всех запросов к сервису :(

При условии что перед томкетом стоит апач2 (httpd) и логи лежат там же где у меня, вот такой скрипт

cat /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -n  | tail -n 50
echo "--------"
cat /var/log/apache2/access.log | awk -F'.' -v OFS='.' '{print $1, $2}' | sort | uniq -c | sort -n  | tail -n 10

вернёт ТОП50 ИП адресов за сегодня и ТОП10 подсетей /24.

Посмотрите, нет ли там 39.101.0.0/16 :)

Да, в поиске база давно не участвует. База - это отдать полный текст и в меньшей степени - отдать хендл. А поиск и просмотровые индексы - это давно SOLR. Хотя возможно в 5.5, да еще и с унаследованными от более ранних версий конфигами index-db-browse и активен.

У меня была попытка поанализировать ботов, но... банальный httpd+tomcat через mod_proxy как-то не вывозил. Да можно было это всё обмазать fail2ban'ом (apache-badbots, много 5хх подряд и пр. триггеры) и банить параллельно по юзерагентам (но открытые соединения на 80 и 443 никуда не денутся) и просто активно использовать фаерволл (и ломаться об maxopenfiles и хранение сессий)....

В общем, даже выступив пару раз на профильных конференциях и позадавав вопросы на профильных форумах ничего для себя не закрыл из открытых вопросов и проблем не решил.

В части dspace'ов падает сеть или гипервизор не выдерживая нагрузки, в части, где железа с запасом, падает томкет, причем тихо. А вот postgreSQL у меня давно не падал :)

Сейчас для тушения пожаров я использую скрипт, который даёт такой вывод:

root@elar:~# /opt/ports_stat.sh
--------------------
80 port
Total connections: 2227
Most often IPs:
      1 183.60.87.200
      1 183.60.87.174
      1 183.56.147.172
      1 183.47.125.163
      1 157.148.59.43
      1 157.148.35.127
      1 14.29.109.31
      1 14.29.109.165
      1 120.241.209.254
      1 120.241.209.222
--------------------
443 port
Total connections: 257
Most often IPs:
      6 94.140.155.151
      6 78.138.179.54
      6 24.211.247.253
      6 176.109.252.14
      5 24.12.119.52
      5 136.243.95.154
      4 85.175.198.21
      4 100.16.137.142
      3 95.181.241.238
      3 89.124.76.150
--------------------
8009 port
Total connections: 621
Most often IPs:
    620 127.0.0.1
--------------------
8080 port
Total connections: 1593
Most often IPs:
   1595 127.0.0.1
--------------------
8000 port
Total connections: 1
Most often IPs:
--------------------
2641 port
Total connections: 0
Most often IPs:
      2 134.76.30.195
--------------------
root@elar:~#

А вот собственно код скрипта:

echo "--------------------"
echo "80 port"
echo "Total connections: $(netstat -anp | grep :80 | wc -l)"
echo "Most often IPs:"
netstat -tn 2>/dev/null | grep ':80 ' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
echo "--------------------"
echo "443 port"
echo "Total connections: $(netstat -anp | grep :443 | wc -l)"
echo "Most often IPs:"
netstat -tn 2>/dev/null | grep ':443 ' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
echo "--------------------"
echo "8009 port"
echo "Total connections: $(netstat -anp | grep :8009 | wc -l)"
echo "Most often IPs:"
netstat -tn 2>/dev/null | grep ':8009 ' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
echo "--------------------"
echo "8080 port"
echo "Total connections: $(netstat -anp | grep :8080 | wc -l)"
echo "Most often IPs:"
netstat -tn 2>/dev/null | grep ':8080 ' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
echo "--------------------"
echo "8000 port"
echo "Total connections: $(netstat -anp | grep :8000 | wc -l)"
echo "Most often IPs:"
netstat -tn 2>/dev/null | grep ':8000 ' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
echo "--------------------"
echo "2641 port"
echo "Total connections: $(netstat -anp | grep :2461 | wc -l)"
echo "Most often IPs:"
netstat -tn 2>/dev/null | grep ':2641 ' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
echo "--------------------"

Давайте по порядку. Скрипт работает для 80, 443, 8009, 8080, 8000 и 2641 портов.

80 и 443 это понятно, это apache2/httpd и если там Total connections - большие тысячи, десятки тысяч или сотни, то всё ясно.

Порты 8009 и 8080 - это по сути AJP (внешние клиенты) и SOLR. некоторое время назад я принял решение их разделить, раньше все сидели на 8080 через mod_proxy, но там сложно адекватно закрыватьс ессии без потери удобства, а вот AJP работает почти так, как надо. Соответственно, сейчас когда я делаю зачем-то index-discovery -o или там stats-util -s то видно на сколько кривой у нас SOLR, а юзеры идкт отдельно.

8000 и 2641 - это порты handle сервера. Оно у нас куплено, настроено и работает и.... логов не ведет и fail2ban на это дело настроить тяжело. При этом байтденс бот может прийти к нам по ссылкам вида hdl.handle.net десять тысяч раз в секунду.

В общем, у меня подобралось какое-то количество не оптимальных и наверняка не самых репрезентативных скриптов и какое-то количество практик их использования. Если есть интерес, а лучше, если есть что добавить (или полностью заменить!) на тему [ideafix.su] то я только за.

у меня dspace 5.5 обновленный с 1.8, postgresql на днях обновил с 9.5 на 14.22, апача нет, только томкат. подскажите, как отмониторить вот точно также, как вы в апаче привели, топ запросов к сервису в томкат? Параметры max_connections в конфиге pg и ds выставил, как вы посоветовали. Утром гляну на результат...

А обновите еще это - [ideafix.su] с проверкой dspace database info до и после.

Для скрипта указанного выше apache2/httpd не используется, т.е. часть:

echo "--------------------"
echo "80 port"
echo "Total connections: $(netstat -anp | grep :80 | wc -l)"
echo "Most often IPs:"
netstat -tn 2>/dev/null | grep ':80 ' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head

Использует только команды echo, awk, netstat, sort, uniq grep, wc, cut. Если чего-то не будет хватать - yum install netstat или yum install awk.

Другие скрипты, которые используют /var/log/apache2/access.log доложны работать условно при учете двух условий, ну трех:
1. в localhost_access.log файле томкета реальные ип а не сплошной 127.0.0.1
2. путь до localhost_access.log известен (у меня томкет из дистрибутива и лог за сегодня находится по пути /var/log/tomcat9/localhost_access_log.2026-05-15.txt)
3. localhost_access.log имеет формат combined (для парсинга юзерагентов).


Т.е. допустим код "для apache2/httpd" выглядит так:

cat /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -n  | tail -n 50
echo "--------"
cat /var/log/apache2/access.log | awk -F'.' -v OFS='.' '{print $1, $2}' | sort | uniq -c | sort -n  | tail -n 10

А для tomcat так:

cat /var/log/tomcat9/localhost_access_log.$(date +%F).txt | awk '{print $1}' | sort | uniq -c | sort -n  | tail -n 50
echo "--------"
cat /var/log/tomcat9/localhost_access_log.$(date +%F).txt | awk -F'.' -v OFS='.' '{print $1, $2}' | sort | uniq -c | sort -n  | tail -n 10

Результат будет плюс-минус одинаковым. Почему плюс-минус? Потому что "сегодняшний" лог в apache2/httpd и tomcat создается/ротейтится в разное время.


[upd]
Нет, возможно просто взять и заменить это [mvnrepository.com] на это # [mvnrepository.com]
'org.postgresql:postgresql:jar:42.7.11' не выйдет.



Редактировано 1 раз. Последний раз 15.05.2026 10:22 пользователем IdeaFix.

Обновил драйвер postgresql для dspace по вашему мануалу. Обновил java до 8_491. После 30 минут работы сервера анализ лога томкат показывает, что там тысячи localhost (логирование только включил специально, вообще отключено, т.е. лог не с начала дня):
13 98.83.177.42
14 104.28.200.203
14 66.249.70.32
15 109.62.207.17
15 193.233.120.75
15 40.77.167.58
16 176.59.174.127
16 18.220.99.37
16 31.163.56.135
16 3.14.150.3
16 3.144.146.2
17 18.222.230.9
17 188.168.144.169
18 52.167.144.21
19 3.15.20.61
20 178.76.231.29
21 66.249.64.129
22 46.138.207.249
23 52.167.144.203
24 172.16.1.40
25 40.77.167.235
25 52.167.144.163
37 40.77.167.14
43 40.77.167.38
44 216.244.66.200
44 40.77.167.70
45 172.16.1.44
46 147.45.50.171
47 157.55.39.197
49 40.77.167.123
50 157.55.39.10
50 66.249.64.128
51 156.59.198.136
53 52.167.144.211
61 40.77.167.35
64 156.59.198.135
65 40.77.167.151
71 40.77.167.76
87 66.249.64.132
113 147.135.213.11
135 207.46.13.141
135 52.167.144.229
166 40.77.167.22
301 157.55.39.192
404 216.244.66.198
414 199.47.82.19
2272 74.7.241.53
2363 74.7.227.147
2425 74.7.242.22
387556 127.0.0.1

Вот результат скрипта с netstat на порту 80:
154 127.0.0.1
3 188.239.39.134
3 178.155.115.248
2 98.83.10.183
2 74.7.242.22
2 74.7.241.53
2 74.7.227.147
2 66.249.64.132
2 178.169.116.105
2 109.62.207.17

Если так много локалхостов – это нормально или это и есть проблема?

Анализ сессий PG показывает, что они все забиты вот таким запросом: SELECT * FROM MetadataValue WHERE resource_id= $1 and resource_type_id = $2 ORDER BY metadata_field_id, place
Причем запросы однотипные, подвисают и висят десятками минут. Я пытался вводить лимит времени на подвисшие сессии, но все равно dspace через некоторое время выдает ошибку БД.



Редактировано 2 раз. Последний раз 15.05.2026 18:07 пользователем phoenix2.

> Если так много локалхостов – это нормально или это и есть проблема?
Это нормально. Это SOLR ходит "сам в себя"

А насчет СУБД, посмотрите что у Вас тут:

[github.com]

Не форсирован ли

browseDAO.class = org.dspace.browse.BrowseDAOPostgres
browseCreateDAO.class = org.dspace.browse.BrowseCreateDAOPostgres

Просто не должно такого быть. Вроде index-db-browse в пять уже скорее для галочки, а в 6 и вовсе дропнут, а начиная с версии 4 и поиск и просмотр и статистика - SOLR. Воможно что-то осталось от 1.х в конфиге.

Так же проверьте что после обновления dspace database-info показывает, новую версию библиотеки? Ибо то что было из коробки (библиотека от 2011 года) возможно и не будет нормально работать с postgresql14, а простая замена одной библиотеки на другую может сработать не так, как ожидается. В более поздних версиях dspace речь идет о замене версии, а в 5.5 не версия обновляется а заменяется библиотека.

Ну и да...

74.7.241.129 - - [15/May/2026:20:54:56 +0500] "GET /robots.txt HTTP/1.1" 200 542 "http://elar.usu.ru/robots.txt" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36; compatible; OAI-SearchBot/1.3; robots.txt; +[openai.com]"

Это по моим логам. Пойду забаню...

[UPD] уже было забанено. В htaccess запрест по юзхерагентоу всего что не nobots.txt, а в robots.txt ожидаемый deny all.



Редактировано 1 раз. Последний раз 16.05.2026 00:08 пользователем IdeaFix.

[ideafix.su] - зафиксировал в одном посте

вот результат после замены драйвера: dspace database info
Database URL: jdbc:postgresql://localhost:5432/dspace
Database Schema: public
Database Software: PostgreSQL version 14.22
Database Driver: PostgreSQL JDBC Driver version 42.2.29.jre7
+----------------+----------------------------+---------------------+---------+
| Version | Description | Installed on | State |
+----------------+----------------------------+---------------------+---------+
| 1.1 | Initial DSpace 1.1 databas | | PreInit |
| 1.2 | Upgrade to DSpace 1.2 sche | | PreInit |
| 1.3 | Upgrade to DSpace 1.3 sche | | PreInit |
| 1.3.9 | Drop constraint for DSpace | | PreInit |
| 1.4 | Upgrade to DSpace 1.4 sche | | PreInit |
| 1.5 | Upgrade to DSpace 1.5 sche | | PreInit |
| 1.5.9 | Drop constraint for DSpace | | PreInit |
| 1.6 | Initializing from DSpace 1 | 2016-04-18 06:28:33 | Success |
| 1.7 | Upgrade to DSpace 1.7 sche | 2016-04-18 06:28:34 | Success |
| 1.8 | Upgrade to DSpace 1.8 sche | 2016-04-18 06:28:36 | Success |
| 3.0 | Upgrade to DSpace 3.x sche | 2016-04-18 06:28:37 | Success |
| 4.0 | Upgrade to DSpace 4.x sche | 2016-04-18 06:28:37 | Success |
| 5.0.2014.08.08 | DS-1945 Helpdesk Request a | 2016-04-18 06:28:37 | Success |
| 5.0.2014.09.25 | DS 1582 Metadata For All O | 2016-04-18 06:28:37 | Success |
| 5.0.2014.09.26 | DS-1582 Metadata For All O | 2016-04-18 06:28:37 | Success |
+----------------+----------------------------+---------------------+---------+

в dspace.cfg в том разделе у меня вот так:
###### Browse Configuration ######
#
# Define the DAO class to use this must meet your storage choice for
# the browse system (RDBMS: PostgreSQL or Oracle, Solr).
# By default, since DSpace 4.0, the Solr implementation is used
#
# PostgreSQL:
# browseDAO.class = org.dspace.browse.BrowseDAOPostgres
# browseCreateDAO.class = org.dspace.browse.BrowseCreateDAOPostgres
#
# Oracle:
# browseDAO.class = org.dspace.browse.BrowseDAOOracle
# browseCreateDAO.class = org.dspace.browse.BrowseCreateDAOOracle
#
# Solr:
# browseDAO.class = org.dspace.browse.SolrBrowseDAO
# browseCreateDAO.class = org.dspace.browse.SolrBrowseCreateDAO

Благодаря вашему скрипту для анализа логов томката через iptables перебанил айпишники, которые были в сильных топах по обращениям. Пока сервис работает. Мониторю дальше. Еще обновил томкат с версии 8 на последний релиз 9 и включил там RateLimitFilter, чтоб банил ip, которые часто стучатся к томкату. НО, чуть позже заметил, что хоть веб-сервис работает, но БД все равно забивается повисшими транзакциям, и я плотно засел в deepseek. Благодаря его подсказкам:
1) завел для jspui context.xml, настроил там параметр removeAbandoned и контроль количества соединений в состоянии “idle”;
2) обратил внимание, что БД забивается непосредственно после перезапуска tomcat, а после принудительного обрывания соединений в БД dspace больше повисших транзакций не возникает;
3) настроил в БД лимиты сессий idle_in_transaction_session_timeout и idle_session_timeout на 5 минут, таким образом, чтобы даже зависшие при первой загрузке (или при последующей работе) tomcat сессии через 5 минут оборвутся.
За сервисом наблюдал 2 неделb. Пока полёт нормальный. Благодаря вашей помощи и помощи нейронки попробую еще на несколько лет отложить вопрос обновления dspace, т.к. мне за его администрирование не платят Спасибо.



Редактировано 2 раз. Последний раз 04.06.2026 15:05 пользователем phoenix2.

Это к сожалению не конец. У Вас первой точкой отказа была СУБД, а у нас - maxopenfoles. Починили базу, потом упрётесь в то что сервис открывает файлов одновременно больше лимита, потом в таблицы фаерволла, который из коробки в дистрибутивах зачем-то хранит 5 дней инфу о сессиях и таблица тоже конечна. Тут будет несколько шагов, я думаю.

Главное - в процессе не сломать ничего, ибо я точно наделал много лишнего и порой не верно интерпретировал результаты, полагая что лучше стало из-за моих действий, а на самом деле просто боты уходили на время.

С одной стороны хорошо что можно подтянуть знания и по тому и по этому... с другой - очень уж комплексная задачка всё равно получается, да и не очень полезная в плане опыта, если постоянно это не администрируешь и опыт не тиражируется.



Редактировано 1 раз. Последний раз 05.06.2026 11:56 пользователем IdeaFix.

Насчет того, что это не первая проблема, с которой я столкнусь... Так я ж тут обращался уже с такой же проблемой в январе 2023го. Тогда вы предположили, что сервис коряво харвестят или ддосят. Проблема тогда ушла сама собой через несколько недель, и юзеры меня не успели начать "наклонять", довольствовались отговорками. Сервис потом успешно работал 3 года.
А вот у меня теперь такой вопрос... Я по вашему скрипту продолжаю банить приставучие айпишники. Среди них, например, RIPE Network Coordination Centre, Amazon.com, crawler.turnitin.com.
Чем в плане внешней видимости грозит моему сервису то, что я баню их обращения?

На самом деле моё субъективное мнение плюс-минус описано тут - [ideafix.su]

Его можно сформулировать так: надо попытаться разделить ботов на плохих и хороших, и не понятных.

Хорошие, это базовые сео инструменты для внешней аналитики, поисковые системы и пр. сервисы, которые либо конвертируют свои харвесты в посещения своими клиентами, либо, как в слкчае с dmoz/ahrefs/majesticseo и пр. косвенно влияют на вес домена. Удивительно, но "хорошие" боты уважают robots.txt, не создают диких нагрузок и в принципе ведут себя так, что это никому не мешает. Исключением по своему опыту я могу назвать разве что ms bing, который может набежать раз в два месяца и попытаться в течении часа выкачать весь репозиторий.

Плохие - это прямо плохие, например буквально китайские боты, и не важно, байтданс это или петалсич, я не вижу механизма конвертации создаваемой ими нагрузки в пользователей репозитория. Байтданс просто учит ЛЛМ на наших данных, а PetalBot вроде даже и можно отнести к хорошим, но даже в материковом Китае мне местные не смогли продемонстрировать результат запроса типа site:elar.urfu.ru в хуавеевском поисковике. Далее к плохим я отношу агенты амейзона, фейсбука, OpenAI и пр. операторов LLM, которые обучают свои модели. Эти просто дикие.... качают как Bing но каждый день.

Ну и всякое непонятное тоже надо периодически посматривать.

Банить прямо фаерволлом по диапазонам адресов конечнов есело, но RIPE Network Coordination Centre это арендные диапазоны которые покупает непонятно кто, и как их банить? /16 сетями? Едва ли это эффективно.

Пока я баню веб-сервером много кого по юзерагенту, всё же приятно, что фейсбуку по статусу не положено подделывать юзерагент :) А некоторые китайские гиперскейлы (Alicloud) действительно приходится банить подсетями.

И когда кажется что всё хорошо, оказывается что ресурсы исчерпываются где-то в других местах - то 40 тысяч соединений на 443 порту и 30 тысяч на 8009, то у фаерволла табличка переполнилась, то еще что-то.

Итого, остаются два момента:
1. Последствия - считаю что если забанить ИИ краулеры и оставить поисковые системы, ничего мы не потеряем ни в моменте ни в перспективе
2. Не решенные задачи - всех не забанишь.


Отдельаня тема - не гугл, который косит под гугл. У меня естьс крипт который по host проверяет всех кто показывает гугловый юзерагент, но таких не много, там я просто пишу на abuse контакт и ставлю гугл в копию.

Тут оказалось что у меня и тестовый сервер on fire....

[test.ideafix.su] - очень локальная песочница для тестовых загрузок, в которой давно не было более 1000 документов. С начала мая по 2-3GB логов в сутки.

Проблему решил так:

RewriteEngine on

RewriteCond %{HTTP_USER_AGENT} (Hello\-World|Scrapy|meta\-webindexer|meta\-externalagent|PetalBot|Baiduspider|Bytedance|Bytespider|Yatcybot|OAI\-SearchBot|ChatGPT\-User|ClaudeBot|keys\-so\-bot|PerplexityBot|TerraCotta|Wget|curl|aiohttp) [NC]
RewriteCond %{REQUEST_URI} !^/robots\.txt$ [NC]
RewriteRule .* - [F,L]

Гугла с бингом в логах не было, они приличные, читают robots.txt - [test.ideafix.su]

Понятно что в продовый сервис кого-то из этих ребят придётся запустить, но тут скорее концепт...

В конкретном случае какую-то дикую, несоразмерную количеству контента нагрузку создавали meta-webindexer и meta-externalagent



Редактировано 4 раз. Последний раз 11.06.2026 10:51 пользователем IdeaFix.

Ну что.... наверное теперь [ideafix.su] я в общем закончил.

0. всякое правильное в sysctl.conf, ибо в современных линуксах это необходимо
1. прятать tomcat за веб-прокси правильно и настраивать и томкет и веб прокси
2. закручивать гайки на уровне веб-сервера (юзерагенты в хтаксес, сессии, треды, потоки, таймауты)
3. файл2бан (а хотя бы и по юзерагентам и всяким запросам на /wp-admin, phpinfo и прочих червей, чище будет)
4. фаерволл
5. мониторинг

Вот опять сегодня ресурс, который на длинне сессии 5 минут демонстрировал обычную нагрузку 700-4500 тысяч соединений в томкете, стал демонстрировать 20000+ соединений. Этот ресурс не падает и на 70 тысячах, но начинает тормозить.

Начинаю разбираться....

awk '{print $1}' /var/log/apache2/access.log | cut -d. -f1,2 | sort | uniq -c | sort -rn | head -n 6

20328 66.249
10078 65.109
4828 34.29
4135 169.224
3393 213.230
3070 5.255

Ничо не понятно, но очень интересно.... смотрим дальше:

awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -n 10
   9628 65.109.100.157
   9319 66.249.69.8
   5561 66.249.69.7
   4748 34.29.217.106
   3506 66.249.69.9
   2173 216.244.66.230
    972 66.249.69.10
    590 78.142.18.40
    529 94.139.252.237
    357 65.109.35.209

Уже понятнее.... смотрим еще дальше:

/opt/today_users_not_gyb.sh | grep '+' | tail -10
     76 Mozilla/5.0 (compatible; YandexAccessibilityBot/3.0; +[yandex.com]) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0
     95 Mozilla/5.0 (compatible; vkShare; +[vk.com])
    301 Mozilla/5.0 (compatible; AhrefsBot/7.0; +[ahrefs.com])
    362 Mozilla/5.0 (compatible; AwarioBot/1.0; +[awario.com])
    484 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +[sleepbot.com]) Chrome/131.0.0.0 Safari/537.36
    914 Mozilla/5.0 (compatible; SemrushBot/7~bl; +[www.semrush.com])
   1706 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Safari/605.1.15 (Applebot/0.1; +[www.apple.com])
   2186 Mozilla/5.0 (compatible; DotBot/1.2; +[opensiteexplorer.org]; help@moz.com)
   4316 Sogou web spider/4.0(+[www.sogou.com])
  13263 Mozilla/5.0 (compatible; SERankingBacklinksBot/1.0; +[seranking.com])

Итого, 65.109.100.157 - один из ботов семруша, можно бы и забанить, но не поможет. А вот 65.109.0.0/16 и 34.29.0.0/16 - это гугл :) Так что сидим и терпим....

Чтобы не терпеть гугла, можно сделать так - [ideafix.su]

А именно забанить только Google Cloud Platform.

В итоге у нас получилась хоть какая-то иллюзия контроля посредством следующих действий:

1. Бан прямо автономками Google Cloud Platform (но не Google Bot) — [ideafix.su]
2. Бан крупных облачных провайдеров (кроме Amazon, на нём сидят letsencrypt и handle.net) — [ideafix.su]
3. Бан на уровне веб сервера некоторых юзерагентов — [ideafix.su]
4. Бан юзерагентов параллельно на уровне fail2ban
5. Настройка сетевого стека linux и веб-сервера для того чтобы держать удар. Ибо банально conntrack на полмиллиона забивался за 5 минут порой.

По поунктам 4 и 5 в общем тоже могу написать какой-то текст если нужно.

Сейчас активно наблюдаю за двумя репозиториями в одном городе, использующим одно и то же ПО и в прицнипе очень похожий программный стек, и использующих похожие практики поплонения. Один репозиторий испытывает серьезную нагрузку из сетей linode, второй - из сетей alicloud. Картина стабильна на потряжении нескольких месяцев. При этом первый репозиторий вообще не интересен клиентам аликлауд а второй - клиентам linode.