WEBVTT

00:00.000 --> 00:10.000
So, we're so efficient.

00:10.000 --> 00:15.000
Okay, next one, buddy.

00:15.000 --> 00:21.000
My deana, I do know if you remember last year, we had a pork improvised by someone that

00:21.000 --> 00:27.000
calculated the carbon footprint impact of your eyes as feeds, and whenever you

00:27.000 --> 00:34.000
call Spotify or whatever to listen to your podcast.

00:34.000 --> 00:40.000
Yeah, so I'm talking about something similar, because whenever we make a request,

00:40.000 --> 00:45.000
we actually have carbon footprint, and she's going to talk about how we optimize that,

00:45.000 --> 00:47.000
and not make unnecessary requests.

00:47.000 --> 00:48.000
Thank you.

00:48.000 --> 00:49.000
Thank you.

00:49.000 --> 00:51.000
So, yeah, that's right.

00:51.000 --> 00:56.000
So, basically, we are going to talk about how to reduce all the data load and carbon impact

00:56.000 --> 00:58.000
in sustainability.

00:58.000 --> 01:00.000
So, let's get into it.

01:00.000 --> 01:06.000
I'm a developer experience engineer at Victoria Metrics, and also I'm an open telemetry

01:06.000 --> 01:12.000
member and contributor, and I'm an organizer of Konnative Dismainia, and the

01:12.000 --> 01:16.000
Kolidov CNCF merge for neurodiversity group.

01:16.000 --> 01:22.000
So, when I first heard about, when I first heard about Grease of the Foundation,

01:22.000 --> 01:25.000
actually, that's from me, like a very, very cool.

01:25.000 --> 01:28.000
They have a very, very cool mission.

01:28.000 --> 01:33.000
That is, among the first one, actually, is to minimize the carbon footprint.

01:33.000 --> 01:39.000
So, their objective is to use less physical resources, less energy,

01:39.000 --> 01:43.000
and use that energy more intelligently.

01:43.000 --> 01:50.000
They were established in 2021, but they grew pretty fast.

01:50.000 --> 01:55.000
Last year, actually, I saw the first time presentation from one of their members,

01:55.000 --> 01:59.000
and it was something that really resonated with me, because in observability,

01:59.000 --> 02:04.000
we don't talk that often about sustainability, or we should talk about

02:04.000 --> 02:07.000
sustainability more often.

02:07.000 --> 02:11.000
So, I started to dig around the bits and understand a bit

02:11.000 --> 02:14.000
backtracking to the green softer foundation.

02:14.000 --> 02:19.000
If there are any protocols or standards that talk about, you know, carbon footprint,

02:19.000 --> 02:25.000
or energy, or anything that, you know, could give me some standardization around it.

02:25.000 --> 02:31.000
So, moments that, moments here, there are like three protocols, or three standards.

02:31.000 --> 02:35.000
So, is the one that talks about the green house gas.

02:35.000 --> 02:41.000
A protocol, so this is like a globally recognized foundational framework for measuring

02:41.000 --> 02:43.000
and reporting emissions.

02:43.000 --> 02:50.000
Then is the ISO 14.064, which is an international standard that provides

02:50.000 --> 02:57.000
principles, requirements for the conservation and reporting of greenhouse gas emissions.

02:57.000 --> 03:03.000
At an organizational level, and it's aligned with the first protocol.

03:03.000 --> 03:10.000
And the last one is ISO 14.067, which is a standard of focuses on the carbon footprint

03:10.000 --> 03:16.000
of products across their life cycle, which can be applied to specifics of their products

03:16.000 --> 03:17.000
or service.

03:17.000 --> 03:25.000
So, why is this interesting for developers or why is this interesting for observability?

03:25.000 --> 03:30.000
It's interesting because besides these protocols, the green softer foundation

03:30.000 --> 03:36.000
actually, well, created, they kind of like made up this specification called

03:36.000 --> 03:42.000
softer carbon intensity, which is something that's, it's pretty cool.

