Created a status endpoint on the dashboard which returns active servers

[yngndrw]

Created a status endpoint on the dashboard (http://{server}/hangfire/status) which returns information about any servers which have been active in the last 5 minutes. The servers are explicitly filtered in case there is no background job server running to clean up expired servers.

Results are returned in JSON format and are cached in-memory for 30 seconds, reducing server load if the page is polled frequently. HTTP status 200 is returned if there is at least one active server, otherwise HTTP status 500 is returned.

Example output with one active server: (Status: 200)

[
  {
    "name": "andrew-computer:140328:c4b87a3a-963d-4144-a983-87e5a4af3628",
    "workersCount": 40,
    "startedAt": "2015-08-19T22:48:25.7030065Z",
    "queues": [
      "critical",
      "default"
    ],
    "heartbeat": "2015-08-19T22:48:41.433"
  }
]

Example output with no active servers: (Status: 500)

[]

Please see discussion topic:
http://discuss.hangfire.io/t/query-server-status-remotely/1242

[odinserj]

@yngndrw, sorry for the delay. This feature is surely nice, but it can be implemented outside of Hangfire.Core library with some changes (StubPage isn't necessary, context.JobStorage is enough for getting the storage), and a new route can be plugged in with DashboardRoutes.Routes public property.

I don't want to add HTTP API endpoints to the core library, and even if we add this one, I'm sure we'll end up with other API methods. I want to keep a balance between features and simplicity of the main assembly.

The only thing that stops me from making a fine-grained set with separate packages for fire-and-forget, recurring jobs, scheduled jobs, continuations and some other things is confusion for new users, when they are required to install additional packages and write additional plumbing code to support features that may expected to work without any configuration (and raise a lot of questions Why feature X does not work?).

Proper HTTP API endpoints with applied semantic versioning (/api/v1/*, /api/v2/*) is a really nice feature, but I suggest to make it as a totally separate package.

[odinserj]

And sorry, I'm currently bad project coordinator – I don't share my vision, my thoughts, principles, expectations regarding to contributions and a lot of other things with others. I totally understand that this is bad for the long term, and this prevents Hangfire from being true open-source project. But I'm constantly thinking about this.

[yngndrw]

Hi Sergey,

I fully accepted the risk of this pull request not fitting into the vision and roadmap, it all goes hand in hand with pushing pull-requests. I had hoped that it would either resolve the issues raised on the discussion site or spark up a new discussion around APIs.

There are many questions left outstanding, authentication was one which wasn't at all considered as part of this pull-request. (The dashboard should be private, but a status endpoint needs to be public) As you mention things such as API versioning and partitioning are also serious considerations. (Should a modification API be partitioned into areas such as fire-and-forget and recurring, or should this be a multiple resources within a single API ? Should meta-data and status endpoints be packages separately from others ?) Then of-course there's the question of technology. (Should MVC 6 be used when it's released early next year ? Should Owin be used ? Should raw ASP.Net 5 be used ?)

Of course, there's also the scope that must be considered. Should this just be an API mirroring the functionality of the library, or could IBackgroundJobClient for example have another implementation which uses the API, allowing usage across different machines ? Could IMonitoringApi be implemented in a way which combines the results of multiple API on different machines, so that you can get a dashboard showing an aggregated view across multiple remote databases ? (As requested in another discussion topic)

My thoughts on packaging would be that there would be two packages, a single package for modification endpoints (I.e. Fire-and-forget, recurring jobs, scheduled jobs, continuations, etc.) and another package for status and monitoring. I think this would reduce the support questions that you mentioned while still being fine-grained enough for people who just want to query data without making changes. I totally agree on versioned endpoints and it's critical to get this in-place immediately so that you aren't left with /api/ for v1 and then /api/v2/ for the next version.

[odinserj]

I totally understand the significance of HTTP endpoints that expose status of background processing – it can be plugged into different monitoring tools. However, for modifications IMO it is better for application developers to create more specific HTTP endpoints with the concrete domain language instead of a generic one (so it can send newsletters, but can't create background job of type X, method Y and argument Z).

Regarding to the questions, you are right, there are many of them, and it is better to get rid Hangfire.Core of them completely :-)

[ses4j]

@yngndrw We're using your endpoint, dropped it into our custom build of Hangfire and it works great. Thanks! We needed it for a similar situation, monitoring from an F5 load balancer.

[yngndrw]

@ses4j Glad it is of use to you. I've been meaning to move it into its own monitoring API package based on @odinserj's comments and feedback but sadly haven't gotten around to making the changes. I think I have a better idea in my head of how it all could look now but with ASP.Net Core 1.0 just around the corner I think it's worth holding off a little longer before updating the pull-request.

Out of interest, what do you do to handle authentication for this ?