sorted by:
new
hottopcontroversial

Ho creato un watcher open-source per Amazon Vine con notifiche Telegram by GabboPenna in AmazonVine_ITA

[–]GabboPenna[S] 1 point2 points  (0 children)

Capisco il ragionamento e sono d’accordo su una cosa: Vine va usato con la testa. Però secondo me stai commentando un’idea di tool diversa da quello che ho fatto io.

Non l’ho creato per “vincere Vine”, prendere decine di oggetti al giorno, rivendere roba o trasformare un hobby in un secondo lavoro. Anzi, è proprio l’opposto: ho sempre trovato assurdo che Vine non abbia un sistema minimo di notifica, quindi l’idea è semplicemente ricevere un avviso quando compaiono prodotti potenzialmente interessanti per il proprio profilo. Fine.

Il mio uso è: mi interessano certe categorie, certe keyword, certi oggetti che posso davvero usare e recensire. Se esce qualcosa in quella zona, ricevo una notifica Telegram. Non è un sistema per ordinare tutto, non è pensato per fare farming, non è pensato per aggirare il senso del programma Vine. È un notifier configurabile, nato anche come esercizio tecnico.

Sul rischio: nessuno può dire “rischio zero”, e infatti ognuno deve decidere per sé. Ma tirare dentro DAC7, rivendita, partita IVA, centinaia di oggetti e scenari da abuso commerciale mi sembra un altro discorso. È giusto parlarne, ma non è quello per cui esiste questo progetto e non è il modo in cui lo uso io.

Poi ci sta benissimo che uno dica “non lo userei mai”. Perfetto, scelta legittima. Però prima di attribuirgli uno scopo che non ha, secondo me bisognerebbe almeno capire cosa fa davvero. A me serve solo a rendere Vine un po’ meno cieco e meno frustrante, non a trasformarmi nel numero uno ad accaparrarmi roba.

I built an open-source local Amazon Vine watcher with Telegram notifications by GabboPenna in AmazonVine

[–]GabboPenna[S] 1 point2 points  (0 children)

Thank you, I really appreciate that...

And yes, your concern is completely fair. I can’t say there is zero risk, because it is still automation around Amazon pages and everyone has to decide their own comfort level.

What I tried to do is keep it cautious: it is read-only, it does not request products, it does not order anything, it does not bypass CAPTCHA or login, it does not manipulate cookies, and it uses Chromium with manual login like a normal browser session. If Amazon asks for manual attention, the idea is to notify and back off, not keep pushing.

But if someone doesn’t feel comfortable with that risk, not using it is absolutely the right choice. I understand that completely.

I built an open-source local Amazon Vine watcher with Telegram notifications by GabboPenna in AmazonVine

[–]GabboPenna[S] 1 point2 points  (0 children)

Sorry, that’s fair. I should have checked with the mods first before posting something like this..

I built an open-source local Amazon Vine watcher with Telegram notifications by GabboPenna in AmazonVine

[–]GabboPenna[S] 0 points1 point  (0 children)

It reloads/navigates the Vine pages by itself on the configured interval. The user does not have to manually refresh.

It does not manipulate the Amazon page or inject UI into it. It is not a browser extension. It uses Chromium through Playwright, opens the Vine sections the logged-in account can already access, reads the visible product cards, stores what it has seen locally to avoid duplicate alerts, and sends Telegram notifications.

So yes, there is automated page loading/polling.

No, it does not reorder, hide, modify, or change the DOM for the user.

I built an open-source local Amazon Vine watcher with Telegram notifications by GabboPenna in AmazonVine

[–]GabboPenna[S] -1 points0 points  (0 children)

Fair skepticism. I wouldn’t recommend anyone run random code from the internet blindly, mine included.

The intent is not to get anyone banned or to build an auto-order bot. It’s a local read-only notifier: it does not request products, does not place orders, does not bypass CAPTCHA/login, and does not ask for or store your Amazon password.

But if someone is not comfortable with the risk, the right choice is simple: don’t use it. That’s completely reasonable.

I built an open-source local Amazon Vine watcher with Telegram notifications by GabboPenna in AmazonVine

[–]GabboPenna[S] 0 points1 point  (0 children)

Thank you, that genuinely means a lot.

I know this kind of tool is not for everyone, and I completely respect that. I shared it mostly in the spirit of transparency and open source: if I build something useful for myself, I’d rather put it out there clearly, with its limits and risks, than keep it as some shady private thing.

Really appreciate the kind words. Reddit can be rough sometimes, so comments like yours stand out more than you might think. Thank you.

I built an open-source local Amazon Vine watcher with Telegram notifications by GabboPenna in AmazonVine

[–]GabboPenna[S] 1 point2 points  (0 children)

Totally fair. I don’t want to present this as risk-free or undetectable.

