jrock.us VS VictoriaMetrics

Compare jrock.us vs VictoriaMetrics and see what are their differences.

jrock.us

jrock.us production infrastructure and personal website (by jrockway)
Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
jrock.us VictoriaMetrics
1 97
0 10,826
- 3.3%
6.2 9.9
3 months ago 5 days ago
Open Policy Agent Go
- Apache License 2.0
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

jrock.us

Posts with mentions or reviews of jrock.us. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-08-26.
  • Monitoring Raspberry Pi Devices Using Telegraf, InfluxDB and Grafana
    3 projects | news.ycombinator.com | 26 Aug 2021
    I used 1.x for my push-monitoring stack at my last job. (For cases where "pull" is practical, I would always use Prometheus. Prometheus also has "push" now, by the way.) They went into 2.0 mode and kind of neglected 1.x, and I kind of forgot about it. At the time, I was most familiar with an internal monitoring system at Google, and I found I couldn't do queries that I expected to be able to do. I even mentioned it on HN and some influx folks told me that what I wanted to do was too weird to support. (It's not. I was collecting byte counters from fiber CPEs, and wanted to have bandwidth charts based on topology tags I stored with the data -- imagine a SQL table like (serial_number text not null, time timestamp not null, locality text not null, bytes_sent int64 not null, bytes_received int64 not null). The problem was that timestamps would not be aligned between records in the same locality group -- I sampled these occasionally throughout the day and not all at the same instant. And, they were counters, not deltas, so the query would have to do the delta across each serial number, and then aggregate across all devices in a locality. Very possible to do, I literally had that chart with the other monitoring system. But not possible with the influx v1 querying, as far as I could tell.)

    I set up 2.x for myself recently, and they have really done a lot of work. The OSS offering has most of the features that cloud/enterprise would. It was easy to set up -- they don't have any instructions for installing it in Kubernetes, and haven't updated their Helm charts for 2.x, but it was like 3 minutes to write a manifest (https://github.com/jrockway/jrock.us/tree/master/production/...) myself, which I prefer 99.9% of the time anyway. The new query language is incredibly verbose, but I see the steps that I remember having with Google's internal system, align, delta, aggregate... all possible. (I had to scratch my head a lot, though, to make it work. And I really am not able to reason about what operations it's doing, what's indexed or not indexed, why I ingest my data as rows but process it as columns, etc.) The performance is good, and it worked well for my use case of pushing data from my Intranet of Stuff. Generally I like it and I don't think they are being shady in any way. Definitely considering using it at work for collecting timing information from regular performance tests and CI steps. (To enable my coworkers to make performance improvements and see "according to this dashboard, I made this release 10% faster!")

    The reason I picked InfluxDB over TimescaleDB for my personal stuff is because InfluxDB has an API with built-in authentication. I can give each of my devices an API key from their web interface, and I make an HTTP request to write data. Very simple. (They have a client library, but honestly my main target is a Beaglebone, and it doesn't have enough memory to compile their client library. I've never seen "go build" run out of memory, but their client makes that happen. I shouldn't develop on my IoT device, of course, but it's just easier because it has Emacs and gopls, and all the sensors connected to the right bus. Was easier to just manually make the API calls than to cross-compile on my workstation and push the release build to the actual device.) TimescaleDB doesn't have that, because it's just Postgres. So I'd basically have to expose port 5432 to the world, create Postgres users for every device, generate a password, store that somewhere, etc. Then to ingest data, I'd connect to the database, tune my connection pool, retry failed requests manually, etc. Using HTTP gets me all that for free; I can just configure retries in Envoy.

    But... SQL queries are a lot easier to figure out than FluxQL queries, and I already have good tools for manipulating raw data in Postgres (DataGrip is my preferred method), so I think I will likely be revisiting TimescaleDB. Honestly, I'd pay for a managed offering right now if they had a button in Google Cloud Console that was "Create Instance and by the way this just gets added to your GCP bill for 10% more than a normal Cloud SQL instance".

VictoriaMetrics

Posts with mentions or reviews of VictoriaMetrics. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-04-03.
  • OpenTelemetry Is Too Complicated
    2 projects | news.ycombinator.com | 3 Apr 2024
    VictoriaMetrics CTO here.

    The referred library is the official OpenTelemetry package for reading metrics in Go language [1] - more details are available at [2].

    Note that we at VictoriaMetrics like the idea of unified observability standard like OpenTelemetry. The issue is in the current otel implementation. It is too bloated and very inefficient. This contradicts to our experience with observability cases, which need very optimized format for metrics' transfer in order to reduce costs on CPU and network traffic needed to transfer and process these metrics.

    VictoriaMetrics continues investing in OpenTelemetry by providing integration docs [3] and improving the existing functionality for otel metrics' ingestion [4].

    [1] https://github.com/open-telemetry/opentelemetry-proto-go

    [2] https://github.com/VictoriaMetrics/VictoriaMetrics/pull/2570...

    [3] https://docs.victoriametrics.com/guides/getting-started-with...

    [4] https://github.com/VictoriaMetrics/VictoriaMetrics/issues/60...

  • Observability at KubeCon + CloudNativeCon Europe 2024 in Paris
    7 projects | dev.to | 26 Mar 2024
    Victoria Metrics
  • All you need is Wide Events, not "Metrics, Logs and Traces"
    7 projects | news.ycombinator.com | 27 Feb 2024
  • Top 11 Grafana Alternatives in 2023
    4 projects | dev.to | 23 Oct 2023
    VictoriaMetrics is primarily a time-series database designed for efficiently storing and querying time-series data. It is often used as a back-end data store for time-series data generated by monitoring systems like Prometheus. VictoriaMetrics excels at handling large volumes of time-series data, offering efficient storage and query capabilities.
  • InfluxDB CTO: Why We Moved from Go to Rust
    5 projects | news.ycombinator.com | 1 Oct 2023
    Not sure I follow since there are very competitive tools written in Go such as https://victoriametrics.com for an example in this space.
  • μMon: Stupid simple monitoring
    12 projects | news.ycombinator.com | 24 Sep 2023
    Did you try VictoriaMetrics [1] and vmagent [2]? It is a single self-contained binary without external dependencies. It requires relatively low amounts of CPU, RAM, disk space and disk IO, and it runs on ARM.

    [1] https://github.com/VictoriaMetrics/VictoriaMetrics/

    [2] https://docs.victoriametrics.com/vmagent.html

  • CERN swaps out databases to feed its petabyte-a-day habit
    2 projects | news.ycombinator.com | 21 Sep 2023
    https://github.com/VictoriaMetrics/VictoriaMetrics#cardinali...

    If I understanding correctly, it deal with high cardinality by dropping data, the operators need to monitor for this and adjust their data to lower the cardinality.

  • Prometheus Observability Platform: Intro
    4 projects | dev.to | 14 Sep 2023
    VictoriaMetrics
  • VictoriaMetrics VS openobserve - a user suggested alternative
    2 projects | 30 Aug 2023
  • OpenTelemetry in 2023
    36 projects | news.ycombinator.com | 28 Aug 2023
    You shouldn't unless you want to use the new open source standard for telemetry. You won't benefit from simplicity or performance improvements. It would be quite the opposite. You can check what is the actual cost of open telemetry adoption here [0]

    But if you ever decide to go this path - VictoriaMetrics supports OpenTelemetry protocol for metrics [1]

    [0] https://github.com/VictoriaMetrics/VictoriaMetrics/pull/2570

    [1] https://docs.victoriametrics.com/Single-server-VictoriaMetri...

What are some alternatives?

When comparing jrock.us and VictoriaMetrics you can also consider the following projects:

Telegraf - The plugin-driven server agent for collecting & reporting metrics.

mimir - Grafana Mimir provides horizontally scalable, highly available, multi-tenant, long-term storage for Prometheus.

thanos - Highly available Prometheus setup with long term storage capabilities. A CNCF Incubating project.

prometheus - The Prometheus monitoring system and time series database.

loki - Like Prometheus, but for logs.

ClickHouse - ClickHouse® is a free analytics DBMS for big data

InfluxDB - Scalable datastore for metrics, events, and real-time analytics

jaeger - CNCF Jaeger, a Distributed Tracing Platform

snmp_exporter - SNMP Exporter for Prometheus

clickhouse-bulk - Collects many small inserts to ClickHouse and send in big inserts

Grafana - The open and composable observability and data visualization platform. Visualize metrics, logs, and traces from multiple sources like Prometheus, Loki, Elasticsearch, InfluxDB, Postgres and many more.