03:42.000 --> 03:48.000
And it's used in another CNCF project called Kepler.

03:48.000 --> 03:56.000
That is actually, in simple terms, it measures how much carbon your softer emits per unit of work.

03:56.000 --> 03:59.000
So, I'm not going to stick around too much on it.

03:59.000 --> 04:03.000
I just wanted to make like something really clear.

04:03.000 --> 04:12.000
So, here in this formula, basically, what it says is that the E stands for energy consumed by

04:12.000 --> 04:16.000
the softer for carbon intensity of the energy.

04:16.000 --> 04:23.000
M is the embodied carbon hardware manufacturing lifecycle, and R is the functional unit,

04:23.000 --> 04:27.000
like I don't request user API call.

04:27.000 --> 04:32.000
And the interesting fact here is that the SCI is a rate not a total,

04:32.000 --> 04:37.000
which makes it comparable for a trendable and observable.

04:37.000 --> 04:41.000
So, I found that's really interesting because it would be nice if,

04:41.000 --> 04:44.000
also, it can be applied to observability.

04:44.000 --> 04:50.000
So, if we're getting a bit more creative, I think we can totally map this type of specification

04:50.000 --> 04:53.000
to observability signals.

04:54.000 --> 04:59.000
So, this is like a note for observability people or anyway software developers.

04:59.000 --> 05:05.000
If we are working in this area.

05:05.000 --> 05:12.000
So, another interesting thing is actually the sustainability paradox.

05:12.000 --> 05:16.000
That is actually a personal link with what I'm saying here.

05:16.000 --> 05:19.000
And the sustainability paradox basically is something like,

05:19.000 --> 05:24.000
okay, the systems become more sustainable or more efficient,

05:24.000 --> 05:28.000
and also become cheaper, but in the same time, because they are becoming cheaper,

05:28.000 --> 05:30.000
people tend to use them more.

05:30.000 --> 05:35.000
So, there is an increase in the usage, which drives obviously the carbon footprint.

05:35.000 --> 05:41.000
So, in a way, it's like a rebound effect, or it's also called a J-Bones paradox.

05:41.000 --> 05:46.000
And it's interesting because also it can be applied to observability.

05:47.000 --> 05:52.000
So, the same like, for example, we use observability to measure systems.

05:52.000 --> 05:58.000
So, you know, we are tracking so many things, metrics, logs, traces, etc.

05:58.000 --> 06:04.000
And that will definitely improve our systems reliability optimization.

06:04.000 --> 06:09.000
But in the same time, we'll increase the compute, right?

06:09.000 --> 06:12.000
So, we'll increase the storage, we'll increase the energy consumption,

06:12.000 --> 06:15.000
obviously we'll drive the carbon footprint.

06:16.000 --> 06:22.000
So, unless we are, you know, architectural, if we don't really like,

06:22.000 --> 06:27.000
if you don't have like a proper sustainability, let's say,

06:27.000 --> 06:33.000
a principles or architecture, or anyway, like a roadmap,

06:33.000 --> 06:38.000
how to do this properly, obviously the observability can also backfire.

06:38.000 --> 06:43.000
And right now, I'm going to use something like, I'm going to take a use case

06:43.000 --> 06:50.000
or metrics, because we also have been using specific, let's say, best practices,

06:50.000 --> 06:54.000
also in software, and also related to observability.

06:54.000 --> 06:59.000
So, for example, green coding practices.

06:59.000 --> 07:06.000
So, basically referring to the programming techniques to reduce the in-large memory data structures,

07:06.000 --> 07:09.000
unnecessary loops, or API calls.

07:09.000 --> 07:14.000
Basically, anything that will drive the decrease or the consumption.

07:14.000 --> 07:19.000
Also, focusing on the code bloats, or preventing code bloats,

07:19.000 --> 07:22.000
think about the code inefficiency.

07:22.000 --> 07:26.000
And it's something that we, like from the developer side,

07:26.000 --> 07:29.000
we are trying to focus on the refactoring of the codes,

