Netdata
zstd
Netdata | zstd | |
---|---|---|
118 | 109 | |
68,252 | 22,445 | |
0.7% | 1.5% | |
10.0 | 9.7 | |
6 days ago | 10 days ago | |
C | C | |
GNU General Public License v3.0 only | GNU General Public License v3.0 or later |
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.
Netdata
-
A list of SaaS, PaaS and IaaS offerings that have free tiers of interest to devops and infradev
netdata.cloud — Netdata is an open-source tool to collect real-time metrics. It's a growing product and can also be found on GitHub!
-
The Hidden Costs of Monitoring
Netdata is designed with efficiency, scalability, and flexibility in mind, aiming to address most of the challenges associated with both open-source tools and commercial SaaS offerings.
-
Looking for a way to remote in to K's of raspberry pi's...
Monitoring = netdata on each RPi https://www.netdata.cloud/ binded to the vpn interface being scraped into a prometeus thaons https://thanos.io/ setup with grafana to give management the Green all is good screens (very important).
-
netdata is suddenly reporting 1hour_ecc_memory_correctable like every day
We run netdata to have a bit of insight into whats happening on the 10+ dedicated servers in Falkenstein. So far we have seen a 1hour_ecc_memory_correctable about once a month. Suddenly we get 1hour_ecc_memory_correctable like every day from different servers. Any ideas why that could be happening?
- Netdata v1.43.0 – with systemd-journal log integration
-
Netdata: query, explore and visualize SystemD Journals!
Documentation and source code of this plugin: https://github.com/netdata/netdata/tree/master/collectors/systemd-journal.plugin
Home Page and source code: https://github.com/netdata/netdata
-
Show HN: The simplest centralized logs management ever, with SystemD and Netdata
I started the discussion, and offered a solution too:
https://github.com/netdata/netdata/discussions/16136
-
μMon: Stupid simple monitoring
hey - I work on ML at Netdata (disclaimer).
We have a big PR open and under review at moment that brings in a lot more logs capabilities: https://github.com/netdata/netdata/pull/13291
We also have some specific logs collectors too - i think in here might be best place to look around at the moment, should take you to the logs part of the integrations section in our demo space (no login needed, sorry for the long horrible url, we adding this section to our docs soon but at moment only lives in the app)
https://app.netdata.cloud/spaces/netdata-demo/rooms/all-node...
- Netdata
zstd
-
Rethinking string encoding: a 37.5% space efficient encoding than UTF-8 in Fury
> In such cases, the serialized binary are mostly in 200~1000 bytes. Not big enough for zstd to work
You're not referring to the same dictionary that I am. Look at --train in [1].
If you have a training corpus of representative data, you can generate a dictionary that you preshare on both sides which will perform much better for very small binaries (including 200-1k bytes).
If you want maximum flexibility (i.e. you don't know the universe of representative messages ahead of time or you want maximum compression performance), you can gather this corpus transparently as messages are generated & then generate a dictionary & attach it as sideband metadata to a message. You'll probably need to defer the decoding if it references a dictionary not yet received (i.e. send delivers messages out-of-order from generation). There are other techniques you can apply, but the general rule is that your custom encoding scheme is unlikely to outperform zstd + a representative training corpus. If it does, you'd need to actually show this rather than try to argue from first principles.
[1] https://github.com/facebook/zstd/blob/dev/programs/zstd.1.md
-
Drink Me: (Ab)Using a LLM to Compress Text
> Doesn't take large amount of GPU resources
This is an understatement, zstd dictionary compression and decompression are blazingly fast: https://github.com/facebook/zstd/blob/dev/README.md#the-case...
My real-world use case for this was JSON files in a particular schema, and the results were fantastic.
-
SQLite VFS for ZSTD seekable format
This VFS will read a sqlite file after it has been compressed using [zstd seekable format](https://github.com/facebook/zstd/blob/dev/contrib/seekable_f...). Built to support read-only databases for full-text search. Benchmarks are provided in README.
-
Chrome Feature: ZSTD Content-Encoding
Of course, you may get different results with another dataset.
gzip (zlib -6) [ratio=32%] [compr=35Mo/s] [dec=407Mo/s]
zstd (zstd -2) [ratio=32%] [compr=356Mo/s] [dec=1067Mo/s]
NB1: The default for zstd is -3, but the table only had -2. The difference is probably small. The range is 1-22 for zstd and 1-9 for gzip.
NB2: The default program for gzip (at least with Debian) is the executable from zlib. With my workflows, libdeflate-gzip iscompatible and noticably faster.
NB3: This benchmark is 2 years old. The latest releases of zstd are much better, see https://github.com/facebook/zstd/releases
For a high compression, according to this benchmark xz can do slightly better, if you're willing to pay a 10× penalty on decompression.
xz -9 [ratio=23%] [compr=2.6Mo/s] [dec=88Mo/s]
zstd -9 [ratio=23%] [compr=2.6Mo/s] [dec=88Mo/s]
- Zstandard v1.5.6 – Chrome Edition
-
Optimizating Rabin-Karp Hashing
Compression, synchronization and backup systems often use rolling hash to implement "content-defined chunking", an effective form of deduplication.
In optimized implementations, Rabin-Karp is likely to be the bottleneck. See for instance https://github.com/facebook/zstd/pull/2483 which replaces a Rabin-Karp variant by a >2x faster Gear-Hashing.
- Show HN: macOS-cross-compiler – Compile binaries for macOS on Linux
-
Cyberpunk 2077 dev release
Get the data https://publicdistst.blob.core.windows.net/data/root.tar.zst magnet:?xt=urn:btih:84931cd80409ba6331f2fcfbe64ba64d4381aec5&dn=root.tar.zst How to extract https://github.com/facebook/zstd Linux (debian): `sudo apt install zstd` ``` tar -I 'zstd -d -T0' -xvf root.tar.zst ```
-
Honey, I shrunk the NPM package · Jamie Magee
I've done that experiment with zstd before.
https://github.com/facebook/zstd/blob/dev/programs/zstd.1.md...
Not sure about brotli though.
-
How in the world should we unpack archive.org zst files on Windows?
If you want this functionality in zstd itself, check this out: https://github.com/facebook/zstd/pull/2349
What are some alternatives?
Zabbix - Real-time monitoring of IT components and services, such as networks, servers, VMs, applications and the cloud.
LZ4 - Extremely Fast Compression algorithm
cadvisor - Analyzes resource usage and performance characteristics of running containers.
Snappy - A fast compressor/decompressor
LibreNMS - Community-based GPL-licensed network monitoring system
LZMA - (Unofficial) Git mirror of LZMA SDK releases
ElastiFlow - Network flow analytics (Netflow, sFlow and IPFIX) with the Elastic Stack
7-Zip-zstd - 7-Zip with support for Brotli, Fast-LZMA2, Lizard, LZ4, LZ5 and Zstandard
Munin - Main repository for munin master / node / plugins
ZLib - A massively spiffy yet delicately unobtrusive compression library.
Nagios - Nagios Core
brotli - Brotli compression format