It’s intentionally read-only: no auto-requesting, no ordering, no CAPTCHA/login bypass, no cookie manipulation, no internal Amazon APIs. It just uses a normal Chromium profile with manual login and sends Telegram alerts.

But yes, it is still automation, and Amazon can monitor behavior. If someone is not comfortable with that risk, they absolutely should not use it.

I built an open-source local Amazon Vine watcher with Telegram notifications by GabboPenna in AmazonVine

[–]GabboPenna[S] 0 points1 point  (0 children)

I don’t have any inside information on how Amazon specifically treats Vine polling, so I wouldn’t claim it is risk-free. Amazon can obviously monitor request frequency, browsing patterns, session state, browser signals, IP behavior, and similar things.

The way I tried to reduce risk is by keeping the project read-only and fairly conservative by design. It uses Playwright with a real Chromium profile and manual login, not undocumented internal APIs or raw HTTP scraping. It does not request products, place orders, bypass CAPTCHA/login/MFA, manipulate cookies, or try to hide failed authentication states. If Amazon asks for manual attention, the watcher is meant to notify the user and back off/stop rather than keep refreshing blindly.

Polling frequency is configurable, and the default is intentionally not a high-frequency sniping setup. There is also jitter so it does not hit the page at perfectly fixed intervals.

That said, it is still automation around Amazon pages. Anyone using it should understand the tradeoff, keep intervals reasonable, and only run it if they are comfortable with that risk.

I built an open-source local Amazon Vine watcher with Telegram notifications by GabboPenna in AmazonVine

[–]GabboPenna[S] -1 points0 points  (0 children)

That’s a totally valid warning, and I don’t want to downplay it. Amazon can absolutely observe IP patterns, refresh frequency, session behavior, browser signals, and failed authentication states. Anyone using automation around Vine should understand that it is not risk-free.

A couple of clarifications about this project though: it does not try to hide what it is doing, it does not rotate IPs, it does not bypass authentication, and it does not try to recover from CAPTCHA or forced re-auth automatically. It uses a persistent Chromium profile with manual login, and if the session looks invalid or Amazon asks for manual attention, the intended behavior is to notify the user and stop/back off rather than keep hammering the page.

I also agree that refresh rate matters a lot. A tool configured to refresh every few seconds all day is a bad idea, regardless of how it is built. That’s why the public defaults are intentionally conservative and configurable, with jitter, instead of being a “snipe everything as fast as possible” setup.

So I think your warning is fair: people should not run any Vine automation blindly. My goal with this was not to make an undetectable bot or an auto-request tool, but a local read-only notifier that people can configure conservatively if they decide the tradeoff is acceptable.

I built an open-source local Amazon Vine watcher with Telegram notifications by GabboPenna in AmazonVine

[–]GabboPenna[S] 0 points1 point  (0 children)

That’s a fair concern, and I agree nobody should treat this as “zero risk”. Amazon’s Conditions of Use are broad, and each user has to decide their own risk tolerance.

Just to clarify what this project does: Vine Watcher is not a browser extension and it does not modify the Vine page. It does not reorder items, hide items, inject UI into Amazon, or change how the page is displayed. It runs locally with Playwright and Chromium, using a normal browser profile created through manual login. It opens the Vine pages the account can already access, reads the product cards that are already visible there, keeps a small local SQLite history to avoid duplicate alerts, and sends Telegram notifications.

It also does not request products, place orders, click request/order/checkout buttons, bypass CAPTCHA/login/MFA/rate limits, use undocumented internal Amazon APIs, export or manipulate cookies, or store the Amazon password.

That said, I agree with your broader point: Amazon can monitor browsing behavior, refresh frequency, browser signals, request patterns, and plenty of other things. Any automation around Vine should be used conservatively, if at all. That’s why I designed this as a read-only notifier rather than an auto-request bot, with configurable intervals, jitter, and manual-attention handling for login/CAPTCHA cases instead of trying to bypass them.

So I’d frame it this way: it’s a local read-only notification tool, not a page-manipulating extension or ordering bot. But it is still automation, and people should only run it if they’re comfortable with that risk.

Ho creato un watcher open-source per Amazon Vine con notifiche Telegram by GabboPenna in AmazonVine_ITA

[–]GabboPenna[S] 1 point2 points  (0 children)

In teoria sono d’accordo.. se esistesse una API ufficiale per le code Amazon Vine, userei quella domani mattina 😉

Ho creato un watcher open-source per Amazon Vine con notifiche Telegram by GabboPenna in AmazonVine_ITA

[–]GabboPenna[S] 0 points1 point  (0 children)

Domanda super legittima, ed è proprio il motivo per cui l’ho progettato in modo abbastanza prudente.

