effective logging in ceilometer
logging in ceilometer is unique, we have a (possibly) extremely high load funnelling data through very few unique channels so if we do not log appropriately, we will have a either no information or way too much information.
this blueprint is to discuss how to log effectively in ceilometer so we can capture and convey the right information on the right levels.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- gordon chung
- Direction:
- Needs approval
- Assignee:
- gordon chung
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- gordon chung
Related branches
Related bugs
Sprints
Whiteboard
to start off, a listing of log levels. i think we should capture what type of log we expect at each point and once we have a good consensus, we can document it somewhere.
CRITICAL:
- this won't start or anything that will trigger a system exit -- gordc
ERROR/EXCEPTION:
- exception/error cases -- gordc
WARNING:
- exception/error cases that are expected to occur regularly --gordc
AUDIT:
- i'm not sure the purpose of this level... we use it but i don't think we should -- gordc
INFO:
- logging non-recurring actions.... maybe setup sections -- gordc
DEBUG:
- 'you are here' type messages... it might be useful to include some information regarding environment -- gordc
Gerrit topic: https:/
Addressed by: https:/
Logging Guidelines for Ceilometer
You should not set a milestone target unless the blueprint has been properly prioritized by the project drivers.
uh...sure. abandoning since it's not that important anymore -- gordc(10.7.15)