07:29.000 --> 07:32.000
rewriting the codes to make it simple, maintainable.

07:32.000 --> 07:36.000
Think about, I don't know, instead of running a very bloated PR,

07:36.000 --> 07:41.000
just structure it very simple in many, many chunks that can be run fast

07:41.000 --> 07:44.000
and also solve the lot faster.

07:44.000 --> 07:49.000
Another thing will be the careful usage of external libraries,

07:49.000 --> 07:55.000
because for example, you know, if we are also using libraries,

07:55.000 --> 07:58.000
they come with like pre-build functionality,

07:58.000 --> 08:02.000
and we don't like use lots of the extra features that they come with it.

08:03.000 --> 08:05.000
So, it's kind of like interesting.

08:05.000 --> 08:09.000
I mean, it's like a best practice to be careful when to use those.

08:09.000 --> 08:15.000
And in terms of language choice, we use go for simplicity and efficiency.

08:15.000 --> 08:19.000
This is like across the solutions we are working on,

08:19.000 --> 08:23.000
and we also dock foods, our own observability.

08:23.000 --> 08:27.000
So, we are using the dashboards, we are using the metrics,

08:28.000 --> 08:35.000
we are using specific tools that will show us exactly how our deployments are doing.

08:35.000 --> 08:38.000
When is time, I know, maybe to drive the costs,

08:38.000 --> 08:44.000
and anyway, the monitoring actually helps us as well.

08:44.000 --> 08:48.000
So, because of that, like code refactoring,

08:48.000 --> 08:52.000
because of applying all these sustainability features,

08:52.000 --> 08:55.000
we are actually seeing in the benchmarks,

08:55.000 --> 08:58.000
a lot of reduction in energy,

08:58.000 --> 09:00.000
a lot of reduction in hardware,

09:00.000 --> 09:03.000
which leads to actually improve,

09:03.000 --> 09:06.000
and improve one into the memory,

09:06.000 --> 09:08.000
this space, and we're latency.

09:08.000 --> 09:11.000
So, that's something that definitely,

09:11.000 --> 09:15.000
also has like, you know, like an effect on both side,

09:15.000 --> 09:21.000
because it also provides our products to actually be better and consume less.

09:22.000 --> 09:27.000
And here, I wanted to just show you something you can scan the QR.

09:32.000 --> 09:34.000
So, here, for example,

09:34.000 --> 09:38.000
this is a live playground that you can access

09:38.000 --> 09:40.000
that's from Victorian metrics,

09:40.000 --> 09:44.000
which is an open source project for time series.

09:44.000 --> 09:46.000
That's the base.

09:46.000 --> 09:50.000
And here, we're going to go directly to Cardinalet Explorer,

09:50.000 --> 09:53.000
and I'm just going to have slides here.

09:56.000 --> 09:58.000
Right, so from Cardinalet Explorer,

09:58.000 --> 10:03.000
you can take a look at the metrics that have the highest number of series

10:03.000 --> 10:05.000
that are the most expensive metrics,

10:05.000 --> 10:07.000
basically, there will be the right on top,

10:07.000 --> 10:10.000
and you can also see when there were less requests.

10:10.000 --> 10:13.000
So, for example, you have a metric that is like the first one,

10:13.000 --> 10:17.000
and was never requested that it means probably you don't use it

10:17.000 --> 10:19.000
at all, and you should get rid of it.

10:19.000 --> 10:23.000
Also, you can get into the labels with the highest number of unique values,

10:23.000 --> 10:26.000
and those that come on top are actually the labels

10:26.000 --> 10:29.000
that will multiply the time series,

10:29.000 --> 10:33.000
and will basically drive the Cardinalet CA high up.

10:33.000 --> 10:35.000
And then you could drill down, for example,

10:35.000 --> 10:40.000
into each metric, into the label with the highest number of series,

10:40.000 --> 10:43.000
and understand exactly how your metrics is composed.

10:43.000 --> 10:48.000
So, for example, if you have really a label that's very high,

