Logging options or best endpoint for health check

I’ve implemented a Health Check in AWS to compute.geometry. I’ve asked it to request “…/version” to check health status.

Compute logs every request, thus the “version” requests swamp my more useful “…/grasshopper” POST’s.

  1. Is there a better status endpoint to use for a Health Check that would not be logged?
  2. or, is there a command line option or environment variable to modify the compute logging level.


Hi Bill. Thanks for your question. Regarding your first question:

  1. Is there a better status endpoint to use for a Health Check that would not be logged? Yes, there’s a better endpoint to use here. You should be able to use the endpoint “…/healthcheck” to determine if the app is alive. If all is well, you should see a response back from the app which returns the word Healthy. This is probably the endpoint you would want to use in your application.

  2. Is there a command line option or environment variable to modify the compute logging level? If you’re specifically targeting the compute.geometry project for logging, then the place to look for how to modify the logging would be in the Startup.cs file. At the bottom of the file, you’ll see a line that looks like Console.WriteLine(msg);. Well, we need to put a check in to only print the message to the console if the request doesn’t include the “…/healthcheck” endpoint. So, the code would now look like this:

if (req.Uri.AbsolutePath != "/healthcheck")
    // log request in apache format
    string msg = $"{req.RemoteIpAddress} - [{DateTime.Now:o}] \"{req.Method} {req.Uri.AbsolutePath} {req.Protocol}\" {res.StatusCode} {contentLength}";

Now, it would only print the console message if it’s anything other than the healthcheck endpoint. We’ve already added this code to the code base, but if you would rather simply replace your existing build of the compute.geometry project, that would work too. You can download the latest build artifact of the compute.geometry project from this link: https://ci.appveyor.com/api/projects/mcneel/compute-rhino3d/artifacts/compute.zip?branch=master

Simply, unzip the contents and replace your existing compute.geometry folder (this should be located at C:\Users\name\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\Hops\0.10.1) with this new one.

We will be working to clean up the console logging so that it is a little cleaner and easier to read. Thanks for your suggestions!

1 Like

Perhaps I misunderstood.

I download and unzipped. When I run compute.geometry, I get version: {“rhino”:“7.13.21348.13001”,“compute”:“”,“git_sha”:“881c3925”}.

When I call the healthcheck endpoint, that call is still logged to the console.

CG [19:45:03 INF] Compute, Rhino 7.13.21348.13001
CG [19:45:03 INF] Configuration Result:
[Success] Name compute.geometry
[Success] DisplayName rhino.compute
[Success] Description rhino.compute
[Success] ServiceName compute.geometry
CG [19:45:03 INF] Topshelf v4.1.0.172, .NET Framework v4.0.30319.42000
CG [19:45:03 INF] Launching RhinoCore library as Administrator
CG 80 [19:45:07 INF] Starting listener(s): [“http://+:80”]
CG 80 [19:45:10 INF] (1/2) Loading grasshopper
CG 80 [19:45:14 INF] (2/2) Loading compute plug-ins
CG 80 [19:45:16 INF] Listening on [“http://+:80”]
CG 80 [19:45:16 INF] The compute.geometry service is now running, press Control+C to exit.
CG 80 [19:45:16 INF] - [2022-01-09T19:45:16.4725315+00:00] “GET /healthcheck HTTP/1.1” 200 -
CG 80 [19:45:18 INF] - [2022-01-09T19:45:18.5506032+00:00] “GET /healthcheck HTTP/1.1” 200 -

Ok. I may have misunderstood your original question. I thought you were only using the compute.geometry project, but it looks like you’re actually using the rhino.compute project which is then launching the compute.geometry project as a sub process. We have logging happening in both projects. Anyway, we’ve added some additional logging attributes to the code base for both projects as well as some refactoring of the /healthcheck code. So, I would recommend downloading the zip file linked below and then replacing both the rhino.compute and compute.geometry folders in your current directory with these new build files. Again, these should be located here: C:\Users\name\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\Hops\0.10.1. Let us know if you’re still seeing requests showing up in the console window when you hit the healtcheck endpoint.

rhino.compute (Jan 2022)

I’m a little unclear on the two different names. There is a middleware server project, with a GitHub name of compute.rhino3d.appserver.

I am NOT using that project. I have a similar, but much lighter weight middleware server that calls the GitHub project called compute.rhino3d. I have compiled that project as suggested, and use it for local development.

In AWS, I use only the compute.geometry.exe in the Compute folder, as installed by the instructions in https://developer.rhino3d.com/guides/compute/deploy/. I launch that manually.

I’ll try the new zip file soon.


Yes. Naming is hard and admittedly the naming conventions used for the rhino.compute project are a little difficult to understand. The main compute github repo has two main projects in it. One is called rhino.compute and the other is called compute.geometry. The rhino.compute project is pretty small but basically handles incoming requests. Based on the type of request it receives it will spin up one or more child processes running the compute.geometry project. This basically means the rhino.compute project acts as a reverse proxy. The compute.geometry project is the larger of the two projects and this is where all the calculations are done for rhino3dm. The amount of time that the compute.geometry process is running also determines how much you get billed for our core-hour billing procedure (click here to learn more about core-hour billing).

So, you may wonder why we broke it into two parts. Firstly, we wanted to be able to spin down the compute.geometry project wasn’t getting used very often (to essentially save everyone money). So, the rhino.compute project sits open all of the time and just waits for incoming requests. If an incoming request is made that requires the compute.geometry project, then it will spin up a new child process (if one isn’t already active) and then do the calculation and return the result. If after a certain time has elapsed (the default is 1 hour and is called idle spans) then the rhino.compute project will spin down the child process and stop the core-hour billing. The second reason we wanted to split the project in two was so that we could handle multiple requests at the same time with different processes - which is safer for Rhino calculations than trying to do everying in a single process with multiple threads.

It looks like you’re trying to rhino.compute and/or compute.geometry in a production environment (not testing it locally). If that is the case, we would now recommend following up this guide to setup rhino.compute behind IIS. This is our new preferred method for deploying rhino.compute for production environments and the other method (the one you linked) is now a bit obsolete. It should still work, but this newer method is a little more robust. Anyway, have a look and let us know if you have any additional questions. It is a long guide and we’re looking for ways to condense it a bit… but let us know if we missed anything. Cheers.