So, we're so efficient.
Okay, next one, buddy.
My deana, I do know if you remember last year, we had a pork improvised by someone that
calculated the carbon footprint impact of your eyes as feeds, and whenever you
call Spotify or whatever to listen to your podcast.
Yeah, so I'm talking about something similar, because whenever we make a request,
we actually have carbon footprint, and she's going to talk about how we optimize that,
and not make unnecessary requests.
Thank you.
So, yeah, that's right.
So, basically, we are going to talk about how to reduce all the data load and carbon impact
in sustainability.
So, let's get into it.
I'm a developer experience engineer at Victoria Metrics, and also I'm an open telemetry
member and contributor, and I'm an organizer of Konnative Dismainia, and the
Kolidov CNCF merge for neurodiversity group.
So, when I first heard about, when I first heard about Grease of the Foundation,
actually, that's from me, like a very, very cool.
They have a very, very cool mission.
That is, among the first one, actually, is to minimize the carbon footprint.
So, their objective is to use less physical resources, less energy,
and use that energy more intelligently.
They were established in 2021, but they grew pretty fast.
Last year, actually, I saw the first time presentation from one of their members,
and it was something that really resonated with me, because in observability,
we don't talk that often about sustainability, or we should talk about
sustainability more often.
So, I started to dig around the bits and understand a bit
backtracking to the green softer foundation.
If there are any protocols or standards that talk about, you know, carbon footprint,
or energy, or anything that, you know, could give me some standardization around it.
So, moments that, moments here, there are like three protocols, or three standards.
So, is the one that talks about the green house gas.
A protocol, so this is like a globally recognized foundational framework for measuring
and reporting emissions.
Then is the ISO 14.064, which is an international standard that provides
principles, requirements for the conservation and reporting of greenhouse gas emissions.
At an organizational level, and it's aligned with the first protocol.
And the last one is ISO 14.067, which is a standard of focuses on the carbon footprint
of products across their life cycle, which can be applied to specifics of their products
or service.
So, why is this interesting for developers or why is this interesting for observability?
It's interesting because besides these protocols, the green softer foundation
actually, well, created, they kind of like made up this specification called
softer carbon intensity, which is something that's, it's pretty cool.
And it's used in another CNCF project called Kepler.
That is actually, in simple terms, it measures how much carbon your softer emits per unit of work.
So, I'm not going to stick around too much on it.
I just wanted to make like something really clear.
So, here in this formula, basically, what it says is that the E stands for energy consumed by
the softer for carbon intensity of the energy.
M is the embodied carbon hardware manufacturing lifecycle, and R is the functional unit,
like I don't request user API call.
And the interesting fact here is that the SCI is a rate not a total,
which makes it comparable for a trendable and observable.
So, I found that's really interesting because it would be nice if,
also, it can be applied to observability.
So, if we're getting a bit more creative, I think we can totally map this type of specification
to observability signals.
So, this is like a note for observability people or anyway software developers.
If we are working in this area.
So, another interesting thing is actually the sustainability paradox.
That is actually a personal link with what I'm saying here.
And the sustainability paradox basically is something like,
okay, the systems become more sustainable or more efficient,
and also become cheaper, but in the same time, because they are becoming cheaper,
people tend to use them more.
So, there is an increase in the usage, which drives obviously the carbon footprint.
So, in a way, it's like a rebound effect, or it's also called a J-Bones paradox.
And it's interesting because also it can be applied to observability.
So, the same like, for example, we use observability to measure systems.
So, you know, we are tracking so many things, metrics, logs, traces, etc.
And that will definitely improve our systems reliability optimization.
But in the same time, we'll increase the compute, right?
So, we'll increase the storage, we'll increase the energy consumption,
obviously we'll drive the carbon footprint.
So, unless we are, you know, architectural, if we don't really like,
if you don't have like a proper sustainability, let's say,
a principles or architecture, or anyway, like a roadmap,
how to do this properly, obviously the observability can also backfire.
And right now, I'm going to use something like, I'm going to take a use case
or metrics, because we also have been using specific, let's say, best practices,
also in software, and also related to observability.
So, for example, green coding practices.
So, basically referring to the programming techniques to reduce the in-large memory data structures,
unnecessary loops, or API calls.
Basically, anything that will drive the decrease or the consumption.
Also, focusing on the code bloats, or preventing code bloats,
think about the code inefficiency.
And it's something that we, like from the developer side,
we are trying to focus on the refactoring of the codes,
rewriting the codes to make it simple, maintainable.
Think about, I don't know, instead of running a very bloated PR,
just structure it very simple in many, many chunks that can be run fast
and also solve the lot faster.
Another thing will be the careful usage of external libraries,
because for example, you know, if we are also using libraries,
they come with like pre-build functionality,
and we don't like use lots of the extra features that they come with it.
So, it's kind of like interesting.
I mean, it's like a best practice to be careful when to use those.
And in terms of language choice, we use go for simplicity and efficiency.
This is like across the solutions we are working on,
and we also dock foods, our own observability.
So, we are using the dashboards, we are using the metrics,
we are using specific tools that will show us exactly how our deployments are doing.
When is time, I know, maybe to drive the costs,
and anyway, the monitoring actually helps us as well.
So, because of that, like code refactoring,
because of applying all these sustainability features,
we are actually seeing in the benchmarks,
a lot of reduction in energy,
a lot of reduction in hardware,
which leads to actually improve,
and improve one into the memory,
this space, and we're latency.
So, that's something that definitely,
also has like, you know, like an effect on both side,
because it also provides our products to actually be better and consume less.
And here, I wanted to just show you something you can scan the QR.
So, here, for example,
this is a live playground that you can access
that's from Victorian metrics,
which is an open source project for time series.
That's the base.
And here, we're going to go directly to Cardinalet Explorer,
and I'm just going to have slides here.
Right, so from Cardinalet Explorer,
you can take a look at the metrics that have the highest number of series
that are the most expensive metrics,
basically, there will be the right on top,
and you can also see when there were less requests.
So, for example, you have a metric that is like the first one,
and was never requested that it means probably you don't use it
at all, and you should get rid of it.
Also, you can get into the labels with the highest number of unique values,
and those that come on top are actually the labels
that will multiply the time series,
and will basically drive the Cardinalet CA high up.
And then you could drill down, for example,
into each metric, into the label with the highest number of series,
and understand exactly how your metrics is composed.
So, for example, if you have really a label that's very high,
and is driving the Cardinalet CA up, you can get rid of it, for example.
You can also go to top queries,
or the ones that take the most time to execute,
and we can show, for example, how long did it last.
If it's something that's definitely drives the Cardinalet CA up,
you can troubleshoot around that.
Use your own dashboards on how to prevent this in the future,
obviously go back to the codes and try to refactor a bit.
So, this is like a couple of features that definitely could reduce
the data bloats inside your observability.
So, what other recommendation we use from our side,
obviously is to observe and optimize the cloud resource usage,
the commission, obviously any style or orphaned resources,
anything that you don't use,
don't scale the instances, GPUs, disks, and network,
also use intelligent auto-scaling for Kubernetes managed or serverless platforms,
use the scheduling workloads for off-peak or green regions,
and also use spots and preemption,
preemptible sorry instances for non-critical tasks and batch jobs.
And also, you can also use auto-remove,
inactive test and word-dev resources.
And obviously, if you have in-house deployment,
you can also optimize those.
So, another interesting, let's say, application of sustainability
that I so recently was about Kubernetes.
Actually, it was a talk that was given by
another conference that was quite interesting.
They took actually the nine hours of circular economy
and they applied it to Kubernetes.
So, the nine hours of circular economy,
there are these ones that I published there.
So, it's like to refuse.
So, avoid what you don't need, basically.
We think, use smarter and share more,
reduce, use fewer resources,
and repair, fix instead of replacing,
refurbish, all-stuff,
re-manufacture, rebuild using parts, etc.
So, the whole idea actually was taken.
So, the whole idea of the nine hours in circular economy
was transposed in for Kubernetes.
And the whole thesis was like,
okay, we can take the same hours,
maybe make it into six,
and really make them customize for Kubernetes.
And I think that can definitely be applied
for observability, because it stands,
you know, to the same mission of sustainability.
So, we can try that, for example, in this way.
So, from the nine hours,
we can reduce to six,
to have the refuser, reduce,
repair, resize, reschedule, and repeat.
And we could try to see how it would look like
for observability.
So, for example, to refuse, or reduce,
basically, we don't need to collect the metrics
that we don't need.
So, for example, we have the Cardinal Explorer,
such a tool.
You see, like, you can identify the metrics
that are more expensive,
and basically probably don't need to use.
So, you can think about reducing that
or eliminating those types of metrics
for repairing,
that you could apply fixed noisy alerts,
broken SLOs, inefficient queries.
And for resizing, you can use roll-ups,
those sampling stream aggregation.
And for scheduling, definitely,
you can focus on change when and how often you observe,
and lower the scrape frequency.
That's something you can also see, for example,
if there are metrics, and any other, they say,
observability projects use adaptive sampling
on demand deep diagnostics.
And for repeats, obviously, you can use
reuse-proven signals, queries, dashboards,
alert patterns across services, and teams,
instead of reinventing them.
That will obviously be also very useful
for the team themselves.
So, I was mentioning that the beginning
project and open source project called a Kepler,
and I think this was probably the talk
that was given last year.
So, Kepler is a CNCF project that uses EBPF,
and system counters to estimate energy use of containers,
pods, virtual machines, and processes,
and Kubernetes environment.
It's definitely one of the most interesting projects
of their, in terms of, of using properly,
and reducing the carbon footprint.
It also has, like, very cool dashboards,
and can be used for the specific purpose.
Another, one of my favorite projects
are the moments, is open-cellometry.
That is, the things that doesn't have anything
to do that much with sustainability at the moment,
but because it's linked to the tracing,
collecting telemetry across software systems,
it would be nice if we can also think
in those terms of green observability.
So, open-cellometry for sure here,
the community is helpful for sure.
We can adopt many of, you know,
let's say, principles or many of the projects,
not many of the lessons learned from the projects
that, for example, were given today,
and definitely open-cellometry can help with that.
So, I would like to see a use case for sustainability
within open-cellometry as well.
Another, another open-cellus project
that doesn't have anything to do with open-cellometry.
Sorry, with sustainability,
is actually open-climate fix.
It's a climate like non-profit
using open-cellus AI and machine learning.
It's improved renewable energy forecasting.
And I think it's really nice
in terms of how this type of projects
can influence the observability projects.
In terms of, you know,
we can collect information
or we can exchange ideas
how they are using machine learning,
how they use open-cellus AI to do that
and we can apply them in observability as well.
And another one that has some effects
for observability is cloud carbon footprint,
which is an open-cellus tool to measure monitor
and help reduce the cloud infrastructure carbon emissions.
So, I think because observability
still gets to mature in that sense.
So, it's still yet to take more steps
into sustainability, into the whole energy consumption
and carbon footprint.
We definitely need a lot more help
and a lot more communication.
So, to apply definitely
other practices that were used in other projects.
And obviously, you know,
from Kepler, we can also learn
what they are doing as well.
So, what I wanted to say
the takeaways,
definitely that's not on the board,
but definitely what I would like to see
is the standard that we're in foundation,
which of the foundation created
that we discussed at the beginning
as AI to be applied in observability.
So, it would be something nice to have
definitely something to think about
for example, if the S.E.I. would be an SLI,
the service level indicator for green observability.
That will be something interesting to think about.
Also, I think definitely and at least
in the sustainability meetings
I've been with the community.
Is that observability companies
should start applying this action
since they won?
So, reducing the energy
and definitely think about the energy,
the usage of energy more intelligently,
and sustainability is definitely
something that is breath of company culture.
So, it's definitely something that
a company should think about
and also distributed in terms of
how it's applied by its employees,
developers, etc.
And yes, we are all responsible to maintain it
and you could obviously discuss it
as a homework, as a project,
discuss it with some co-workers,
for example, I've seen other people
come with a GitHub project and discuss it
in sustainability meetings
and this is how everything starts.
Obviously, I left some resources there
and on my GitHub repo,
that was mentioned in the previous
in the first slide,
you could download the presentation
that's here.
And thank you very much.
If you have any questions.
There are five minutes of questions.
No, it's five minutes of questions.
Not per a question, I just want to say
that we use big parameters at the work,
and for example, a teacher that may
make a giant difference is the screening
aggregation.
We had, let's say, two,
sometimes five million samples per second
ingested.
And a lot of that was used less
cardinality from labels that we didn't need.
And with five lines of yam,
we reduced our ingestion rates in half.
Without changing anything,
without having to convince the colleagues
to fix their metrics.
I just changed the yam file
and five minutes later.
So that's one of the questions.
Yeah, thank you.
So yeah, to rate the rate,
basically what was said,
that the use of the work,
big-soyometrics,
and especially stream aggregation,
that basically will reduce
the high cardinality,
you know,
that's the factor of the codes.
Yeah, not worry about having high cardinality.
And thank you for the comments.
Actually, it's an improvement from
primitias.
And yeah, give it a try.
I'm just wondering,
what gives more impact.
Is it the fact that,
we can use,
which is more with the same assets we have,
because if we reduce the traffic,
then we don't have to either
streamline for such a true race traffic,
because we actually can use the same infrastructure.
So the fact that we don't need to upgrade
the hardware has more impact,
than the number of processes
that, as I mentioned,
there was a energy,
how much energy the mic,
the processors are going to use,
is small,
to the amount of energy that you need to
extend your infrastructure.
Yeah, absolutely.
How do you think that,
how do you think the impact
would be,
like, where is it more?
Right.
So if I understand correctly,
it's like,
what's the impact,
what is more noticeable,
if you're actually using the same resources,
instead of actually going for
a new type of architecture,
a new architecture,
and I'm updating that architecture.
Well, you really,
that's why we are also advising
our users,
is used like the minimum,
let's say hardware,
or the minimal set-up
that you think about, right?
So don't go,
oh, I have,
I know I'm just saying I don't know
thousands of metrics,
I need to go for the cluster.
I need to do that.
I have to have a massive architecture.
No, you don't.
Try it with like a single,
notes,
try it with something really simple,
and then understand how everything evolves, right?
So don't jump to the very complicated
architecture just because,
you know,
the company looks big or,
you know,
the ingestion rate,
and think,
think small,
thus with that modest infrastructure,
and definitely think twice in,
you know,
jumping over board and then try to buy new stuff.
It's something that I think it's probably
in the modern days,
but we're all just trying to upgrade or,
you know,
just the next thing that's more shiny and fancy,
or instead of being modest and reuse,
what we have.
And definitely,
we see a lot more in terms of energy.
That's more convenient.
Keep it.