Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
valyala
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
11 ms
·
151.
▲
Grepping Logs Remains Terrible
(chronicles.mad-scientist.club)
2 points
by
valyala
2y ago
|
1 comments
152.
▲
Home Infra – Beyond K8s
(vrutkovs.eu)
3 points
by
valyala
2y ago
|
0 comments
153.
▲
Book Preview: The Anatomy of Go
(bytesizego.com)
1 points
by
valyala
2y ago
|
0 comments
154.
▲
by
valyala
2y ago
I highlight Loki problems, so potential users are aware of them when choosing log management system. It is Loki's developers business to decide what to do next - to fix these problems or continue hiding them, so users discover them the
155.
▲
by
valyala
2y ago
> 2. It has a convenient and simple query language IMHO, Loki query language is the most inconvenient language for logs I've seen: - It doesn't support calculating multiple stats in a single query. For example, it cannot calcul
156.
▲
by
valyala
2y ago
I'm trying to push Loki developers to fix these issues to make Loki users happy. What's the point to hide these issues? The won't disappear on their own over time. I'm very glad to know about VictoriaLogs issues, so they
157.
▲
by
valyala
2y ago
How much CPU and RAM do all the Loki components use for your workload? Could you share Loki config, which can deal with 1TB/hr volume of logs?
158.
▲
by
valyala
2y ago
Elasticsearch can store arbitrary text in log fields, including JSON-encoded string. Elasticsearch can also tokenize JSON-encoded string and provide fast full-text search over such string in the same way like it does for a regular plaintext
159.
▲
by
valyala
2y ago
Did you try VictoriaLogs? It is easier to configure than Loki and Elasticsearch, and it uses less CPU and RAM. See https://itnext.io/how-do-open-source-solutions-for-logs-work...
160.
▲
by
valyala
2y ago
VictoriaLogs is free from issues mentioned in the referred article. It supports log fields with big number of unique values (such as user_id, trace_id, ip, etc.) from the beginning, and it doesn't need any configuration for working wit
161.
▲
Some notes on Grafana Loki's new "structured metadata"
(utcc.utoronto.ca)
117 points
by
valyala
2y ago
|
44 comments
162.
▲
JSONBench – A Benchmark for Data Analytics on JSON
(jsonbench.com)
1 points
by
valyala
2y ago
|
0 comments
163.
▲
Tiny wins: the big benefits of little changes [the post from 2018]
(joelcalifa.com)
1 points
by
valyala
2y ago
|
0 comments
164.
▲
Practical protobuf – from basic to best practices
(victoriametrics.com)
2 points
by
valyala
2y ago
|
0 comments
165.
▲
Using AI for Troubleshooting: OpenAI vs. DeepSeek
(coroot.com)
2 points
by
valyala
2y ago
|
0 comments
166.
▲
by
valyala
2y ago
No, thank you! Europe has these laws, which complicate reducing workforce when needed. These laws resulted in economic crisis across top industries (such as automotive) we see right now.
167.
▲
by
valyala
2y ago
I suppose they switched from Grafana Cloud to self-hosted Prometheus or Prometheus-like solution such as Mimir, Thanos or VictoriaMetrics.
168.
▲
FOSDEM 2005 recap (Go and observability tracks)
(victoriametrics.com)
1 points
by
valyala
2y ago
|
0 comments
169.
▲
by
valyala
2y ago
As I know, Flux query language from InfluxDB v2 was too complex comparing to the simple pipe-based SQL from the BigQuery announcement. That is the main reason why Flux is abandoned in InfluxDB v3.
170.
▲
by
valyala
2y ago
Agreed! LogsQL uses `|` as pipe delimiter too - https://docs.victoriametrics.com/victorialogs/sql-to-logsql/
171.
▲
by
valyala
2y ago
While SQL is great, complex analytical queries are much easier to write, read and modify when they are written in pipe-based syntax because of the reasons outlined in the announcement: - Pipe-based query is executed in clear sequential stag
172.
▲
by
valyala
2y ago
Pipe-based query syntax has been appeared a better alternative to SQL in many databases, because it is easier to read, write and maintain. The only thing is that this syntax isn't standardized among databases yet. BTW, we at VictoriaLo
173.
▲
How protobuf works: the art of data encoding
(victoriametrics.com)
1 points
by
valyala
2y ago
|
0 comments
174.
▲
by
valyala
2y ago
Pay attention that VictoriaLogs doesn't need any configuration and table schema in this benchmark - it is enough to ingest JSON lines, where every line contains a single ad serving event [1]. Also it is interesting to compare the origi
175.
▲
VictoriaLogs Beats Elasticsearch, MongoDB and PostgreSQL in ClickBench
13 points
by
valyala
2y ago
|
1 comments
176.
▲
by
valyala
2y ago
I believe all the users mentioned above are some kind of bots, which abuse GitHub, since human users cannot run `git push` 10K+ times per day to the same single repository.
177.
▲
by
valyala
2y ago
Another interesting discovery - an organization with more than 15K GitHub repositories - https://github.com/orgs/static-web-apps-testing-org/reposito... It has been found with the following query - https:/&#
178.
▲
GitHub repositories with big number of commits per day
6 points
by
valyala
2y ago
|
3 comments
179.
▲
by
valyala
2y ago
Loki has the following problems: - It is non-trivial to setup and operate. It requires properly configuring and orchestrating numerous components - distributor, ingestor, querier, query frontend, compactor, consul, ruler, memcache, index se
180.
▲
by
valyala
2y ago
Take a look at VictoriaLogs - https://docs.victoriametrics.com/victorialogs/ . It is a single small executable, which runs out of the box with the default configs (e.g. it is zero-config) and stores all the data into a
More ›