• Debian 11 is approaching its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.80 will be the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

Issue Plesk Monitoring generates thousands of localhost requests in httpsd_access_log

Azurel

Silver Pleskian
Server operating system version
AlmaLinux 9.8
Plesk version and microupdate number
18.0.80#2
I noticed that /var/log/plesk/httpsd_access_log is filled with thousands of requests generated by the Plesk Monitoring extension, for example:

127.0.0.1 - - [19/Aug/2026:10:54:20 +0200] "POST /modules/monitoring/public/index.php/Sa_....oY/query HTTP/1.1" 200 129 "-" "Go-http-client/1.1" "-"'/modules/monitoring/public/index.php/Sa_....oY/query' '' '/usr/local/psa/admin/htdocs'

The requests are coming from 127.0.0.1, return HTTP 200, and occur at a very high frequency (in this example every ~2 seconds). The log has grown to around 75 MB in than two weeks. Previous archived files of httpsd_access_log are around 300KB.

Code:
# ls -lah /var/log/plesk/httpsd_access_log*
-rw-r--r-- 1 root root  75M Aug 19 12:10 /var/log/plesk/httpsd_access_log
-rw-r--r-- 1 root root 289K Jul 31 03:25 /var/log/plesk/httpsd_access_log-20260731.gz
-rw-r--r-- 1 root root 240K Aug  3 03:44 /var/log/plesk/httpsd_access_log-20260803.gz
-rw-r--r-- 1 root root 328K Aug  6 03:05 /var/log/plesk/httpsd_access_log-20260806.gz

I have this questions:
  1. Why are these internal Monitoring requests written to the regular httpsd_access_log at all?
  2. Is the very high polling frequency (multiple requests every few seconds) expected behavior, and is there a way to reduce it?
  3. Why is my httpsd_access_log not logrotating?
 
Why are these internal Monitoring requests written to the regular httpsd_access_log at all?

As far as I am aware, this is expected behavior. Monitoring calls go through the same web server, thus, they get recorded in the same log file.

Is the very high polling frequency (multiple requests every few seconds) expected behavior, and is there a way to reduce it?

When you observe that behavior do you/another admin interact with Monitoring in Plesk panel?

Why is my httpsd_access_log not logrotating?

Can you please confirm what's the current logrotate confirmation and do you observe the issue with that particular file only or with other logs as well?
 
What files would need to change, and where? Which service create httpsd_access_log-2026XXXX.gz?

I see
/var/log/maillog.processed.1.gz was created 18.08.2026
or
/var/www/vhosts/example.com/logs/access_ssl_log.processed.1.gz was created 19.08.2026

What I find strange is that logrotate supposedly hasn't been running since the upgrade from AlmaLinux 8 to 9. Is it different in AlmaLinux 9?

AlmaLinux8to9 was 07 August:
Code:
reboot   system boot  5.14.0-611.55.1. Fri Aug  7 08:39 - 06:13 (1+21:34)
shutdown system down  4.18.0-553.153.1 Fri Aug  7 08:30 - 08:39  (00:08)

Code:
# journalctl --since "2026-08-05" | grep -i logrotate
Aug 05 03:47:04 example.com run-parts[3741847]: (/etc/cron.daily) starting logrotate
Aug 05 03:47:11 example.com run-parts[3743433]: (/etc/cron.daily) finished logrotate
Aug 06 03:07:02 example.com run-parts[470927]: (/etc/cron.daily) starting logrotate
Aug 06 03:07:03 example.com run-parts[471997]: (/etc/cron.daily) finished logrotate
Aug 07 03:51:03 example.com run-parts[751895]: (/etc/cron.daily) starting logrotate
Aug 07 03:51:04 example.com run-parts[752951]: (/etc/cron.daily) finished logrotate

help this?

ls -la /etc/cron.daily/
total 32
drwxr-xr-x. 2 root root 4096 Aug 10 20:16 .
drwxr-xr-x. 143 root root 12288 Aug 18 09:52 ..
-rwxr-xr-x 1 root root 539 Aug 10 13:36 50plesk-daily
-rwxr-xr-x 1 root root 82 Jan 3 2019 curl-cacert
-rwxr-xr-x 1 root root 131 Jul 29 13:03 dmarc-report
-rwxr-xr-x 1 root root 756 Jul 29 13:03 plesk-rrd-cleaner


rpm -q logrotate
logrotate-3.18.0-12.el9.x86_64


systemctl status logrotate.timer
○ logrotate.timer - Daily rotation of log files
Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; disabled; preset: enabled)
Active: inactive (dead)
Trigger: n/a
Triggers: ● logrotate.service
Docs: man:logrotate(8)
man:logrotate.conf(5)


systemctl cat logrotate.timer
# /usr/lib/systemd/system/logrotate.timer
[Unit]
Description=Daily rotation of log files
Documentation=man:logrotate(8) man:logrotate.conf(5)

[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target


systemctl cat logrotate.service
# /usr/lib/systemd/system/logrotate.service
[Unit]
Description=Rotate log files
Documentation=man:logrotate(8) man:logrotate.conf(5)
RequiresMountsFor=/var/log
ConditionACPower=true

[Service]
Type=oneshot
ExecStart=/usr/sbin/logrotate /etc/logrotate.conf

# performance options
Nice=19
IOSchedulingClass=best-effort
IOSchedulingPriority=7

# hardening options
# details: systemd.exec
# no ProtectHome for userdir logs
# no PrivateNetwork for mail deliviery
# no NoNewPrivileges for third party rotate scripts
# no RestrictSUIDSGID for creating setgid directories
LockPersonality=true
MemoryDenyWriteExecute=true
PrivateDevices=true
PrivateTmp=true
ProtectClock=true
ProtectControlGroups=true
ProtectHostname=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectSystem=full
RestrictNamespaces=true
RestrictRealtime=true

# /usr/lib/systemd/system/logrotate.service.d/plesk-httpdmng.conf
[Service]
# Allow normal operation of httpdmng in postrotate of /etc/logrotate.d/mod_security and /etc/logrotate.d/httpd
ReadWritePaths=/usr/local/psa/var /etc/sw/
 
Back
Top