csharptips/ping-endpoint

[utterances-bot]

C# Tip: use the Ping class instead of an HttpClient to ping an endpoint - Code4IT

Sometimes you need to ping some endpoints. Don't rely on HttpClient, but use the native Ping class.

https://www.code4it.dev/csharptips/ping-endpoint

[AndyPook]

Ping uses a different protocol (ICMP) to test if a host is addressable. Basically just if the network card is "live". If an address is serving many sites (as is normal) or the site is behind some gateway/Ingress/firewall/etc (they all are) then ping will just show that that initial endpoint is "up" not necessarily that the specific site is live. Some hosts (even some ISPs) will block ICMP as a security measure.

Even using HEAD (a nice idea) doesn't always work as not all sites/paths support that method. Even just checking for 2xx status codes doesn't always work as some sites will put a "bad things happened" page in front of a failed site.

The only thing that is (somewhat) reliable is to do a GET and scan the returned html for some "healthy" signal (pattern of text maybe, though site redesigns can break this). Checking for redirects can also be a signal (default HttpClient options will auto-magically follow redirects)

This stuff is a nightmare :(

[bellons91]

Yes, right! It's a mess!

Some hosts - like those stored on Azure - block ping requests. In those cases, we should use tcpping (as explained here ).

But, AFAIK, there's no native class for tcpping on C#

[AndyPook]

easy enough to write one :)

but also... tcpping still has most of the issues I listed with ping. Maybe it's "ok" with AppServices (do you get a dedicated ip-address for every service?).

tcpping just detects whether port 80 (I assume there's an option for 443) is open on the address specified. But that'll just be the public endpoint (ie firewall, proxy, balances, gateway, Ingress, ...). It might have something like CloudFlare or FrontDoor in front of it. So it may not touch the actual "web site" as this may be several hops away behind some routing that uses the http Host header or TLS SNI to route to the actual site (amongst all the others hosted on the same address). That public endpoint could be serving some "bad things happened" page because your site (on some internal host) is down/broken.

I'm talking about infrastructure in general, I'm not completely familiar with AppServices specifically.

If you just want to check if the wider "hosting system" has a live public port, this is fine. But it doesn't really tell you anything about the availability/health of the "web site".

[bellons91]

Yes, you're right.

There's no way to ensure that we are calling the actual service.

The only two ways that come to my mind are:

• using Ping only to ping for services within our infrastructure - so referring directly to Origin
• call an Health Check endpoint - hoping that there's nothing that caches it, of course :D

Can you think of any other ways?

[AndyPook]

Ping fits if you are using unmanaged infrastructure. This is one of the many things you get by buying into IaaS/PaaS. Part of what you're paying for is the "is it up" signals, dashboards etc. If you're running your own hardware then some systematic "ping" system will be necessary. But there are also products that will do these things for you (thinking Elastic Search with Beat etc) you can get a long way with the free tiers. Or things like Pingdom which you can teach how to determine if your site & api is up and functional. Building this stuff yourself can be a huge distraction from your actual product.

HealthChecks... definitely. These are generally a step or two down from the app itself. Checking things like: can the process reach the datastore?; can it see the payment system? can it see the internet? etc etc And then you need something to prod these and record the history and success/failure and perform actions (ie restart; notify). Kubernetes has features built in for some of this (ie only add a service to the load balances when a service becomes healthy; bounce a pod if healthchecks fail ...). Other PaaS systems have similar abilities.

Then there's Metrics. Hopefully as part of a fuller Telemetry/Observability strategy. Capture metrics (request per second; request duration; error rate; queue length; memory usage...) with appropriate labels. Then dashboards can show a different aspect of the health of your system. Kubernetes (and other "cloud" systems) can potentially use those metrics to auto-scale your system. Queue length too long; number of users growing; request duration too long... scale out the number of instances of the various services to consume message faster; handle more users concurrently etc etc

On Fri, 22 Oct 2021 at 10:07, Davide Bellone @.***> wrote:

Yes, you're right.

There's no way to ensure that we are calling the actual service.

The only two ways that come to my mind are:

• using Ping only to ping for services within our infrastructure - so referring directly to Origin
• call an Health Check endpoint - hoping that there's nothing that caches it, of course :D

Can you think of any other ways?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/code4it-dev/blog-comments/issues/18#issuecomment-949431439, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAF6XK5WGIOBFZESZLH4DELUIESWLANCNFSM5GJM2YJA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.