Project

General

Profile

Actions

User story #8183

open

Add a more detailed status API with component status

Added by Janos Mattyasovszky almost 8 years ago. Updated over 3 years ago.

Status:
New
Priority:
N/A
Category:
API
Target version:
-
UX impact:
Suggestion strength:
User visibility:
Effort required:
Name check:
Fix check:
Regression:

Description

We would like to implement a monitoring check, which would test, if the API is alive and responsible.

It would good if there could be a standardized way to "ping" the API, that would return a boolean answer, if it is ready to work or has something wrong.

Example:
"An unauthenticated resource that shows the current status of the Pulp server. A 200 response shows that the server is up and running."
@ http://pulp.readthedocs.org/en/latest/dev-guide/integration/rest-api/status.html#getting-the-server-status


Related issues 2 (0 open2 closed)

Related to Rudder - User story #5798: Different access levels for API keys / REST API authorizations and rightsRejectedActions
Has duplicate Rudder - User story #7730: Have an "status" call available from public APIRejected2016-01-06Actions
Actions #1

Updated by François ARMAND almost 8 years ago

I suspect you don't want something like the status API?

http://www.rudder-project.org/doc-3.1/rest-api.html#_status

Or at least that maybe you want something like that, but on the public API.

Why do you need it to be unauthenticated ? (I mean, not that don't think you need it unauthenticated, but that if we have more use cases and example, it's easier to understand the whole need, like: do we want it to always be unauthenticated ? Do we want other information than just alive for authenticated people ? This king of things).

Actions #2

Updated by Jonathan CLARKE almost 8 years ago

  • Has duplicate User story #7730: Have an "status" call available from public API added
Actions #3

Updated by Janos Mattyasovszky almost 8 years ago

The status-API from localhost is enough, if you run your monitoring from localhost ;-) But this still does not cover the case when you messed up your apache config in a way, that you have broken some of the proxy-settings, so that the API does not work from the outside, just from localhost...

Since currently there is no differentiation between API Keys, adding an API Key to an external monitoring server just to test it can for example fetch /nodes/root, is a little bit overkill.

So the proposed solution is an unathenticated endpoint, that would return something machine-parse-able (like "OK"), or just indicate a return code of 200:OK, 500:NotOK, if the API Endpoint is up and running.

I could solve this by modifying/creating a new proxy rule in apache to expose that status-api to external, but it would be nice if this could be done in an upstream way.

Actions #4

Updated by Janos Mattyasovszky almost 8 years ago

Additional note: this would be solved if the access level of the API Keys could be customized, for example one just having the basic access to poll the status of the services...

Actions #5

Updated by Janos Mattyasovszky almost 8 years ago

  • Related to User story #5798: Different access levels for API keys / REST API authorizations and rights added
Actions #6

Updated by Matthieu CERDA almost 8 years ago

Important note: the REST-way of creating a status like API is either to return a real status in JSON format:

{
  "status": "OK",
}

or a valid empty JSON response:

{ }

with a status code 200 or 500 depending on the application status.

I feel that just "OK" as a response body is not acceptable (a REST API should always return valid JSON, or an empty body)

Actions #7

Updated by Vincent MEMBRÉ almost 8 years ago

I agree with Matthieu on the response format (which should follow other API responses format) and use adequate answers when not working

Actions #8

Updated by Janos Mattyasovszky almost 8 years ago

Regarding the response: I totally agree, that we'd need to return a valid json.

If you'd want to make it future-proof, you could add something like:

{ 
  "services": { 
    "database": "ok", 
    "ldap":     "ok", 
    "webapp":   "ok" 
  }
}

One thing to talk about is if this would require any kind of authorization.
If yes, the linked User Story #5798 would help to secure a monitoring-only API Key.

Actions #9

Updated by Janos Mattyasovszky almost 8 years ago

There was something similar implemented for gitlab 8.8 released recently:

http://docs.gitlab.com/ce/monitoring/health_check.html

Actions #10

Updated by Vincent MEMBRÉ over 7 years ago

  • Status changed from New to In progress
  • Assignee changed from Nicolas CHARLES to Vincent MEMBRÉ
Actions #11

Updated by Benoît PECCATTE over 7 years ago

  • Target version changed from 4.0.0~rc2 to 4.0.0~rc3
Actions #12

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 4.0.0~rc3 to 4.0.0~rc4
Actions #13

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 4.0.0~rc4 to 4.0.0~rc5
Actions #14

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 4.0.0~rc5 to 4.0.0
Actions #15

