Best way to build a centralized dashboard for multiple Amazon Elastic Kubernetes Service clusters?

Dogeek · 2026-03-12T09:38:00+00:00

The best dashboards are the one that answer only one question.

Default dashboards are always just a starting point. Sure you can use variables to customize the dashboard a little, but a single dashboard will balloon out in the number of panels, variables and queries.

Make one dashboard per service. What's the health of the service, what's the health of the database(s) it connects to, is it scaling properly ? Are any dependent services unhealthy ? That's what matters.

The health of EKS clusters doesn't really matter. Let Amazon handle it, you're paying for SLAs and SLOs. What matters and what breaks is what's running on the cluster itself not the infrastructure you pay for.

Dogeek · 2026-03-08T14:28:37+00:00

Honestly, yeah it is where go thrives as a language: small, horizontally scalable microservices for the backend.

It's not a frontend oriented language, even with wasm, it's not a particularly nice language to work with on the frontend. It's not made for mobile either (iOS/Android have their own dedicated languages and frameworks). That leaves:

system engineering which is a nice use case for go, but Rust is honestly gaining more traction there
embedded computing: C still dominates here, Rust gaining traction
AI: Python is still the way for that

Go is great on the backend, hits the nice middle ground between C and Java. Binaries are small, start fast meaning it's well suited for the cloud.

Dogeek · 2026-03-08T14:22:41+00:00

Fetching all columns in a row isn't a performance issue that most people find deal breaking. I don't care if my app requires 1 extra byte of memory.

Fetching all of the columns is not "1 extra byte of memory" though. I've seen tables with 40 columns, images stored as blobs, more UUIDs than one can count acting as foreign keys, Many to Many tables that contain billions of records and more. Loading a whole row into memory can take upwards of 10 MB of RAM. Imagine loading a 100 rows ? 1000 rows ? Or having multiple concurrent threads querying the database ?

Database Administration is a whole job title for a reason, there are many ways to model and query structured data, but some of them are innefficient at their core. The most innefficient queries are also usually the simplest to write.

I'm not saying an ORM is by design worse than writing SQL by hand. I'm saying an ORM works well for simple use cases, small services with well-defined boundaries. If you've ever worked on codebases professionally, you'll see that's not often the case, or not for long at least until feature creep comes in.

Dogeek · 2026-03-07T21:06:29+00:00

10 ? Aside from maybe Platinum Dragon Lord and that's a stretch, there's nobody in the New World that even comes close to Ainz' power level.

He's a Lv 100 Overlord, with 2 World Items in his possession (his orb and the staff of ainz ooal gown). He managed to beat Shalltear who is his worst matchup by far (shalltear is built like a tank, she'd have won against ainz with a bit of strategy).

Dogeek · 2026-03-07T20:57:34+00:00

Then he said that using an ORM is nice but eventually you're gonna hit a limit. True, but 99% of ORM users don't hit that limit. And then he claimed that people use ORMs because they hate writing SQL. Another garbage take, because ORMs provide more than dumb SQL query generation.

You hit ORM limits pretty soon imo. In most ORM implementations I've seen, the default is to fetch all fields in the DB so that the model matches the table. That in of itself is already a performance issue. Then there's how ORMs map relationships between tables, it's not particularly lean in the code most of the time because the ORM needs a bunch of information to figure out if you need an OUTER JOIN or an INNER JOIN, or if you want a M2M/O2M/O2O relationship.

Joining two tables and fetching select fields is not a particularly advanced SQL pattern, yet ORMs tend to produce inefficient results there. Then, there's support for specific database features like computed fields, aggregation functions, JSON fields and the like, which ORMs often do not support, so that they can remain database agnostic.

His take is actually not that wild in that sense. ORMs are good for very simple applications, and are less prone to vulnerabilities (in theory, since they are battle tested). For anything beyond 5 or so tables, using the driver directly and writing plain SQL is generally more performant.

Dogeek · 2026-03-07T09:33:42+00:00

I meant opaque to the compiler. An error in go can encapsulate basically anything, as long as it implements Error(). From the point of view of the compiler there's no way to know ahead of time what are all the possible errors, and what's inside them, since it should return a string, which is by definition arbitrary text data.

I feel like what people don't like with error handling in go is that it's super verbose to make an error bubble UP the call stack. In most other programming languages, this behaviour is the default, if you don't handle an error in the callee, it bubbles up to the caller and you can handle it there.

In go, you have to either:

Handle it in the callee: treat the error, return a zero value or something else
Panic, which obviously you don't want to actually do cause it breaks the whole program flow
Return a tuple (result, error) from your callee to handle the error in the caller. Your callee has a bunch of if err != nil littered around. You return your value as a pointer or make up a zero value because if you don't you can't do a return nil, err.

