Any chance of being able to use multiple index types based on different types of log data? Then setting different retention policies on the types?
I ask as we're looking at different business requirements for say, network vs application logs.
Are these abilities that might be covered in more current versions of logstash/elasticsearch? v2.x is well underway for both and we're still in v1.5.1/1.6, respectively.
-AJ
Multiple retention policies?
Multiple retention policies?
Andrew J. - Do you even grok?
Re: Multiple retention policies?
Unfortunately, it's not something that is built into NLS, and probably won't be implemented in the future.
It is possible to do this with the ELK stack, but for NLS, it would require a rewrite of the way the entire product works. NLS is made to be an easy solution, and adding multiple databases would make it a much more complicated setup. I would love to see this implemented, but from a usability standpoint, I understand why we do it the way we do.
With that out of the way, you do have a couple options:
You can delete all data of a certain type by using a query, and run that query on a cron job.
You could spin up a separate instance of NLS, it may not be ideal, but it could work.
It is possible to do this with the ELK stack, but for NLS, it would require a rewrite of the way the entire product works. NLS is made to be an easy solution, and adding multiple databases would make it a much more complicated setup. I would love to see this implemented, but from a usability standpoint, I understand why we do it the way we do.
With that out of the way, you do have a couple options:
You can delete all data of a certain type by using a query, and run that query on a cron job.
You could spin up a separate instance of NLS, it may not be ideal, but it could work.
Former Nagios Employee.
me.
me.
Re: Multiple retention policies?
I'll have to investigate the cron job. As my org grows its use of ELK with NLS, I can see us needing more flexibility and possibly moving to Elastic's setup.
They just announced Elastic Stack yesterday as they see that cohesive packages are gaining interest.
They just announced Elastic Stack yesterday as they see that cohesive packages are gaining interest.
Andrew J. - Do you even grok?
Re: Multiple retention policies?
I understand the desire for the additional features that the latest versions of the ELK stack provide, but we try to stay on the side of stability over new features. NLS is still one of our newer products, and as such it will grow over time. We're always happy to take feature requests, and no customer feedback goes ignored. I think one thing to keep in mind is our target audience. The ELK stack is a pretty complicated solution, and NLS is one of the first solutions provided to make it a simple setup for almost anyone. We aim for ease of use and stability, and that's not always parallel with bleeding edge solutions.
Former Nagios Employee.
me.
me.
Re: Multiple retention policies?
Fully understand and support.
And yes, as I clarify my wants and needs, I will definitely add to the feature requests. As most of us who are deeply involved in Nagios paid products, we greatly appreciate the feedback loop we have with the product developers. NagiosCon is a big part of that loop... which reminds me I need to work on my abstract!
We can close this thread and I may have more questions later on the details of the scheduled cleanup query.
And yes, as I clarify my wants and needs, I will definitely add to the feature requests. As most of us who are deeply involved in Nagios paid products, we greatly appreciate the feedback loop we have with the product developers. NagiosCon is a big part of that loop... which reminds me I need to work on my abstract!
We can close this thread and I may have more questions later on the details of the scheduled cleanup query.
Andrew J. - Do you even grok?
Re: Multiple retention policies?
Thank you for your understanding. We appreciate the long time support, and I'm already pretty hyped for the conference!
Former Nagios Employee.
me.
me.