Updated by François ARMAND over 7 years ago

  • Target version changed from 4.0.0 to 4.1.0~beta1
Actions #16

Updated by Vincent MEMBRÉ about 7 years ago

  • Target version changed from 4.1.0~beta1 to 4.1.0~beta2
Actions #17

Updated by Vincent MEMBRÉ about 7 years ago

  • Target version changed from 4.1.0~beta2 to 4.1.0~beta3
Actions #18

Updated by Vincent MEMBRÉ about 7 years ago

  • Target version changed from 4.1.0~beta3 to 4.1.0~rc1
Actions #19

Updated by Vincent MEMBRÉ about 7 years ago

  • Status changed from In progress to New
Actions #20

Updated by Alexis Mousset about 7 years ago

  • Target version changed from 4.1.0~rc1 to 4.2.0~beta1
Actions #21

Updated by Alexis Mousset almost 7 years ago

  • Target version changed from 4.2.0~beta1 to 4.2.0~beta2
Actions #22

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 4.2.0~beta2 to 4.2.0~beta3
Actions #23

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 4.2.0~beta3 to 4.2.0~rc1
Actions #24

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 4.2.0~rc1 to 4.2.0~rc2
Actions #25

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 4.2.0~rc2 to 4.2.0
Actions #26

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 4.2.0 to 4.2.1
Actions #27

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 4.2.1 to 4.2.2
Actions #28

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 4.2.2 to 4.2.3
Actions #29

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 4.2.3 to 4.2.4
Actions #30

Updated by Vincent MEMBRÉ about 6 years ago

  • Target version changed from 4.2.4 to 4.2.5
Actions #31

Updated by Vincent MEMBRÉ almost 6 years ago

  • Target version changed from 4.2.5 to 4.2.6
Actions #32

Updated by Vincent MEMBRÉ almost 6 years ago

  • Target version changed from 4.2.6 to 4.2.7
Actions #33

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 4.2.7 to 414
Actions #34

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 414 to 5.0.0~beta1
Actions #35

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 5.0.0~beta1 to 5.0.0~beta2
Actions #36

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 5.0.0~beta2 to 5.0.0~rc1
Actions #37

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 5.0.0~rc1 to 5.0.0
Actions #38

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 5.0.0 to 5.0.1
Actions #39

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 5.0.1 to 5.0.2
Actions #40

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 5.0.2 to 5.0.3
Actions #41

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 5.0.3 to 5.0.4
Actions #42

Updated by Vincent MEMBRÉ about 5 years ago

  • Target version changed from 5.0.4 to 5.0.5
Actions #43

Updated by Alexis Mousset about 5 years ago

  • Target version changed from 5.0.5 to 5.0.6
Actions #44

Updated by Vincent MEMBRÉ about 5 years ago

  • Target version changed from 5.0.6 to 5.0.7
Actions #45

Updated by François ARMAND about 5 years ago

  • Target version changed from 5.0.7 to 5.0.9
Actions #46

Updated by Vincent MEMBRÉ almost 5 years ago

  • Target version changed from 5.0.9 to 5.0.10
Actions #47

Updated by Alexis Mousset almost 5 years ago

  • Subject changed from Implement very basic "ALIVE" ping for API to Add a more detailed status API with component status

Done in https://docs.rudder.io/api/#api-System-getStatus, but we could use a more detailed version with components status.

Actions #48

Updated by Vincent MEMBRÉ almost 5 years ago

  • Target version changed from 5.0.10 to 5.0.11
Actions #49

Updated by Vincent MEMBRÉ almost 5 years ago

  • Target version changed from 5.0.11 to 5.0.12
Actions #50

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 5.0.12 to 5.0.13
Actions #51

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 5.0.13 to 5.0.14
Actions #52

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 5.0.14 to 5.0.15
Actions #53

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 5.0.15 to 5.0.16
Actions #54

Updated by Alexis Mousset about 4 years ago

  • Target version changed from 5.0.16 to 5.0.17
Actions #55

Updated by Vincent MEMBRÉ almost 4 years ago

  • Target version changed from 5.0.17 to 5.0.18
Actions #56

Updated by Benoît PECCATTE almost 4 years ago

  • Target version changed from 5.0.18 to 6.2.0~beta1
Actions #57

Updated by Vincent MEMBRÉ over 3 years ago

  • Target version changed from 6.2.0~beta1 to 6.2.0~rc1
Actions #58

Updated by François ARMAND over 3 years ago

  • Target version deleted (6.2.0~rc1)
Actions

Also available in: Atom PDF