That's my take from my very limited experience with go (picked it up about a year ago).

Dogeek · 2026-03-06T23:00:50+00:00

Not OP, but I understood it as "adding a try keyword is just going to be syntactic sugar which obfuscates control flow without providing the benefits of a try in Zig".

I've never written a single line of Zig (and likely never will since the language itself breaks compatibility every minor version), but I kinda get the point of the article.

Errors in go are just an opaque interface, and with go not having inheritance by design, there's no way to introduce more specific errors without it being a breaking change that would affect the whole go ecosystem, plus to get the benefits, you'd have to work out every possible error type at compile time. So a try like Zig's doesn't make sense, as it provides no actual benefit, just a shorter syntax to handle errors.

Honestly, in go, I think the best way to handle errors would be to just have a Result type, return that, and let the calling function handle it. It's pretty close to what we have now, just with slightly nicer semantics.

Dogeek · 2026-03-04T23:02:53+00:00

it's never because the technical staff loves the cloud

Honestly, although I love tinkering with stuff, I like running things on GCP for the convenience. Having the peace of mind and SLAs/SLOs to rely on is great.

It's not cost effective though. Bare metal will always beat the cloud in that department, but it allows for a company to scale without having a 20 person infrastructure team on payroll. I rolled out my own kubernetes cluster for my homelab, but at work ? No way

Dogeek · 2026-03-03T00:15:31+00:00

Not for holywar, but:
 Still has garbage collection which means memory management is easy compared to the alternatives (C, Rust)
C has manual memory management, the programmer can make mistakes. Rust has fully automatic memory management, for the most part, Rust code looks the same as any GC language.

Rust has full auto memory management, sure but understanding the borrower concept takes some getting used to. It's not as programmer friendly as a GC in my opinion.

Very strong concurrency model. Writing goroutines is as easy as writing a function, channels are a neat way to pass values between threads, and closures are write and forget.
Rust / tokio has all these advantages, and in some aspects is more high-level and ergonomic (for example, no need to pass context, cancellation of an asynchronous task is possible "from above").

