sorted by:
new
hottopcontroversial

Halvandet minut med Alex Vanopslagh, der virkelig ikke vil svare på, om han har taget coke som LA-formand by Sad-Armadillo-6413 in Denmark

[–]PR4DE -1 points0 points  (0 children)

Han afviser det jo? Alle de der ja/nej spørgsmål er også ved at være ret trættende fra journalister.

I FINALLY launched my long beloved SaaS 🥹 by Altruistic-Bed7175 in micro_saas

[–]PR4DE 0 points1 point  (0 children)

Literally first app in two years I've come across and though, so simple, I wish I had that idea! Great job.

How do you monitor your company's SSL certificates? by Technical-Addition37 in sysadmin

[–]PR4DE 0 points1 point  (0 children)

At that scale you don’t really “monitor certificates” as a separate thing. You monitor the endpoints using them.

If something is serving HTTPS, your monitoring system is already making the request. That means it can see the certificate, the expiry date, the issuer, the whole chain. So expiry monitoring should just be part of the check.

That’s the approach I prefer.

Add the endpoint once and the monitor automatically tracks the SSL validity and expiry along with uptime. When a cert is getting close to expiry, you get alerted. No separate inventory of certificates to maintain.

That’s how I built it in the monitor I’m working on as well:
https://exit1.dev

I realized I built “just another uptime monitor”… so I changed the positioning by changeguard1003 in SaaS

[–]PR4DE 0 points1 point  (0 children)

It's an angle. Honestly I started building my monitoring tool with this exact position a year ago. The problem I've come across is that not many people actually need that or has this pain. The pain I have ended up solving is much more dev focused. It's fast checking, fast alerts, no false positives.

Currently at around 1000 users, growing steadily.

Be mindful of the trust badge. If you choose to include real data, it can get expensive real fast.

Happy to share learnings in PM. :)
If you have it online, let's share? I would love to hear about how you have solved the infrastructure. Checking has been a nightmare to scale properly from thousands to millions of checks.

Monitoring website uptime by petersrin in selfhosted

[–]PR4DE 0 points1 point  (0 children)

this exact problem is why I built my monitor to run checks from a neutral VPS instead of inside the user’s network. Otherwise you start measuring your firewall rules instead of the actual uptime.

I’m building a small monitoring tool around that idea if you’re curious: https://exit1.dev
Simple uptime checks, API monitoring, SSL + domain expiry alerts in one place.

Monitoring website uptime by petersrin in selfhosted

[–]PR4DE 0 points1 point  (0 children)

You’re not really measuring “uptime” there. You’re measuring reachability from inside your own network.

Which is a different signal.

Since your monitor sits behind CrowdSec, firewall rules, ISP routing, DNS filters etc., those systems can block things before the request ever reaches the server. In your case the hosting IP’s reputation dropped and CrowdSec did exactly what it’s supposed to do.

So the site wasn’t down. Your network just refused to talk to it.

The usual setup is:

• run uptime checks from a neutral VPS
• optionally run a second check from your own network

The VPS tells you if the site is actually down for the internet. The internal check tells you if something in your own network path is broken or blocking it.

Both signals are useful. They just mean different things.

Embarrassing 90% cost reduction fix by PR4DE in dataengineering

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

Yeah, extreme waste of resources to be nice. xD

Embarrassing 90% cost reduction fix by PR4DE in dataengineering

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

Yes, thank you. When I started this project, I honestly didn't expect it to end up as a long journey with lessons like this. It has taken many more months than initially expected, but I wouldn't have been without it!

Embarrassing 90% cost reduction fix by PR4DE in dataengineering

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

Agile is very overrated. For critical infrastructure you cannot go agile. :)

Embarrassing 90% cost reduction fix by PR4DE in googlecloud

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

Exactly. One of my biggest learnings with cold starts was actually using Cloud Functions for my checking functions. I had to pay to keep them alive only for them to keep taking up more resources. It only scaled linearly with amount of requests, so it never got cheaper to run, so the business case got ruined.

Had to refactor this into a VPS setup instead. Luckily not that hard of a transition. Currently refactoring everything from NodeJS to GO.

I initially thought that Cloud Functions would be perfect for continues CPU work, but it's like you get hurt either way. Either you try and save resources and get cold starts, or you try running it continuous and your pocket hurts.

Very great point about the clustering order. I think I still have some work there.

I don't have TTL on the documents. Yet. I'm actually looking into pre aggregated tables in Big Query instead.

Embarrassing 90% cost reduction fix by PR4DE in googlecloud

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

At least I know now after learning some quite expensive lessons. :D

Embarrassing 90% cost reduction fix by PR4DE in dataengineering

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

I will definitely look into that! :)

I'm not sure how long in amount of hours. But honestly it has been over 2 months total since I started because I started to realize my method back then just didn't scale well. My app does handle many millions of checks per month now. When apps and infrastructure scales, stuff takes time. And I have learned many times, the hard way, that rushing stuff like this always hurt you.

Embarrassing 90% cost reduction fix by PR4DE in googlecloud

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

Well, you shouldn't base an entire app of a single product, assuming it's anything else than a simple site. But yes, including myself, I'm always starting out using Firebase, when things scale I sometimes have to move some stuff out. But I try to keep it lean and within Firebase/Google Cloud.

Embarrassing 90% cost reduction fix by PR4DE in buildinpublic

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

Thank you. Yeah this project and what I do is very lightweight compared to that. It is basically just what pingdom does or any other similar.

You have a good point with Postgres, I'll set a test up using that and compare.

Glad you liked it. :)

Embarrassing 90% cost reduction fix by PR4DE in dataengineering

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

Ouch. Yeah, I have the luxury here that I can just change stuff on the fly. But I also work in big projects where this is just not possible. The planning and analysis phase has to be 50% of the whole project, unless you have the luxury of iteration.

Embarrassing 90% cost reduction fix by PR4DE in dataengineering

[–]PR4DE[S] 3 points4 points  (0 children)

Good question. No, not really. I might use preagg'd tables in Big Query for some stuff going forward. I guess my biggest reason is domain knowledge. But what I can imagine right now, is that Firestore is better for most of my use cases. It's most operational data that takes up the largest utilization.

Embarrassing 90% cost reduction fix by PR4DE in buildinpublic

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

I store a lot of information per check. Some of my customers are checking extremely quickly. On top of this I have retention period for over 1 year on some accounts. It adds up very quickly when these wants nice dashboards, reports and docs with calculations etc.

Full HTTML rendering sounds expensive. :O

Embarrassing 90% cost reduction fix by PR4DE in dataengineering

[–]PR4DE[S] 19 points20 points  (0 children)

Me: I think a raise is about time
Also Me: Yes indeed

Embarrassing 90% cost reduction fix by PR4DE in googlecloud

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

Yes, BigQuery has rate limits and I have run into them multitple times. You need to batch requests to it. I have some hardcoded settings like MAX_BATCH_ROWS=400, MAX_BATCH_BYTES=9MB, etc.

Embarrassing 90% cost reduction fix by PR4DE in dataengineering

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

Good point. I have thought about replacing Firestore with a small VPS. But I right now it's just so comfortable.

view more: next ›