10:48.000 --> 10:52.000
and is driving the Cardinalet CA up, you can get rid of it, for example.

10:52.000 --> 10:55.000
You can also go to top queries,

10:55.000 --> 10:59.000
or the ones that take the most time to execute,

10:59.000 --> 11:05.000
and we can show, for example, how long did it last.

11:05.000 --> 11:09.000
If it's something that's definitely drives the Cardinalet CA up,

11:09.000 --> 11:12.000
you can troubleshoot around that.

11:12.000 --> 11:16.000
Use your own dashboards on how to prevent this in the future,

11:16.000 --> 11:21.000
obviously go back to the codes and try to refactor a bit.

11:21.000 --> 11:27.000
So, this is like a couple of features that definitely could reduce

11:27.000 --> 11:32.000
the data bloats inside your observability.

11:32.000 --> 11:38.000
So, what other recommendation we use from our side,

11:38.000 --> 11:43.000
obviously is to observe and optimize the cloud resource usage,

11:43.000 --> 11:47.000
the commission, obviously any style or orphaned resources,

11:47.000 --> 11:49.000
anything that you don't use,

11:49.000 --> 11:54.000
don't scale the instances, GPUs, disks, and network,

11:54.000 --> 12:01.000
also use intelligent auto-scaling for Kubernetes managed or serverless platforms,

12:01.000 --> 12:06.000
use the scheduling workloads for off-peak or green regions,

12:06.000 --> 12:09.000
and also use spots and preemption,

12:09.000 --> 12:15.000
preemptible sorry instances for non-critical tasks and batch jobs.

12:15.000 --> 12:19.000
And also, you can also use auto-remove,

12:19.000 --> 12:22.000
inactive test and word-dev resources.

12:22.000 --> 12:25.000
And obviously, if you have in-house deployment,

12:25.000 --> 12:28.000
you can also optimize those.

12:28.000 --> 12:43.000
So, another interesting, let's say, application of sustainability

12:43.000 --> 12:47.000
that I so recently was about Kubernetes.

12:47.000 --> 12:50.000
Actually, it was a talk that was given by

12:50.000 --> 12:53.000
another conference that was quite interesting.

12:53.000 --> 12:57.000
They took actually the nine hours of circular economy

12:57.000 --> 12:59.000
and they applied it to Kubernetes.

12:59.000 --> 13:01.000
So, the nine hours of circular economy,

13:01.000 --> 13:05.000
there are these ones that I published there.

13:05.000 --> 13:07.000
So, it's like to refuse.

13:07.000 --> 13:10.000
So, avoid what you don't need, basically.

13:10.000 --> 13:13.000
We think, use smarter and share more,

13:13.000 --> 13:16.000
reduce, use fewer resources,

13:16.000 --> 13:20.000
and repair, fix instead of replacing,

13:20.000 --> 13:23.000
refurbish, all-stuff,

13:23.000 --> 13:27.000
re-manufacture, rebuild using parts, etc.

13:27.000 --> 13:31.000
So, the whole idea actually was taken.

13:31.000 --> 13:34.000
So, the whole idea of the nine hours in circular economy

13:34.000 --> 13:37.000
was transposed in for Kubernetes.

13:37.000 --> 13:39.000
And the whole thesis was like,

13:39.000 --> 13:41.000
okay, we can take the same hours,

13:41.000 --> 13:43.000
maybe make it into six,

13:43.000 --> 13:47.000
and really make them customize for Kubernetes.

13:47.000 --> 13:51.000
And I think that can definitely be applied

13:51.000 --> 13:53.000
for observability, because it stands,

13:53.000 --> 13:57.000
you know, to the same mission of sustainability.

13:57.000 --> 14:01.000
So, we can try that, for example, in this way.

14:01.000 --> 14:03.000
So, from the nine hours,

14:03.000 --> 14:06.000
we can reduce to six,

14:06.000 --> 14:08.000
to have the refuser, reduce,

14:08.000 --> 14:12.000
repair, resize, reschedule, and repeat.

