Hello,
I wonder, if there is more interest here for starting a logging and monitoring SIG. It should provide (as the name says) for logging and monitoring. With people running huge installations, it makes sense to have more centralized logging, but there's currently not that much in CentOS repositories.
I could imagine to have both tools and also installation and configuration bits and pieces to be maintained by the SIG.
Before I'd be putting out more details, about what I could imagine or what I would like to see, I would like to see some more interested folks raising their hands.
Best, Matthias
Hi Matthias, Please count me in. I am also interested in this SIG.
Regards,
Alex Meng mengxiandong@gmail.com mengxiandong@gmail.com
On Thu, Apr 28, 2016 at 5:28 PM, Matthias Runge mrunge@matthias-runge.de wrote:
Hello,
I wonder, if there is more interest here for starting a logging and monitoring SIG. It should provide (as the name says) for logging and monitoring. With people running huge installations, it makes sense to have more centralized logging, but there's currently not that much in CentOS repositories.
I could imagine to have both tools and also installation and configuration bits and pieces to be maintained by the SIG.
Before I'd be putting out more details, about what I could imagine or what I would like to see, I would like to see some more interested folks raising their hands.
Best, Matthias _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 29/04/16 00:28, Matthias Runge wrote:
Hello,
I wonder, if there is more interest here for starting a logging and monitoring SIG. It should provide (as the name says) for logging and monitoring. With people running huge installations, it makes sense to have more centralized logging, but there's currently not that much in CentOS repositories.
I could imagine to have both tools and also installation and configuration bits and pieces to be maintained by the SIG.
Before I'd be putting out more details, about what I could imagine or what I would like to see, I would like to see some more interested folks raising their hands.
Best, Matthias
Seems interesting ! Wondering if you're already targeting some known solutions for the logging part at least. For example the ELK stack is pretty known and (ab)used those days, but proper packaging in .rpm format is still missing (and nothing even at the Fedora level) so is that something you had in mind ?
On Fri, Apr 29, 2016 at 01:00:07PM +0200, Fabian Arrotin wrote:
Seems interesting ! Wondering if you're already targeting some known solutions for the logging part at least. For example the ELK stack is pretty known and (ab)used those days, but proper packaging in .rpm format is still missing (and nothing even at the Fedora level) so is that something you had in mind ?
We're using elasticsearch and logstash packages that are provided by packages.elastic.co, which work... but I'd love to see a more orchastrated build environment. Our Kibana interface is currently a source build (I believe... I didn't build it) but I've been planning on replacing it with the docker build anyway.
On 04/29/2016 07:03 AM, Jonathan Billings wrote:
On Fri, Apr 29, 2016 at 01:00:07PM +0200, Fabian Arrotin wrote:
Seems interesting ! Wondering if you're already targeting some known solutions for the logging part at least. For example the ELK stack is pretty known and (ab)used those days, but proper packaging in .rpm format is still missing (and nothing even at the Fedora level) so is that something you had in mind ?
We're using elasticsearch and logstash packages that are provided by packages.elastic.co, which work... but I'd love to see a more orchastrated build environment.
Can you explain what you mean by "orchastrated build environment"?
Our Kibana interface is currently a source build (I believe... I didn't build it) but I've been planning on replacing it with the docker build anyway.
A docker image still needs to get the bits from somewhere, preferably an rpm.
On Fri, Apr 29, 2016 at 07:40:51AM -0600, Rich Megginson wrote:
On 04/29/2016 07:03 AM, Jonathan Billings wrote:
We're using elasticsearch and logstash packages that are provided by packages.elastic.co, which work... but I'd love to see a more orchastrated build environment.
Can you explain what you mean by "orchastrated build environment"?
I meant someone keeping track of dependencies between versions and making sure you don't bump your elasticsearch RPMs and break your logstash input because of API changes, and vice-versa.
On Fri, Apr 29, 2016 at 11:32:17AM -0400, Jonathan Billings wrote:
I meant someone keeping track of dependencies between versions and making sure you don't bump your elasticsearch RPMs and break your logstash input because of API changes, and vice-versa.
Oh, and making sure that the package update process doesn't break existing services and provide an easier upgrade route.
On 04/29/2016 09:32 AM, Jonathan Billings wrote:
On Fri, Apr 29, 2016 at 07:40:51AM -0600, Rich Megginson wrote:
On 04/29/2016 07:03 AM, Jonathan Billings wrote:
We're using elasticsearch and logstash packages that are provided by packages.elastic.co, which work... but I'd love to see a more orchastrated build environment.
Can you explain what you mean by "orchastrated build environment"?
I meant someone keeping track of dependencies between versions and making sure you don't bump your elasticsearch RPMs and break your logstash input because of API changes, and vice-versa.
That should be one of the goals of the SIG. To that end, we will need to create targeted CI upgrade tests, among other tests.
On 04/29/2016 05:00 AM, Fabian Arrotin wrote:
On 29/04/16 00:28, Matthias Runge wrote:
Hello,
I wonder, if there is more interest here for starting a logging and monitoring SIG. It should provide (as the name says) for logging and monitoring. With people running huge installations, it makes sense to have more centralized logging, but there's currently not that much in CentOS repositories.
I could imagine to have both tools and also installation and configuration bits and pieces to be maintained by the SIG.
Before I'd be putting out more details, about what I could imagine or what I would like to see, I would like to see some more interested folks raising their hands.
Best, Matthias
Seems interesting ! Wondering if you're already targeting some known solutions for the logging part at least. For example the ELK stack is pretty known and (ab)used those days, but proper packaging in .rpm format is still missing (and nothing even at the Fedora level) so is that something you had in mind ?
We are targeting the EFK stack initially - we already have a lot of fluentd users, and most of the rpm packaging work for fluentd and its ruby dependencies has already been done.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Apr 29, 2016 at 01:00:07PM +0200, Fabian Arrotin wrote:
Seems interesting ! Wondering if you're already targeting some known solutions for the logging part at least. For example the ELK stack is pretty known and (ab)used those days, but proper packaging in .rpm format is still missing (and nothing even at the Fedora level) so is that something you had in mind ?
Yes, that was basically, what I had in mind. Instead of logstash, I'd be more looking at fluentd, but would love to ship elasticsearch and kibana built from source.
For performance monitoring I was thinking of using collectd, graphite and graphana. Sensu would be a good option for availability monitoring.
Elasticsearch is currently packaged in fedora, and some other tools are already in place somewhere, but it would be good to collect it all together and to provide a bit more content around them.
Matthias
On 29 Apr 2016 16:38, "Matthias Runge" mrunge@matthias-runge.de wrote:
On Fri, Apr 29, 2016 at 01:00:07PM +0200, Fabian Arrotin wrote:
Seems interesting ! Wondering if you're already targeting some known solutions for the logging part at least. For example the ELK stack is pretty known and (ab)used those days, but proper packaging in .rpm format is still missing (and nothing even at the Fedora level) so is that something you had in mind ?
Yes, that was basically, what I had in mind. Instead of logstash, I'd be more looking at fluentd, but would love to ship elasticsearch and kibana built from source.
For performance monitoring I was thinking of using collectd, graphite and graphana. Sensu would be a good option for availability monitoring.
Elasticsearch is currently packaged in fedora, and some other tools are already in place somewhere, but it would be good to collect it all together and to provide a bit more content around them.
Matthias
-- Matthias Runge mrunge@matthias-runge.de
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Count me in.
On Apr 28, 2016 5:28 PM, "Matthias Runge" mrunge@matthias-runge.de wrote:
Hello,
I wonder, if there is more interest here for starting a logging and monitoring SIG. It should provide (as the name says) for logging and monitoring. With people running huge installations, it makes sense to have more centralized logging, but there's currently not that much in CentOS repositories.
I could imagine to have both tools and also installation and configuration bits and pieces to be maintained by the SIG.
Before I'd be putting out more details, about what I could imagine or what I would like to see, I would like to see some more interested folks raising their hands.
Best, Matthias _______________________________________________
I'm inexperienced in this area, but centralized monitoring and logging are on my list. collectd seems particularly intriguing; I like how you can plug in listen and forward capability and get a relay host in individual environments, as well as a centralized aggregator for all of an org's environments.
Count me interested, at least enough to follow along.
--Pete
On 29/04/16 10:58, Pete Travis wrote:
I'm inexperienced in this area, but centralized monitoring and logging are on my list. collectd seems particularly intriguing; I like how you can plug in listen and forward capability and get a relay host in individual environments, as well as a centralized aggregator for all of an org's environments.
Count me interested, at least enough to follow along.
--Pete
Great to hear!
Matthias
-
Anton Sherkhonov -
Earl A Ramirez -
Fabian Arrotin -
Jonathan Billings -
Matthias Runge -
Pete Travis -
Rich Megginson -
Xiandong Meng