[389-users] Re: Monitoring 389ds with telegraf

> On 19 Sep 2019, at 22:43, Olivier JUDITH wrote: > > Hi , > > Thank for your support > Is it possible to have a version of your container from Dockerhub > (firstyear/389ds) with availability to set Directory Manager default password > ? > I need this for CircleCi testing phases after a

[389-users] Re: Monitoring 389ds with telegraf

Hi , Thank for your support Is it possible to have a version of your container from Dockerhub (firstyear/389ds) with availability to set Directory Manager default password ? I need this for CircleCi testing phases after a push on Github. Regards Le ven. 6 sept. 2019 à 01:59, William Brown a

[389-users] Re: Monitoring 389ds with telegraf

> On 6 Sep 2019, at 05:28, Olivier JUDITH wrote: > > Hi all , > > For all those who are interested , i started to develop with the help of > Marco Favero a monitoring solution based on telegraf to gather > metrics from my 389 instances . > All metrics are stored in influxdb ( timeseries

[389-users] Re: monitoring

Aha, I should have thought of that. Thanks > On Jan 3, 2018, at 12:51 PM, Mark Reynolds wrote: > > Checkout /usr/include/ldap.h ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to

[389-users] Re: monitoring

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 > >

[389-users] Re: monitoring

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 wrote: > > > > On 01/03/2018 12:37 PM, Sergei Gerasenko wrote: >> Digging deeper into the access log, I see that

[389-users] Re: monitoring

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 > > wrote: >>

[389-users] Re: monitoring

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

[389-users] Re: monitoring

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 wrote: > > Ok, thank you. I think the exact description of that counter is (from >

[389-users] Re: monitoring

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

[389-users] Re: monitoring

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

[389-users] Re: monitoring

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

[389-users] Re: monitoring

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 wrote: > >> What is an "error" in your data? > > The

[389-users] Re: monitoring

dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify add: aci aci: (target ="ldap:///cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config")(targetattr != "aci || connection")(version 3.0; acl "monitor3"; allow( read, search, compare ) userdn =

[389-users] Re: monitoring

> 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.___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send

[389-users] Re: monitoring

Cool. Another question: just going off the snmp,monitor path, I’m graphing searchops and errors. Here’s what that looks like: As you can see, the search ops correspond exactly to the error peaks. The error logs are empty though. Is this correlation of any concern? How can I get more detail

[389-users] Re: monitoring

That should work. Thanks, M. On Thu, Dec 21, 2017 at 1:49 PM, Sergei Gerasenko wrote: > Excellent info, Mark. Thank you. I’m using collectd for graphing the > results and since the backend trees are not readable by everyone, I’m > thinking of granting read access to the

[389-users] Re: monitoring

Excellent info, Mark. Thank you. I’m using collectd for graphing the results and since the backend trees are not readable by everyone, I’m thinking of granting read access to the collectd account. Is an ldif like the one below the right way to do it: dn: cn=monitor,cn=ldbm

[389-users] Re: monitoring

The SNMP counters are not always interesting, but they can provide the system memory use and some LDAP BIND info. Under cn=monitor , the most important are: the difference between opsinitiated and opscompleted and also threads currentconnections and backendmonitordn so under

[389-users] Re: monitoring

I’ve implemented the solution described in the thread. My question now is: what should I really monitor? There are so many metrics to consider. The thread talks about cn=snmp,cn=monitor. But there are also cn=monitor suffixes under each backend for example. Is there a recommended mininum set

[389-users] Re: monitoring

Thank you for the ref to the post. In absense of anything else, I might go with the python solution. If there’s an easier way though, I’m also interested. > On Dec 14, 2017, at 6:23 PM, Marc Sauton wrote: > > There is no collectd 389-ds plug-in, but there was a post with

[389-users] Re: monitoring

There is no collectd 389-ds plug-in, but there was a post with an example: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/thread/TTKWB7WA4NEHYM5GDPLDJVIMR34DKNT2/ May be other users already run some similar plug-in? Should we have such plug-in? Thanks, M. On Thu,