Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kitura-specific monitoring #5

Open
tobespc opened this issue Jan 26, 2017 · 3 comments
Open

Kitura-specific monitoring #5

tobespc opened this issue Jan 26, 2017 · 3 comments

Comments

@tobespc
Copy link
Member

tobespc commented Jan 26, 2017

Raised from

https://github.com/IBM-Swift/SwiftMetrics/issues/21

@tobespc
Copy link
Member Author

tobespc commented Mar 10, 2017

closing as parent is closed

@tobespc tobespc closed this as completed Mar 10, 2017
@mattcolegate
Copy link
Member

Re-opening as I don't think we addressed any of the issues in the parent

@mattcolegate mattcolegate reopened this Mar 10, 2017
@mattcolegate
Copy link
Member

From David Jones:
"On the 'standard stuff that would be of interest to 90% of people', at least from my perspective: basic statistics about the usage of various facilities of Kitura. In other words, to have a basic dashboard of "How is my Kitura server configured, and how is it currently being used".
For example:
Routing: My application defines 10 routes (URLs). How frequently is each route driven? What is the distribution of payload sizes (received / sent) and processing times for a route?
Logging: Is it enabled (+ at what level?) Where are logs being written? At the moment, I think we only support stdout ... but in the future this might be more useful. Could we even get access to the logs?
Errors: How frequently does my application respond to an erroneous request? Are there persistent offenders (for example, IP addresses which are generating a lot of bogus traffic, or URLs that are frequently requested but not handled)
Load: How many clients are connected? How long has a client been connected? How many requests has he made? What is the average / max response time back to that client?

... just some ideas, I appreciate some may have non-trivial overhead, so might be nice to have a 'trace levels' style facility where you can choose (it would have to be at build time) what level of information was available.
I can imagine you might have a server running with high levels of detail (and the associated performance impact) when testing / debugging."

I expect this would be best implemented using Kitura Probes, which means having a SwiftMetrics Probe Framework.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants