[Feature] storage: add storage-loki-plugin support loki+ SkyWalking #9836
Replies: 2 comments 6 replies
-
|
Move this to idea discussion. As this new proposal is never discussed and accepted. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I'm so sorry, I posted in the wrong place and don't have much experience with how to participate in sky walking discussions. From my experience, loki 2.6 is relatively mature, and there are not too many deadlocks or low-level errors such as program unusable memory overflow, and loki is already in a production-ready log system. And there are huge advantages in cost. wait more eyes. |
Beta Was this translation helpful? Give feedback.
-
|
A new storage option is a very heavy proposal, and we need you to answer several key questions.
About the cost your mentioned, true, ES costs a lot, this is not news. This argument exists as always with ElasticSearch project. This is why we are building the APM native database, https://github.com/apache/skywalking-banyandb. We are open to more options, but the above concerns should be addressed. Also, if you are willing to build a new project, to re-distribute SkyWalking with your new option, and to see whether users are going to choose it, we are happy to help you marketing it in our community. A similar thing was asked about is using ClickHouse to process metrics part, you can see these both are hard of the complete solution, we can't accept them as official unless we are confident people are really to use this way, and believe the complexity of deployment and operation is still acceptable. You should know that APM is a third-level system after your business system and analysis/BI system. So, the operation team usually doesn't want to cost too much to maintain a complex deployment as more components are involved, easier if one of them crashed somehow. If you feel ElasticSearch is not easy, it would be definitely harder to use ElasticSearch + Loki/Clickhouse. |
Beta Was this translation helpful? Give feedback.
-
|
And importantly, this is not my feeling or preference, this is a lesson we learnt from the project history. Check this, #9059 We accepted InfluxDB(v1) and IoTDB as storage options in past years, both of them were not used in the product, and finally voted to be removed. Because they are half of the complete solution. They are only suitable for some metrics cases. But SkyWalking requires more than that. |
Beta Was this translation helpful? Give feedback.
-
|
If you have a complete proposal and a PoC to verify, we could go on for further discussions. |
Beta Was this translation helpful? Give feedback.
-
|
@wu-sheng oh，hi, Thanks for such a detailed description!
This is really a pity.
This is a big challenge. I know that metrics, logs, and trace data have different challenges. When the 3 challenges merge into one, I believe it makes the problem more difficult to solve. IMO grafana's loki tempo mimir These 3 projects solve the problem of these three types of data separately, which is a simpler solution.
I'd love to maintain this plugin, I'm also maintaining loki, I'm sure I can do the job well, but it may take me a long time. open source in my off-duty time. and At present I am not familiar with the code of sky walking, I mainly hope that loki can be used in more projects |
Beta Was this translation helpful? Give feedback.
-
|
I think using loki is totally acceptable. You could build a open source project using hybrid storage option. SkyWalking is built powered by the modularization kernel. So you could simplely write the storage plugin with other existing storage options together, and release as a 3rd party extension. https://skywalking.apache.org/docs/#SourceMarker Your storage offer could be loki+ElasticSearch redistribution. But just notice, we can't use skywalking as project name, you need a new one for that. We could link your project like we did for SourceMarker and accept your blogs about your new projects. Anyway, we are welcome to new extensions, and we don't have to agree at this point for more details. We could collaborate with a kind of dependencies. |
Beta Was this translation helpful? Give feedback.
-
Many things in open source take a long time. BanyanDB took 2 years ib discussion, and began in last year, only after we are certain we need one, and we could build a good native one. So, don't hurry. I recommend to maintain a separate repository, which could ease the time sensitivity. SkyWalking main repo with default storage options release in every 2-3 months. All features have to be well tested, as we have countless users, and they adopt new versions fast, because many new features would be added every time. https://github.com/apache/skywalking/tree/master/docs/en/changes You don't have to follow this when you are running a separate project as an extension. Many people host their extensions in this separate org as a closing place to SkyWalking but out of the Apache Foundation official repositories. It could be more flexible, and free for new projects. When you are ready, this project could be donated into ASF, if one day it is ready. |
Beta Was this translation helpful? Give feedback.
-
Search before asking
Description
The indexing technology of ES will cause the log inflation ratio to be too large, which will eventually cause users to pay a huge bill.
In the field of logs, there is a new non-indexed log system that is developing rapidly. Taking grafana loki as an example, the log inflation ratio is only It is 1/1000 of the original log. This allows users to have a log system at 1/100 to 1/10 of the cost of ES.
Use case
Users don't want to pay an overly expensive logging bill.
We can provide users with a low-cost storage, but will explicitly tell users that the query performance is lower than ES.
Related issues
none
Are you willing to submit a PR?
Code of Conduct
Beta Was this translation helpful? Give feedback.
All reactions