Skip to main content

    Filter by idea status

    Filter by product

    629 Ideas

    FredericGerard
    FredericGerardSteward **

    Plugin for Splunk : return value of spl requestReleased

    Hi    Persona: operators and adminsProblem to solve: The Monitoring Connector Splunk brings a host template App-Monitoring-Splunk-Api-custom which allows to configure search request using Query-Matches-Number template. This service returns the number of response to the request. But there's no way, with this plugin, to get a value calculated by Splunk.For instance : it'd be useful to monitor ratio of splunk scheduled requests skipped by the scheduler. Proper SPL request exists and return a percentage(index=x blablabla | table skippedRatio). Since the service template counts the number of response, the best one can do is to add condition to the SPL request (index=x blablabla | table skippedRatio | where skippedRatio > y) so that it would generate a response only in case of threshold crossing. It's a shame because threshold is coded in the request, return value can not be historised.Expected outcome: a Query-Number-Value service template.Potential solutions: Enrich plugin to get back a pair {fieldName, fieldValue} as long output, and the value as short one. The fieldValue has to be a decimal number to be compared to threshold. The essentials is likely already coded in the plugin, since it's ending each request sent with a "|stats count".It could also be probably achieved using HTTP collection plugin, but enriching Splunk plugin would probably be welcomed by the Centreon-Splunk community 🙂.Thanks !

    Horst KitschSteward **

    check period and notification period are dealing with time periods, but recurring downtime does notNeeds Votes

    We are facing the following situation:Our company has hundreds of retail sites around the world. We’re doing network monitoring for those sites. Many of these sites do NOT have power during the night and therefor they are not reachable.Of course, we don’t want to have notifications during that period or tickets for a known recurring situation!We started with notification period settings to send notifications only during the time, when the retail stores should be open. That works fine, BUT during downtime, they still appear as critical and/or unknown in the resource monitor. This makes the resource monitor less useful for other services we should care about.Using check period instead would keep the resource monitor ‘clean’ and prevent from unnecessary notifications, but we’re ‘blind’ during night time. Reporting might be difficult (not completely thought about) and we like to have as much insight as possible, but check period will stop polling.Now we came to recurring downtimes! I think, this would exactly do, what we expect - continue polling and visibility of the status 24x7, but treating occuring events as ‘handled’. No notification, no ticket and a clean resource monitor.All good so far, but the recurring downtime is terrible to configure, if you need a downtime every night with different start- and endtimes, you need a weelky ‘plan’ with 14 periods - i.e. Monday, midnight until 10 AM and 8 PM until midnight and this for every day of the week.Wouldn’t it be good to use the time-periods also for the recurring downtimes as already for check and notification period available?A long explanation for a simple topic.