Well yes. But just in case this wasn't clear: this is a crime, and you will get your money back in most cases. It's on the merchant to ensure a Direct Debit Mandate is actually valid.
I just don’t get this sentiment. How would you represent metrics as traces? You cannot. Even reconstructing traces from logs would be challenging at best. How would you get, say, Garbage Collector metrics from logs or traces? You cannot.
There is no magic bullet. Observability isn’t something you can just slap on and call it a day. While traces and logs might share superficial similarities, they are not the same. And metrics are something else altogether. Trying to somehow unify them would be a prime example of "wrong abstraction".
> “The next time something like this occurs again, please save me a trace.”
The building blocks for this exist. The observability platform must simply (haha) implement the pattern detectors and use them for sampling decisions.
I am not sure if this is what they mean, but e.g. with Micrometer in Java you can instrument your code once with observations that produces observation events, then you can register handlers that can turn them into metrics, or logs, or traces without having to instrument your code three times.
Logs and metrics are both derived from events. A log takes the whole event and records it somewhere. A metric takes some numeric value from the event, aggregates it over time, and records it periodically. You can reconstruct a metric from logs for the underlying events.
A trace is a period of execution between two events. You could record a trace as a pair of log entries, or one log entry at the end. You can then reconstruct a trace from those log entries. If you want to associate multiple spans, and separate log entries, within a trace, you use a shared ID, which is just the same as a context entry for logging.
All three of these pillars are just ways of looking at events. They are not fundamentally different at all. This is a mistaken idea in "Observability 1.0" whose correction is the basis of "Observability 2.0".
The pillars still have their uses, but the choice between them is really a non-functional one - storing a log entry for every event might be too expensive, so just store metrics instead, and index every log entry so it can be correlated with nearby ones might be too expensive, so just store specific traces instead.
This is the literally the "everything is a graph" argument from database architecture. The conceptual abstraction fails badly because it has to be implemented on real silicon that imposes constraints not considered in the abstraction.
Logs, metrics, and traces are all derived from raw events but none of them are intrinsically discrete events in a systems engineering sense. They are all different data models with different patterns of traversal over raw events. As data model, you need to build secondary indexes over the raw metrics to reflect the orthogonal data access patterns depending on if you are evaluating them as logs, metrics, or traces. This famously has poor scalability and performance.
In analytical processing we largely manage the inherent performance and scalability issues using denormalization, which allows processing pipelines with very different requirements to be optimized independently. Or in this context, treating logs, metrics, and traces as unrelated things with independent infrastructure.
"Observability 2.0" deeply embeds an architectural assumption that all systems are small. It is not a tractable architecture in high-scale or high-performance systems.
Real silicon has a long history of destroying beautiful conceptual abstractions in software engineering.
You are conflating the challenges of ingesting and querying at large scale with the what the original comment is about, which is emitting them more easily.
I don't see them as separate issues. Emitting them directly runs into the inherently poor memory locality (and potentially concurrency) of trying to produce logs, metrics, and traces from the same underlying event data representation.
It is only "easy" if performance and scalability don't matter.
> Logs and metrics are both derived from events. A log takes the whole event and records it somewhere. A metric takes some numeric value from the event, aggregates it over time, and records it periodically. You can reconstruct a metric from logs for the underlying events.
No, metric is just value. Some are derived from events (like histogram/rate of given event duration) but others are wholly independent (like returning app's CPU/memory usage)
The app's memory usage is an aggregation of the alloc/free events. I think the original point was that all of the metrics, traces and logs are conceptually the same but for efficiency, we store less data in each place, not the full history. Personally, for the systems I work on, having an easy way to turn logs into metrics and vice versa, without deciding up front, would be a slight benefit.
Technically, you can use the same places in the code where you stop/start/fork traces to also be the places where you increment the counters/gauges, etc. Which I think the GP was alluding to when describing the micrometer solution. Similarly, you can derive metrics for log lines without having to emit the actual log lines.
Then separately you can have log levels or verbosity levels that control to which level you actually emit traces/logs and/or roll up metrics.
At that point you almost might as well just log everything. The decision logic is likely about as complex as just doing it. Then I suppose you have a watchdog task that fires off every, say, 15 minutes or an hour or something, looks at the collected data, and either decides to keep it or trash it while recording a tiny "nothing interesting" datapoint.
No... Adaptive sampling is a family of statistical methods to choose an appropriate decimation strategy for arbitrary events based on real-world occurrence distributions.
It can be applied to tracing, metrics, logging ("sampling") and profiling.
In the code define everything as a span with a name, scope (start-end), description and tags... and then you can easily dynamically produce traces, spans, logs or metrics based on what you need.
When I visit an article on a popular German tech news website, it interrupts music playback on my iPad (the website takes audio focus). I bet they do something similar.
No fiddling is definitely not a primary point. If one has both valuable or large amounts of data fiddling is inevitable. Nothing I have seen in retail markets is at a level of chromecast or phone setup or TV setup.
And often not only the price is high but poor reliability.
Of course no fiddling is a primary point. That’s probably _the main point_. Sure you need _some_ configuration/setup, but it’s in a completely different ballpark to a custom built solution.
which brand? Anytime you have data locally it is lot of work. There is a reason people go to Google drive or even proton drive etc for that reason. If you can do that initial setup then DIY is not worse. Yes, all these plug-n-play give a false sense of security. One of the RAID drives is failing - no one knows.
Your definition of fiddling is maybe wrong. Not everyone is Linus S or Jeff geerling to look for that exact DDR stick etc. Get a resonable laptop or mini PC with 2 x drives. Done. Even windows drive share.
storage of data long-term of course to many segments of a market needs to be seamless and safe feeling, comforting even. To slap a brand on the side of a NAS that is complex and causes grandma to lose the entire family photo history that you scanned for a few summers after your uncle did research for decades - well, that's not great for repeat sales, right?
Believe me, you don't want a NAS at a chromecast level. Chromecasts are designed to be user friendly and hide a lot of settings. That wouldn't be a problem if the things worked at least. I can't even count how many times I've had to reset a chromecast because something broke and wasn't fixable.
A casual user would never buy a NAS at all, since most prefer the ease of something like iCloud or Google. If you buy a NAS you often have a specific reason to (too much data, needing to be able to reach a speed to work off of it, security...) and then the fiddeling becomes an advantage I feel. Yes it's a bit more effort, but you can get something that actually does what you want to instead of what the manufacturer thinks that you want it to do.
I suspect the energy efficiency correlates with how old it is -- modern silicon in laptops is amazing. I doubt a new PC would take up 45W like this i7 7700k-powered one I've had for years.
This "no fiddling" could be the single entire counterpoint to the article and hacker culture in general. All the problems stem from "consumer wants no fiddling".
I think it's a little more nuanced. Most people cannot fiddle (with PCs). They would have to learn to, first. Does this mean they deserve to have shit shoved down their throats? No. However, they are very vulnerable, and companies want to capitalize on this fact.
Hackers (whatever kind) are just one portion of the total populace. Others deserve genuinely good products, too. And maybe sometimes even a hacker wants to take a break. ;-)
> Most people cannot fiddle (with PCs). They would have to learn to, first. Does this mean they deserve to have shit shoved down their throats?
I can fiddle perfectly well. I do it all day at work, with workstations, servers and HPC. I can already scratch that itch with much nicer than I will be ever able to buy myself. But I am not spending 1 hour more than I need to for my NAS at home, life is too short and I also like to have other hobbies. To the point that yes, I do spend a bit more for convenience and niceness.
> And maybe sometimes even a hacker wants to take a break. ;-)
Oh yeah, that combination of fear and lack of knowledge probably plays a big part. I was once involved with creating a privacy policy for a B2B(!) web application. What a farce. In the end, the process was cut short (counsel too expensive and not nearly familiar enough with tech). The resulting document was at least 50 % stuff the app simply does not do.
The main point is to use zswap over swap plus zram. The sd card usecase definitely doesnt want swap to disk, compressed or otherwise, so zram or no swap are the options.
Moving swap off of sdcard is indeed a good plan.
But since swapping is done when ram is depleted, using a ramdisk for it (which uses ram) is ... exactly what you dont want.
Since OP states they have disks attached to the machine as well, the better thing is use a partition there for swap.
If you join multiple/many tables, you could end up with a large volume of data. And yes, this is bit-for-bit duplication—on the network. The query result is (typically) a single table. This table will get serialized as-is, with all duplicate data.
Couldn't we make references as `byte offsets in the result set` work to handle duplication? Real memory pointers wouldn't work over the network of course, but if the database driver would return results like this, the client could easily stitch these together. My hunch is that even if we implement references on a higher level than raw byte offsets it would still be more performant than just returning R1*R2 bytes for any R1<1:N>R2.
---
EDIT: According to LLM friends you could achieve before wire de-duplication by using FOR JSON AUTO in SQL Server or jsonb_agg in PostgreSQL. Not sure how much overhead that incurs though.
I think jsonb_agg could be a solution. Requires cpu for decoding but I think it is compensated by the reduction of on the wire traffic. Queries are different , especially if you have several one-to-many joins so you have to do it at the framework level. I wonder if it would be feasible a Postgres extension that does this automatically for you
You'd still return a multiplicative amount of rows, even if those rows contained only a reference. `array_agg` in postgres avoids this, but EF does not support using it for collection navigations.
One could envision a "Cartesian product" operation in the wire protocol, but I'm not convinced that's a good approach.
> You'd still return a multiplicative amount of rows, even if those rows contained only a reference
Sure, but a pointer is still a massive win over records, and I think a further cartesian product wire protocol extension would not be worth the hassle.
I don't think pointers (beyond a simple "same as in previous row" marker) will be a huge improvement, since you still get a multiplicative number of rows. And it comes with the cost of keeping all that data in memory. This approach also competes with using cheap compression (e.g. LZ4).
Some kind of "product" operator on the other hand reduces the cost to additive (just like `array_agg`).
> I don't think pointers (beyond a simple "same as in previous row" marker) will be a huge improvement, since you still get a multiplicative number of rows
A marker as "byte offset in response data" is very efficient. Consider this:
SELECT BlogPost bp LEFT JOIN Comment c WHERE bp.id=101 AND c.blogPostId=bp.id
If the BlogPost is 1KiB in size and has 500 comments, doing it naively will return `500 * 1KiB` for the BlogPost part.
To contrast, suppose your format needs 3 bytes for pointers, you will use `1 * 1KiB + 500 * 3B` for the BlogPost part.
Compression and decompression takes CPU-time, I have a hunch this brings in an unacceptable penalty. At least this route hasn't been chosen while it would be the easiest to implement.
Agree that Compression is not a good option for this; you'd wind up needing to decompress the rows anyway (or spend a good amount of time on trying to use the compressed symbols to detect a dupe, which I feel like would be very dependent on picking the right algo or maybe even a custom one.)
As far as your idea, I think where a lot of the challenge lies in that it complicates a lot of the up-front protocol.
Some of these DB protocols are downright ugly [0], and need to have a very long tail for supporting systems built on older versions. And they can be very finicky thus people are afraid to touch both the DB side and the Driver side.
So, at best you'd need to have a special connect string and then work with driver teams and/or vendors to understand the new format, deal with all of the teething issues, and will have to continue to support the old protocol in your DB code for at least another decade (probably longer for any commercial product.)
[0] - TDS comes to mind, I'm betting TTC/OPI is not fun either.
And yet it was exactly one case.
reply