-
Notifications
You must be signed in to change notification settings - Fork 170
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
Metrics policy #860
Metrics policy #860
Conversation
end | ||
|
||
local function filter_level() | ||
local filter_level = resty_env.value(log_level_env) or log_level_default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shadowing upvalue 'filter_level' on line 42
end | ||
|
||
local function filter_level() | ||
local filter_level = resty_env.value(log_level_env) or log_level_default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shadowing upvalue 'filter_level' on line 43
ca213ab
to
f371e5e
Compare
) | ||
|
||
function _M.inc(status) | ||
if status >= 200 and status < 300 then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't be better to use math ?
string.format('%dxx', (404/100))
And handle nil
and 0
separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
|
||
local new = _M.new | ||
|
||
local log_map = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be log_list
? map
would mean a hash table?
'debug', | ||
} | ||
|
||
local log_level_env = 'METRICS_LOG_LEVEL' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should prefix it with APICAST_
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's better to name it NGINX_METRICS_LOG_LEVEL
as per your comment below about the name of the policy.
local log_level_default = 'error' | ||
local max_logs_default = 100 | ||
|
||
local function find_i(t, value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now when thinking about it. It might be good to hash this as value => i
so we have constant time lookup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that'd be better for when we want the index, but there's also https://github.com/3scale/apicast/blob/f371e5e4ec18c5046175eb2abc07d7b1c6928e7e/gateway/src/apicast/policy/metrics/metrics.lua#L88 below, so looks like we need both (value=>i, i=>value)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, thats fine no? Just need to process it once.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now it only iterates through all the elements (and there are only 8 of them) in init()
.
In metrics()
it's fetching an element from the list given an index, so this is fine as it is now. I changed the name of the var as you suggested above.
@@ -0,0 +1,113 @@ | |||
local _M = require('apicast.policy').new('Metrics') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might want to call this Nginx Metrics ? Probably need some input from @3scale/product.
Several policies will be exposing metrics and this one is really focused on internal nginx stuff like shared dictionaries, connections etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. I think we can go ahead and change it.
This is a policy included by default that does not have a JSON manifest. That means that the name will not be visible anywhere in the UI.
function _M:metrics() | ||
local logs = get_logs(self.max_logs) | ||
|
||
for i = 1, #logs, 3 do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each of those 3 different metrics could be own function to reduce complexity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or maybe extract them to their own module like this one: https://github.com/3scale/apicast/pull/860/files#diff-0a1eff24f8903a000e877b8fedece766
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather address refactorings in a future PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
f371e5e
to
e929942
Compare
This has been imported from https://github.com/3scale/apicast-cloud-hosted/
This is needed to be able to use ngx.errlogs methods that we call from the Metrics policy. Ref: https://github.com/openresty/lua-nginx-module#lua_capture_error_log
The Executor calls policies .init() without self
e929942
to
2167081
Compare
@mikz I addressed all the comments except one #860 (comment) which I'd rather address separately. |
|
||
function _M.inc(status) | ||
if not status or status == 0 then | ||
ngx.log(ngx.WARN, 'Invalid status received') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it better to actually measure this ? It would be interesting metric no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I think the http client might return 0 in some error cases, for example. Would be interesting to monitor those as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is fine 👍
I'd really consider measuring also the invalid responses from 3scale backend. Those are even more interesting than 2xx and 4xx because you actually want to have alerts when that happens.
And it would be good to have a list of metrics and an example in the PR description.
c70096d
to
9661f32
Compare
I added the list of metrics and an example in the PR description. |
Closes (partially) #745
This is an initial version with a reduced number of metrics. For now, it includes:
This is an example output: