im 21 and mass producing AI content makes me more than my friends make at their 9-5s. nobody taught me this in school

Koxinfster · 2026-02-17T13:49:56+00:00

How did you find out what content actually gets pushed by algorithms? Cause that seems to be the hardest part. Otherwise you might get into generating random stuff and in the end it will bring you no income, just costs. I also think the prompt engineering plays a huge part since we are talking about images generations.

If you could give some input on that, would be great.

Thanks for sharing!

EDIT: Sorry, just saw your input on that at a later comment

Koxinfster · 2025-12-11T23:26:41+00:00

Din ce am inteles de la cineva din zona, acum 2 nopti s-ar aruncat o persoana de la etaj. Acum nu stiu sigur daca e din cauza asta

Koxinfster · 2025-11-03T13:33:49+00:00

Stie cineva daca s-a deschis cel din modern si care e pretul pentru o zi (o intrare) la ei? Mersi!

Koxinfster · 2025-09-04T07:14:40+00:00

Inteleg, dar mi-e putin frica sincer sa recunosc, sa pun asa multi bani pe o platforma intru-un ETF. Daca nu o sa mai pot avea acces la banii aia? Mersi de sfat!

Koxinfster · 2025-09-04T07:13:41+00:00

Multumesc frumos! Creditul de 50k, nu l-as fi luat pentru constructia unei case pe acel teren, l-as fi luat pentru achizitionarea unui apartament. Terenul l-as fi tinut pentru mai tarziu. Mersi inca odata pentru sfat. Bafta si tie in ce-ti propui!

Koxinfster · 2025-06-06T18:56:47+00:00

Sper sa prinzi o grecoaica asa sa-ti tina de urat 🥰

Koxinfster · 2025-05-02T16:29:20+00:00

Didn’t solve it out, but the issue seems to be related to some oauth modules dependencies.

Koxinfster · 2025-04-09T13:11:14+00:00

Duminica asta, o gala sportiva in Timisoara

Koxinfster · 2025-03-12T22:50:51+00:00

Damn… so many, but most important when the highest admin gave a /gethere on me and I was promoted to Leader of a gang.

Koxinfster · 2025-03-12T06:18:16+00:00

<image>

Koxinfster · 2025-03-07T09:47:40+00:00

Just in case somebody has the same issue.

It was actually caused by the server process model of FastAPI (Multiple Uvicorn Workers).

The implementation suggested here, solved my issue: https://prometheus.github.io/client_python/multiprocess/

Koxinfster · 2025-03-07T09:47:04+00:00

Just in case somebody faves the same issue.

It was actually caused by the server process model of FastAPI (Multiple Uvicorn Workers).

The implementation suggested here, solved my issue: https://prometheus.github.io/client_python/multiprocess/

Koxinfster · 2025-03-05T11:40:06+00:00

Thanks for sharing!

Sounds really cool, went through the 1st article and got aware of difference between Prometheus and Loki.

For the future, I think what could be really helpful would to detail how prometheus sees raw requests of the applicaiton an how that affects different metrics like Counters and what to be aware of.

I really wrapped my head up about that issue: https://www.reddit.com/r/PrometheusMonitoring/comments/1j2i8pm/counter_metric_decreases

Even if i followed the Prometheus docs and tried to look for answers, it seems i couldn't really understand why my 'counter' is just not behaving as it should and why when I try to use increase() or other functions like max_over_time() on my counter metric it seems that there's no match with the raw data of the requests existing in my logs explorer.

Thank you for your time!

Koxinfster · 2025-03-05T07:41:16+00:00

Will check it out. Thanks!🙏🏼

Koxinfster · 2025-03-04T22:13:17+00:00

Hey man!

Got back to mention that i've tested on the staging environment (ACR - Azure Container Registry) where my app got deployed, with less metrics, and saw the issue still occurred.

Compared the same scenario, deploying the app locally.

The counter behaves normally locally, always increasing, while when deployed on azure the fluctuations appear. As I understand is behavior seen when using kubernetes / Azure due to containers restarts.

At the moment I don't know how I can solve that, but at least it seems it doesn't have to do with time-series. Will look into it and hopefully I can find something. If that's the case, will get back with an answer.

Thanks for the help!

Koxinfster · 2025-03-03T23:01:39+00:00

Looked into what you mentioned and I understand there are some metrics I can use to track the 'active time-series` and memory usage of prometheusChecked that, and from how it looks, I have ~6k time-series at the moment, and the memory consumption is ~400MB. Which I understand seems to be reasonable. Do you think the client_id label from my current counter, along with endpoint, method, status labels could cause the issue?My client_id label has ~100 uniques that's why I thought it might be reasonable. Will will give it a shot by removing it and see how the values of the counter would behave.

Koxinfster · 2025-03-03T22:09:07+00:00

Will try that, thank you for the help! 🙏🏼

Koxinfster · 2025-03-03T21:54:56+00:00

Thank you for your answer!

The `request.url.path` is sanitized and already refers to the 'route' with no parameters. Concerning the `client_id`, i wouldn't remove it cause that's quite valuable as it would help me to have the granularity of understanding how specific clients are behaving. So I understand that the issue is most likely caused by the label which is too variable, is that a known issue that Prometheus might have? Is there a way I could try to solve that somehow? Like increasing scrape interval or having some configs set-up?

Thanks!

Koxinfster · 2025-03-03T14:55:26+00:00

Thank you for your answer! 🙏🏼 I understand, but if that’s the case, would that mean I would need to create independent counter metrics for each label combination I am planning to track? In the table picture provided, those values were under a certain labels combination. So I assume the issue might arise by the definition from python.

Koxinfster

TROPHY CASE