Post and proposal is withdrawn by author

(Rich Koshak) #13

I’m more suggesting looking at the openHAB InfluxDB Persistence add-on as an example which might more closely match what you need to do to do the same or similar with Graphite.

But I will say InfluxDB is very popular around here, I use it myself. It is a Time Series database, uses an MIT license, and it has strong community support and commercial support is available.

I’ve only used it for my home setup but have seen enough books and articles written to know it is a pretty big player in “big data” circles.

(Asvilabs) #14

Post and proposal is withdrawn by author. Author has left the forum.

(Rich Koshak) #15

Yes, you can find their repo here. It is MIT Licensed so should work about the same as Apache License, but it won’t be Apache.

I hate when these companies bury their “community” editions on their website.

They do mention it on pages where they describe their proprietary Cloud and Enterprise options that InfluxDB itself is open source. And it is part of most of the Linux Distro package management systems.

I personally run their Docker image from Docker Hub.

And like I said before, I mainly brought it up as an example to look at, not as an alternative to Graphite, though if you find it worth consideration I’ll consider my comment doubly useful. :smiley:

(Asvilabs) #16

Post and proposal is withdrawn by author. Author has left the forum.

(Asvilabs) #17

Post and proposal is withdrawn by author. Author has left the forum.

( ) #18

Hello @ganesh.ingle,

may I ask which use cases you are trying to solve? You’ve suggested a whole stack of applications (which I’m all aware of and most I’ve used at some point) but what is the goal of your endeavors?

Your ideas seem to somehow mix data persistence and logging. These are totally different topics.

An openHAB InfluxDB persistence add-on exists and it is popular and working quite well, especially in combination with Grafana. See: InfluxDB+Grafana persistence and graphing
That said, the add-on could be improved in some areas, so maybe you are intrigued to do some work there?
You are suggesting to develop a Graphite add-on. Why? If any I’d see Prometheus as the most interesting solution on the market (besides InfluxDB).

As for logging: This is a more complicated issue and the “improvement” depends on your use case! What is it you are looking to solve by managing log data in ELK? As @rlkoshak mentioned I had openHAB connected to ELK once and didn’t find any use for it in the end…

Interested in your answers. Best Thomas

(Asvilabs) #19

Post is withdrawn by author.

(Asvilabs) #20

Post is withdrawn by author.

(Asvilabs) #21

Post is withdrawn by author.

(Asvilabs) #22

Post is withdrawn by author.

(Asvilabs) #23

Post is withdrawn by author.

(Rich Koshak) #24

There are features inside Eclipse Smarthome for developing and deploying crosscutting concerns like this. I’m not sure the addition of a new API that other bindings have to call is an appropriate use case for a Binding.

How constrained are these log formats? Is it possible to use a log4j appender to put them into the right format? That is a far better approach than requiring all the 200+ bindings to support a second logging API that may or may not be there all the time.

I think the main point that Thom and I are trying to make is that no, it isn’t a subset of this system. It is a separate system. They two involve different parts of the system and serve two very different purposes.

(Asvilabs) #25

Post is withdrawn by author.

(Rich Koshak) #26

Good luck, as said in the other thread, you are not interested in working with the oh community in any way so I will no longer contribute to these conversations. I suggest the rest of the community so the same.

I recommend that you drop OH, use Eclipse SmartHome (the whole reason ESH was split off was to allow companies to build their solution off of it) and stop waisting the OH community’s time.

(Asvilabs) #27

I think your reference point is OH and its baseline. Mine is my users. Thanks for your technical inputs anyway, those are valuable.

(Rich Koshak) #28

I provided them with the understanding that they were going to be used to improve OH.

(Asvilabs) #29

Post is withdrawn by author.

(Asvilabs) #30

Post is withdrawn by author.

( ) #31

@ganesh.ingle it’s a shame you didn’t give informative answers to my previous message. If you still want to have a constructive conversation I suggest you do.

Your main focus seems to lie on logging. You are suggesting drastic changes but did you actually check the existing infrastructure? The latest builds of openHAB use log4j2, a powerful logging component which (and this is something you seem to miss) can pipe it’s messages to wherever you want. @rlkoshak linked a thread by me right in the beginning, describing how to link log4j1 to ELK. With log4j2 there are now even more options and one I missed back then was the ability to send logging from openHAB to logstash in an annotated json format. If you were to exploit that option, you might find yourself with what you are asking for. A fine-tuned solution for openHAB-to-ELK would be very interesting for many!!

It seems like you are eager to help improve openHAB but you are skipping the opportunity to get to know ESH/OH and discuss your ideas with the community. I believe that is the source of @rlkoshak 's last message.

(Asvilabs) #32

Post is withdrawn by author.