mmanciop

5 ms·

1.
by mmanciop 1y ago
Indeed if there were “official” container images out there, I might have instead run the server on Google Cloud Run or AWS AppRunner, without having to take care of the Linux underneath. Or an Amazon ECS task. I don’t have a Kubernetes clus
2.
by mmanciop 1y ago
> Telemetry does not address this, though. Shoving it into a container and assigning it a simple “restart if down” rule does. A Systemd unit as shown in [1] does it too without using containers and with fewer moving parts of using contai
3.
by mmanciop 1y ago
To be fair, the setup of the article works with most modern observability solutions, in same cases just by replacing the endpoint and authentication token. Turning telemetry processing into a sort of utility is one of the great things that
4.
by mmanciop 1y ago
Indeed. My personal definition of nanosecond is the time passing between the Minecraft server having a hiccup, and the first scream piercing the air. The printer not printing is DEFCON 5 material.
5.
by mmanciop 1y ago
I actually had to splurge got 2 VCPUs on Digital Ocean to avoid "skipping ticks" and it does sound pretty nuts to me. We play max 3 players. I would expect the server with such a load to be able to run on a slightly tuned up toast
6.
by mmanciop 1y ago
> As you said "There is so much fun that could be had in setting up an actually resilient system instead.", maybe the author has more fun setting up alerts and metrics instead of a resilient system like you do? Adding the backu
7.
by mmanciop 1y ago
> How are metrics helpful? There is so much fun that could be had in setting up an actually resilient system instead. Metrics are the means to an end of alerting. And with alerting, I mean getting pinged on my phone when something import
8.
by mmanciop 1y ago
I swear I had a lot of fun setting doing the setup. I am also a massive observability nerd, so YMMV :-)
9.
by mmanciop 1y ago
One of the stretch goals for me writing this article was indeed to show between the lines how Prometheus Exporters, the OpenTelemetry Collector and Systemd can all work together. That is a very reusable skill on monitoring workflows running
10.
by mmanciop 1y ago
For this, I have the impression that https://github.com/dirien/minectl might be very close to what you are thinking. I did not try it, but took the Minecraft Exporter from it and used in the setup.
11.
by mmanciop 1y ago
Because I enjoy observability and monitoring a LOT, and because my kids nag me to hell and back when our home IT infrastructure is having a bad day.
12.
by mmanciop 1y ago
I am indeed an employee of Dash0. The setup for telemetry collector will work with anything that accepts OTLP, and with minor adjustments, the data can be sent elsewhere too in other formats, as the OpenTelemetry Collector is very flexible
13.
by mmanciop 1y ago
Thanks for setting me straight :-) I updated the article to reflect that.
14.
Monitoring my Minecraft server with OpenTelemetry and Prometheus(dash0.com)
94 points by mmanciop 1y ago|59 comments
15.
Best practices for Kubernetes metadata in OpenTelemetry(dash0.com)
2 points by mmanciop 2y ago|0 comments
16.
by mmanciop 2y ago
For local development, yes. But I see that almost never done in production settings, especially with containerized workloads. Is there a neat way to do it in Kubernetes?
17.
by mmanciop 2y ago
I loved this article. I am working on an LD_PRELOAD object for some observability usecases, and while there was a learning curve, Zig an its lack of dependence from LibC is a breath of fresh air!
18.
by mmanciop 2y ago
Adopting OpenTelemetry does not have to be hard for common use-cases. On Kubernetes, the Dash0 operator ( https://artifacthub.io/packages/search?repo=dash0-operator ) automatically instruments Node.js and Java workloads
19.
by mmanciop 2y ago
Yes, it probably would be able to do the same logic as in the blogpost with the Prometheus scaler: https://keda.sh/docs/2.16/scalers/prometheus/ I might give it a go in a follow-up :-)
20.
by mmanciop 2y ago
True, but that approach is also limited in what it can autoscale on, namely Utilization metrics. They are not always good data to make scaling decisions on (covered in the article).
21.
Kubernetes horizontal pod autoscaling powered by an OpenTelemetry-native tool(dash0.com)
33 points by mmanciop 2y ago|6 comments
22.
by mmanciop 2y ago
I looked into how to wire the Horizontal Pod Autoscaler for Kubernetes to Dash0, the OpenTelemetry-native observability tool I am working on, and it turned out to be surprising simple.
23.
by mmanciop 2y ago
We explicitly test 1.28+. But I have in front of me a 1.27.13 and the operator works on it without issues. And probably goes way further back than that. What is the oldest version of Kubernetes you have seen in the wild recently? Disclaimer
24.
by mmanciop 2y ago
I can 100% confirm that OpenTelemetry is a fantastic project to get rid of most observability lock-in. For context: I am the Head of Product of Dash0, a recently-launched Observability product 100% based on OpenTelemetry. (And Dash0 is not
25.
by mmanciop 3y ago
And there I thought that being good at scamming was a key skill in crypto. (Nothing personal, but it had to be said.)
26.
by mmanciop 3y ago
The just want tons of moneys
27.
by mmanciop 3y ago
Don’t forget they also urgently needed to paint themselves as victims of the ecosystem they shaped and nurtured for decades.
28.
by mmanciop 3y ago
While the post is mostly correct and one can agree with most of it, it’s very hard to believe that, unless more people pay for RHEL, it would cease to exist. What’s more believable, is that this is a matter of wanting more money for sales t
29.
by mmanciop 3y ago
Translation: we fired a bunch of people, so did everybody. Talent’s no longer scare, and there is a large supply of jobless people that would get your position on a whim. Get fucked.
30.
by mmanciop 3y ago
> Lockheed is dirty while Palantir or Facebook aren’t Said nobody with any common sense, ever. Palanthir or Meta are in my eyes as bad on CV as… as… wait is there a way I don’t go Godwin’s in this thread?

More ›