François Battail ha scritto:
I've almost finished the module (read: compilation reports no error) and want to
take some time to discuss about some potential issues.
Good.
1) Interaction with Nginx
[...]
2) API
The API consist in one call:
void ngx_register_monitoring_value (ngx_str_t * name, ngx_atomic_t * value) ;
This function should be called by an Nginx module during it's initialization to
tell the monitoring module that this variable should be added to the pool for
watching.
That's all. The module just continue to do what it wants with its ngx_atomic_t
value, I will do the rest.
I may have some issue because my module has three states: initializing,
registering, running so may be the order of modules may be problematic.
When actually happens the running phase?
At the end of the HTTP request? At regular intervals?
Note that since you don't know when a variable will be updated, you may
miss important changes in the variable.
As an example, in the upstream module if a peer is down, the variable
peer.down will be set to 1, but if *all* the peers are down, then all
the variables are set to 0, for a fast restart in the successive request.
3) Configuration
[...]
4) Scripts
A script should have read access to where nginx.pid is and will do the following
pseudo code:
shm_id = ftok ("path.to.nginx.monitoring") ;
mem = attach_to_shared_mem (shm_id) ;
values = parse (mem)
do_what_you_want_with_values (values)
I can't see any form of synchronization here.
for example: update RRD databases, search for an anormal error count, search for
an event unexpected...
It's no more my problem :-)
5) Conclusion
Dear List, tell me what you think and I will release soon this module (under A
BSD-like licence of course) for review and comments.
Best regards.