14:12.000 --> 14:15.000
And we could try to see how it would look like

14:15.000 --> 14:18.000
for observability.

14:19.000 --> 14:22.000
So, for example, to refuse, or reduce,

14:22.000 --> 14:25.000
basically, we don't need to collect the metrics

14:25.000 --> 14:27.000
that we don't need.

14:27.000 --> 14:29.000
So, for example, we have the Cardinal Explorer,

14:29.000 --> 14:30.000
such a tool.

14:30.000 --> 14:32.000
You see, like, you can identify the metrics

14:32.000 --> 14:34.000
that are more expensive,

14:34.000 --> 14:37.000
and basically probably don't need to use.

14:37.000 --> 14:40.000
So, you can think about reducing that

14:40.000 --> 14:43.000
or eliminating those types of metrics

14:43.000 --> 14:47.000
for repairing,

14:47.000 --> 14:50.000
that you could apply fixed noisy alerts,

14:50.000 --> 14:54.000
broken SLOs, inefficient queries.

14:54.000 --> 14:57.000
And for resizing, you can use roll-ups,

14:57.000 --> 15:02.000
those sampling stream aggregation.

15:02.000 --> 15:05.000
And for scheduling, definitely,

15:05.000 --> 15:09.000
you can focus on change when and how often you observe,

15:09.000 --> 15:11.000
and lower the scrape frequency.

15:11.000 --> 15:14.000
That's something you can also see, for example,

15:14.000 --> 15:17.000
if there are metrics, and any other, they say,

15:17.000 --> 15:22.000
observability projects use adaptive sampling

15:22.000 --> 15:25.000
on demand deep diagnostics.

15:25.000 --> 15:28.000
And for repeats, obviously, you can use

15:28.000 --> 15:32.000
reuse-proven signals, queries, dashboards,

15:32.000 --> 15:35.000
alert patterns across services, and teams,

15:35.000 --> 15:37.000
instead of reinventing them.

15:37.000 --> 15:40.000
That will obviously be also very useful

15:40.000 --> 15:43.000
for the team themselves.

15:44.000 --> 15:47.000
So, I was mentioning that the beginning

15:47.000 --> 15:51.000
project and open source project called a Kepler,

15:51.000 --> 15:55.000
and I think this was probably the talk

15:55.000 --> 15:58.000
that was given last year.

15:58.000 --> 16:07.000
So, Kepler is a CNCF project that uses EBPF,

16:07.000 --> 16:11.000
and system counters to estimate energy use of containers,

16:11.000 --> 16:14.000
pods, virtual machines, and processes,

16:14.000 --> 16:16.000
and Kubernetes environment.

16:16.000 --> 16:20.000
It's definitely one of the most interesting projects

16:20.000 --> 16:24.000
of their, in terms of, of using properly,

16:24.000 --> 16:26.000
and reducing the carbon footprint.

16:26.000 --> 16:29.000
It also has, like, very cool dashboards,

16:29.000 --> 16:34.000
and can be used for the specific purpose.

16:34.000 --> 16:38.000
Another, one of my favorite projects

16:38.000 --> 16:40.000
are the moments, is open-cellometry.

16:40.000 --> 16:43.000
That is, the things that doesn't have anything

16:43.000 --> 16:46.000
to do that much with sustainability at the moment,

16:46.000 --> 16:49.000
but because it's linked to the tracing,

16:49.000 --> 16:52.000
collecting telemetry across software systems,

16:52.000 --> 16:55.000
it would be nice if we can also think

16:55.000 --> 16:58.000
in those terms of green observability.

16:58.000 --> 17:00.000
So, open-cellometry for sure here,

17:00.000 --> 17:03.000
the community is helpful for sure.

17:03.000 --> 17:05.000
We can adopt many of, you know,

17:06.000 --> 17:10.000
let's say, principles or many of the projects,

17:10.000 --> 17:13.000
not many of the lessons learned from the projects

17:13.000 --> 17:16.000
that, for example, were given today,