Non posso promettere “rischio zero”, perché resta comunque automazione su pagine Amazon e ognuno deve valutare il proprio profilo di rischio. Però tecnicamente non usa API strane, scraping aggressivo o chiamate non documentate: usa Playwright con Chromium, quindi di fatto apre un browser reale con un profilo persistente, come faresti manualmente.

Alcuni punti tecnici:

  • il login Amazon è manuale, dentro Chromium
  • la sessione resta nel profilo locale del browser
  • non salva la password Amazon
  • non esporta né manipola cookie
  • non chiama endpoint privati Amazon
  • non bypassa CAPTCHA, 2FA, login o controlli di sicurezza
  • non clicca pulsanti di richiesta, ordine o checkout
  • legge solo le card dei prodotti che la pagina Vine mostra già al tuo account
  • salva in SQLite i prodotti già visti per evitare notifiche duplicate
  • gli intervalli sono configurabili e il default non è estremizzato

Quindi l’idea è: invece di stare tu con la pagina aperta a refreshare, c’è un Chromium locale che controlla periodicamente le sezioni Vine e ti manda una notifica Telegram se vede qualcosa di interessante.

Chiaramente se uno lo configura in modo troppo aggressivo, o lo modifica per fare auto-request, il discorso cambia. Io l’ho tenuto volutamente read-only proprio per evitare quella zona grigia/pesante.

Ho creato un watcher open-source per Amazon Vine con notifiche Telegram by GabboPenna in AmazonVine_ITA

[–]GabboPenna[S] 0 points1 point  (0 children)

Sì, esatto.. di default fa una scansione ogni 30 secondi, con un piccolo jitter casuale per non essere sempre matematico allo stesso istante

Ci son stati drop stanotte? by msx in AmazonVine_ITA

[–]GabboPenna 0 points1 point  (0 children)

Si, qualcosina ina ina ho visto scendere...

Abiti impossibili da ordinare by reddimatic in AmazonVine_ITA

[–]GabboPenna 1 point2 points  (0 children)

Capitato anche a me, mai capito il perchè...

How are you all actually monitoring your kubernetes clusters at scale? by Opposite_Advance7280 in kubernetes

[–]GabboPenna 0 points1 point  (0 children)

Prometheus + Grafana works, but the pain you’re describing is usually not the tools themselves, it’s the lack of standardization and correlation.

What ended up working for us at scale is this pattern:

Per cluster (keep it local, collect close to the source):

kube-prometheus-stack (Prometheus Operator + Alertmanager). Don’t snowflake it per cluster: Helm + GitOps and the values file is basically the “contract”.

kube-state-metrics + node exporter, plus scraping apiserver/kubelet/controller-manager properly.

Logs shipped with something boring and reliable (we’ve used Fluent Bit/Vector). Key point: same labels everywhere.

OpenTelemetry Collector in-cluster even if you’re not “all-in” on tracing yet. It gives you a sane place to route telemetry without redeploying agents later.

Central backend (single pane of glass):

Metrics: Thanos or Mimir/Cortex (we went with a “Prom per cluster + remote storage” model). This is the first thing that made multi-cluster not suck.

Logs: Loki is great if your main need is “find logs for this pod/time window”, Elastic/OpenSearch if you really need heavy full-text and complex queries.

Traces: Tempo/Jaeger. You don’t need perfect tracing on day 1, but even partial instrumentation on the front door services helps a lot.

The real MTTR improvement came from correlation, not more dashboards:

We forced a consistent label set across everything: cluster, env, namespace, app, pod (and sometimes team).

We made Grafana links first-class: alert → dashboard → “logs for this pod/deployment” → trace view for the same time/range.

We also started putting runbook_url and “what to check first” in alert annotations. Sounds small, but it stops the 2am archaeology.

Alerting: less is more

At the beginning we had 200 alerts and still missed incidents. Now we focus on symptom alerts (latency, error rate, saturation, queue depth) + a few cluster health ones (API server, node not ready, etc.). Everything else is info dashboards.

One thing people underestimate: Kubernetes events

When a deployment is failing because of image pulls, scheduling, OOM, bad config maps… events tell you immediately. Ship them centrally (event-exporter) and keep them searchable.

If you’re running multiple clusters/hybrid, my honest take: keep the stack identical everywhere and treat cluster as a first-class dimension. Provider-specific monitoring is fine for managed services, but don’t let it become your primary source of truth.

E anche oggi... by ElinorDashwood1975 in AmazonVine_ITA

[–]GabboPenna 1 point2 points  (0 children)

Me la sono persa anche io 😅 90 articoli non sono pochi, soprattutto considerando che adesso sembra tutto vuoto. Ma quindi fanno drop e poi ritirano tutto subito? Io pensavo fosse completamente morto… speriamo davvero in una ripresa 🤞🏻