Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Adding Kevin. This should be an easy feature to get into the product.
One question: Does the customer expect the value of peakConnections to persist
between server restarts?
Comment 7Xander D Harkness
2006-11-14 14:21:42 UTC
It is not required to have the Peak connection persist between restarts.
(In reply to comment #10)
> Just some comments/thoughs:
>
> Peak connection information can be very interesting to get, but most if not all
> the information is currently reported through counters initialized at startup
> (and designed for snmp), like current or total connections, see for example the
> "Operations Table" chapter at
> https://www.redhat.com/docs/manuals/dir-server/ag/7.1/snmp.html#1072684
>
> If you want a peak connection information, don't we have to deal with sample
> interval in the DS, and may be provide other data like current req / sec, peak
> conn / sec ?
No, not if peak connection is just a high water mark.
You can also use logconv.pl to get this information from the access log.
>
> Although this can be very good to have, it is till easier for a monitoring tool
> to read the snmp counters or collect the same counters with a cn=config, and
> detect the low, peak, average of a given monitored counter, periodically.
>
> Like for networking gear, it is usually up to a monitoring tool to keep and
> archive at its own sample rate the snmp counter reads into a rrd file
> (http://oss.oetiker.ch/rrdtool/), and then extract the average and peak values
> when retrieving the information when building a status page and graphs.
>
Internal Status set to 'Resolved'
Status set to: Closed by Client
Resolution set to: 'Closed by Client'
This event sent from IssueTracker by Andreas.Andersson
issue 106099
The rfe in bugzilla is under review, no version defined yet.
re-closing.
Marc.
Internal Status set to 'Resolved'
Status set to: Closed by Tech
Resolution set to: 'Netscape Applications'
This event sent from IssueTracker by msauton
issue 106099