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.
Bug 215481 - RFE rhds71 does not have peak connections in its monitoring facility
Summary: RFE rhds71 does not have peak connections in its monitoring facility
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: pre-dev-freeze
: ---
Assignee: Rich Megginson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 389_1.3.0 512820 690319
TreeView+ depends on / blocked
 
Reported: 2006-11-14 10:17 UTC by Issue Tracker
Modified: 2020-09-13 20:02 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-17 17:31:01 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 221 0 None None None 2020-09-13 20:02:04 UTC

Description Issue Tracker 2006-11-14 10:17:14 UTC 
Escalated to Bugzilla from IssueTracker
Comment 6 Rich Megginson 2006-11-14 14:03:55 UTC 
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 7 Xander D Harkness 2006-11-14 14:21:42 UTC 
It is not required to have the Peak connection persist between restarts.
Comment 11 Rich Megginson 2007-06-11 17:01:10 UTC 
(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.
>
Comment 12 Issue Tracker 2007-06-28 08:57:03 UTC 
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
Comment 15 Issue Tracker 2007-06-28 18:07:16 UTC 
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
Comment 16 Rich Megginson 2012-01-09 19:29:15 UTC 
Upstream ticket:
https://fedorahosted.org/389/ticket/221
Comment 18 Noriko Hosoi 2016-03-17 17:31:01 UTC 
Per triage: this symptom is no longer applied to the current version.
Note You need to log in before you can comment on or make changes to this bug.