check_http monitor or similar. Run http checks on local host

[ct_27]

We're moving off of OpsView which uses Nagios opensource agents.   The one in question is http_check.   The purpose of this Nagios Plugin is to run an http/https check on the local machine.  This validates that the website is running and by running it locally it eliminates other potential points of failure such as firewalls and eliminates some security checkpoints like SSO.

For those wondering how this is useful if for say the end user can't reach the url.  It's a controlled test to validate the basics are functioning so that when alarm goes off we can eliminate the question of if the foundational components are working. If so, then we know the break is out on the firewall,network, or users ISP.

Also, this allows us to call different subdirectory tests like domain.com/application1, domain.com/application2,

To conduct this check it'll be as simply OneAgent Extension running pythons requests.get, validate the status_code and as necessary validate the responding headers and text contain validating text.

-OR-

Leave the opensource nagios http_check plugins on our machines and use an ActiveGate extension to call the http_check command remotely (just like OpsView does) and consume the response as a thirdpart-synthetic.

I'm just checking with the community if anyone has encountered this need already and developed a solution.   

[ChadTurner]

Maybe I don't understand the question, but you can create AGs that provide Synthetic functionality on internal apps/web pages. Is that what you are looking for? to create a Synthetic internally? 

[Julius_Loman]

@ChadTurner ActiveGates in many cases can't reach the local service. Imagine a service listening on loopback interface only. Unless you have ActiveGate locally installed, you cannot do any HTTP checks.

I believe in old OneAgents there was an option to do HTTP checks from OneAgent and that was then moved to ActiveGate. 

[AntonioSousa · Accepted solution]

For what I understand, the service should be available remotely, because as @ct_27  said it's servicing users. So it could be tested by an Activegate HTTP monitor.

But, on the other hand, testing with the localhost strategy, guarantees that the service is running and not affected by network outages or security issues. Please beware that some of these events might complicate the point below, because if network fails, for instance, network connectivity back to Dynatrace might be a problem.

Given this, I see two opportunities here: having a OneAgent extension, like @ct_27  referred to, but also doing the script test and sending the results through the Dynatrace API. This latter one is a little bit more messy to implement, though. Regarding licensing consumption, I'm almost certain that if they are sent as metrics, there will be no DDU consumption with a OneAgent extension (within limits), but not quite sure with the API technique.

Finally, check the "connectivity" feature in Dynatrace, as it should give some ideas of problems. Also check some other metrics, particularly builtin:tech.generic.network.sessions.connectivity, as it gives connectivity values at the process level.