17:16.000 --> 17:19.000
and definitely open-cellometry can help with that.

17:19.000 --> 17:23.000
So, I would like to see a use case for sustainability

17:23.000 --> 17:26.000
within open-cellometry as well.

17:26.000 --> 17:31.000
Another, another open-cellus project

17:31.000 --> 17:34.000
that doesn't have anything to do with open-cellometry.

17:34.000 --> 17:36.000
Sorry, with sustainability,

17:36.000 --> 17:39.000
is actually open-climate fix.

17:39.000 --> 17:41.000
It's a climate like non-profit

17:41.000 --> 17:44.000
using open-cellus AI and machine learning.

17:44.000 --> 17:47.000
It's improved renewable energy forecasting.

17:47.000 --> 17:50.000
And I think it's really nice

17:50.000 --> 17:53.000
in terms of how this type of projects

17:53.000 --> 17:56.000
can influence the observability projects.

17:56.000 --> 17:58.000
In terms of, you know,

17:58.000 --> 18:00.000
we can collect information

18:00.000 --> 18:02.000
or we can exchange ideas

18:02.000 --> 18:04.000
how they are using machine learning,

18:04.000 --> 18:06.000
how they use open-cellus AI to do that

18:06.000 --> 18:10.000
and we can apply them in observability as well.

18:10.000 --> 18:15.000
And another one that has some effects

18:15.000 --> 18:19.000
for observability is cloud carbon footprint,

18:19.000 --> 18:22.000
which is an open-cellus tool to measure monitor

18:22.000 --> 18:26.000
and help reduce the cloud infrastructure carbon emissions.

18:26.000 --> 18:29.000
So, I think because observability

18:30.000 --> 18:33.000
still gets to mature in that sense.

18:33.000 --> 18:35.000
So, it's still yet to take more steps

18:35.000 --> 18:40.000
into sustainability, into the whole energy consumption

18:40.000 --> 18:42.000
and carbon footprint.

18:42.000 --> 18:44.000
We definitely need a lot more help

18:44.000 --> 18:46.000
and a lot more communication.

18:46.000 --> 18:49.000
So, to apply definitely

18:49.000 --> 18:52.000
other practices that were used in other projects.

18:52.000 --> 18:55.000
And obviously, you know,

18:55.000 --> 18:58.000
from Kepler, we can also learn

18:58.000 --> 19:01.000
what they are doing as well.

19:01.000 --> 19:04.000
So, what I wanted to say

19:04.000 --> 19:06.000
the takeaways,

19:06.000 --> 19:08.000
definitely that's not on the board,

19:08.000 --> 19:10.000
but definitely what I would like to see

19:10.000 --> 19:13.000
is the standard that we're in foundation,

19:13.000 --> 19:15.000
which of the foundation created

19:15.000 --> 19:17.000
that we discussed at the beginning

19:17.000 --> 19:21.000
as AI to be applied in observability.

19:21.000 --> 19:24.000
So, it would be something nice to have

19:24.000 --> 19:27.000
definitely something to think about

19:28.000 --> 19:32.000
for example, if the S.E.I. would be an SLI,

19:32.000 --> 19:35.000
the service level indicator for green observability.

19:35.000 --> 19:39.000
That will be something interesting to think about.

19:39.000 --> 19:42.000
Also, I think definitely and at least

19:42.000 --> 19:44.000
in the sustainability meetings

19:44.000 --> 19:46.000
I've been with the community.

19:46.000 --> 19:48.000
Is that observability companies

19:48.000 --> 19:51.000
should start applying this action

19:51.000 --> 19:52.000
since they won?

19:52.000 --> 19:54.000
So, reducing the energy

19:54.000 --> 19:57.000
and definitely think about the energy,

19:57.000 --> 20:00.000
the usage of energy more intelligently,

20:00.000 --> 20:03.000
and sustainability is definitely

20:03.000 --> 20:06.000
something that is breath of company culture.

20:06.000 --> 20:08.000
So, it's definitely something that

20:08.000 --> 20:11.000
a company should think about

