Closed mklauber closed 11 years ago
Currently you can have different logs monitored passing an array to monitor_path, but a solution based on defines definitively would allow much better control on how and what to manage. So for me is OK, go on with that, I'll merge any improvement to the module.
Cool. I'll try and work up a complete solution for this over the next week or so.
Great... if possible preserve the current $monitor_path params and leave it as an alternative (backwards compatible) option to your own one based on defines.
Sorry, this PR got out of my radar... I see the Travis error can you verify it?
Had to fix some things (did you check splunk::info::monitor??) and move the concat stuff into the inpit defines.
Sorry, actually got pulled into fixing something things in Puppet mainline, so this got off my radar. I'll keep plugging away at it, let you know when I get everything setup. I may only get the client configured to use this initially.
To whom it may concern, I wanted to bring up a suggestion of how to manage inputs and outputs better. Within our company we want to monitor multiple applications, and have created classes for each application. As part of these classes we wanted to specify which log files splunk should watch. The issue I ran into is that you can only specify "monitor_path" in one place.
So my suggestion is to turn monitors and the various inputs into defined resources, and then let people define "splunk::monitor" with the class that includes the application. I've proof of concept'd a resource for "monitor" below, which you can declare in multiple locations and is concatenated into inputs.conf. Is this something you would like moving forward in or should I fork and publish my own module with this concept?
(Note: I'm not looking to merge at this time, it was just the simplest way to show the code comparison.)