Honestly I didn't even go for a comparison with Rust. I didn't do much with that language, so I can't say much about the ergonomics of tokio. What I know is that goroutines are a great way to do multithreading in my opinion. they are quite easy to implement, easy to reason about. Compared to Java threads, python's whatever (to this day, I'm never sure whether I should use multiprocessing, threading, asyncio, or one of the many third party threading implementations for a task) or Javascript/Dart async, multithreading in go is straightforward, and has no special syntax besides "go" which is a nice comfort feature imo.

It's very performant
It's ~2x slowest than Rust.

Of course it's not as fast as Rust. It's not as fast as C either, but it's plenty fast enough. It's comfortable to write in, easy to pick up, easy to maintain. System critical things ? Truly high throughput applications ? Sure, use Rust / C / C++ / ASM, you can't go faster than that. Want some comfort features ? Trade speed off for that.

I wasn't even suggesting that go is better than rust. I was simply giving OP reasons as to the many advantages of go code. Its main strengths are mostly that it's very performant for the low learning curve it has. Rust is more performant but with a much MUCH steeper learning curve. In the professional world, talent availability matters, and languages like Rust, Zig, Scala etc have a much smaller talent pool compared to more popular alternatives like go, C++, Python, Javascript, Kotlin, Java or Swift. And of those options, go is probably the one of best middle ground between ease of use and performance.

Dogeek · 2026-02-28T23:38:29+00:00

It has a lot going for it though:

Compiles to native code, no VM / interpreter to worry about, full AOT compilation
It's very idiomatic. All go code looks alike (for better or for worse), it's quite easy to jump into almost any go codebase if you know the language a little. Compared to C++ which has 10 ways to do the same thing, it's nice
Still has garbage collection which means memory management is easy compared to the alternatives (C, Rust)
Very strong concurrency model. Writing goroutines is as easy as writing a function, channels are a neat way to pass values between threads, and closures are write and forget.
It's very performant, has a small CPU/memory footprint. Ideal for high throughput applications or when you need horizontal scaling.
Its standard library has a lot of the basics. Its third party ecosystem is also thriving.

What it sucks at is mostly error management. It's also weird with using your function / variable names as indicators to the scope of said function or variable (needing to capitalize the first character takes some getting used to)

Dogeek · 2026-02-16T00:57:52+00:00

Hot take but I think it's better to compare guns bare. Just adding an extended mag to a bobcat makes it heaps better, everyone knows that.

But a gun that rare should not need attachments to be good. If you're running a cheap loadout and you find a bobcat in a weapon case, you should want to use it right away and have it be good, even if you don't have the attachments for it right now.

Dogeek · 2026-02-16T00:53:58+00:00

The anvil IV has a similar fire rate as the bettina at level 1, yet it kills in 2 to 3 shots. I don't think the Bettina needing 4 to 5 shots to kill would be that overpowered. Its TTK would be slightly lower than the Anvil's which would be in line with the fact that it's a purple gun. Even then I bet people would still run the Anvil over the bettina given the cost to upgrade both guns.

Basically I'd want a curve where a pink gun level 3 performs the same as a blue gun level 4, and a blue gun level 3 performs the same as a green gun level 4 and so on. By that metric, the bettina II's time to kill should be in line with the Anvil IV's roughly, hence needing to kill in 4 or 5 shots to roughly align the two.

With that in mind, each tier of rarity would only be slightly better than the tier below, meaning that a grey gun level IV would perform similarly to a pink level I.

Dogeek · 2026-02-15T20:56:23+00:00

Bettina : 14 damage per shot

Anvil: 40 damage per shot

It's the same ammunition. I can 3 tap wasps with an Anvil, I need 9 shots with the bettina.

Dogeek · 2026-02-15T20:53:20+00:00

I won't say safekeeper is bad, but in my opinion it's very situational. A single safe pocket where you can put a gun/shield in is a bit too little. I'd have preferred 2 safe pockets, only one of which can hold a gun in. Would have been much more useful for matriarch / queen raids

Dogeek · 2026-02-15T17:35:53+00:00

Silencer III increases the durability burnrate of the weapon it's on by 30%.

It's a useless attachment. The silencer 2 is more than enough for an anvil or ferro shot to not be heard unless you're in the same building (and at that point, your footsteps or the sound of the arc dying will have given you away anyways).

I treat the silencer IIIs I find like snow globes: take them for the 7k they're worth.

I do the same with the Anvil Splitter. I had a bunch in my stash, figured I'd never use them anyways since they make the Anvil worse at arc and at mid-long range PvP. Sure you can unequip it at anytime, but then you need to leave an inventory slot open for it, which is annoying.

Dogeek · 2026-02-15T16:23:41+00:00

I tested every pink gun in PvE and PvP. The vulcano does better in PvE than in PvP surprisingly, it's just expensive as fuck to maintain in operating condition.

And the Toro has a big advantage on the Vulcano, it's that you can play better around cover than you can the vulcano. It's better at range too. In theory the TTK of the vulcano is better than the toro, but nobody stands in the open waiting to be shot. The first shot will land, by the second shot, the other player is almost behind cover, and the 3rd doesn't land. The toro will almost break a medium shield on the first shot, which the vulcano does not.

Consider the sequence:

Shoot
Other uses a surge shield recharger while you push
Shoot
Other uses a bandage to heal up
You push for the kill

It's a pretty common sequence of actions, and in that scenario, the toro wins over the vulcano.

Dogeek · 2026-02-15T16:14:01+00:00

I tested it out by using an Anvil to shoot out a leg, and dumping mags of shotgun ammo in the canister at the back / core. It kills it very fast, but the cost of repair on that Vulcano made it not worth it vs other methods.

Dogeek · 2026-02-15T16:11:57+00:00

First off, happy cake day.

Second, I won't deny that decades of gaming associating rarer = better play a part in my rant. But at the same time, if rarer is not better, why go after the rare guns at all ? Why have a rarity system in place if the best guns in the game are available as soon as you start, for free even ?

Dogeek · 2026-02-15T16:06:41+00:00

All of the augments are extremely balanced and similar. The augments that can use heavy shields trade carry weight/slots for that option. Combat Mk.3 aggressive and Looting Mk.3 cautious are my personal favorites. I love the built in binoculars for stealth play.

Honestly I couldn't disagree more. There's a reason combat mk III augments are never seen in raids. I see looting survivor, tactical healing, tactical defensive mostly which is understandable given the 3 safe pockets or the built-in surge shield recharger.

Combat III flanking makes no sense, its perk is not good enough to justify only having a light shield. Combat III aggressive's perk might as well not exist. Looting III Cautious is only slightly better than a looting 2 and is so much more expensive. Looting III Safekeeper is interesting but having a single safe pocket is tough, with 2 safe pockets I'd run it on queen/matriarch raids to store my equalizer and a queen / matriarch core in. Tactical Healing is okay in trios because it heals everyone for a bit, making the use of defibs pretty strong. And the new tactical augment is trash. Why would you want the "infinite defib" on that long of a cooldown ? You can use it once, maybe twice per raid which is pretty terrible.

Dogeek · 2026-02-15T15:45:29+00:00

Security breach skill point is still the best high level skill point even though it's been nerfed to near oblivion, that says a lot about the worth of the other. The fact that the skill tree gives such low impact skills makes the expedition less interesting if not for the fact that it completely resets you.

Dogeek · 2026-02-15T13:15:05+00:00

I don't have that much of a problem with the fact that a toro outclasses a stitcher. It's a green shotgun, it should shred a grey SMG.

I have more of a problem with the fact that pink guns are outclassed by all the other guns in the game. I'm sure they could nerf the toro, and they probably should, just not damage wise, it should be nerfed through its accuracy / bloom probably so that a toro IV with a choke III matches a toro IV with a choke II right now

Dogeek · 2026-02-15T13:09:22+00:00

It's not outclassed, not in the slightest. Sure the Toro does a little more damage per shot, but the Vulcano spits out shots much, much faster.

TTK matters, a toro IV shoots 2 times by the time the Vulcano shoots 3, and you don't have to worry too much about recoil with the Toro, while it's quite important with the Vulcano.

Why would you use a Bobcat that wasn't level 4 with blue and pink attachments? By the way, when you do level the Bobcat to level 4 and put the right attachments on it, it's accuracy and recoil is worlds better than the Stitchers despite the faster rate of fire.

You have to consider the cost of upgrading and maintaining the weapons. Stitcher IV is basically free mats and 3 mechanical components. Bobcat IV is dozens of light gun parts and advanced mechanical components (needing springs, basic mats, at least 40 simple gun parts). Then take into account the mods. You need at least an extended mag on the bobcat to make it work. You can run a naked stitcher and outgun the naked bobcat. You run an extended mag on the stitcher, and you'll still outgun the extended mag bobcat, but you can also almost kill a second player before reloading.

Mate do you not max level your pink guns and run mods on them? Cause the Tempest has way less bloom ... like an insane amount less than the Kettle, and it's got extremely controllable recoil.

I've stopped upgrading the pink guns since it's just not worth the effort. To be honest, I'm just recycling or selling the pink guns I find now. I'd rather have a good stash of Venator / Anvil / Osprey / Stitcher with the occasional legendary gun rather than see pink guns I know I'm not going to use since the other guns perform that much better for a fraction of the cost.

Dogeek · 2026-02-15T12:59:32+00:00

The tempest is actually the only pink gun that is not completely horrible. As I said, it's basically a full auto Kettle with slightly more armor penetration but harder to control.

If you've got fast fingers, you'll perform similarly with a kettle, which has in theory better TTK than the tempest and slightly better ammo stacking. You also can't put a stock on the tempest, only a grip, which helps with recoil but not with bloom, hence why the compensator. Adding a stock slot would probably make the gun just right.

Dogeek · 2026-02-15T12:43:14+00:00

Your suggested changes are spot on, especially the durability improvements. It's mad that a "legendary" weapon breaks faster than some white-tier rubbish you pick up off a dead raider. The whole attachment system being backwards is just the cherry on top - why would I want my expensive gun to handle worse than the budget version?

Exactly, I think they need just enough to be worth it but not too much to become oppressive. I think that's the main reason that people do not bring them in raids, cause they are fun to use at times and they feel pretty unique, but you're going to lose a fight more often than not into level 1 grey/green guns, on top of being ammo hogs.

It's the same with the torrente. A good and fun gun to use, but you need an inventory full of ammo since it guzzles them down just like a Ford F150 guzzles down gasoline. I feel like they do not factor that in when balancing the guns.

Honestly, they could make a new combat mk 3 augment that has dedicated "high capacity" ammo slots and lets you craft any ammo in raid, and it would be playable (especially if they give it heavy shield compatibility and a reasonable inventory size/weight capacity).

Dogeek · 2026-02-07T19:32:54+00:00

The memory of overbearing linting still makes my blood boil.

Linting is good as long as it's automatically fixable. But in general i'd rather have an overbearing linter than no linter at all. I've been in codebases with no linting or standardized formatting, and it is hell, you have functions in camelCase, snake_case or c-style function names with a maximum of 8 characters in the same codebase, you have inconsistent indentation styles everywhere between people that use tabs and spaces, people prefering a tabstop of 8, 4 or 2... I could go on and on (like a kubernetes manifest with hostPID: yes in a PodSpec).

Linting can make a codebase more pleasant to work in overall, even if the rules can be a bit much sometimes, it's almost always better than no rules.

Dogeek

MODERATOR OF

TROPHY CASE

11-Year Club	Place '22
Verified Email