20:11.000 --> 20:13.000
and also distributed in terms of

20:13.000 --> 20:16.000
how it's applied by its employees,

20:16.000 --> 20:18.000
developers, etc.

20:18.000 --> 20:22.000
And yes, we are all responsible to maintain it

20:22.000 --> 20:24.000
and you could obviously discuss it

20:24.000 --> 20:27.000
as a homework, as a project,

20:27.000 --> 20:29.000
discuss it with some co-workers,

20:29.000 --> 20:31.000
for example, I've seen other people

20:31.000 --> 20:34.000
come with a GitHub project and discuss it

20:34.000 --> 20:36.000
in sustainability meetings

20:36.000 --> 20:39.000
and this is how everything starts.

20:39.000 --> 20:42.000
Obviously, I left some resources there

20:42.000 --> 20:45.000
and on my GitHub repo,

20:45.000 --> 20:47.000
that was mentioned in the previous

20:47.000 --> 20:48.000
in the first slide,

20:48.000 --> 20:50.000
you could download the presentation

20:50.000 --> 20:52.000
that's here.

20:52.000 --> 20:53.000
And thank you very much.

20:53.000 --> 20:55.000
If you have any questions.

20:55.000 --> 21:05.000
There are five minutes of questions.

21:05.000 --> 21:15.000
No, it's five minutes of questions.

21:15.000 --> 21:18.000
Not per a question, I just want to say

21:18.000 --> 21:20.000
that we use big parameters at the work,

21:20.000 --> 21:22.000
and for example, a teacher that may

21:22.000 --> 21:24.000
make a giant difference is the screening

21:24.000 --> 21:26.000
aggregation.

21:26.000 --> 21:29.000
We had, let's say, two,

21:29.000 --> 21:32.000
sometimes five million samples per second

21:32.000 --> 21:33.000
ingested.

21:33.000 --> 21:35.000
And a lot of that was used less

21:35.000 --> 21:37.000
cardinality from labels that we didn't need.

21:37.000 --> 21:40.000
And with five lines of yam,

21:40.000 --> 21:44.000
we reduced our ingestion rates in half.

21:44.000 --> 21:46.000
Without changing anything,

21:46.000 --> 21:48.000
without having to convince the colleagues

21:48.000 --> 21:51.000
to fix their metrics.

21:51.000 --> 21:54.000
I just changed the yam file

21:54.000 --> 21:57.000
and five minutes later.

21:57.000 --> 22:01.000
So that's one of the questions.

22:01.000 --> 22:03.000
Yeah, thank you.

22:03.000 --> 22:05.000
So yeah, to rate the rate,

22:05.000 --> 22:07.000
basically what was said,

22:07.000 --> 22:09.000
that the use of the work,

22:09.000 --> 22:10.000
big-soyometrics,

22:10.000 --> 22:12.000
and especially stream aggregation,

22:12.000 --> 22:14.000
that basically will reduce

22:14.000 --> 22:16.000
the high cardinality,

22:16.000 --> 22:17.000
you know,

22:17.000 --> 22:19.000
that's the factor of the codes.

22:19.000 --> 22:24.000
Yeah, not worry about having high cardinality.

22:24.000 --> 22:26.000
And thank you for the comments.

22:26.000 --> 22:28.000
Actually, it's an improvement from

22:28.000 --> 22:29.000
primitias.

22:29.000 --> 22:32.000
And yeah, give it a try.

22:32.000 --> 22:35.000
I'm just wondering,

22:35.000 --> 22:38.000
what gives more impact.

22:38.000 --> 22:40.000
Is it the fact that,

22:40.000 --> 22:44.000
we can use,

22:44.000 --> 22:47.000
which is more with the same assets we have,

22:47.000 --> 22:49.000
because if we reduce the traffic,

22:49.000 --> 22:51.000
then we don't have to either

22:51.000 --> 22:53.000
streamline for such a true race traffic,

22:53.000 --> 22:56.000
because we actually can use the same infrastructure.

