What is an "error" in your data?
The “error” graph graphs the “errors” attribute from cn=snmp,cn=monitor. I don’t know what conditions actually increment that value.
So does anybody have more details on the errors attribute under cn=snmp,cn=monitor? Should I increase the log level to see what the errors are? If so, can you tell me how?
On Dec 24, 2017, at 10:46 AM, Sergei Gerasenko gerases@gmail.com wrote:
What is an "error" in your data?
The “error” graph graphs the “errors” attribute from cn=snmp,cn=monitor. I don’t know what conditions actually increment that value.
On 01/03/2018 11:16 AM, Sergei Gerasenko wrote:
So does anybody have more details on the errors attribute under cn=snmp,cn=monitor? Should I increase the log level to see what the errors are? If so, can you tell me how?
Any time an error occurs on a search or write operation this counter is incremented. Look in the DS access logs for anything that is not "err=0" to see what the exact errors are. I suggest running logconv.pl to make this easier:
# logconv.pl -e /var/log/dirsrv/slapd-YOUR_INSTANCE/access*
On Dec 24, 2017, at 10:46 AM, Sergei Gerasenko <gerases@gmail.com mailto:gerases@gmail.com> wrote:
What is an "error" in your data?
The “error” graph graphs the “errors” attribute from cn=snmp,cn=monitor. I don’t know what conditions actually increment that value.
Ok, thank you. I think the exact description of that counter is (from 389-ds-base-1.3.5.10/ldap/servers/snmp/redhat-directory.mib):
dsErrors OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of operations that could not be serviced due to errors other than security errors, and referrals. A partially serviced operation will not be counted as an error. The errors include NameErrors, UpdateErrors, Attribute errors and ServiceErrors." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Sections 12.4, 12.5, 12.8 & 12.9. and, RFC1777 Section 4." ::= {dsOpsEntry 20}
Didn’t know about logconv.pl. Nice tip. Running it with -ej produced:
----- Errors -----
err=0 9560 Successful Operations err=14 330 SASL Bind in Progress err=32 161 No Such Object
----- Recommendations -----
1. You have unindexed components, this can be caused from a search on an unindexed attribute, or your returned results exceeded the allidsthreshold. Unindexed components are not recommended. To refuse unindexed searches, switch 'nsslapd-require-index' to 'on' under your database entry (e.g. cn=UserRoot,cn=ldbm database,cn=plugins,cn=config).
2. You have a significant difference between binds and unbinds. You may want to investigate this difference.
For #1, can I identify the unindexed attributes and create the indeces? For #2, does it mean that some binds hang around without being closed? What’s the best way to investigate #2 further?
Thanks, Mark.
Any time an error occurs on a search or write operation this counter is incremented. Look in the DS access logs for anything that is not "err=0" to see what the exact errors are. I suggest running logconv.pl to make this easier:
# logconv.pl -e /var/log/dirsrv/slapd-YOUR_INSTANCE/access*
For #1, I see the -u option, which does give me the name of the unindexed entries. So, I think I can figure this one out from here.
On Jan 3, 2018, at 11:58 AM, Sergei Gerasenko gerases@gmail.com wrote:
Ok, thank you. I think the exact description of that counter is (from 389-ds-base-1.3.5.10/ldap/servers/snmp/redhat-directory.mib):
dsErrors OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of operations that could not be serviced due to errors other than security errors, and referrals. A partially serviced operation will not be counted as an error. The errors include NameErrors, UpdateErrors, Attribute errors and ServiceErrors." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Sections 12.4, 12.5, 12.8 & 12.9. and, RFC1777 Section 4." ::= {dsOpsEntry 20}Didn’t know about logconv.pl. Nice tip. Running it with -ej produced:
----- Errors -----
err=0 9560 Successful Operations err=14 330 SASL Bind in Progress err=32 161 No Such Object
----- Recommendations -----
You have unindexed components, this can be caused from a search on an unindexed attribute, or your returned results exceeded the allidsthreshold. Unindexed components are not recommended. To refuse unindexed searches, switch 'nsslapd-require-index' to 'on' under your database entry (e.g. cn=UserRoot,cn=ldbm database,cn=plugins,cn=config).
You have a significant difference between binds and unbinds. You may want to investigate this difference.
For #1, can I identify the unindexed attributes and create the indeces? For #2, does it mean that some binds hang around without being closed? What’s the best way to investigate #2 further?
Thanks, Mark.
Any time an error occurs on a search or write operation this counter is incremented. Look in the DS access logs for anything that is not "err=0" to see what the exact errors are. I suggest running logconv.pl to make this easier:
# logconv.pl -e /var/log/dirsrv/slapd-YOUR_INSTANCE/access*
On 01/03/2018 01:03 PM, Sergei Gerasenko wrote:
For #1, I see the *-u* option, which does give me the name of the unindexed entries. So, I think I can figure this one out from here.
On Jan 3, 2018, at 11:58 AM, Sergei Gerasenko <gerases@gmail.com mailto:gerases@gmail.com> wrote:
Ok, thank you. I think the exact description of that counter is (from 389-ds-base-1.3.5.10/ldap/servers/snmp/redhat-directory.mib):
dsErrors OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of operations that could not be serviced due to errors other than security errors, and referrals. A partially serviced operation will not be counted as an error. The errors include NameErrors, UpdateErrors, Attribute errors and ServiceErrors." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Sections 12.4, 12.5, 12.8 & 12.9. and, RFC1777 Section 4." ::= {dsOpsEntry 20}
Didn’t know about logconv.pl. Nice tip. Running it with -ej produced:
----- Errors -----
err=0 9560 Successful Operations err=14 330 SASL Bind in Progress err=32 161 No Such Object
----- Recommendations -----
1. You have unindexed components, this can be caused from a search on an unindexed attribute, or your returned results exceeded the allidsthreshold. Unindexed components are not recommended. To refuse unindexed searches, switch 'nsslapd-require-index' to 'on' under your database entry (e.g. cn=UserRoot,cn=ldbm database,cn=plugins,cn=config).
2. You have a significant difference between binds and unbinds. You may want to investigate this difference.
To be honest these "recommendations" aren't very accurate. If you look at the unindexed searches reported by logconv.pl you should only be concerned about ones that have an etime greater than zero. Some "unindexed searches" are not bad, only the ones with high etimes.
For #1, can I identify the unindexed attributes and create the indeces? For #2, does it mean that some binds hang around without being closed? What’s the best way to investigate #2 further?
Thanks, Mark.
Any time an error occurs on a search or write operation this counter is incremented. Look in the DS access logs for anything that is not "err=0" to see what the exact errors are. I suggest running logconv.pl to make this easier:
# logconv.pl -e /var/log/dirsrv/slapd-YOUR_INSTANCE/access*
Digging deeper into the access log, I see that certain operations return with non-zero error codes. The most prolific are 14 and 32. These are LDAP_SASL_BIND_IN_PROGRESS and LDAP_NO_SUCH_OBJECT respectively. So *maybe* the SNMP counter is incremented on those error codes. I’m currently looking at the source code trying to confirm that. I couldn’t find the definitions of those codes in the 389-ds-base source base. I found them here (of all places): https://docs.oracle.com/cd/E19957-01/817-6707/resultcodes.html#wp30446 https://docs.oracle.com/cd/E19957-01/817-6707/resultcodes.html#wp30446 I know it’s a totally different code base, but it appears to share some standards with the 389-ds implementation.
On Jan 3, 2018, at 10:16 AM, Sergei Gerasenko gerases@gmail.com wrote:
So does anybody have more details on the errors attribute under cn=snmp,cn=monitor? Should I increase the log level to see what the errors are? If so, can you tell me how?
On Dec 24, 2017, at 10:46 AM, Sergei Gerasenko <gerases@gmail.com mailto:gerases@gmail.com> wrote:
What is an "error" in your data?
The “error” graph graphs the “errors” attribute from cn=snmp,cn=monitor. I don’t know what conditions actually increment that value.
On 01/03/2018 12:37 PM, Sergei Gerasenko wrote:
Digging deeper into the access log, I see that certain operations return with non-zero error codes. The most prolific are 14 and 32. These are LDAP_SASL_BIND_IN_PROGRESS and LDAP_NO_SUCH_OBJECT respectively. So *maybe* the SNMP counter is incremented on those error codes. I’m currently looking at the source code trying to confirm that.
It's in ldap/servers/slapd/result.c:367
if (err != LDAP_SUCCESS) { /* count the error for snmp */ /* first check for security errors */ if (err == LDAP_INVALID_CREDENTIALS || err == LDAP_INAPPROPRIATE_AUTH || err == LDAP_AUTH_METHOD_NOT_SUPPORTED || err == LDAP_STRONG_AUTH_NOT_SUPPORTED || err == LDAP_STRONG_AUTH_REQUIRED || err == LDAP_CONFIDENTIALITY_REQUIRED || err == LDAP_INSUFFICIENT_ACCESS || err == LDAP_AUTH_UNKNOWN) { slapi_counter_increment(g_get_global_snmp_vars()->ops_tbl.dsSecurityErrors); } else if (err != LDAP_REFERRAL && err != LDAP_OPT_REFERRALS && err != LDAP_PARTIAL_RESULTS) { /*madman man spec says not to count as normal errors --security errors --referrals -- partially seviced operations will not be conted as an error */ slapi_counter_increment(g_get_global_snmp_vars()->ops_tbl.dsErrors); } }
And yes err=32 is no such object (common error code especially if you are using the 389-console), and err=14 is normal during GSSAPI binds.
Regards, Mark
I couldn’t find the definitions of those codes in the 389-ds-base source base. I found them here (of all places): https://docs.oracle.com/cd/E19957-01/817-6707/resultcodes.html#wp30446%C2%A0... know it’s a totally different code base, but it appears to share some standards with the 389-ds implementation.
On Jan 3, 2018, at 10:16 AM, Sergei Gerasenko <gerases@gmail.com mailto:gerases@gmail.com> wrote:
So does anybody have more details on the errors attribute under cn=snmp,cn=monitor? Should I increase the log level to see what the errors are? If so, can you tell me how?
On Dec 24, 2017, at 10:46 AM, Sergei Gerasenko <gerases@gmail.com mailto:gerases@gmail.com> wrote:
What is an "error" in your data?
The “error” graph graphs the “errors” attribute from cn=snmp,cn=monitor. I don’t know what conditions actually increment that value.
Cool, you saved me a lot of time. Quick question: where are all these constants (LDAP_SUCCESS, etc) defined?
On Jan 3, 2018, at 12:11 PM, Mark Reynolds mreynolds@redhat.com wrote:
On 01/03/2018 12:37 PM, Sergei Gerasenko wrote:
Digging deeper into the access log, I see that certain operations return with non-zero error codes. The most prolific are 14 and 32. These are LDAP_SASL_BIND_IN_PROGRESS and LDAP_NO_SUCH_OBJECT respectively. So *maybe* the SNMP counter is incremented on those error codes. I’m currently looking at the source code trying to confirm that.
It's in ldap/servers/slapd/result.c:367
if (err != LDAP_SUCCESS) { /* count the error for snmp */ /* first check for security errors */ if (err == LDAP_INVALID_CREDENTIALS || err == LDAP_INAPPROPRIATE_AUTH || err == LDAP_AUTH_METHOD_NOT_SUPPORTED || err == LDAP_STRONG_AUTH_NOT_SUPPORTED || err == LDAP_STRONG_AUTH_REQUIRED || err == LDAP_CONFIDENTIALITY_REQUIRED || err == LDAP_INSUFFICIENT_ACCESS || err == LDAP_AUTH_UNKNOWN) { slapi_counter_increment(g_get_global_snmp_vars()->ops_tbl.dsSecurityErrors); } else if (err != LDAP_REFERRAL && err != LDAP_OPT_REFERRALS && err != LDAP_PARTIAL_RESULTS) { /*madman man spec says not to count as normal errors --security errors --referrals -- partially seviced operations will not be conted as an error */ slapi_counter_increment(g_get_global_snmp_vars()->ops_tbl.dsErrors); } }And yes err=32 is no such object (common error code especially if you are using the 389-console), and err=14 is normal during GSSAPI binds.
On 01/03/2018 01:18 PM, Sergei Gerasenko wrote:
Cool, you saved me a lot of time. Quick question: where are all these constants (LDAP_SUCCESS, etc) defined?
Checkout /usr/include/ldap.h
On Jan 3, 2018, at 12:11 PM, Mark Reynolds <mreynolds@redhat.com mailto:mreynolds@redhat.com> wrote:
On 01/03/2018 12:37 PM, Sergei Gerasenko wrote:
Digging deeper into the access log, I see that certain operations return with non-zero error codes. The most prolific are 14 and 32. These are LDAP_SASL_BIND_IN_PROGRESS and LDAP_NO_SUCH_OBJECT respectively. So *maybe* the SNMP counter is incremented on those error codes. I’m currently looking at the source code trying to confirm that.
It's in ldap/servers/slapd/result.c:367
if (err != LDAP_SUCCESS) { /* count the error for snmp */ /* first check for security errors */ if (err == LDAP_INVALID_CREDENTIALS || err == LDAP_INAPPROPRIATE_AUTH || err == LDAP_AUTH_METHOD_NOT_SUPPORTED || err == LDAP_STRONG_AUTH_NOT_SUPPORTED || err == LDAP_STRONG_AUTH_REQUIRED || err == LDAP_CONFIDENTIALITY_REQUIRED || err == LDAP_INSUFFICIENT_ACCESS || err == LDAP_AUTH_UNKNOWN) { slapi_counter_increment(g_get_global_snmp_vars()->ops_tbl.dsSecurityErrors); } else if (err != LDAP_REFERRAL && err != LDAP_OPT_REFERRALS && err != LDAP_PARTIAL_RESULTS) { /*madman man spec says not to count as normal errors --security errors --referrals -- partially seviced operations will not be conted as an error */ slapi_counter_increment(g_get_global_snmp_vars()->ops_tbl.dsErrors); } }
And yes err=32 is no such object (common error code especially if you are using the 389-console), and err=14 is normal during GSSAPI binds.
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Aha, I should have thought of that. Thanks
On Jan 3, 2018, at 12:51 PM, Mark Reynolds mreynolds@redhat.com wrote:
Checkout /usr/include/ldap.h
389-users@lists.fedoraproject.org
-
Mark Reynolds -
Sergei Gerasenko