Replies: 1 comment
-
|
@mr-karan , thank you for creating a this discussion! Could you update the query name used in VictoriaLogs? It is LogsQL, not LogQL (this is completely different query language from Grafana Loki). See this comment, which compares LogsQL to LogQL a bit. VictoriaLogs provides rich http-based querying API, which should simplify implementing a datasource for Logchef. The following document can be useful when translating SQL to LogsQL - https://docs.victoriametrics.com/victorialogs/sql-to-logsql/ |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I recently came across this interesting tweet from valyala from VictoriaMetrics team: https://x.com/valyala/status/1916631380559089806
Technical feasibility
Sources are already first-class citizens in Logchef's architecture. The platform is designed with a plug-and-play approach for data sources. Currently we only support ClickHouse, but since the source interface is external, adding VictoriaLogs should be technically feasible.
Search syntax considerations
Right now Logchef converts our simple search syntax to ClickHouse SQL. However, LogsQL (which VictoriaLogs uses) is already quite mature. We could explore if our search interface can be extended to work with both query languages:
This would maintain a consistent user experience regardless of the backend data source.
Community feedback
This discussion is primarily to gauge early interest. If there's sufficient demand from the community for VictoriaLogs support, we can prioritize this feature for an upcoming release.
What are your thoughts? Would VictoriaLogs support be valuable for your use cases?
Beta Was this translation helpful? Give feedback.
All reactions