22:56.000 --> 22:58.000
So the fact that we don't need to upgrade

22:58.000 --> 23:00.000
the hardware has more impact,

23:00.000 --> 23:03.000
than the number of processes

23:03.000 --> 23:04.000
that, as I mentioned,

23:04.000 --> 23:05.000
there was a energy,

23:05.000 --> 23:08.000
how much energy the mic,

23:08.000 --> 23:10.000
the processors are going to use,

23:10.000 --> 23:11.000
is small,

23:11.000 --> 23:14.000
to the amount of energy that you need to

23:14.000 --> 23:16.000
extend your infrastructure.

23:16.000 --> 23:17.000
Yeah, absolutely.

23:17.000 --> 23:19.000
How do you think that,

23:19.000 --> 23:20.000
how do you think the impact

23:20.000 --> 23:21.000
would be,

23:21.000 --> 23:23.000
like, where is it more?

23:23.000 --> 23:24.000
Right.

23:24.000 --> 23:26.000
So if I understand correctly,

23:26.000 --> 23:27.000
it's like,

23:27.000 --> 23:28.000
what's the impact,

23:28.000 --> 23:30.000
what is more noticeable,

23:30.000 --> 23:33.000
if you're actually using the same resources,

23:33.000 --> 23:36.000
instead of actually going for

23:36.000 --> 23:37.000
a new type of architecture,

23:37.000 --> 23:38.000
a new architecture,

23:38.000 --> 23:40.000
and I'm updating that architecture.

23:40.000 --> 23:42.000
Well, you really,

23:42.000 --> 23:45.000
that's why we are also advising

23:45.000 --> 23:47.000
our users,

23:47.000 --> 23:50.000
is used like the minimum,

23:50.000 --> 23:52.000
let's say hardware,

23:52.000 --> 23:54.000
or the minimal set-up

23:54.000 --> 23:56.000
that you think about, right?

23:56.000 --> 23:57.000
So don't go,

23:57.000 --> 23:58.000
oh, I have,

23:58.000 --> 24:00.000
I know I'm just saying I don't know

24:00.000 --> 24:01.000
thousands of metrics,

24:01.000 --> 24:03.000
I need to go for the cluster.

24:03.000 --> 24:04.000
I need to do that.

24:04.000 --> 24:06.000
I have to have a massive architecture.

24:06.000 --> 24:07.000
No, you don't.

24:07.000 --> 24:09.000
Try it with like a single,

24:09.000 --> 24:10.000
notes,

24:10.000 --> 24:12.000
try it with something really simple,

24:12.000 --> 24:15.000
and then understand how everything evolves, right?

24:15.000 --> 24:18.000
So don't jump to the very complicated

24:18.000 --> 24:20.000
architecture just because,

24:20.000 --> 24:21.000
you know,

24:21.000 --> 24:23.000
the company looks big or,

24:23.000 --> 24:24.000
you know,

24:24.000 --> 24:25.000
the ingestion rate,

24:25.000 --> 24:26.000
and think,

24:26.000 --> 24:27.000
think small,

24:27.000 --> 24:29.000
thus with that modest infrastructure,

24:29.000 --> 24:31.000
and definitely think twice in,

24:31.000 --> 24:32.000
you know,

24:32.000 --> 24:35.000
jumping over board and then try to buy new stuff.

24:35.000 --> 24:37.000
It's something that I think it's probably

24:37.000 --> 24:38.000
in the modern days,

24:38.000 --> 24:40.000
but we're all just trying to upgrade or,

24:40.000 --> 24:41.000
you know,

24:41.000 --> 24:43.000
just the next thing that's more shiny and fancy,

24:43.000 --> 24:46.000
or instead of being modest and reuse,

24:46.000 --> 24:47.000
what we have.

24:47.000 --> 24:48.000
And definitely,

24:48.000 --> 24:51.000
we see a lot more in terms of energy.

24:51.000 --> 24:53.000
That's more convenient.

24:53.000 --> 24:54.000
Keep it.